Kubernetes 101: Grasping the Fundamentals ☸️

Author(s): Afaque Umer

Originally published on Towards AI.

Kubernetes 101: Grasping the Fundamentals ☸️

The Problem ⁉️

It’s no secret that the craze for running containerized applications has surged in recent years. The demand for container instances is equally massive for organizations or projects operating on a massive scale. In a production setting, it’s crucial to oversee the containers hosting applications and guarantee uninterrupted operation. For instance, should a container fail, another should seamlessly take its place. Wouldn’t it be simpler if such management were automated by a dedicated system?

Enter Kubernetes 🚀 the ultimate savior! With Kubernetes, you gain a robust framework for running distributed systems with resilience. It handles scaling, and failover, offers deployment patterns, and much more ✨

Kubernetes What? K8s Who?

Kubernetes is a container orchestration platform that leverages Linux container technologies to manage the deployment and scaling of applications. It can create and destroy instances of an
application according to demand over a cluster of machines🪄

Imagine it as the fairy godmother of containers, making sure they dance gracefully at the ball of your software kingdom. In simpler terms, Kubernetes is the ultimate stage manager for your containerized applications. It simplifies the underlying infrastructure and offers a unified API, managing the cluster. This simplification enables developers to concentrate on their application’s logic without being bogged down by infrastructure management complexities.

And here’s the kicker: in our world of software, we love shortcuts so much that we’ve nicknamed Kubernetes as k8s. Lazy? Maybe. Efficient? Absolutely! So, the next time you spot k8s and think it’s some secret code, fear not, my friend, you’re now in on the joke!

Before delving into Kubernetes, grasping the concepts of containers and orchestration is essential. Containerization is a distinct domain, and familiarity with it is crucial. If you’re new to containers, I suggest checking out my previous blog where I’ve covered this topic in detail. Here’s the link for your convenience.

Alrighty, Now that we’ve got our application all snug in a Docker container, what’s the next move? How do we kick it into gear for production? And what if it’s not a solo act and relies on other containers like databases or messaging services? Oh, and let’s not forget about scaling up when the user count hits the roof, and gracefully scaling down when it’s time to chill.

To make all this happen, you require a foundation with a defined set of resources. This foundation must manage the communication between containers and adjust their numbers on the fly according to demand. This entire procedure of automating the deployment and supervision of containers is termed Container Orchestration.

The Architecture

Now that we’ve grasped the essence of Kubernetes and its functionality, it’s time to delve into its intricate architecture, like any complex system, understanding K8s requires peeling back its layers, much like dissecting the inner workings of a car to truly grasp its mechanics. Just as a driver must comprehend the nuances of an engine, steering, gearbox, braking system, etc. to navigate the roads safely, delving into K8s architecture unveils its components — the control plane, nodes, pods, and more — each playing a vital role in orchestrating the seamless operation of containerized applications. By delving into the fundamental components such as Nodes, Pods, Deployments, Services, Ingress, and Volumes, we can gain insights into how K8s streamlines the deployment, scaling, and management of applications in modern cloud-native environments. Understanding these core concepts lays the groundwork for harnessing the full potential of Kubernetes to build resilient and scalable applications.

So, buckle up as we embark on a journey to explore the fundamental components and architecture of Kubernetes ☸️

Node

A Kubernetes cluster is a collection of computing resources (nodes) that work together to run containerized applications.

A node, physical or virtual, serves as the host for K8s. It functions as a worker machine where K8s deploys containers. It consists of two main components: the Master node and Worker nodes.

Master Node

The master node a.k.a Control Plane, analogous to the driver of a car, serves as the central controller of the Kubernetes cluster. It consists of several essential components:

• Kubernetes API Server: Like the steering wheel of a car, the API server provides the interface through which commands and instructions are received and processed.
• etcd: Similar to a car’s GPS, etcd stores crucial information about the cluster’s configuration and state, helping navigate the cluster’s operations.
• Scheduler: Acts as navigator, determining the best route for executing tasks (pods) based on resource availability and requirements.
• Controller Manager: Functions as the maintenance crew, ensuring that various controllers maintain the desired cluster state, just like maintaining the car’s condition.

Worker Node

The worker node is responsible for running the applications and services within the Kubernetes cluster. It consists of four key components:

1. Kubelet: As the primary component of the worker node, the kubelet communicates with the API server to receive instructions on executing applications and services on the node.
2. Kube Proxy: Responsible for network proxying within the worker node, the Kube Proxy maintains network rules and directs traffic to the appropriate container.
3. Pods: Pods, the fundamental deployable units in Kubernetes, consist of one or more containers sharing the same network namespace and storage volumes.
4. Container Runtime: Handling the execution of containers on the worker node, the container runtime supports various options like Docker, CRI-O, and Containerd within the Kubernetes ecosystem.

Pods

A pod is the smallest thing you can use in Kubernetes. It’s like a little group of containers that work together and share the same network settings, such as IP address and port numbers.

When you need more of your application to handle increased traffic, Kubernetes can make more copies of your pod (scaled horizontally) and spread them out across the cluster. It’s important to keep pods small so they don’t waste resources. If you put too many containers in one pod, they all have to grow or shrink together, even if they don’t need to. To resolve this, pods should remain as small as possible, typically holding only a main process and tightly coupled helper containers.

Pods are regarded as temporary elements and can be generated, adjusted in scale, or terminated according to the requirements. To simplify matters significantly, you don’t have to oversee individual Pods. Instead, you can utilize workload resources to handle a group of pods. These resources employ controllers (Deployments, StatefulSets, or ReplicaSets) to ensure the correct quantity and type of pods are operational, aligning with the state designated. Read more here 👉📃

