Kubernetes

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, networking, and lifecycle management of containerized applications across clusters of machines. Originally designed by Google based on internal experience with large-scale cluster management systems (Borg and Omega), Kubernetes was donated to the Cloud Native Computing Foundation (CNCF) in 2015 and has since become the de facto standard for running containerized workloads in production environments. It abstracts away the underlying physical or virtual infrastructure, presenting a declarative API through which operators describe the desired state of an application, while the system continuously works to reconcile the actual state of the cluster with that desired state.

Architecture

A Kubernetes cluster is composed of a control plane and a set of worker nodes. The control plane makes global decisions about the cluster and detects and responds to cluster events, while worker nodes run the actual application workloads inside containers.

Control Plane Components

The control plane consists of several cooperating processes, typically distributed across multiple machines for high availability:

• kube-apiserver: The front end of the control plane, exposing the Kubernetes REST API. All interactions with the cluster, whether from users, the command-line tool kubectl, or internal components, pass through the API server.
• etcd: A consistent and highly available key-value store used as the backing store for all cluster data, including the desired state of every object in the system.
• kube-scheduler: Watches for newly created Pods with no assigned node and selects a node for them to run on, based on resource requirements, constraints, affinity rules, and other scheduling policies.
• kube-controller-manager: Runs controller processes that regulate the state of the cluster, such as the Node Controller, Replication Controller, Endpoints Controller, and Service Account Controller.
• cloud-controller-manager: Integrates the cluster with underlying cloud provider APIs, managing resources such as load balancers, storage volumes, and node lifecycle in cloud environments.

Node Components

Every worker node runs the following components:

• kubelet: An agent that ensures containers described in PodSpecs are running and healthy on the node.
• kube-proxy: A network proxy that maintains network rules on nodes, enabling communication to Pods from inside or outside the cluster.
• Container runtime: The software responsible for running containers, such as containerd or CRI-O, accessed through the Container Runtime Interface (CRI).

Core Objects and Abstractions

Pods

The Pod is the smallest deployable unit in Kubernetes. A Pod represents one or more tightly coupled containers that share the same network namespace, storage volumes, and lifecycle. Containers within a Pod communicate over localhost and can share mounted volumes.

Workload Controllers

Kubernetes rarely manages Pods directly; instead, higher-level controllers manage Pods on the user's behalf:

• Deployment: Manages stateless application replicas, supporting declarative updates, rolling upgrades, and rollbacks.
• StatefulSet: Manages stateful applications requiring stable network identities and persistent storage across rescheduling.
• DaemonSet: Ensures a copy of a Pod runs on all, or a selected subset of, nodes in the cluster.
• Job and CronJob: Manage batch or scheduled workloads that run to completion rather than indefinitely.

Services and Networking

A Service provides a stable network endpoint that abstracts a dynamic set of Pods, typically selected via labels. Kubernetes networking follows a flat model in which every Pod receives its own IP address and can communicate with every other Pod without network address translation. Service types include:

• ClusterIP: Exposes the Service on an internal cluster IP, reachable only within the cluster.
• NodePort: Exposes the Service on a static port on each node's IP.
• LoadBalancer: Provisions an external load balancer via the cloud provider.
• Ingress: An API object managing external HTTP/HTTPS access to Services, typically including routing rules, TLS termination, and virtual hosting.

Storage

Kubernetes decouples storage from compute through the PersistentVolume (PV) and PersistentVolumeClaim (PVC) abstractions. A PersistentVolume represents a piece of storage provisioned in the cluster, while a PersistentVolumeClaim is a request for storage by a user, matched to an available PersistentVolume. The StorageClass object enables dynamic provisioning, allowing volumes to be created on demand according to defined parameters.

Configuration Objects

• ConfigMap: Stores non-confidential configuration data as key-value pairs, injectable into Pods as environment variables or mounted files.
• Secret: Stores sensitive data such as passwords, tokens, and keys, encoded and access-controlled separately from ConfigMaps.

Declarative Model and Reconciliation

Kubernetes operates on a declarative, controller-based model rather than an imperative one. Users submit manifests, typically written in YAML, describing the desired state of the system. Each controller runs a continuous reconciliation loop: it observes the current state of the cluster through the API server, compares it against the desired state, and issues actions to converge the two. This pattern, often summarized as the "control loop," makes the system self-healing: if a Pod crashes or a node fails, the relevant controller automatically creates replacement resources to restore the desired state.

Namespaces and Multi-Tenancy

Namespaces provide a mechanism for isolating groups of resources within a single cluster, enabling multiple teams or applications to share infrastructure while maintaining logical separation of names, quotas, and access policies. Resource Quotas and Limit Ranges can be applied per namespace to constrain the aggregate and per-object consumption of CPU, memory, and other resources.

Scheduling and Resource Management

The scheduler assigns Pods to nodes using a two-phase process: filtering, which eliminates nodes that cannot satisfy a Pod's requirements, and scoring, which ranks the remaining feasible nodes to select the most suitable one. Scheduling decisions are influenced by:

• Resource requests and limits: CPU and memory values that inform both scheduling decisions and runtime enforcement.
• Node affinity and anti-affinity: Rules that attract or repel Pods relative to node labels.
• Pod affinity and anti-affinity: Rules governing Pod placement relative to other Pods.
• Taints and tolerations: A mechanism allowing nodes to repel Pods unless those Pods explicitly tolerate the node's taint.

Extensibility

Kubernetes is designed as an extensible platform rather than a fixed system. Extension mechanisms include:

• Custom Resource Definitions (CRDs): Allow users to define new object types recognized by the API server.
• Operators: Combine CRDs with custom controllers to encode operational knowledge for managing complex, stateful applications.
• Admission Controllers and Webhooks: Intercept requests to the API server to validate or mutate objects before persistence.
• Container Storage Interface (CSI) and Container Network Interface (CNI): Standardized interfaces allowing third-party storage and networking providers to integrate with the platform.

Example Manifests

apiVersion: apps/v1
kind: Deployment
metadata:
  name: codartium-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: codartium-app
  template:
    metadata:
      labels:
        app: codartium-app
    spec:
      containers:
        - name: codartium-app
          image: codartium/app:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

kubectl apply -f deployment.yaml
kubectl get pods -l app=codartium-app
kubectl rollout status deployment/codartium-app

Common Interaction Tooling

The primary command-line interface for interacting with a cluster is kubectl, which communicates with the kube-apiserver to create, inspect, update, and delete resources. Higher-level packaging and templating of Kubernetes manifests is commonly handled by tools such as Helm, which organizes related manifests into versioned, parameterized "charts."