Services

Lace replaces kube-proxy and implements the Kubernetes Service spec, in every network, with the exceptions listed under unsupported features. What follows is what is worth knowing about each service type under network isolation, not a restatement of the spec.

Network context

A service is bound to a network by a NetworkBindingPolicy, the same way pods are. That network is the context used to route from the service VIP to its endpoints, so a service should be bound to the same network as the pods it targets.

Reaching a service from another network is a topology concern: a VIP is reachable across networks only through a peering. See Service peering.

Opting out

Two labels take a service out of Lace’s hands, on the service itself or on one of its EndpointSlices: service.kubernetes.io/headless, which DNS resolves and nothing proxies, and service.kubernetes.io/service-proxy-name, which hands it to another proxy. Labelling one Lace already programs withdraws it, so a cluster running a second proxy can partition services between them at any time.

ClusterIP

The service is reachable through its VIP from within its own network, and from peered networks per the topology rules.

NodePort

In addition to the ClusterIP, the service is reachable on a port of the nodes’ internal addresses. Every node answers on its own addresses, regardless of where the backing pods run. A node answers only for itself: traffic addressed to another node’s address is routed to that node and resolved there, so externalTrafficPolicy: Local is decided by the node that was dialled rather than by whichever node the packet passed through.

Which source networks may reach a NodePort is governed by external networks: the node addresses classify into an external network, and a routing policy from that network grants access. Reaching a different node’s address additionally needs ordinary routing to that external network, since the service is no longer resolved locally.

LoadBalancer

The service is assigned an external VIP from a LoadBalancerClass pool and that VIP is attracted to a node that advertises it on L2. See LoadBalancer for the full model.

Load balancing

Traffic to a VIP is distributed by uniform random selection across the eligible ready endpoints. Which endpoints are eligible is decided by the service’s traffic policy and distribution; selection within that set is always random.

Traffic policy and distribution

Traffic policy and topology-aware routing behave as the spec defines. Worth noting: trafficDistribution falls through to the next locality tier — node, zone, then the rest of the cluster — when the closer one has none.

When no eligible endpoint is ready, the service drains to the endpoints that are still serving while terminating rather than dropping the flow, so a backend keeps receiving traffic through its grace period. Cluster drains to any of them, ignoring locality; Local drains only to node-local ones and drops when the node has none.

A LoadBalancer using externalTrafficPolicy: Local is allocated a health check port, which an external load balancer probes over HTTP to learn whether a node has backends of its own: 200 when it does, 503 when it does not, with the count in an X-Load-Balancing-Endpoint-Weight header and in the body. The port is answered by the node agent, so it stops answering while the agent restarts.

It answers on every address of the node, and about the family the probe arrived on: a node with local backends in one family only reports up on that family’s addresses, and refuses the other’s altogether, which is what Local will actually do with the traffic.

Beyond the spec, the lace-cni.io/traffic-distribution: PreferClosest annotation prefers the closest endpoints available: node-local first, then same zone, then anywhere in the cluster.

Dual-stack

A service gets a VIP per address family it is configured for. Which families that is follows the apiserver’s service IP-family configuration; for a LoadBalancer it is further constrained by the families the selected class pool provides.