Skip to main content
FluentFlash

Kubelet for Kubernetes CKA: Complete Study Guide

·

The kubelet is a critical node-level agent that appears frequently on the Kubernetes Certified Associate (CKA) exam. Understanding how it manages pods, communicates with the API server, and handles container lifecycle directly impacts your exam success.

This guide covers kubelet architecture, configuration, real-world troubleshooting, and practical study strategies. You'll learn how to diagnose node failures, manage pod eviction, handle certificates, and tackle exam scenarios with confidence.

Mastering kubelet through focused flashcard study strengthens both your exam preparation and real-world Kubernetes administration skills.

Kubernetes cka kubelet - study with AI flashcards and spaced repetition

What is the Kubelet and Why It Matters for CKA

The kubelet is a node agent running on every Kubernetes node. It ensures containers execute in pods exactly as specified in the PodSpec manifest.

Role in Cluster Architecture

The kubelet sits between the control plane's desired state and actual node execution. It receives pod specifications from the API server, pulls container images, starts containers, and monitors pod health continuously. When something fails, the kubelet automatically handles restarts based on your restart policy.

Why CKA Tests Kubelet Heavily

CKA questions test kubelet frequently because real-world Kubernetes failures trace directly to kubelet misconfiguration. You must diagnose node problems, understand pod scheduling, troubleshoot eviction scenarios, and identify certificate issues.

The kubelet manages multiple critical functions:

  • Pulling container images and starting containers
  • Implementing liveness probes and readiness probes for health checks
  • Handling graceful pod termination with SIGTERM signals
  • Managing pod volumes and port mappings
  • Enforcing resource limits through the container runtime

Practical Troubleshooting Skills

For CKA success, learn to check kubelet logs using journalctl, review configuration files, and use kubectl describe nodes to identify issues. These hands-on techniques appear repeatedly in exam scenarios.

Kubelet Architecture and Communication Flow

The kubelet operates as a daemon process on each node and maintains constant communication with the Kubernetes API server. This bidirectional communication is essential for a functioning cluster.

API Server Communication Model

The API server watches the node's pod endpoint and pushes pod specifications to the kubelet. The kubelet pulls these specs, creates the necessary pods, and reports node and pod status back to the API server. This watch mechanism ensures the kubelet stays synchronized with cluster state.

The kubelet exposes its own API on port 10250 (default) with endpoints including:

  • /pods (list pods on the node)
  • /metrics (node metrics)
  • /logs (container logs)

TLS Authentication and Security

The kubelet authenticates to the API server using TLS certificates located in /var/lib/kubelet/pki/. Understanding this authentication flow is critical for diagnosing communication failures between nodes and the control plane.

Container Runtime Interface (CRI)

The kubelet implements the Container Runtime Interface abstraction. This allows Kubernetes to work with Docker, containerd, CRI-O, and other runtimes. The kubelet translates PodSpecs into container runtime calls.

Pod Specification Sources

The kubelet handles three sources of pod specifications:

  • Static pods (manifest files on the node)
  • API server pods (dynamically scheduled)
  • HTTP-served pods (less common)

Static pods deserve special attention because they run control plane components on control plane nodes and can't be deleted through the API.

kubectl logs and kubectl exec

When you run kubectl logs or kubectl exec, the API server contacts the kubelet API on port 10250. This is why these commands fail when the kubelet is unreachable.

Kubelet Configuration, Flags, and Troubleshooting

The kubelet configuration controls how nodes behave and directly impacts pod scheduling and resource management. Modern deployments use configuration files at /etc/kubernetes/kubelet/kubelet-config.yaml, specified via the --config flag.

Critical Configuration Parameters

Understanding these parameters is essential for CKA:

  • kubeAPIQPS: API server query rate (controls how frequently the kubelet queries the API)
  • kubeReserved: Resources reserved for kubelet and system processes
  • systemReserved: OS-level resource reservations
  • maxPods: Maximum pods per node (default 110)
  • podPidsLimit: Process ID limit per pod
  • node-status-update-frequency: How often the kubelet reports status (default 10 seconds)

These settings directly impact pod eviction, scheduling decisions, and cluster stability.

Troubleshooting with Logs

The kubelet logs are your first diagnostic tool. On systemd systems, stream logs in real-time:

journalctl -u kubelet -f

Diagnosing Common Issues

