Red Hat OpenShift#

EDB CloudNativePGクラスターは Red Hat OpenShift Container Platform (OCP) version 4.x で実行することが認定されています

Red Hat Catalog から直接利用できます。

このセクションの目的は、組織のセキュリティとアクセス制御ポリシーに基づいて、EDB CloudNativePGクラスターの最適なインストール方法を決定するのに役立つことです。

最初の重要なステップは、OpenShift環境でのPostgreSQLクラスターのアーキテクチャをデザインすることです。

アーキテクチャが明確になったら、インストールを続行できます。 KubernetesのEDB Postgresは、次の方法でインストールおよび管理できます。

OpenShift web console
フル制御の場合、oc と呼ばれる OpenShift command-line interface (CLI)

EDB CloudNativePGクラスターは、OpenShiftで定義された使用可能なインストールモードをすべてサポートしています。

クラスタ全体、すべての名前空間
ローカル、単一の名前空間
ローカル、複数の名前空間を監視する oc を使用してのみ使用可能

注釈

プロジェクトは、追加のアノテーションを備えたKubernetes名前空間であり、一般のユーザーのリソースへのアクセスが管理される中心的な手段です。

ほとんどの場合、EDB CloudNativePG クラスターのデフォルトのクラスター全体のインストールが推奨され、PostgreSQLクラスターの集中管理または委任管理RBAC定義に従って特定のユーザー/プロジェクトに制限されます OpenShiftの重要な概念を参照してください

および以下のユーザーと権限 )。

重要

インストールとアップグレードの両方のプロセスでは、 cluster-admin 権限を持つアカウントを使用してOpenShift Container Platformクラスターにアクセスする必要があります。 Default cluster roles より、 cluster-admin は*「プロジェクトで任意のアクションを実行できるスーパーユーザー。ローカルバインディングでユーザーにバインドされると、プロジェクト内のすべてのリソースのクォータとすべてのアクションを完全に制御します。」*。

アーキテクチャ#

汎用 Kubernetes/PostgreSQL architecture page に含まれているのと同じ概念

同様にOpenShiftを適用します。

ここでも、重要な要素は、OpenShift環境のアベイラビリティーゾーンまたはデータセンターの数です。

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クラスターが存在します。特集ページで説明しているように、これは主にディザスターリカバリーソリューションであることを理解した上で、独立したレプリカクラスターをセットアップできます。非常に効果的ですが、手動介入を必要とするいくつかの制限があります。カスケード方法でも、同じソリューションを追加のOpenShiftクラスターに適用できます。

一方、OpenShiftクラスターがリージョン内の マルチプルのアベイラビリティーゾーン にまたがる場合、復元力と自己修復のためのオペレーターの機能を完全に活用でき、リージョンはSPoFになることができます。つまり、リージョン全体を停止して、クラスターをダウンさせます。さらに、前述のように、レプリカクラスターを設定することにより、さまざまなリージョンの複数のOpenShiftクラスターを利用できます。

PostgreSQLワークロードのノードの予約#

PostgreSQLデータベース操作で最適なパフォーマンスとリソース割り当てを得るには、本番で特定のワーカーノードをpostgres 専用に割り当てて、PostgreSQLワークロードを分離することを強くお勧めします。これは、単一のアベイラビリティーゾーンで動作しているか、マルチアベイラビリティーゾーン環境で動作しているかにかかわらず、特に重要です。

PostgreSQLワークロードの実行専用のOpenShiftのワーカーノードは、通常 Postgresノード またはpostgres ノードと呼ばれます。

この専用のアプローチにより、PostgreSQLワークロードが他のアプリケーションとリソースを競合しないことが保証され、安定性とパフォーマンスの向上につながります。

詳細については、 PostgreSQLワークロードのノードの予約を参照してください。

ドキュメント。 OpenShiftで作業する場合の主な違いは、以下で説明するように、ラベルとテイントがノードに適用される方法に関係します。

ノードをpostgres ノードとしてラベル付けするには、次のコマンドを実行します。

oc label node <NODE-NAME> node-role.kubernetes.io/postgres=

postgres テイントをノードに適用するには、次のコマンドを使用します。

oc adm taint node <NODE-NAME> node-role.kubernetes.io/postgres=:NoSchedule

ノードを正しくラベル付けとテインメントすることにより、アフィニティと寛容を介してこれらの専用ノードでPostgreSQLワークロードのみがスケジュールされ、データベース環境の安定性とパフォーマンスが強化されます。

OpenShiftの重要な概念#

EDB CloudNativePG クラスターオペレーターがOpenShift環境にどのように適合するかを理解するには、次のKubernetes関連のトピックに精通する必要があります。

オペレーター
認証
ロールベースのアクセス制御RBACを介した承認
サービスアカウントとユーザー
ルール、ロール、およびバインディング
プロジェクトを介したクラスターRBACとローカルRBAC

これは、オペレーターのデフォルトのクラスター全体のインストールで必要とされる昇格した権限に慣れていない場合に特に当てはまります。

また、クラスターロール、ローカルロール、クラスターロールバインディング、ローカルロールバインディング、ユーザー、グループ、サービスアカウント間の関係を明確に示しているため、OpenShiftドキュメントから以下の図を選択しました。

以下の“Predefined RBAC objects” sectionには、EDB CloudNativePGクラスターがKubernetesおよびOpenShift RBAC実装に準拠する方法に関する重要な情報が含まれており、デフォルトでインストールされているクラスターロール、ロール、サービスアカウントをカバーしています。

上記の概念に精通している場合は、選択したインストール方法に直接進むことができます。それ以外の場合、OpenShiftドキュメントとRed Hatブログから取得した次のリソースを読むことをお勧めします。

Operator Lifecycle Manager (OLM) concepts and resources
Understanding authentication
Role-based access control (RBAC) 、承認のルール、ロール、バインディング、およびプロジェクトを介したクラスターRBACとローカルRBACをカバー
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 も定義します。

参考

Operator group membership を読むと、CSVとインストールモードの詳細を見つけることができます

と Defining cluster service versions (CSVs)

OpenShiftドキュメントより。

マルチテナント管理の制限#

Red Hat OpenShift Container Platformは、単一のクラスターにオペレーターのさまざまなバリエーションを同時にインストールすることに対する限定的なサポートを提供します。他のオペレーターと同様に、EDB CloudNativePG クラスターはコントロールプレーンの拡張機能になります。コントロールプレーンはOpenShiftクラスターのすべてのテナントプロジェクトの間で共有されるため、オペレーターもマルチテナント環境では共有リソースになります。

Operator Lifecycle ManagerOLMは、異なる名前空間にオペレーターを複数回インストールできますが、1つの重要な制限があります。すべてが同じAPIバージョンのオペレーターを共有する必要があります。

詳細は、 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つのオプションがあります。

マイナーリリースに残るようにstable-vX.Y チャンネルに移動しますたとえば、 stable-v1.22 は1.22マイナーLTSリリースに残り、将来のパッチリリースを消費します。
複数のマイナーリリースのサポートを導入する前のstable と同等のfast に移動します

Webコンソールを介したインストール#

EDBプライベートレジストリへのアクセスの保証#

重要

オペレーターイメージとオペランドイメージの両方が保存されているプライベートEDBリポジトリへのアクセスが必要です。アクセスには、有効な EDB subscription plan が必要です。詳細は Accessing EDB private image registries を参照してください。

OpenShiftインストールは、プライベートリポジトリに保持されているオペランドとオペレータイメージにアクセスするためにプルシークレットを使用します。

プライベートリポジトリへの資格情報を取得したら、 openshift-operators 名前空間に次の名前のプルシークレットを作成する必要があります。

postgresql-operator-pull-secret 、EDB CloudNativePG クラスターオペレーターイメージの場合

次のように、oc create コマンドを介して各シークレットを作成できます。

oc create secret docker-registry postgresql-operator-pull-secret \
  -n openshift-operators --docker-server=docker.enterprisedb.com \
  --docker-username="@@REPOSITORY@@" \
  --docker-password="@@TOKEN@@"

そこで

@@REPOSITORY@@ は、 Which repository to choose? で説明したように、リポジトリの名前です。
@@TOKEN@@ は、トークンの取得方法で説明しているように、EDBアカウントのリポジトリトークンです。

EDB CloudNativePG クラスターオペレーターは、OpenShiftダッシュボードからRed Hat OperatorHubで直接見つけることができます。

WebコンソールでOperators -> OperatorHub ページに移動します。

Database セクションをスクロールするか、Filter by keyword ボックスこの場合は「PostgreSQL」にキーワードを入力してEDB CloudNativePG クラスターオペレーターを見つけ、選択します。

Operatorに関する情報を読み、 Install を選択します。
次のOperator installation ページでは、以下を選択することを想定しています。
- インストールモードクラスター全体のインストールまたは single namespace installation
- 更新チャンネル詳細については the "Channels" section を参照してください-不明な場合はfast を選択します
- 承認戦略、マーケットプレイスでの入手可能状況に従ってRed Hatによって認定されたオペレーターの新しいリリース
- Automatic OLMは、実行中のオペレーターを新しいバージョンに自動的にアップグレードします
- Manual Installed Operators セクションで承認を必要とすることにより、OpenShiftは人間の介入を待機します

重要

オペレーターのアップグレードのプロセスは、 Installation and upgrades に説明されています。

重要

単一のプロジェクト、技術的には`OwnNamespace` インストールモードにオペレーターを同じクラスターに複数回インストールすることが可能です。 APIが同じである限り、異なるアップグレードポリシーですべての名前空間にオペレーターインストールが存在しますマルチテナント管理の制限を参照してください。

オペレーターのクラスター全体とローカルインストールの選択は、重要なターニングポイントです。既存のローカルインストールを使用してオペレーターをグローバルにインストールしようとすると、以下のエラーがスローされることによりブロックされます。続行する場合は、最初にオペレーターのすべてのローカルインストールを削除する必要があります。

クラスター全体のインストール#

クラスター全体のインストールでは、OpenShiftにオペレーターをデフォルトのopenshift-operators 名前空間にインストールし、クラスター内のすべてのプロジェクトで利用できるようにします。これは、EDB CloudNativePGクラスターをインストールするデフォルトの通常推奨されるアプローチです。

警告

これは、OpenShiftクラスター内のすべてのユーザーがKubernetesオペレーターのEDB Postgresを使用、Cluster オブジェクトをデプロイ、または独自の名前空間で実行されている`Cluster` オブジェクトを表示できることを意味するわけではありません。 EDB CloudNativePGクラスターの管理対象カスタムリソース主に`Cluster` のものと対話するためには、ユーザーが名前空間に必要な特別なロールがいくつかあります。詳細はユーザーと権限を参照してください。

Webコンソールから、Installation mode としてAll namespaces on the cluster (default) を選択します。

その結果、演算子はすべての名前空間で可視されます。それ以外の場合は、他のOpenShiftオペレーターと同様に、さらにトラブルシューティングを行う問題を報告しているWorkloads → Pods ページのopenshift-operators プロジェクトのポッドのログを確認します。

単一プロジェクトのインストール#

単一プロジェクトのインストールでは、OpenShiftにOperatorを特定の名前空間にインストールし、そのプロジェクトのみで使用できるようにします。

警告

これは、名前空間内のすべてのユーザーがKubernetesオペレーターのEDB Postgresを使用、Cluster オブジェクトを展開、または名前空間で実行されている`Cluster` オブジェクトを表示できることを意味するわけではありません。クラスター全体のインストールモードと同様に、ユーザーがEDB CloudNativePGクラスターの管理カスタムリソース主に`Cluster` ものと対話するためには、名前空間に特別なロールがいくつか必要です。ユーザーと権限を参照してください。

詳細については。

Webコンソールから、 Installation mode としてA specific namespace on the cluster を選択し、ターゲット名前空間この例ではproj-dev を選択します。

その結果、演算子は選択した名前空間でのみ可視されます。これは、 Installed operators ページから確認できます。

問題が発生した場合は、 Workloads → Pods ページから、さらにトラブルシューティングを行う問題を報告している、選択したインストール名前空間のポッドのログを確認します。

このインストールプロセスは、同じOpenShiftクラスター内の複数の名前空間で繰り返すことができ、さまざまなプロジェクトにオペレーターを独立してインストールできます。この場合、マルチテナント管理の制限を必ず読んでください。

`oc` CLIを介したインストール#

重要

OpenShift CLI `oc のインストール <OpenShift CLI oc のインストール>` を参照してください。

oc コマンドラインインターフェイスのインストール方法については、

OpenShift Container Platform Webコンソールを使用する代わりに、OperatorHubからEDB CloudNativePG Cluster Operatorをインストールし、 oc コマンドラインインターフェイスを使用してサブスクリプションを作成できます。 oc CLIを介して、すべての名前空間、単一の名前空間または複数の名前空間にオペレーターをインストールできます。

警告

複数の名前空間のインストールは、現在OpenShiftでサポートされています。ただし、 definition of multiple target namespaces for an operator may be removed in future versions of OpenShift .

このセクションでは、主にOperatorGroup およびSubscription オブジェクトを作成することによる、簡単な例を使用して複数のプロジェクトへのオペレーターのインストールについて説明します。

注釈

この例では、オペレーターを`my-operators` 名前空間にインストールし、web-staging 、web-prod 、bi-staging 、および`bi-prod` 名前空間でのみ使用できるようにします。プロジェクトの名前を自由に変更するか、名前空間を追加/削除します。

cloud-native-postgresql オペレーターがOperatorHubから利用できることを確認します。

oc get packagemanifests -n openshift-marketplace cloud-native-postgresql

オペレーターを検査して、インストールモード特にMultiNamespace と使用可能なチャネルを確認します。

oc describe packagemanifests -n openshift-marketplace cloud-native-postgresql

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

重要

また、 Target namespace selection で説明しているように、ラベルセレクターを使用して名前空間をリストすることもできます。

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

OperatorGroup およびSubscription オブジェクトの上記のYAMLファイル定義でoc apply -f を使用します。

このセクションで説明する方法は、EDB CloudNativePGクラスターの事前定義されたClusterRole sを選択した名前空間の特定のユーザーにマッピングできるため、適切なRoleBinding オブジェクトと組み合わせて非常に強力です。

注釈

上記の手順は、単一のプロジェクトのバインドに使用することもできます。唯一の違いは、指定されたターゲット名前空間の数1つと、場合によっては演算子グループの名前空間理想的にはターゲット名前空間と同じです。

上記の操作の結果は、以下の画像に示すように、Webコンソールから確認することもできます。

Multi namespace installation displayed in the web console#

`oc` を使用したクラスター全体のインストール#

必要に応じて、 oc を使用してオペレーターをグローバルにインストールし、 openshift-operators 名前空間のglobal-operators と呼ばれるデフォルトのOperatorGroup を利用し、同じ名前空間のcloud-native-postgresql オペレーターの新しいSubscription オブジェクトを作成することもできます。

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 をインストールするための基本的な手順を示します。

最初に、ダッシュボードの右上隅にあるクエスチョンマークを選択します。

次に、表示される指示に従って、オペレーティングシステムとアーキテクチャの点でニーズに合ったバイナリをダウンロードします。

参考

詳細および更新情報については、公式 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 に到達します。

詳細については、

重要

バージョン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

これは、次を実行して確認できます。

oc get customresourcedefinitions.apiextensions.k8s.io | grep postgresql

これは、次のようなものを返します。

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によって管理されます。

重要

Kubernetesのサービスアカウントは名前空間リソースです。明示的に許可されない限り、サービスアカウントは、定義された名前空間の外部でアクセスできません。

これは、次を実行して確認できます。

oc get serviceaccounts -n openshift-operators

これは、次のようなものを返します。

NAME                          SECRETS   AGE
builder                       2         ...
default                       2         ...
deployer                      2         ...
postgresql-operator-manager   2         ...

default サービスアカウントは、Kubernetesによって自動的に作成され、すべての名前空間に存在します。 builder およびdeployer サービスアカウントは、OpenShiftによって自動的に作成されます Default project service accounts and roles を参照してください。

postgresql-operator-manager サービスアカウントは、クラウドネイティブのPostgreSQLクラスターを管理する際にKubernetes / OpenShiftコントロールプレーンの一部として動作するために使用されるサービスアカウントです。

重要

postgresql-operator-manager サービスアカウントは、オペレーターの作業を停止する可能性があるため削除しないでください。

クラスターロール#

Operator Lifecycle ManagerOLMは、クラスターロールオブジェクトのセットを自動的に作成して、ロールバインディング定義とRBACポリシーの詳細な実装を促進します。一部のクラスターロールには、EDB CloudNativePGクラスターの一部であるカスタムリソース定義に適用されるルールがありますが、より広範なKubernetes / OpenShiftレルムの一部である他です。

EDB CloudNativePGクラスターCRDのクラスターロール#

every CRD owned by EDB CloudNativePG Cluster' CSV の場合、OLMは、顧客対応ユーザーおよびサービスアカウントが使用できるいくつかの事前定義されたクラスターロールを展開します。特に

リソースの完全な管理のためのロール admin サフィックス
リソースを編集するロール edit サフィックス
リソースを表示するロール view サフィックス
実際のCRD crdview サフィックスを表示するロール

重要

クラスターロール自分自身はセキュリティ上の脅威ではありません。これらは、OpenShiftで、特定のプロジェクトまたはグローバルで実際のユーザーに後で「バインド」されるロールのテンプレートを定義するための推奨される方法です。実際、クラスターロールは、グローバル権限の`ClusterRoleBinding` オブジェクトと組み合わせて、またはローカル権限の`RoleBinding` オブジェクトと組み合わせて使用できます。これにより、複数のプロジェクトでクラスターロールを再利用できると同時に、ローカルロールを介して個々のプロジェクト内のカスタマイズが可能になります。

次を実行して、事前定義されたクラスターロールのリストを確認できます。

oc get clusterroles | grep postgresql

これは、次のようなものを返します。

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リソースと同様に、実際のロールを検査できます。例

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 リソースのすべてを有効にしていることがわかります。

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:
  - *

参考

OperatorGroupによるRBACの実際の実装に興味がある場合は、 OperatorGroup: RBAC を参照してください。

Kubernetes CRDのクラスターロール#

特定の名前空間にSubscription オブジェクトをインストールすると、オペレーターのクラスター全体のインストールのopenshift-operators など、OLMは、オペレーターが使用するpostgresql-operator-manager サービスアカウントに権限を付与するために使用されるクラスターロールも作成します。このクラスターロールの名前は、インストールされたオペレーターのバージョンとインストール時間によって異なるため、異なります。

次のコマンドを実行して、取得できます。

oc get clusterrole --selector=olm.owner.kind=ClusterServiceVersion

次に、上記のクエリーで返された名前はcloud-native-postgresql.VERSION-HASH のフォームを持つ必要がありますを使用して、 describe コマンドを介してルール、リソース、および動詞を確認できます。

oc describe clusterrole cloud-native-postgresql.VERSION-HASH

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:  <none>
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]

重要

上記の権限は、Kubernetes APIサーバーと対話するためにオペレーターのサービスアカウント専用に予約されています。これらは、 Cluster 、Pooler 、Backup 、および`ScheduledBackup` リソースとのみ対話するオペレーターのユーザーは直接アクセスできません。 EDB CloudNativePGクラスターCRDのクラスターロールを参照してください。

オペレーターは、PostgreSQL管理に関連する多くの操作を宣言的な方法で自動化します。それ以外の場合は、手動で命令的介入を必要とします。このような操作には、RBACたとえばサービスアカウント、ポッドたとえばセキュリティコンテキスト制約など、およびPostgresレベルたとえばTLS証明書などのセキュリティ関連事項も含まれます。

オペレーターがこれらの昇格された権限を必要とする理由の詳細については、 Security / Cluster / RBAC を参照してください。

ユーザーと権限#

EDB CloudNativePG クラスターオペレーターを使用する非常に一般的な方法は、 cluster-admin ロールに依存し、リソースを一元管理することです。

または、他のオペレーターまたはリソースと同様に、Kubernetes / OpenShiftで利用可能なRBACフレームワークを使用できます。

たとえば、他のクラウドネイティブアプリケーションと同様に、clusters.postgresql.k8s.enterprisedb.io-v1-admin クラスターロールを特定の名前空間の特定のグループまたはユーザーにバインドすることに関心がある場合があります。次の例は、そのクラスターロールをweb-prod プロジェクト内の特定のユーザーにバインドします。

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 でも同じプロセスを繰り返すことができます。

一方、クラスターロールを使用したくない場合は、この例のように特定の名前空間ロールを作成できます。

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

次に、このロールを特定のユーザーに割り当てます。

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 が* と等しいロールを作成します。

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のバージョンによって異なります。次の表と注意事項に細心の注意を払ってください。

EDB CloudNativePG Cluster Version	OpenShift Versions	Supported SCC
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

重要

バージョン4.10は`restricted` のみを提供しているため、EDB CloudNativePG クラスターバージョン1.18および1.19は`restricted` をサポートしています。 Openshift 4.11では`restricted` が`restricted-v2` に置き換えられたため、Kubernetes用EDB Postgresの将来のリリースは`restricted` をサポートする保証はありません。

オペレーターは、最初からセキュリティを重視して開発されたため、常にRed Hat認定プロセスを遵守することに加えて、KubernetesのEDB PostgresはOpenShift 4.11で導入された新しいSCCの下で動作します。

デフォルトでは、EDB CloudNativePGクラスターはすべての機能をドロップします。これにより、ライフサイクル中にオペレーターが安全でない機能を利用しないことが保証されます。

OpenShiftでは、OpenShift展開から各ポッドのSecurityContext.SeccompProfile を継承します。これは、Pod Security Admission Controllerによって設定されます。

注釈

nonroot-v2 および`hostnetwork-v2` が制限の少ないSCCとして認定されている場合でも、当社はそれらに対してテストを実行していないため、これらのSCCが動作することを保証できません。そうは言っても、 nonroot-v2 および`hostnetwork-v2` は`restricted-v2` のルールのサブセットであるため、これらが機能しないと信じる理由はありません。

プーラーイメージのカスタマイズ#

デフォルトでは、 Pooler リソースは、 quay.io/enterprisedb/pgbouncer イメージで実行されるpgbouncer コンテナを持つポッドを作成します。

高度なインターフェイスからイメージ名を変更できます。具体的には、 “Template” セクションを開き、 “Spec > Containers” の下で “Add Container” を選択します。

次に

コンテナの名前としてpgbouncer を設定しますポッドテンプレートの必須フィールド
必要に応じて “Image” フィールドを設定します以下の画像を参照してください。

VeleroのOADP#

EDB CloudNativePG クラスターオペレーターは、 Velero を管理するために Openshift API for Data Protection オペレーターの使用を推奨します

OpenShift環境。 EDB CloudNativePG クラスターがVeleroと統合する方法に関する具体的な詳細は、アドオンドキュメントの Velero section で見つけることができます。 OADP operator

は、EDBで直接サポートされていないコミュニティオペレーターです。 OADPオペレーターは、 EDB PostgresでVeleroを使用する必要はありませんが、OpenShiftにVeleroをインストールする便利な方法です。

モニタリングとメトリック#

OpenShiftには、KubernetesのEDB Postgresを含むユーザー定義プロジェクトに活用できる Prometheus インストールが含まれています。

GrafanaはOpenShiftに含まれなくなったため、Grafana統合はこのガイドの範囲外です。

このセクションでは、デフォルトのOpenShiftインストールを活用して、基本的なオブザーバビリティを開始する方法を示します。

OpenShift monitoring stack overview を参照してください。

さらなる背景については。

OpenShift構成によっては、EDB CloudNativePG Clusterクラスターをモニタする前に、少しのセットアップを行う必要がある場合があります。

OpenShiftを enable monitoring for user-defined projects に構成する必要があります。

おそらくOpenShift管理者に、インストールにcluster-monitoring-config configMapがあるかどうか、存在する場合はユーザーワークロードモニタリングが有効になっているかどうかを確認する必要があります。

このconfigMap の存在を確認できます。openshift-monitoring 名前空間にある必要があることに注意してください。

oc -n openshift-monitoring get configmap cluster-monitoring-config

ユーザーワークロードモニタリングを有効にするには、構成マップをoc apply またはoc edit 次のようにすることができます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true

enableUserWorkload を設定すると、複数の監視コンポーネントがopenshift-user-workload-monitoring 名前空間に作成されます。

$ 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 名前空間での監視を使用して次のクラスターを作成できます。

kubectl apply -n foo -f - <<EOF
- --
apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
  name: cluster-with-metrics
spec:
  instances: 3

  storage:
    size: 1Gi

  monitoring:
    enablePodMonitor: true
EOF

これで、この例でインストールされるデフォルトのメトリックを照会できるようになります。 OpenShiftのObserve セクション開発者パースペクティブに、PromQLクエリーを作成できるMetrics サブメニューが表示されます。オートコンプリートが有効になっているため、cnp_ 接頭辞をピークにできます。

PrometheusRules としてのデフォルトメトリックに基づいてアラートを定義するのは簡単です。以下にルールの例をいくつか示します。

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: postgresql-operator-default-alerts
spec:
  groups:
  - name: cnp-default.rules
    rules:
    - alert: LongRunningTransaction
      annotations:
        description: Pod {{ $labels.pod }} is taking more than 5 minutes (300 seconds) for a query.
        summary: A query is taking longer than 5 minutes.
      expr: |-
        cnp_backends_max_tx_duration_seconds > 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を作成することが含まれます。再度、 relevant OpenShift document page を参照してください

詳細については、特に、 Webコンソールを使用したユーザー権限の付与 セクションに関心があります。

monitoring-rules-edit のRoleBindingは名前空間に適用されるため、適切なものを取得していることを確認してください。

以前にダウンロードしたcnp-prometheusrule.yaml ファイルにアラートが含まれているとします。これらのルールは次のようにインストールできます。

oc apply -n foo -f cnp-prometheusrule.yaml

これで、アラートがある場合は表示されるはずです。最初はアラートが存在しない場合があることに注意してください。

アラートルーティングと通知は、このガイドの範囲を超えています。

Red Hat OpenShift

目次

Red Hat OpenShift#

アーキテクチャ#

PostgreSQLワークロードのノードの予約#

OpenShiftの重要な概念#

クラスターサービスバージョンCSV#

マルチテナント管理の制限#

チャンネル#

stable チャンネルについて#

Webコンソールを介したインストール#

EDBプライベートレジストリへのアクセスの保証#

クラスター全体のインストール#

単一プロジェクトのインストール#

oc CLIを介したインストール#

oc を使用したクラスター全体のインストール#

OpenShift CLI oc のインストール#

オペレーターのアップグレード#

事前定義されたRBACオブジェクト#

カスタムリソース定義CRD#

サービスアカウント#

クラスターロール#

EDB CloudNativePGクラスターCRDのクラスターロール#

Kubernetes CRDのクラスターロール#

ユーザーと権限#

ポッドセキュリティ標準#

プーラーイメージのカスタマイズ#

VeleroのOADP#

モニタリングとメトリック#

`stable` チャンネルについて#

`oc` CLIを介したインストール#

`oc` を使用したクラスター全体のインストール#

OpenShift CLI `oc` のインストール#