Azure Red Hat OpenShift に関する FAQ

価格情報については、「Azure Red Hat OpenShift の価格」を参照してください。

サービス レベル アグリーメント (SLA) の情報については、「オンライン サービスのサービス レベル アグリーメント」を参照してください。

Azure Red Hat OpenShift 4.x でサポートされているリージョンのリストについては、利用可能なリージョンに関するページを参照してください。

Azure Red Hat OpenShift 4 でサポートされている仮想マシンのサイズのリストについては、Azure Red Hat OpenShift 4 でサポートされているリソースに関するページを参照してください。

サポートされるポッドの実際の数は、アプリケーションのメモリ、CPU、ストレージの要件によって異なります。

Azure Red Hat OpenShift 4.x には、ノードあたり 250 のポッド制限と 60 の計算ノードの制限があります。 これらの制限により、1 つのクラスターでサポートされるポッドの最大数は 250 × 60 = 15,000 に制限されます。 パブリック IP がないプライベート クラスター (たとえば、ユーザー定義ルーティング (UDR) を使用して作成され、バージョン 4.11 以上を実行している場合) では、制限は 120 計算ノードと 30,000 ポッドです。

不正解です。 Azure Red Hat OpenShift クラスターのすべてのノードは、同じ Azure リージョンに由来する必要があります。

はい。 クラスターが可用性ゾーンをサポートする Azure リージョンにデプロイされている場合、クラスターは自動的に複数の可用性ゾーンにデプロイされます。 詳細については、可用性ゾーンに関するページをご覧ください。

不正解です。 クラスター コントロール プレーン ノードを含むすべてのリソースはサブスクリプション内で実行されます。 これらの種類のリソースは、読み取り専用のリソース グループに置かれます。

Azure マネージド アプリケーションは、顧客のサブスクリプションを利用するロックされたリソース グループ内に存在します。 お客様は、そのリソース グループ内のオブジェクトを表示できますが、変更することはできません。

各 Azure Red Hat OpenShift クラスターは指定された顧客専用であり、その顧客のサブスクリプション内に存在します。

はい。ARO では、既定のルーター、統合されたコンテナー レジストリ、クラスターのメトリックと監視用のコンポーネントなどのインフラストラクチャ コンポーネントのみをホストするマシンを、インフラストラクチャ マシン セットを使って作成できます。 詳細については、「ARO クラスターにインフラストラクチャ ノードをデプロイする」を参照してください。

クラスターのアップグレードはどのように処理しますか?

アップグレード、メンテナンス、およびサポートされているバージョンの詳細については、サポート ライフサイクル ガイドを参照してください。

ホスト オペレーティング システムと OpenShift ソフトウェアは、Azure Red Hat OpenShift が、上流の OpenShift Container Platform のマイナー リリース バージョンと修正プログラムを使用するときに更新されます。

ノードは、アップグレードの一環として再起動されます。

Prometheus は、プレインストールされ、Azure Red Hat OpenShift 4.x クラスター用に構成されています。 詳細については、クラスターの監視に関する記述を参照してください。

はい (Azure Red Hat OpenShift 4.x の場合)。

基になる VM からのログは、管理サービスによって処理され、顧客に公開されることはありません。

Azure Red Hat OpenShift 4.x クラスターの場合、OpenShift Web コンソールには、ノード レベルのすべてのメトリックが含まれます。 詳しくは、クラスター情報の表示に関する Red Hat のドキュメントを参照してください。

Azure で仮想マシン スケール セットを使う場合は、既定で 5 つの障害ドメインがあります。 スケール セット内の各仮想マシン インスタンスは、これらの障害ドメインのいずれかに配置されます。 これにより、クラスター内のコンピューティング ノードにデプロイされたアプリケーションが別々の障害ドメインに確実に配置されるようになります。

詳細については、「Virtual Machine Scale Sets に対する障害ドメインの適切な数を選択する」を参照してください。

顧客は、顧客管理者としてノードを取得したり、ラベルを表示したりできます。これにより、スケール セット内の任意の VM を対象にする方法が提供されます。

特定のラベルを使用する場合は、次の点に注意してください。

• ホスト名を使うことはできません。 ホスト名はアップグレードと更新によって頻繁にローテーションされるため、変更が保証されます。
• 特定のラベルまたはデプロイ戦略に対する要求がある場合、実現することができるようになっています。 しかし、エンジニアリングの作業が必要であり、現時点ではサポートされていません。

