クラウドエッジのコラボレーションシナリオでは、異なるグループに属するノードは互いに分離されます。 例えば、これらのノードは、切断されてもよく、同じリソースを共有しなくてもよく、異種リソースを有してもよく、または独立して配備されるアプリケーションを実行してもよい。 ACK Edgeは、ノードプール機能を提供します。 この機能は、特定の属性に基づいてノードをノードプールに抽象化します。これにより、同じノードプール内のノードを一元管理および維持できます。 このトピックでは、ノードプールについて説明し、ノードプールの種類と、ノードプールによるノードの管理方法について説明します。
ノードプールのタイプ
クラウドエッジのコラボレーションシナリオでは、ACK edgeは次のタイプのノードプールを提供します。オンクラウドノードプールとエッジノードプールです。
オンクラウドノードプール: オンクラウドノードプールは、クラスターの同じ仮想プライベートクラウド (VPC) に存在するElastic Compute Service (ECS) インスタンスを管理します。 オンクラウドノードプールは、ACK Proクラスターが提供するノードプールと同じです。
オンクラウドノードプール (デフォルト): システムがACK Edgeクラスターを作成すると、default-nodepoolという名前のオンクラウドノードプールが自動的に作成されます。
重要default-nodepoolノードプールは削除できません。 ノードプールには、少なくとも1つのノードが含まれている必要があります。 そうしないと、ACK Edgeクラスターは通常どおり機能できません。
オンクラウドノードプール (elastic): ノードオートスケーリングが有効になっているオンクラウドノードプール。
エッジノードプール: エッジノードプールは、異なるリージョンのECSノード、データセンターにデプロイされたノード、異なるクラウドサービスプロバイダーのノード、工場、店舗、車両、船舶のサーバーノードなど、リージョン間に分散したノードを管理します。
オンクラウドノードプール
オンクラウドノードプールの属性は、ACK Proクラスターが提供する属性と同じであり、オンクラウドノードプールでも同じ操作を実行できます。 詳細については、「クラウド上のノードプールの概要」をご参照ください。
エッジノードプール
エッジノードプールは、エッジノードグループの抽象化です。 エッジノードプールを作成するときは、まず、クラウドエッジ接続、ノード間通信、ポッドネットワークなど、ノードプール内のノードの基本属性を確認する必要があります。 さらに、CPUまたはGPU、リージョン、AMD64またはARM64アーキテクチャなどの他のノード属性に基づいて、エッジノードを複数のエッジノードプールに分散することを推奨します。
ノードプールの作成後、エッジノードプールを変更することで、ノードプール内のノードのラベルとテイントをバッチ管理できます。 クラスターからすべてのエッジノードを削除した後、エッジノードプールを削除できます。
アプリケーションを複数のノードプールにデプロイするには、YurtAppSetを作成します。 YurtAppSetsは、ノードプールラベルの変更にすばやく対応できます。 これにより、YurtAppSetsは、複数のノードプールに分散されるワークロードの構成 (ポッド数やアプリケーションバージョンなど) を一元管理できます。
Kubernetes Servicesのバックエンドエンドポイントは、ノード間でランダムに分散されます。 したがって、2つのエッジノードプールのネットワークが切断された場合、エッジノードプールにわたるサービス間通信は、失敗するか、または高いネットワーク待ち時間を有する可能性がある。 サービストポロジを作成して、サービス通信を同じエッジノードプールまたはエッジノードに制限することができます。 これにより、ドメイン間通信シナリオでのサービス通信障害を回避できます。