Kubernetes クラスターのワークロードが増加するにつれて、ノードの管理は複雑になります。アプリケーションごとに異なるインスタンスタイプ、OS イメージ、課金方法、運用保守 (O&M) 戦略が必要になるためです。ノードプールを使用すると、クラスターノードを同じ構成を共有する論理グループに整理できるため、単一の Container Service for Kubernetes (ACK) クラスター内で、異なるノードセットに異なる設定やメンテナンスポリシーを適用できます。
単一のクラスターには、異なる構成を持つ複数のノードプールを含めることができます。例:
OS イメージの混在:同一クラスター内で ContainerOS、Alibaba Cloud Linux、Windows を使用
コンテナランタイムの混在:同一クラスター内で containerd、Docker、Sandboxed-Container を使用
課金方法の混在:同一クラスター内で従量課金、サブスクリプション、プリエンプティブルインスタンスによる支払いを併用
複数のノードプールで個別にオートスケーリングを有効化
ノードプールのタイプ
ACK は、通常ノードプールとマネージドノードプールの 2 種類のノードプールを提供します。
通常ノードプール
通常ノードプールには、同じ構成を共有する 1 つ以上のノードが含まれます。各ノードプールは 1 つのスケーリンググループにマッピングされます。ノードプールをスケーリングすると、ACK は Auto Scaling を使用してノードを追加または削除します。
最適なケース: ノードの O&M を完全に制御したいチーム。パッチ適用、修復、更新はすべて手動でトリガーされます。
一部のシステムコンポーネントは、デフォルトノードプールにインストールされます。デフォルトノードプールを自動的にスケーリングすると、これらのコンポーネントが不安定になる可能性があります。オートスケーリングが必要な場合は、デフォルトノードプールを使用するのではなく、オートスケーリングを有効にした専用のノードプールを作成してください。
マネージドノードプール
マネージドノードプールは、CVE 脆弱性のパッチ適用、ノードの修復、コンポーネントの更新、kubelet のマイナーバージョンの更新など、日常的な O&M タスクを自動化します。メンテナンスウィンドウを設定すると、ACK はそのウィンドウ内でこれらの操作を自動的に実行します。
最適なケース: 運用オーバーヘッドを削減し、ACK に日々のノードメンテナンスを任せたいチーム。一部の複雑なノードの異常には、依然として手動での介入が必要な場合があります。
詳細については、「マネージドノードプールの概要」をご参照ください。
ノードプールタイプの選択
| 通常ノードプール | マネージドノードプール | |
|---|---|---|
| O&M 責任 | お客様 | ACK (一部) |
| メンテナンスウィンドウ | 不要 | 必須 |
| ノードの修復 | 手動 | 自動 |
| CVE 脆弱性のパッチ適用 | 手動 | 自動 |
| コンポーネントの更新 | 手動 | 自動 |
| kubelet のマイナーバージョン更新 | 手動 | 自動 |
| ContainerOS の高速スケールアウト | 非サポート | サポート — 1,000 の ContainerOS ノードが 53 秒で準備完了 (CentOS の 330 秒と比較、ノードの 90% が準備完了した時点での測定) |
| サポートされる OS イメージ | ContainerOS、Alibaba Cloud Linux、Red Hat、Ubuntu、Windows | ContainerOS、Alibaba Cloud Linux、Red Hat、Ubuntu |
マネージドノードプールでの CVE 脆弱性パッチ適用は、Security Center が提供する高度な機能です。Security Center Enterprise Edition 以上が必要です。ACK はこの機能に対して追加料金を請求しません。詳細については、「機能と特徴」をご参照ください。
サポートされる OS イメージと制限事項の詳細については、「OS イメージ」をご参照ください。
制限事項:
ノードプールを削除する前に、すべてのノードを削除する必要があります。
オートスケーリングは、ノードプールの作成時にのみ有効にできます。有効にすると、ノードプールは以下の特徴を持つ弾性ノードプールになります:
手動スケールアウトはサポートされません。
プリエンプティブルインスタンスによる支払い課金方法がサポートされます。
スケーリングアクティビティでは、標準 CPU インスタンス、GPU インスタンス、共有 GPU インスタンスがサポートされます。
オートスケーリングを無効にすると、弾性ノードプールは通常のノードプールに戻ります。通常のノードプールを弾性ノードプールに変換することはサポートされていません。
詳細については、「ノードのオートスケーリングの有効化」をご参照ください。
サポートされる操作
| 操作 | 説明 |
|---|---|
| ノードプールの作成と管理 | ノードプールを作成し、その構成を指定します。 |
| ノードプールの変更 | ノードプールの構成を変更します。ほとんどの場合、変更は新しく追加されたノードにのみ適用されます。例外として、ラベルと Taint の同期、ノードのアップグレード、ノードの修復、脆弱性のパッチ適用、kubelet の構成などがあり、これらの変更は既存のノードにも適用されます。 |
| ノードプールの手動スケーリング | 希望するノード数を調整します。数を増やすとノードが追加され、減らすと作成時刻の降順でノードが解放されます。 |
| 既存の ECS インスタンスを ACK クラスターに追加 | どのクラスターにも属していない既存のノードをノードプールに追加します。制限事項については、該当トピックの「制限事項」セクションをご参照ください。 |
| ノードの削除 | 1 つ以上のノードをノードプールから削除します。削除されたノードは、クラスターやノードプールに属さなくなります。削除前にノードをドレインし、インスタンスを解放することができます。 |
| ノードプールの更新 | ノードプール内のすべてのノードの OS イメージ、ランタイム、kubelet を更新します。実行中のワークロードへの影響を最小限に抑えるために、バッチで更新します。マネージドノードプールは、メンテナンスウィンドウ内で自動的に更新できます。 |
| ノードの修復 | 異常なノードを一度に 1 つずつ修復します。マネージドノードプールはノードを自動的に修復します。 |
| ノードプールの OS CVE 脆弱性へのパッチ適用 | ノードプール内のノード全体に脆弱性パッチを適用します。ワークロードへの影響を最小限に抑えるために、バッチでパッチを適用します。マネージドノードプールは、メンテナンスウィンドウ内で自動的にパッチを適用します。 |
| ノードプールの kubelet 構成のカスタマイズ | ノードプール内のすべてのノードの kubelet 構成を変更します。変更は後から追加されたノードにも適用されます。 |
| ノードのオートスケーリングの有効化 | 実際の負荷とスケーリングポリシーに基づいて、標準 CPU インスタンス、GPU インスタンス、またはプリエンプティブルインスタンスを追加するように Auto Scaling を構成します。複数のゾーン、インスタンスタイプ、スケーリングモードをサポートします。 |
課金
ノードプールは無料です。お支払いいただくのは、ノードプールでプロビジョニングされたクラウドリソース、主に Elastic Compute Service (ECS) インスタンスとスケーリンググループの料金のみです。
ECS の課金の詳細については、「ECS の課金」をご参照ください。
Auto Scaling の課金の詳細については、「Auto Scaling の課金」をご参照ください。
既存ノードの課金方法を変更する (例えば、従量課金からサブスクリプションへ) には、ECS コンソールを使用します。詳細については、「インスタンスの課金方法を従量課金からサブスクリプションに変更」をご参照ください。
基本概念
以下の用語は、ノードプールが依存する基盤となるインフラストラクチャを説明しています。
| 用語 | 説明 |
|---|---|
| スケーリンググループ | オートスケーリングと管理に使用される ECS インスタンスのコレクション。各ノードプールは 1 つのスケーリンググループにマッピングされます。ノードプール内のすべてのリソース (ECS インスタンスとスケーリンググループ) は、同じ Alibaba Cloud アカウントに属している必要があります。 重要 ノードは、スケーリンググループから直接ではなく、常にノードプールを通じて構成および管理してください。スケーリンググループを直接変更すると、ノードプールの機能が損なわれる可能性があります。 |
| スケーリング設定 | スケールアウト時に作成される ECS インスタンスの構成テンプレートを定義します。オートスケーリングがスケールアウトをトリガーすると、この構成に基づいて新しいインスタンスが作成されます。 重要 Auto Scaling コンソールまたは API を通じてスケーリング設定を変更しないでください。ノード構成はノードプールのみを通じて管理してください。 |
| スケーリングアクティビティ | ノードプールがスケールインまたはスケールアウトするときにトリガーされる操作。システムは操作を自動的に完了し、アクティビティを記録します。過去のスケーリングアクティビティはコンソールで表示できます。 |
| システムディスクの交換 | 既存ノードの追加や OS イメージの更新など、一部のノードプール操作では、システムディスクを交換してノードを初期化します。交換後、IaaS 属性 (ノード名、インスタンス ID、IP アドレス) は変更されませんが、システムディスクのデータは削除されます。データディスクは影響を受けません。 重要 永続データはシステムディスクではなく、データディスクに保存してください。 |
| インプレースアップグレード | システムディスクの交換に代わる方法。インプレースアップグレードは、システムディスクを交換したり、ノードを再初期化したり、ノードデータを破棄したりすることなく、コンポーネントを更新します。 |
次のステップ
ノードプールの作成と管理 — 最初のノードプールを構成する
ノードプールの手動スケーリング — オンデマンドでノードを追加または削除する
既存の ECS ノードを ACK クラスターに追加 — 既存のインスタンスをノードプールに取り込む
ノードの削除 — ドレインおよび解放オプションを使用してノードを安全に削除する
ノードプール O&M — ノードプールのスペックアップ、修復、およびパッチ
ノードとノードプールのベストプラクティス — デプロイメントセット、プリエンプティブルインスタンスのノードプールなど
特定のノードプールへのアプリケーションポッドのスケジューリング — 特定のノードプールにワークロードをターゲットする
コンテナランタイムの Docker から containerd への移行 — Kubernetes 1.24 以降を実行するクラスターで必須
ノードとノードプールに関するよくある質問 — 一般的な問題のトラブルシューティング