Kubernetes basics

Kubernetes management

Kubernetes components, RKE2 architecture, and inspecting the cluster in Rancher and from the command line.

7 min read

Kubernetes management

In this section you will learn in about an hour which parts a Kubernetes cluster consists of, how the RKE2 distribution implements those parts, and how to inspect the cluster both from the Rancher UI and from the command line. The cluster used in the training is an RKE2 cluster running in the cloud, managed with Rancher.

1. What does cluster management mean?

A Kubernetes cluster is a set of machines (nodes) that work together as a single unit for running containers. Management means understanding:

  • which parts the cluster consists of and what each part does,
  • how the parts communicate with each other,
  • how the cluster state is inspected and troubleshooting is done.

The cluster is divided into two roles:

  • The control plane makes the decisions and stores the cluster state.
  • The worker nodes run the actual application containers.
flowchart LR
    subgraph CP[Control Plane]
        API[kube-apiserver]
        ETCD[(etcd)]
        SCH[kube-scheduler]
        CM[kube-controller-manager]
    end
    subgraph W[Worker Nodes]
        KL[kubelet]
        KP[kube-proxy]
        CR[Container Runtime]
    end
    User[kubectl / Rancher] --> API
    API --- ETCD
    API --- SCH
    API --- CM
    API --- KL

2. Control Plane components

The control plane consists of four key components. In RKE2 they are run as static pods on the server nodes.

kube-apiserver

The cluster’s central API (REST API). All communication goes through it — kubectl, Rancher, and the cluster’s internal components alike. It:

  • receives and validates requests (authentication and authorization, RBAC),
  • is the only component that reads from and writes to etcd,
  • acts as the hub of events that other components watch.

etcd

A distributed, strongly consistent key–value database that stores the cluster’s entire desired and current state. It is the cluster’s source of truth.

⚠️ Remember: etcd contains everything — including Secrets. Backing it up and securing it is critical. RKE2 takes automatic snapshots of etcd.

kube-scheduler

Decides which worker node a new Pod is placed on. It takes into account, among other things:

  • the nodes’ free resources (CPU, memory),
  • the Pod’s resource requests and limits (requests/limits),
  • rules such as nodeSelector, taints/tolerations, and affinity.

The scheduler does not start the container itself — it only records the decision through the kube-apiserver.

kube-controller-manager

Runs a set of controllers that implement reconciliation loops: they compare the desired and current state and take corrective actions. Examples:

  • Node controller – monitors node health,
  • Deployment/ReplicaSet controller – keeps the number of replicas correct,
  • Job controller – runs one-off tasks.
sequenceDiagram
    participant U as kubectl / Rancher
    participant A as kube-apiserver
    participant E as etcd
    participant S as kube-scheduler
    participant K as kubelet (worker)
    U->>A: Create Deployment (desired state)
    A->>E: Store state
    S->>A: Select node for Pod
    A->>K: Start Pod on node
    K->>A: Report state (Running)

3. Worker nodes

Worker nodes (in RKE2, agent nodes) run the application containers. Every node has three key parts.

kubelet

The node’s agent, which:

  • receives from the kube-apiserver which Pods should be running on the node,
  • starts and monitors containers through the container runtime,
  • performs health checks (liveness/readiness probes),
  • reports the node’s and Pods’ state back to the kube-apiserver.

kube-proxy

Handles the node’s networking rules and routes traffic to Services (for example using iptables or IPVS rules). This way a Service’s virtual IP is routed to the correct Pods.

Container Runtime

The software that starts and runs the containers. RKE2 uses the containerd runtime. The runtime handles pulling container images, the container lifecycle, and isolation.

💡 Control Plane components are ultimately run as containers using worker-level mechanisms too: in RKE2 a server node runs both the control plane’s static pods and the kubelet and containerd parts.

4. RKE2 architecture

RKE2 (Rancher Kubernetes Engine 2) is Rancher’s security-focused Kubernetes distribution. It installs and maintains the components described above, ready-packaged.

Server and agent nodes

  • A server node (rke2-server) runs the control plane components and the embedded etcd. In production there are typically 3 server nodes for high availability.
  • An agent node (rke2-agent) is a worker node that runs only the kubelet, kube-proxy, and containerd, plus the application workloads.

