feat: handle kubelet TCP/HTTP probes

.github/workflows/ci.yml

@@ -4,7 +4,7 @@ on: [push]
 
 jobs:
   staticcheck:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-24.04
     steps:
       - uses: actions/checkout@v4
 
@@ -19,7 +19,10 @@ jobs:
           version: "2024.1"
 
   test:
-    runs-on: ubuntu-latest
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-24.04, ubuntu-24.04-arm]
     steps:
       - uses: actions/checkout@v4
 
@@ -66,7 +69,10 @@ jobs:
         run: git diff --exit-code
 
   e2e:
-    runs-on: ubuntu-latest
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-24.04, ubuntu-24.04-arm]
     steps:
       - uses: actions/checkout@v4
 

Makefile

@@ -60,13 +60,13 @@ push-dev: build-installer build-manager
 	docker push $(MANAGER_IMAGE)
 
 test-e2e:
-	go test -v ./e2e/
+	go test -timeout=30m -v ./e2e/ $(testargs)
 
 bench:
 	go test -bench=. -benchtime=10x -v -run=Bench ./e2e/
 
 test:
-	go test -v -short ./...
+	go test -v -short ./... $(testargs)
 
 # docker-e2e runs the e2e test in a docker container. However, as running the
 # e2e test requires a docker socket (for kind), this mounts the docker socket
@@ -81,7 +81,7 @@ docker-bench: build-test
 # has to have SYS_ADMIN because the test tries to set netns and mount bpffs
 # we use --pid=host to make the ebpf tracker work without a pid resolver
 docker-test:
-	docker run --rm --cap-add=SYS_ADMIN --cap-add=NET_ADMIN --pid=host --userns=host -v $(PWD):/app $(TEST_IMAGE) make test
+	docker run --rm --cap-add=SYS_ADMIN --cap-add=NET_ADMIN --pid=host --userns=host -v $(PWD):/app $(TEST_IMAGE) go test -v -short ./... $(testargs)
 
 CLANG ?= clang
 CFLAGS := -O2 -g -Wall -Werror
@@ -91,9 +91,11 @@ CFLAGS := -O2 -g -Wall -Werror
 # dependencies installed.
 generate: export BPF_CLANG := $(CLANG)
 generate: export BPF_CFLAGS := $(CFLAGS)
-generate: ttrpc
+generate: ttrpc ebpf
 	go generate ./api/...
-	docker run --rm -v $(PWD):/app:Z --user $(shell id -u):$(shell id -g) --env=BPF_CLANG="$(CLANG)" --env=BPF_CFLAGS="$(CFLAGS)" $(EBPF_IMAGE)
+
+ebpf:
+	docker run --rm -v $(PWD):/app:Z --user $(shell id -u):$(shell id -g) --userns=host --env=BPF_CLANG="$(CLANG)" --env=BPF_CFLAGS="$(CFLAGS)" $(EBPF_IMAGE)
 
 ttrpc:
 	go mod download

README.md

@@ -204,8 +204,7 @@ kubectl delete -k https://github.com/ctrox/zeropod/config/production
 ## Configuration
 
 A pod can make use of zeropod only if the `runtimeClassName` is set to
-`zeropod`. Apart from that there are two annotations that are currently
-required. See this minimal example of a pod:
+`zeropod`. See this minimal example of a pod:
 
 ```yaml
 apiVersion: v1
@@ -223,8 +222,41 @@ spec:
         - containerPort: 80
 ```
 
-Then there are also a few optional annotations that can be set on the pod to
-tweak the behaviour of zeropod.
+### Probes
+
+Zeropod is able to intercept liveness probes while the container process is
+scaled down to ensure the application is not restored for probes. This just
+works for HTTP and TCP probes, GRPC and exec probes will wake the container up.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  annotations:
+    zeropod.ctrox.dev/scaledown-duration: 10s
+spec:
+  runtimeClassName: zeropod
+  containers:
+    - name: nginx
+      image: nginx
+      ports:
+        - containerPort: 80
+      livenessProbe:
+        httpGet:
+          port: 80
+```
+
+In this example, the container will be scaled down 10 seconds after starting
+even though we have defined a probe. Zeropod will take care of replying to the
+probe when the container is scaled down. Whenever the container is running, the
+probe traffic will be forwarded to the app just like normal traffic. You can
+also customize the path and the headers of the probe, just be mindful of the
+size of those. To reduce memory usage, by default, zeropod will only read the
+first `1024` bytes of each request to detect an HTTP probe. If the probe is
+larger than that, traffic will just be passed through and the app will be
+restored on each probe request. In that case, it can be increased with the
+[probe buffer size](#zeropodctroxdevprobe-buffer-size) annotation.
 
 ### `zeropod.ctrox.dev/container-names`
 
@@ -281,6 +313,20 @@ the application is stateless and super fast to startup.
 zeropod.ctrox.dev/disable-checkpointing: "true"
 ```
 
+### `zeropod.ctrox.dev/disable-probe-detection`
+
+Disables the probe detection mechanism. If there are probes defined on a
+container, they will be forwarded to the container just like any traffic and
+will wake it up.
+
+### `zeropod.ctrox.dev/probe-buffer-size`
+
+Configure the buffer size of the probe detector. To be able to detect an HTTP
+liveness/readiness probe, zeropod needs to read a certain amount of bytes from
+the TCP stream of incoming connections. This normally does not need to be
+adjusted as the default should fit most probes and only needs to be increased in
+case the probe contains lots of header data. Defaults to `1024` if unset.
+
 ## Experimental features
 
 ### `zeropod.ctrox.dev/migrate`