Skip to main content

Kubernetes

Kubernetes has become the de facto standard for container orchestration, providing a declarative platform to deploy, scale, and operate application containers across clusters of hosts. It abstracts the underlying infrastructure and gives engineering teams a common control plane for workload scheduling, service discovery, and automated operations.

For modern DevOps and platform engineering, Kubernetes is not merely a tool—it is the foundation upon which internal developer platforms, GitOps workflows, and self-healing production systems are built. This section of DevOpsDevPro provides a structured guide to Kubernetes architecture, core objects, deployment patterns, security practices, and production operations, connecting container orchestration to the broader DevOps ecosystem.

What Is Kubernetes?​

Before Kubernetes, engineering teams managed containers manually or with basic scripting. Scaling required manual intervention, deployments were complex and error-prone, and maintaining application health across many hosts was operationally heavy.

Kubernetes solves these challenges by providing:

  • Automated scheduling: Pods are placed onto nodes based on resource requirements and constraints.
  • Self-healing: Failed containers are restarted, unresponsive nodes are drained, and desired state is continuously maintained.
  • Declarative deployment: Desired application state is defined in YAML manifests, and Kubernetes controllers reconcile the cluster to match that state.
  • Horizontal scaling: Workloads can be scaled out or in automatically based on CPU, memory, or custom metrics.
  • Service discovery and load balancing: Services provide stable networking endpoints and distribute traffic to healthy Pods.

Kubernetes shifts operations from imperative commands to a desired-state model, where engineers specify what should run, not how to run it.

Kubernetes Architecture Overview​

A Kubernetes cluster consists of a control plane that manages the cluster state and a set of worker nodes that run application workloads. The control plane makes global decisions, while node components execute container lifecycle operations.

Kubernetes Cluster
┌────────────────────┐
│   Control Plane    │
│                    │
│  API Server        │
│  etcd              │
│  Scheduler         │
│  Controller Manager│
└────────────────────┘
          │
          ▼
┌────────────────────┐
│   Worker Nodes     │
│                    │
│  kubelet           │
│  Container Runtime │
│  kube-proxy        │
└────────────────────┘
          │
          ▼
┌────────────────────┐
│   Containers &     │
│   Applications     │
└────────────────────┘

Control Plane Components​

API Server​

The API server is the front-end to the Kubernetes control plane. All internal and external interactions—kubectl commands, controller reconciliations, scheduler decisions—go through the API server. It validates and processes RESTful requests, updating etcd accordingly.

etcd​

etcd is a distributed key-value store that holds the entire cluster configuration and state. Every object—Pods, Services, Deployments—is persisted in etcd. Backup and recovery of etcd are critical operational tasks for cluster reliability.

Scheduler​

The scheduler watches for newly created Pods that have no node assigned and selects an optimal node for them to run on. It considers resource requirements, affinity and anti-affinity rules, taints and tolerations, and other scheduling constraints.

Controller Manager​

The controller manager runs a set of controllers that continuously reconcile the actual cluster state toward the desired state. Examples include the Deployment controller, ReplicaSet controller, and Node controller. Each controller watches the API server for changes and takes action to converge on the declared configuration.

Cloud Controller Manager​

This optional component integrates Kubernetes with cloud provider APIs. It manages cloud-specific resources like load balancers, persistent storage volumes, and node lifecycles, allowing the core Kubernetes components to remain cloud-agnostic.

Node Components​

kubelet​

The kubelet is the agent running on every node. It receives Pod specifications from the API server and ensures the containers described in those Pods are running and healthy. The kubelet reports node and Pod status back to the control plane.

Container Runtime​

The container runtime is the software responsible for running containers. Kubernetes supports any runtime conforming to the Container Runtime Interface (CRI), such as containerd or CRI-O.

kube-proxy​

kube-proxy maintains network rules on each node, enabling network communication to Pods through Services. It handles the forwarding of traffic to the correct backend Pods based on Service definitions.

Kubernetes Core Objects​

Pods​

The Pod is the smallest deployable unit in Kubernetes. A Pod wraps one or more tightly coupled containers, sharing network namespace and storage volumes. Pods are ephemeral and are typically managed by higher-level controllers rather than created directly.

Deployments​

Deployments manage stateless application workloads. They define a desired number of Pod replicas and provide declarative updates through rolling updates. If a Pod fails, the Deployment controller ensures a replacement is created.

StatefulSets​

StatefulSets are designed for stateful applications that require stable network identities and persistent storage. Each Pod in a StatefulSet maintains a consistent hostname and can be associated with dedicated PersistentVolumes.

DaemonSets​

