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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.