6.3. Red Hat OpenShift Service on AWS のサービス定義

Red Hat OpenShift Service on AWS は Amazon Web Services (AWS) アカウントに直接請求されます。ROSA の価格は消費量に基づいており、年間契約または 3 年間の契約で割引率が高くなります。ROSA の総コストは、次の 2 つの要素で構成されます。

詳細は、AWS ウェブサイトの Red Hat OpenShift Service on AWS の料金 ページをご覧ください。

お客様はクラスターをセルフサービスで利用できます。これには以下が含まれますが、これらに限定されません。

これらのセルフサービスタスクは、Red Hat OpenShift Service on AWS (ROSA) CLI (rosa) を使用して実行できます。

ROSA with HCP クラスターにはすべて、少なくとも 2 つのワーカーノードが必要です。クラウドプロバイダーコンソールを使用して基盤となる (EC2 インスタンス) インフラストラクチャーをシャットダウンすることは、サポート対象外の操作であり、データの損失やその他のリスクにつながる可能性があります。

現在、ROSA with HCP では、次の AWS リージョンが利用可能です。

クラスターは、3 つ以上のアベイラビリティーゾーンを持つリージョンにのみデプロイできます。詳細は、AWS ドキュメントの Regions and Availability Zones セクションを参照してください。

HCP を備えた新しい ROSA クラスターはそれぞれ、単一リージョンの既存の Virtual Private Cloud (VPC) 内にインストールされます。必要に応じて、そのリージョンのアベイラビリティゾーンの合計数までデプロイできます。これにより、クラスターレベルのネットワークおよびリソースの分離が行われ、VPN 接続や VPC ピアリングなどのクラウドプロバイダーの VPC 設定が有効になります。永続ボリューム (PV) は Amazon Elastic Block Storage (Amazon EBS) によってサポートされ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものとして機能します。永続ボリューム要求 (PVC) は、Pod がスケジュールできなくなる状況を防ぐために、関連付けられた Pod リソースが特定のアベイラビリティーゾーンに割り当てられるまでボリュームにバインドされません。アベイラビリティーゾーン固有のリソースは、同じアベイラビリティーゾーン内のリソースでのみ利用できます。

Red Hat OpenShift Service on AWS は AWS Local Zones の使用をサポートしていません。

サービス自体の SLA は、Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) で定義されています。

クラスターが 限定サポート ステータスに移行すると、Red Hat はクラスターをプロアクティブに監視しなくなり、SLA は適用されなくなり、SLA に対して要求されたクレジットは拒否されます。製品サポートがなくなったという意味ではありません。場合によっては、違反要因を修正すると、クラスターが完全にサポートされた状態に戻ることがあります。ただし、それ以外の場合は、クラスターを削除して再作成する必要があります。

クラスターは、次のシナリオなど、さまざまな理由で限定サポートステータスに移行する場合があります。

クラスターが限定サポートステータスに移行する可能性のある特定のアクションに関する質問がある場合、またはさらに支援が必要な場合は、サポートチケットを作成します。

Red Hat OpenShift Service on AWS には Red Hat Premium サポートが含まれており、このサポートは Red Hat カスタマーポータル を使用して利用できます。

サポートの応答時間は、Red Hat 製品サポートのサービスレベルアグリーメント を参照してください。

AWS サポートは、AWS との既存のサポート契約に基づきます。

クラスター監査ログは、インテグレーションが有効になっている場合に AWS CloudWatch 経由で利用できます。インテグレーションが有効でない場合は、サポートケースを作成して監査ログをリクエストできます。

STDOUT に送信されるアプリケーションログは Fluentd によって収集され、クラスターロギングスタックで AWS CloudWatch に転送されます (インストールされている場合)。

Red Hat OpenShift Service on AWS クラスターには、CPU、メモリー、ネットワークベースのメトリクスを含むクラスターモニタリングの統合された Prometheus スタックが同梱されます。これは Web コンソールからアクセスできます。また、これらのメトリクスにより、ROSA ユーザーが提供する CPU またはメモリーメトリクスに基づく水平 Pod 自動スケーリングが可能になります。

クラスター通知 (サービスログと呼ばれることもあります) は、クラスターのステータス、健全性、またはパフォーマンスに関するメッセージです。

クラスター通知は、Red Hat Site Reliability Engineering (SRE) が管理対象クラスターの健全性をユーザーに通知する際に使用する主な方法です。Red Hat SRE は、クラスター通知を使用して、クラスターの問題を解決または防止するためのアクションを実行するように促すこともあります。

クラスターの所有者と管理者は、クラスターの健全性とサポート対象の状態を維持するために、クラスター通知を定期的に確認して対処する必要があります。

クラスターの通知は、Red Hat Hybrid Cloud Console のクラスターの Cluster history タブで表示できます。デフォルトでは、クラスターの所有者のみがクラスター通知をメールで受信します。他のユーザーがクラスター通知メールを受信する必要がある場合は、各ユーザーをクラスターの通知連絡先として追加します。

