kubepath
1 DNS → node IP The A record 2 DNAT → :8000/:8443 The node’s :80 and :443 3 ACME ← back through :80 TLS, by HTTP-01 only 4 router → service Matching the request 5 EndpointSlice → pod IP Service, and what it actually does here 6 runsc The pod, inside gVisor 7 CNPG · ClickHouse The data path, shared
The request path hop 1 of 10 traces to the constraint

The A record

Where a normal cluster puts a load balancer’s address, this one puts the worker node’s.

On Scaleway Kapsule, a Service of type: LoadBalancer is not a routing instruction — it is a purchase order. The cloud controller manager sees it, provisions a Scaleway Load Balancer, gives it a public IP, and starts billing for it. Declining that purchase is the one constraint this cluster is built around, and every strange thing further down the path is downstream of it.

So DNS points at the node. The zone holds an A record for each hostname the cluster serves, and every one of them resolves to the public IP of the single worker node. There is no address in front of the cluster that belongs to the cluster rather than to a machine.

That has three consequences worth saying out loud before anyone reads a manifest. First, the node’s IP is now a published fact, cached in resolvers you do not control — so replacing the node is a DNS change plus a propagation wait, not a rolling operation. Second, there is no health-checking layer in front of the node: if the node is up but Traefik is not, DNS keeps sending traffic at it and the failure is a connection refused rather than a failover. Third, with one worker node there is no second address to fail over to, so the honest description is that availability is bounded by one machine and the design does not pretend otherwise.

This is a reasonable trade for a platform of this size. It is only dangerous when it is undocumented, because the first person to scale the node pool will expect a second node to add capacity at the edge, and it will not — it will add a second node that no DNS record points at.

the zone, and what it points at
; the cluster front door is a machine, not a load balancer
example.com.        300  IN  A   51.15.xx.xx
*.example.com.      300  IN  A   51.15.xx.xx

$ kubectl get nodes -o wide
NAME              STATUS  ROLES   EXTERNAL-IP    OS-IMAGE
scw-pl-waw-pool-1 Ready   <none>  51.15.xx.xx    Ubuntu 22.04

$ kubectl get svc -A --field-selector spec.type=LoadBalancer
No resources found          # on purpose. this is the whole point.

Check yourself

2 questions. One attempt each is recorded; the explanation is the point, not the score.

On Kapsule, what does creating a Service of type: LoadBalancer actually do?

Why is replacing the worker node a DNS operation rather than a rolling one?

The node’s :80 and :443 →