はじめに
Part 1ではコンテナランタイムの基礎とcgroup v1の仕組みを概説した。本稿では、より実践的なレイヤーに踏み込み、cgroup v2への移行とNUMAアーキテクチャを意識したCPUピニングを中心に解説する。大規模クラスタで数千ポッドを安定稼働させるためには、カーネルパラメータとハードウェアトポロジを正確に把握することが不可欠だ。
cgroup v2 が変えたリソース管理の考え方
cgroup v1では、サブシステム(cpu, memory, blkioなど)がそれぞれ独立した階層を持っていたため、設定の整合性を保つのが難しかった。cgroup v2では単一の統合階層に統合され、リソース制御の一貫性が大幅に向上している [Source: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html]。
Kubernetes 1.25以降では--cgroup-driver=systemdとcgroupv2の組み合わせが推奨構成となっており、以下のようにノードのcgroupバージョンを確認できる。
# cgroupバージョンの確認 stat -fc %T /sys/fs/cgroup/ # cgroup2fs と表示されればv2が有効 Memory QoSの実装
cgroup v2で新たに導入されたmemory.highは、OOM Killerを発動させずにメモリ圧力をプロセスにフィードバックする機能だ。これにより、バースト的なメモリ使用が他のコンテナに波及するリスクを軽減できる。
# memory.high を設定する例 (バイト単位) echo $((512 * 1024 * 1024)) > /sys/fs/cgroup/kubepods/pod<UID>/memory.high KubernetesではPodのQoSクラス(Guaranteed / Burstable / BestEffort)に応じてこの値が自動計算されるが、DaemonSetなど特定ワークロードでは手動チューニングが有効なケースがある。
NUMAトポロジとCPUピニング
物理サーバが複数のNUMAノードを持つ場合、コンテナがNUMAノードをまたいでメモリアクセスするとレイテンシが大幅に増加する。これをNUMAペナルティと呼ぶ。
Linuxカーネルのトポロジ情報は/sys/devices/system/node/以下で確認できる。
# NUMAノードとCPUの対応を確認 numactl --hardware # 出力例 # node 0 cpus: 0 1 2 3 4 5 ... 31 # node 1 cpus: 32 33 34 ... 63 KubernetesではTopology Managerを有効化することで、CPUとメモリを同一NUMAノードに割り当てる制御が可能になる [Source: https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/]。
# kubelet設定 (kubelet-config.yaml) apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration topologyManagerPolicy: single-numa-node cpuManagerPolicy: static single-numa-nodeポリシーを設定すると、スケジューラはGuaranteed QoSクラスのPodを単一NUMAノード内に収まるCPU・メモリの組み合わせにのみ配置する。これにより、レイテンシクリティカルなワークロード(高頻度取引システム、リアルタイム動画処理など)で数十ミリ秒単位の改善が期待できる。
実践: CPUマネージャとHugePagesの組み合わせ
NUMA最適化をさらに強化するには、HugePagesの活用も検討する価値がある。通常の4KBページに比べ、2MBや1GBのHugePagesはTLBミスを大幅に削減し、メモリ帯域幅を有効活用できる。
# Podマニフェスト例 resources: requests: cpu: "4" memory: "8Gi" hugepages-2Mi: "512Mi" limits: cpu: "4" memory: "8Gi" hugepages-2Mi: "512Mi" HugePagesはGuaranteed QoSでのみ安定動作するため、requestsとlimitsを完全一致させること。また、コンテナ内のアプリケーション側でもmmapフラグMAP_HUGETLBを明示的に指定する必要がある点に注意したい。
パフォーマンス計測の基本ツールセット
カーネルレベルのチューニングを施した後は、定量的な効果測定が必須だ。以下のツールを組み合わせると、ボトルネックの所在が明確になる。
| ツール | 目的 |
|---|---|
perf stat | CPUサイクル・キャッシュミス計測 |
numastat | NUMAノード別メモリアクセス統計 |
bpftrace | カーネルイベントのリアルタイムトレース |
cgroup_exporter | cgroupメトリクスのPrometheus連携 |
特にbpftraceはカーネルスペースのイベントをほぼオーバーヘッドなしに観測できるため、本番環境での一時的なデバッグに向いている。
まとめと次回予告
Part 2では、cgroup v2の統合階層モデルとNUMAトポロジを意識したCPUピニング、HugePagesを用いたメモリ最適化を解説した。これらを組み合わせることで、大規模コンテナ環境におけるリソース競合とレイテンシ増大を体系的に抑制できる。
Part 3では、eBPFを用いたネットワーク最適化と、コンテナセキュリティの観点からseccompプロファイルとAppArmorポリシーの実装手順を取り上げる予定だ。カーネル・CPU・ネットワーク・セキュリティを一気通貫で理解することで、真の意味での大規模運用基盤が構築できる。
Category: 開発 | Tags: kubernetes, linux, container
0 件のコメント:
コメントを投稿