Kubernetes, which is defined as a powerful container orchestration platform, has several important components such as Pods, Services, Ingress, ConfigMaps, Secrets, Deployments, ReplicaSet, StatefulSets, and others. In this article, we will discuss 8 important components in-depth to help you understand how they function and how they tie into the larger Kubernetes ecosystem before deploying your first application in Kubernetes. In the previous article of this Kubernetes series, we learned about essential concepts of Kubernetes before starting your Kubernetes journey.
So, this article is for you whether you're a beginner just getting started with Kubernetes or an experienced user trying to enhance your understanding. Let's explore some of Kubernetes' key components to realize the full potential of container orchestration! Hopefully, by the end of this artile, you'll have a solid understanding of each of these components as well as how to deploy and manage your containerized apps using them.
Some of Kubernetes' essential components are:
A pod is known as the smallest deployable unit in Kubernetes which represents a single instance of a running process. Pods run inside a node which is a physical or virtual machine in a Kubernetes cluster that runs containers. Usually, a pod is meant to run one container inside it but it can contain multiple containers as well. One common use case is a pod is the sidecar pattern where a main application container run alongside one and more sidecar containers for providing different functionality. For example, a single container inside a pod runs an instance of a web server like Nginx or Apache but in case there are two containers, then the main container runs a web server, and the other running sidecar container provides logging or monitoring capabilities.
In the diagram, we can see that node contains two pods and each pod has a container running inside it. One pod has a my-app container and another pod has a database container.
In Kubernetes, when pods are created, they are assigned an internal IP address to communicate with each other. If a pod is recreated, it may be assigned a different IP address that's why these IP addresses are not stable. So, if my-app is communicating with the database app using an internal IP address, we need to adjust the IP address every time the database pod recreation.
To prevent this issue, another component of Kubernetes Service is used. A Service provides a stable IP address for pods. Even if pods are recreated, the Service and its IP address will stay. In the above diagram, if my-app pod will be recreated, it will not affect the life cycle of its service. The service and its IP address will be the same, so we don't need to adjust any IP address anymore. Services also act as a load balancer which means that it catches traffic and forwards it to the pod that is the least busy.
An Ingress is a Kubernetes component that enables you to expose your services to the public internet. An Ingress performs as a reverse proxy, forwarding incoming requests to the appropriate service based on the rules that you define on the ingress resource. Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer.
In this diagram, we are exposing the my-app application over the public internet. Here, a request from a client first goes to the ingress and then the ingress sends that request to the service of the my-app pod.
A ConfigMap provides a way to store configuration data in key-value pairs for an application separately from your application code. It is an external configuration file for an application. It can be used to store environment variables, database endpoints, or other application settings. It is connected to the pods, so pods can get data that ConfigMap contains.
In this example, to communicate with the database pod, my-app will have a database endpoint/URL named "my-db-service". If we put this endpoint in the application as an application properties file or as an external variable, it will be a problem if the URL will change to "db-service". In that case, the application needs to rebuild which creates a complicated process. We can avoid all these hassles if we simply put this database endpoint in the ConfigMap and adjust it in case of any changes.
A Secret gives an application a method to store sensitive information like usernames, passwords, certificates, or API keys in an encrypted format. This component is similar to ConfigMap. The only difference is ConfigMap is used to store information in a plain text format while Secrets are used to store encrypted data securely. Secret also needs to be attached to the pod, so that pod gets those secure contents from it.
In this diagram, we can add the database's credentials inside the Secret with proper encryption and connects it to the my-app pods to get those credentials securely.
A Deployment is a high-level object that manages the deployment and scaling of a set of replicas of a pod. It is known as the blueprint of a pod. It ensures that the desired number of replicas is always healthy and running. It provides a declarative approach to specify your application's desired state, along with the container image, the number of replicas, and any other configuration options. Kubernetes automatically handles the deployment of new replicas and the termination of old replicas when you change the configuration of the Deployment, ensuring that your application is always running and up-to-date.
For example, if we specify 2 replicas in the deployment file of the my-app pod, it will create another pod in another node of the Kubernetes cluster which will also connect to the same Service. In the diagram, we can see that if a pod dies, the service will forward the traffic to another pod running in another node in the same cluster as the Service works as a load balancer. In this way, we can ensure that our application is always running and healthy.
In Kubernetes, a ReplicaSet makes sure that a certain amount of pod replicas are running at all times. For pods, fault tolerance and scalability are ensured by replica sets. ReplicaSet shouldn't typically be created explicitly. Deployment, on the other hand, is a higher-level object that manages ReplicaSets and gives Pods declarative updates. Instead of using ReplicaSets explicitly, Deployments are recommended.
A StatefulSet maintains a set of stateful Pods and ensures a specified number of stateful pods are always running. A StatefulSet is used for applications that require stable and unique network identities or persistent storage, such as databases. If we want to use the replication of the database pod in another node, we can't use the deployment because the database has its state which is its data. In this case, we need to use StatefulSet which ensures that database reads and writes are synchronized. Deploying a database using StatefulSet is a bit complicated compared with Deployment. So it is recommended to host a database outside the Kubernetes cluster.
In conclusion, Kubernetes is a powerful platform for container orchestration that provides a wide range of components to support the deployment and scaling of your apps. We looked at 8 key Kubernetes parts in this article: Pods, Services, Ingress, ConfigMaps, Secrets, Deployments, ReplicaSets, and StatefulSets. You can construct reliable, scalable, and resilient applications that take full advantage of Kubernetes by comprehending about these components and how they work.
I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the ❤️ like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.