EKSノードのカーネルチューニングクイズ

このクイズでは、パラメーターの適用経路、カーネルバージョンの移行、根拠のあるチューニングについて理解度を確認します。

多肢選択問題

1. 根拠のないカーネルチューニングによって生じる3つの問題は何ですか？
   • A) セキュリティ脆弱性、ライセンス違反、サポートの喪失
   • B) 再現できない設定、カーネルアップグレード時の破損、カーネルの自動調整機能の無効化
   • C) ネットワーク帯域の低下、ディスク使用量の増加、メモリリーク
   • D) Podのスケジューリング失敗、イメージpullの失敗、認証失敗

回答を表示

回答: B) 再現できない設定、カーネルアップグレード時の破損、カーネルの自動調整機能の無効化

解説: ノードごとに値が異なると、インシデントの再現が難しくなります。調整可能なパラメーターの名前や場所はカーネルバージョン間で移動することがあり（sysctlからdebugfsなど）、6.1では有効な設定が6.18で壊れる場合があります。ソケットごとに明示的なSO_RCVBUF/SO_SNDBUFを設定すると、そのソケットの自動サイズ調整が無効になります。一方、tcp_rmem/tcp_wmemの範囲を変えただけでは自動調整は無効になりません。そのため、チューニングの前提は測定です。症状と関連するカウンターを照合し、証拠が裏付ける設定だけを調整してください。

2. 2026年時点で、AL2023のカーネルバージョン移行について何を把握しておくべきですか？
   • A) AL2023はカーネル6.1だけを提供する
   • B) 更新されたデフォルト/最新AMIでは新しいカーネルが選択される場合があるが、AMI IDを固定すれば変わらない
   • C) カーネルバージョンはEKSコントロールプレーンのバージョンで自動的に決まる
   • D) AL2023はカーネルアップグレードをサポートしない

回答を表示

回答: B) 更新されたデフォルト/最新AMIでは新しいカーネルが選択される場合があるが、AMI IDを固定すれば変わらない

解説: 起動テンプレート/プロビジョナーが選択したAMIと、実行中のカーネルを確認してください。EKS最適化AMIのリリースでは独自の選択方法が使われます。ノードを置き換えただけでは、カーネルがアップグレードされた証拠になりません。

3. CPU throttlingの最も一般的な根本原因と、最初に行うべき対応は何ですか？
   • A) ノードのCPUが不足しているため、より大きなインスタンスタイプに変更する
   • B) アプリケーションが認識するCPU数とクォータが一致していない。制限に合わせてGOMAXPROCS、-XX:ActiveProcessorCountなどを調整する
   • C) カーネルスケジューラーのバグなのでカーネルをアップグレードする
   • D) cgroup v2の移行問題なのでv1へ戻す

回答を表示

回答: B) アプリケーションが認識するCPU数とクォータが一致していない。制限に合わせてGOMAXPROCS、-XX:ActiveProcessorCountなどを調整する

解説: コンテナ内のランタイムがノードの全コアを認識して同じ数のスレッドを起動すると、CPU制限のクォータをすぐに使い切ります。4つのスレッドが同時実行されると、20msのクォータは実時間の5msで消費され、残りの95msは待ちます。まず、アプリケーションが認識するCPU数を制限に合わせ、次に制限を引き上げ、それでも必要な非常に高感度なケースでは制限を外すことを検討します。

4. ノードの安定性にはカーネルチューニングより何が効果的ですか。また、その理由は何ですか？
   • A) Pod数の制限。密度を下げて問題を避ける
   • B) kubeletのリソース予約とeviction threshold。不十分な予約ではカーネルまたはkubelet自体がOOMになり、ノード全体がNotReadyになる。カーネルOOMよりevictionの方が望ましい
   • C) メモリを解放するための定期的なノード再起動スケジュール
   • D) ディスクの余裕を確保するための小さいイメージ

回答を表示

回答: B) kubeletのリソース予約とeviction threshold。不十分な予約ではカーネルまたはkubelet自体がOOMになり、ノード全体がNotReadyになる。カーネルOOMよりevictionの方が望ましい

