Kubernetes Concepts

External

• https://kubernetes.io/docs/concepts/

Internal

• Kubernetes
• Docker Concepts
• OpenShift Concepts

TODO

Deplete Kubernetes Concepts TO DEPLETE.

Overview

Kubernetes is an Apache 2.0 Open Source container orchestration platform, or a container orchestrator. To understand how Kubernetes works is to understand a set of high level concepts, briefly mentioned here. More details on individual concepts are available on their respective pages.

A high level abstraction often used for Kubernetes is "data center OS". The primary target of Kubernetes are containerized cloud-native applications, which are applications that are made from a set of small autonomous services (microservices) that communicate with each other. Kubernetes help deploying, scaling up, scaling down, performing updates and rollbacks of these services, handled as containers. In the process, it abstracts out details such as what specific compute nodes or physical storage volumes are allocated to applications.

Kubernetes instances are known as clusters. 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 state of the cluster is internally stored by a Cluster Store component, which is currently etcd. The control loops essential to the declarative model implemented by Kubernetes are driven by the controller manager. The workloads are dispatched by the scheduler. All these components (API Server, cluster store, controllers, scheduler, cloud controller manager) are collectively known as the control plane. Externally, the state can be accessed and modified most commonly via a command line client named kubectl. The cluster consists in a set of nodes. There are master nodes and worker nodes. Each node runs a container runtime, usually Docker. However, support for other container runtimes is available, via Container Runtime Interface (CRI).

Worker nodes are used to run workloads, as Pods - pods are scheduled to nodes and closely monitored. A pod is a wrapper that allows containers to run on Kubernetes and it is the atomic unit of deployment in Kubernetes. A pod may include one one or more containers. Pods come and go - if a 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 layer 5 alternative to service, named Ingress is available.

A pod by itself has no built-in resilience: if it fails for any reason, it is gone. A higher level primitive - 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 ReplicaSet. Deployments are used to implement rolling updates and rollbacks. There are higher-level pod controllers that manage sets of pods in different ways: DaemonSets and StatefulSets. Individual pods can be managed as Jobs or CronJobs.

Networking. kube-proxy. Pod network. The DNS Service. All in Networking Concepts.

Storage. Storage Concepts

Security. Security Concepts

Cluster Configuration.

Subjects

• Control Plane and Data Plane Concepts
• API Resources Concepts
• Container Runtime Concepts
• Pod and Container Concepts
• Service Concepts
• Ingress Concepts
• Higher Level Pod Controllers
• Networking Concepts
• Kubernetes Manifests
• Storage Concepts
• Managed Kubernetes
• Cluster Configuration Concepts
• Security Concepts
• Namespace Concepts

Declarative versus Imperative Approach

The preferred style while operating Kubernetes is to use a declarative model: Kubernetes likes to manage application declaratively, where we describe how we want our application to look in a set of YAML files, named manifests, POST these files into the Kubernetes API Server and wait for the changes to be applied. The controller manager insures that the current state matches the desired state. Step-by-step, the declarative model works as follows:

1. The desired state of the application is declared in the manifest file.
2. The manifest file is POSTed into the API Server, usually with kubectl command.
3. The API server authenticates and authorizes the request and then validates the manifest.
4. The API server stores the state - as desired state - in the cluster store.
5. The API server identifies the controller responsible with enforcing and monitoring the state.
6. The controller in charge implements the desired state, by adjusting the current state to match it.
7. The controller manager's control loops monitor the current state and make sure that it does not diverge from the desired state.
8. If the current state of the cluster diverges from the desired state, the cluster control plane will perform whatever tasks are necessary to bring those states in sync.

This model is the opposite of the traditional imperative model, where a precise sequence of specific commands are issued to explicitly adjust the state. In other words, in the declarative model we tell the cluster how things should look, as opposite to telling it how to adjust the state.

The declarative model is essential to how Kubernetes operates.