Worker Node Components Quiz
Quiz
resources:
requests:
memory: 128Mi
limits:
memory: 512MiContainer Runtime Interface (CRI)
A standardized gRPC API that allows Kubernetes (specifically kubelet) to work with different container runtimes (containerd, CRI-O, etc.) without being tied to a specific implementation. It abstracts image management, container lifecycle, and execution operations.
Did you get it right?
_____:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10livenessProbe 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?).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?).Virtual IP (VIP)
The Service ClusterIP doesn’t exist on any network interface in the cluster. It’s not assigned to any device. Instead, it’s a placeholder IP that kube-proxy uses to create iptables/IPVS rules. When packets are sent to this IP, kernel rules intercept and rewrite them to real pod IPs. The ClusterIP exists only in routing rules, not as an actual network address.
Did you get it right?
# Default Kubernetes node monitoring settings
node-monitor-period: 5s
node-monitor-grace-period: 40s
pod-eviction-timeout: 5mQoS 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?
_____:
httpGet:
path: /ready
port: 8080
periodSeconds: 5readinessProbe 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).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).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?