Worker Node Components Quiz
Quiz
Question 1 of 39
(0 answered)
Question 1
A pod is scheduled to a worker node but its containers are repeatedly crash-looping. Which component detects the failures, triggers restarts according to the pod’s restart policy, and reports the pod status back to the API server?
✓
Correct!
kubelet is the node agent responsible for the full pod lifecycle — it calls the container runtime to start containers and runs health probes. When a liveness probe fails or a container exits, kubelet applies the pod’s restart policy and triggers a new container start. kube-proxy (A) only configures network rules for service routing; it never monitors container health. The container runtime (C) executes containers but doesn’t independently decide when to restart them — kubelet drives that decision. The node controller (D) monitors node health from the control plane but doesn’t directly restart individual containers.
✗
Incorrect
kubelet is the node agent responsible for the full pod lifecycle — it calls the container runtime to start containers and runs health probes. When a liveness probe fails or a container exits, kubelet applies the pod’s restart policy and triggers a new container start. kube-proxy (A) only configures network rules for service routing; it never monitors container health. The container runtime (C) executes containers but doesn’t independently decide when to restart them — kubelet drives that decision. The node controller (D) monitors node health from the control plane but doesn’t directly restart individual containers.
Think about which component directly watches pod specs and bridges the scheduler’s assignment with container execution.
Question 2
Which of the following are direct responsibilities of kubelet?
✓
Correct!
kubelet handles health probes, enforces resource limits through cgroups, and mounts volumes. Creating iptables rules and distributing traffic are kube-proxy responsibilities.
✗
Incorrect
kubelet handles health probes, enforces resource limits through cgroups, and mounts volumes. Creating iptables rules and distributing traffic are kube-proxy responsibilities.
Focus on pod-level operations rather than cluster-wide networking.
Question 3
The Service object in Kubernetes directly routes traffic from the Service IP to pod IPs.
✓
Correct!
This is a common misconception. Service objects are just configuration stored in etcd. kube-proxy reads Service configuration and creates iptables/IPVS rules, and the Linux kernel applies these rules to route traffic. Services themselves never touch packets.
✗
Incorrect
This is a common misconception. Service objects are just configuration stored in etcd. kube-proxy reads Service configuration and creates iptables/IPVS rules, and the Linux kernel applies these rules to route traffic. Services themselves never touch packets.
Think about what happens at the kernel level when packets arrive.
Question 4
A pod has the following resource configuration. What happens when the container tries to use 600Mi of memory?
resources:
requests:
memory: 128Mi
limits:
memory: 512MiWhat will this code output?
✓
Correct!
When a container exceeds its memory limit (512Mi in this case), kubelet kills the container with an OOMKilled status. Memory limits are hard limits enforced via cgroups, unlike CPU which is throttled.
✗
Incorrect
When a container exceeds its memory limit (512Mi in this case), kubelet kills the container with an OOMKilled status. Memory limits are hard limits enforced via cgroups, unlike CPU which is throttled.
Memory and CPU limits are handled differently—one is throttled, one is killed.
Question 5
kubelet uses _____ (control groups) to enforce resource requests and limits on containers.
✓
Correct!
Linux cgroups (control groups) are kernel-level resource namespaces that enforce hard limits on container resource usage. kubelet writes to a pod’s cgroup hierarchy during startup, translating
limits.memory: 512Mi in the pod spec into a kernel enforcement boundary. Without cgroups, a container could freely consume all CPU and memory on the node, starving other pods. Think of resource requests as a scheduling reservation and limits as a hard ceiling enforced by the kernel at runtime.✗
Incorrect
Linux cgroups (control groups) are kernel-level resource namespaces that enforce hard limits on container resource usage. kubelet writes to a pod’s cgroup hierarchy during startup, translating
limits.memory: 512Mi in the pod spec into a kernel enforcement boundary. Without cgroups, a container could freely consume all CPU and memory on the node, starving other pods. Think of resource requests as a scheduling reservation and limits as a hard ceiling enforced by the kernel at runtime.It’s a Linux kernel feature abbreviated as a single word.
Question 6
Arrange the pod startup flow in the correct sequence:
Drag to arrange in the correct order
⋮⋮
Scheduler assigns Pod to Worker Node
⋮⋮
kubelet calls Container Runtime to pull image and start container
⋮⋮
kubelet calls CNI plugin to setup networking
⋮⋮
kube-proxy updates iptables/IPVS rules
⋮⋮
kubelet starts health probes
✓
Correct!
The sequence is: 1) Scheduler assigns pod → 2) kubelet detects assignment → 3) CNI creates network namespace and assigns IP → 4) Runtime pulls image and starts container → 5) kubelet starts health probes → 6) Status reported to API server → 7) Endpoints updated → 8) kube-proxy updates rules.
✗
Incorrect
The sequence is: 1) Scheduler assigns pod → 2) kubelet detects assignment → 3) CNI creates network namespace and assigns IP → 4) Runtime pulls image and starts container → 5) kubelet starts health probes → 6) Status reported to API server → 7) Endpoints updated → 8) kube-proxy updates rules.
Question 7
What happens when a pod’s readiness probe fails?
✓
Correct!
When a readiness probe fails, kubelet removes the pod from service endpoints so it stops receiving traffic, but the container continues running. Liveness probe failures trigger container restarts.
✗
Incorrect
When a readiness probe fails, kubelet removes the pod from service endpoints so it stops receiving traffic, but the container continues running. Liveness probe failures trigger container restarts.
Consider what ‘ready’ means in the context of receiving traffic.
Question 8
What is the Container Runtime Interface (CRI)?
What is the Container Runtime Interface (CRI)?
Container Runtime Interface (CRI)
Standard gRPC API that lets kubelet work with any container runtime without code changes.
- Purpose: decouple kubelet from specific runtime implementations
- Protocol: gRPC — runtime runs as a separate process that kubelet calls
- What it abstracts: image pulls, container lifecycle, execution, log streaming
- Common runtimes: containerd (default in most distros), CRI-O (K8s-native)
- Key benefit: swap runtimes (e.g., containerd → CRI-O) without modifying kubelet
Did you get it right?
✓
Correct!
✗
Incorrect
Question 9
Complete the health probe configuration to check if a container is alive:
Fill in the probe type
_____:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10✓
Correct!
livenessProbe checks if a container is alive. If it fails, kubelet restarts the container. This is different from readinessProbe (can accept traffic?) and startupProbe (has finished starting?).✗
Incorrect
livenessProbe checks if a container is alive. If it fails, kubelet restarts the container. This is different from readinessProbe (can accept traffic?) and startupProbe (has finished starting?).Question 10
In the traffic routing flow, which components actually process or modify network packets?
✓
Correct!
Only iptables/IPVS rules (in the Linux kernel) and CNI plugins actually process packets. Service and Endpoints are just configuration objects in etcd, and kube-proxy creates rules but doesn’t process packets itself.
✗
Incorrect
Only iptables/IPVS rules (in the Linux kernel) and CNI plugins actually process packets. Service and Endpoints are just configuration objects in etcd, and kube-proxy creates rules but doesn’t process packets itself.
Think about what operates at the kernel/network layer versus what’s stored in etcd.
Question 11
When kube-proxy operates in iptables mode and a client sends a request to a Service ClusterIP (10.96.100.50), what happens at the network level?
✓
Correct!
The packet reaches the node’s network stack where the kernel’s netfilter intercepts it. iptables rules (created by kube-proxy) match the Service ClusterIP and perform DNAT (Destination NAT) to rewrite the destination to a real pod IP. Neither the Service object nor kube-proxy process touches the packet.
✗
Incorrect
The packet reaches the node’s network stack where the kernel’s netfilter intercepts it. iptables rules (created by kube-proxy) match the Service ClusterIP and perform DNAT (Destination NAT) to rewrite the destination to a real pod IP. Neither the Service object nor kube-proxy process touches the packet.
Focus on what happens at the kernel level with the rules that were pre-configured.
Question 12
When kubelet enforces CPU limits on a container, the container is killed if it exceeds the limit.
✓
Correct!
CPU limits are enforced by throttling, not killing. When a container reaches its CPU limit, it’s throttled (slowed down) but continues running. Only memory limit violations result in the container being killed (OOMKilled).
✗
Incorrect
CPU limits are enforced by throttling, not killing. When a container reaches its CPU limit, it’s throttled (slowed down) but continues running. Only memory limit violations result in the container being killed (OOMKilled).
Think about the difference between how CPU and memory limits are enforced.
Question 13
During pod eviction due to node resource pressure, in what order does kubelet evict pods?
✓
Correct!
kubelet evicts pods in order of QoS class: BestEffort first (no requests/limits), then Burstable (requests < limits), and finally Guaranteed (requests = limits). This protects workloads with stronger resource guarantees.
✗
Incorrect
kubelet evicts pods in order of QoS class: BestEffort first (no requests/limits), then Burstable (requests < limits), and finally Guaranteed (requests = limits). This protects workloads with stronger resource guarantees.
Think about which pods have the least resource guarantees.
Question 14
Why is the Service ClusterIP called a ‘virtual IP’?
Why is the Service ClusterIP called a ‘virtual IP’?
Virtual IP (VIP) — Service ClusterIP
A Service ClusterIP is a fictional IP that exists only in iptables/IPVS rules — not on any actual network interface.
- Not assigned to: any pod, node interface, kube-proxy process, or Service object itself
- Lives in: iptables/IPVS rules created by kube-proxy on each node
- How traffic works: packet to VIP → kernel netfilter matches rule → DNAT rewrites destination to real pod IP
- Why it’s virtual: Linux netfilter intercepts and rewrites the packet before it ever leaves the node network stack
- Mental model: a ‘catch rule’ that hijacks packets destined for the ClusterIP and redirects them to a real pod
Did you get it right?
✓
Correct!
✗
Incorrect
Question 15
Which of the following statements correctly describe kube-proxy’s role?
✓
Correct!
kube-proxy watches for changes, creates network rules, and translates Service config into rules. However, it does NOT receive or forward packets itself—the kernel applies the rules it creates. Load balancing happens via kernel rules, not a proxy process.
✗
Incorrect
kube-proxy watches for changes, creates network rules, and translates Service config into rules. However, it does NOT receive or forward packets itself—the kernel applies the rules it creates. Load balancing happens via kernel rules, not a proxy process.
kube-proxy is a ‘rule creator’, not a ‘packet processor’.
Question 16
A node stops sending heartbeats to the API server. How long until the node is marked as NotReady?
# Default Kubernetes node monitoring settings
node-monitor-period: 5s
node-monitor-grace-period: 40s
pod-eviction-timeout: 5mWhat will this code output?
✓
Correct!
The node is marked NotReady after the node-monitor-grace-period (default ~40 seconds) of missing heartbeats. Pod eviction happens later, after the pod-eviction-timeout (~5 minutes).
✗
Incorrect
The node is marked NotReady after the node-monitor-grace-period (default ~40 seconds) of missing heartbeats. Pod eviction happens later, after the pod-eviction-timeout (~5 minutes).
Look at the grace period specifically for node monitoring.
Question 17
What is the primary advantage of kube-proxy’s IPVS mode over iptables mode?
✓
Correct!
IPVS mode offers O(1) lookup time (vs O(n) for iptables), better performance with many services, and advanced load balancing algorithms (round-robin, least connection, etc.). However, it requires kernel modules and is more complex.
✗
Incorrect
IPVS mode offers O(1) lookup time (vs O(n) for iptables), better performance with many services, and advanced load balancing algorithms (round-robin, least connection, etc.). However, it requires kernel modules and is more complex.
Think about algorithmic complexity and scale.
Question 18
kubelet communicates with the container runtime through the _____ (three-letter acronym) interface.
✓
Correct!
CRI (Container Runtime Interface) is the standardized gRPC API that allows kubelet to work with different container runtimes like containerd, CRI-O, etc.
✗
Incorrect
CRI (Container Runtime Interface) is the standardized gRPC API that allows kubelet to work with different container runtimes like containerd, CRI-O, etc.
It’s a three-letter acronym that starts with ‘C’.
Question 19
kubelet can run containers even if the API server is down, as long as it has the pod specifications cached.
✓
Correct!
kubelet maintains a local cache of pod specifications and can continue managing existing pods even if the API server becomes unavailable. However, it won’t receive new pod assignments or updates during the outage.
✗
Incorrect
kubelet maintains a local cache of pod specifications and can continue managing existing pods even if the API server becomes unavailable. However, it won’t receive new pod assignments or updates during the outage.
Think about kubelet’s autonomy and local caching capabilities.
Question 20
Which component is responsible for assigning an IP address to a newly created pod?
✓
Correct!
The CNI (Container Network Interface) plugin is responsible for setting up pod networking, including creating the network namespace and assigning an IP address. kubelet calls the CNI plugin to perform these operations.
✗
Incorrect
The CNI (Container Network Interface) plugin is responsible for setting up pod networking, including creating the network namespace and assigning an IP address. kubelet calls the CNI plugin to perform these operations.
Think about which plugin handles networking specifically.
Question 21
Arrange the components in order of who interacts with what during packet routing from Service IP to Pod IP:
Order from first to last in the routing process
⋮⋮
Client sends packet to Service ClusterIP
⋮⋮
Kernel netfilter intercepts packet
⋮⋮
Node network stack receives packet
⋮⋮
iptables/IPVS rules rewrite destination (DNAT)
⋮⋮
CNI routes packet to destination pod
✓
Correct!
Traffic flow: Client sends to ClusterIP → Node network stack → Kernel netfilter intercepts → iptables/IPVS performs DNAT → CNI routes to pod. The Service object is never in this flow—it’s just configuration.
✗
Incorrect
Traffic flow: Client sends to ClusterIP → Node network stack → Kernel netfilter intercepts → iptables/IPVS performs DNAT → CNI routes to pod. The Service object is never in this flow—it’s just configuration.
Question 22
Explain the three QoS classes that determine pod eviction priority.
Explain the three QoS classes that determine pod eviction priority.
QoS Classes (Quality of Service)
Guaranteed: requests = limits for all containers. Highest priority, evicted last.
Burstable: requests < limits (or only requests set). Medium priority.
BestEffort: No requests or limits set. Lowest priority, evicted first.
kubelet uses these classes during resource pressure to decide which pods to evict, protecting workloads with stronger resource guarantees.
Did you get it right?
✓
Correct!
✗
Incorrect
Question 23
When a worker node fails completely, which of the following occur in the cluster recovery process?
✓
Correct!
When a node fails: heartbeats stop → Node marked NotReady (~40s) → After grace period (~5m) pods are terminated → Controllers create replacement pods on healthy nodes. The node isn’t immediately removed, and the failed node’s kube-proxy can’t update anything since it’s down.
✗
Incorrect
When a node fails: heartbeats stop → Node marked NotReady (~40s) → After grace period (~5m) pods are terminated → Controllers create replacement pods on healthy nodes. The node isn’t immediately removed, and the failed node’s kube-proxy can’t update anything since it’s down.
Consider what happens to pods and how controllers respond, not immediate removal.
Question 24
What is the relationship between Service objects and Endpoints objects?
✓
Correct!
The Endpoints controller watches Services and creates/updates Endpoints objects based on the Service selector matching pod labels. kube-proxy watches Endpoints to know which pod IPs to include in its routing rules. Services define what to match, Endpoints list the actual IPs.
✗
Incorrect
The Endpoints controller watches Services and creates/updates Endpoints objects based on the Service selector matching pod labels. kube-proxy watches Endpoints to know which pod IPs to include in its routing rules. Services define what to match, Endpoints list the actual IPs.
Think about the flow: Service selector → which pods match → where to route.
Question 25
Complete the probe that determines if a container should receive traffic from a Service:
Fill in the probe type
_____:
httpGet:
path: /ready
port: 8080
periodSeconds: 5✓
Correct!
readinessProbe determines if a container can accept traffic. When it fails, the pod is removed from Service endpoints. This is different from livenessProbe (restart if fails) and startupProbe (initial startup check).✗
Incorrect
readinessProbe determines if a container can accept traffic. When it fails, the pod is removed from Service endpoints. This is different from livenessProbe (restart if fails) and startupProbe (initial startup check).Question 26
In iptables mode, kube-proxy supports advanced load balancing algorithms like least-connection and round-robin with weights.
✓
Correct!
iptables mode only provides random selection among backends (statistically distributing traffic). Advanced load balancing algorithms like round-robin, least-connection, and weighted distribution are available in IPVS mode.
✗
Incorrect
iptables mode only provides random selection among backends (statistically distributing traffic). Advanced load balancing algorithms like round-robin, least-connection, and weighted distribution are available in IPVS mode.
Think about the capabilities difference between iptables and IPVS modes.
Question 27
Which statement best describes how kubelet interacts with the API server?
✓
Correct!
kubelet uses the watch mechanism to efficiently monitor the API server for pods assigned to its node (via nodeName field). It also continuously sends status updates (heartbeats, pod status) back to the API server.
✗
Incorrect
kubelet uses the watch mechanism to efficiently monitor the API server for pods assigned to its node (via nodeName field). It also continuously sends status updates (heartbeats, pod status) back to the API server.
Think about the efficiency of watch vs polling, and two-way communication.
Question 28
What happens at each step when kubelet enforces resource limits on a container?
What happens at each step when kubelet enforces resource limits on a container?
Resource Limit Enforcement
Setup: kubelet reads resource requests/limits from pod spec.
Enforcement via cgroups: kubelet configures Linux cgroups to limit container resources.
CPU: When limit reached → container is throttled (slowed down) but continues running.
Memory: When limit exceeded → container is killed with OOMKilled status.
Requests vs Limits: Requests (guarantee) used for scheduling, limits (just promise) enforced by kubelet.
Did you get it right?
✓
Correct!
✗
Incorrect
Question 29
Which of the following are responsibilities of the container runtime (not kubelet)?
✓
Correct!
The container runtime handles image management, creates/manages container namespaces and cgroups, and provides logs. kubelet runs probes and reports pod status to the API server (the runtime reports container state to kubelet, not directly to the API server). Scheduling is the scheduler’s job.
✗
Incorrect
The container runtime handles image management, creates/manages container namespaces and cgroups, and provides logs. kubelet runs probes and reports pod status to the API server (the runtime reports container state to kubelet, not directly to the API server). Scheduling is the scheduler’s job.
Focus on low-level container operations vs orchestration tasks.
Question 30
Why does the Service ClusterIP (e.g., 10.96.100.50) not appear on any network interface in the cluster?
✓
Correct!
Service ClusterIPs are virtual IPs (VIPs) that don’t exist on any actual network interface. They’re used by kube-proxy to create routing rules. When packets arrive destined for a ClusterIP, kernel rules intercept and rewrite them to real pod IPs via DNAT.
✗
Incorrect
Service ClusterIPs are virtual IPs (VIPs) that don’t exist on any actual network interface. They’re used by kube-proxy to create routing rules. When packets arrive destined for a ClusterIP, kernel rules intercept and rewrite them to real pod IPs via DNAT.
Think about the concept of ‘virtual’ IP and where routing actually happens.
Question 31
After a startupProbe succeeds once, it continues running on each periodSeconds interval alongside liveness and readiness probes.
✓
Correct!
startupProbe is a one-shot gate, not a continuous monitor. Its sole job is to disable liveness and readiness probes until the application finishes initializing — protecting slow-starting containers from premature restarts. Once it succeeds, it permanently stops firing for that container’s lifetime. kubelet then hands off to livenessProbe (restart if alive-check fails) and readinessProbe (traffic gating). The common misconception is treating all three probes as continuous background loops — startupProbe is the odd one out.
✗
Incorrect
startupProbe is a one-shot gate, not a continuous monitor. Its sole job is to disable liveness and readiness probes until the application finishes initializing — protecting slow-starting containers from premature restarts. Once it succeeds, it permanently stops firing for that container’s lifetime. kubelet then hands off to livenessProbe (restart if alive-check fails) and readinessProbe (traffic gating). The common misconception is treating all three probes as continuous background loops — startupProbe is the odd one out.
Think about what ‘startup’ implies about when this probe’s job is done.
Question 32
A single centralized kube-proxy instance manages iptables/IPVS rules across all nodes in the cluster.
✓
Correct!
kube-proxy runs as a DaemonSet — one instance per node. Each independently watches the API server for Service and Endpoint changes, then maintains its own local iptables/IPVS rules. This per-node design is what makes routing efficient: when a packet arrives at a node, the kernel applies local rules without contacting any other node or central process. A centralized proxy would be a single point of failure and a bottleneck; the distributed model means kube-proxy failure on one node only affects routing updates on that node.
✗
Incorrect
kube-proxy runs as a DaemonSet — one instance per node. Each independently watches the API server for Service and Endpoint changes, then maintains its own local iptables/IPVS rules. This per-node design is what makes routing efficient: when a packet arrives at a node, the kernel applies local rules without contacting any other node or central process. A centralized proxy would be a single point of failure and a bottleneck; the distributed model means kube-proxy failure on one node only affects routing updates on that node.
Think about how Kubernetes typically deploys node-level agents.
Question 33
kube-proxy on a node crashes and is not restarted. Which of the following best describes the immediate impact on that node?
✓
Correct!
kube-proxy writes rules into the kernel and then exits the packet path entirely — the kernel applies those rules independently. If kube-proxy crashes, the existing iptables/IPVS rules remain intact and traffic continues flowing normally. The damage is staleness: new pod additions, pod terminations, and Service updates won’t be reflected on that node’s rules until kube-proxy recovers. Option A reflects the misconception that kube-proxy actively forwards packets (it doesn’t — it’s a rule creator, not a proxy in the traditional sense). Option C describes node failure eviction, not kube-proxy failure. Option D conflates kube-proxy with CoreDNS — DNS resolution is entirely separate.
✗
Incorrect
kube-proxy writes rules into the kernel and then exits the packet path entirely — the kernel applies those rules independently. If kube-proxy crashes, the existing iptables/IPVS rules remain intact and traffic continues flowing normally. The damage is staleness: new pod additions, pod terminations, and Service updates won’t be reflected on that node’s rules until kube-proxy recovers. Option A reflects the misconception that kube-proxy actively forwards packets (it doesn’t — it’s a rule creator, not a proxy in the traditional sense). Option C describes node failure eviction, not kube-proxy failure. Option D conflates kube-proxy with CoreDNS — DNS resolution is entirely separate.
Recall which component actually processes packets versus which component writes rules and then steps aside.
Question 34
kubelet sends heartbeats to the API server every _____ seconds by default.
✓
Correct!
kubelet sends node status heartbeats every 10 seconds by default. The node-monitor-grace-period is ~40 seconds, meaning the node is marked NotReady after roughly 4 consecutive missed heartbeats. This interval isn’t arbitrary — it’s tuned to tolerate brief network blips without triggering false NotReady events while still detecting genuine failures quickly. Understanding the heartbeat rate helps reason about the ~40s/~5m thresholds for NotReady and pod eviction.
✗
Incorrect
kubelet sends node status heartbeats every 10 seconds by default. The node-monitor-grace-period is ~40 seconds, meaning the node is marked NotReady after roughly 4 consecutive missed heartbeats. This interval isn’t arbitrary — it’s tuned to tolerate brief network blips without triggering false NotReady events while still detecting genuine failures quickly. Understanding the heartbeat rate helps reason about the ~40s/~5m thresholds for NotReady and pod eviction.
The node-monitor-grace-period is ~40 seconds — how many missed beats does that represent?
Question 35
Which of the following are valid eviction signals that kubelet monitors when a node is under resource pressure?
✓
Correct!
kubelet monitors four eviction signal categories: memory.available (available RAM), nodefs.available (disk space for volumes and pod logs), imagefs.available (disk space for container images and layers), and pid.available (process ID exhaustion). CPU pressure is notably absent — when CPU is saturated, throttling handles it via cgroups without evicting pods. Network pressure is managed at a different layer and doesn’t trigger eviction. Configuring eviction thresholds for nonexistent signals like cpu.available silently has no effect.
✗
Incorrect
kubelet monitors four eviction signal categories: memory.available (available RAM), nodefs.available (disk space for volumes and pod logs), imagefs.available (disk space for container images and layers), and pid.available (process ID exhaustion). CPU pressure is notably absent — when CPU is saturated, throttling handles it via cgroups without evicting pods. Network pressure is managed at a different layer and doesn’t trigger eviction. Configuring eviction thresholds for nonexistent signals like cpu.available silently has no effect.
CPU handles pressure through throttling, not eviction. Which resource types can be genuinely ‘full’?
Question 36
In modern Kubernetes clusters (1.21+), kube-proxy exclusively watches Endpoints objects to determine which pod IPs to include in routing rules.
✓
Correct!
Starting in Kubernetes 1.21, kube-proxy defaults to watching EndpointSlice objects rather than Endpoints. EndpointSlices shard large backend lists into smaller objects (default max: 100 endpoints per slice). When a single pod is added or removed, only the affected slice is updated — instead of retransmitting the entire endpoints list. Endpoints still exist for backward compatibility, but modern kube-proxy uses EndpointSlices for scalability. This matters when debugging: a Service may appear correct in Endpoints but routing can still be stale if the matching EndpointSlice is inconsistent.
✗
Incorrect
Starting in Kubernetes 1.21, kube-proxy defaults to watching EndpointSlice objects rather than Endpoints. EndpointSlices shard large backend lists into smaller objects (default max: 100 endpoints per slice). When a single pod is added or removed, only the affected slice is updated — instead of retransmitting the entire endpoints list. Endpoints still exist for backward compatibility, but modern kube-proxy uses EndpointSlices for scalability. This matters when debugging: a Service may appear correct in Endpoints but routing can still be stale if the matching EndpointSlice is inconsistent.
Think about what ‘slices’ implies about how endpoints are partitioned at scale.
Question 37
Starting from Kubernetes 1.24, Docker Engine can be used directly as the container runtime without any additional adapter.
✓
Correct!
Docker Engine doesn’t implement the CRI (Container Runtime Interface) natively. Kubernetes previously supported it via dockershim — a built-in CRI-to-Docker translation layer — but this was deprecated in 1.20 and removed entirely in 1.24. After 1.24, clusters that need Docker Engine must use cri-dockerd, a separate adapter maintained outside the Kubernetes project. Most clusters migrated to containerd or CRI-O, which implement CRI natively. Ignoring this when upgrading to 1.24+ causes container startup to fail immediately since kubelet can no longer communicate with Docker.
✗
Incorrect
Docker Engine doesn’t implement the CRI (Container Runtime Interface) natively. Kubernetes previously supported it via dockershim — a built-in CRI-to-Docker translation layer — but this was deprecated in 1.20 and removed entirely in 1.24. After 1.24, clusters that need Docker Engine must use cri-dockerd, a separate adapter maintained outside the Kubernetes project. Most clusters migrated to containerd or CRI-O, which implement CRI natively. Ignoring this when upgrading to 1.24+ causes container startup to fail immediately since kubelet can no longer communicate with Docker.
Docker doesn’t natively implement the interface kubelet uses to talk to runtimes.
Question 38
kubelet uses _____ (three-letter acronym) plugins to mount volumes and manage storage for pods.
✓
Correct!
CSI (Container Storage Interface) is the standardized API through which kubelet interacts with storage plugins — analogous to CRI for container runtimes and CNI for networking. CSI plugins handle volume mounting, lifecycle management, and storage driver interaction, keeping kubelet decoupled from any specific storage implementation. The three interfaces — CRI, CNI, CSI — are kubelet’s extension points for compute, networking, and storage respectively. When a pod mounts a PersistentVolumeClaim, kubelet calls the appropriate CSI driver to attach and mount the underlying storage.
✗
Incorrect
CSI (Container Storage Interface) is the standardized API through which kubelet interacts with storage plugins — analogous to CRI for container runtimes and CNI for networking. CSI plugins handle volume mounting, lifecycle management, and storage driver interaction, keeping kubelet decoupled from any specific storage implementation. The three interfaces — CRI, CNI, CSI — are kubelet’s extension points for compute, networking, and storage respectively. When a pod mounts a PersistentVolumeClaim, kubelet calls the appropriate CSI driver to attach and mount the underlying storage.
It forms a trio with CRI and CNI — think about what the ‘S’ stands for.
Question 39
After a node has been NotReady for approximately 5 minutes, how does the Node Controller trigger eviction of the pods running on that node?
✓
Correct!
The Node Controller applies a
node.kubernetes.io/not-ready:NoExecute taint (or unreachable:NoExecute) to the failed node. Pods without a matching toleration are automatically removed via the taint eviction mechanism. This design is elegant: the Node Controller only needs to set a taint — it doesn’t need to know which pods are running or enumerate them individually. Each pod’s own tolerations determine whether it gets evicted. Option A is wrong because kubelet on a failed node is unreachable — that’s why the taint mechanism exists. Option B is wrong because the control plane doesn’t speak CRI directly; that’s kubelet’s job. Option D is wrong because pods enter Terminating state (not Failed), and it’s the pod’s controller (ReplicaSet, Deployment) — not the scheduler — that creates replacements.✗
Incorrect
The Node Controller applies a
node.kubernetes.io/not-ready:NoExecute taint (or unreachable:NoExecute) to the failed node. Pods without a matching toleration are automatically removed via the taint eviction mechanism. This design is elegant: the Node Controller only needs to set a taint — it doesn’t need to know which pods are running or enumerate them individually. Each pod’s own tolerations determine whether it gets evicted. Option A is wrong because kubelet on a failed node is unreachable — that’s why the taint mechanism exists. Option B is wrong because the control plane doesn’t speak CRI directly; that’s kubelet’s job. Option D is wrong because pods enter Terminating state (not Failed), and it’s the pod’s controller (ReplicaSet, Deployment) — not the scheduler — that creates replacements.Think about the taint/toleration mechanism and why it’s well-suited for a node the control plane can’t directly reach.
Quiz Results
Score
0/0
Accuracy
0%
Right
0
Wrong
Skipped
0
Last updated on