K9s: Adjust memory and cpu warning levels

Posted by on May 28, 2024 No comments

Maybe you are like me and feel that the default memory warning level of 70% is a little off in the clusters you work.

Here is how to change them:
1. Open .config/k9s/config.yaml in your favorite editor (of course VIM 😉 )
2. Edit the section called “thresholds”

 thresholds:
    cpu:
      critical: 90
      warn: 70
    memory:
      critical: 90
      warn: 70

3. Save and restart k9s – done!

Apart from this, K9s is a wonderful tool that I don’t want to live a day without 🙂
You can find it here: https://k9scli.io/. Just download and enjoy!

Tested on K9s v.0.31.9 and Ubuntu 20.04.4 LTS (WSL2)

Path based routing in a Kubernetes Ingress (Nginx)

Posted by on May 28, 2024 No comments

Here we want to route traffic to different applications within our cluster with the help of paths. One advantage of this approach is that we only need one server certificate, since all traffic is going to use the same host.

We will focus on the Ingress here and not the Service object (every application that exposes services will need a Service object as a bridge between the application and the Ingress)

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-application-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  ingressClassName: nginx
  rules:
 - host: my.domain.com
   http:
     paths:
     - path: /app-a/(.*)
       pathType: Prefix
       backend:
         service:
           name: my-app-a-service
           port:
             number: 8080  
     - path: /app-b/(.*)
       pathType: Prefix
       backend:
         service:
           name: my-app-b-service
           port:
             number: 8080

With the example configuration above we see that the following url’s are valid:

my.domain.com/app-a/ # will hit the root of my-app-a-service at "/"
my.domain.com/app-a/actuator/health # my-app-a-service at "/actuator/health"
my.domain.com/app-b/service # will route to my-app-b-service at "/service"

How does it work?
First we look at the paths: “/app-a/(.*)”. The “(.*)” part is a regular expression that means “match all characters after the slash (“/”) and put it into a group” .

A little higher up in the configuration we find “nginx.ingress.kubernetes.io/rewrite-target: /$1” annotation. This tells the Ingress that we should extract the first group (“$1”) and forward it to the backend Service. This is the way we remove the first part of the path (/app-a/). We only use this part to separate to what service the call should go and do not want it to follow the call to the backend. Everything after the last slash (“/”) is forwarded to the application, both url and any query parameters.

A nifty solution when you don’t need every service to be a separate domain

Tested on VMWare Tanzu Kubernetes v1.22

WireMock: Verify payload sent to a mocked service in JUnit 5

Posted by on May 13, 2024 No comments

This was not totally logical to me so I’ll write the solution down here for myself and anyone else that might have the same problem as me 🙂

The solution is to use the WireMock.verify function to setup a payload assertion.

Example (pseudo code):

import com.github.tomakehurst.wiremock.client.WireMock;
import com.niklasottosson.myApplication;
import org.junit.jupiter.api.Test;

import static com.github.tomakehurst.wiremock.client.WireMock.equalToXml;
import static com.github.tomakehurst.wiremock.client.WireMock.postRequestedFor;
import static com.github.tomakehurst.wiremock.client.WireMock.urlEqualTo;


public class MyApplicationIntegrationTest {

  @Test
  public void happyCaseTest() {

    String expected = "Hello Test";
    String myPath = "/mymockservice"

    // 1. Setup WireMock
    WireMock.stubFor(post(urlEqualTo(myPath))
       .willReturn(
             aResponse()
                   .withStatus(200)
                   .withHeader("Content-Type", "text/xml")
                   .withBody("Hello from mock service")));        

   // 2. Run system under test
   myApplication.start();        

   // 3. Verify payload sent to mock service
   WireMock.verify(
       postRequestedFor(urlEqualTo(myPath))
            .withRequestBody(equalToXml(expected))
    );
  }
}

1. Setup a WireMock stub for receiving calls from myApplication on a specific path
2. Start system under test, myApplication in this case
3. Verify that a call has been made to the path AND with a request payload matching our “expected” result. If this validates the payload is as “expected” 🙂

So in conclusion, WireMock is doing the assertion here, not our testing framework

Tested with WireMock v.3.1.0