Where do services live in Kubernetes?

Question

I am learning Kubernetes and currently deep diving into high availability and while I understand that I can set up a highly available control plane (API-server, controllers, scheduler) with local (or with remote) etcds as well as a highly available set of minions (through Kubernetes itself), I am still not sure where in this concept services are located.

If they live in the control plane: Good I can set them up to be highly available.

If they live on a certain node: Ok, but what happens if the node goes down or becomes unavailable in any other way?

As I understand it, services are needed to expose my pods to the internet as well as for loadbalancing. So no HA service, I risk that my application won't be reachable (even though it might be super highly available for any other aspect of the system).

Answer 1

Kubernetes Service is another REST Object in the k8s Cluster. There are following types are services. Each one of them serves a different purpose in the cluster.

• ClusterIP
• NodePort
• LoadBalancer
• Headless

fundamental Purpose of Services

• Providing a single point of gateway to the pods
• Load balancing the pods
• Inter Pods communication
• Provide Stability as pods can die and restart with different Ip
• more

These Objects are stored in etcd as it is the single source of truth in the cluster.

Kube-proxy is the responsible for creating these objects. It uses selectors and labels.

For instance, each pod object has labels therefore service object has selectors to match these labels. Furthermore, Each Pod has endpoints, so basically kube-proxy assign these endpoints (IP:Port) with service (IP:Port).Kube-proxy use IP-Tables rules to do this magic.

Kube-Proxy is deployed as DaemonSet in each cluster nodes so they are aware of each other by using etcd.

Answer 2

You can think of a service as an internal (and in some cases external) loadbalancer. The definition is stored in Kubernetes API server, yet the fact thayt it exists there means nothing if something does not implement it. Most common component that works with services is kube-proxy that implements services on nodes using iptables (meaning that every node has every service implemented in it's local iptables rules), but there are also ie. Ingress Controller implementations that use Service concept from API to find endpoints and direct traffic to them, effectively skipping iptables implementation. Finaly there are service mesh solutions like linkerd or istio that can leverage Service definitions on their own.

Services loadbalance between pods in most of implementations, meaning that as long as you have one backing pod alive (and with enough capacity) your "service" will respond (so you get HA as well, specially if you implement readiness/liveness probes that among other things will remove unhealthy pods from services)

Kubernetes Service documentation provides pretty good insight on that