解説:--system-reservedと--kube-reservedが不十分だと、Podがノードメモリをすべて使い、カーネルやkubeletがOOMになります。ノードはNotReadyとなり、その上のすべてのPodに影響するため、個別PodのOOMより深刻です。evictionではKubernetesがPodを制御された形で移動しますが、OOM killerはプロセスを突然終了します。カーネルOOMになる前にKubernetesが介入できるよう、--eviction-hardを設定することが目標です。

5. PSI（Pressure Stall Information）が使用量メトリクスより優れたシグナルになるのはなぜですか？
   • A) 使用量をより正確に測定する
   • B) 使用量ではなく、リソース待ちで停止した時間の割合を報告するため。使用量グラフが平穏でも、reclaimや競合に費やす時間を示せる
   • C) カーネルではなくハードウェアが収集する
   • D) 履歴データを自動的に保持する

回答を表示

回答: B) 使用量ではなく、リソース待ちで停止した時間の割合を報告するため。使用量グラフが平穏でも、reclaimや競合に費やす時間を示せる

解説:memory.pressureのsome avg10は、過去10秒間に少なくとも1つのタスクがそのリソースで停止していた時間の割合です。メモリ使用量が上限を十分下回って安定していても値が上昇していれば、ページキャッシュのreclaimなどに時間が使われています。使用量グラフだけでは分からない情報です。これはcgroup v2で提供され、/proc/pressure/*ではノード全体の値を、<cgroup>/memory.pressureではcgroupごとの値を確認できます。

6. 次のうち、「根拠のあるチューニング」の代表例ではないものはどれですか？
   • A) OpenSearch系のソフトウェアがデフォルト値で起動できない場合のvm.max_map_count
   • B) accept queue overflowカウンターの証拠がある場合のnet.core.somaxconn
   • C) 測定済みのBDP/メモリ問題やソケット単位の上書きを理解せずにTCPバッファー設定を変更する
   • D) ソースポートの枯渇が接続失敗に直接現れる場合のnet.ipv4.ip_local_port_range

回答を表示

回答: C) 測定済みのBDP/メモリ問題やソケット単位の上書きを理解せずにTCPバッファー設定を変更する

解説:tcp_rmem/tcp_wmemはサイズの範囲やデフォルトを定義しますが、変更しても自動調整が単独で無効になるわけではありません。SO_RCVBUF/SO_SNDBUFを明示的に設定すると、対応するソケットの自動サイズ調整が無効になります。

7. PodのsecurityContext.sysctlsでは変更できない値はどれですか？
   • A) net namespaceごとに設定可能な多くのnet.*値
   • B) ノード全体の値であるnet.netfilter.nf_conntrack_max
   • C) Podのnet namespaceに属するTCP関連の値
   • D) 上記すべてを変更できる

回答を表示

回答: B) ノード全体の値であるnet.netfilter.nf_conntrack_max

解説: 多くのnet.*値はnet namespaceごとに設定でき、PodのsecurityContext.sysctlsから変更できます。一方、vm.*、fs.*やnet.netfilter.nf_conntrack_maxのような一部の値はノード全体に適用されるため、ノードのbootstrapまたはBottlerocket設定経路が必要です。また、kubeletはデフォルトで「unsafe」sysctlを拒否します。許可するにはノード設定である--allowed-unsafe-sysctlsが必要です。

8. カーネルパラメーターの変更を長期的に管理する上で、最も重要なことは何ですか？
   • A) 常に最新のカーネルへアップグレードする
   • B) 設定をコードとして管理し、コメントに根拠を記録し、ワークロード特性ごとにノードグループを分ける
   • C) すべてのノードに同じチューニングプロファイルを強制する
   • D) 本番環境にすぐ変更を適用する

回答を表示

回答: B) 設定をコードとして管理し、コメントに根拠を記録し、ワークロード特性ごとにノードグループを分ける

解説: KarpenterのEC2NodeClass、起動テンプレート、Bottlerocketの設定で値をコード化すると、ノードごとに値が異なるのを防げます。「なぜこの値なのか」というコメントがなければ、6か月後に誰も元へ戻せなくなる場合があります。ワークロード特性によって必要なチューニングは異なるため、1つのプロファイルを強制せずノードグループを分けてください。加えて、カーネル移行を固定または計画し、適用後に実際の値を確認（特にconntrack）し、条件を揃えて前後を測定します。