Red Hat OpenShift ================= EDB CloudNativePGクラスターは :ref:`Red Hat OpenShift Container Platform (OCP) version 4.x ` で実行することが認定されています `Red Hat Catalog `_ から直接利用できます。 このセクションの目的は、組織のセキュリティとアクセス制御ポリシーに基づいて、EDB CloudNativePGクラスターの最適なインストール方法を決定するのに役立つことです。 最初の重要なステップは、OpenShift環境でのPostgreSQLクラスターの :ref:`アーキテクチャ <アーキテクチャ>` をデザインすることです。 アーキテクチャが明確になったら、インストールを続行できます。 KubernetesのEDB Postgresは、次の方法でインストールおよび管理できます。 - :ref:`OpenShift web console <#installation-via-web-console>` - フル制御の場合、\ ``oc`` と呼ばれる :ref:`OpenShift command-line interface (CLI) <#installation-via-the-oc-cli>` EDB CloudNativePGクラスターは、OpenShiftで定義された使用可能なインストールモードをすべてサポートしています。 - クラスタ全体、すべての名前空間 - ローカル、単一の名前空間 - ローカル、複数の名前空間を監視する ``oc`` を使用してのみ使用可能 .. Note:: プロジェクトは、追加のアノテーションを備えたKubernetes名前空間であり、一般のユーザーのリソースへのアクセスが管理される中心的な手段です。 ほとんどの場合、EDB CloudNativePG クラスターのデフォルトのクラスター全体のインストールが推奨され、PostgreSQLクラスターの集中管理または委任管理RBAC定義に従って特定のユーザー/プロジェクトに制限されます :ref:`OpenShiftの重要な概念 ` を参照してください および以下の :ref:`ユーザーと権限 <ユーザーと権限>` )。 .. Important:: インストールとアップグレードの両方のプロセスでは、 `cluster-admin` 権限を持つアカウントを使用してOpenShift Container Platformクラスターにアクセスする必要があります。 :ref:`Default cluster roles ` より、 `cluster-admin` は*「プロジェクトで任意のアクションを実行できるスーパーユーザー。ローカルバインディングでユーザーにバインドされると、プロジェクト内のすべてのリソースのクォータとすべてのアクションを完全に制御します。」*。 アーキテクチャ -------------- 汎用 :ref:`Kubernetes/PostgreSQL architecture page ` に含まれているのと同じ概念 同様にOpenShiftを適用します。 ここでも、重要な要素は、OpenShift環境のアベイラビリティーゾーンまたはデータセンターの数です。 :ref:`Disaster Recovery Strategies for Applications Running on OpenShift ` で概説されている ステートフルアプリケーションについて2020年にRaffaele Spazzoliが書いたブログ記事によると、EDB CloudNativePGクラスターを完全に活用するには、3つ以上のアベイラビリティーゾーンにまたがるOpenShiftクラスターを計画、設計、実装する必要があります。これは、ほとんどのパブリッククラウドプロバイダーの展開では問題を引き起こすことはありませんが、オンプレミスのシナリオでは間違いなく課題です。 OpenShiftクラスターに **1つのアベイラビリティーゾーン** のみの場合、そのゾーンは高可用性の観点からの単一ポイント障害SPoFです。シェアナッシングアーキテクチャを賢明に採用し、PostgreSQLクラスターが次のことを確認している場合。少なくとも1つのスタンバイ同期レプリケーションを使用する場合は2つ、および各PostgreSQLインスタンスは別のストレージを使用する別のKubernetesワーカーノードで実行されていること。継続的なバックアップデータがOpenShiftクラスターの外部のストレージサービスに追加で保存されることを確認して、データセンターを超えてディザスターリカバリー操作を実行できます。 ほとんどの場合、アクティブ/パッシブ戦略では、同じ大都市圏または別のリージョンの別のデータセンターに別のOpenShiftクラスターが存在します。特集ページで説明しているように、これは主にディザスターリカバリーソリューションであることを理解した上で、独立した :ref:`レプリカクラスター <レプリカクラスター>` をセットアップできます。非常に効果的ですが、手動介入を必要とするいくつかの制限があります。カスケード方法でも、同じソリューションを追加のOpenShiftクラスターに適用できます。 一方、OpenShiftクラスターがリージョン内の **マルチプルのアベイラビリティーゾーン** にまたがる場合、復元力と自己修復のためのオペレーターの機能を完全に活用でき、リージョンはSPoFになることができます。つまり、リージョン全体を停止して、クラスターをダウンさせます。さらに、前述のように、レプリカクラスターを設定することにより、さまざまなリージョンの複数のOpenShiftクラスターを利用できます。 PostgreSQLワークロードのノードの予約 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PostgreSQLデータベース操作で最適なパフォーマンスとリソース割り当てを得るには、本番で特定のワーカーノードを\ ``postgres`` 専用に割り当てて、PostgreSQLワークロードを分離することを強くお勧めします。これは、単一のアベイラビリティーゾーンで動作しているか、マルチアベイラビリティーゾーン環境で動作しているかにかかわらず、特に重要です。 PostgreSQLワークロードの実行専用のOpenShiftのワーカーノードは、通常 **Postgresノード** または\ ``postgres`` ノードと呼ばれます。 この専用のアプローチにより、PostgreSQLワークロードが他のアプリケーションとリソースを競合しないことが保証され、安定性とパフォーマンスの向上につながります。 詳細については、 :ref:`PostgreSQLワークロードのノードの予約 ` を参照してください。 ドキュメント。 OpenShiftで作業する場合の主な違いは、以下で説明するように、ラベルとテイントがノードに適用される方法に関係します。 ノードを\ ``postgres`` ノードとしてラベル付けするには、次のコマンドを実行します。 .. code:: sh oc label node node-role.kubernetes.io/postgres= ``postgres`` テイントをノードに適用するには、次のコマンドを使用します。 .. code:: sh oc adm taint node node-role.kubernetes.io/postgres=:NoSchedule ノードを正しくラベル付けとテインメントすることにより、アフィニティと寛容を介してこれらの専用ノードでPostgreSQLワークロードのみがスケジュールされ、データベース環境の安定性とパフォーマンスが強化されます。 OpenShiftの重要な概念 --------------------- EDB CloudNativePG クラスターオペレーターがOpenShift環境にどのように適合するかを理解するには、次のKubernetes関連のトピックに精通する必要があります。 - オペレーター - 認証 - ロールベースのアクセス制御RBACを介した承認 - サービスアカウントとユーザー - ルール、ロール、およびバインディング - プロジェクトを介したクラスターRBACとローカルRBAC これは、オペレーターのデフォルトのクラスター全体のインストールで必要とされる昇格した権限に慣れていない場合に特に当てはまります。 また、クラスターロール、ローカルロール、クラスターロールバインディング、ローカルロールバインディング、ユーザー、グループ、サービスアカウント間の関係を明確に示しているため、OpenShiftドキュメントから以下の図を選択しました。 |OpenShift Cluster Roles| 以下の\ `“Predefined RBAC objects” section <#predefined-rbac-objects>`__\ には、EDB CloudNativePGクラスターがKubernetesおよびOpenShift RBAC実装に準拠する方法に関する重要な情報が含まれており、デフォルトでインストールされているクラスターロール、ロール、サービスアカウントをカバーしています。 上記の概念に精通している場合は、選択したインストール方法に直接進むことができます。 それ以外の場合、OpenShiftドキュメントとRed Hatブログから取得した次のリソースを読むことをお勧めします。 - :ref:`Operator Lifecycle Manager (OLM) concepts and resources ` - :ref:`Understanding authentication ` - :ref:`Role-based access control (RBAC) ` 、承認のルール、ロール、バインディング、およびプロジェクトを介したクラスターRBACとローカルRBACをカバー - :ref:`Default project service accounts and roles ` - `With Kubernetes Operators comes great responsibility `_ クラスターサービスバージョンCSV ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 技術的には、オペレーターは、EDBによって定義されたクラスターサービスバージョンCSVに従って、Operator Lifecycle ManagerOLMを介してOpenShiftで実行されるように設計されています。 CSVは、ユーザーインターフェイスWebダッシュボードから利用可能だけでなく、オペレーターが必要とするRBACルール、およびオペレーターが定義および所有するカスタムリソースたとえば\ ``Cluster`` などを定義するYAMLマニフェスト。 CSVは、オペレーターの使用可能な\ ``installModes`` 、つまり\ ``AllNamespaces`` クラスター全体、\ ``SingleNamespace`` シングルプロジェクト、\ ``MultiNamespace`` マルチプロジェクト、および\ ``OwnNamespace`` も定義します。 .. Seealso:: :ref:`Operator group membership ` を読むと、CSVとインストールモードの詳細を見つけることができます と :ref:`Defining cluster service versions (CSVs) ` OpenShiftドキュメントより。 マルチテナント管理の制限 ^^^^^^^^^^^^^^^^^^^^^^^^ Red Hat OpenShift Container Platformは、単一のクラスターにオペレーターのさまざまなバリエーションを同時にインストールすることに対する限定的なサポートを提供します。他のオペレーターと同様に、EDB CloudNativePG クラスターはコントロールプレーンの拡張機能になります。コントロールプレーンはOpenShiftクラスターのすべてのテナントプロジェクトの間で共有されるため、オペレーターもマルチテナント環境では共有リソースになります。 Operator Lifecycle ManagerOLMは、異なる名前空間にオペレーターを複数回インストールできますが、1つの重要な制限があります。すべてが同じAPIバージョンのオペレーターを共有する必要があります。 詳細は、 :ref:`Operator groups ` を参照してください。 OpenShiftドキュメント。 チャンネル ---------- バージョン1.16.0のリリース以降、EDB CloudNativePGクラスターは次の `OLM channels `_ で利用できます。 - ``fast`` チャンネルのヘッドバージョンは、常にEDB CloudNativePGクラスターの最新の利用可能なマイナーリリースでの最新の利用可能なパッチリリースです。 - ``stable-vX.Y`` チャンネルのヘッドバージョンは、常にEDB CloudNativePGクラスターのX.Yマイナーリリースで利用可能な最新のパッチリリースです。 ``fast`` には、複数のマイナーバージョンにまたがるバージョンが含まれる場合がありますが、 ``stable-vX.Y`` ブランチには、同じマイナーリリースのパッチバージョンのみが含まれます。 CloudNativePGとEDB CloudNativePGクラスターは両方とも *トランク開発* および *継続的デリバリー* DevOps原則を使用して開発されていることを考慮すると、 ``fast`` チャネルを使用することをお勧めします。 ``stable`` チャンネルについて ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``stable`` チャネルは、以前にEDBが\ ``cloud-native-postgresql`` を配布するために使用していました。このチャンネルは **時代遅れ** であり、削除されました。 現在\ ``stable`` を使用している場合、それから移行するための2つのオプションがあります。 1. マイナーリリースに残るように\ ``stable-vX.Y`` チャンネルに移動しますたとえば、 ``stable-v1.22`` は1.22マイナーLTSリリースに残り、将来のパッチリリースを消費します。 2. 複数のマイナーリリースのサポートを導入する前の\ ``stable`` と同等の\ ``fast`` に移動します Webコンソールを介したインストール --------------------------------- EDBプライベートレジストリへのアクセスの保証 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Important:: オペレーターイメージとオペランドイメージの両方が保存されているプライベートEDBリポジトリへのアクセスが必要です。アクセスには、有効な `EDB subscription plan `_ が必要です。詳細は :ref:`Accessing EDB private image registries ` を参照してください。 OpenShiftインストールは、プライベートリポジトリに保持されているオペランドとオペレータイメージにアクセスするためにプルシークレットを使用します。 プライベートリポジトリへの資格情報を取得したら、 ``openshift-operators`` 名前空間に次の名前のプルシークレットを作成する必要があります。 - ``postgresql-operator-pull-secret`` 、EDB CloudNativePG クラスターオペレーターイメージの場合 次のように、\ ``oc create`` コマンドを介して各シークレットを作成できます。 .. code:: sh oc create secret docker-registry postgresql-operator-pull-secret \ -n openshift-operators --docker-server=docker.enterprisedb.com \ --docker-username="@@REPOSITORY@@" \ --docker-password="@@TOKEN@@" そこで - ``@@REPOSITORY@@`` は、 :ref:`Which repository to choose? ` で説明したように、リポジトリの名前です。 - ``@@TOKEN@@`` は、 :ref:`トークンの取得方法 <トークンの取得方法>` で説明しているように、EDBアカウントのリポジトリトークンです。 EDB CloudNativePG クラスターオペレーターは、OpenShiftダッシュボードからRed Hat OperatorHubで直接見つけることができます。 1. Webコンソールで\ ``Operators -> OperatorHub`` ページに移動します。 .. figure:: /images/openshift/operatorhub_1.png :width: 70% :alt: Menu OperatorHub Menu OperatorHub 2. ``Database`` セクションをスクロールするか、\ ``Filter by keyword`` ボックスこの場合は「PostgreSQL」にキーワードを入力してEDB CloudNativePG クラスターオペレーターを見つけ、選択します。 .. figure:: /images/openshift/operatorhub_2.png :width: 70% :alt: Install OperatorHub Install OperatorHub 3. Operatorに関する情報を読み、 ``Install`` を選択します。 4. 次の\ ``Operator installation`` ページでは、以下を選択することを想定しています。 - インストールモード :ref:`クラスター全体のインストール <クラスター全体のインストール>` または :ref:`single namespace <#single-project-installation>` installation - 更新チャンネル詳細については :ref:`the "Channels" section <#channels>` を参照してください-不明な場合は\ ``fast`` を選択します - 承認戦略、マーケットプレイスでの入手可能状況に従ってRed Hatによって認定されたオペレーターの新しいリリース - ``Automatic`` OLMは、実行中のオペレーターを新しいバージョンに自動的にアップグレードします - ``Manual`` ``Installed Operators`` セクションで承認を必要とすることにより、OpenShiftは人間の介入を待機します .. Important:: オペレーターのアップグレードのプロセスは、 :ref:`Installation and upgrades ` に説明されています。 .. Important:: 単一のプロジェクト、技術的には`OwnNamespace` インストールモードにオペレーターを同じクラスターに複数回インストールすることが可能です。 APIが同じである限り、異なるアップグレードポリシーですべての名前空間にオペレーターインストールが存在します :ref:`マルチテナント管理の制限 <マルチテナント管理の制限>` を参照してください。 オペレーターのクラスター全体とローカルインストールの選択は、重要なターニングポイントです。既存のローカルインストールを使用してオペレーターをグローバルにインストールしようとすると、以下のエラーがスローされることによりブロックされます。続行する場合は、最初にオペレーターのすべてのローカルインストールを削除する必要があります。 .. figure:: /images/openshift/openshift-operatorgroup-error.png :width: 70% :alt: Install failing Install failing クラスター全体のインストール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ クラスター全体のインストールでは、OpenShiftにオペレーターをデフォルトの\ ``openshift-operators`` 名前空間にインストールし、クラスター内のすべてのプロジェクトで利用できるようにします。これは、EDB CloudNativePGクラスターをインストールするデフォルトの通常推奨されるアプローチです。 .. Warning:: これは、OpenShiftクラスター内のすべてのユーザーがKubernetesオペレーターのEDB Postgresを使用、`Cluster` オブジェクトをデプロイ、または独自の名前空間で実行されている`Cluster` オブジェクトを表示できることを意味するわけではありません。 EDB CloudNativePGクラスターの管理対象カスタムリソース主に`Cluster` のものと対話するためには、ユーザーが名前空間に必要な特別なロールがいくつかあります。詳細は :ref:`ユーザーと権限 <ユーザーと権限>` を参照してください。 Webコンソールから、\ ``Installation mode`` として\ ``All namespaces on the cluster (default)`` を選択します。 .. figure:: /images/openshift/openshift-webconsole-allnamespaces.png :width: 70% :alt: Install all namespaces Install all namespaces その結果、演算子はすべての名前空間で可視されます。それ以外の場合は、他のOpenShiftオペレーターと同様に、さらにトラブルシューティングを行う問題を報告している\ ``Workloads → Pods`` ページの\ ``openshift-operators`` プロジェクトのポッドのログを確認します。 .. Important "Beware":: クラスター全体のインストールを選択すると、後で単一のプロジェクトインストールに簡単に移動できません。 単一プロジェクトのインストール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 単一プロジェクトのインストールでは、OpenShiftにOperatorを特定の名前空間にインストールし、そのプロジェクトのみで使用できるようにします。 .. Warning:: これは、名前空間内のすべてのユーザーがKubernetesオペレーターのEDB Postgresを使用、`Cluster` オブジェクトを展開、または名前空間で実行されている`Cluster` オブジェクトを表示できることを意味するわけではありません。クラスター全体のインストールモードと同様に、ユーザーがEDB CloudNativePGクラスターの管理カスタムリソース主に`Cluster` ものと対話するためには、名前空間に特別なロールがいくつか必要です。 :ref:`ユーザーと権限 <ユーザーと権限>` を参照してください。 詳細については。 Webコンソールから、 ``Installation mode`` として\ ``A specific namespace on the cluster`` を選択し、ターゲット名前空間この例では\ ``proj-dev`` を選択します。 .. figure:: /images/openshift/openshift-webconsole-singlenamespace.png :width: 70% :alt: Install one namespace Install one namespace その結果、演算子は選択した名前空間でのみ可視されます。これは、 ``Installed operators`` ページから確認できます。 .. figure:: images/openshift/openshift-webconsole-singlenamespace-list.png :alt: Install one namespace list Install one namespace list 問題が発生した場合は、 ``Workloads → Pods`` ページから、さらにトラブルシューティングを行う問題を報告している、選択したインストール名前空間のポッドのログを確認します。 .. Important "Beware":: 単一プロジェクトのインストールを選択すると、後でクラスター全体のインストールに簡単に移動できません。 このインストールプロセスは、同じOpenShiftクラスター内の複数の名前空間で繰り返すことができ、さまざまなプロジェクトにオペレーターを独立してインストールできます。この場合、 :ref:`マルチテナント管理の制限 <マルチテナント管理の制限>` を必ず読んでください。 ``oc`` CLIを介したインストール ------------------------------ .. Important:: :ref:`OpenShift CLI `oc` のインストール ` を参照してください。 ``oc`` コマンドラインインターフェイスのインストール方法については、 OpenShift Container Platform Webコンソールを使用する代わりに、OperatorHubからEDB CloudNativePG Cluster Operatorをインストールし、 ``oc`` コマンドラインインターフェイスを使用してサブスクリプションを作成できます。 ``oc`` CLIを介して、すべての名前空間、単一の名前空間または複数の名前空間にオペレーターをインストールできます。 .. Warning:: 複数の名前空間のインストールは、現在OpenShiftでサポートされています。ただし、 :ref:`definition of multiple target namespaces for an operator may be removed in future versions of OpenShift ` . このセクションでは、主に\ ``OperatorGroup`` および\ ``Subscription`` オブジェクトを作成することによる、簡単な例を使用して複数のプロジェクトへのオペレーターのインストールについて説明します。 .. Note:: この例では、オペレーターを`my-operators` 名前空間にインストールし、`web-staging` 、`web-prod` 、`bi-staging` 、および`bi-prod` 名前空間でのみ使用できるようにします。プロジェクトの名前を自由に変更するか、名前空間を追加/削除します。 1. ``cloud-native-postgresql`` オペレーターがOperatorHubから利用できることを確認します。 :: oc get packagemanifests -n openshift-marketplace cloud-native-postgresql 2. オペレーターを検査して、インストールモード特に\ ``MultiNamespace`` と使用可能なチャネルを確認します。 :: oc describe packagemanifests -n openshift-marketplace cloud-native-postgresql 3. ``web-staging`` 、\ ``web-prod`` 、\ ``bi-staging`` 、および\ ``bi-prod`` 名前空間をターゲットとするように、 ``my-operators`` 名前空間に\ ``OperatorGroup`` オブジェクトを作成します。 :: apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: cloud-native-postgresql namespace: my-operators spec: targetNamespaces: - web-staging - web-prod - bi-staging - bi-prod .. Important:: また、 :ref:`Target namespace selection ` で説明しているように、ラベルセレクターを使用して名前空間をリストすることもできます。 4. ``my-operators`` 名前空間に\ ``Subscription`` オブジェクトを作成して、 ``openshift-marketplace`` の\ ``certified-operators`` ソースで使用可能な\ ``cloud-native-postgresql`` 演算子の\ ``fast`` チャネルをサブスクライブします 前に手順1および2で見つけたとおり。 :: apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cloud-native-postgresql namespace: my-operators spec: channel: fast name: cloud-native-postgresql source: certified-operators sourceNamespace: openshift-marketplace 5. ``OperatorGroup`` および\ ``Subscription`` オブジェクトの上記のYAMLファイル定義で\ ``oc apply -f`` を使用します。 このセクションで説明する方法は、EDB CloudNativePGクラスターの事前定義された\ ``ClusterRole`` sを選択した名前空間の特定のユーザーにマッピングできるため、適切な\ ``RoleBinding`` オブジェクトと組み合わせて非常に強力です。 .. Note:: 上記の手順は、単一のプロジェクトのバインドに使用することもできます。唯一の違いは、指定されたターゲット名前空間の数1つと、場合によっては演算子グループの名前空間理想的にはターゲット名前空間と同じです。 上記の操作の結果は、以下の画像に示すように、Webコンソールから確認することもできます。 .. figure:: /images/openshift/openshift-webconsole-multinamespace.png :width: 70% :alt: Multi namespace installation displayed in the web console Multi namespace installation displayed in the web console ``oc`` を使用したクラスター全体のインストール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 必要に応じて、 ``oc`` を使用してオペレーターをグローバルにインストールし、 ``openshift-operators`` 名前空間の\ ``global-operators`` と呼ばれるデフォルトの\ ``OperatorGroup`` を利用し、同じ名前空間の\ ``cloud-native-postgresql`` オペレーターの新しい\ ``Subscription`` オブジェクトを作成することもできます。 .. code:: yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cloud-native-postgresql namespace: openshift-operators spec: channel: fast name: cloud-native-postgresql source: certified-operators sourceNamespace: openshift-marketplace 上記のYAMLファイルで\ ``oc apply -f`` を実行すると、すべての名前空間で演算子を使用できるようになります。 OpenShift CLI ``oc`` のインストール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``oc`` コマンドは、OpenShiftコマンドラインインターフェイスCLIを表します。システムにインストールすることを強くお勧めします。以下に、OpenShiftダッシュボードから\ ``oc`` をインストールするための基本的な手順を示します。 最初に、ダッシュボードの右上隅にあるクエスチョンマークを選択します。 .. figure:: /images/openshift/oc_installation_screenshot_1.png :width: 70% :alt: Command Line Tools menu Command Line Tools menu 次に、表示される指示に従って、オペレーティングシステムとアーキテクチャの点でニーズに合ったバイナリをダウンロードします。 .. figure:: /images/openshift/oc_installation_screenshot_2.png :width: 70% :alt: Command Line Tools Command Line Tools .. Seealso:: 詳細および更新情報については、公式 :ref:`OpenShift CLI documentation ` を参照してください。 Red Hatによって直接保守されています。 オペレーターのアップグレード ---------------------------- オペレーターを安全にアップグレードするには、\ ``stable-vX.Y`` チャネル、またはEDB CloudNativePGクラスターの開発トランクのヘッドをフォローする場合は\ ``fast`` チャネルにいる必要があります。 現在\ ``stable`` チャネルにいる場合は、\ ``fast`` を選択するか、Kubernetes用EDB Postgresの最新の長期サポートリリース現在\ ``stable-v1.22`` に徐々に移動する必要があります。 ``stable`` で、オペレーターのバージョンが1.15以前の場合、 ``stable-v1.15`` に移動してアップグレードしてください。次に、 ``stable-v1.16`` 、次に\ ``stable-v1.17`` で操作を繰り返し、最終的に\ ``stable-v1.18`` または\ ``fast`` に到達します。 ``stable`` で、オペレーターバージョンが1.16である場合、 ``stable-v1.16`` に移動してアップグレードしてください。次に、 ``stable-v1.17`` で操作を繰り返し、最終的に\ ``stable-v1.18`` または\ ``fast`` に到達します。 .. Warning "1.15.x, 1.16.x, and 1.17.x are now End of Life":: 1.15.xの最後にサポートされたバージョンは、2022年10月にリリースされました。1.16.xの最後にサポートされたバージョンは、2022年12月にリリースされました。1.17.xの最後にサポートされたバージョンは、2023年3月にリリースされました。これらのバージョンの将来の更新はありません。計画的。 `EDB "Platform Compatibility" page `_ を参照してください。 詳細については、 .. Important:: バージョン1.16.0、1.15.2以降で、オペレーターのステータスで条件が表される方法を変更しました。この変更により、Operator Lifecycle Managerが既存のCRと比較して新しいCRDをチェックする方法が原因で、アップグレードプロセス中に古い条件のいずれかが設定されている場合、Openshiftでオペレーターのアップグレードがハングアップする可能性があります。 この問題を回避するには、最初にバージョン1.15.5にアップグレードする必要があります。これにより、Openshiftのアップグレードを妨げているすべてのクラスターCRから問題のある条件が自動的に削除されます。 事前定義されたRBACオブジェクト ------------------------------ EDB CloudNativePGクラスターには、RBACポリシー構成に関して重要な役割を担うリソースの事前定義されたセットが付属しています。 カスタムリソース定義CRD ^^^^^^^^^^^^^^^^^^^^^^^ EDB CloudNativePG クラスターオペレーターは、次のカスタムリソース定義CRDを所有しています。 - ``Backup`` - ``Cluster`` - ``Pooler`` - ``ScheduledBackup`` - ``ImageCatalog`` - ``ClusterImageCatalog`` これは、次を実行して確認できます。 .. code:: sh oc get customresourcedefinitions.apiextensions.k8s.io | grep postgresql これは、次のようなものを返します。 .. code:: console backups.postgresql.k8s.enterprisedb.io 20YY-MM-DDTHH:MM:SSZ clusterimagecatalogs.postgresql.k8s.enterprisedb.io 20YY-MM-DDTHH:MM:SSZ clusters.postgresql.k8s.enterprisedb.io 20YY-MM-DDTHH:MM:SSZ imagecatalogs.postgresql.k8s.enterprisedb.io 20YY-MM-DDTHH:MM:SSZ poolers.postgresql.k8s.enterprisedb.io 20YY-MM-DDTHH:MM:SSZ scheduledbackups.postgresql.k8s.enterprisedb.io 20YY-MM-DDTHH:MM:SSZ サービスアカウント ^^^^^^^^^^^^^^^^^^ オペレーターがインストールされている名前空間デフォルトでは\ ``openshift-operators`` には、次の事前定義されたサービスアカウントが含まれています。\ ``builder`` 、\ ``default`` 、\ ``deployer`` 、そして最も重要な\ ``postgresql-operator-manager`` CSVによって管理されます。 .. Important:: Kubernetesのサービスアカウントは名前空間リソースです。明示的に許可されない限り、サービスアカウントは、定義された名前空間の外部でアクセスできません。 これは、次を実行して確認できます。 .. code:: sh oc get serviceaccounts -n openshift-operators これは、次のようなものを返します。 .. code:: console NAME SECRETS AGE builder 2 ... default 2 ... deployer 2 ... postgresql-operator-manager 2 ... ``default`` サービスアカウントは、Kubernetesによって自動的に作成され、すべての名前空間に存在します。 ``builder`` および\ ``deployer`` サービスアカウントは、OpenShiftによって自動的に作成されます :ref:`Default project service accounts and roles ` を参照してください。 ``postgresql-operator-manager`` サービスアカウントは、クラウドネイティブのPostgreSQLクラスターを管理する際にKubernetes / OpenShiftコントロールプレーンの一部として動作するために使用されるサービスアカウントです。 .. Important:: `postgresql-operator-manager` サービスアカウントは、オペレーターの作業を停止する可能性があるため削除しないでください。 クラスターロール ^^^^^^^^^^^^^^^^ Operator Lifecycle ManagerOLMは、クラスターロールオブジェクトのセットを自動的に作成して、ロールバインディング定義とRBACポリシーの詳細な実装を促進します。一部のクラスターロールには、EDB CloudNativePGクラスターの一部であるカスタムリソース定義に適用されるルールがありますが、より広範なKubernetes / OpenShiftレルムの一部である他です。 EDB CloudNativePGクラスターCRDのクラスターロール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :ref:`every CRD owned by EDB CloudNativePG Cluster' CSV <#custom-resource-definitions-crd>` の場合、OLMは、顧客対応ユーザーおよびサービスアカウントが使用できるいくつかの事前定義されたクラスターロールを展開します。特に - リソースの完全な管理のためのロール ``admin`` サフィックス - リソースを編集するロール ``edit`` サフィックス - リソースを表示するロール ``view`` サフィックス - 実際のCRD ``crdview`` サフィックスを表示するロール .. Important:: クラスターロール自分自身はセキュリティ上の脅威ではありません。これらは、OpenShiftで、特定のプロジェクトまたはグローバルで実際のユーザーに後で「バインド」されるロールのテンプレートを定義するための推奨される方法です。実際、クラスターロールは、グローバル権限の`ClusterRoleBinding` オブジェクトと組み合わせて、またはローカル権限の`RoleBinding` オブジェクトと組み合わせて使用できます。これにより、複数のプロジェクトでクラスターロールを再利用できると同時に、ローカルロールを介して個々のプロジェクト内のカスタマイズが可能になります。 次を実行して、事前定義されたクラスターロールのリストを確認できます。 .. code:: sh oc get clusterroles | grep postgresql これは、次のようなものを返します。 .. code:: console backups.postgresql.k8s.enterprisedb.io-v1-admin YYYY-MM-DDTHH:MM:SSZ backups.postgresql.k8s.enterprisedb.io-v1-crdview YYYY-MM-DDTHH:MM:SSZ backups.postgresql.k8s.enterprisedb.io-v1-edit YYYY-MM-DDTHH:MM:SSZ backups.postgresql.k8s.enterprisedb.io-v1-view YYYY-MM-DDTHH:MM:SSZ cloud-native-postgresql.VERSION-HASH YYYY-MM-DDTHH:MM:SSZ clusterimagecatalogs.postgresql.k8s.enterprisedb.io-v1-admin YYYY-MM-DDTHH:MM:SSZ clusterimagecatalogs.postgresql.k8s.enterprisedb.io-v1-crdview YYYY-MM-DDTHH:MM:SSZ clusterimagecatalogs.postgresql.k8s.enterprisedb.io-v1-edit YYYY-MM-DDTHH:MM:SSZ clusterimagecatalogs.postgresql.k8s.enterprisedb.io-v1-view YYYY-MM-DDTHH:MM:SSZ clusters.postgresql.k8s.enterprisedb.io-v1-admin YYYY-MM-DDTHH:MM:SSZ clusters.postgresql.k8s.enterprisedb.io-v1-crdview YYYY-MM-DDTHH:MM:SSZ clusters.postgresql.k8s.enterprisedb.io-v1-edit YYYY-MM-DDTHH:MM:SSZ clusters.postgresql.k8s.enterprisedb.io-v1-view YYYY-MM-DDTHH:MM:SSZ imagecatalogs.postgresql.k8s.enterprisedb.io-v1-admin YYYY-MM-DDTHH:MM:SSZ imagecatalogs.postgresql.k8s.enterprisedb.io-v1-crdview YYYY-MM-DDTHH:MM:SSZ imagecatalogs.postgresql.k8s.enterprisedb.io-v1-edit YYYY-MM-DDTHH:MM:SSZ imagecatalogs.postgresql.k8s.enterprisedb.io-v1-view YYYY-MM-DDTHH:MM:SSZ poolers.postgresql.k8s.enterprisedb.io-v1-admin YYYY-MM-DDTHH:MM:SSZ poolers.postgresql.k8s.enterprisedb.io-v1-crdview YYYY-MM-DDTHH:MM:SSZ poolers.postgresql.k8s.enterprisedb.io-v1-edit YYYY-MM-DDTHH:MM:SSZ poolers.postgresql.k8s.enterprisedb.io-v1-view YYYY-MM-DDTHH:MM:SSZ scheduledbackups.postgresql.k8s.enterprisedb.io-v1-admin YYYY-MM-DDTHH:MM:SSZ scheduledbackups.postgresql.k8s.enterprisedb.io-v1-crdview YYYY-MM-DDTHH:MM:SSZ scheduledbackups.postgresql.k8s.enterprisedb.io-v1-edit YYYY-MM-DDTHH:MM:SSZ scheduledbackups.postgresql.k8s.enterprisedb.io-v1-view YYYY-MM-DDTHH:MM:SSZ ``get`` コマンドを使用して、他のKubernetesリソースと同様に、実際のロールを検査できます。例 .. code:: sh oc get -o yaml clusterrole clusters.postgresql.k8s.enterprisedb.io-v1-admin 以下の関連するスキミング出力を見ると、 ``clusters.postgresql.k8s.enterprisedb.io-v1-admin`` クラスターロールが、 ``postgresql.k8s.enterprisedb.io`` APIグループで定義された\ ``cluster`` リソースのすべてを有効にしていることがわかります。 .. code:: yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: clusters.postgresql.k8s.enterprisedb.io-v1-admin rules: - apiGroups: - postgresql.k8s.enterprisedb.io resources: - clusters verbs: - * .. Seealso:: OperatorGroupによるRBACの実際の実装に興味がある場合は、 `OperatorGroup: RBAC `_ を参照してください。 Kubernetes CRDのクラスターロール ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 特定の名前空間に\ ``Subscription`` オブジェクトをインストールすると、オペレーターのクラスター全体のインストールの\ ``openshift-operators`` など、OLMは、オペレーターが使用する\ ``postgresql-operator-manager`` サービスアカウントに権限を付与するために使用されるクラスターロールも作成します。このクラスターロールの名前は、インストールされたオペレーターのバージョンとインストール時間によって異なるため、異なります。 次のコマンドを実行して、取得できます。 .. code:: sh oc get clusterrole --selector=olm.owner.kind=ClusterServiceVersion 次に、上記のクエリーで返された名前は\ ``cloud-native-postgresql.VERSION-HASH`` のフォームを持つ必要がありますを使用して、 ``describe`` コマンドを介してルール、リソース、および動詞を確認できます。 .. code:: sh oc describe clusterrole cloud-native-postgresql.VERSION-HASH .. code:: console Name: cloud-native-postgresql.VERSION.HASH Labels: olm.owner=cloud-native-postgresql.VERSION olm.owner.kind=ClusterServiceVersion olm.owner.namespace=openshift-operators operators.coreos.com/cloud-native-postgresql.openshift-operators= Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- configmaps [] [] [create delete get list patch update watch] secrets [] [] [create delete get list patch update watch] services [] [] [create delete get list patch update watch] deployments.apps [] [] [create delete get list patch update watch] poddisruptionbudgets.policy [] [] [create delete get list patch update watch] backups.postgresql.k8s.enterprisedb.io [] [] [create delete get list patch update watch] clusters.postgresql.k8s.enterprisedb.io [] [] [create delete get list patch update watch] poolers.postgresql.k8s.enterprisedb.io [] [] [create delete get list patch update watch] scheduledbackups.postgresql.k8s.enterprisedb.io [] [] [create delete get list patch update watch] persistentvolumeclaims [] [] [create delete get list patch watch] pods/exec [] [] [create delete get list patch watch] pods [] [] [create delete get list patch watch] jobs.batch [] [] [create delete get list patch watch] podmonitors.monitoring.coreos.com [] [] [create delete get list patch watch] serviceaccounts [] [] [create get list patch update watch] rolebindings.rbac.authorization.k8s.io [] [] [create get list patch update watch] roles.rbac.authorization.k8s.io [] [] [create get list patch update watch] leases.coordination.k8s.io [] [] [create get update] events [] [] [create patch] mutatingwebhookconfigurations.admissionregistration.k8s.io [] [] [get list update] validatingwebhookconfigurations.admissionregistration.k8s.io [] [] [get list update] customresourcedefinitions.apiextensions.k8s.io [] [] [get list update] namespaces [] [] [get list watch] nodes [] [] [get list watch] clusters.postgresql.k8s.enterprisedb.io/status [] [] [get patch update watch] poolers.postgresql.k8s.enterprisedb.io/status [] [] [get patch update watch] configmaps/status [] [] [get patch update] secrets/status [] [] [get patch update] backups.postgresql.k8s.enterprisedb.io/status [] [] [get patch update] scheduledbackups.postgresql.k8s.enterprisedb.io/status [] [] [get patch update] pods/status [] [] [get] clusters.postgresql.k8s.enterprisedb.io/finalizers [] [] [update] poolers.postgresql.k8s.enterprisedb.io/finalizers [] [] [update] .. Important:: 上記の権限は、Kubernetes APIサーバーと対話するためにオペレーターのサービスアカウント専用に予約されています。 これらは、 `Cluster` 、`Pooler` 、`Backup` 、および`ScheduledBackup` リソースとのみ対話するオペレーターのユーザーは直接アクセスできません。 :ref:`EDB CloudNativePGクラスターCRDのクラスターロール ` を参照してください。 オペレーターは、PostgreSQL管理に関連する多くの操作を宣言的な方法で自動化します。それ以外の場合は、手動で命令的介入を必要とします。このような操作には、RBACたとえばサービスアカウント、ポッドたとえばセキュリティコンテキスト制約など、およびPostgresレベルたとえばTLS証明書などのセキュリティ関連事項も含まれます。 オペレーターがこれらの昇格された権限を必要とする理由の詳細については、 :ref:`Security / Cluster / RBAC ` を参照してください。 ユーザーと権限 -------------- EDB CloudNativePG クラスターオペレーターを使用する非常に一般的な方法は、 ``cluster-admin`` ロールに依存し、リソースを一元管理することです。 または、他のオペレーターまたはリソースと同様に、Kubernetes / OpenShiftで利用可能なRBACフレームワークを使用できます。 たとえば、他のクラウドネイティブアプリケーションと同様に、\ ``clusters.postgresql.k8s.enterprisedb.io-v1-admin`` クラスターロールを特定の名前空間の特定のグループまたはユーザーにバインドすることに関心がある場合があります。次の例は、そのクラスターロールを\ ``web-prod`` プロジェクト内の特定のユーザーにバインドします。 .. code:: yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: web-prod-admin namespace: web-prod subjects: - kind: User apiGroup: rbac.authorization.k8s.io name: mario@cioni.org roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: clusters.postgresql.k8s.enterprisedb.io-v1-admin 他の事前定義された\ ``ClusterRole`` でも同じプロセスを繰り返すことができます。 一方、クラスターロールを使用したくない場合は、この例のように特定の名前空間ロールを作成できます。 .. code:: yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: web-prod-view namespace: web-prod rules: - apiGroups: - postgresql.k8s.enterprisedb.io resources: - clusters verbs: - get - list - watch 次に、このロールを特定のユーザーに割り当てます。 .. code:: yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: web-prod-view namespace: web-prod roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: web-prod-view subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: web-prod-developer1 この最後の例では、その名前空間\ ``web-prod`` のオペレーターによって管理されているすべてのリソースへの管理権限\ ``verbs`` が\ ``*`` と等しいロールを作成します。 .. code:: yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: web-prod-admin namespace: web-prod rules: - apiGroups: - postgresql.k8s.enterprisedb.io resources: - clusters - backups - scheduledbackups - poolers verbs: - * ポッドセキュリティ標準 ---------------------- OpenShiftのEDB CloudNativePGクラスターは、 ``restricted`` および\ ``restricted-v2`` SCC ``SecurityContextConstraints`` をサポートします。これは、実行しているEDB CloudNativePGクラスターとOpenShiftのバージョンによって異なります。次の表と注意事項に細心の注意を払ってください。 .. csv-table:: :header: EDB CloudNativePG Cluster Version,OpenShift Versions,Supported SCC :widths: 10,10,15 :align: left :class: longtable 1.24.x,4.12-4.17,"restricted, restricted-v2" 1.23.x,4.12-4.16,"restricted, restricted-v2" 1.22.x,4.12-4.16,"restricted, restricted-v2" 1.18.x,4.10-4.13,"restricted, restricted-v2" .. Important:: バージョン4.10は`restricted` のみを提供しているため、EDB CloudNativePG クラスターバージョン1.18および1.19は`restricted` をサポートしています。 Openshift 4.11では`restricted` が`restricted-v2` に置き換えられたため、Kubernetes用EDB Postgresの将来のリリースは`restricted` をサポートする保証はありません。 .. Important "Security changes in OpenShift >=4.11":: Kubernetes 1.21では、 `PodSecurityPolicy` がPod Security Admission Controllerに置き換えられ、Kubernetes内のセキュリティを管理する新しいデフォルト方法になりました。 Kubernetes 1.21を実行しているOpenshift 4.11には、ワークロードを管理するデフォルトのSCCになるSecurityContextConstraintsSCCの新しいセットも含まれています。これらの新しいSCCは、`restricted-v2` 、`nonroot-v2` 、および`hostnetwork-v2` です。詳細については、 :ref:`Important OpenShift changes to Pod Security Standards ` を参照してください。 オペレーターは、最初からセキュリティを重視して開発されたため、常にRed Hat認定プロセスを遵守することに加えて、KubernetesのEDB PostgresはOpenShift 4.11で導入された新しいSCCの下で動作します。 デフォルトでは、EDB CloudNativePGクラスターはすべての機能をドロップします。これにより、ライフサイクル中にオペレーターが安全でない機能を利用しないことが保証されます。 OpenShiftでは、OpenShift展開から各ポッドの\ ``SecurityContext.SeccompProfile`` を継承します。これは、Pod Security Admission Controllerによって設定されます。 .. Note:: `nonroot-v2` および`hostnetwork-v2` が制限の少ないSCCとして認定されている場合でも、当社はそれらに対してテストを実行していないため、これらのSCCが動作することを保証できません。そうは言っても、 `nonroot-v2` および`hostnetwork-v2` は`restricted-v2` のルールのサブセットであるため、これらが機能しないと信じる理由はありません。 プーラーイメージのカスタマイズ ------------------------------ デフォルトでは、 ``Pooler`` リソースは、 ``quay.io/enterprisedb/pgbouncer`` イメージで実行される\ ``pgbouncer`` コンテナを持つポッドを作成します。 .. Note "There's more":: プーラーのポッドのカスタマイズの詳細については、接続プーリングドキュメントの :ref:`ポッドテンプレート <ポッドテンプレート>` セクションを参照してください。 高度なインターフェイスからイメージ名を変更できます。具体的には、 *“Template”* セクションを開き、 *“Spec > Containers”* の下で *“Add Container”* を選択します。 .. figure:: /images/pgbouncer-pooler-template.png :width: 70% :alt: Pooler template Pooler template 次に - コンテナの名前として\ ``pgbouncer`` を設定しますポッドテンプレートの必須フィールド - 必要に応じて *“Image”* フィールドを設定します以下の画像を参照してください。 .. figure:: /images/pgbouncer-pooler-image.png :width: 70% :alt: Pooler image Pooler image VeleroのOADP ------------ EDB CloudNativePG クラスターオペレーターは、 `Velero `_ を管理するために :ref:`Openshift API for Data Protection ` オペレーターの使用を推奨します OpenShift環境。 EDB CloudNativePG クラスターがVeleroと統合する方法に関する具体的な詳細は、アドオンドキュメントの :ref:`Velero section ` で見つけることができます。 :ref:`OADP operator ` は、EDBで直接サポートされていないコミュニティオペレーターです。 OADPオペレーターは、 EDB PostgresでVeleroを使用する必要はありませんが、OpenShiftにVeleroをインストールする便利な方法です。 モニタリングとメトリック ------------------------ OpenShiftには、KubernetesのEDB Postgresを含むユーザー定義プロジェクトに活用できる `Prometheus `_ インストールが含まれています。 GrafanaはOpenShiftに含まれなくなったため、Grafana統合はこのガイドの範囲外です。 このセクションでは、デフォルトのOpenShiftインストールを活用して、基本的なオブザーバビリティを開始する方法を示します。 :ref:`OpenShift monitoring stack overview ` を参照してください。 さらなる背景については。 OpenShift構成によっては、EDB CloudNativePG Clusterクラスターをモニタする前に、少しのセットアップを行う必要がある場合があります。 OpenShiftを :ref:`enable monitoring for user-defined projects ` に構成する必要があります。 おそらくOpenShift管理者に、インストールに\ ``cluster-monitoring-config`` configMapがあるかどうか、存在する場合はユーザーワークロードモニタリングが有効になっているかどうかを確認する必要があります。 この\ ``configMap`` の存在を確認できます。\ ``openshift-monitoring`` 名前空間にある必要があることに注意してください。 .. code:: sh oc -n openshift-monitoring get configmap cluster-monitoring-config ユーザーワークロードモニタリングを有効にするには、構成マップを\ ``oc apply`` または\ ``oc edit`` 次のようにすることができます。 .. code:: yaml apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: true ``enableUserWorkload`` を設定すると、複数の監視コンポーネントが\ ``openshift-user-workload-monitoring`` 名前空間に作成されます。 .. code:: sh $ oc -n openshift-user-workload-monitoring get pod NAME READY STATUS RESTARTS AGE prometheus-operator-58768d7cc-28xb5 2/2 Running 0 5h10m prometheus-user-workload-0 6/6 Running 0 5h10m prometheus-user-workload-1 6/6 Running 0 5h10m thanos-ruler-user-workload-0 3/3 Running 0 5h10m thanos-ruler-user-workload-1 3/3 Running 0 5h10m これで、メトリックを有効にしているクラスターからメトリックを表示できるようになります。 たとえば、 ``foo`` 名前空間での監視を使用して次のクラスターを作成できます。 .. code:: sh kubectl apply -n foo -f - < 300 for: 1m labels: severity: warning - alert: BackendsWaiting annotations: description: Pod {{ $labels.pod }} has been waiting for longer than 5 minutes summary: If a backend is waiting for longer than 5 minutes expr: |- cnp_backends_waiting_total > 300 for: 1m labels: severity: warning - alert: PGDatabaseXidAge annotations: description: Over 150,000,000 transactions from frozen xid on pod {{ $labels.pod }} summary: Number of transactions from the frozen XID to the current one expr: |- cnp_pg_database_xid_age > 300000000 for: 1m labels: severity: warning - alert: PGReplication annotations: description: Standby is lagging behind by over 300 seconds (5 minutes) summary: The standby is lagging behind the primary expr: |- cnp_pg_replication_lag > 300 for: 1m labels: severity: warning - alert: LastFailedArchiveTime annotations: description: Archiving failed for {{ $labels.pod }} summary: Checks the last time archiving failed. Will be < 0 when it has not failed. expr: |- (cnp_pg_stat_archiver_last_failed_time - cnp_pg_stat_archiver_last_archived_time) > 1 for: 1m labels: severity: warning - alert: DatabaseDeadlockConflicts annotations: description: There are over 10 deadlock conflicts in {{ $labels.pod }} summary: Checks the number of database conflicts expr: |- cnp_pg_stat_database_deadlocks > 10 for: 1m labels: severity: warning - alert: ReplicaFailingReplication annotations: description: Replica {{ $labels.pod }} is failing to replicate summary: Checks if the replica is failing to replicate expr: |- cnp_pg_replication_in_recovery > cnp_pg_replication_is_wal_receiver_up for: 1m labels: severity: warning ルールを適用する前に、やはりOpenShiftのセットアップが必要になる場合があります。 ルールを適用および監視するユーザーに\ ``monitoring-rules-edit`` または少なくとも\ ``monitoring-rules-view`` ロールを割り当てる必要があります。 これには、名前空間にその権限でRoleBindingを作成することが含まれます。再度、 :ref:`relevant OpenShift document page ` を参照してください 詳細については、特に、 *Webコンソールを使用したユーザー権限の付与* セクションに関心があります。 ``monitoring-rules-edit`` のRoleBindingは名前空間に適用されるため、適切なものを取得していることを確認してください。 以前にダウンロードした\ ``cnp-prometheusrule.yaml`` ファイルにアラートが含まれているとします。これらのルールは次のようにインストールできます。 .. code:: sh oc apply -n foo -f cnp-prometheusrule.yaml これで、アラートがある場合は表示されるはずです。最初はアラートが存在しない場合があることに注意してください。 .. figure:: /images/openshift/alerts-openshift.png :width: 70% :alt: Prometheus alerts Prometheus alerts アラートルーティングと通知は、このガイドの範囲を超えています。 .. |OpenShift Cluster Roles| image:: /images/openshift/openshift-rbac.png :width: 70%