クラウドネイティブ PostgreSQL - CrunchyData PGO チュートリアル: Postgres クラスターの作成、接続、削除

はじめる

インストールの一環として、次の操作を実行したことを確認してください。

1. Postgres Operator サンプル リポジトリをフォークし、ホストにクローンします。
2. https://github.com/CrunchyData/postgres-operator-examples/fork
3. PGO を postgres-operator 名前空間にインストールします。 postgres-operator-examples ディレクトリにいる場合は、kubectl apply -k kustomize/install コマンドを実行できます。

詳細なインストール手順については、以下を参照してください: Cloud Native PostgreSQL - CrunchyData PGO: 5 分で始める

このチュートリアルでは、kustomize/postgres で提供されている例を基に構築していきます。

YAML マニフェスト内のネストされたオブジェクトを参照する場合は、 を使用します。 kubectl explain に似た形式。たとえば、この yaml ファイル内の最も深い要素を参照する場合は、次のようになります。

 仕様:
 カバ:
 食欲： 非常に大きい

spec.hippos.appetite と言います。

kubectl explain はあなたの味方です。 kubectl explain postgrescluster を使用して、postgrescluster.postgres-operator.crunchydata.com カスタム リソース定義をイントロスペクトできます。 CRD リファレンスもご覧ください。

CRDS

• https://access.crunchydata.com/documentation/postgres-operator/5.0.4/references/crd/

PGO (Postgres Operator) をインストールしたら、Postgres クラスターの作成を始めましょう。

Postgres クラスターの作成

Postgres クラスターの作成は非常に簡単です。 kustomize/postgres ディレクトリ内の例を使用する場合、次のコマンドを実行するだけです。

 kubectl apply -k kustomize / postgres

PGO は、postgres-operator 名前空間に hippo という名前の単純な Postgres クラスターを作成します。 postgresclusters.postgres-operator.crunchydata.com カスタム リソースで kubectl describe を使用して、Postgres クラスターのステータスを追跡できます。

 kubectl -n postgres - オペレーターはpostgresclusters を説明します。 postgres - 演算子。 クランチデータ。 com カバ

次のコマンドを使用して、Postgres Pod のステータスを追跡できます。

 - - セレクター= postgres - 演算子。 クランチデータ。 com / cluster = hippo 、 postgres - 演算子。 クランチデータ。 com / インスタンス

何が起こったのですか?

PGO は、kustomize/postgres ディレクトリにある Kustomize マニフェストで提供される情報に基づいて Postgres クラスターを作成します。 kustomize/postgres/postgres.yaml ファイルを調べて、何が起こっているのかをよりよく理解しましょう。

 apiVersion : postgres - 演算子。 クランチデータ。 com / v1beta1
 種類: PostgresCluster
 メタデータ:
 名前: カバ
仕様:
 イメージ: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:centos8-13.5-0
 postgresバージョン: 13
 インスタンス:
 - 名前: インスタンス1
 データボリュームクレーム仕様:
 アクセスモード:
 - 「一度だけ読み書き可能」
 リソース：
 リクエスト:
 ストレージ: 1 Gi
 バックアップ:
 pgバックレスト:
 イメージ: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.36-0
 リポジトリ:
 - 名前: repo1
 音量：
 ボリュームクレーム仕様:
 アクセスモード:
 - 「一度だけ読み書き可能」
 リソース：
 リクエスト:
 ストレージ: 1 Gi

先ほど kubectl apply コマンドを実行したとき、Kubernetes に PostgresCluster カスタム リソースが作成されました。 PGO は、新しい PostgresCluster リソースが追加されたことを検出し、Kubernetes で Postgres を実行するために必要なすべてのオブジェクトの作成を開始します。

他に何が起こりましたか? PGO は metadata.name から値を読み取り、Postgres クラスターに hippo という名前を付けました。さらに、PGO は、それぞれ spec.image と spec.backups.pgbackrest.image の値を調べることで、Postgres と pgBackRest にどのコンテナーを使用するかを認識します。 spec.postgresVersion の値は、使用している Postgres のメジャー バージョンを PGO が追跡するのに役立つため重要です。

PGO は、マニフェストの spec.instances セクションを通じて、作成する Postgres インスタンスの数を認識します。名前はオプションですが、instance1 という名前を付けることにしました。クラスターの初期化中に複数のレプリカとインスタンスを作成することもできますが、これについては、HA Postgres クラスターのスケーリングと作成方法について説明するときに詳しく説明します。

PostgresCluster カスタム リソースの非常に重要な部分は、dataVolumeClaimSpec セクションです。これは、Postgres インスタンスが使用するストレージについて説明します。これは、Persistent Volume Claims をモデルにしています。 spec.instances.dataVolumeClaimSpec.storageClassName を指定しない場合は、Kubernetes 環境のデフォルトのストレージ クラスが使用されます。

永続ボリュームクレーム

• https://kubernetes.io/docs/concepts/storage/persistent-volumes/

Postgres クラスターの作成の一環として、バックアップ アーカイブに関する情報も指定しました。 PGO は、テラバイト規模のバックアップを処理するように設計されたオープンソースのバックアップおよびリカバリ ツールである pgBackRest を使用します。クラスターの初期化の一環として、バックアップとアーカイブ (先行書き込みログまたは WAL) を保存する場所を指定できます。このチュートリアルの災害復旧セクションでは、PostgresCluster 仕様のこの部分についてさらに詳しく説明し、Amazon S3、Google GCS、Azure Blob ストレージにバックアップを保存する方法について説明します。

Postgres クラスタへの接続

Postgres クラスターを作成することは 1 つの方法です。それに接続するのは別のことです。 PGO が Postgres クラスターに接続する方法を見てみましょう。

舞台裏: サービス、シークレット、TLS

PGO は、Postgres データベースに接続するための安定したエンドポイントを提供するために、一連の Kubernetes サービスを作成しました。これらのエンドポイントを使用すると、アプリケーションにデータへの接続を一貫して維持する方法を簡単に提供できます。利用可能なサービスを確認するには、次のコマンドを実行します。

 kubectl -n postgres -operator get svc - - セレクター= postgres -operator 。 クランチデータ。 com / クラスター= カバ

次のような結果が生成されます。

 名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
hippo - ha ClusterIP 10.103 。 73.92 < なし> 5432 / TCP 3 時間 14 分
hippo - ha - config ClusterIP なし< なし> < なし> 3 時間 14 分
hippo - pods ClusterIP なし< なし> < なし> 3 時間 14 分
hippo - プライマリClusterIP なし< なし> 5432 / TCP 3 h14m
 hippo - レプリカClusterIP 10.98 。 110.215 < なし> 5432 / TCP 3 時間 14 分

これらのサービスのほとんどについては心配する必要はありません。Postgres クラスターの全体的な健全性を管理するために用意されているからです。データベースに接続するために、関心のあるサービスは hippo-primary と呼ばれます。 PGO のおかげで、その情報は Secret に記録されるため、この点について心配する必要もありません。

Postgres クラスターが初期化されると、PGO はアプリケーションがアクセスできるデータベースと Postgres ユーザーをブートストラップします。この情報は、-pguser- パターンで名前が付けられた Secrets に保存されます。私たちの hippo クラスターでは、この Secret は hippo-pguser-hippo と呼ばれます。このシークレットには、アプリケーションを Postgres データベースに接続するために必要な情報が含まれています。

• user: ユーザーアカウントの名前。
• パスワード: ユーザー アカウントのパスワード。
• dbname: ユーザーがデフォルトでアクセスできるデータベースの名前。
• ホスト: データベース ホストの名前。これは、メインの Postgres インスタンスのサービスを参照します。
• port: データベースがリッスンしているポート。
• uri: Postgres データベースにログインするためのすべての情報を提供する PostgreSQL 接続 URI。
• jdbc-uri: PostgreSQL JDBC 接続 URI。JDBC ドライバーを介して Postgres データベースにログインするためのすべての情報を提供します。

すべての接続は TLS 経由で行われます。 PGO は独自の証明機関 (CA) を提供し、アプリケーションを Postgres クラスターに安全に接続できるようにします。これにより、盗聴防止機能を提供し、MITM 攻撃を防ぐ Postgres の検証フル「SSL モード」を使用できるようになります。独自の CA を使用するオプションもあります。これについては、このチュートリアルの後半の「クラスターのカスタマイズ」セクションで説明します。

verify-full「SSL モード」

• https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS

サービスタイプの変更

デフォルトでは、PGO は ClusterIP サービス タイプでサービスをデプロイします。データベースを公開する方法に応じて、異なるサービス タイプを使用するようにサービスを変更する必要がある場合があります。

サービスタイプ

• https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

PGO によって管理されるサービスは、次のプロパティから変更できます。

• spec.service - Postgres マスター サーバーに接続するために使用されるサービスを管理します。
• spec.proxy.pgBouncer.service - PgBouncer 接続プールに接続するために使用されるサービスを管理します。

たとえば、NodePort サービスを使用するように Postgres マスター ノードを設定するには、マニフェストに次のコードを追加します。

 仕様:
 サービス：
 タイプ: NodePort