DaemonSets ensure that a copy of a specific Pod runs on every node (or a subset of nodes). Common use cases include log collectors, monitoring agents, and node-level security daemons.

Jobs and CronJobs​

Jobs run a Pod to completion a specified number of times, suitable for batch processing. CronJobs extend Jobs with time-based scheduling, similar to Unix cron.

Kubernetes Networking​

Pod Networking​

Kubernetes imposes a flat, routable network model: every Pod gets its own IP address, and Pods on any node can communicate directly without network address translation (NAT). This simplifies service discovery and application communication.

Services​

Services provide stable networking endpoints for a set of Pods. Three main types exist:

  • ClusterIP: Exposes the service on an internal cluster IP; reachable only within the cluster.
  • NodePort: Opens a specific port on every node's IP, forwarding traffic to the service.
  • LoadBalancer: Provisions an external cloud load balancer and maps it to the service.

Ingress​

Ingress resources manage external HTTP and HTTPS access to services, providing host-based and path-based routing. Ingress controllers (such as NGINX Ingress or Traefik) implement the defined rules.

Service Mesh​

Service meshes like Istio and Linkerd add a transparent infrastructure layer for traffic management, security (mTLS), and observability. They operate at the application layer without requiring code changes, providing fine-grained control over service-to-service communication.

Kubernetes Storage​

Volumes​

Ephemeral volumes share the lifetime of a Pod and are used for temporary data sharing between containers.

PersistentVolumes (PV)​

PVs represent a piece of storage in the cluster that has been provisioned by an administrator or dynamically via StorageClasses. They have a lifecycle independent of any individual Pod.

PersistentVolumeClaims (PVC)​

A PVC is a request for storage by a user. It consumes PV resources, binding to an available PV that matches the claim's requirements (size, access mode).

StorageClass​

StorageClasses enable dynamic provisioning of persistent volumes. They define the provisioner, parameters, and reclaim policy, allowing applications to request storage on-demand without manual administrator intervention.

Kubernetes Application Configuration​

ConfigMaps​

ConfigMaps decouple non-sensitive configuration from Pod specifications. Configuration data is stored in key-value pairs and can be mounted as files or exposed as environment variables.

Secrets​

Secrets hold sensitive information such as passwords and tokens. While Kubernetes Secrets offer base64 encoding and limited access control, for stronger security, many teams integrate external secret managers (HashiCorp Vault, AWS Secrets Manager) and use tools like External Secrets Operator to sync secrets into the cluster.

Kubernetes Deployment Lifecycle​

The lifecycle of a Kubernetes application proceeds through several stages:

Container Image
      ↓
Manifest Definition
      ↓
Deployment Creation
      ↓
   Pod Scheduling
      ↓
  Service Exposure
      ↓
    Monitoring
      ↓
Scaling and Updates
  1. Container Image: A container image is built and pushed to a registry.
  2. Manifest Definition: Kubernetes YAML (Deployment, Service, ConfigMap) is written to define the desired state.
  3. Deployment Creation: The manifest is applied, and the Deployment controller creates a ReplicaSet.
  4. Pod Scheduling: The scheduler assigns Pods to appropriate worker nodes.
  5. Service Exposure: A Service is created to provide stable access, and optionally an Ingress routes external traffic.
  6. Monitoring: Observability tooling collects metrics, logs, and traces from running Pods.
  7. Scaling and Updates: Based on load or new image versions, deployments are scaled or updated using rolling update strategies.

Kubernetes Deployment Strategies​

Rolling Updates​

The default Kubernetes strategy. Pods are replaced gradually, with new Pods becoming ready before old ones are terminated. This provides zero-downtime updates but can lead to mixed versions serving traffic temporarily.

Blue-Green Deployment​

Two complete environments are maintained. The new version is deployed to the "green" environment while the "blue" environment serves production traffic. A Service selector switch moves traffic instantly. Rollback is equally fast by switching back.

Canary Deployment​

The new version is deployed alongside the old version, but only a fraction of traffic is routed to it initially. Traffic is increased gradually while monitoring error rates and latency. This limits the blast radius of a bad release.

Progressive Delivery​

Progressive delivery combines canary deployments with automated metric analysis. Tools like Argo Rollouts or Flagger watch Prometheus metrics during a canary deployment and automatically promote or roll back the release based on defined success criteria.

Kubernetes Package Management​

Helm​

Helm is the package manager for Kubernetes. It bundles related Kubernetes manifests into charts—reusable, versioned templates parameterized via values files. Helm manages the full lifecycle of a release: installation, upgrade, rollback, and deletion. Charts reduce duplication and enable organizations to standardize application deployment across teams.

