Azure Red Hat OpenShift に関する FAQAzure Red Hat OpenShift FAQ

この記事では、Microsoft Azure Red Hat OpenShift に関してよく寄せられる質問 (FAQ) を説明します。This article addresses frequently asked questions (FAQs) about Microsoft Azure Red Hat OpenShift.

どの Azure リージョンがサポートされていますか?Which Azure regions are supported?

Azure Red Hat OpenShift がサポートされている世界中のリージョンの一覧については、サポートされているリソースに関するページを参照してください。See Supported resources for a list of global regions where Azure Red Hat OpenShift is supported.

既存の仮想ネットワークにクラスターをデプロイできますか?Can I deploy a cluster into an existing virtual network?

いいえ。No. もっとも、ピアリングを使って Azure Red Hat OpenShift クラスターを既存の VNET に接続することはできます。But you can connect an Azure Red Hat OpenShift cluster to an existing VNET via peering. 詳細については、クラスターの仮想ネットワークを既存の仮想ネットワークに接続する方法に関するセクションを参照してください。See Connect a cluster's virtual network to an existing virtual network for details.

どのクラスター操作を使用できますか?What cluster operations are available?

コンピューティング ノード数の増大または減少のみを行えます。You can only scale up or down the number of compute nodes. 作成後は、Microsoft.ContainerService/openShiftManagedClusters リソースに対するその他の変更は許可されません。No other modifications are permitted to the Microsoft.ContainerService/openShiftManagedClusters resource after creation. コンピューティング ノードの最大数は 20 に制限されています。The maximum number of compute nodes is limited to 20.

どの仮想マシンのサイズを使用できますか?What virtual machine sizes can I use?

Azure Red Hat OpenShift クラスターで使用できる仮想マシンのサイズの一覧については、Azure Red Hat OpenShift 仮想マシンのサイズに関するページを参照してください。See Azure Red Hat OpenShift virtual machine sizes for a list of virtual machine sizes you can use with an Azure Red Hat OpenShift cluster.

クラスター上のデータは暗号化されていますか?Is data on my cluster encrypted?

既定では、保存時の暗号化があります。By default, there is encryption at rest. Azure Storage プラットフォームは、永続化する前に自動的にデータを暗号化し、取得前にデータの暗号化を解除します。The Azure Storage platform automatically encrypts your data before persisting it, and decrypts the data before retrieval. 詳細については、保存データの Azure Storage Service Encryption に関するページを参照してください。See Azure Storage Service Encryption for data at rest for details.

Prometheus/Grafana を使用して自分のアプリケーションを監視できますか?Can I use Prometheus/Grafana to monitor my applications?

はい、Prometheus を自分の名前空間にデプロイし、自分の名前空間内のアプリケーションを開始できます。Yes, you can deploy Prometheus in your namespace and monitor applications in your namespace.

いいえ、現時点ではできません。No, not at current time.

Jenkins などのツールを使用するできるように、Docker レジストリを外部で使用できますか?Is the Docker registry available externally so I can use tools such as Jenkins?

Docker レジストリは https://docker-registry.apps.<clustername>.<region> から利用できますが、強力なストレージ耐久性保証は得られません。The Docker registry is available from https://docker-registry.apps.<clustername>.<region> However, a strong storage durability guarantee is not provided. Azure Container Registry を使用することもできます。You can also use Azure Container Registry.

名前空間間のネットワークはサポートされていますか?Is cross-namespace networking supported?

顧客と個々 のプロジェクト管理者は、NetworkPolicy オブジェクトを使用して、プロジェクトごとに名前空間間のネットワークをカスタマイズできます (拒否を含む)。Customer and individual project admins can customize cross-namespace networking (including denying it) on a per project basis using NetworkPolicy objects.

管理者はユーザーおよびクォータを管理できますか?Can an admin manage users and quotas?

はい。Yes. Azure Red Hat OpenShift 管理者は、ユーザーおよびクォータを管理するほか、ユーザーが作成したすべてのプロジェクトにアクセスできます。An Azure Red Hat OpenShift administrator can manage users and quotas in addition to accessing all user created projects.