ルートにカスタムホスト名を使用するには、正規名 (CNAME) レコードを作成して DNS プロバイダーを更新する必要があります。CNAME レコードでは、OpenShift の正規ルーターのホスト名をカスタムドメインにマップする必要があります。OpenShift の正規ルーターのホスト名は、ルートの作成後に Route Details ページに表示されます。または、ワイルドカード CNAME レコードを 1 度作成して、指定のホスト名のすべてのサブドメインをクラスターのルーターにルーティングできます。

ROSA には、クラスター上の内部サービスと外部サービスの両方に必要な TLS セキュリティー証明書が含まれています。外部ルートの場合は、各クラスターに提供され、インストールされる 2 つの別個の TLS ワイルドカード証明書があります。1 つは Web コンソールおよびルートのデフォルトホスト名用であり、もう 1 つは API エンドポイント用です。Let’s Encrypt は証明書に使用される認証局です。内部の API エンドポイント などのクラスター内のルートでは、クラスターの組み込み認証局によって署名された TLS 証明書を使用し、TLS 証明書を信頼するためにすべての Pod で CA バンドルが利用可能である必要があります。

ROSA は、イメージレジストリーからイメージをプルするときに、ビルドによって信頼されるカスタム認証局を使用することをサポートしています。

Red Hat OpenShift Service on AWS は、デフォルトの Ingress コントローラーからのみロードバランサーをデプロイします。お客様は、他のすべてのロードバランサーを、セカンダリー Ingress コントローラーやサービスロードバランサー用に、必要に応じてデプロイできます。

プロジェクト管理者は、IP 許可リストによる ingress の制御など、さまざまな目的でルートアノテーションを追加できます。

Ingress ポリシーは、ovs-networkpolicy プラグインを使用する NetworkPolicy オブジェクトを使用して変更することもできます。これにより、同じクラスターの Pod 間や同じ namespace にある Pod 間など、Ingress ネットワークポリシーを Pod レベルで完全に制御できます。

すべてのクラスター ingress トラフィックは定義されたロードバランサーを通過します。すべてのノードへの直接のアクセスは、クラウド設定によりブロックされます。

EgressNetworkPolicy オブジェクトによる Pod の Egress トラフィック制御を使用すると、ROSA with Hosted Control Plane (HCP) の送信トラフィックを防止または制限できます。

Red Hat OpenShift Service on AWS では、次のような AWS 管理のテクノロジーを使用してプライベートネットワーク接続を設定できます。

プライベートクラウドネットワーク設定を持つ ROSA クラスターの場合、お客様は、明示的に指定されたドメインの問い合わせ先として、そのプライベート接続で利用可能な内部 DNS サーバーを指定できます。

ROSA クラスターを既存の Virtual Private Cloud (VPC) にデプロイするか、クラスターとって新しいサブネットを持つマシンプールを追加で作成すると、ネットワーク検証チェックが自動的に実行されます。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、デプロイメント前に設定の問題を解決できます。

ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。

ワーカーノードは、保存時に暗号化される Amazon Elastic Block Store (Amazon EBS) ストレージを使用します。

PV に使用される EBS ボリュームはデフォルトで保存時に暗号化されます。

永続ボリューム (PV) は、Read-Write-Once の Amazon Elastic Block Store (Amazon EBS) によってサポートされています。

PV は一度に 1 つのノードにのみ割り当てられ、それらがプロビジョニングされるアベイラビリティーゾーンに固有のものです。ただし、PV はそのアベイラビリティーゾーンの任意のノードに割り当てることができます。

各クラウドプロバイダーには、1 つのノードに割り当てることのできる PV の数に独自の制限があります。詳細は、AWS インスタンスタイプの制限 を参照してください。

AWS CSI ドライバーは、Red Hat OpenShift Service on AWS の RWX サポートを提供するのに使用できます。コミュニティー Operator は、設定を簡素化するために提供されます。詳細は、Amazon Elastic File Storage Setup for Red Hat OpenShift Service on AWS を参照してください。

ROSA with HCP ではノードの自動スケーリングが利用できます。オートスケーラーオプションを設定して、クラスター内のマシンの数を自動的にスケーリングできます。

コントロールプレーンのコンポーネントは、お客様のワーカーノード設定に関係なく、常に複数のアベイラビリティゾーンにデプロイされます。

カスタムノードラベルはノードの作成時に Red Hat によって作成され、現時点では ROSA with HCP クラスターで変更することはできません。ただし、カスタムラベルは新規マシンプールの作成時にサポートされます。

ワーカーノードは永続性が保証されておらず、OpenShift の通常の運用および管理の一環として、いつでも置き換えられる可能性があります。

次のような状況では、ワーカーノードが置き換えられる可能性があります。

Kubernetes ベースのシステムで実行されるすべてのコンテナー化されたワークロードでは、ノードの置き換えに対して耐性を持つようにアプリケーションを設定することがベストプラクティスです。

