Kube-proxy implements a form of virtual IP for services for all types except ExternalName. Three modes are:
(a) Proxy-mode: userspace
- kube-proxy monitors the Kubernetes master, observe services and endpoints objects that get added or deleted.
- The mode opens a random port on the local node for each service.
- Every connections to the “proxy port” are proxied to a backend pods of the service and reported in the endpoints.
(b) Proxy-mode: iptables
- kube-proxy continuously observes the Kubernetes master for added or removed services and endpoint objects.
- This mode installs iptables rules to capture traffic to the clusterIP (virtual) and port of the every service, and then redirects the traffic to a service backend set.
- By defaultly, the mode installs iptables rules to select a random backend pod for all endpoints object.
(c) Proxy-mode: ipvs
- To create appropriate ipvs rules, kube-proxy observes the services and endpoints and calls netlink interface.
- The mode periodically syncs ipvs rules with services and endpoints, to make sure that the ipvs status is consistent with its expectations,
- Traffic gets redirected to a backend pod, when a service is accessed.
Headless services
Services that doesn’t want load-balancing and only a single serviceIP can create a ‘headless’ service by specifying “none” for the clusterIP (.spec.clusterIP). The two ways are:
1. Headless service with selectors
The headless service which defines with selectors, the case endpoints controller creates endpoint records in the API. These records will modify the DNS configuration to return A records (addresses) that point to the pods that expose the service.
2. Headless service without selectors
The Headless services which defines without selectors, so the endpoints controller wont create endpoint records. The DNS system configures any of the below:
- For ExternalName service type, CNAME records
- For the rest service types, a record for any endpoints that share names with the service