Kubernetes GitOps​

GitOps applies DevOps best practices to Kubernetes operations by using a Git repository as the single source of truth for cluster desired state. Declarative manifests are stored in Git. A GitOps operator (such as Argo CD or Flux) running inside the cluster continuously monitors the repository and reconciles the live cluster state with the desired state.

Git Repository (desired state)
        ↓
  GitOps Controller
        ↓
 Kubernetes Cluster (live state)

This model provides audit trails, change traceability, and fast recovery from failures by simply reverting a Git commit.

Kubernetes Security​

Production Kubernetes requires a multi-layered security posture:

Authentication and Authorization​

Kubernetes supports multiple authentication methods and implements Role-Based Access Control (RBAC) to restrict API operations. Service accounts provide identities for Pods, and each workload should be assigned the minimum permissions necessary.

Network Security​

Network Policies control traffic flow between Pods and namespaces. They define ingress and egress rules, enabling micro-segmentation and reducing lateral movement if a service is compromised.

Image Security​

Container images should be scanned for vulnerabilities before deployment and sourced from trusted registries. Admission controllers can enforce that only signed or scanned images run in the cluster.

Secrets Management​

Sensitive data should not be stored in plaintext Kubernetes Secrets alone. Integrate external secrets management systems, encrypt secrets at rest in etcd, and rotate credentials regularly.

Kubernetes Observability​

Metrics​

Prometheus scrapes Pod and cluster metrics, which Grafana dashboards visualize. Metrics provide insight into resource usage, request rates, error rates, and latency—the foundational data for SLO monitoring.

Logging​

Centralized logging with tools like Fluent Bit, Loki, or Elasticsearch aggregates logs from all containers. Structured logging simplifies searching and correlation during incidents.

Tracing​

Distributed tracing (OpenTelemetry, Jaeger) tracks a request across microservices, helping identify latency bottlenecks and pinpoint failures in complex call chains.

Kubernetes observability feeds directly into SRE practices, providing the data needed to define SLIs, set SLOs, and trigger alerts that support error budgets.

Kubernetes and DevOps Integration​

CI/CD​

Automated pipelines build container images and update Kubernetes manifests with new image tags. Integration with GitOps controllers automates deployments, while progressive delivery techniques reduce risk. See the CI/CD section.

Infrastructure as Code​

The underlying Kubernetes cluster—nodes, networking, IAM roles—is provisioned and managed with IaC tools like Terraform. Application-level configuration is then layered on top. See the IaC section.

Operations and SRE​

Kubernetes observability data informs incident response and reliability engineering. SLOs, error budgets, and automated runbooks help operate production clusters with discipline. See the Operations section.

Kubernetes Learning Path​

A structured path to build Kubernetes expertise:

Containers Fundamentals
        ↓
 Kubernetes Architecture
        ↓
     Core Objects
        ↓
 Networking and Storage
        ↓
 Application Deployment
        ↓
        Helm
        ↓
       GitOps
        ↓
      Security
        ↓
 Production Operations

Common Kubernetes Mistakes​

Learning Kubernetes Without Containers​

Docker and container fundamentals are prerequisites. Without understanding images, registries, and runtime behavior, troubleshooting Kubernetes becomes guesswork.

Treating Kubernetes as a Simple Deployment Tool​

Kubernetes is a full application platform. Using it as a raw deployment target without leveraging its scheduling, scaling, and service discovery capabilities misses the value.

Ignoring Networking​

Pod CIDR conflicts, Service types, and Ingress behavior require a solid networking foundation. Many production incidents trace back to misconfigured networking.

Running Production Workloads Without Observability​

Deploying applications without metrics, logs, and alerts leaves teams blind to performance issues and failures. Observability must be part of the initial deployment.

Overcomplicating Early Designs​

Begin with simple Deployments and Services. Adopt service meshes, complex schedulers, and multi-cluster topologies only when the operational need is clear.

Kubernetes Tools Landscape​

Container Runtime​

  • containerd
  • CRI-O

Kubernetes Distributions​

  • Amazon EKS
  • Azure AKS
  • Google GKE
  • Red Hat OpenShift

Package Management​

  • Helm
  • Kustomize

GitOps​

  • Argo CD
  • Flux

Observability​

  • Prometheus
  • Grafana
  • OpenTelemetry

Kubernetes is not just a container scheduler; it is the foundation for building scalable, automated, and reliable cloud-native platforms. Successful adoption requires combining architecture knowledge, automation, security, observability, and operational discipline. The articles in this section provide practical, production-oriented guidance to help you master Kubernetes and integrate it into your DevOps practices.