Kubernetes (K8s for short) has become an integral part of modern IT infrastructures. At the same time, many companies and decision-makers shy away from this technology: not only because of the technology itself, but also because of the many unfamiliar terms.
In this article, we explain the most important Kubernetes terms in detail and in everyday language. Our aim is to make Kubernetes understandable, tangible and logical.
Pod
A pod is the smallest unit you can deploy in a Kubernetes environment. It has one or more containers that work together and share the network and storage resources of the host node on which the pod is located.
You can either create pods manually or automate various Kubernetes controllers. The advantage of controllers is that they manage the created pods for you: For example, if you shut down a node, a controller redistributes the pods on it.
Important to understand:
- Pods are transient
- If possible, never work directly with individual pods
- Kubernetes treats pods like disposable units
Container
The container is what is contained in a pod. It contains everything it needs to work. A container contains the application, all the required libraries and runtime environment.
Why containers are so important for Kubernetes
Kubernetes can only automate what is standardized.
containers deliver exactly that:
- Reproducible
- Scalable
- Interchangeable
Node
A Kubernetes node is a small collection of resources that supports one or more containers. These resources are, for example, physical servers or virtual machines. Each resource contains the services Docker, kube-proxy and kubelet, which help to create the runtime environment and support Kubernetes pods.
Important feature:
- Pods are not bound to a node.
- If a node fails, Kubernetes restarts the pods on another node.
Cluster
A cluster is a group of nodes that behave like a single, distributed system. In Kubernetes, a cluster is the group of nodes that you use to manage and run your containerized applications.
A Kubernetes cluster consists of two subgroups, each with one or more nodes: The control plane and the workers. The nodes of the control plane control the state of the entire cluster. They send out tasks in the cluster, including planning, maintenance and updates.
A cluster therefore consists of:
- Multiple nodes
- A central control system (control plane)
- Network, storage and other resources (e.g. GPUs)
Control Plane
The control plane ensures the desired state of the cluster and determines, for example, which applications are running. The components of the control plane consist of:
- Kubernetes API Server
- Kubernetes Scheduler
- Kubernetes Cloud Controller (optional)
- Kubernetes Controller Manager
- etcd (Key Value Store)
Namespace
Namespaces divide a Kubernetes cluster into isolated logical units so that IT teams can better organize their resources. You can create as many namespaces as you like. IT teams use them to logically separate development, test and production environments from each other, to set guidelines for resource usage or to map responsibilities.
ConfigMap and Secret
The application configuration for a service can be saved in ConfigMaps and Secrets, for example database passwords or email settings. This configuration can then be made available to a container either as an environment variable or via a volume.
Save ConfigMaps:
- Configuration values
- Environment variables
- Feature flags
Deployment
A deployment is like a written work instruction for Kubernetes. It describes how many pods of the same application should run, which container version and how updates are to be carried out. It is particularly practical that deployments can take over the scaling and updating of the pods. Rolling updates with various strategies are also supported. This enables so-called zero-downtime deployments, in which applications can be updated continuously and without interruption during operation.
Why deployments are so powerful:
- Rolling releases without downtime
- Automatic rollback in the event of errors
- Full control without manual intervention
StatefulSet
A StatefulSet allows multiple instances of a pod to be started in a specified order. For example, it can be ensured that a primary database server is always started before its secondary replicas.
Services
Services have a static IP address. Each pod that is to be accessible therefore normally has an assigned service. Services also support load balancing, which simplifies access to pods, even if there are multiple replicas of them. Depending on the type used, services can only be accessible internally in the cluster or also externally.
Why services are indispensable:
Pods are constantly changing: IP address, location, number
Without service:
Chaos for every application that wants to communicate
Job
A job starts one or more pods and executes them. Once the specified number of pods has been successfully executed, the job is complete. CronJobs are based on jobs and enable the scheduled, recurring execution of pods.
etcd
etcd is the primary data storage of Kubernetes. It contains all configuration files and information about the state of a particular cluster and stores and replicates all cluster states. You can deploy etcd either as pods on the nodes of the control plan or as an external cluster.
Docker image
A Docker image contains the complete code of an application and its dependencies, e.g. a web server or a runtime environment. The configuration of the service is excluded, as this is dependent on the environment.
GitOps
GitOps is a Kubernetes-centric paradigm for developers and IT administrators. It uses Git as a single source of truth to define the desired state of clusters and applications. It requires the use of Git to deploy infrastructure and software.
Helmet charts
Helm charts are, simply put, a collection of YAML files with different resources that are necessary for the deployment of an application. Over the years, Helm has established itself as the de facto “package manager” for Kubernetes.
Cubelet
The Kubelet is an agent that manages the pods on each Kubernetes node. It registers its node with the API server and ensures that all containers in a pod run without errors. It reports the status of its host to the control plane and communicates continuously with the Kubernetes API server.
Kube proxy
Kube-Proxy provides network services for the Kubernetes environment. It processes network communication both within a cluster and between the cluster and the outside world. To do this, it manages network rules on nodes via nftables.
Kubernetes Scheduler
It distributes copies of pods to different nodes in order to increase availability. In doing so, it follows the defined requirements for resources and conditions for distributing the application within the cluster.
Ingress
Ingress is an extended service for HTTP/HTTPS. It enables requests to be forwarded to specific services based on request information.
Ingress regulates:
- External access
- Routing by domain or path
- TLS/HTTPS
Ingress resource
Publishes a service via a public URL. Based on the ingress, an ingress controller (e.g. Traefik) is automatically configured so that incoming traffic from outside is correctly distributed to the service and thus also to the pods of this service.
Volumes
Kubernetes enables the provision of data for applications in pods using volumes. The data can originate from Secrets, ConfigMaps or PersistentVolumes.
It is also possible to provide non-persistent storage that is deleted when the pod is terminated.
Persistent Volume
The file system of a container is not persistent. As soon as a container is restarted, the existing file system is deleted and a new one is created from the Docker image. In order to store data persistently and securely in the long term – for example for the operation of databases – you can create persistent volumes in Kubernetes and mount them in a container.
Scaling
Kubernetes supports horizontal scaling (more instances) and vertical scaling (more resources per instance) for pods and nodes. In some scenarios, additional controllers are required for this.
Self-Healing
Kubernetes monitors pods, detects errors and replaces defective instances.
Conclusion: Understanding Kubernetes step by step
At first glance, Kubernetes seems extensive and complex, mainly due to the large number of terms and concepts. This is exactly where this article comes in: It shows that Kubernetes is made up of clearly delineated building blocks that are logically interlinked. Anyone who understands the basic terms such as pod, container, node, deployment or service can already understand very well how applications are deployed, operated and secured in Kubernetes.
It is important to note that you do not need to master all the concepts in detail to get started with Kubernetes. Many topics such as Ingress, StatefulSets, GitOps or Helm only become relevant as applications grow or become more complex. A solid basic understanding of the core components is sufficient to hold discussions with developer or DevOps teams, to better classify decisions and to realistically assess the added value of Kubernetes.
Kubernetes is not rocket science, but a powerful automation framework that can be learned step by step. If you start small and understand the basics, you will gradually build up the knowledge that enables modern, scalable and reliable IT infrastructures.
0 Comments