Illustrated

Kubernetes

Glossary

Introduction

Our illustrated glossary covers a range of terms commonly used in the Kubernetes world. This page acts as a reference point to refer back to if you ever get muddled with definitions whilst learning more about Kube! The terms and definitions were sourced from the official Kubernetes documentation.

We're releasing all of the images under CC BY 4.0 and we welcome you to reuse them in future projects. If you want to quickly find a particular image, we've also put together an index with thumbnails and all of the vector files.

Foundational Concepts

These are concepts that are not necessarily specific to Kubernetes. However, Kubernetes makes use of these concepts in its implementation. It is a good idea to have a basic understanding of these concepts to help with understanding how Kubernetes works.

<- Swipe for image / definition ->

Applications

Applications

Cgroup (Control Group)

Cgroup (Control Group)

Cloud Provider

Cloud Provider

Cronjob

Cronjob

Job

Job

Logging

Logging

Containers

Containers are a key concept in Kubernetes, and in this section we define the different types of containers as well as concepts relating to containers. For example, images are a core component used to build up containers.

<- Swipe for image / definition ->

Container

Container

Ephemeral Container

Ephemeral Container

Init Container

Init Container

Image

Image

Container Runtimes

These are software components which can run containers on a host operating system. They are also referred to as container engines. The most commonly used container runtimes are defined in this section.

<- Swipe for image / definition ->

Container Runtime

Container Runtime

Containerd

Containerd

Cri-O

Cri-O

Docker

Docker

Volumes

Volumes store data within them and are accessed by containers. In this section we list definitions relating to persistent volumes, which are particularly relevant in the Kubernetes world.

<- Swipe for image / definition ->

Dynamic Volume Provisioning

Dynamic Volume Provisioning

Persistent Volume

Persistent Volume

Persistent Volume Claim

Persistent Volume Claim

Storage Class

Storage Class

Volume

Volume

Kubernetes Objects

In a Kubernetes system, the desired state of a cluster is represented by persistent entities known as Kubernetes objects. There are different types of objects that each have their own role to play. For example, you have Pod objects representing a set of running processes in a cluster, a Service object for enabling traffic exposure, load balancing and service discovery for Pods and a ServiceAccount object providing an identity to a process for authentication purposes.

Object Types

There are a number of different types of Kubernetes objects which each play a different role in helping to represent the state of the cluster.

<- Swipe for image / definition ->

ConfigMap

ConfigMap

CustomResourceDefinition

CustomResourceDefinition

DaemonSet

DaemonSet

Deployment

Deployment

Endpoints

Endpoints

Helm Chart

Helm Chart

Ingress

Ingress

Manifest

Manifest

Mirror Pod

Mirror Pod

Pod

Pod

Pod Security Policy

Pod Security Policy

ReplicaSet

ReplicaSet

Secret

Secret

Service

Service

Service Account

Service Account

StatefulSet

StatefulSet

Static Pod

Static Pod

Object Metadata

Every Kubernetes object also has metadata that can be defined by developers. There are two types of metadata:

Labels: Other objects check these labels to determine if the object with the label matches a criteria being looked for. For example, a Service uses a Selector to find Pods with a specific label.

Annotations: Other relevant information that is not related to identifying and selecting objects, for example Kubernetes auto-scaling systems can look at a Pod’s annotations to determine if another replica of the Pod should be created or a service like Istio can check a Pod’s annotations to determine if it should add a sidecar container to it.

<- Swipe for image / definition ->

Annotation

Annotation

Label

Label

Name

Name

Namespace

Namespace

Selector

Selector

UID

UID

Object Specs

Every Kubernetes object has characteristics that can be defined by a developer, these characteristics are known as the object’s spec. For example, you can define Container Environment Variables for containers inside of a Pod and/or define the Volumes the containers should have.

<- Swipe for image / definition ->

Container Environment Variables

Container Environment Variables

Container Lifecycle Hooks

Container Lifecycle Hooks

LimitRange: An illustration showing a glass of liquid labelled 'Memory' connected by a pipe to a container. There is a vice clamping down on the pipe and reducing the flow through to the container.

