James Ainslie

A Service name can resolve correctly while traffic to its address still fails. Kubernetes 1.11 brings two components involved in that path to general availability, IPVS-based Service load balancing and CoreDNS integration. The June 27 release announcement makes an important distinction between their defaults. CoreDNS becomes the kubeadm default, while IPVS remains an explicitly selected proxy mode.

I value the separation between the Kubernetes API and its implementations. A Service declaration can remain familiar while the cluster changes how it resolves the name or distributes connections. That flexibility is useful only if the operator understands which implementation is active. General availability describes support status, while the selected mode and installed configuration determine the packet's actual path.

This release also moves dynamic kubelet configuration and multiversion custom resource definitions to beta. Those changes expand how the control system can evolve, but the networking promotions deserve their own explanation. They affect two dependencies that an application encounters before it receives a useful response from another Service. The mechanics are visible in the source shipped with the release.

IPVS handles transport-layer load balancing

The IPVS documentation in the 1.11.0 source describes Linux kernel transport-layer load balancing for TCP and UDP services. A virtual service exposes an address and port, with real servers behind it. Kube-proxy's IPVS mode programs that implementation for Kubernetes Services. The application's Service address does not have to encode the selected backend.

The documentation traces IPVS mode to Kubernetes 1.8, followed by beta in 1.9. Its promotion in 1.11 therefore follows an existing implementation path. The announced advantages include scalability and a simpler programming interface than iptables. Those are reasons to make the alternative available, but they do not establish a universal throughput figure for every cluster. The release announcement supplies no workload-independent performance number to apply to an individual installation.

IPVS also supports several load-balancing algorithms. The source documentation names least connections and weighted approaches among its capabilities. This gives the implementation more scheduling choices than a basic distribution rule. Selecting the proxy mode still requires the necessary kernel facilities, so an API-level configuration choice is only one part of enabling the implementation on a node.

The contemporary prerequisite list includes ip_vs and scheduler modules such as ip_vs_rr, together with connection-tracking support. It also calls for the ipset package. Required modules may already be built into the kernel or loaded separately. The distinction matters because failure to find a module in a loaded-module listing does not by itself establish that the kernel lacks the functionality.

Kube-proxy can fall back to iptables when the IPVS requirements are unavailable. An operator who requested IPVS must therefore distinguish the requested mode from the mode which started successfully. The documentation provides an IPVS-specific diagnostic command.

ipvsadm -ln

Its output lists virtual addresses and their real-server destinations. That makes it relevant to verifying the forwarding state on the node. An empty or unexpected table is a different observation from a DNS lookup returning the wrong address. The two symptoms concern different stages of the connection path and need evidence from different components.

IPVS mode still uses iptables

The source documentation explicitly describes iptables use within the IPVS proxier. Packet filtering and source address translation still require rules. NodePort support also uses iptables. Consequently, finding Kubernetes-related iptables chains on a node does not prove that IPVS mode failed to start. Those chains can be part of the intended combined implementation.

For example, enabling masquerading for all Service traffic requires source address translation even though IPVS selects destinations. When a cluster CIDR is configured, the proxier can apply masquerading to traffic originating outside it. These are decisions about source addresses and reachability, separate from choosing which real server receives a connection.

LoadBalancer source ranges provide another example. The documented rules permit traffic from the specified range and drop other traffic to the load-balancer address. This is an access restriction associated with the Service. The virtual server's ability to distribute connections does not eliminate the need to apply that restriction elsewhere in the packet-processing path.

This combined behavior affects debugging. A connection problem may involve the virtual-server destinations, the translation rules or the filter applied to the address. Examining only the IPVS destination table would leave some of the implementation unexamined. Equally, interpreting every iptables rule as a remnant of the previous mode could lead an operator to remove rules the active proxier expects to maintain.

I consider the continued use of iptables a useful example of why implementation names need explanation. IPVS identifies the load-balancing mechanism selected by kube-proxy. It does not imply that all other Linux networking work has moved into that mechanism. The source documents the complementary operations, which gives an operator a more accurate basis for interpreting the node's state.

CoreDNS installation preserves a service endpoint

The kubeadm DNS add-on implementation in 1.11.0 shows how the DNS choice fits into cluster setup. Its add-on entry point selects CoreDNS when the relevant feature configuration enables it. The CoreDNS path assembles a Deployment and configuration, then uses the same DNS Service template used for the other DNS implementation.

The DNS Service address derives from the configured Service subnet. This is useful separation between the DNS server implementation and the endpoint through which workloads reach it. A change in the server deployment does not need to imply a different purpose for the cluster's DNS Service. The installer handles the Service as a distinct Kubernetes object with its own create-or-update behavior.

CoreDNS also needs permission to read cluster state. The installation code creates or updates its ClusterRole and ClusterRoleBinding along with a ServiceAccount. It then creates or updates the Deployment. The server is therefore part of the cluster's ordinary authorization model, with explicit resources representing the access required by its integration.

The code retains an existing CoreDNS ConfigMap instead of blindly replacing it during this operation. That distinction is meaningful for an installed DNS service whose configuration may already contain local decisions. Deployment reconciliation and configuration retention have different effects. The installer names those operations separately in the implementation, so its behavior cannot be summarized as simply replacing every object in the add-on.

DNS migration includes configuration translation

Kubeadm's CoreDNS path reads the existing kube-dns ConfigMap when it exists. It translates stub domains and upstream nameservers into CoreDNS configuration. A missing ConfigMap is acceptable, while other retrieval errors stop the operation. That gives a new installation a different input condition from a cluster which already carries customized DNS settings.

Stub-domain data is decoded as a map from domain names to lists of nameserver addresses. For each domain, the translator produces a server stanza with error handling, caching and a proxy directive. Upstream nameservers are decoded separately as a list. This is configuration conversion between representations, with explicit parsing errors when the stored data does not match the expected form.

The implementation also translates federation settings. These functions show why changing the installed DNS server involves more than selecting a container image. Existing forwarding decisions describe where particular questions should go. Losing those decisions during installation could leave ordinary cluster-name lookups working while resolution of a configured external domain changes.

The add-on detection function searches Deployments in the system namespace using the k8s-app=kube-dns label. It returns no deployed add-on when the list is empty and reports an error when several matching Deployments exist. For a single match, it extracts the add-on name and image version. A label associated with the DNS function therefore remains useful even while the implementation's own deployment name changes.

Service creation also accounts for an already allocated DNS address. The helper tolerates both an existing-object response and an invalid-create response before attempting an update. That behavior reflects the desired continuity of the DNS endpoint. Installation must deal with an address already represented in cluster state, as well as with the resources required to run the selected server behind it.

These two networking promotions therefore have different operational effects. IPVS adds a stable choice for how nodes distribute Service connections, with kernel prerequisites and complementary iptables rules. CoreDNS becomes kubeadm's DNS default, with installation code that constructs authorization resources and translates existing DNS settings. A Service lookup and the connection which follows it continue to depend on separately maintained cluster state.