Amazon Web Services ブログ
AWS PrivateLink を用いた Red Hat OpenShift Service on AWS のプライベートクラスター
この記事は Red Hat OpenShift Service on AWS: private clusters with AWS PrivateLink (記事公開日: 2021 年 10 月 22 日) を翻訳したものです。
Red Hat OpenShift Service on AWS (ROSA) は、パブリック、プライベート、AWS PrivateLink を用いたプライベート、という3つのやり方でデプロイできます。パブリックとプライベートのクラスターは、どちらも OpenShift クラスターはインターネットにアクセス可能であり、OpenShift で動作するアプリケーションワークロードがプライベートであるか否かが異なります。しかしながら、 OpenShift クラスターとアプリケーションワークロードの両方をプライベートにしたいという要望を持つお客様もいます。そうするには ROSA はマネージドサービスであり Red Hat SRE チームがお客様の代わりに OpenShift クラスターを監視・管理する必要がある事が課題となります。クラスターが完全にプライベートである時、どのようにこれを実現できるでしょうか？
この記事では、この課題を解決する方法を説明し、そのユースケースとアーキテクチャを紹介します。
PrivateLink を用いた ROSA のプライベートクラスターのデプロイ
PrivateLink を用いた ROSA のプライベートクラスターを ROSA CLI からデプロイできます。ただし、既に存在する VPC 内にデプロイしなければなりません。既存の VPC のプライベートサブネットのサブネット ID を 3 つ指定する必要があります。
インタラクティブモードでの ROSA のデプロイ
または次のシングルコマンドを与えます。
rosa create cluster --cluster-name rosaprivatelink --multi-az --region us-west-2 --version 4.8.2 --enable-autoscaling --min-replicas 3 --max-replicas 3 --machine-cidr 10.1.0.0/16 --service-cidr 172.30.0.0/16 --pod-cidr 10.128.0.0/14 --host-prefix 23 --private-link —subnet-ids subnet-06999e53d2a2ec991,subnet-0a19ca9a50cfd238e,subnet-01760325eb996a87b
ROSA のインストールプロセスは EC2 インスタンスが、インターネットゲートウェイもしくは他の Egress ポイントへのルーティングを経由して、インターネットへの外向きのアクセスを持っていること必要とします。この点について VPC を解説する際に後ほど詳細に説明します。
ROSA の PrivateLink プロビジョニングプロセスの間に生成される AWS リソース
ROSA クラスター自体は他のデプロイメントオプションと同じ方法でデプロイされます。コントロールプレーンノード、インフラストラクチャノード、ワーカーノードが 3 つの AWS アベイラビリティゾーンにまたがってプライベートサブネットにデプロイされます。
特筆すべき差分
- AWS PrivateLink の VPC エンドポイントサービスと ROSA VPC から Red Hat SRE チームへの PrivateLink の接続が追加されます
- AWS ロードバランサーの数が減ります
- インターネット向けの AWS ロードバランサーがありません
- OpenShift インストーラによるインターネットゲートウェイの確認が行われません
PrivateLink を用いた ROSA プライベートクラスターでは、Red Hat SRE チームがお客様の代わりに監視や操作を行うためにクラスターをインターネットからアクセス可能にする必要がありません。PrivateLink の VPC エンドポイントサービスが作られ、VPC のそれぞれのプライベートサブネットと接続されます。
PrivateLink は Red Hat が所有する VPC に接続され、その SRE チームが OpenShift を保守・管理します。Red Hat SRE チームが OpenShift web コンソールか API に接続する必要がある場合、PrivateLink を経由して OpenShift コンソールと API を提供している AWS ロードバランサーに接続します。内部向けとインターネット向けの両方のロードバランサーを用意する必要がなくなるため、AWS ロードバランサーの数が減ります。これにより、OpenShift のアプリケーションワークロードへのアクセスを提供する Classic Load Balancer が 1 台と OpenShift API とコンソールのエンドポイントへのアクセスを提供する Network Load Balancer が 1 台のみある構成になります。
ROSA PrivateLink を用いたお客様のユースケースと VPC
お客様が OpenShift クラスターとアプリケーションワークロードがインターネットに公開されていないマネージドな OpenShift を求めているが、インターネット向けのアクセスを中央管理する必要はないというユースケースでは、お客様は従来通りの VPC、すなわちパブリックサブネットとプライベートサブネットと NAT ゲートウェイとインターネットゲートウェイなどがある VPC にデプロイできます。
マネージメントコンソールにある VPC 起動ウィザードを用いるか、Infrastructure as Code の AWS CloudFormation を活用したい場合は Amazon Virtual Private Cloud (Amazon VPC) クイックスタートを用いることで、この VPC をデプロイできます。
厳格なネットワークと基盤のポリシーを定めているお客様は、特定の Ingress パスと Egress パスに要求があるかもしれません。この場合は、VPC を他の Ingress VPC と Egress VPC に接続するか、オンプレミスに接続することになるでしょう。AWS は VPC とオンプレミスの間の様々な接続オプションを提供しています。次のホワイトペーパーでよりこれらについて詳しく解説されています。
この記事では、ROSA VPC を AWS Transit Gateway を用いてオンプレミスかEgress VPCに接続することに焦点をあてます。
この場合、ROSA がデプロイされる VPC はプライベートサブネットのみを持っていて、インターネットゲートウェイと接続されていません。その代わりに VPC をEgress ポイントに接続してトラフィックをルーティングするために Transit Gateway を用います。
中央制御された出口を担う AWS の Egress VPC に接続した ROSA VPC
オンプレミスに接続した ROSA VPC
上記の場合に両方とも、ROSA はプライベートサブネットにデプロイされます。ROSA のインストールプロセスはインターネットにあるリソースにアクセスする必要があります。VPC の構造はインターネットへのルーティングと名前解決の提供が有効なものでなければなりません。デプロイに先立って、戻りの経路もルートテーブルに含まれていることを入念に点検してください。
ROSA VPC のための Transit Gateway の設定手順
次のように進めます。
- Transit Gateway の作成
- VPC からゲートウェイへのアタッチメントの作成
- VPC と Transit Gateway のルートテーブルの更新
Transit Gateway は ROSA VPC、Egress VPC もしくはオンプレミスへの接続のためのエンドポイントにアタッチされる必要があります。今回の手順では、Egress VPC 内のプライベートサブネットへのアタッチメントと ROSA VPC へのアタッチメントを作成します。それぞれのアタッチメントは VPC内の 3 つのサブネットと接続します。
次に、アタッチメントが作られたら、トラフィックが VPC からインターネットに行き来できるようにルートテーブルを更新しなければなりません。
- Transit Gateway をターゲットとするデフォルトルートが追加されるように ROSA VPC 内のルートテーブルを更新します。
- Transit Gateway をターゲットとする ROSA VPC の CIDR ブロック宛のルートが追加されるように Egress VPC のルートテーブルを更新します。
- Transit Gateway 自体のルートテーブルを更新します。VPC に向かうルートエントリは既に登録されています。これらはアタッチメントが作成されたときに自動的に生成されます。我々はそれ以外のトラフィックが Egress VPC へのアタッチメントを通るようにデフォルトルートを追加する必要があります。
そして、ROSA を ROSA VPC のプライベートサブネットにデプロイすることができます。
アプリケーションの所有者とプラットフォームチームは AWS Control Tower と AWS Service Catalog を用いることでセルフサービス化できます。 VPC のような共通の構成要素を Infrastructure as Code のテンプレートとして提供し、 AWS Service Catalog に載せることができます。チームは ROSA VPC をカタログからデプロイして、そして ROSA をデプロイすることができます。詳しく知りたい場合は、記事「Self-service VPCs in AWS Control Tower using AWS Service Catalog」を参照してください。
トラブルシューティング
問題を回避するためのいくつかの確認事項を述べます。
- ルーティング、特に戻りの経路のルーティングが存在するか検証してください。プロビジョニングの途中、
- OpenShift クラスターはインターネットにあるリソースにアクセスする必要があります。
- ROSA VPC 内の EC2 インスタンスは Transit Gatewayを通って Egress ポイントへ到達できる必要があります。
- トラフィックには戻りのパスが必要です。
- ファイアウォールの設定: 共通のサービスインフラストラクチャやセキュリティ Egress レイヤ、例えば Palo Alto のようなもの、をお客様が設置していることがあります。もしこれが ROSA VPC からインターネットへの HTTP トラフィックを許可していなければ、プロビジョニングの妨げとなってしまいます。
- ネットワーク ACL: PrivateLink を用いた ROSA は既存の VPC にデプロイされることから、サブネットのネットワーク ACL が ROSA VPC を出入りする必要なトラフィックを許可していることを確認してください。 ROSA クラスターのプロビジョニングは必要となるセキュリティグループを作成します。
- あるべき理想の状態の設定 (Desired state configuration): AWS インフラストラクチャの変更を元に戻す自動化が導入されているかもしれません。これが ROSA プロビジョニングを妨げないようにチームが相互に協力することが求められます。ある事例では、ROSA クラスターのプロビジョニングがセキュリティグループを生成しますが、お客様のセキュリティと状態維持の自動化がこれを考慮せずに、ツールが ROSA のセキュリティグループからルールを削除して通信を妨げました。原因が特定された後、セキュリティチームはあるべき理想の状態として ROSA のためのルールをツールに設定して問題は解消しました。
多くの問題は正しいステークホルダが互いに認識していなかったことに起因して発生していました。アプリケーションプラットフォームの所有者、ネットワークチーム、セキュリティチームとCloud Center of Excellence (CCoE) が関わっていることを確認してください。
まとめ
PrivateLink を用いた Red Hat OpenShift Service on AWS クラスターによってお客様はシステムをインターネットに公開することなく OpenShift クラスターとアプリケーションワークロードをデプロイできます。 Red Hat SRE チームは PrivateLink の接続を用いてクラスターにアクセスして、お客様の代わりにクラスターを管理できます。お客様はさまざまな実装と自動化の手法を適用することができます。
追加情報
AWSブログ: Building an egress VPC with AWS Transit Gateway and the AWS CDK
AWSブログ: Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway
翻訳はパートナーソリューションアーキテクトの市川が担当しました。原文はこちらです。