What is Kubernetes & Main Kubernetes Components
Kubernetes
Kubernetes is an open-Source container orchestration framework originally developed by Google. It facilitates the management of containerized applications across various environments, including physical machines, virtual machines, and the cloud. Automates deployment, scaling, and container management. This is most widely recognized container orchestration tool.
Features of K8S
Kubernetes offers several key features:
- High Availability (No Downtime) : High availability ensures that applications always remain accessible to users, preventing downtime.
- Scalability (High Performance) : Kubernetes enables rapid scaling of applications to accommodate increased load and user traffic. Similarly, it allows for easy scaling down when demand decreases, ensuring flexibility in resource management.
- Disaster Recovery (Backup and Restore) : In case of infrastructure failures—such as data loss, server crashes, or other critical issues—Kubernetes provides mechanisms for backing up and restoring data, ensuring that applications maintain their latest state without data loss.
Main Kubernetes Components
Node
In Kubernetes, a worker node is a physical or virtual machine that runs application workloads.
Pod
The smallest unit in Kubernetes is a Pod, which acts as an abstraction over a container, creating a runtime environment for container . A Pod is designed to run a single application container but can also, host multiple containers if needed, typically for a main application and a helper service.
Kubernetes provides a built-in virtual network, assigning each Pod a unique internal IP address, enabling direct communication between Pods using these internal IPs.
Pods are Ephemeral:
Pods in Kubernetes are ephemeral, meaning they can be easily terminated and replaced with new ones, each receiving a new IP address. This makes direct communication between Pods using IP addresses inconvenient. To Solve this issue, Kubernetes provides a Service.
Service
A static IP address or permanent IP address that can be attached to each Pod. The life cycle of service and Pod or not connected, even if the Pod dies the service and its IP address will stay.
Ingress
if your application to be accessible through a browser ,for this you must create an external service .But obviously you wouldn’t want your database to be open to the public requests. For that you would create Something called an internal service. However, the URL of the external service is not very practical. Basically, what you have is http://<nodeip>:port .
Note: Testing purpose is ok but in production we will expect url with domain name only. https://my-app.com
The alternate to external service in K8S is Ingress. external request goes first to ingress and it does the forwarding , then to the service.
Configmap & Secret
If environment variables of the application like a database URL ,external service URLs are configured inside the application image, any changes would require rebuilding the application. To avoid this, Kubernetes provides ConfigMap, which serves as an external configuration Source. ConfigMap can be attached to a Pod, allowing it to access the stored data without requiring a new image build.
Kubernetes offers Secrets, which function similarly to ConfigMaps but are designed to store sensitive data. Secrets are stored in Base64 encoded format, though this does not provide full security. Kubernetes does not encrypt Secrets by default, So, third-party tools—either from cloud providers or standalone Solutions—must be used for encryption to ensure security.
Volumes
In Kubernetes, if a Pod restarts, any data stored within it will be lost, To ensure data is reliably stored long-term, Kubernetes provides Volumes.
Volumes work by attaching physical storage to a Pod, which can either be:
- Local storage – located on the same server node where the Pod is running.
- Remote storage – external to the Kubernetes cluster, such as cloud storage or on-premises storage.
Deployments and Stateful Sets
Kubernetes uses Deployments to create pods, which serve as a blueprint for managing replicas. With Deployments, users can define the number of replicas and easily scale Pods up or down as needed. Since Deployments abstract Pod management, they are the primary way to interact with applications in Kubernetes.
However, managing database replicas requires a different approach. Unlike stateless application Pods, databases maintain a state (data), meaning replicas must share and synchronize data to avoid inconsistencies. This is where StatefulSets come in. StatefulSets, like Deployments, handle Pod replication and scaling, but they ensure that database reads and writes remain synchronized, preventing data conflicts.
Deploying databases within a K8S using StatefulSets can be complex and challenging. Because of this, a common practice is to host databases outside the Kubernetes cluster while keeping application Deployments within the cluster for easy scalability and replication.
DaemonSet
To Solve this issue, Kubernetes provides a DaemonSet, which ensures that exactly one pod per node is automatically deployed and managed. A DaemonSet dynamically adjusts the number of pod replicas based on the number of nodes in the cluster—adding pods when new nodes are added and removing pods when nodes are removed. This eliminates the need to manually specify replica counts and ensures that the application is evenly distributed across all nodes.