cgroup v2 は、統一された階層と改善されたメモリ管理メカニズムを使用し、将来の Kubernetes バージョンの拡張機能と互換性があります。ノードをデフォルトで cgroup v2 を有効にする新しいオペレーティングシステムに移行することで、クラスターの安定性とリソース管理の効率が向上します。
Cgroup バージョンガイド
Linux カーネルは、cgroup v1 と cgroup v2 の 2 つのバージョンの cgroup を提供します。cgroup は、CPU、メモリ、I/O などの、プロセスグループが使用する物理リソースを制限、計算、分離します。cgroup v2 は次世代の cgroup インターフェイスです。cgroup v1 の複数のコントローラー階層の問題を解決し、より一貫性のあるリソース制御を提供します。2 つのバージョンは、共通のインターフェイスとサブシステムの編成方法が異なります。cgroup ファイルシステムに直接アクセスするアプリケーションは、互換性のために更新する必要があります。
詳細については、「cgroup v1 と cgroup v2 の違い」をご参照ください。
バージョン 1.31 以降、Kubernetes は cgroup v1 のサポートをメンテナンスモードに移行しました。そのため、cgroup v2 への移行が推奨されます。cgroup v2 の主な利点は次のとおりです：
安定性の向上：cgroup v2 は統一されたメモリアカウンティングモデルを使用してページキャッシュを効果的に管理します。これにより、cgroup v1 でディスク I/O が高いアプリケーションがメモリを占有し、他のアプリケーションが Out-of-Memory (OOM) イベントによって強制終了される問題が解決されます。
統一階層：CPU やメモリなどのすべてのリソースコントローラーが単一の階層で編成されます。これにより、cgroup v1 の複数階層における構成の競合や管理の複雑さが回避され、リソースの表示とポリシーの定義が簡素化されます。
リソースの可観測性の向上：cgroup v2 では Pressure Stall Information (PSI) が導入されています。PSI は、アプリケーションが CPU、メモリ、または I/O リソースを待機している間にブロックされた時間を定量化します。これにより、パフォーマンスのボトルネックを分析するための詳細なメトリックが提供されます。
ノードの cgroup バージョンの確認
移行する前に、ノードにログインし、次のコマンドを実行して現在の cgroup バージョンを確認します。
# ターゲットノードにログインした後にこのコマンドを実行します
stat -fc %T /sys/fs/cgroup/
# 期待される出力：
# cgroup2fs --> cgroup v2 を示します
# tmpfs --> cgroup v1 を示します
移行手順
ノードレベル：オペレーティングシステムの変更
Container Service for Kubernetes (ACK) クラスターノードの cgroup バージョンは、そのオペレーティングシステムによって決まります。移行するには、ノードプールレベルでオペレーティングシステムを cgroup v2 をサポートする新しいバージョンに変更する必要があります。ACK では、デフォルトで cgroup v2 を使用するオペレーティングシステムには、Alibaba Cloud Linux 3.2104 LTS 64 ビットコンテナ最適化版、Alibaba Cloud Linux 4 LTS 64 ビットコンテナ最適化版、ContainerOS 3.3 以降、RHEL 9 以降、Ubuntu 22 以降が含まれます。
詳細については、「オペレーティングシステムの変更」をご参照ください。
アプリケーションレベル: ワークロードの互換性の確保
cgroup v1 と v2 のファイルシステムの構造とパラメーター名は互換性がないため、/sys/fs/cgroup パスを直接読み取るアプリケーションは、cgroup v2 をサポートするように検証またはアップグレードする必要があります。
カテゴリ | 説明 |
Java アプリケーション |
|
Go アプリケーション | uber-go/automaxprocs パッケージを使用している場合は、v1.5.1 以降にアップグレードしてください。 |
cAdvisor | cAdvisor をスタンドアロンの DaemonSet として使用して Pod とコンテナーをモニターする場合は、v0.43.0 以降に更新してください。 |
Nginx Ingress | 古いバージョンでは、cgroup v2 の CPU コア情報を正しく解析できない場合があります。これにより、過剰なメモリ使用量が発生し、OOM イベントがトリガーされる可能性があります。 v1.11.2 以降にアップグレードしてください。詳細については、「GitHub Issue #9665」をご参照ください。 ACK Nginx Ingress Controller をアップグレードする際は、「Nginx Ingress Controller コンポーネントをアップグレードする」をご参照ください。 |
注意すべきその他のアプリケーションとコンポーネント
サードパーティのモニタリングおよび APM エージェント：Prometheus Node Exporter、Datadog Agent、SkyWalking などのツールは、cgroupfs データソースに依存してノードまたはコンテナーのメトリックを収集します。cgroup v2 と互換性のないバージョンでは、データが欠落したり異常になったりする可能性があります。公式ドキュメントを確認し、cgroup v2 を明示的にサポートするバージョンにアップグレードしてください。
セキュリティおよび監査ツール：Falco や Sysdig などのツールは、cgroup 情報を使用してイベントをそのソースに関連付けます。コンポーネントのバージョンに互換性がない場合、検出ルールが失敗したり、誤検知が発生したりする可能性があります。互換性のあるバージョンにアップグレードし、ステージング環境でルールの有効性を確認してください。
パフォーマンスに敏感なアプリケーションとカスタムスクリプト：一部のアプリケーション起動スクリプトは、CPU クォータに基づいてスレッド数を設定するなど、自動チューニングのために cgroup ファイルを読み取ります。このロジックは、パスの変更により cgroup v2 では失敗します。関連するスクリプトを確認し、cgroup v2 と互換性のある方法でデータを読み取るように更新してください。
本番環境に関する推奨事項
アプリケーションの互換性
カスタムアプリケーションやスクリプトを確認し、
cpu.cfs_quota_usのような cgroup v1 ファイルシステムに依存していないことを確認してください。ファイルシステムインターフェイスに互換性がないため、このロジックは cgroup v2 では失敗し、更新する必要があります。カスタムノード構成
オペレーティングシステムを変更すると、ノードがリセットされます。すべてのカスタム変更は、ノードプールの機能を使用して永続化する必要があります。そうしないと、ノードが再構築された後に変更が失われます。関連する構成方法と注意事項については、以下をご参照ください：
モニタリングとアラート：Alibaba Cloud Prometheus Monitoring を有効にして、クラスター全体の健全性と主要なコンテナーのリソース使用量の傾向を継続的に監視します。これにより、異常を迅速に検出できます。