What is Kubernetes (K8s): A Comprehensive Guide

Running one container on a server is straightforward. The difficulty begins when an application grows into several services, runs across multiple machines, receives unpredictable traffic, and needs updates without extended downtime.

That is the problem Kubernetes is designed to solve. While working with containerised applications, I have found that Kubernetes becomes easier to understand once you stop viewing it as a collection of YAML files and instead see it as a system that continuously compares what you requested with what is actually running.

This guide explains Kubernetes from that perspective. We’ll cover its architecture, Pods, Deployments, ReplicaSets, Services, storage, configuration, networking, and kubectl, followed by a practical local deployment using kind.

What Is Kubernetes?

Kubernetes, commonly shortened to K8s, is an open-source platform for deploying, scaling, and managing containerised applications.

It groups computing machines into a cluster and provides APIs for defining how application workloads should run. Kubernetes then schedules containers, monitors their state, replaces failed instances, manages updates, and connects application components through its networking abstractions.

The name K8s comes from replacing the eight letters between the “K” and “s” in Kubernetes with the number 8.

Why Do Applications Need Kubernetes?

Containers package an application with its runtime and dependencies. They make applications more portable and consistent, but containers alone do not answer operational questions such as:

• Which server should run each container?
• What happens when a server fails?
• How are several instances kept running?
• How does traffic reach healthy instances?
• How is a new version released gradually?
• How are configuration and credentials provided?
• How does an application obtain persistent storage?
• How should capacity change when traffic increases?

Teams can build custom scripts for these tasks, but maintaining them becomes difficult as the number of applications, containers, and servers grows.

Kubernetes provides a common control system for solving these problems.

How Kubernetes Works: Desired State and Reconciliation

Kubernetes follows a declarative model. Instead of writing a script containing every action required to deploy an application, you describe the desired outcome.

For example, you can declare:

Run three instances of this application using this container image.

Kubernetes stores that desired state through its API. Controllers then compare it with the current cluster state.

If only two instances are running, Kubernetes creates another. If four exist, it removes one. If a Pod fails, a controller creates a replacement.

This continuous process is called reconciliation.

The important point is that Kubernetes does not merely execute a deployment once. It keeps working to maintain the requested state.

Why Is Kubernetes Useful?

1. Automated Scheduling

Kubernetes decides which worker node should run a new Pod based on available resources, constraints, affinity rules, taints, tolerations, and scheduling policies.

2. Self-Healing Workloads

Kubernetes can restart failed containers, replace failed Pods, and move workloads away from unavailable nodes.

This does not mean Kubernetes can repair application code or recover corrupted data. It restores the declared workload state.

3. Horizontal Scaling

The number of Pod replicas can be changed manually or automatically. A HorizontalPodAutoscaler can adjust replica counts using supported metrics.

Automatic scaling requires metrics and correctly configured resource requests. It is not enabled simply because an application runs on Kubernetes.

4. Controlled Rollouts and Rollbacks

Deployments can gradually replace old Pods with new ones. If a release is unsuccessful, the Deployment can be rolled back to a previous revision.

5. Service Discovery

Services and cluster DNS give applications stable names for reaching groups of Pods, even as individual Pod IP addresses change.

6. Storage Orchestration

Kubernetes provides abstractions for requesting and attaching persistent storage. The actual storage may come from a cloud provider, network storage system, or local infrastructure.

7. Portable APIs

The Kubernetes API remains broadly consistent across supported cloud providers and on-premises environments.

That does not make every workload automatically portable. Storage, load balancers, identity systems, networking, and managed services can still be provider-specific.

8. Extensible Ecosystem

Kubernetes can be extended through custom resources, operators, controllers, admission policies, and external tools for deployment, security, observability, networking, and storage.

Kubernetes Architecture

A Kubernetes cluster consists of a control plane and one or more worker nodes.

Kubernetes Cluster
├── Control Plane
│   ├── API Server
│   ├── etcd
│   ├── Scheduler
│   └── Controller Manager
└── Worker Nodes
    ├── kubelet
    ├── Container Runtime
    ├── Network Components
    └── Pods

In a production cluster, control-plane components and worker capacity are commonly distributed across multiple machines or availability zones.

Control-Plane Components

The control plane manages the cluster and makes decisions about workloads.

kube-apiserver

