CODEWITHSUNDEEP
kuberneteshigh-availability
stiller_leser
stiller_leser

Reputation: 1572

Where do services live in Kubernetes?

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).

Upvotes: 16

Views: 3491

Answers (3)

S.Nakib
S.Nakib

Reputation: 1021

The term Service may confuse us since it gives the impression that some processes are running as Services, listening to incoming traffic, and Proxying/Load Balancing to PODS. However, that's not true.

Kubernetes Services aren't Processes listening to incoming traffic like some servers or load-balancers.

So, how does this Service mechanism work?

Services are Kubernetes objects stored in the etcd after creation.

The Kub-Proxy in each node keeps track of when Services are Created, Updated, and Deleted and updates the Node's iptable rules so the kernel will redirect the Service IP to the correct POD IP for any request to the Service.

So you don't need to worry about the Availability of the Services if some node goes down.

Upvotes: 0

Suresh Vishnoi
Suresh Vishnoi

Reputation: 18373

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.

Upvotes: 15

Radek 'Goblin' Pieczonka
Radek 'Goblin' Pieczonka

Reputation: 22884

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

Upvotes: 12

Related Questions