Kubernetes Fundamentals: Architecture, Core Components, and Essential kubectl Commands

 

Introduction

Kubernetes (K8s) is an open-source container orchestration platform used to deploy, manage, scale, and maintain containerized applications.

Instead of manually managing individual containers, Kubernetes automates many operational tasks, including:

• Deploying applications

• Managing containers

• Scaling applications

• Restarting failed workloads

• Load balancing

• Service discovery

• Rolling updates

• Managing application configuration

• Scheduling workloads across machines

For example, instead of manually running:

docker run nginx

we can define the desired state in Kubernetes and let Kubernetes manage the application.

---

Kubernetes Architecture at a Glance

The basic Kubernetes structure looks like this:

Kubernetes Cluster
│
├── Control Plane
│
└── Worker Node
     │
     ├── Pod
     │    └── Container
     │         ↑
     │       Image
     │
     └── Container Runtime
          └── containerd / CRI-O

There is an important relationship to understand here:

A Kubernetes cluster contains nodes. Nodes run Pods. Pods contain containers. Containers are created from container images. The container runtime runs the containers on the node.

---

1. Kubernetes Cluster

A Kubernetes cluster is the complete Kubernetes environment.

A cluster normally consists of:

• Control Plane

• One or more Worker Nodes

Kubernetes Cluster
│
├── Control Plane
│
├── Worker Node 1
├── Worker Node 2
└── Worker Node 3

The Control Plane manages the cluster, while Worker Nodes run application workloads.

---

2. Control Plane

The Control Plane is responsible for managing the Kubernetes cluster.

Important components include:

Control Plane
│
├── API Server
├── Scheduler
├── Controller Manager
└── etcd

API Server

The Kubernetes API Server is the main communication interface for the cluster.

When we run:

kubectl get pods

kubectl communicates with the API Server.

kubectl
   ↓
API Server
   ↓
Kubernetes Cluster

Scheduler

The Scheduler decides which node should run a Pod.

For example:

Pod
 ↓
Scheduler
 ↓
Worker Node 2

The Scheduler considers factors such as available resources and scheduling constraints.

Controller Manager

The Controller Manager contains controllers that continuously compare the desired state with the actual state.

For example, if we request:

Desired: 3 Pods

but one Pod fails:

Desired: 3 Pods
Actual:  2 Pods

Kubernetes works to create another Pod:

Desired: 3 Pods
Actual:  3 Pods

etcd

etcd is a distributed key-value store used by Kubernetes to store cluster state and configuration data.

---

3. Worker Node

A Worker Node is a physical machine or virtual machine where Kubernetes workloads run.

For example:

Kubernetes Cluster
│
├── Control Plane
│
├── Worker Node 1
├── Worker Node 2
└── Worker Node 3

A worker node contains components such as:

Worker Node
│
├── kubelet
├── Container Runtime
└── Pods

---

4. kubelet

The kubelet is an agent that runs on each node.

Its job is to make sure that the containers described in the Pod specification are running correctly.

A simplified flow is:

API Server
     ↓
   kubelet
     ↓
Container Runtime
     ↓
  Container

The kubelet communicates with the container runtime through the Kubernetes Container Runtime Interface (CRI).

---

5. Pod

A Pod is the smallest deployable unit in Kubernetes.

Kubernetes normally manages containers through Pods rather than managing individual containers directly.

The simplest structure is:

Node
│
└── Pod
     └── Container

A Pod can contain:

• One container

• Multiple containers

Most simple applications use one main container per Pod.

For example:

Pod
│
└── nginx container

A more advanced Pod could contain:

Pod
│
├── Application container
└── Sidecar container

Containers inside the same Pod share certain resources, including the Pod's network namespace.

---

6. Container

A container is a running instance created from a container image.

For example:

nginx:latest
      ↓
Container

A useful way to remember this is:

Image     = Package / Blueprint
Container = Running instance

The image contains the application and its required filesystem and dependencies. The container is the running environment created from that image.

---

7. Container Image

A container image is a packaged artifact used to create containers.

It can contain:

• Application code

• Dependencies

• Libraries

• Configuration

• Filesystem layers

Examples:

nginx:latest
redis:latest
ubuntu:24.04
postgres:16

Images are commonly stored in container registries.

Examples include:

• Docker Hub

• Amazon Elastic Container Registry (ECR)

• Azure Container Registry (ACR)

• Google Artifact Registry

• GitHub Container Registry

• Private container registries

The general flow is:

Container Registry
        ↓
      Image
        ↓