The API server is the entry point to the Kubernetes control plane.

Commands and components interact with the cluster through this API. The API server:

• Authenticates requests
• Checks authorisation
• Runs admission controls
• Validates resource definitions
• Reads and writes cluster state
• Exposes Kubernetes API objects

When you run kubectl apply, the command sends a request to the API server.

etcd

etcd is a consistent, highly available key-value store used for Kubernetes API data.

It stores information about resources such as Deployments, Pods, Services, ConfigMaps, and Secrets. Direct access to etcd is normally restricted to the API server and cluster administrators.

Backing up etcd is essential in self-managed clusters because losing it can mean losing the cluster’s stored state.

kube-scheduler

The scheduler finds Pods that have not yet been assigned to a node and selects suitable nodes for them.

It considers factors such as:

• CPU and memory requests
• Node selectors
• Affinity and anti-affinity rules
• Taints and tolerations
• Topology constraints
• Available capacity

The scheduler chooses a node; it does not start the container itself.

kube-controller-manager

The controller manager runs several Kubernetes control loops.

Controllers watch resources through the API server and make changes that move the current state towards the desired state.

Examples include:

• Deployment controller
• ReplicaSet controller
• Node controller
• Job controller
• ServiceAccount controller

cloud-controller-manager

The cloud controller manager connects Kubernetes with supported cloud-provider APIs.

It can help manage:

• Cloud load balancers
• Node information
• Routes
• Persistent storage integrations

It is optional and is mainly relevant when the cluster runs with a supported cloud-provider integration.

Worker-Node Components

Worker nodes run the application workloads.

kubelet

The kubelet is an agent that runs on each node. It watches the Pods assigned to its node and works with the container runtime to ensure their containers are running.

It also reports node and Pod status back to the API server.

Container Runtime

The container runtime downloads images and starts or stops containers.

Modern Kubernetes clusters use runtimes that implement the Container Runtime Interface, such as:

• containerd
• CRI-O

Kubernetes removed the built-in Docker Engine integration called dockershim. Container images built with Docker still work because they follow standard container-image formats.

Network Implementation

The cluster needs networking that satisfies the Kubernetes network model. This is commonly implemented through a Container Network Interface plugin.

Depending on the cluster, networking components may provide:

• Pod IP addresses
• Pod-to-Pod connectivity
• Network policies
• Service routing
• Encryption
• Observability

Some clusters use kube-proxy to implement part of Service networking, while certain network plugins provide their own replacement.

What Is a Pod in Kubernetes?

A Pod is the smallest deployable computing unit in Kubernetes. It contains one or more containers that are scheduled and run together.

Containers in the same Pod share:

• A network namespace
• One Pod IP address
• A port space
• Attached volumes
• A common lifecycle

Most Pods contain one main application container. Additional containers should be placed in the same Pod only when they are tightly coupled and need to share networking, storage, or lifecycle.

Key Characteristics of Pods

Shared Networking

Containers inside a Pod communicate using localhost. Because they share the same network namespace, two containers in one Pod cannot bind to the same port.

Pods normally receive their own cluster IP addresses. Pod-to-Pod communication depends on the cluster’s networking implementation and network policies.

A Service is not technically required for one Pod to reach another Pod IP, but Pod IPs are temporary. Services provide the stable endpoint applications usually need.

Shared Storage

Volumes can be mounted into multiple containers in the same Pod.

For example, one container could write generated files to a volume while another processes or serves those files.

Ephemeral Identity

Pods are replaceable. When a controller replaces a failed Pod, the new Pod receives a new identity and usually a new IP address.

Applications should not treat an individual Pod as permanent.

Scheduling as One Unit

All containers in a Pod are scheduled to the same node. You cannot scale the containers inside one Pod independently.

If two components need different replica counts or resource scaling, they usually belong in separate Pods.

Init and Sidecar Containers

Init containers run before the application containers and can prepare configuration, wait for dependencies, or initialise data.

Sidecar containers run alongside the primary application container and can provide supporting behaviour. Kubernetes also supports sidecar containers through its init-container model for lifecycle-aware sidecars.

Should You Create Pods Directly?

You can create a Pod directly, but this is uncommon for long-running applications.

A direct Pod is not automatically replaced if it is manually deleted. Production workloads are usually managed through higher-level controllers such as:

