Microservices on Kubernetes

Traditional Microservices

The typical trait of a traditional microservice stack is that it needs a service registry.

Each service registers its own address information on startup, and updates that address information when the service moves.

If a service goes down, it is usually restarted by a resident supervisor such as Supervisor, Systemd, or PM2.

A set of machines formally grouped into a cluster, but without the cluster's management and scheduling capability.

Microservices on Kubernetes

• Service discovery

A Kubernetes cluster actively registers services through Service and Endpoint, and maintains the list of available addresses.

On Kubernetes, a Service is an abstract concept: it can represent a single service, or a group of services.

A Service uses a Label Selector to pick a set of Pods — usually multiple instances of the same service — and uses a Cluster IP to represent that set. The Cluster IP is a virtual IP address, different from a Pod's IP address, and it does not change as Pods come and go.

• Load balancing

When a Service receives a request, it forwards the request to one of the Pods through its built-in load balancer.

The default load balancing strategy is round robin, and it can be changed to random through configuration. The way to change it is to add sessionAffinity: ClientIP to the Service configuration.