The services model in Kubernetes provides the most basic, but most important, aspect of microservices: discovery. Understanding service discovery is key to understanding how an application runs on Kubernetes.

The previous article in this series covered the basics of nodes and pods. As a reminder, a node is the workhorse of the Kubernetes cluster, responsible for running containerized workloads; additional components of logging, monitoring and service discovery; and optional add-ons. While pods are the smallest and simplest unit in the Kubernetes object model and the smallest schedulable item in a Kubernetes application.

Any API object in Kubernetes, including a node or a pod, may have key-value pairs associated with it — additional metadata for identifying and grouping objects sharing a common attribute or property. Kubernetes refers to these key-value pairs as labels and annotations. Service discovery takes advantage of the labels and selectors to associate a service with a set of pods.

Sponsor Note

KubeCon + CloudNativeCon conferences gather adopters and technologists to further the education and advancement of cloud native computing. The vendor-neutral events feature domain experts and key maintainers behind popular projects like Kubernetes, Prometheus, Envoy, CoreDNS, containerd and more.

A single pod or a ReplicaSet may be exposed to internal or external clients via services, which associate a set of pods with a specific criterion. Any pod whose labels match the selector defined in the service manifest will automatically be discovered by the service. This architecture provides a flexible, loosely-coupled mechanism for service discovery.

When a pod is created, it is assigned an IP address accessible only within the cluster. But there is no guarantee that the pod’s IP address will remain the same throughout its life cycle. Kubernetes may relocate or re-instantiate pods at runtime, resulting in a new IP address for the pod.

#ebook series article #kubernetes #microservices #feature