クラスターを特定の Azure AD ユーザーに制限できますか?Can I restrict a cluster to only certain Azure AD users?

はい。Yes. Azure AD アプリケーションを構成することで、クラスターにサインインできる Azure AD ユーザーを制限できます。You can restrict which Azure AD users can sign in to a cluster by configuring the Azure AD Application. 詳細については、ご利用のアプリを特定のユーザー セットに制限する」を参照してください。For details, see How to: Restrict your app to a set of users

ユーザーがプロジェクトを作成することを禁止できますか。Can I restrict users from creating projects?

はい。Yes. Azure Red Hat OpenShift 管理者としてクラスターにログインし、次のコマンドを実行します。Log in to your cluster as an Azure Red Hat OpenShift administrator and execute this command:

oc adm policy \
    remove-cluster-role-from-group self-provisioner \

詳細については、OpenShift ドキュメントのセルフプロビジョニングを無効にする方法に関するセクションをご覧ください。For more information, see the OpenShift documentation on disabling self-provisioning.

クラスターは複数の Azure リージョンにわたってコンピューティング ノードを持つことができますか?Can a cluster have compute nodes across multiple Azure regions?

いいえ。No. Azure Red Hat OpenShift クラスターのすべてのノードは、同じ Azure リージョンに基づく必要があります。All nodes in an Azure Red Hat OpenShift cluster must originate from the same Azure region.

マスターおよびインフラストラクチャ ノードは、Azure Kubernetes Service (AKS) の場合と同様に無視されますか?Are master and infrastructure nodes abstracted away as they are with Azure Kubernetes Service (AKS)?

いいえ。No. クラスター マスターを含めすべてのリソースは、顧客サブスクリプションで実行します。All resources, including the cluster master, run in your customer subscription. これらの種類のリソースは、読み取り専用のリソース グループに置かれます。These types of resources are put in a read-only resource group.

Open Service Broker for Azure (OSBA) はサポートされていますか?Is Open Service Broker for Azure (OSBA) supported?

はい。Yes. OSBA は Azure Red Hat OpenShift と共に使用できます。You can use OSBA with Azure Red Hat OpenShift. 詳細については、「Open Service Broker for Azure」を参照してください。See Open Service Broker for Azure for more information.

別のサブスクリプションの仮想ネットワークを詳しく見ようとしていますが、Failed to get vnet CIDR エラーを取得します。I am trying to peer into a virtual network in a different subscription but getting Failed to get vnet CIDR error.

仮想ネットワークを含むサブスクリプションでは、必ず az provider register -n Microsoft.ContainerService --wait を使用して Microsoft.ContainerService プロバイダーを登録してください。In the subscription that has the virtual network, make sure to register Microsoft.ContainerService provider with az provider register -n Microsoft.ContainerService --wait

Azure Red Hat OpenShift (ARO) のメンテナンス プロセスとは何ですか?What is the Azure Red Hat OpenShift (ARO) maintenance process?

ARO 用のメンテナンスには、次の 3 種類があります。アップグレード、etcd データのバックアップと復元、クラウド プロバイダーによって開始されるメンテナンスです。There are three types of maintenance for ARO: upgrades, backup and restoration of etcd data, and cloud provider-initiated maintenance.

  • アップグレードには、ソフトウェアのアップグレードと CVE が含まれます。Upgrades include software upgrades and CVEs. CVE 修復は、yum update を実行することで起動時に発生し、即時のリスク軽減のために提供されます。CVE remediation occurs on startup by running yum update and provides for immediate mitigation. 並列では、将来のクラスターの作成のために、新しいイメージ ビルドが作成されます。In parallel a new image build will be created for future cluster creates.

  • etcd データのバックアップと管理は、アクションに応じて、クラスターのダウンタイムを必要とする可能性がある自動化されたプロセスです。Backup and management of etcd data is an automated process that may require cluster downtime depending on the action. etcd データベースがバックアップから復元されている場合は、ダウンタイムが発生します。If the etcd database is being restored from a backup there will be downtime. etcd を 1 時間ごとにバックアップし、過去 6 時間のバックアップを保持します。We back up etcd hourly and retain the last 6 hours of backups.

  • クラウド プロバイダーによって開始されるメンテナンスには、ネットワーク、ストレージ、リージョンの障害が含まれます。Cloud provider-initiated maintenance includes network, storage, and regional outages. メンテナンスはクラウド プロバイダーに依存し、プロバイダーによって提供される更新プログラムに依存します。The maintenance is dependent on the cloud provider and relies on provider-supplied updates.

