Mastering Kubernetes Core Concepts
Week 12 - Workloads, Storage & Networking
Introduction
Hello there to all 👋! This week has been one of the most overwhelming ones yet. I have been studying and learning Kubernetes for the past 8-9 days, and I have to say it hasn't been easy. The amount of information one has to absorb while learning and understanding Kubernetes is truly overwhelming. Last week, I got started with Kubernetes and learned what Kubernetes is about, what problems it solves, and its architecture. This week I continued on that journey and learned many important concepts such as Namespaces, Pods, Deployments, Services, Jobs, storage, and more.
Workload Resources
After going through and understanding the core concepts and architecture, I moved on to the next topic, which was Workload resources. Workload resources comprise Pods, Controllers, and Configuration management. Once again, to practice while learning, I created an EC2 instance of type t2.medium and learned to install Kubernetes through both Minikube and Kind. Once the K8s setup was done, I got started with the first topic, which was Namespaces.
Namespaces are virtual clusters within a physical Kubernetes cluster. Namespaces are Kubernetes' way of organizing and isolating resources within a cluster.
We know Kubernetes is a container orchestration tool, and all those containers are wrapped with an abstract layer called Pods.
Pods are the fundamental building blocks of Kubernetes, serving as the smallest deployable unit that can be created and managed within the system. The purpose of pods is to wrap containers with shared networking and storage.
I came to know that pods are ephemeral, which means they can fail or be destroyed easily. So as part of K8s's auto-healing process, K8s uses controllers like Deployment to maintain the desired state and re-create or restart pods to fulfill the desired number of pods.
Deployment manages multiple identical pods and ensures the desired number of pod replicas are running. The same functionality is provided by ReplicaSets, but Deployment has a few important advantages over it, such as rolling updates and rollbacks. Since these pods run inside the cluster, to access the applications running inside the pods, we use Services.
Service allows for stable and permanent networking for pods, ensuring that pods remain accessible even as they are updated or scaled. Service has 4 types: ClusterIP (internal), NodePort (external), LoadBalancer (cloud), and ExternalName.
While learning and practicing these concepts, I was creating these resources using commands, and then I came to know about manifest files. Manifest files are YAML or JSON files that describe the desired state of resources such as Pods, Deployments, and Services, and can be applied directly using the kubectl tool. This approach was much more efficient than using commands to create, update, or delete resources. Examples of all the manifest files for different resources are well documented in the Kubernetes official documentation, which has been a great help.
Workload Controllers
Like Deployment and ReplicaSets, there are more controllers that ensure the state of K8s is equal to the desired state, such as StatefulSet and DaemonSet.
StatefulSet manages stateful applications that need stable identities and persistent storage, such as databases, message queues, etc. Unlike Deployments, which are used for stateless applications, StatefulSets ensure that each Pod has a unique, persistent identity, including a stable hostname and volume.
DaemonSet ensures exactly one pod runs on every node (or selected nodes). DaemonSets are perfect for system-level services that need to run on every node, such as log collectors, monitoring agents, etc.
While these controllers are used to ensure the pods are running on the desired worker nodes and in the desired number, Jobs and CronJobs handle workloads that need to run to completion rather than continuously. While Deployments and StatefulSets keep applications running forever, Jobs are designed to run to completion and then stop. Jobs are perfect for one-time tasks, batch processing, and migration tasks. While Jobs run to completion for a single time, CronJobs run on a schedule. These can be used for scheduled maintenance, periodic backups, and regular data processing. I practiced creating Jobs and CronJobs by creating a simple CronJob to log a sentence.
Storage Resources
I have learned that Pods are ephemeral, which means if or when they die, their data disappears. But for stateful applications like databases, any team or company cannot afford to lose their data. So, the solution to this problem is Persistent Volume and Persistent Volume Claim, which provides storage that outlives individual pods.
Persistent Volume is a piece of storage in the cluster that has been provisioned by the administrator or dynamically provisioned. It represents actual storage like disk space or cloud storage, and this storage is not dependent on any pod.
Persistent Volume Claim is the request to use storage by an application. When an application requests storage (Persistent Volume), the volume binds to the application. The process of binding is as follows:
Administrator provisions PV (or dynamic provisioning creates it)
User creates PVC specifying storage requirements
Kubernetes matches PVC to suitable PV (binding process)
Pod uses PVC to mount persistent storage
Data persists even if pod is deleted
Networking - Ingress
Up to this point, I learned about internal networking for pods and how to access them from inside the container. But when deploying an application, we want users to be able to access and route through the application without any errors. For that purpose, Kubernetes Ingress is used to provide a centralized way to manage external access to services within a cluster. It allows for the routing of HTTP and HTTPS traffic to different services based on criteria such as URL paths and hostnames. Ingress is an important and essential part of the Kubernetes ecosystem.
Ingress comprises 3 main components:
Ingress Resource: The configuration object defining routing rules
Ingress Controller: The actual implementation that processes Ingress rules (nginx, Traefik, AWS ALB, etc.)
Backend Services: The destination services that receive routed traffic
Ingress has different routing strategies, such as path-based routing like /api, /app, etc., and hostname-based routing such as api.company.com and blog.company.com. Ingress is a complex and deep topic, so even though I learned to configure and implement Ingress rules in demo applications, I still need to dive deeper into this topic in the future.
Resource Configuration
So far, I had learned the fundamental yet important topics of K8s such as storage, networking, etc., but learning about resource configuration is as important as them. Resource configuration consists of concepts like ConfigMaps, Secrets, Resource Quotas, Limits, and much more. But for initial understanding, I decided to focus on these four first. By creating multiple manifest files for the creation and deletion of resources like pods, deployments, and services, I discovered that configuration should be stored in a separate environment. Just like we use .env to store configurations and secrets of the application, in K8s we use ConfigMaps and Secrets.
ConfigMap stores configuration data as key-value pairs that pods can consume as environment variables, command-line arguments, or mounted files. ConfigMap stores non-sensitive data like database URLs, settings, etc.
Secrets store sensitive data like passwords, tokens, and keys. They're similar to ConfigMaps but with additional security features. Data in Secrets configuration is usually stored in base64 format to encode binary data into text format for systems that can't handle binary data well.
These two are used to manage configuration data and sensitive information, whereas Resource Quotas and Limits are part of a resource management strategy that ensures fair distribution of resources. Resource Quotas and Limits work together to control how much CPU, memory, and other resources can be consumed at both the namespace and pod levels.
These are used to set maximum resources a container can use. If exceeded, the container is throttled (CPU) or killed (memory). Managing resources inside the cluster is critical to ensure that applications run smoothly while simultaneously optimizing costs.
Resources I Used
Challenges I Faced
1️⃣ K8s pod's status - CrashLoopBackoff when creating deployment
This was frustrating because the pods kept restarting in an endless loop. After debugging for a while, I discovered that I was working on the wrong Git branch, which had different configuration files than what I expected. The pod was trying to run with incorrect configurations, causing it to crash repeatedly.
Solution: Switched to the correct Git branch with the proper configuration files, and the deployment worked perfectly.
2️⃣ Unexpected Ingress error - Validating Admission Webhook for the NGINX Ingress Controller
This error appeared when I was trying to create Ingress resources. The webhook was rejecting my Ingress configurations, and despite trying various troubleshooting approaches like checking the webhook configuration and validating my manifest files, I couldn't resolve the issue.
Solution: After spending considerable time debugging, I decided to create a fresh cluster, which resolved the issue completely.
3️⃣ Wasn't able to update previously written manifest files
When trying to edit YAML files using vim, I kept getting permission denied errors. This was particularly annoying when I needed to make quick changes to my configurations during testing.
Solution: Had to use sudo with the vim command to get the necessary permissions to edit the files.
What's Next
The next topics for me in Kubernetes are Auto-scaling (HPA and VPA) and Taints and Tolerations, so I will continue with my Kubernetes learning journey.
Let's Connect!
If you have any recommended resources, better approaches to my challenges, or insights, I'd love to hear them! Drop your thoughts in the comments.
Have a wonderful day!