LimitRange

LimitRange: Provides constraints to limit resource consumption per Containers and Pods in a namespace.

LimitRange

Pod Disruption Budget: An illustration showing a block labelled 'App' with 3 Pods. There is a screen next to it which reads 'Minimum pods needed: 3'

Pod Disruption Budget

Pod Disruption Budget: A Pod Disruption Budget allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget.

Pod Disruption Budget

Pod Lifecycle: An illustration showing a horizontal arrow with dashed lines splitting it into phases. A pod is shown at the point of the second dashed line.

Pod Lifecycle

Pod Lifecyle: A high level summary of what phase the Pod is in within its lifecyle.

Pod Lifecycle

Preemption: An illustration showing a Node with two Pods on it, and a robot arm wishing to add a further Pod. One of the Pods is being 'evicted' from the Node via a slide.

Preemption

Preemption: Pre-emption logic in Kubernetes helps a pending Pod to find a suitable Node by evicting low priority Pods existing on that Node.

Preemption

Pod Priority: An illustration showing 3 Pods, respectively with a gold, silver and bronze rosette labelled 1, 2 and 3.

Pod-Priority

Pod Priority: Pod Priority indicates the importance of a Pod relative to other Pods.

Pod-Priority

QoS Class: An illustration showing a Pod, with a magnifying glass examining the container inside it.

QOS Class

QoS Class: QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.

QOS Class

Resource Quotas: An illustration showing a box with some dials on it, and a series of Nodes stacked on top.

Resource Quotas

Resource Quotas: Provides constraints that limit aggregate resource consumption per Namespace.

Resource Quotas

Security Context: An illustration showing a Pod wearing a security lanyard marked 'VIP'.

Security Context

Secuity Context: The securityContext field defines privelege and access control settings for a Pod or container.

Security Context

Taint: An illustration showing a Pod marked with three different coloured shapes. Next to the Pod is an anthropomorphic figure holding a sheet of paper with these different shapes on. Two of the shapes are marked by a tick, but one is marked by a cross. The anthropomorphic figure has an angry face.

Taint

Taint: A core object consisting of three required properties: key, value and effect. Taints prevent the scheduling of pods on nodes or node groups.

Taint

Toleration: An illustration showing a Pod marked with three different coloured shapes. Next to the Pod is an anthropomorphic figure holding a sheet of paper with these different shapes on. All three shapes are marked by a tick, and the anthropomorphic figure is smiling and giving a 'thumbs up'.

Toleration

Toleration: A core object consisting of three required properties: key, value and effect. Tolerations enable the scheduling of pods on nodes or node groups that have matching taints.

Toleration

Kubernetes Architecture

Kubernetes is a client-server architecture, the low-level technical concepts that implement the architecture can be split up into Kubernetes’s Master Components and Kubernetes Node Components. The concepts in this section are the high-level technical concepts.

<- Swipe for image / definition ->

Aggregation Layer: An illustration showing a Master Node with a box on its head. The box has various screens and dials, and is connected by wire to the kube-apiserver.

Aggregation Layer

Aggregation Layer: The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.

Aggregation Layer

API Group: An illustration showing a box with various dials and displays, and the kube-apiserver attached by wire. The box has a readout which states 'API Group 1: Object 1, Object 2, Object 3'

API Group

API Group: A set of related paths in Kubernetes API

API Group

Cluster: An illustration showing three anthropomorphic figures (nodes). One of these nodes has a white hat labelled 'M'.

Cluster

Cluster: A set of machines, called nodes, that run containerised applications managed by Kubernetes. A cluster has at least one master node and one worker node.

Cluster

Container Network Interface (CNI): An illustration showing two pods, where the containers in each Pod are communicating with each other, represented by tin cans and string.

Container Network Interface (CNI)

Container Network Interface (CNI): Container network interface plugins are a type of Network plugin that adheres to the app/CNI specification.

Container Network Interface (CNI)

Container Storage Interface (CSI): An illustration showing an orange container with the doors open, and a blue box containing folders. An arrow leads from the blue box into the open container.