• Deployment
• StatefulSet
• DaemonSet
• Job
• CronJob

These resources create and maintain Pods on your behalf.

Kubernetes Workload Controllers

Deployment

A Deployment manages Pods for an application workload, usually one that does not maintain local state.

It provides:

• Declarative updates
• Replica management
• Rolling deployments
• Rollback history
• Pausing and resuming rollouts

ReplicaSet

A ReplicaSet ensures that a requested number of matching Pods exist.

Deployments create and manage ReplicaSets automatically. You normally should not manually modify a ReplicaSet owned by a Deployment.

StatefulSet

A StatefulSet is intended for workloads that need stable identities, ordered operations, or persistent storage associated with individual replicas.

Common examples include databases, queues, and distributed systems, although running these systems reliably still requires application-specific operational knowledge.

DaemonSet

A DaemonSet runs a Pod on every eligible node or a selected group of nodes.

It is commonly used for:

• Log collection
• Node monitoring
• Network agents
• Security agents
• Storage components

Job

A Job runs Pods until a task completes successfully.

It is useful for:

• Data migrations
• Report generation
• Batch processing
• One-time maintenance

CronJob

A CronJob creates Jobs on a defined schedule.

It can run tasks such as nightly backups, periodic synchronisation, or scheduled reports.

Deployment, ReplicaSet, and Pod Relationship

The hierarchy for a typical stateless application is:

Deployment
└── ReplicaSet
    ├── Pod
    ├── Pod
    └── Pod

The Deployment controls the rollout. The ReplicaSet maintains the replica count. The Pods run the containers.

When a Deployment’s Pod template changes, the Deployment creates a new ReplicaSet and gradually shifts the workload to it.

Creating a Kubernetes Deployment

Create nginx.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3

  selector:
    matchLabels:
      app: nginx

  template:
    metadata:
      labels:
        app: nginx

    spec:
      containers:
        - name: nginx
          image: nginx:1.29-alpine

          ports:
            - name: http
              containerPort: 80

          resources:
            requests:
              cpu: 50m
              memory: 64Mi

            limits:
              cpu: 250m
              memory: 128Mi

          readinessProbe:
            httpGet:
              path: /
              port: http

            initialDelaySeconds: 2
            periodSeconds: 5

          livenessProbe:
            httpGet:
              path: /
              port: http

            initialDelaySeconds: 10
            periodSeconds: 10

Apply it:

kubectl apply -f nginx.yaml

Check the Deployment:

kubectl get deployments

Check the ReplicaSet:

kubectl get replicasets

Check the Pods:

kubectl get pods

The resource requests help the scheduler choose nodes. The limits constrain resource usage.

The readiness probe determines when a Pod can receive traffic. The liveness probe helps Kubernetes detect and restart an unhealthy container.

Use probes carefully. A badly designed liveness probe can repeatedly restart a healthy but slow application.

What Is a Kubernetes Service?

A Service provides a stable network endpoint for a logical group of Pods.

Pods are usually selected through labels. As Pods are created, replaced, or removed, the Service continues routing traffic to matching ready endpoints.

For example:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx

  ports:
    - name: http
      port: 80
      targetPort: http

  type: ClusterIP

Add this Service to nginx.yaml or save it separately, then apply it:

kubectl apply -f nginx.yaml

Kubernetes DNS allows workloads in the same namespace to reach it using:

http://nginx

Types of Kubernetes Services

ClusterIP

ClusterIP is the default Service type.

It exposes the Service on an internal virtual IP, making it suitable for communication within the cluster.

Example use:

• API to database proxy
• Frontend to backend
• Internal microservice communication

NodePort

NodePort exposes the Service through a port on each applicable node.

Traffic sent to a node’s IP and the assigned port can be forwarded to the Service.

NodePort is useful for certain development, testing, and infrastructure configurations, but it is not usually the preferred direct public entry point for production applications.

LoadBalancer

LoadBalancer asks the environment’s load-balancer integration to provision or configure an external load balancer.

Its behaviour depends on the cluster and cloud-provider implementation. It does not universally guarantee a fixed public IP, and some local or self-managed clusters require an additional load-balancer implementation.

ExternalName

ExternalName maps a Service name to an external DNS name through a DNS CNAME response.

It does not create a proxy or forward traffic by itself.

