Today, I attended a K8SUG meetup (focused on GitOps, FluxCD, and more), and realized my understanding of Kubernetes was limited to managing containerized microservices. Therefore, I’ve decided to invest some time in learning Kubernetes, starting with getting a Quick Start running.
Kubernetes Architecture Diagram
Kubernetes Concepts
Node, Pod, and Control Plane
A set of working machines, called nodes (in K8s, these are the machines, or servers, running containerized applications), run containerized applications. Every cluster has at least one working node (worker node).
Worker nodes host Pods (representing a group of running containers on your cluster), with Pods serving as the smallest deployable units of computing that can be created and managed in Kubernetes. The Control plane (or the control plane) manages the worker nodes and the Pods in the cluster. In production environments, the control plane typically runs across multiple computers, with a cluster usually running multiple nodes to provide fault tolerance and high availability.
A properly functioning Kubernetes cluster looks like this:
Understanding Node
Kubernetes executes your workloads (applications running on Kubernetes) by placing containers into Pods running on Nodes. A Node can be a virtual or physical machine. Each node contains the services necessary to run Pods.
Typically, there are several Nodes in a cluster; however, in a learning environment or resource-constrained setting, your cluster might consist of just one Node.
node-components on a node include kubelet (an agent that ensures containers are running in Pods on the node), container runtimes (software responsible for running containers), and kube-proxy (a network proxy for the node).
Understanding Pod
When we talk about Pods in Kubernetes, think of them as a collection of containers, like a “box” containing multiple smaller containers. These containers could be different parts of your application, such as the frontend, backend, or database. Pods provide a place for containers to “live,” allowing them to work together and share resources.
In practical terms, you can think of a Pod as a car carrying passengers, with each container being a passenger. These passengers may be different members of a team who need to reach a destination together. The Pod acts as the vehicle, providing space for the containers to live and allowing them to share resources like air conditioning and audio systems.
Furthermore, a Pod can be seen as a small working unit, like a project team within an organization. Each member has their own task, but they need to collaborate to complete the project. The Pod acts as this team, with containers working together inside to fulfill the functions of the application.
In summary, understanding Pods in Kubernetes means understanding that they are a place where containers live and work together, providing an environment for resource sharing and collaboration, enabling efficient operation and management of applications.
Understanding Control Plane
When we talk about the Control Plane in Kubernetes, think of it as a manager or commander responsible for overseeing the operation and behavior of the entire Kubernetes cluster. This control plane is like a command center, responsible for coordinating and managing various activities within the cluster.
Imagine you’re playing a large-scale game, and the Control Plane is like the “game administrator” within it. They monitor all activities in the game, ensuring that everything is running according to the rules. If a player needs resources or there’s a problem to solve, the administrator intervenes and takes action.
In Kubernetes, the Control Plane serves a similar role to this game administrator. It consists of multiple components, such as the API Server, Scheduler, Controller Manager, and etcd. These components work together to monitor and manage various resources in the cluster, such as Pods, Services, and Volumes.
Therefore, understanding the Control Plane in Kubernetes means understanding that it is the manager of the cluster, responsible for supervising and coordinating various activities within the cluster, ensuring everything runs smoothly.
ReplicaSet, Deployment, and Service
Understanding ReplicaSet
When you start using Kubernetes (often abbreviated as K8s), you’ll encounter something called ReplicaSet. ReplicaSet functions somewhat like creating backups for your applications. You can tell ReplicaSet how many replicas (copies) of your application you want to run, and it ensures that many replicas are always running, even if some encounter issues and need to be automatically repaired. For example, if you tell ReplicaSet you want three replicas of an application, it will ensure there are always three running. If one fails, it automatically starts a new one to maintain the count at three.
It’s like having a spare tire. If one tire goes flat, you can replace it with the spare, and the vehicle can keep moving. In the Kubernetes world, ReplicaSet serves as this spare tire.
Using ReplicaSet
When managing your applications with Kubernetes, you may want to ensure that your applications are always available, even in case of failures. This is where ReplicaSet comes in handy.
Imagine you have an online store with thousands of users shopping every day. Your website is managed by Kubernetes, and ReplicaSet is one of the tools Kubernetes uses to ensure your website is always online.
You tell ReplicaSet you want three replicas (i.e., three identical websites) to be running. This way, if one server encounters an issue, the other two can continue serving users. If a user is using the server that has an issue, Kubernetes automatically redirects them to a functioning server, ensuring they are not affected.
Therefore, ReplicaSet’s primary use case is to ensure your applications are always online and capable of automatically recovering from failures to maintain system stability and availability.
Understanding Deployment
When managing your applications in Kubernetes, you’ll often hear about something called Deployment. Deployment functions like managing a team.
Imagine you have a basketball team, and you want to ensure you always have enough players for every game. Additionally, if a player gets injured or sick, you want to be able to easily replace them.
Deployment acts as your team manager. You tell Deployment how many players (i.e., replicas of your application) you want for each game, and it ensures there are always that many players available. If a player gets injured, it automatically calls in a substitute. Moreover, Deployment can help you with other tasks, such as updating application versions, ensuring all players are on the same version.
Therefore, the main role of Deployment is to ensure your applications remain in the desired state and to facilitate easy management and updates of your applications.
Using Deployment
Deployment has two main use cases:
-
Application Deployment and Updates: Imagine you have an online store website, and you want to deploy new versions easily while ensuring website stability. Deployment can help with this. You tell Deployment how many replicas of the new version of the application you want to run, and it automatically starts new replicas. It ensures the old version of the application continues running until the new version is successfully started, ensuring website stability. Once the new version is running successfully, Deployment gradually replaces the old version, ensuring a smooth transition.
-
Scaling Applications: Suppose your online store is having a promotion, and you expect more users to visit your website. You can modify the Deployment configuration to tell Kubernetes to start more replicas to handle increased traffic. Once the promotion ends, you can reduce the number of replicas to save resources and costs. Deployment can automate these operations without manual management of each replica’s start and stop.
Deployment simplifies deployment, updates, and management of applications, making them more straightforward and reliable.
Understanding Service
When managing your applications in Kubernetes, you may encounter something called Service. Service acts as the facade of your application.
Imagine you have a popular café with many customers coming in for coffee every day. To make it convenient for customers, you set up a service counter at the entrance where customers can place orders, pay, and then have their coffee delivered to their seats.
In Kubernetes, Service is similar to this service counter. Your application may consist of multiple replicas, and the IP addresses of these replicas may change constantly. Service acts as the facade of your application, with a fixed IP address and a stable domain name. Customers (other applications) only need to know this IP address or domain name to access your application, without needing to know the specific replica providing the service.
Additionally, Service can distribute traffic to different replicas based on your application’s requirements, ensuring each replica can handle requests evenly, thereby improving the application’s stability and reliability.
Therefore, Service plays a crucial role in Kubernetes, providing a stable entry point for your application and helping manage traffic to ensure the application’s availability.
Service has several main functionalities in Kubernetes:
-
Stable Entry Point: Service provides a fixed IP address and a stable domain name as the entry point for your application. Regardless of changes in the background replicas, customers (other applications) only need to know the Service’s IP address or domain name to access your application without worrying about which replica is serving them.
-
Load Balancing: When your application consists of multiple replicas, Service can evenly distribute traffic among these replicas to ensure each replica can handle incoming requests. This improves the performance and reliability of the application.
-
Service Discovery: Service helps other applications discover and connect to your application. By querying Kubernetes’ DNS or accessing the Service’s IP address through environment variables, other applications can easily find and communicate with your application.
-
Internal Communication: Different components within the same Kubernetes cluster often need to communicate, and these components may consist of different replicas. Service facilitates communication between these components over the internal network without exposing them to the public network.
Service provides stable entry points, load balancing, service discovery, and internal communication, helping you build and manage reliable distributed applications.
Service, Deployment, and ReplicaSet Working Together
Imagine you’re the owner of an online store with a warehouse stocked with various products. Your store is managed using Kubernetes, and your products are your applications.
First, you need Deployment to manage your products. Deployment acts as your warehouse manager, responsible for managing the quantity of products in stock. You tell Deployment how many products (replicas) you want in stock, and it automatically maintains that quantity, just like a warehouse manager ensuring stock levels. If a product goes out of stock, it automatically replenishes it.
Next, you need ReplicaSet to help Deployment achieve this functionality. ReplicaSet acts as an assistant to Deployment, helping ensure there are enough copies of products in stock. It monitors the stock levels in the warehouse, automatically replenishing products if it detects any shortages, ensuring the stock levels meet your requirements.
Finally, you need Service to allow customers to purchase products. Service acts as the front desk of your store, accepting customer orders and passing them to the warehouse manager. Customers only need to know the front desk’s address to buy the products they want, without needing to directly contact the warehouse manager. Service acts as the bridge connecting customers and the warehouse manager, ensuring customers can purchase products smoothly.
In summary, Service, Deployment, and ReplicaSet work together in a mutually supportive and collaborative manner, building a stable and reliable application management system.
