Pod probes

The kubelet runs liveness, readiness, and startup probes by connecting to a pod’s own address — but pods live in isolated overlay networks the host is not part of, and the same address may exist in several networks at once. Lace lets the kubelet probe a pod in any network, while every other connection the host makes stays on the host’s own network, untouched.

Reaching a probe endpoint

When a pod is attached, the node registers its probe ports — the ports named by the pod’s liveness, readiness, and startup probes — as probe targets, each recording which network the pod belongs to.

A cgroup eBPF program attached to the kubelet’s cgroup watches the connections the kubelet opens. A connection whose destination matches a registered probe target is tagged with that target’s network; every other connection is left alone and proceeds normally.

The tagged connection is delivered into that overlay network to the pod, over the same host-origin path used for other host-to-pod traffic (see Data plane). Two things make this work across isolated networks:

• The target carries the pod’s network, so the same address in two different networks stays unambiguous — the kubelet does not have to know which network it is reaching.
• Policy enforcement is skipped for probe flows: the kubelet is trusted node infrastructure, not a network peer, so a probe is never subject to a network’s reachability rules.

Isolation

Only the kubelet’s connections to registered pod probe endpoints are redirected into an overlay. The host is never attached to any network. All other traffic the host originates — and any process outside the kubelet’s cgroup — stays on the host network and is unaffected, so reaching into every network for probes does not open the host to those networks in either direction.

Configuring the kubelet cgroup

The cgroup program has to attach to the cgroup that actually contains the kubelet process. This is set with the Helm value node.kubeletCgroupPath, defaulting to /sys/fs/cgroup/system.slice/kubelet.service.

Change it when the kubelet runs under a different cgroup — a different init system, distribution, or a managed Kubernetes distribution that packages the kubelet elsewhere. If the configured path does not match the kubelet’s real cgroup, the hook attaches to the wrong cgroup and probes never reach their pods.