Container Storage Interface (CSI)

Container Storage Interface (CSI): The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers.

Container Storage Interface (CSI)

Control Plane: An illustration showing two containers on a platform. Beneath the platform is a box with various screens and buttons, and the containers above are shown on the screens.

Control Plane

Control Plane: The container orchestration layer that exposes the API and interfaces to define, deploy and manage the lifecycle of containers.

Control Plane

Controller: An illustration showing the view through a pair of binoculars. Through the binoculars can be seen two Pods with a third Pod appearing (represented by dashed lines).

Controller

Controller: A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.

Controller

Data Plane: An illustration showing a platform with two containers on it. Underneath is another platform with blocks labelled 'CPU' and 'Memory'.

Data Plane

Data Plane: The layer that provides storage capacity such as CPU, memory, network and storage so that containers can run and connect to the network.

Data Plane

Etcd: An illustration showing the etcd logo.

Etcd

Etcd: Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.

Etcd

Extensions: An illustration showing the Kubernetes logo. The logo is connected by dashed lines to a letter 'E', and then to a computer.

Extensions

Extensions: Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.

Extensions

Horizontal Pod Autoscaler: An illustration showing 2 Pods marked 1A and 1B respectively and both with 'CPU 30'. A third Pod marked 1C (and also 30 CPU) is appearing. Next to them is a screen that reads 'Current: 60, Target: 90'.

Horizontal Pod Autoscaling

Horizontal Pod Autoscaler: An API resource that automatically scales the number of Pod replicas based on targeted CPU utilisation or custom metric targets.

Horizontal Pod Autoscaling

Kubernetes API: An illustration showing a box with various dials and a screen, labelled with the Kubernetes logo. On the screen are a pair of Nodes and some text.

Kubernetes API

Kubernetes API: The application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster.

Kubernetes API

Minikube: An illustration showing the Kubernetes logo being shrunk down to fit on a computer screen.

Minikube

Minikube: A tool for running Kubernetes locally.

Minikube

Node: An illustration showing a smiling anthropomorphic figure standing on top of the Kubernetes logo.

Node

Node: A node is a worker machine in Kubernetes.

Node

Operator Pattern: An illustration showing a whiteboard, with a system diagram drawn on it that shows components interacting with each other.

Operator Pattern

Operator Pattern: The operator pattern is a system design that links a Controller to one or more custom resources.

Operator Pattern

Workloads: An illustration showing an anthropomorphic figure using a pallet mover to push a shipping container.

Workloads

Workloads: Workloads are objects you use to manage and run your containers on the cluster.

Workloads

Kubernetes Master Components

Kubernetes master components are found in the master node. These components are the Kubernetes cluster’s control plane, making global decisions about the cluster and detecting and responding to cluster events. For example, the kube-apiserver component will receive an API request to create a new Pod and appropriate actions will be executed to fulfill the request and the kube-controller-manager component makes sure the cluster is in the desired state.

<- Swipe for image / definition ->

Cloud Controller Manager: An illustration showing the control plane box with a platform above it. On the platform is a container and a cloud, and the cloud has arrows going to and from a box labelled 'API'.

Cloud Controller Manager

Cloud Controller Manager: A Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that just interact with your cluster.

Cloud Controller Manager

Kube-apiserver: An illustration showing a master node with a machine on top. The machine has some dials and a screen readout, and is connected to a satellite dish to show transmission.

kube-apiserver

Kube-apiserver: Component on the master that exposes the Kubernetes API. It is the front end for the Kubernetes control plane.

kube-apiserver

Kube-controller-manager: An illustration showing two anthropomorphic figures working in a control center. On one side are screens labelled 'Current' (which shows one Pod) and 'Desired' (which shows two Pods). On the other side is a screen which reads 'Updating cluster state...'.

kube-controller-manager

One of the three processes that compose the Kubernetes Master. A daemon that embeds the core control loops shipped wih Kubernetes.

kube-controller-manager

Replication Controller: An illustration showing three Pods labelled 1A, 1B and 1C and a screen that reads 'Pods needed: 3'.