Deployment

Kubernetes deployments determine the application’s operational scale by allowing you to specify how pods should be replicated across nodes. They dictate the desired number of identical pod copies and the preferred update approach. Kubernetes monitors pod health, adjusting the pod count to maintain the desired application state. If a pod dies, the deployment will automatically re-create it.

Once your pod is deployed, the next question is how to access it. If you’re using a Deployment to manage your app, it can dynamically create and remove pods. Pods, however, aren’t reliable or long-lasting — they’re temporary. Each pod has its own IP address, but the pods running at one moment might not be the same as those running later. So, if some pods backends provide services to other pods frontends in your cluster, how do the frontends know which IP address to connect to and keep track of it? The solution to this challenge is Kubernetes Services.

Services

A Service acts as a layer of abstraction over pods, serving as the primary interface for application consumers. While pods may undergo replacement, resulting in changes to their internal names and IPs, a Service provides a consistent endpoint, typically represented by a single machine name or IP address. This endpoint remains stable even as the underlying pods change, ensuring continuity for external network interactions.

The Service abstraction facilitates this separation. Typically, the group of Pods associated with a Service is identified by a selector defined by you.
In Kubernetes, various service types facilitate directing traffic to your pods. Each type possesses unique traits and applications.

The default ClusterIP type exposes services on an internal IP, accessible only from within the cluster. NodePort exposes services on a static port on each node’s IP, enabling external access. LoadBalancer type utilizes cloud provider load balancers for external access, commonly used in cloud environments. ExternalName type redirects requests to external services. These different Service types cater to diverse networking requirements, ensuring seamless communication between components within the Kubernetes cluster and external entities.

Applying the principles outlined earlier, you can form a cluster of nodes and initiate deployments of pods onto the cluster. However, one final obstacle remains: enabling external access to your application?

Kubernetes naturally separates pods from external access as a default measure, ensuring isolation. When you aim to establish communication with a service hosted within a pod, you must initiate a communication channel. This process, known as Ingress, grants external entities access to communicate with the services encapsulated within Kubernetes pods.

Ingress

Ingress serves as a gateway that exposes HTTP and HTTPS routes from external sources to services residing within the cluster. The routing of traffic is governed by rules specified within the Ingress resource.

To use the Ingress resource, your cluster needs an ingress controller running. Ingress can be configured to provide services with external URLs, balance traffic, handle SSL/TLS termination, and support name-based virtual hosting. The Ingress controller, often employing a load balancer, is responsible for implementing these settings. However, Ingress doesn’t expose arbitrary ports or protocols. For services other than HTTP and HTTPS, options like NodePort or LoadBalancer types are typically used to enable internet access. Read more here 👉📃

Volumes

A volume in Kubernetes serves as a layer of abstraction that separates the pod from the underlying storage system, enabling data storage and access beyond the pod’s lifecycle. Containers within the same pod can share this storage space, and the node itself can access it directly. To utilize a volume, it must be mounted within a container in the pod.

As applications within a Kubernetes cluster may run on different nodes at different times, storing data in any random location within the file system is not feasible. Suppose an application writes data to a file assuming it will remain in a specific location, but the application is later moved to another node. In that case, the file won’t be accessible where expected. Hence, the local storage on each node is viewed as a transient cache for running programs, and data saved locally cannot be reliably retained.

There are various types of volumes available in Kubernetes to suit different storage requirements it keeps on updating here are a few common ones:

1. EmptyDir: A temporary volume created when a pod is assigned to a node. Data stored in EmptyDir volumes is deleted when the pod is terminated or rescheduled.
2. HostPath: Mounts a directory from the host node’s file system into the pod. HostPath volumes are suitable for situations where data needs to be shared between containers running on the same node.
3. PersistentVolumeClaim (PVC): This volume type allows pods to request storage resources dynamically from a Persistent Volume (PV) provisioned by the cluster’s storage provider. PVCs provide a way to abstract the underlying storage infrastructure from the application.
4. ConfigMap: Stores configuration data in key-value pairs that can be mounted as a volume within a pod. ConfigMap volumes are often used to inject configuration settings into containers at runtime.
5. Secret: Similar to ConfigMap, Secret volumes store sensitive data such as passwords, API tokens, or SSL certificates securely within the cluster.
6. CSI (Container Storage Interface) Volume: This type of volume allows for the integration of third-party storage solutions into Kubernetes. CSI volumes offer flexibility and compatibility with a wide range of storage systems.

That concludes the scope of this brief and somewhat dry theoretical blog. What has been outlined above is a simplified rendition of Kubernetes, yet it provides a foundational understanding to commence your exploration and experimentation. However, it’s important to note that these components represent just a fraction of Kubernetes’ vast capabilities. Depending on the specific use case, additional features and resources such as ConfigMaps, Secrets, StatefulSets, DaemonSets and more may be required to fully leverage Kubernetes’ potential. As Kubernetes continues to evolve and expand, it remains a dynamic and powerful tool for building resilient, scalable, and cloud-native applications. This overview serves as a starting point for exploring the rich ecosystem of Kubernetes, but there is much more to discover and learn 🧠

All right, all right, all right! With that, we come to the end of this blog. I hope you enjoyed this article! and found it informative and engaging. You can follow me Afaque Umer for more such articles.

I will try to bring up more Machine learning/Data science concepts and will try to break down fancy-sounding terms and concepts into simpler ones.

Thanks for reading 🙏Keep rocking🤘Keep learning 🧠 Keep Sharing 🤝

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI