Kubernetes Concepts

From NovaOrdis Knowledge Base
Revision as of 22:11, 10 August 2019 by Ovidiu (talk | contribs) (→‎Overview)
Jump to navigation Jump to search

External

Internal

TODO

Deplete Kubernetes Concepts TO DEPLETE.

Overview

Kubernetes is a container orchestrator. To understand how it works is to understand a set of high level concepts, briefly mentioned here. More details on individual concepts are available on their respective pages. All interactions with a Kubernetes cluster are performed by sending REST requests into an API server. The API server is responsible with managing and exposing the state of the cluster. The cluster consists in a set of nodes. Nodes are used to run Pods - Pods are scheduled to nodes and monitored closely by the cluster. A Pod is the atomic unit of deployment in Kubernetes, and contains one or more containers. Pods come and go - if one Pod dies, it is not resurrected, but another Pod might be scheduled as replacement. In consequence, the IP address of an individual Pod cannot be relied on. To provide a stable access point to a set of equivalent Pods - which is how applications are deployed on Kubernetes, Kubernetes uses the concept of Service, which can be thought of as stable networking for a continuously changing set of Pods. A Service's IP address and port can be relied on to be stable for the life of the Service. All live Pods represented by a Service at a moment in time are known as the Service's endpoint. There are several types of Services: ClusterIP, NodePort and LoadBalancer. The association between Services and Pods they expose is loose, established logically by the Service's Selector, which is a label-based mechanism: a Pod "belongs" to a Service if the Service's Selector matches the Pod's Labels. A Pod by itself has no built-in resilience: if it fails for any reason, it is gone. A higher level concept - the Deployment - is used to manage a set of Pods from a high availability perspective: the Deployment insures that a specific number of equivalent Pods is always running, and if one of more Pods fail, the Deployment brings up replacement Pods. The deployment relies on an intermediary concept - the Replica Set. Deployments are used to implement rolling updates and rollbacks.