Red Hat は、オブジェクトレベルのバックアップソリューションを ROSA クラスターに使用することを推奨しています。OpenShift API for Data Protection (OADP) は OpenShift に含まれていますが、デフォルトでは有効になっていません。お客様は、クラスター上で OADP を設定して、オブジェクトレベルのバックアップおよび復元機能を実現できます。

Red Hat はお客様のアプリケーションまたはアプリケーションデータをバックアップしません。お客様はアプリケーションとそのデータに対して単独で責任を負い、独自のバックアップおよび復元機能を導入する必要があります。

ROSA with HCP はサービスとして実行されます。ライフサイクル終了 (EOL) に達すると、Red Hat の SRE チームが強制的にアップグレードを実行します。最新バージョンへのアップグレードのスケジューリング機能を利用できます。

アップグレードは、ROSA CLI、rosa、または OpenShift Cluster Manager を使用してスケジュールできます。

アップグレードポリシーおよび手順の詳細は、Red Hat OpenShift Service on AWS のライフサイクル を参照してください。

現時点では、Windows コンテナーに対する Red Hat OpenShift のサポートは Red Hat OpenShift Service on AWS では利用できません。代わりに、ROSA クラスター上で稼働する OpenShift Virtualization 上で Windows ベースの仮想マシンを実行することがサポートされています。

ROSA with HCP は、OpenShift 4 上で稼働し、唯一利用可能なコンテナーエンジン (コンテナーランタイムインターフェイス) である CRI-O を使用します。

ROSA with HCP は、OpenShift 4 上で稼働し、すべてのクラスターノードのオペレーティングシステムとして Red Hat CoreOS (RHCOS) を使用します。

通常、Red Hat ワークロードは、Operator Hub を通じて利用できる Red Hat 提供の Operator を指します。Red Hat ワークロードは Red Hat SRE チームによって管理されないため、ワーカーノードにデプロイする必要があります。これらの Operator は、追加の Red Hat サブスクリプションが必要になる場合があり、追加のクラウドインフラストラクチャーコストが発生する場合があります。これらの Red Hat 提供の Operator の例は次のとおりです。

OperatorHub marketplace にリスト表示されるすべての Operator はインストールに利用できるはずです。これらの Operator はお客様のワークロードと見なされ、Red Hat SRE によって監視または管理されません。Red Hat によって作成された Operator は Red Hat によってサポートされます。

クラスターの認証は、OpenShift Cluster Manager またはクラスター作成プロセスを使用するか、ROSA CLI rosa を使用して設定できます。ROSA はアイデンティティープロバイダーではないため、クラスターへのアクセスすべてが統合ソリューションの一部としてお客様によって管理される必要があります。同時にプロビジョニングされる複数のアイデンティティープロバイダーの使用がサポートされます。以下のアイデンティティープロバイダーがサポートされます。

特権付きコンテナーは、cluster-admin ロールを持つユーザーが利用できます。特権付きコンテナーを cluster-admin として使用する場合、これは Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services) の責任および除外事項に基づいて使用されます。

Red Hat OpenShift Service on AWS は、通常のユーザーに加えて、ROSA with HCP 固有のグループにアクセスを提供します。このグループは dedicated-admin と呼ばれます。dedicated-admin グループのメンバーであるクラスターのすべてのユーザーは、

Red Hat OpenShift Service on AWS の管理者には、組織のクラスターについて cluster-admin ロールへのデフォルトアクセスがあります。cluster-admin ロールを持つアカウントにログインしている場合、ユーザーのパーミッションは、特権付きセキュリティーコンテキストを実行するために拡大します。

デフォルトで、すべてのユーザーはプロジェクトを作成し、更新し、削除できます。これは、dedicated-admin グループのメンバーが認証されたユーザーから self-provisioner ロールを削除すると制限されます。

oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

以下を適用すると、制限を元に戻すことができます。

oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth

最新のコンプライアンス情報は、ROSA のプロセスとセキュリティー の コンプライアンス テーブルを参照してください。

Red Hat OpenShift Service on AWS では、AWS は AWS Shield と呼ばれる標準の DDoS 保護をすべてのロードバランサーで提供します。これにより、ROSA で使用されるすべての公開ロードバランサーに対して、最も一般的なレベル 3 および 4 の攻撃に対する 95% の保護が提供されます。応答を受信するために haproxy ルーターに送信される HTTP 要求に 10 秒のタイムアウトが追加されるか、追加の保護を提供するために接続が切断されます。

Red Hat OpenShift Service on AWS では、etcd ボリュームの暗号化を含め、コントロールプレーンのストレージが保存時にデフォルトで暗号化されます。このストレージレベルの暗号化は、クラウドプロバイダーのストレージ層を介して提供されます。

お客様は、ビルド時に etcd データベースを暗号化することも、etcd データベースを暗号化するために独自のカスタム AWS KMS キーを提供することもできます。

etcd 暗号化では、次の Kubernetes API サーバーおよび OpenShift API サーバーのリソースが暗号化されます。