In this blog post, we will go through the fundamentals of Kubernetes in an easy-to-understand way without any complex technical terminologies. By the end of this post, you will have a better understanding of the basic components of Kubernetes and be ready to explore the world of Kubernetes with confidence.
As per the official documentation,
Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
In simple words, Kubernetes is a container orchestration platform that manages the entire lifecycle of individual containers. If a container shuts down, the orchestration platform automatically launches another container in its place. Additionally, it offers a range of features such as automated rollouts and rollbacks, service discovery, load balancing, and more.
Basic Kubernetes Components
Kubernetes offers a variety of components to help build robust architectures. In this section, we’ll take a closer look at the fundamental components.
Pod
The Pod object is the smallest unit of K8s, comprised of one or more (tightly related) containers, with shared storage and network resources, and a specification for how to run the containers. It is an abstraction over the container as Kubernetes manages pods rather than managing the containers directly.
K8s provides a built-in virtual network, assigning a unique internal IP address to each pod. However, pods are ephemeral, so when they are recreated, a new IP address is assigned. So communicating with the pod using its IP address can become highly inconvenient. This is where the Service object comes into the picture.
Service
A Kubernetes Service provides you with a stable endpoint that can be used to direct traffic to the desired pods. The lifecycles of the service and the pod are not connected, so even if the pod dies, the service and its address will stay. The set of pods targeted by a service is usually determined by a selector that we define.
So now if we want to provide communication between components within the k8s cluster, we can create internal services. On the other hand, external services expose applications to clients outside the k8s cluster, enabling access from web browser or external systems.
While services provide basic external access to applications, if we wanted to expose our application to traffic external to our cluster with advanced routing and traffic management capabilities, we need to define an Ingress object.
Ingress
The Ingress object provides external access to the services in a cluster. The request goes first to the ingress and it does the forwarding to the service. The benefit of this approach is that we can manage which service to expose to the public network. Additionally, it offers numerous advanced features such as path-based or host-based routing, TLS termination, and load balancing, among others.
ConfigMap and Secret
Our container images contain various properties stored within them. Any change in the property value will lead to rebuilding the container image which can be quite inconvenient.
K8s provides us with an external key-value store that can be used to store non-confidential data. This key-value store is known as the ConfigMap. It also helps us to decouple environment-specific properties so that our applications are portable.
However, ConfigMap stores data in plain text, which is problematic for sensitive data like credentials that are required by the application code during runtime. To address this problem, Kubernetes has a component called Secret. Secrets are similar to ConfigMaps but are specifically designed to hold confidential data. However, it’s important to remember that Secrets are base64-encoded.
Deployment
Consider a scenario where your backend application runs on a single Pod and suddenly crashes due to an error. It will automatically be recreated and will accept new requests. But, there would be a down time which is unacceptable in production environments.
Here comes the advantage of distributed systems and containers. Instead of relying on a single pod, we will replicate our container over multiple pods. But if multiple pods are running which pod will receive the incoming request? So along with providing a static address, the Service object also acts as the load balancer and forwards the incoming request to the appropriate pod.
But what if we want to release a new version of the application? Should we manually update the container image on each pod? What if we want to increase or decrease the number of pods? Do we have to manually create or destroy them?
The answer to all these questions is Deployment.
The Deployment component acts as a blueprint for the pods. We can specify the required number of pods, scale up or scale down, modify the resources, and much more. In simpler words, we can say that we mention our desired state of the application in the Deployment and k8s changes the actual state to the desired state in a controlled fashion.
We’ve only scratched the surface of Kubernetes here. Kubernetes has much more to explore. Experimentation is key — play around with configurations, explore new features, and let your curiosity guide you. Share your thoughts or questions in the comments below. And keep an eye out for more Kubernetes insights coming your way!