Headless Service

A headless Service uses:

clusterIP: None

Instead of exposing a virtual Service IP, DNS can return Pod or workload endpoints directly. Headless Services are often used with StatefulSets and applications that perform their own discovery.

Ingress and Gateway API

Services expose applications at the network-service level. HTTP and HTTPS routing often require an additional API and controller.

Ingress can route requests based on:

• Hostname
• Path
• TLS configuration

For example:

api.example.com/users  → users Service
api.example.com/orders → orders Service

An Ingress resource requires an Ingress controller. Creating the YAML resource alone does not configure traffic unless a compatible controller is installed.

Gateway API is a newer Kubernetes networking API designed with more expressive roles and routing capabilities. The appropriate choice depends on your platform and controller support.

Kubernetes Networking Basics

Kubernetes networking involves several distinct communication paths.

Container-to-Container

Containers within the same Pod communicate through localhost.

Pod-to-Pod

Pods communicate using cluster networking. Network policies may restrict which Pods are allowed to communicate.

Pod-to-Service

A Pod sends traffic to a stable Service name or IP. The Service routes it to an eligible backend endpoint.

External-to-Service

External traffic may enter through a LoadBalancer Service, NodePort, Ingress, Gateway, or another platform-specific entry point.

Network Policies

NetworkPolicy resources describe which network connections should be allowed for selected Pods.

They require support from the installed network plugin. Creating a NetworkPolicy in a cluster without enforcement support will not provide isolation.

Kubernetes Storage

Containers and Pods are temporary, but many applications need durable data.

Volumes

A volume makes storage available to containers in a Pod.

Some volume types exist only for the lifetime of the Pod, while others connect to external persistent storage.

PersistentVolume

A PersistentVolume represents storage available to the cluster.

It may be created manually or dynamically through a StorageClass.

PersistentVolumeClaim

A PersistentVolumeClaim is a request for storage made by a workload.

For example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: application-data
spec:
  accessModes:
    - ReadWriteOnce

  resources:
    requests:
      storage: 5Gi

The available access modes and storage behaviour depend on the storage provider.

StorageClass

A StorageClass defines a category of storage and how it should be dynamically provisioned.

Kubernetes manages the request and attachment process, but the underlying storage system still determines durability, backup support, performance, and availability.

Configuration and Secrets

Application configuration should normally be kept separate from container images.

ConfigMap

A ConfigMap stores non-confidential configuration as key-value data or files.

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-config
data:
  LOG_LEVEL: info
  FEATURE_SEARCH: "true"

Secret

A Secret stores sensitive data such as tokens, passwords, or certificates.

Kubernetes Secrets are base64-encoded by default, not automatically encrypted in every cluster. Production environments should consider:

• Encryption at rest
• Restricted RBAC permissions
• External secret-management systems
• Secret rotation
• Audit logging
• Avoiding secret exposure through logs or environment dumps

Do not commit real credentials to Kubernetes YAML files.

How kubectl Works

kubectl is the standard command-line tool for interacting with the Kubernetes API.

When you run:

kubectl get pods

kubectl:

1. Reads the current context from your kubeconfig.
2. Determines the API server and credentials.
3. Sends an authenticated request to the API server.
4. Receives the authorised API response.
5. Formats the response for the terminal.

kubectl does not read etcd directly.

Useful kubectl Commands

List Pods:

kubectl get pods

Show additional information:

kubectl get pods -o wide

Inspect a Pod:

kubectl describe pod <pod-name>

Read container logs:

kubectl logs <pod-name>

Follow logs:

kubectl logs -f <pod-name>

Execute a command inside a container:

kubectl exec -it <pod-name> -- sh

View recent events:

kubectl get events \
  --sort-by=.metadata.creationTimestamp

Check a rollout:

kubectl rollout status deployment/nginx

View rollout history:

kubectl rollout history deployment/nginx

Roll back a Deployment:

kubectl rollout undo deployment/nginx

Scale a Deployment:

kubectl scale deployment/nginx --replicas=5

Kubernetes Contexts

A context combines:

• A cluster
• A user or credential
• A default namespace

List contexts:

kubectl config get-contexts

Show the active context:

kubectl config current-context

Switch context:

kubectl config use-context <context-name>

Working in the wrong context can result in production changes being made accidentally. Always check the active context before applying or deleting resources.

