Kubernetes Core Concept 1 - Clusters and Workloads Infrastructure Components

kube-apiserver

The API server is how the underlying Kubernetes APIs are exposed. This component provides the interaction for management tools, such as kubectl or the Kubernetes dashboard.

kube-controller-manager

The Controller Manager oversees a number of smaller Controllers that perform actions such as replicating pods and handling node operations.

Kubernetes cluster architecture

A Kubernetes cluster is divided into two components: Control Plan and Nodes

Deployments

A deployment represents one or more identical pods, managed by the Kubernetes Deployment Controller. A deployment defines the number of replicas (pods) to create, and the Kubernetes Scheduler ensures that if pods or nodes encounter problems, additional pods are scheduled on healthy nodes.

Nodes

A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node contains the services necessary to run pods and is managed by the master components. The services on a node include the container runtime, kubelet and kube-proxy.

Helm

A package manager used with K8s. You can build and use existing public Helm charts that contain a packaged version of application code and Kubernetes YAML manifests to deploy resources. These Helm charts can be stored locally, or often in a remote repository, such as an Azure Container Registry Helm chart repo.

DaemonSets

Ensure a running instance on each node, early in the Kubernetes bootstrap process. DaemonSet is again used to deploy one or more identical pods, but the DaemonSet Controller ensures that each node specified runs an instance of the pod. For specific log collection or monitoring needs, you may need to run a given pod on all, or selected, nodes. The DaemonSet Controller can schedule pods on nodes early in the cluster boot process, before the default Kubernetes scheduler has started. This ability ensures that the pods in a DaemonSet are started before traditional pods in a Deployment or StatefulSet are scheduled.

Node selectors

In an AKS cluster that contains multiple node pools, you may need to tell the Kubernetes Scheduler which node pool to use for a given resource. For example, ingress controllers shouldn't run on Windows Server nodes (currently in preview in AKS). Node selectors let you define various parameters, such as the node OS, to control where a pod should be scheduled.

namespace

Kubernetes resources, such as pods and Deployments, are logically grouped. These groupings provide a way to logically divide an AKS cluster and restrict access to create, view, or manage resources. You can create namespaces to separate business groups, for example. Users can only interact with resources within their assigned namespaces.

Pods

Kubernetes uses pods to run an instance of your application. A pod represents a single instance of your application. Pods typically have a 1:1 mapping with a container, although there are advanced scenarios where a pod may contain multiple containers. These multi-container pods are scheduled together on the same node, and allow containers to share related resources. A pod is a logical resource, but the container(s) are where the application workloads run. Pods are typically ephemeral, disposable resources, and individually scheduled pods miss some of the high availability and redundancy features Kubernetes provides. Instead, pods are usually deployed and managed by Kubernetes Controllers, such as the Deployment Controller.

StatefulSets

Maintain the state of applications beyond an individual pod lifecycle, such as storage. StatefulSets can be used for stateful applications, such as applications that include database components. A StatefulSet is similar to a deployment in that one or more identical pods are created and managed. Replicas in a StatefulSet follow a graceful, sequential approach to deployment, scale, upgrades, and terminations. With a StatefulSet (as replicas are rescheduled) the naming convention, network names, and storage persist. With StatefulSets, the underlying persistent storage remains even when the StatefulSet is deleted.

container runtime

Node component that allows containerized applications to run and interact with additional resources such as the virtual network and storage. In AKS, Moby is used as the container runtime.

Node pools

Nodes of the same configuration are grouped together into node pools. A Kubernetes cluster contains one or more node pools. The initial number of nodes and size are defined when you create an AKS cluster, which creates a default node pool. This default node pool in AKS contains the underlying VMs that run your agent nodes. To ensure your cluster operates reliably, you should run at least 2 (two) nodes in the default node pool.

Control plane

The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. This layer is composed by many different components, such as (but not restricted to): etcd API Server Scheduler Controller Manager Cloud Controller Manager These components can be run as traditional operating system services (daemons) or as containers. The hosts running these components were historically called masters.

namespaces kube-public

This namespace is typically not used, but can be used for resources to be visible across the whole cluster, and can be viewed by any user.

namespaces kube-system

This namespace is where core resources exist, such as network features like DNS and proxy, or the Kubernetes dashboard. You typically don't deploy your own applications into this namespace.

namespaces default

This namespace is where pods and deployments are created by default when none is provided. In smaller environments, you can deploy applications directly into the default namespace without creating additional logical separations. When you interact with the Kubernetes API, such as with kubectl get pods, the default namespace is used when none is specified.

etcd

To maintain the state of your Kubernetes cluster and configuration, the highly available etcd is a key value database within Kubernetes. Kubernetes uses etcd as a key-value database store. It stores the configuration of the Kubernetes cluster in etcd. It also stores the actual state of the system and the desired state of the system in etcd. It then uses etcd's watch functionality to monitor changes to either of these two things. If they diverge, Kubernetes makes changes to reconcile the actual state and the desired state.

kube-scheduler

When you create or scale applications, the Scheduler determines what nodes can run the workload and starts them.

Pod Disruption Budgets

can be used to define how many replicas in a deployment can be taken down during an update or node upgrade. For example, if you have 5 replicas in your deployment, you can define a pod disruption of 4 to only permit one replica from being deleted/rescheduled at a time. As with pod resource limits, a best practice is to define pod disruption budgets on applications that require a minimum number of replicas to always be present.

kubectl create or kubectl apply

deployment command. To create a deployment, you define a manifest file in the YAML.

Deployment Controller

drains and terminates a given number of replicas, creates replicas from the new deployment definition, and continues the process until all replicas in the deployment are updated.