一般的なアップグレード プロセスとは何ですか?What is the general upgrade process?

アップグレードの実行は、安全なプロセス実行である必要があり、クラスター サービスを中断しないようにしてください。Running an upgrade should be a safe process to run and should not disrupt cluster services. SRE では、新しいバージョンが利用可能か、または CVE が未完了である場合に、アップグレード プロセスをトリガーできます。The SRE can trigger the upgrade process when new versions are available or CVEs are outstanding.

利用可能な更新プログラムは、ステージング環境でテストされ、運用クラスターに適用されます。Available updates are tested in a stage environment and then applied to production clusters. 適用すると、新しいノードが一時的に追加され、ノードがローテーション方式で更新されるため、ポッドでレプリカの数を保持できます。When applied, a new node is temporarily added and nodes are updated in a rotating fashion so that pods maintain replica counts. ベスト プラクティスに従うと、ダウンタイムが最小限からなしになるように確保することができます。Following best practices helps ensure minimal to no downtime.

保留中のアップグレードまたは更新の重要度によっては、CVE に対するサービスのエクスポージャが軽減されるように、更新プログラムをすぐに適用できるという点で、プロセスが異なる場合があります。Depending on the severity of the pending upgrade or update, the process might differ in that the updates might be applied quickly to mitigate the service’s exposure to a CVE. 新しいイメージは、クラスターのアップグレードとして、非同期でビルド、テスト、ロール アウトされます。A new image will be built asynchronously, tested, and rolled out as a cluster upgrade. それ以外の場合は、緊急時と計画メンテナンスの間に違いはありません。Other than that, there is no difference between emergency and planned maintenance. 計画メンテナンスは、顧客と共に事前にスケジュールされていません。Planned maintenance is not prescheduled with the customer.

顧客との通信が必要な場合は、ICM と電子メールによって通知を送信できます。Notifications may be sent via ICM and email if communication to the customer is required.

非常時と計画メンテナンス期間についてWhat about emergency vs. planned maintenance windows?

Microsoft では、この 2 種類のメンテナンスを区別しません。We do not distinguish between the two types of maintenance. Microsoft チームは 24 時間年中無休で利用でき、従来のスケジュールされた "時間外" のメンテナンス期間を使用しません。Our teams are available 24/7/365 and do not use traditional scheduled “out-of-hours” maintenance windows.

ホスト オペレーティング システムと OpenShift ソフトウェアはどのように更新されますか?How will host operating system and OpenShift software be updated?

ホスト オペレーティング システムと OpenShift ソフトウェアは、一般的なアップグレードとイメージのビルド プロセスによって更新されます。The host operating system and OpenShift software are updated through our general upgrade and image build process.

更新されたノードを再起動するプロセスとは何ですか?What’s the process to reboot the updated node?

これは、アップグレードの一環として処理される必要があります。This should be handled as a part of an upgrade.

ARO では etcd に格納されるデータは暗号化されますか?Is data stored in etcd encrypted on ARO?

etcd レベルでは暗号化されません。It is not encrypted on the etcd level. このオプションをオンにすることは、現在サポートされていません。The option to turn it on is currently unsupported. OpenShift ではこの機能がサポートされますが、これをロードマップに加えるには、エンジニアリングの作業が必要です。OpenShift supports this feature, but engineering efforts are required to make it on the road map. データはディスク レベルで暗号化されます。The data is encrypted at the disk level. 詳細については、「データストア層でのデータの暗号化」を参照してください。Refer to Encrypting Data at Datastore Layer for more information.

基になる VM のログを顧客のログ分析システムにストリーミングできますか?Can logs of underlying VMs be streamed out to a customer log analysis system?

Syslog、Docker のログ、ジャーナル、dmesg は、マネージド サービスによって処理され、顧客には公開されません。Syslog, docker logs, journal, and dmesg are handled by the managed service and are not exposed to customers.

顧客はどのようにしてノード レベルで CPU やメモリなどのメトリックにアクセスし、スケーリングや問題のデバッグなどを実行できますか。ARO クラスターでは kubectl top を実行できないようです。How can a customer get access to metrics like CPU/memory at the node level to take action to scale, debug issues, etc. I cannot seem to run kubectl top on an ARO cluster.

顧客管理者クラスター ロールで oc adm top nodes または kubectl top nodes コマンドを使用することで、ノード レベルで CPU/メモリ メトリックにアクセスできます。Customers can access the CPU/Memory metrics at the node level by using the command oc adm top nodes or kubectl top nodes with the customer-admin clusterrole. また、oc adm top pods または kubectl top pods コマンドを使用して、pods の CPU/メモリ メトリックにアクセスすることもできます。Customers can also access the CPU/Memory metrics of pods with the command oc adm top pods or kubectl top pods

ARO の既定のポッド スケジューラ構成とは何ですか?What is the default pod scheduler configuration for ARO?

ARO では、OpenShift に付属する既定のスケジューラを使用します。ARO uses the default scheduler that ships in OpenShift. ARO でサポートされていない追加のメカニズムがいくつかあります。There are a couple of additional mechanisms that are not supported in ARO. 詳細については、既定のスケジューラのドキュメントマスター スケジューラのドキュメントを参照してください。Refer to default scheduler documentation and master scheduler documentation for more details.

高度なスケジュールまたはカスタム スケジュールは、現在サポートされていません。Advanced/Custom scheduling is currently unsupported. 詳細については、スケジュールのドキュメントを参照してください。Refer to the Scheduling documentation for more details.

デプロイをスケールアップする場合、サービスのすべてのポッドが 1 つの障害ドメインの障害によってダウンしないことを確実にするために、Azure 障害ドメインはポッド配置にどのようにマップされますか?If we scale up the deployment, how do Azure fault domains map into pod placement to ensure all pods for a service do not get knocked out by a failure in a single fault domain?

Azure で仮想マシン スケール セットを使用すると、既定で 5 つの障害ドメインがあります。There are by default five fault domains when using virtual machine scale sets in Azure. スケール セット内の各仮想マシン インスタンスは、これらの障害ドメインのいずれかに配置されます。Each virtual machine instance in a scale set will get placed into one of these fault domains. これにより、クラスター内のコンピューティング ノードにデプロイされたアプリケーションが別々の障害ドメインに確実に配置されるようになります。This ensures that applications deployed to the compute nodes in a cluster will get placed in separate fault domains.

詳細については、「仮想マシン スケール セットに対する障害ドメインの適切な数を選択する」を参照してください。Refer to Choosing the right number of fault domains for virtual machine scale set for more details.

ポッドの配置を管理する方法はありますか?Is there a way to manage pod placement?

顧客は、顧客管理者としてノードを取得したり、ラベルを表示したりできます。これにより、スケール セット内の任意の VM を対象にする方法が提供されます。Customers have the ability to get nodes and view labels as the customer-admin. This will provide a way to target any VM in the scale set.

特定のラベルを使用する場合は、次の点に注意してください。Caution must be used when using specific labels:

  • ホスト名を使うことはできません。Hostname must not be used. ホスト名はアップグレードと更新によって頻繁にローテーションされるため、変更が保証されます。Hostname gets rotated often with upgrades and updates and is guaranteed to change.

  • 顧客に特定のラベルまたは配置戦略の要求がある場合は、これを実現できますが、エンジニアリングの作業が必要であり、現時点ではサポートされていません。If the customer has a request for specific labels or a deployment strategy, this could be accomplished but would require engineering efforts and is not supported today.

ARO クラスター内のポッドの最大数とは何ですか?What is the maximum number of pods in an ARO cluster?  ARO のノードごとの最大ポッド数とは何ですか?  What is the maximum number of pods per node in ARO?

Azure Red Hat OpenShift 3.11 ではノードあたりのポッド数が 50 個に制限されており、ARO ではコンピューティング ノードが 20 個に制限されているため、ARO クラスターでサポートされるポッドの最大数は 50*20 = 1000 になります。Azure Red Hat OpenShift 3.11 has a 50-pod per node limit with ARO having a 20-compute node limit, so that caps the maximum number of pods supported in an ARO cluster to 50*20 = 1000.

プライベート VNET にデプロイする IP 範囲を指定して、ピアリングされた他の企業 VNET との競合を回避することはできますか?Can we specify IP ranges for deployment on the private VNET, avoiding clashes with other corporate VNETs once peered?

Azure Red Hat OpenShift では、VNET ピアリングをサポートしており、顧客がピアリングする VNET と、OpenShift ネットワークが動作する VNET CIDR を提供することを許可します。Azure Red Hat OpenShift supports VNET peering and allows the customer to provide a VNET to peer with and a VNET CIDR in which the OpenShift network will operate.

ARO によって作成された VNET は保護され、構成の変更は受け入れられません。The VNET created by ARO will be protected and will not accept configuration changes. ピアリングされた VNET は顧客によって制御され、そのサブスクリプションに存在します。The VNET that is peered is controlled by the customer and resides in their subscription.

クラスターは顧客のサブスクリプション内に存在しますか?Does the cluster reside in a customer subscription? 

Azure マネージド アプリケーションは、顧客のサブスクリプションを利用するロックされたリソース グループ内に存在します。The Azure Managed Application lives in a locked Resource Group with the customer subscription. 顧客は、その RG 内のオブジェクトを表示できますが、変更はできません。Customer can view objects in that RG but not modify.

SDN モジュールは構成可能ですか?Is the SDN module configurable?

SDN は openshift-ovs-networkpolicy であり、構成することはできません。SDN is openshift-ovs-networkpolicy and is not configurable.

マスター/インフラストラクチャ/アプリ ノードでは、どの UNIX 権限 (IaaS 内) を使用できますか?Which UNIX rights (in IaaS) are available for Masters/Infra/App Nodes?

このオファリングには該当しません。Not applicable to this offering. ノード アクセスは禁止されています。Node access is forbidden.

私たちには、どの OCP 権限がありますか?Which OCP rights do we have? クラスター管理者ですか?Cluster-admin? プロジェクト管理者ですか?Project-admin?

詳細については、Azure Red Hat OpenShift クラスター管理者の概要に関するページを参照してください。For details, see the Azure Red Hat OpenShift cluster administration overview.

LDAP と共に利用されるのは、どの種類のフェデレーションですか?Which kind of federation with LDAP?

これは、Azure AD の統合によって実現されます。This would be achieved via Azure AD integration. 

他の顧客と共有される ARO 内の要素はありますか?Is there any element in ARO shared with other customers? それとも、すべてが独立しているのでしょうか?Or is everything independent?

各 Azure Red Hat OpenShift クラスターは指定された顧客専用であり、その顧客のサブスクリプション内に存在します。Each Azure Red Hat OpenShift cluster is dedicated to a given customer and lives within the customer's subscription. 

任意の永続ストレージ ソリューション (OCSなど) を選ぶことはできますか。Can we choose any persistent storage solution, like OCS? 

2 つのストレージ クラスから選ぶことができます。Azure Disk と Azure File です。Two storage classes are available to select from: Azure Disk and Azure File.

クラスターはどのように更新されますか (脆弱性に起因するメジャーとマイナーを含む)。How is a cluster updated (including majors and minors due to vulnerabilities)?

一般的なアップグレード プロセスとは何ですか?」を参照してください。See What is the general upgrade process?

どの Azure Load Balancer が ARO によって使用されますか?What Azure Load balancer is used by ARO?  Standard ですか、それとも Basic ですか、また、構成は可能ですか?  Is it Standard or Basic and is it configurable?

ARO では Standard の Azure Load Balancer が使用され、構成することはできません。ARO uses Standard Azure Load Balancer, and it is not configurable.

ARO では、NetApp ベースのストレージを使用できますか?Can ARO use NetApp-based storage?

現時点では、サポートされているストレージ オプションは、Azure Disk および Azure File ストレージ クラスだけです。At the moment the only supported storage options are Azure Disk and Azure File storage classes.