詳細については、ポッドの配置の制御に関するページを参照してください。

4.x クラスターの場合は、セキュリティで保護されたレジストリを公開し、認証を構成する必要があります。 詳しくは、次の Red Hat のドキュメントをご覧ください。

• レジストリを公開する
• レジストリにアクセスする

テナント間での ARO クラスターの移動は、現在サポートされていません。

ARO クラスターとそれに関連付けられているリソースのサブスクリプション間での移動は、サポートされていません。

ARO クラスターとそれに関連付けられているリソースの移動や名前変更は、サポートされていません。

4.x クラスターでは、既存の VNet にクラスターをデプロイできます。

顧客と個々のプロジェクト管理者は、NetworkPolicy オブジェクトを使用して、プロジェクトごとに名前空間の間のネットワークをカスタマイズできます (拒否を含む)。

仮想ネットワークを含むサブスクリプションでは、必ず az provider register -n Microsoft.ContainerService --wait のコマンドを使用して Microsoft.ContainerService プロバイダーを登録してください。

4.x クラスターでは、独自の IP 範囲を指定できます。

ソフトウェア定義ネットワークは openshift-ovs-networkpolicy であり、構成できません。

Azure Red Hat OpenShift では Standard Azure Load Balancer が使われており、構成はできません。

はい。 Azure Red Hat OpenShift 管理者は、ユーザーおよびクォータを管理するほか、ユーザーが作成したすべてのプロジェクトにアクセスできます。

はい。 Microsoft Entra アプリケーションを構成すると、クラスターにサインインできる Microsoft Entra ユーザーを制限できます。 詳細については、アプリをユーザーのセットに制限する方法に関する記事を参照してください。

はい。 管理者としてクラスターにログインし、以下のコマンドを実行します:

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

詳細については、ご使用のクラスター バージョンのセルフプロビジョニングの無効化に関する OpenShift のドキュメントを参照してください。

• 4.6 クラスターでのセルフプロビジョニングの無効化

ノード アクセスは、クラスター管理者ロールを通じて使うことができます。 詳細については、Kubernetes RBAC の概要に関するページを参照してください。

クラスター管理者ロールを使うことができます。 詳細については、Kubernetes RBAC の概要に関するページを参照してください。

独自の ID プロバイダーを構成します。 詳細については、ID プロバイダーの構成に関する Red Hat のドキュメントを参照してください。

既定では、データは保存時に暗号化されます。 Azure Storage プラットフォームは、永続化する前に自動的にデータを暗号化し、取得前にデータの暗号化を解除します。 詳細については、「保存データ向け Azure Storage Service Encryption」をご覧ください。

ストレージ アカウントは、プライベートアクセスのみに設定されます。

ストレージ アカウントは暗号化されます (新しいクラスターのみ)。 既存のクラスターを再度作る必要があります。

ストレージ アカウントは、新しいクラスターのために汎用 v2 を使って作られます。

汎用 v2 ストレージ アカウントは最新の Azure Storage 機能をサポートし、汎用 v1 および BLOB ストレージ アカウントのすべての機能を組み込んでいます。

Storage アカウントへのアクセスは、Azure ネットワーク セキュリティ グループ (NSGs) を介して、ストレージアカウントとの間のネットワーク トラフィックをフィルター処理するファイアウォール ルールによって制限されます。 詳細については、Azure ネットワーク セキュリティ グループの概要に関するページをご覧ください。

トランスポート層セキュリティ (TLS) プロトコルバージョン 1.2 は、安全性の高い通信、データのプライバシー、およびデータの整合性を提供します。

既定ではデータは暗号化されませんが、暗号化を有効にするオプションがあります。 詳細については、etcd の暗号化に関するガイドを参照してください。

Azure Disk (Premium_LRS) は、既定のストレージ クラスとして構成されます。 追加のストレージ プロバイダー、および構成の詳細 (Azure File を含む) については、永続ストレージに関する Red Hat のドキュメントを参照してください。

ARO では、クラスターのリージョン外に格納される顧客データがありますか?

不正解です。 ARO クラスターで作成されたすべてのデータは、クラスターのリージョン内に維持されます。