私たちの Hippo クラスターの場合は、次のようになります。例:

 kubectl -n postgres -operator get svc - - セレクター= postgres -operator 。 クランチデータ。 com / クラスター= カバ

次のようなものが生成されます。

 名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
hippo - ha NodePort 10.96 。 17.210 < なし> 5432 : 32751 / TCP 2 分37秒
hippo - ha - config ClusterIP なし< なし> < なし> 2 分 37 秒
hippo - pods ClusterIP なし< なし> < なし> 2 分 37 秒
hippo - プライマリClusterIP なし< なし> 5432 / TCP 2 分 37 秒
hippo - レプリカClusterIP 10.96 。 151.53 < なし> 5432 / TCP 2 分37 秒

(サービスを外部に公開し、TLS 検証に依存する場合は、PGO のカスタム TLS 機能を使用する必要があることに注意してください)。

アプリを接続

このチュートリアルでは、オープンソースの ID 管理アプリケーションである Keycloak に接続します。 Keycloak は Kubernetes にデプロイでき、Postgres データベースによってサポートされます。 Postgres Operator の例のリポジトリに Keycloak と PostgresCluster をデプロイする例が提供されていますが、次のリストでは、すでに実行中の hippo クラスターを使用してデプロイします。

キークローク

• https://www.keycloak.org/

KeycloakとPostgresClusterのデプロイ例

• https://github.com/CrunchyData/postgres-operator-examples/tree/main/kusTOMize/keycloak

公式リストは現地の状況に適さない可能性があります。参照: クラウドネイティブ PostgreSQL - CrunchyData PGO: 5 分で始める

 kubectl apply - - ファイル名= - << EOF
 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: キークローク
名前空間: postgres - 演算子
ラベル:
 アプリ。 Kubernetes 。 io / 名前: キークローク
仕様:
 セレクター:
 マッチラベル:
 アプリ。 Kubernetes 。 io / 名前: キークローク
テンプレート：
 メタデータ:
 ラベル:
 アプリ。 Kubernetes 。 io / 名前: キークローク
仕様:
 コンテナ:
 - 画像： 岸壁。 io / keycloak / keycloak : 最新
名前: キークローク
環境:
 - 名前: DB_VENDOR
 値: "postgres"
 - 名前: DB_ADDR
 valueFrom : { secretKeyRef : { 名前: hippo - pguser - hippo 、 キー: ホスト} }
 - 名前: DB_PORT
 valueFrom : { secretKeyRef : { 名前: hippo - pguser - hippo 、 キー: ポート} }
 - 名前: DB_DATABASE
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : dbname } }
 - 名前: DB_USER
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : user } }
 - 名前: DB_PASSWORD
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : password } }
 - 名前: KEYCLOAK_USER
 値: "admin"
 - 名前: KEYCLOAK_PASSWORD
 値: "admin"
 - 名前: PROXY_ADDRESS_FORWARDING
 値: "true"
 ポート:
 - 名前: http
 コンテナポート: 8080
 - 名前: https
 コンテナポート: 8443
 準備状況プローブ:
 httpGet : 取得:
 パス: / auth / realms / master
 ポート: 8080
 再起動ポリシー: 常に
終了

リストのこの部分に注意してください:

 - 名前: DB_ADDR
 valueFrom : { secretKeyRef : { 名前: hippo - pguser - hippo 、 キー: ホスト} }
 - 名前: DB_PORT
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : port } }
 - 名前: DB_DATABASE
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : dbname } }
 - 名前: DB_USER
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : user } }
 - 名前: DB_PASSWORD
 valueFrom : { secretKeyRef : { name : hippo - pguser - hippo 、 key : password } }

上記のリストは、これらすべての値が hippo-pguser-hippo Secret からどのように派生されるかを示しています。つまり、接続資格情報を知る必要はなく、安全に渡す必要もありません。資格情報はアプリケーションで直接利用できます。

このアプローチを使用すると、PGO が Postgres をどのようにデプロイするかを事前に知らなくても、アプリケーションを Postgres に接続された GitOps パイプラインに直接結び付けることができます。アプリケーションに必要なすべての情報が Secret に伝播されます。

Postgres クラスタの削除

場合によっては、クラスターを削除する必要があることがあります。公式の例に従っている場合は、次のコマンドを実行するだけで Postgres クラスターを削除できます。

 kubectl delete -k kustomize / postgres

PGO はクラスターに関連付けられているすべてのオブジェクトを削除します。

データ保持については、PVC の保持ポリシーによって異なります。 Kubernetes がデータ保持を管理する方法の詳細については、ボリューム再利用に関する Kubernetes ドキュメントを参照してください。

PVC保持ポリシー

• https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming