Azure Red Hat OpenShift 定義
次のセクションでは、Azure Red Hat OpenShift アカウントを管理するためのサービス定義について説明します。
請求
Azure Red Hat OpenShift クラスターは、顧客の Azure サブスクリプションにデプロイされます。 顧客は、Azure Red Hat OpenShift クラスターによって発生したコストに対して直接 Azure に支払いを行います。
Azure Red Hat OpenShift ノードは Azure 仮想マシン上で実行されます。 これらは、Azure Linux 仮想マシンの価格に応じて請求されます。 Azure Red Hat OpenShift クラスターによって消費されるコンピューティング、ネットワーキング、ストレージ リソースは、使用量に応じて請求されます。
コンピューティング とインフラストラクチャ コストに加えて、アプリケーション ノードには Azure Red Hat OpenShift ライセンス コンポーネントの追加コストが発生します。 このコストは、アプリケーション ノードの数とインスタンスの種類に基づきます。
予約や Azure の前払いなど、すべての標準の Azure 購入オプションが適用されます。 標準の Azure 購入オプションは、Azure Red Hat OpenShift に使用できます。 また、Azure Red Hat OpenShift クラスターで使用される仮想マシン、ネットワーク、ストレージ リ ソースに対して、標準の Azure 購入オプションを使用できます。
価格の詳細については、「Azure Red Hat OpenShift の価格」を参照してください。
クラスター セルフサービス
顧客は、Azure コマンドライン ユーティリティ (CLI) を使用してクラスターを作成および削除できます。 Azure Red Hat OpenShift クラスターは、クラスターが正常にデプロイされた後、その資格情報が Azure CLI から利用できる kubeadmin ユーザーを使ってデプロイします。
OpenShift Web コンソールや OpenShift CLI (oc) などのツールを使用して OpenShift API とやり取りすることで、ノードのスケーリングなど、他のすべての Azure Red Hat OpenShift クラスター アクションを実行できます。
Azure リソース アーキテクチャ
Azure Red Hat OpenShift デプロイでは、Azure サブスクリプション内に 2 つのリソース グループが必要です。 最初のリソース グループは、顧客によって作成され、クラスターの仮想ネットワーク コンポーネントが含まれます。 ネットワーク要素を別々に保つことで、顧客は要件を満たすように Azure Red Hat OpenShift を構成し、ピアリング オプションを追加できます。
2 番目のリソース グループは、Azure Red Hat OpenShift リソース プロバイダーによって作成されます。 それには、仮想マシン Azure Red Hat OpenShift ネットワーク セキュリティ グループ、ロード バランサーなど、さまざまなクラスター コンポーネントが含まれます。 Azure Red Hat OpenShift リソース グループ内にあるクラスター コンポーネントは、顧客が変更することはできません。 クラスタ構成は、OpenShift Web コンソールまたは OpenShift CLI または同様のツールを使用して、OpenShift API とのやり取りを通じて実行する必要があります。
Note
ARO リソース プロバイダーのサービス プリンシパルには、ARO クラスターの VNet に対するネットワーク共同作成者ロールが必要です。 これは、ARO リソース プロバイダーが ARO Private Link サービスやロード バランサーなどのリソースを作成するために必要です。
Red Hat オペレーター
クラスター作成時に、顧客が Azure Red Hat OpenShift クラスターに Red Hat プルシークレットを提供することが推奨されます。 Red Hat プル シークレットを使用すると、クラスターは OpenShift オペレーター ハブの他のコンテンツと共に Red Hat コンテナー レジストリにアクセスできます。
Azure Red Hat OpenShift クラスターは、Red Hat のプル シークレットを指定せずにアプリケーションを提供できますが、Operator Hub からオペレーターをインストールすることはできなくなります。
Red Hat プル シークレットは、デプロイ後のクラスターにも提供できます。
Compute
Azure Red Hat OpenShift クラスターは、3 つ以上のワーカー ノードでプロビジョニングされます。
複数の可用性ゾーンで構成されるリージョンでは、各ゾーンにワーカー ノード マシン セットが作成されます。 また、ワーカー ノードは、各マシン セットからプロビジョニングされます。
Azure リージョンが可用性ゾーンをサポートしていない場合、Azure Red Hat OpenShift クラスターは、1 つのマシン セットからワーカー ノードをプロビジョニングします。 顧客は、各リージョンでノード数と権限を増やす機能を持っています。
Azure Red Hat OpenShift クラスターは、3 つのコントロール プレーン ノードでプロビジョニングされます。 これらのノードは、etcd キー値ストアおよび API 関連のワークロードを担当します。 コントロール プレーン ノードは、顧客のワークロードに使用できません。 コントロール プレーン ノードのデプロイは、ワーカー ノードと同じ規則に従います。
- 複数の可用性ゾーンで構成されるリージョンでは、コントロール プレーン ノード マシン セットが各ゾーンに作成されます。 コントロール プレーン ノードは、各マシン セットからプロビジョニングされます。
- Azure リージョンが可用性ゾーンをサポートしていない場合、Azure Red Hat OpenShift クラスターは、コントロール プレーン ノードを 1 台のコンピューター セットからプロビジョニングします。
Azure コンピューティングの種類
サポートされているコントロール プレーンとワーカー ノードの種類とサイズの一覧については、「サポートされている仮想マシンのサイズ」を参照してください。
Azure リージョン
Azure Red Hat OpenShift でサポートされているリージョンについては、「リージョン別の利用可能な製品」に関するページを参照してください。
Azure CLI から、次のコマンドを実行して、使用可能なリージョンの一覧を表示します。
az provider show -n Microsoft.RedHatOpenShift --query "resourceTypes[?resourceType == 'OpenShiftClusters']".locations -o yaml
デプロイ後、Azure Red Hat OpenShift クラスターを別のリージョンに移動できません。 同様に、サブスクリプション間で Azure Red Hat OpenShift クラスターを転送できません。
サービス レベル アグリーメント
SLA の詳細については、「SLA for Azure Red Hat OpenShift」 を参照してください。
サポート
Azure Red Hat OpenShift のサポート要求は、次によって送信できます。
- Azure portal でのサポート要求
- Red Hat カスタマーポータル経由でのサポート要求
要求は、マイクロソフトおよび Red Hat のサポート エンジニアによってトリアージされ、対処されます。 Azure Red Hat OpenShift Red Hat Premium サポートが含まれています。 サポートには、Microsoft Azure portal からアクセスできます。
Red Hat で直接サポート チケットを開くには、クラスターにプルシークレットが必要です。 クラスターの作成時に追加することも、既存のクラスターで追加または更新することもできます。
Logging
次のセクションでは、Azure Red Hat OpenShift のセキュリティに関する情報を提供します。
クラスター操作と監査ログ
Azure Red Hat OpenShift は、クラスターとそのコンポーネントの正常性とパフォーマンスを維持するためのサービスと使用してデプロイします。 これらのサービスには、クラスター操作と監査ログが含まれます。 クラスター操作と監査ログは、サポートとトラブルシューティングのために Azure 集計システムに自動的に転送されます。 このデータには、承認されたメカニズムを経由して承認されたサポート スタッフのみがアクセスできます。
顧客のクラスター管理者は、オプションのログ スタックをデプロイして、Azure Red Hat OpenShift クラスターからすべてのログを集計できます。 たとえば、ノード システムの監査ログとインフラストラクチャ ログを集約できます。 ただし、これらのログは別のクラスター リソースを消費します。
アプリケーションのログ記録
OperatorHub.ioへのアクセスが有効になっている場合、Azure Red Hat OpenShift には、Elasticsearch、Fluentd、Kibana (EFK) に基づくオプションのログ スタックが含まれています。
ログ スタックLogging Operatorは、顧客の要件を満たすように構成できます。 ただし、これは、長期的なログ アーカイブではなく、クラスターとアプリケーションのトラブルシューティングを支援するために、短期的なリテンション期間を目的として設計されています。
クラスター ログ スタックがインストールされている場合、STDOUT に送信されるアプリケーション ログは Fluentd によって収集されます。 アプリケーション ログは、クラスター ログ スタックを経由して使用できます。 保持期間は 7 日間に設定されますが、シャードあたり 200 GiB を超えることはありません。 長期的なリテンション期間を維持するには、顧客はデプロイでサイドカー コンテナーの設計に従う必要があります。 顧客は、選択したログ集約または分析サービスにログを転送する必要があります。
監視
次のセクションでは、Azure Red Hat OpenShift のセキュリティに関する情報を提供します。
クラスターのメトリック
Azure Red Hat OpenShift は、クラスターとそのコンポーネントの正常性とパフォーマンスを維持するためのサービスと使用してデプロイします。 これらのサービスには、サポートとトラブルシューティングを目的として、Azure 集計システムへの重要なメトリックのストリーミングが含まれます。 このデータには、承認されたメカニズムを経由して承認されたサポート スタッフのみがアクセスできます。
Azure Red Hat OpenShift には、顧客がクラスターの監視を表示するために、統合された Prometheus/Grafana スタックが付属しています。 スタックには、CPU、メモリ、ネットワークベースのメトリックが含まれます。
Web コンソールからアクセスできるこれらのメトリックを使用して、Grafana ダッシュボードを使用してクラスター レベルの状態と容量/使用状況を表示することもできます。 これらのメトリックを使用すると、顧客が提供する CPU またはメモリ メトリックに基づくポッドの水平自動スケール Azure Red Hat OpenShift できます。
ネットワーク
次のセクションでは、Azure Red Hat OpenShift のセキュリティに関する情報を提供します。
ドメイン検証済みの証明書
既定では、Azure Red Hat OpenShift には、クラスターの内部サービスと外部サービスの両方に必要な TLS セキュリティ証明書が含まれています。 外部ルートの場合、トランスポート層セキュリティ (TLS) ワイルドカード証明書が提供され、クラスターにインストールされます。 TLS 証明書は、OpenShift API エンドポイントにも使用されます。 DigiCert は、これらの証明書に使用される証明機関 (CA) です。
カスタム ドメイン
デプロイ中、Azure Red Hat OpenShift では、クラスターのカスタムドメインを指定できます。 カスタムドメインは、クラスターサービスとアプリケーションの両方に使用されます。 DNS サーバーには、指定されたドメイン 2 つの DNS A レコードを作成する必要があります。
- api サーバーの IP アドレスを指す api
- * アプリケーションは、イングレス IP アドレスを指します。
Azure Red Hat OpenShift では、既定で、カスタム ドメインに作成されたすべてのルートに自己署名証明書が使用されます。 カスタムドメインを使用する場合は、クラスターに接続します。 次に、OpenShift のドキュメントに従って、イングレス コントローラー用のカスタム証明機関 CA と API サーバー用のカスタム CA を構成します。
ビルドのカスタムの CA
Azure Red Hat OpenShift では、イメージ レジストリからイメージを取得する際にビルドによって信頼される、信頼される、CA の使用がサポートされています。
ロード バランサー
Azure Red Hat OpenShift は、2 つの Azure ロード バランサーを使用してデプロイします。 1 つ目は、アプリケーションへのイグレス トラフィックと OpenShift API および Kubernetes API 用に使用されます。 2 つ目は、クラスタ コンポーネント間の内部通信に使用されます。
クラスター イングレス
プロジェクト管理者は、IP 許可リストを介したイングレス コントロールなど、さまざまな目的でルート注釈を追加できます。
イングレス ポリシーは、ovs-networkPolicy プラグインを使用する NetworkPolicy オブジェクトを使用して変更できます。 NetworkPolicy オブジェクトを使用すると、同じクラスター上のポッド間や同じ名前空間内のポッド間を含め、ポッド レベルまでのイングレス ネットワーク ポリシーを完全に制御できます。
すべてのクラスターイングレス トラフィックは、定義されたロード バランサーを通過します。
クラスターのエグレス
EgressNetworkPolicy オブジェクトによるポッド送信トラフィック制御を使用して、Azure Red Hat OpenShift で送信トラフィックを防止または制限することができます。 現在、すべての仮想マシンは、発信インターネットアクセスを持っている必要があります。
クラウド ネットワーク構成
Azure Red Hat OpenShift では、次のようなクラウド プロバイダーが管理するテクノロジを通じてプライベート ネットワーク接続を構成できます。
- VNet 接続
- Azure VNet ピアリング
- Azure VNet Gateway
- Azure Express Route
Red Hat SRE では、これらのプライベート ネットワーク接続の監視は行いません。 これらの接続を監視することは、顧客の責任です。
顧客が指定した DNS
Azure Red Hat OpenShift の顧客は、独自の DNS サーバーを指定できます。 詳細については、「Azure Red Hat OpenShift クラスター用にカスタム DNS を構成する」を参照してください。
コンテナー ネットワーク インターフェイス
Azure Red Hat OpenShift には、コンテナー ネットワーク インターフェイス (CNI) として OVN (オープン仮想ネットワーク) が付属しています。 CNI の置換はサポートされている操作ではありません。 詳細については、「Azure Red Hat OpenShift クラスター用 OVN-Kubernetes ネットワーク プロバイダー」を参照してください。
記憶域
次のセクションでは、Azure Red Hat OpenShift のセキュリティに関する情報を提供します。
保存時の暗号化
Azure Storage では、サーバー側暗号化 (SSE) を使用して、クラウドに永続化されるときにデータを自動的に暗号化します。 既定では、データは Microsoft プラットフォームのマネージド キーで暗号化されます。
ブロックス トレージ (RWO)
永続ボリュームは、読み取り/書き込み時 (RWO) である Azure ディスク ブロック ストレージによってバックアップされます。 1024-GiB ディスクは、動的に作成され、各 Azure Red Hat OpenShift コントローラー プレーン ノードに接続されます。 これらのディスクは、プレミアム SSD LRS Azure マネージド ディスクです。 既定のワーカー ノード マシン セットのディスク サイズは、クラスターの作成時に構成できます。
顧客は、要件に合わせてより多くのマシン セットを作成する権限を持っています。
永続ボリューム (PV) は、一度に 1 つのノードにのみアタッチでき、プロビジョニングされた可用性ゾーンに固有です。 可用性ゾーン内の任意のノードにアタッチできます。
Azure では、1つのノードにアタッチできる種類の PVs の数が制限されています。 Azure の制限は、顧客がワーカー ノードに選択する仮想マシンの種類とサイズによって異なります。 たとえば、Dasv4 シリーズの最大データ ディスクを表示するには、Dasv4を参照してください。
[共有ストレージ キー] (RWX)
Azure Red Hat OpenShift クラスターの共有ストレージは、顧客が構成する必要があります。 Azure ファイルのストレージ クラスを構成する方法の例については、「 Azure Red Hat OpenShift 4 で Azure ファイル ストレージクラスを作成する」 を参照してください
プラットフォーム
次のセクションでは、Azure Red Hat OpenShift プラットフォームに関する情報を提供します。
クラスターバックアップ ポリシー
重要
アプリケーションとアプリケーションデータのバックアップ計画があることが 重要 です。
アプリケーションとアプリケーション データのバックアップは、Azure Red Hat OpenShift サービスの自動化された部分ではありません。 アプリケーションの手動バックアップを実行する方法のチュートリアルについては、「Azure Red Hat OpenShift 4 クラスターアプリケーションのバックアップを作成する」を参照してください。
DaemonSet
顧客は、Azure Red Hat OpenShift でデーモンセットを作成して実行できます。 ワーカー ノードでのみ実行するように DaemonSet を制限するには、次のノードセレクタを使用します。
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
Azure Red Hat OpenShift バージョン
Azure Red Hat OpenShift はサービスとして実行されます。 これにより、最新の安定した OpenShift コンテナー プラットフォーム バージョンで最新の状態を維持することができます。 サポートとアップグレードポリシーについては、「Azure Red Hat OpenShift 4 のサポートライフサイクル」を参照してください。
サポート ライフサイクル
Azure Red Hat OpenShift サポートライフサイクルの詳細については、「Azure Red Hat OpenShift 4 のサポートライフサイクル」を参照してください。
コンテナー エンジン
Azure Red Hat OpenShift は OpenShift 4 で実行され、Kubernetes container runtime インターフェイスの CRI 実装は、唯一使用可能なコンテナー エンジンとして使用されます。
オペレーティング システム
Azure Red Hat OpenShift は、すべてのコントロールプレーンとワーカーノードのオペレーティングシステムとして Red Hat Enterprise Linux CoreOS (RHCOS) を使用して OpenShift 4 で実行されます。 Windows ワークロードは Azure OpenShift ではサポートされていません。これは、このプラットフォームでは現在のところ、Windows ワーカー ノードがサポートされていないためです。
Kubernetes オペレーターのサポート
Azure Red Hat OpenShift は、Red Hat および認定独立系ソフトウェア ベンダー (ISV) によって作成されたオペレーターをサポートします。 Red Hat が提供するオペレーターは、Red Hat でサポートされています。 ISV オペレーターは ISV でサポートされています。
OperatorHub を使用するには、Red Hat プル シークレットを使用してクラスターを構成する必要があります。 OperatorHub 使用の詳細については、「OperatorHub を理解する」を参照してください
セキュリティ
次のセクションでは、Azure OpenShift セキュリティに関する情報を提供します。
認証プロバイダー
Azure Red Hat OpenShift クラスターは、どの認証プロバイダーで構成されていません。
顧客は、Microsoft Entra ID などの独自のプロバイダーを構成する必要があります。 プロバイダーの構成については、次の記事を参照してください。
規制コンプライアンス
Azure Red Hat Openshift の規制遵守認定の詳細については、「Microsoft Azure コンプライアンス認証」を参照してください。
次のステップ
詳細については、サポート ポリシー のドキュメントを参照してください。