Kubernetes. The shallow introduction to base components.

The last time when I used Kubernetes was a quite long time ago. Therefore, I decided to refresh my knowledge in this area. My learning process I would like to solidify by writing several blog posts. This one is the first one. Let me start with the theory on the basic components of Kubernetes.

Without further ado, let’s see what we have there.


According to the official documentation:

“Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.”

A Pod contains a container or group of related containers that we can deploy on the cluster. A Pod has its own IP address in the virtual K8s network. What is crucial, is that address is not static, and it changes when a Pod is being recreated.


A service is an abstraction that gives the possibility to communicate with Pods in the virtual network. It solves the problem related to the fact that Pods may change their IP addresses during recreation. Another important thing about a service is that it allows communication with multiple instances of the same Pod. It can act as, for example, a load balancer for a set of Pods. A service allows also communication from outside the cluster.


As I mentioned above, services allow communication with Pods from external sources. However, using services for this purpose, especially in production, is not a good practice. For this scenario, we have another dedicated component, called ingress. Quoting official documentation:

“An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting”.

Config maps and secrets

Config maps and secrets are components used for storing non-confidential and confidential key-value pairs that pods may consume, for example, as environmental variables. Thanks to them, we can separate configs from containers. This entails that changing config’s values does not require container image rebuild.


Deployments describe the desired state of a cluster. For example, in a deployment, we can specify how many pods with a specific container’s image should be instantiated.


Has the identical function as deployments, with one difference. StatefulSets are meant for containers that need:
– stable, unique network identifiers.
– stable, persistent storage.
– ordered, graceful deployment and scaling.
– ordered, automated rolling updates.

They are great for containers with DBs.


Same as in Docker volumes give the possibility to persist data across containers restart. They also allow sharing data between containers running in the Pod. Volumes in Kubernetes support not only the directory on a hard-drive, but also many more other solutions, like network/cloud storage.

Please follow and like us:
Notify of