Replication Controller

Replication Controller: A workload resource that manages a replicated application, ensuring that a specific number of instances of a Pod are running.

Replication Controller

Kube-scheduler: An illustration showing three nodes with different numbers of Pods on top of them. A robot arm is adding a Pod to one of the Nodes.

Scheduler

Kube-scheduler: Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on.

Scheduler

Kubernetes Node Components

Kubernetes node components are found in every worker node. The Kubelet component ensures the containers are running in a Pod, the Container Runtime component is the software required for running the containers and the kube-proxy component implements the concepts defined by the Service object.

<- Swipe for image / definition ->

Container Runtime Interface (CRI): An illustration showing containers moving along a conveyor belt on top of a node. The kubelet (an anthropomorphic figure with a telescope) is also on top of the node and watching the containers.

Container Runtime Interface (CRI)

Container Runtime Interface (CRI): The container runtime interface (CRI) is an API for container runtimes to integrate with kubelet on a node.

Container Runtime Interface (CRI)

Device Plugin: An illustration showing 3 orange containers and one purple container (labelled 'DP'). An additional block (also labelled 'DP') is linked to the purple container by an arrow.

Device Plugin

Device Plugin: Device Plugins are containers running in Kubernetes that provide access to a vendor specific resource.

Device Plugin

Kubelet: An illustration showing a Pod with a containers inside. Next to the Pod is a Node (represented by pink anthropomorphic figure) with a blue anthropomorphic figure sat on top, looking at the containers through a telescope.

Kubelet

Kubelet: An agent that runs on each node on the cluster. It makes sure that containers are running in a Pod.

Kubelet

Kube-proxy: An illustration showing a crossroads A truck labelled 'Traffic' is approaching that crossroad, and at the end of the road in each direction is a Pod (labelled respectively 1, 2 and 3). There is also a node with a kubelet. All these elements are faded into the background, as the focus is on a signpost in the middle of the crossroad. This signpost points in the three directions and is labelled 'Pod 1', 'Pod 2' and 'Pod 3'.
Kube-proxy: kube-proxy is a network proxy that runs on each node on a cluster, implementing part of the Kubernetes Service concept.

Kubernetes Administration

In Kubernetes, it is possible to regulate resources that a user, object and processes can access. With Role Based Access Control (RBAC) regulates access to computer or network resources for example you can restrict which users can deploy Kubernetes objects to a particular namespace. Resource Quotas can restrict the resources consumed per namespace.

<- Swipe for image / definition ->

Add-ons: An illustration showing the back of a PC box, with numerous different ports.

Add-ons

Add-ons: Resources that extend the functionality of Kubernetes.

Add-ons

Admission Controller: An illustration showing a transmitter in the middle. On the right hand side are various different coloured arrows leading to the transmitter (these arrows are labelled 'Requests'). On the left hand side of the illustration these arrows have been condensed into clear lines in each colour, which lead from the transmitter to a master node with kube-apiserver.

Admission Controller

Admission Controller: A piece of code that intercepts requests to the Kubernetes API server prior to the persistence of the object.

Admission Controller

Kubectl: An illustration of a command line window that starts with '/kubectl'. A dual-headed arrow goes between this window and the Kubernetes API (represented by a server box with Kubernetes logo).

Kubectl

Kubectl: A command line tool for communicating with a Kubernetes API server.

Kubectl

RBAC (Role Based Access Control): An illustration showing a box with a screen. On the screen are rows of text, and at the end of each row is a padlock in either opened or closed position.

RBAC (Role Based Access Control)

RBAC (Role Based Access Control): Manages authorisation decisions, allowing admins to dynamically configure access policies for the Kubernetes API.

RBAC (Role Based Access Control)

Conclusion

That's all for now, we hope this resource proves useful for you! A reminder that all of the images are available to use under CC BY 4.0, and we'd be delighted to see them in your future projects.

If you'd like to learn more we definitely recommend checking out the full glossary – it's less fun but more comprehensive. We'd also love to hear from you if you have any feedback, or simply if you want to talk Kube.