Azure Red Hat OpenShift に関する FAQ

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

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

For a list of supported regions for Azure Red Hat OpenShift 4.x, see Available regions.

An existing cluster that uses a service principal can't be migrated to use a managed identity. Azure Red Hat OpenShift クラスターでマネージド ID を使用する新しいクラスターを作成する必要があります。 詳細については、「 マネージド ID を使用して Azure Red Hat OpenShift クラスターを作成する (プレビュー)」を参照してください。

Azure Red Hat OpenShift 4 でサポートされている仮想マシン のサイズの一覧については、 Azure Red Hat OpenShift 4.0 のサポート ポリシーを参照してください。

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

Azure Red Hat OpenShift 4.x には、ノードあたり 250 のポッド制限と 250 の計算ノードの制限があります。 これらの制限により、1 つのクラスターでサポートされるポッドの最大数は 250 × 250 = 62,500 に制限されます。 これらの制限は、ユーザー定義ルーティング (UDR) を使用して作成され、バージョン 4.11 以降を実行しているクラスターでも同じです。

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

Yes. クラスターが可用性ゾーンをサポートする Azure リージョンにデプロイされている場合、クラスターは自動的に複数の可用性ゾーンにデプロイされます。 For more information, see Availability zones.

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

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

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

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

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

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

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

Prometheus は、Azure Red Hat OpenShift 4.x クラスター用にプレインストールされ、構成されています。 Read more about cluster monitoring.

はい。Azure Red Hat OpenShift 4.x で Prometheus を使用できます。

基になる仮想マシンからのログはマネージド サービスによって処理され、顧客には公開されません。

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

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

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

お客様には、ノードを取得し、顧客管理者としてラベルを表示する機能があります。この機能を使用すると、スケール セット内の任意の仮想マシンをターゲットにできます。

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

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

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

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

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

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

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

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

4.x クラスターでは、既存の仮想ネットワークにクラスターをデプロイできます。

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

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

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

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

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

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

Yes. Microsoft Entra アプリケーションを構成すると、クラスターにサインインできる Microsoft Entra ユーザーを制限できます。 詳細については、「 Microsoft Entra アプリを一連のユーザーに制限する」を参照してください。

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

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 は、安全性の高い通信、データのプライバシー、およびデータの整合性を提供します。

データは既定では暗号化されませんが、暗号化を有効にすることはできます。 For more information, see the guide on encrypting etcd.

Azure Disk (Premium_LRS) は、既定のストレージ クラスとして構成されます。 For other storage providers, and for configuration details (including Azure File), see the Red Hat documentation on persistent storage.

No. クラスターで作成されたすべてのデータは、クラスターのリージョン内に保持されます。

Related content

• Azure Red Hat OpenShift 4.0 サポート ポリシー
• Azure Red Hat OpenShift 4 のサポート ライフサイクル