第16章 AWS VPC クラスターの AWS Outpost への拡張
OpenShift Container Platform バージョン 4.14 では、テクノロジープレビュー機能として、AWS Outposts で実行されているコンピュートノードを使用して、Amazon Web Services (AWS) にクラスターをインストールすることができました。OpenShift Container Platform バージョン 4.15 以降、このインストール方法はサポートされなくなりました。代わりに、AWS 上のクラスターを既存の VPC にインストールし、インストール後の設定タスクとして AWS Outposts にコンピュートノードをプロビジョニングできます。
Amazon Web Services (AWS) 上のクラスターを既存の Amazon Virtual Private Cloud (VPC) にインストール した後、AWS Outposts にコンピュートマシンをデプロイするコンピュートマシンセットを作成できます。AWS Outposts は、低遅延のオンプレミス環境とともに、クラウドベースの AWS デプロイメントの多くの機能を使用できるようにする AWS エッジコンピュートサービスです。詳細は、AWS Outposts のドキュメント を参照してください。
16.1. OpenShift Container Platform 上の AWS Outposts の要件と制限
以下の要件と制限に対応するように OpenShift Container Platform クラスターを設定すると、クラウドベースの AWS クラスター上のリソースと同様に AWS Outpost 上のリソースを管理できます。
- AWS 上の OpenShift Container Platform クラスターを Outpost に拡張するには、クラスターを既存の Amazon Virtual Private Cloud (VPC) にインストールしておく必要があります。
- Outpost のインフラストラクチャーは、AWS リージョンのアベイラビリティーゾーンに関連付けられており、専用のサブネットを使用します。Outpost にデプロイされた Edge コンピュートマシンは、Outpost のサブネットと、Outpost が関連付けられているアベイラビリティーゾーンを使用する必要があります。
-
AWS Kubernetes クラウドコントローラーマネージャーは、Outpost サブネットを検出すると、Outpost サブネット内にサービスロードバランサーを作成しようとします。AWS Outposts は、サービスロードバランサーの実行をサポートしていません。クラウドコントローラーマネージャーが Outpost サブネットでサポート対象外のサービスを作成しないようにするには、Outpost サブネット設定に
kubernetes.io/cluster/unmanaged
タグを含める必要があります。この要件は、OpenShift Container Platform バージョン 4.15 における回避策です。詳細は、OCPBUGS-30041 を参照してください。 -
AWS 上の OpenShift Container Platform クラスターには、
gp3-csi
およびgp2-csi
ストレージクラスがあります。これらのクラスは、Amazon Elastic Block Store (EBS) の gp3 および gp2 ボリュームに対応します。OpenShift Container Platform クラスターはデフォルトでgp3-csi
ストレージクラスを使用しますが、AWS Outposts は EBS gp3 ボリュームをサポートしません。 -
この実装では、
node-role.kubernetes.io/outposts
taint を使用して、通常のクラスターのワークロードが Outpost ノードに分散するのを防ぎます。Outpost でユーザーのワークロードをスケジュールするには、アプリケーションのDeployment
リソースで対応する toleration を指定する必要があります。ユーザーのワークロード用に AWS Outpost インフラストラクチャーを予約すると、互換性を保つためにデフォルトの CSI をgp2-csi
に更新するなど、追加の設定要件が回避されます。 -
Outpost にボリュームを作成するには、CSI ドライバーに Outpost の Amazon Resource Name (ARN) が必要です。ドライバーは、
CSINode
オブジェクトに保存されているトポロジーキーを使用して、Outpost の ARN を特定します。ドライバーが正しいトポロジー値を使用するようにするには、ボリュームバインドモードをWaitForConsumer
に設定した上で、作成する新しいストレージクラスに、許可されるトポロジーを設定しないようにする必要があります。 AWS VPC クラスターを Outpost に拡張すると、2 種類のコンピューティングリソースが得られます。Outpost にはエッジコンピュートノードがあり、VPC にはクラウドベースのコンピュートノードがあります。クラウドベースの AWS Elastic Block ボリュームは、Outpost エッジコンピュートノードに接続できません。また、Outpost ボリュームはクラウドベースのコンピュートノードに接続できません。
そのため、CSI スナップショットを使用して、永続ストレージを使用するアプリケーションをクラウドベースのコンピュートノードからエッジコンピュートノードに移行したり、元の永続ボリュームを直接使用したりすることはできません。アプリケーションの永続ストレージデータを移行するには、手動でバックアップおよび復元操作を実行する必要があります。
AWS Outposts は、AWS Network Load Balancer または AWS Classic Load Balancer をサポートしていません。AWS Outposts 環境でエッジコンピュートリソースの負荷分散を有効にするには、AWS Application Load Balancer を使用する必要があります。
Application Load Balancer をプロビジョニングするには、Ingress リソースを使用し、AWS Load Balancer Operator をインストールする必要があります。クラスターに、ワークロードを共有するエッジベースとクラウドベースの両方のコンピュートインスタンスが含まれている場合は、追加の設定が必要です。
詳細は、「Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用」を参照してください。