Kubernetes Architecture

Kubernetes is an architecture that offers a loosely coupled mechanism for service discovery across a cluster. A Kubernetes cluster has one or more control planes and one or more compute nodes.

The Kubernetes Cluster

A Kubernetes cluster consists of two main parts:?

the control plane and the compute nodes.?

The control plane manages the overall cluster, handling tasks such as scheduling, scaling, and updating applications.?

The compute nodes, on the other hand, are the machines (either physical servers or virtual machines) where the applications actually run.

The Foundation: Nodes and Pods

The core building blocks of Kubernetes are Nodes and Pods.?

Nodes are the worker bees – physical or virtual machines – that serve as the execution environment for containerized applications. Imagine each node as a dedicated server in a data center.

Pods, on the other hand, are the fundamental units of deployment in Kubernetes. Think of them as self-contained units housing one or more containers, along with the necessary storage resources. Each pod has its own unique IP address, allowing it to communicate with other pods and external services.

The Control Plane: The Brain of the Operation

The control plane serves as the central nervous system of a Kubernetes cluster. It's a collection of services that manage the overall health and state of the cluster, issuing commands and ensuring everything runs smoothly. Here's a closer look at the key components within the control plane:

1. kube-apiserver: The API server is the communication hub for the cluster. It handles all RESTful API calls and coordinates interactions between various components.
2. etcd: This is a key-value store that holds all the cluster data. It ensures data consistency and availability. Information in etcd is stored in a format that's easy to read and write, often in YAML (Yet Another Markup Language).
3. kube-scheduler: The scheduler assigns newly created pods to nodes based on resource requirements, policies, and other constraints like geographical location and workload interference.
4. kube-controller-manager: This component runs several controllers that handle routine tasks. These controllers include Replication Controller, Node Controller, Endpoints Controller, Service Account and Token Controllers etc.
5. cloud-controller-manager: In clusters that run on cloud infrastructure, this component integrates with the cloud provider’s API to manage cloud-specific resources. These controllers include Node Controller, Route Controller, Service Controller etc.

Node Architecture

Nodes in a Kubernetes cluster have several components that work together to run and manage containers:

1. kubelet: This agent runs on each node and ensures containers are running as specified in the pod specifications.
2. kube-proxy: A network proxy on each node that maintains network nodes which allows for the communication from Pods to network sessions, whether inside or outside the cluster, using operating system (OS) packet filtering if available.
3. Container Runtime: This is the software that runs the containers. While Docker is the most well-known runtime, Kubernetes supports any runtime that conforms to the Kubernetes Container Runtime Interface (CRI).

Beyond the Core: Additional Kubernetes Infrastructure Components

While Pods, Nodes, and the Control Plane form the foundation of Kubernetes, several other infrastructure components play crucial roles in managing containerized applications effectively. Here's a breakdown of some key elements:

• Deployments: Imagine you're building a large house (your application). Pods are like individual rooms, but you need a plan for the entire structure. Deployments act as the blueprint, defining the desired state of your application – how many pods (rooms) you need and how they should be configured. Deployments manage the rollout process, ensuring a smooth transition from old versions to new ones with minimal downtime.
• ReplicaSets: These ensure high availability for your application. Think of them as backup generators for your house. ReplicaSets guarantee a specific number of identical pod replicas are always running, even if individual pods malfunction. If a pod encounters an issue, a replica ensures your application keeps functioning uninterrupted.
• Cluster DNS: Every house needs an address for deliveries. Similarly, pods within a Kubernetes cluster need a way to discover each other. Cluster DNS provides a mechanism for assigning internal DNS names to pods and services, allowing them to communicate seamlessly using these names.

In Kubernetes, DNS names are assigned to Pods and Services for communication by name instead of IP address. The default domain name used for DNS resolution within the cluster is cluster.local, which can be customized if required.

For instance, if a Service named my-service is running in the my-namespace namespace, then the corresponding DNS name would be:

my-service.my-namespace.svc.cluster.local        

For example, if a Pod with IP address 10.1.2.3 is running in the my-namespace namespace, its DNS name would be:

10-1-2-3.my-namespace.pod.cluster.local        

When Pods and Services are in the same namespace, you can use the service name instead of the fully qualified domain name (FQDN) to access Services through queries.

When a Pod and a Service are in different namespaces in Kubernetes, you need to specify both the Service name and the namespace to access the Service from the Pod.

some other:

• Services: These act as an abstraction layer for pods, providing a stable network identity for applications. Imagine having a doorbell for your house – a service provides a single point of access for external users to interact with your application, regardless of which pods are currently running the application logic.
• Namespaces: These are virtual clusters within a larger Kubernetes cluster, allowing you to isolate resources and configurations for different projects or teams. Think of them as separate apartments within a large building. Namespaces provide a way to organize and manage your containerized applications efficiently.
• Secrets and ConfigMaps: These are secure ways to store sensitive information like passwords and configuration data that your pods need to run. Imagine a secure locker in your house for important documents. Secrets and ConfigMaps provide a mechanism to manage this sensitive information securely without hardcoding it within your container images.

Follow Neeraj Pandey ?? For More

Stay Tuned ??????