Services

Lace replaces kube-proxy and implements Kubernetes services for every network. All service types are supported: ClusterIP, NodePort, and LoadBalancer.

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.

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. These addresses are taken from each node and propagated cluster-wide through that node’s UnderlayEndpoint, so the port answers on every node regardless of where the backing pods run.

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.

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

Topology-aware routing is fully supported. internalTrafficPolicy and externalTrafficPolicy are honored: Local restricts a flow to endpoints on the same node (and drops it when there are none), per their respective traffic origin. trafficDistribution selects a preference order over endpoint locality — node, zone, then the rest of the cluster — falling through to the next tier when the closer one has no ready endpoints.

In addition, 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.