Container Runtime
        ↓
    Container
        ↓
       Pod
        ↓
      Node

---

8. Container Runtime

The container runtime is the software responsible for creating and running containers on a node.

Common container runtimes include:

containerd
CRI-O

For example:

Worker Node
│
├── kubelet
│
├── containerd
│
└── Pods
     └── Containers

Kubernetes does not directly execute the container process. The kubelet communicates with the container runtime, and the runtime manages the container lifecycle.

---

Important: Image vs Container vs Container Runtime

These three concepts are often confused.

Image

A packaged artifact used to create a container.

nginx:latest

Container

A running instance created from the image.

nginx image
     ↓
Container

Container Runtime

Software that creates and runs the container.

Image
  ↓
Container Runtime
  ↓
Container

Therefore:

The container is created from the image, and the container runtime is responsible for running the container.

---

Complete Kubernetes Architecture

Putting the major components together:

                         Kubernetes Cluster
                                │
                ┌───────────────┴───────────────┐
                │                               │
          Control Plane                    Worker Node
                │                               │
        ┌───────┼────────┐              ┌───────┼──────────┐
        │       │        │              │       │          │
    API Server Scheduler etcd         kubelet  Runtime     Pods
                                                │           │
                                            containerd      │
                                                            │
                                                     ┌──────┴──────┐
                                                     │             │
                                                   Pod           Pod
                                                     │             │
                                                 Container     Container
                                                     ↑             ↑
                                                     │             │
                                                   Image         Image

---

How Kubernetes Runs a Containerized Application

Suppose we want to deploy:

image: nginx:latest

The simplified process is:

1. Kubernetes receives the workload
              ↓
2. Scheduler selects a suitable Node
              ↓
3. kubelet on that Node receives the Pod specification
              ↓
4. kubelet communicates with the Container Runtime
              ↓
5. Runtime checks whether the image exists locally
              ↓
6. If necessary, Runtime pulls the image from a Registry
              ↓
7. Runtime creates the Container
              ↓
8. Container runs inside the Pod

The overall flow is:

Container Registry
        ↓
      Image
        ↓
Container Runtime
        ↓
    Container
        ↓
       Pod
        ↓
      Node
        ↓
Kubernetes Cluster

---

Understanding kubectl

kubectl is the command-line tool used to communicate with Kubernetes clusters.

The basic communication flow is:

kubectl
   ↓
Kubernetes API Server
   ↓
Kubernetes Cluster

For example:

kubectl get pods

This asks the Kubernetes API Server for information about Pods.

---

Essential kubectl Commands

The following commands are useful for checking and understanding a Kubernetes environment.

1. Check Whether kubectl Is Installed

kubectl version --client

This checks the installed kubectl client.

Important: This does not prove that a Kubernetes cluster is running.

---

2. Check the Kubernetes Cluster

kubectl cluster-info

If the cluster is running and accessible, this returns information about the Kubernetes control plane.

If you see:

The connection to the server ... was refused

then kubectl cannot currently connect to the Kubernetes API Server.

For example:

The connection to the server 127.0.0.1:32771 was refused

This means the configured API Server endpoint is not currently reachable.

---

3. Check the Current Kubernetes Context

kubectl config current-context

Example:

minikube

The current context tells you which Kubernetes context kubectl is currently using.

---

4. See All Configured Contexts

kubectl config get-contexts

Example:

CURRENT   NAME       CLUSTER    AUTHINFO
*         minikube   minikube   minikube

The * indicates the current context.

---

5. View the Current Kubernetes Configuration

kubectl config view --minify

This displays configuration for the currently selected context.

---

6. Check the Kubernetes Version

kubectl version

This can show both client and server version information when the cluster is reachable.

To check only the client:

kubectl version --client

---

7. Check the Nodes

kubectl get nodes

Example:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   10d   v1.34.0

This shows:

• Node name

• Node status

• Node role

• Node age

• Kubernetes version

---

8. Get More Information About Nodes

kubectl get nodes -o wide

This provides additional node information such as:

• Internal IP

• OS

• Kernel version

• Container runtime

---

9. Get Detailed Information About a Node

kubectl describe node <node-name>

Example:

kubectl describe node minikube

This provides detailed information such as:

• CPU

• Memory

• Pods

• Conditions

• Labels

• Taints

• Container runtime

• Kubernetes version

---

10. Check the Container Runtime

To see which container runtime each node is using:

kubectl get nodes -o custom-columns='NODE:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersion'

