Linux カーネルの概要
サポート対象バージョン: Linux 6.1 / 6.12 / 6.18 (Amazon Linux 2023)、Kubernetes 1.33 以降 (Amazon EKS) 最終更新日: 2026年9月12日
このセクションの内容
- コンテナと Kubernetes が実際に動作する基盤: namespace、cgroup、netfilter、conntrack の背後にあるカーネル機能
- Pod から NIC までカーネル内をパケットが通る経路と、各ポイントで観測・調整できる内容
- カーネルパラメータが EKS ノードのワークロード性能と安定性に与える影響、および変更すべき設定とそのままにすべき設定
このセクションを設ける理由
Kubernetes のドキュメントの多くは、宣言型 API の上位レイヤーを説明します。Pod を作成するとコンテナが起動し、Service を作成するとトラフィックが分散され、リソース制限を設定するとコンテナはその上限を超えて使わない、という具合です。
しかし、インシデントを診断するときに必要な知識は、その一つ下のレイヤーにあります。
| 本番環境で遭遇する症状 | カーネルレイヤーでの実情 |
|---|---|
| 「Pod が OOMKilled になったが、コンテナのメモリ使用量は制限値未満だった」 | cgroup v2 の memory.current にはページキャッシュが含まれます。RSS だけを見ても不十分です |
| 「ノード上の新しい接続が気付かれないまま破棄される」 | ほかのパケット破棄要因と合わせて、conntrack の件数/最大値、挿入/破棄カウンター、カーネルログを調査します |
| 「CPU 制限を設定したら p99 が不安定になった」 | CFS/EEVDF のスロットリングです。使用率は低くても、タスクは各期間で強制停止されます |
| 「同じノード上の Pod 間の通信が異常に速い」 | veth ペアだけを通り、NIC を経由しません |
| 「Service ルールが数千個あり、レイテンシが上がった」 | iptables モードの kube-proxy ではルールが線形に評価されます |
これらの原因は Kubernetes API レイヤーからは見えません。 このギャップを埋めることが、このセクションの目的です。
対象読者と前提条件
- EKS/Kubernetes の運用経験があり、リソース制約やネットワーク障害を直接診断する必要があるインフラストラクチャエンジニア
- 基本的な Linux コマンドとプロセスの概念を理解していることを前提とします
- カーネルソースの読解やモジュール作成は対象外です。運用担当者が観測および調整できる内容に焦点を当てます
ドキュメント構成
| # | ドキュメント | 解説する内容 |
|---|---|---|
| 1 | コンテナを支えるカーネル機能 | コンテナは何で構成されているか。cgroup v1 から v2 への変更が運用上重要なのはなぜか |
| 2 | カーネルのネットワークスタック | ソケットから NIC までパケットはどの経路を通るか。フックを挿入できる場所はどこか |
| 3 | EKS ノードのカーネル調整 | どのパラメータを、いつ変更すべきか。デフォルトのままにするのが適切なのはどのような場合か |
このセクションの読み方
ドキュメント 1 は 2 と 3 の前提となります。cgroup と namespace を知らないと、ドキュメント 3 の調整項目が該当箇所で理解できません。
ネットワークの問題を診断するためにこのセクションを開いた場合は、ドキュメント 2 とドキュメント 3 のネットワークに関する部分で十分です。リソースの問題 (OOM、CPU スロットリング) の場合は、ドキュメント 1 の cgroup セクション → ドキュメント 3 のメモリ/CPU セクションを確認してください。
関連ドキュメント
- Linux の基礎 / Linux の運用: コマンドと基本操作
- コンテナ技術: コンテナランタイムとイメージレイヤー
- eBPF の基礎: eBPF のプログラムタイプと用途
- ネットワークの基礎 パート 1: レイヤーモデルからクラウドまで
- Pod ネットワークのベンチマーク: このセクションの理論に対応する測定
- リソースの最適化: requests/limits の設計
- VPC Lattice カーネルデータパス: リンクローカルインターセプトにおけるカーネルレイヤー
正確性に関する注意
カーネルの動作はバージョンによって変わり、特にチューニング項目はカーネルバージョン間で場所が変わったり、名前が変更されたりします (sysctl → debugfs など)。このセクションは AL2023 に含まれるカーネル系列 (6.1 / 6.12 / 6.18) に基づいており、バージョン依存の項目では対象バージョンを明記しています。
公式ドキュメントで確認できていない内容は、事実として記述せず Needs verification ブロックで示します。本番クラスターにパラメータを適用する前に、必ず対象ノードのカーネルバージョンで実際の値を直接確認してください。