How a Deployment Is Created Internally

When you run:

kubectl apply -f nginx.yaml

the process is approximately:

1. kubectl sends the Deployment definition to the API server.
2. The API server authenticates and authorises the request.
3. Admission controls and schema validation are applied.
4. The accepted Deployment state is persisted through the API server.
5. The Deployment controller notices the new desired state.
6. It creates or updates a ReplicaSet.
7. The ReplicaSet controller creates the required Pod objects.
8. The scheduler assigns unscheduled Pods to suitable nodes.
9. The kubelet on each selected node starts the containers.
10. The kubelet reports their status through the API server.
11. Service endpoint controllers update eligible backends when Pods become ready.

Controllers and other components watch resources through the API server. They do not normally watch etcd directly.

Setting Up Kubernetes Locally With kind

kind stands for Kubernetes IN Docker. It creates Kubernetes nodes as containers and is useful for:

• Learning Kubernetes
• Local testing
• CI pipelines
• Testing Kubernetes manifests
• Multi-node cluster experiments

It is not intended to replace a production Kubernetes platform.

Prerequisites

Install:

• Docker or another supported container runtime
• kubectl
• kind

The official kind quick-start guide lists current installation options. As of this update, the recommended stable kind release is v0.32.0.

If Go is installed, you can use:

go install sigs.k8s.io/kind@v0.32.0

On macOS with Homebrew:

brew install kind

Verify the installation:

kind version
kubectl version --client
docker version

Create a Multi-Node kind Cluster

Create kind-cluster.yaml:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

nodes:
  - role: control-plane
  - role: worker
  - role: worker

Create the cluster:

kind create cluster \
  --name local-demo \
  --config kind-cluster.yaml

kind creates the nodes and configures a kubectl context named:

kind-local-demo

Verify the cluster:

kubectl cluster-info \
  --context kind-local-demo

List the nodes:

kubectl get nodes

You should see one control-plane node and two workers.

Deploy the Example Application

Apply the Deployment and Service:

kubectl apply -f nginx.yaml

Check the resources:

kubectl get deployments
kubectl get replicasets
kubectl get pods
kubectl get services

Wait for the rollout:

kubectl rollout status deployment/nginx

Forward a local port to the Service:

kubectl port-forward service/nginx 8080:80

Open:

http://localhost:8080

You should see the NGINX welcome page.

Test Kubernetes Self-Healing

List the Pods:

kubectl get pods

Delete one:

kubectl delete pod <pod-name>

Watch what happens:

kubectl get pods --watch

The ReplicaSet notices that the number of Pods is below the declared count and creates a replacement.

This demonstrates workload reconciliation. Kubernetes did not restore the deleted Pod itself; it created a new Pod to satisfy the Deployment’s desired state.

Test a Rolling Update

Change the container image:

kubectl set image \
  deployment/nginx \
  nginx=nginx:stable-alpine

Watch the rollout:

kubectl rollout status deployment/nginx

View the ReplicaSets:

kubectl get replicasets

The Deployment creates a new ReplicaSet for the new Pod template and scales down the previous one according to its update strategy.

If needed, roll back:

kubectl rollout undo deployment/nginx

For production workloads, pin images to tested versions or immutable digests rather than relying on floating tags.

Delete the Local Cluster

When finished:

kind delete cluster --name local-demo

This removes the kind node containers and the cluster they contain.

What Kubernetes Does Not Do Automatically

Kubernetes provides orchestration primitives, but it does not automatically solve every production concern.

You still need to design:

• Application architecture
• Database replication and recovery
• Backups
• Monitoring and alerting
• Centralised logging
• Distributed tracing
• Container-image security
• Identity and access management
• Network policies
• Secret management
• Cost controls
• Capacity planning
• Disaster recovery
• CI/CD processes
• Cluster upgrades

A Kubernetes Deployment with three replicas is not automatically highly available if all replicas depend on one failing database or run in one failure zone.

Kubernetes improves the tools available for resilience, but the application and infrastructure must still be designed correctly.

When Should You Use Kubernetes?

Kubernetes may be appropriate when:

• Several containerised services need to be managed.
• Workloads must scale independently.
• Teams need controlled deployments and rollbacks.
• Applications run across several nodes or zones.
• A common platform is needed across multiple teams.
• Workload scheduling and self-healing provide clear operational value.
• The organisation can maintain or purchase the required platform expertise.