Example:

NODE       RUNTIME
minikube   containerd://2.1.3

This tells us that the node is using:

containerd

Another possible runtime is:

cri-o://1.x.x

---

11. Check Pods

To see Pods in the current namespace:

kubectl get pods

To see Pods across all namespaces:

kubectl get pods -A

Example:

NAMESPACE     NAME                  READY   STATUS    AGE
default       nginx-abc123          1/1     Running   5m
kube-system   coredns-xyz456        1/1     Running   10m

---

12. Check Which Node Each Pod Is Running On

kubectl get pods -A -o wide

Example:

NAMESPACE     NAME          READY   STATUS    NODE
default       nginx-abc123  1/1     Running   minikube

The NODE column tells us which node is running the Pod.

---

13. Check Container Names Inside Pods

kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,CONTAINERS:.spec.containers[*].name'

Example:

NAMESPACE     POD             CONTAINERS
default       nginx-abc123   nginx
kube-system   coredns-xyz456 coredns

This shows the container names defined in the Pods.

---

14. Check Which Images the Containers Use

kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,CONTAINERS:.spec.containers[*].name,IMAGES:.spec.containers[*].image'

Example:

NAMESPACE   POD            CONTAINERS   IMAGES
default     nginx-abc123  nginx        nginx:latest

Now we can trace:

Pod
 ↓
Container
 ↓
Image

---

15. Describe a Pod

For detailed information about a Pod:

kubectl describe pod <pod-name>

Example:

kubectl describe pod nginx-abc123

For a Pod in a specific namespace:

kubectl describe pod <pod-name> -n <namespace>

This is especially useful for troubleshooting.

---

16. Check Namespaces

kubectl get namespaces

or:

kubectl get ns

Example:

NAME              STATUS
default           Active
kube-system       Active
kube-public       Active
kube-node-lease   Active

Namespaces provide logical separation for Kubernetes resources.

---

17. Check Common Resources

kubectl get all

To see resources across all namespaces:

kubectl get all -A

This can show resources such as:

• Pods

• Services

• Deployments

• ReplicaSets

---

Essential Command Cheat Sheet

Once the cluster is running, these are the commands worth remembering:

# Check kubectl
kubectl version --client

# Check cluster connectivity
kubectl cluster-info

# Check current cluster/context
kubectl config current-context

# See all contexts
kubectl config get-contexts

# View current configuration
kubectl config view --minify

# Check Kubernetes version
kubectl version

# Check nodes
kubectl get nodes

# Check nodes with additional information
kubectl get nodes -o wide

# Check container runtime
kubectl get nodes -o custom-columns='NODE:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersion'

# Check Pods
kubectl get pods

# Check Pods across all namespaces
kubectl get pods -A

# Check Pods and the Nodes where they run
kubectl get pods -A -o wide

# Check container names
kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,CONTAINERS:.spec.containers[*].name'

# Check container images
kubectl get pods -A -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,CONTAINERS:.spec.containers[*].name,IMAGES:.spec.containers[*].image'

# Check namespaces
kubectl get ns

# Describe a Pod
kubectl describe pod <pod-name>

# Describe a Node
kubectl describe node <node-name>

# Check common resources
kubectl get all -A

---

The Kubernetes Mental Model

The easiest way to remember the basic hierarchy is:

KUBERNETES CLUSTER
        ↓
      NODE
        ↓
       POD
        ↓
   CONTAINER
        ↑
      IMAGE

However, the container runtime runs on the Node and is responsible for creating and running the containers:

                    KUBERNETES CLUSTER
                            │
                            ↓
                          NODE
                    ┌───────┴────────┐
                    │                │
                    ↓                ↓
                   POD       Container Runtime
                    │                │
                    ↓                ↓
               CONTAINER ←────── containerd
                    ↑
                    │
                  IMAGE

The Key Concept

Kubernetes schedules Pods onto Nodes. The kubelet communicates with the container runtime, and the container runtime creates and runs containers from container images.

The complete flow can therefore be visualized as:

User
 ↓
kubectl
 ↓
Kubernetes API Server
 ↓
Scheduler
 ↓
Node
 ↓
kubelet
 ↓
Container Runtime
 ↓
Container Image
 ↓
Container
 ↓
Pod

This hierarchy and these commands provide the foundation for understanding the next Kubernetes topics: Deployments, ReplicaSets, Services, Namespaces, ConfigMaps, Secrets, Ingress, StatefulSets, Persistent Volumes, and Kubernetes networking.