Cloud Native Operations

English

한국어

English

한국어

Appearance

EKS Node Kernel Tuning Quiz ​

This quiz tests your understanding of parameter application paths, kernel version transitions, and justified tuning.

Multiple Choice Questions ​

  1. What are the three problems unfounded kernel tuning creates?
    • A) Security vulnerabilities, license violations, loss of support
    • B) Unreproducible configuration, breakage on kernel upgrade, defeating kernel auto-tuning
    • C) Reduced network bandwidth, increased disk usage, memory leaks
    • D) Pod scheduling failures, image pull failures, authentication failures
Show Answer

Answer: B) Unreproducible configuration, breakage on kernel upgrade, defeating kernel auto-tuning

Explanation: Values differing per node make incidents hard to reproduce. Tunable names and locations move between kernel versions (sysctl → debugfs, and so on), so a setting valid on 6.1 can break on 6.18. Explicit per-socket SO_RCVBUF/SO_SNDBUF settings disable the corresponding socket's automatic sizing; changing tcp_rmem/tcp_wmem bounds does not by itself disable autotuning. So the precondition for tuning is measurement — correlate the symptom with relevant counters and adjust only settings supported by that evidence.

  1. What must you know about AL2023's kernel version transition as of 2026?
    • A) AL2023 offers only kernel 6.1
    • B) A refreshed default/latest AMI can select a new kernel, while a pinned AMI ID remains unchanged
    • C) The kernel version is determined automatically by the EKS control plane version
    • D) AL2023 does not support kernel upgrades
Show Answer

Answer: B) A refreshed default/latest AMI can select a new kernel, while a pinned AMI ID remains unchanged

Explanation: Verify the AMI selected by the launch template/provisioner and the running kernel. EKS-optimized AMI releases have their own selection; replacing a node alone is not proof of a kernel upgrade.

  1. What is the most common root cause of CPU throttling, and the first response?
    • A) Insufficient node CPU — move to a larger instance type
    • B) A mismatch between the CPU count the application perceives and its quota — align GOMAXPROCS, -XX:ActiveProcessorCount, etc., with the limit
    • C) A kernel scheduler bug — upgrade the kernel
    • D) A cgroup v2 migration problem — revert to v1
Show Answer

Answer: B) A mismatch between the CPU count the application perceives and its quota — align GOMAXPROCS, -XX:ActiveProcessorCount, etc., with the limit

Explanation: If the runtime inside the container sees all node cores and spawns that many threads, it burns the CPU limit's quota instantly. With 4 threads running concurrently, a 20ms quota is consumed in 5ms of wall time and the remaining 95ms is waiting. So the first response is aligning the perceived CPU count with the limit, followed by raising the limit, followed by considering limit removal for extremely sensitive cases.

  1. What is more effective than kernel tuning for node stability, and why?
    • A) Limiting Pod count — lower density avoids problems
    • B) kubelet resource reservations and eviction thresholds — insufficient reservation leads to the kernel or kubelet itself hitting OOM, taking the whole node NotReady, and eviction is better than a kernel OOM
    • C) A node restart schedule — periodic restarts to clean up memory
    • D) Smaller images — freeing disk headroom
Show Answer

Answer: B) kubelet resource reservations and eviction thresholds — insufficient reservation leads to the kernel or kubelet itself hitting OOM, taking the whole node NotReady, and eviction is better than a kernel OOM

Explanation: With insufficient --system-reserved and --kube-reserved, Pods consume all node memory and the kernel or kubelet hits OOM. The node goes NotReady and every Pod on it is affected — far worse than an individual Pod OOM. Eviction is Kubernetes moving a Pod in a controlled way while the OOM killer abruptly kills a process, so the goal is setting --eviction-hard so Kubernetes intervenes before a kernel OOM.

  1. Why does PSI (Pressure Stall Information) give a better signal than usage metrics?
    • A) It measures usage more accurately
    • B) It reports the fraction of time stalled on that resource rather than usage, so it reveals time spent on reclaim or contention even when the usage graph looks calm
    • C) It is collected in hardware rather than the kernel
    • D) It retains historical data automatically
Show Answer

Answer: B) It reports the fraction of time stalled on that resource rather than usage, so it reveals time spent on reclaim or contention even when the usage graph looks calm

Explanation:some avg10 in memory.pressure is the fraction of the last 10 seconds in which at least one task was stalled on that resource. With memory usage sitting calmly below the limit, a climbing value means time is going into page cache reclaim — something a usage graph alone will not show. It is provided by cgroup v2, node-wide at /proc/pressure/* and per cgroup at <cgroup>/memory.pressure.

  1. Which of the following is NOT a representative case of "justified tuning"?
    • A) vm.max_map_count — OpenSearch-family software fails to start at the default
    • B) net.core.somaxconn — evidence available from the accept-queue overflow counter
    • C) Changing TCP buffer settings without a measured BDP/memory problem or understanding the per-socket override
    • D) net.ipv4.ip_local_port_range — source port exhaustion shows up directly as connection failures
Show Answer

Answer: C) Changing TCP buffer settings without a measured BDP/memory problem or understanding the per-socket override

Explanation: tcp_rmem/tcp_wmem define sizing bounds/defaults; changing them does not by itself disable autotuning. Explicit SO_RCVBUF/SO_SNDBUF disables the corresponding socket’s automatic sizing.

  1. Which value cannot be changed via a Pod's securityContext.sysctls?
    • A) Many net.* values that are settable per net namespace
    • B) net.netfilter.nf_conntrack_max — a node-global value
    • C) TCP-related values belonging to the Pod's net namespace
    • D) All of the above are changeable
Show Answer

Answer: B) net.netfilter.nf_conntrack_max — a node-global value

Explanation: Many net.* values are settable per net namespace and can be changed via Pod securityContext.sysctls. By contrast vm.*, fs.*, and some values like net.netfilter.nf_conntrack_max are node-global and require the node bootstrap or Bottlerocket settings path. Also, kubelet rejects "unsafe" sysctls by default, so allowing one requires --allowed-unsafe-sysctls, which is itself a node setting.

  1. What matters most long-term in managing kernel parameter changes?
    • A) Always upgrading to the newest kernel
    • B) Managing as code, recording the rationale in comments, and separating node groups by workload character
    • C) Forcing one identical tuning profile on every node
    • D) Applying changes to production immediately
Show Answer

Answer: B) Managing as code, recording the rationale in comments, and separating node groups by workload character

Explanation: Codifying with Karpenter EC2NodeClass, launch templates, or Bottlerocket settings prevents values differing per node. Without a comment on "why this value," nobody can revert it six months later. Different workload characters need different tuning, so separate node groups rather than forcing one profile. Add to that pinning or planning the kernel transition, verifying actual values after applying (especially conntrack), and measuring before and after under identical conditions.