When Is Kubernetes Unnecessary?

Kubernetes may add more complexity than value when:

• The application is small and runs reliably on one server.
• Traffic and deployment requirements are simple.
• The team has limited infrastructure experience.
• A managed application platform already meets the product’s needs.
• Operational overhead would exceed the benefits.
• The application is an early prototype with uncertain requirements.

A container platform, serverless service, or managed hosting product may be a better starting point for a small application.

As the number of services and environments grows, operating the platform often becomes ongoing engineering work rather than a one-time setup. A dedicated software development team can help connect application architecture, CI/CD, observability, security, and Kubernetes operations instead of treating the cluster as an isolated infrastructure project.

Kubernetes Production Checklist

Before running important workloads, review:

• Control-plane and worker-node availability
• Resource requests and limits
• Readiness, liveness, and startup probes
• PodDisruptionBudgets
• Topology spread and anti-affinity
• Autoscaling configuration
• Network policies
• RBAC permissions
• Secret management
• Image scanning and signing
• Persistent-volume backups
• etcd backups for self-managed clusters
• Monitoring, logging, and alerting
• Cluster and API-version upgrades
• Namespace and quota design
• Disaster-recovery testing
• Cost and capacity monitoring

Frequently Asked Questions

What Is Kubernetes in Simple Terms?

Kubernetes is a system that runs and coordinates containers across multiple machines. You describe how an application should run, and Kubernetes continuously works to maintain that state.

Is Kubernetes the Same as Docker?

No. Docker is commonly used to build and run containers. Kubernetes coordinates containers across a cluster. Kubernetes can run standard container images created with Docker without using Docker Engine on its nodes.

What Is a Kubernetes Cluster?

A Kubernetes cluster is a group of machines running Kubernetes components. The control plane manages cluster state, while worker nodes run application workloads inside Pods.

What Is a Pod?

A Pod is Kubernetes’ smallest deployable computing unit. It contains one or more tightly coupled containers that share networking, attached storage, scheduling, and a common lifecycle.

What Is the Difference Between a Pod and a Container?

A container runs an application process with its dependencies. A Pod is the Kubernetes unit that hosts and manages one or more related containers on the same node.

What Is the Difference Between a Deployment and ReplicaSet?

A ReplicaSet maintains a requested number of Pods. A Deployment manages ReplicaSets and adds rollout strategies, revision history, declarative updates, and rollback capabilities.

How Does Kubernetes Handle Scaling?

Replica counts can be changed manually or adjusted by autoscalers using configured metrics. Node autoscaling may also add or remove compute capacity when supported by the cluster environment.

Does Kubernetes Automatically Fix Application Failures?

Kubernetes can restart containers and replace failed Pods. It cannot automatically fix defective code, corrupted data, incorrect configuration, unavailable dependencies, or flawed application architecture.

Is Kubernetes Only for Microservices?

No. Kubernetes can run monoliths, background workers, batch tasks, databases, and other containerised workloads. Its operational complexity should still be justified by the application’s requirements.

Can Kubernetes Run On-Premises?

Yes. Kubernetes can run on physical servers, virtual machines, public clouds, private clouds, edge systems, and hybrid infrastructure, provided the required compute, networking, storage, and operational components are available.

Is Kubernetes Free?

The Kubernetes software is open source. Running it still costs money for servers, networking, storage, monitoring, backups, security tools, and the engineers or managed services required to operate it.

Our Final Words

Kubernetes is best understood as a reconciliation system for containerised workloads. You define the desired state through API objects, and controllers continuously work to make the cluster match it.

Pods run the containers. Deployments manage application rollouts. ReplicaSets maintain replica counts. Services provide stable networking. ConfigMaps and Secrets supply configuration. PersistentVolumeClaims request storage. kubectl gives engineers a practical way to work with all of these resources through the API server.

What stood out while working through Kubernetes is that its individual objects are not especially difficult. The complexity comes from how networking, storage, security, availability, deployments, and application behaviour interact in production.

Start with a local kind cluster, deploy one application, expose it through a Service, delete a Pod, and observe the replacement. Once that reconciliation model is clear, the rest of Kubernetes becomes much easier to understand.