Key features

  • Supervisor – RKE2’s own process that starts and monitors the kubelet and the control plane’s static pods.
  • Embedded etcd – etcd is run as part of the server node; RKE2 handles the snapshots.
  • containerd – the built-in container runtime.
  • CNI plugin – Canal (Calico + Flannel) by default; alternatives include Cilium.
  • helm-controller – installs add-ons (CNI, CoreDNS, ingress-nginx, metrics-server) automatically when the cluster starts.
  • Static pods – the control plane components’ manifests are on the node at /var/lib/rancher/rke2/agent/pod-manifests/.
flowchart TB
    subgraph RANCHER[Rancher · management]
        UI[Rancher UI + API]
    end
    subgraph SRV[Server nodes · rke2-server]
        direction TB
        S_API[kube-apiserver]
        S_ETCD[(embedded etcd)]
        S_SCH[kube-scheduler]
        S_CM[controller-manager]
        S_KL[kubelet + containerd]
    end
    subgraph AGT[Agent nodes · rke2-agent]
        direction TB
        A_KL[kubelet]
        A_KP[kube-proxy]
        A_CR[containerd]
        A_POD[Application pods]
    end
    UI --> S_API
    S_API --- S_ETCD
    S_API --- S_SCH
    S_API --- S_CM
    S_API --- A_KL

Rancher connects to the cluster through an agent and provides a graphical view of the nodes, pods, and workloads. The same information is also available with kubectl commands.

5. Rancher as a management UI

Rancher is a Kubernetes management platform for creating, importing, and managing multiple clusters from one place. In the training, Rancher is used to manage the RKE2 cluster.

Rancher’s key views:

  • Cluster Management – creating and importing clusters and the node states.
  • Cluster Explorer – the resources inside a single cluster (Nodes, Pods, Deployments, Services, ConfigMaps, Secrets…).
  • Workloads – inspecting and managing application workloads graphically.

Everything you see in Rancher comes through the same kube-apiserver as the kubectl commands — Rancher is a UI to the same API.

6. Hands-on: nodes and system pods (15 min)

Inspect the cluster’s parts both from the command line and from Rancher. First make sure you have the cluster’s kubeconfig in use (see the exercise in the architecture section) and access to Rancher.

Also make sure your own namespace is created and in use — this is where you will work in the later exercises:

bash 
# Replace <your-name> with your own name
kubectl create namespace <your-name> --dry-run=client -o yaml | kubectl apply -f -
kubectl config set-context --current --namespace=<your-name>

A) From the command line (kubectl)

1. List the nodes and their roles:

bash 
kubectl get nodes -o wide

Identify the server nodes (role control-plane,etcd,master) and the agent nodes (worker) in the output. The columns also show the node’s IP, operating system, and Kubernetes version.

2. Inspect the system pods in the kube-system namespace:

bash 
kubectl get pods -n kube-system -o wide

Find RKE2’s components in the output, for example:

  • etcd-<node>, kube-apiserver-<node>, kube-scheduler-<node>, kube-controller-manager-<node> – the control plane’s static pods,
  • kube-proxy-<node> – the network proxy on every node,
  • rke2-canal-* / cilium-* – the CNI network plugin,
  • rke2-coredns-* – the cluster DNS,
  • rke2-ingress-nginx-*, rke2-metrics-server-* – additional services.

3. View the detailed information of a single node:

bash 
kubectl describe node <node-name>

Pay attention to the Roles, Taints, Capacity, Allocatable, and Conditions (e.g. Ready=True) sections.

4. Verify the cluster’s basic health:

bash 
kubectl cluster-info
kubectl get pods -n kube-system --field-selector status.phase!=Running

The latter command should be empty — all system pods are Running.

B) From the Rancher UI

  1. Log in to Rancher and open the training cluster.
  2. Go to Cluster → Nodes. Compare the number of nodes and their roles to the output of kubectl get nodes.
  3. Open Cluster Explorer → Workloads → Pods and select kube-system as the namespace. Find the same components as on the command line.
  4. Click one pod (e.g. kube-apiserver-*) and examine its state, events, and logs.

🔎 Observation: Rancher and kubectl show the same information because both use the same kube-apiserver. The UI is handy for an overview, and the command line for precise troubleshooting and automation.

Summary

  • The cluster is divided into the control plane (kube-apiserver, etcd, scheduler, controller-manager) and the worker nodes (kubelet, kube-proxy, container runtime).
  • kube-apiserver is the hub of all communication; etcd is the source of truth.
  • RKE2 packages these ready to use: server nodes run the control plane and the embedded etcd, agent nodes are workers. containerd is the runtime and Canal the default CNI.
  • Rancher is a management UI to the same kube-apiserver — the same information is also available with the kubectl get nodes and kubectl get pods -n kube-system commands.