Kubernetes 01 - Kubernetes Architecture and Terminology

As Kubernetes continues to dominate the container orchestration landscape, it’s crucial for DevOps engineers and IT professionals to familiarize themselves with its key concepts and terminology. In this post, we’ll break down some of the fundamental terms you’ll encounter when working with Kubernetes.

Kubernetes

Let’s start with the star of the show: Kubernetes itself. Often abbreviated as K8s (pronounced “k-eights”) or simply called “Kube,” Kubernetes is a comprehensive container orchestration system. It’s designed to automate the deployment, scaling, and management of containerized applications across clusters of hosts.

Kubectl: CLI to configure Kubernetes and manage apps

To interact with Kubernetes, you’ll frequently use kubectl (officially pronounced “cube control”). This powerful command-line interface (CLI) allows you to configure Kubernetes and manage your applications. Whether you’re deploying new apps, scaling existing ones, or troubleshooting issues, kubectl is your go-to tool for communicating with the Kubernetes API.

Node: Single server in the Kubernetes cluster

In the Kubernetes world, a node refers to a single server in your Kubernetes cluster. These can be physical machines or virtual machines, depending on your infrastructure setup. Nodes are where your containerized applications actually run.

Kubelet: The Node Agent

Each node in your Kubernetes cluster runs a component called the kubelet. This is the Kubernetes agent responsible for communication between the node and the control plane. It ensures that containers are running in a Pod and handles mounting volumes, among other tasks.

Control Plane: The Brain of the Operation

The control plane, sometimes referred to as the “master,” is a set of containers that manage the entire Kubernetes cluster. It’s responsible for maintaining the desired state of your cluster, making global decisions about the cluster, and responding to cluster events.

Key components of the control plane include:

• API Server: The front-end of the Kubernetes control plane, handling internal and external requests.
• Scheduler: Responsible for assigning new workloads to nodes.
• Controller Manager: Oversees a number of smaller controllers that handle node operations, replication, endpoints, etc.
• etcd: A distributed key-value store that stores all cluster data.

Pod: Smallest deployable unit in Kubernetes

A Pod is the smallest and most basic deployable unit in Kubernetes. It represents a single instance of a running process in your cluster. Pods can contain one or more containers, storage resources, a unique network IP, and options that govern how the container(s) should run. They are designed to be relatively ephemeral, disposable entities.

Controller: Manages the state of Pods and other objects

Controllers in Kubernetes are control loops that watch the state of your cluster, then make or request changes where needed. They try to move the current cluster state closer to the desired state. Some examples of controllers include:

• ReplicaSet: Ensures that a specified number of pod replicas are running at any given time.
• Deployment: Provides declarative updates for Pods and ReplicaSets.
• StatefulSet: Manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods.

Service: Network endpoint to connect to one or more Pods

In Kubernetes, a Service is an abstraction that defines a logical set of Pods and a policy by which to access them. Services allow applications to discover and communicate with each other without needing to be aware of the underlying Pod topology or lifecycle. They provide a stable IP address and DNS name that remain constant, even as the underlying Pods are created and destroyed. This abstraction is critical because Pods are ephemeral and can change frequently due to scaling or failures.

A primary goal of Services is to decouple applications from the underlying infrastructure, allowing them to interact without requiring changes to accommodate the dynamic nature of Pods. Services enable seamless communication by abstracting the network details of Pods and providing a consistent way to access them. This design facilitates the deployment of both cloud-native applications and legacy applications that have been containerized.

Kubernetes assigns each Pod an IP address, but these addresses can change as Pods are added or removed. This volatility poses a challenge: how do you ensure that an application can reliably communicate with another, given that their IP addresses can change? Kubernetes Services solve this by acting as a stable endpoint that clients can connect to, while the Service dynamically routes traffic to the current set of healthy Pods.

Namespace: Virtual cluster inside a physical cluster

In Kubernetes, namespaces are a way to isolate and organize groups of resources within a single cluster. They provide a scope for names and ensure that resources within different namespaces can have the same name without conflict. This is particularly useful in environments where multiple teams or projects share the same cluster, as namespaces enable them to work independently.

Namespaces are particularly beneficial in large environments with many users, teams, or projects. Here are some scenarios when you might consider using multiple namespaces:

• Multiple Teams or Projects: When different teams or projects need to operate independently within the same cluster, namespaces can help segregate resources.
• Resource Quotas: Namespaces can be used to enforce resource quotas, ensuring that one team or project doesn’t consume more than its fair share of cluster resources.
• Name Conflicts: By using namespaces, resources with the same name can exist in different namespaces without any conflict.

It’s important to note that for clusters with a small number of users, you might not need to create multiple namespaces. You can start with the default setup and expand into multiple namespaces as needed.