Watch for these frequent failure scenarios:

  • Kubelets not registering with the API server (check network and certificates)
  • Pods stuck in Pending state (verify kubeAPIQPS isn't throttling)
  • Nodes reporting NotReady (typically certificate expiration or kubelet crashes)

Run kubectl describe node <node-name> to see critical kubelet conditions like Ready, MemoryPressure, DiskPressure, and PIDPressure. A NotReady condition almost always indicates kubelet failure.

Pod Health Probes

The kubelet implements three probe types:

  • Liveness probes: Restart failed containers
  • Readiness probes: Determine if a pod should receive traffic
  • Startup probes: Handle slow-starting applications

Each probe type supports HTTP, TCP, and exec methods. Misconfigured probes appear frequently on CKA exam scenarios.

Pod Lifecycle Management and Eviction

The kubelet manages the complete pod lifecycle from initial scheduling through final termination. Understanding each stage is crucial for CKA success.

Pod Lifecycle Stages

When a pod is scheduled to a node, the kubelet executes this sequence:

  1. Pulls the container image (if not already cached)
  2. Creates the container using the container runtime
  3. Sets up networking through CNI plugins
  4. Mounts volumes
  5. Starts monitoring for health and resource violations

Pod lifecycle states are:

  • Pending: Being scheduled and pulled
  • Running: Containers executing
  • Succeeded: Completed successfully
  • Failed: Containers crashed
  • Unknown: Lost contact with kubelet

Eviction and QoS Classes

Pod eviction occurs when node resources become scarce. The kubelet monitors memory and disk pressure, triggering eviction based on QoS class:

  • Guaranteed: Resource requests equal limits (evicted last)
  • Burstable: Partial resource limits (evicted second)
  • BestEffort: No resource limits (evicted first)

For CKA, configure eviction thresholds using flags like --eviction-hard and --eviction-soft.

Graceful Termination

When a pod is deleted, the kubelet sends SIGTERM to containers and waits for terminationGracePeriodSeconds (default 30 seconds) before forcefully killing them with SIGKILL. This allows applications to gracefully shut down connections.

PreStop Hooks and Node Maintenance

PreStop hooks allow custom cleanup logic before termination. The kubelet also handles node maintenance:

  • Cordon: Prevents new pods from scheduling
  • Drain: Forcefully evicts existing pods

Understand when to use kubectl cordon versus kubectl drain for cluster maintenance.

Kubelet Certificates, Security, and CKA Exam Strategy

The kubelet uses TLS certificates to authenticate with the API server and secure its own API endpoint. Certificate management and security are heavily tested on CKA.

Certificate Locations and Rotation

The kubelet certificate is located at /var/lib/kubelet/pki/kubelet.crt with the private key at /var/lib/kubelet/pki/kubelet.key. Certificate expiration is a common failure scenario.

Kubernetes 1.26+ enables automatic kubelet certificate rotation, but understand manual rotation. Check certificate expiration:

openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout

Enable automatic rotation with these flags:

  • --rotate-certificates: Enable client certificate rotation
  • --rotate-server-certificates: Enable server certificate rotation

Kubelet API Security

The kubelet API on port 10250 requires proper authentication through client certificates. Verify connectivity using curl:

curl -k --cert kubelet.crt --key kubelet.key https://node-ip:10250/api/v1/pods

The kubelet implements authorization through the API server, checking if requests are authorized using the system:nodes ClusterRole.

CKA Exam Focus Areas

Prioritize these practical scenarios:

  • Diagnose why nodes report NotReady status due to certificate issues
  • Manually rotate expired certificates
  • Verify kubelet can communicate with the API server
  • Check ServiceAccount integration with kubelet authentication

Flashcard Study Strategy

Create cards focused on:

  • Certificate locations and expiration diagnosis
  • Eviction policy configuration and QoS classes
  • Pod lifecycle state transitions and probe types
  • Scenario-based troubleshooting for NotReady nodes
  • Common kubelet flags and configuration parameters

Build your deck with real CKA exam scenarios where you must diagnose why a node fails or pods don't schedule. This mirrors actual exam questions and reinforces practical Kubernetes administration.

Master Kubelet for CKA Success

Flashcards are uniquely effective for kubelet study because they break down complex architectural concepts, configuration parameters, and troubleshooting procedures into bite-sized, testable knowledge. Create interactive flashcards covering kubelet certificate locations, eviction policies, configuration flags, pod lifecycle states, and real-world troubleshooting scenarios. Spaced repetition ensures you retain critical details like kubeconfig paths, service file locations, and diagnostic commands needed for practical exam tasks. Build your card deck with scenario-based questions that mirror actual CKA exam challenges, reinforcing both theoretical understanding and hands-on problem-solving skills.

Create Free Flashcards

Frequently Asked Questions

What is the difference between the kubelet and kube-proxy?

The kubelet and kube-proxy are separate node-level agents with distinct responsibilities.

The kubelet manages the complete pod lifecycle. It pulls container images, creates containers, monitors pod health, manages volumes, and reports node status to the API server. Kubelet issues cause pods to fail or not run at all.

The kube-proxy manages networking and Service load balancing. It creates iptables or IPVS rules that route traffic from Service cluster IPs to the correct pod endpoints. Kube-proxy issues cause pods to exist but be unreachable through Services.

For CKA: understand that kubelet problems prevent pods from running, while kube-proxy problems prevent traffic from reaching running pods. Both are essential for a functioning cluster.

How do I troubleshoot a node that shows NotReady status?

A NotReady node indicates the kubelet cannot communicate with the API server or has encountered a critical failure. Follow this systematic troubleshooting approach:

Check Kubelet Logs

Start by reviewing kubelet logs:

journalctl -u kubelet -f

Look for certificate expiration errors, authentication failures, or connection timeouts.

Verify Connectivity and Configuration

  • Verify network connectivity between node and control plane using ping or nc
  • Check that the kubelet configuration file is valid YAML
  • Verify the kubeconfig file referenced in --kubeconfig is accessible and properly authenticated

Inspect Node Details

Run kubectl describe node <node-name> to see detailed node conditions including specific error messages.

Common Causes

  • Expired certificates (check with openssl x509)
  • Incorrect kubeconfig pointing to wrong API server
  • Firewall rules blocking port 6443
  • Insufficient disk space causing kubelet to crash
  • Kubelet service not running as expected
What are static pods and how does the kubelet handle them?

Static pods are pods defined through manifest files on the node itself, not through the API server. The kubelet watches a manifest directory (typically /etc/kubernetes/manifests) specified via --pod-manifest-path and automatically creates pods from YAML files in that directory.

When a static pod manifest is updated, the kubelet detects the change and updates the pod. If a file is deleted, the kubelet removes the pod.

Why Static Pods Matter for CKA

Static pods are critical for Kubernetes infrastructure because they run control plane components like apiserver, controller-manager, and etcd on control plane nodes. This ensures these components are always running even if the API server is temporarily unavailable.

Key Differences from API Server Pods

  • Static pods appear in kubectl get pods but are suffixed with the node name
  • You cannot delete static pods through the API server
  • You must remove the manifest file to delete a static pod

This is why control plane nodes appear to run core components but you cannot delete them through standard kubectl commands.

How does the kubelet implement resource limits and request scheduling?

The kubelet uses container resource requests and limits specified in pod specs to control scheduling and enforce runtime constraints.

Scheduling Phase

During scheduling, the kube-scheduler uses resource requests to verify the node has sufficient allocatable resources. It calculates available capacity by subtracting kubelet and system reservations from total node capacity.

Runtime Enforcement

The kubelet enforces limits using Linux cgroups. If a container exceeds memory limits, the kernel OOM killer terminates it. For CPU, containers are throttled rather than killed.

Resource Reservations

Configure what the kubelet reserves for itself using:

  • kubeReserved: Resources for kubelet processes
  • systemReserved: Resources for the operating system

QoS Classes and Eviction

QoS classes determine eviction order when node resources are scarce:

  • Guaranteed: Highest priority (not evicted)
  • Burstable: Medium priority
  • BestEffort: Lowest priority (evicted first)

Understanding QoS classes is crucial for CKA resource management questions.

What's the relationship between kubelet API and kubectl logs/exec commands?

When you run kubectl logs or kubectl exec, the API server contacts the kubelet API on port 10250 of the relevant node. The kubelet API handles these requests by interfacing with the container runtime to fetch logs or execute commands inside containers.

Communication Flow

  1. You run kubectl logs <pod-name>
  2. kubectl sends the request to the API server
  3. API server forwards the request to the kubelet API on port 10250
  4. Kubelet interfaces with the container runtime to fetch logs
  5. Logs are streamed back through the API server to your terminal

Why kubectl logs/exec Fail

These commands fail when the kubelet is down or unreachable. The problem is kubelet connectivity, not the pod itself.

Diagnosing Connectivity Issues

Verify kubelet API access using curl:

curl -k --cert kubelet.crt --key kubelet.key https://node-ip:10250/logs

For CKA: understand that kubectl log or exec failures usually indicate kubelet problems rather than pod problems.