インストールとアップグレード

Kubernetesへのインストール

オペレーターマニフェストを直接使用する

オペレーターは、Kubernetesの他のリソースと同様に、kubectl を介して適用されるYAMLマニフェストを介してインストールできます。

latest operator manifest をインストールできます

このマイナーリリースでは次のようになります。

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.22/releases/cnpg-1.22.2.yaml

これは次の方法で確認できます。

kubectl get deployment -n cnpg-system cnpg-controller-manager

`kubectl` の`cnpg` プラグインを使用する

cnpg プラグインを使用して、静的マニフェストにあるデフォルトの構成オプションをオーバーライドできます。

たとえば、デフォルトの最新のマニフェストを生成しますが、ウォッチ名前空間を特定の名前空間のみに変更するには、次のコマンドを実行できます。

kubectl cnpg install generate \
  --watch-namespace "specific-namespace" \
  > cnpg_for_specific_namespace.yaml

より包括的な例については、 Backup {postgresql-cnpg-io-v1-Backup} ドキュメントを参照してください。

警告

GKEにCloudNativePGをデプロイしており、エラー`... failed to call webhook...` を取得した場合は、公式 docs で説明しているように、デフォルトでは、ワーカーノードとコントロールプレーン間のトラフィックは、いくつかの特定のポートを除きてファイアウォールによってブロックされていることに注意してください

そしてこれによって issue 。 WebhookサービスのtargetPort を許可されるもののいずれかに変更するか、ファイアウォールでWebhookのポート9443 を開く必要があります。

Helmチャートを使用する

オペレーターは、提供されている Helm chart を使用してインストールできます。

OLMを使用する

CloudNativePGは、 Operator Lifecycle Manager (OLM) を使用してインストールすることもできます

OperatorHub.io から直接。

デプロイメントの詳細

Kubernetesでは、オペレーターはデフォルトでKubernetes Deployment としてcnpg-system 名前空間にインストールされます。この展開の名前は、インストール方法によって異なります。マニフェストまたはcnpg プラグインを介してインストールされる場合、デフォルトでcnpg-controller-manager と呼ばれます。 Helmを介してインストールされた場合、デフォルト名はcnpg-cloudnative-pg です。

注釈

Helmを使用すると、 *"values.yaml"* file の`fullnameOverride` フィールドを介してデプロイメントの名前をカスタマイズできます。

kubectl のdescribe コマンドを使用して、詳細情報を取得できます。

$ kubectl get deployments -n cnpg-system
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
<deployment-name>   1/1     1            1           18m

kubectl describe deploy \
  -n cnpg-system \
  <deployment-name>

他の展開と同様に、レプリカセットの上にあり、ローリングアップグレードをサポートします。 CloudNativePGオペレーターのデフォルト構成には、単一のレプリカの展開が付属しており、ほとんどのインストールに適しています。ポッドが実行されているノードに到達できなくなった場合、ポッドは別のノードで再スケジュールされます。

オペレーターレベルでの高可用性が必要な場合、オペレーターがリーダー選択をサポートしていることを考慮すると、展開構成で複数のレプリカを指定できます。また、テイントと寛容を利用して、実際のPostgreSQLクラスターが実行されているノードでオペレーターが実行されないことを確認できます。これには、自己管理のKubernetesインストールのコントロールプレーンが含まれる場合があります。

参考

いくつかのデフォルトオプションをオーバーライドすることにより、オペレーターのデフォルト動作を変更できます。詳細については、オペレーター設定セクションを参照してください。

アップグレード

重要

1.14.0以前のリリースノートをよくお読みください

一部のバージョンは追加の手順を必要とする場合があるため、アップグレードを実行する前に。

警告

バージョン1.20にアップグレードする場合は、 dedicated section below を注意深くお読みください。

CloudNativePGオペレーターのアップグレードは、2段階のプロセスです。

コントローラと関連するKubernetesリソースをアップグレードする
すべてのPostgreSQLポッドで実行されているインスタンスマネージャーをアップグレードする

リリースノートに別の記載がない限り、最初のステップは、通常、プレーンなKubernetesインストールの新しいバージョンのマニフェストを適用するか、使用するディストリビューションのネイティブパッケージマネージャーを使用して実行されます上記のセクションの指示に従ってください。

2番目のステップは、コントローラを更新した後に自動的に実行され、デフォルトでは、新しいインスタンスマネージャーを使用するように展開されたすべてのPostgreSQLインスタンスのローリング更新をトリガーします。ローリング更新手順は、スイッチオーバーで最高潮に達します。これは、 primaryUpdateStrategy オプションで制御されます。デフォルトではunsupervised に設定されます。 supervised に設定している場合、ユーザーはkubectl のcnpg プラグインを介して新しいインスタンスを手動で昇格させて、ローリング更新を完了する必要があります。

参考

このプロセスは、ローリングアップデートページで詳細に説明されています。

重要

primaryUpdateStrategy が`unsupervised` のデフォルト値に設定されている場合、オペレーターのアップグレードはPostgreSQLクラスターでスイッチオーバーをトリガーし、通常は無視できるダウンタイムを発生します。

バージョン1.10.0以降、ローリング更新動作をインスタンスマネージャーのインプレース更新に置き換えることができます。後者は、PostgreSQLインスタンスの再起動、その結果、クラスター内のスイッチオーバーを必要としません。デフォルトで無効になっているこの動作について以下に説明します。

インスタンスマネージャーのインプレース更新

デフォルトでは、CloudNativePGは、オペレーターが更新されるたびに、クラスターのローリング更新を発行します。オペレーターに同梱される新しいインスタンスマネージャーは、initコンテナを介して各PostgreSQLポッドに追加されます。

ただし、この動作は構成を介して変更でき、インスタンスマネージャーのインプレース更新を有効にできます。これは、コンテナを生きたままにするPID 1プロセスです。

内部的には、CloudNativePGのバージョン1.10からのインスタンスマネージャーは、完全性検証フェーズが完了すると、既存の実行可能ファイルを置き換える新しい実行可能ファイルのインジェクションと、すべての内部プロセスの正常な終了をサポートしています。新しいインスタンスマネージャーが新しいバイナリを使用して再起動すると、既に実行されている postmaster が採用されます。

その結果、PostgreSQLプロセスは更新の影響を受けず、スイッチオーバーを実行する必要はありません。コインの反対側は、Podがスタート後に変更され、不変性の純粋な概念を壊すということです。

オペレーター設定でENABLE_INSTANCE_MANAGER_INPLACE_UPDATES 環境変数を'true' に設定することにより、この機能を有効にできます。

インプレースアップグレードプロセスでは、ポッド内のinitコンテナイメージは変更されません。したがって、ポッド定義はオペレーターの現在のバージョンを反映しません。

バージョン間の互換性

CloudNativePGはセマンティックバージョニングに従います。同じAPIバージョン内のオペレーターのすべてのリリースは、以前のAPIバージョンと互換性があります。現在のAPIバージョンはv1で、オペレーターのバージョン1.x.yに対応します。

新機能に加えて、オペレーターの新しいバージョンにはバグ修正と安定性の強化が含まれています。このため、各バージョンは、最も安全で安定したPostgres環境を維持するためにリリースされるため、**オペレーターの最新バージョンにアップグレードすることを強くお勧めします。

CloudNativePGは現在、少なくとも毎月オペレーターの新しいバージョンをリリースしています。各バージョンが利用可能になったときに更新を適用できない場合は、バージョンをスキップせずに、各バージョンを順番にアップグレードして、定期的に最新の状態になることをお勧めします。

1.14.0以前のリリースノートページには、CloudNativePGのすべてのリリースバージョンで導入された変更の詳細なリストが含まれており、ソフトウェアの新しいバージョンにアップグレードする前に読む必要があります。

ほとんどのバージョンは直接アップグレード可能であり、その場合、プレーンなKubernetesインストールに新しいマニフェストを適用するか、選択したディストリビューションのネイティブパッケージマネージャーを使用するだけで十分です。

バージョンを直接アップグレードできない場合、新しいバージョンをインストールする前に古いバージョンを削除する必要があります。これはユーザーデータに影響を与えるのではなく、オペレーター自分自身にのみ影響を与えます。

<!– ### 1.23.0、1.22.2または1.21.4へのアップグレード

重要

CloudNativePGの既存のすべてのユーザーは、バージョン1.23.0、または少なくとも現在使用しているマイナーリリースの最新の安定バージョン1.22.2または1.21.4にアップグレードすることをお勧めします。

警告

上位のマイナーリリースにアップグレードするたびに、すべての中間マイナーリリースのリリースノートとアップグレード手順を確認してください。たとえば、1.21.xから1.23に移行する場合は、1.22および1.23のリリースノートとアップグレード手順を必ず読んでください。

ユーザー定義のレプリケーションスロット

CloudNativePGは、プライマリで定義されたすべてのレプリケーションスロットの自動同期を提供するようになりました。高可用性HAクラスター内のスタンバイ。

スタンバイでレプリケーションスロットを手動で管理する場合、これらのレプリケーションスロットを同期から除外することが重要です。これを行わないと、CloudNativePGがスタンバイから削除する場合があります。この除外を実装するには、次のYAML構成を利用します。この例では、 ’foo’で始まる名前のレプリケーションスロットは同期されません。

...
  replicationSlots:
    synchronizeReplicas:
      enabled: true
      excludePatterns:
      - "^foo"

または、同期メカニズムを完全に無効にする場合は、次の構成を使用します。

...
  replicationSlots:
    synchronizeReplicas:
      enabled: false

サーバーサイドでのマニフェストの適用

Kubernetes 1.29以降のバージョンとの互換性を保証するために、CloudNativePGは Server-side apply の使用を義務付けました

オペレーターマニフェストを展開するとき。

このインストール方法を採用することは、新しい展開に問題はありませんが、 --server-side オプションを使用して既存のオペレーターマニフェストを更新すると、以下の例のようなエラーが発生する場合があります。

Apply failed with 1 conflict: conflict with "kubectl-client-side-apply" using..

このようなエラーが発生した場合は、 --force-conflicts オプションを明示的に指定して競合解決を強制することにより解決できます。

kubectl apply --server-side --force-conflicts -f <OPERATOR_MANIFEST>

今後、 kube-apiserver はCRDの認識されたマネージャーとして自動的に認識され、この問題に関するさらなる手動介入の必要性がなくなります。

->

以前のマイナーバージョンから1.22へのアップグレード

CloudNativePGは、デフォルトでのセキュリティのアプローチを遵守し続けます。バージョン1.22以降、 ALTER SYSTEM コマンドの使用はデフォルトで無効になりました。

この選択の背後にある理由は、デフォルトで、CloudNativePGによって制御されるデータベースクラスターのPostgreSQL構成の変更が、Kubernetes APIを介してのみ許可されるようにするためです。

同時に、バージョン1.22.0、1.21.2、および1.20.5から一時的にでも使用する必要がある場合に、次の抜粋のように.spec.postgresql.enableAlterSystem をtrue に設定することにより、ALTER SYSTEM を有効にするオプションを提供しています。

...
  postgresql:
    enableAlterSystem: true
...

22のクラスターでは、デフォルトでenableAlterSystem がfalse に設定されます。 1.22で既存の動作を保持したい場合は、上記のようにenableAlterSystem をtrue に明示的に設定する必要があります。

バージョン1.21.2および1.20.5、および1.20および1.21ブランチの以降のパッチリリースでは、既存の動作を維持しながら、enableAlterSystem はデフォルトでtrue に設定されます。 ALTER SYSTEM を使用する必要がない場合は、 enableAlterSystem を明示的にfalse に設定することをお勧めします。

重要

上記の例に示すように、バージョン1.22.0、1.21.2、または1.20.5へのアップグレードの直後に`enableAlterSystem` の目的の値を設定できます。

以前のマイナーバージョンから1.21へのアップグレード

オペレーターの 構成よりコンベンション 動作をすぐに改善し続けることを目的に、CloudNativePGは次の領域でいくつかのノブのデフォルト値を変更します。

PostgreSQLインスタンスの起動およびシャットダウン制御
自己修復
セキュリティ
ラベル

警告

以下の変更のリスト、および既存のワークロードを中断したくない場合は、既存の動作を保持するように`Cluster` マニフェストを変更する方法をよく読んでください。または、確認するまでアップグレードを延期します。一般に、正当な理由がない限り、これらのデフォルト値を採用することをお勧めします。

スーパーユーザーアクセスは無効になっています

デフォルトのセキュリティ に向けて、CloudNativePGは、明示的に有効になっていない限り、すべての新しいクラスターのネットワークを介したpostgres スーパーユーザーアクセスを無効にします。

実行しているCloudNativePGのバージョンに関係なく、PostgreSQLクラスターへのスーパーユーザーアクセスを保証したい場合は、次の設定で明示的に宣言することをお勧めします。

spec:
   ...
   enableSuperuserAccess: true

HAのレプリケーションスロット

高可用性のレプリケーションスロットはデフォルトで有効になっています。

実行しているCloudNativePGのバージョンに関係なく、レプリケーションスロットを無効にしたい場合は、次の設定で明示的に宣言することをお勧めします。

spec:
   ...
   replicationSlots:
     highAvailability:
       enabled: false

PostgreSQLのシャットダウンの遅延

20.2、 the `stopDelay parameter <Postgresインスタンスマネージャー>` まで

30秒に設定されました。この値を変更して調整するという推奨事項にもかかわらず、サポートインシデントまたはコミュニティの問題中に調べたほぼすべてのケースは、この値が変更されないままであることを示しています。

new default value is 1800 seconds 、30分に相当。

新しいsmartShutdownTimeout パラメーターは、 PostgreSQLのsmart シャットダウンプロシージャを完了するために予約されているstopDelay 値内の最大時間ウィンドウを定義するために導入されました。この間、Postgresサーバーは、すべての通常のセッションが終了するのを待機している間、新しい接続を拒否します。

経過すると、 stopDelay までの残り時間はPostgreSQLがアーカイブとストリーミングレプリカの両方とのWALコミットメントに関する義務を完了し、クラスターがデータを失わないようにするために予約されます。

古い動作を保持したい場合は、明示的に設定する必要があります。

spec:
   ...
   stopDelay: 30

そして、 アップグレードが完了した後 、 smartShutdownTimeout を指定します。

spec:
   ...
   stopDelay: 30
   smartShutdownTimeout: 15

PostgreSQLの起動の遅延

20.2、 the `startDelay parameter <Postgresインスタンスマネージャー>` まで

は30秒に設定され、CloudNativePGはこのパラメーターをKubernetes livenessプローブのinitialDelaySeconds として使用しました。サポートされているすべてのKubernetesリリースが startup probes を提供していることを考慮すると、 startDelay は、それぞれ10秒の期間に自動的に分割されます。

重要

startupProbe を追加するには、各ポッドを再起動する必要があります。その結果、オペレーターをアップグレードすると、オンライン更新の場合でも、クラスターのワンタイムローリング更新が実行されます。

この値を変更して調整するという推奨事項にもかかわらず、サポートインシデントまたはコミュニティの問題中に調べたほぼすべてのケースは、この値が変更されないままであることを示しています。このパラメーターがPostgreSQLインスタンスの起動に影響を与えることを考えると、startDelay の値が低いと、Postgresが一貫した復旧状態に到達せず、無期限に再起動されます。

このため、 startDelay は1時間に相当する raised by default to 3600 seconds になりました。

新しい実装を使用して既存の動作を保持したい場合は、次のことを明示的に設定することによりそれを行うことができます。

spec:
   ...
   startDelay: 30

PostgreSQLスイッチオーバーの遅延

20.2、 the `switchoverDelay parameter <Postgresインスタンスマネージャー>` まで

非常に長い間隔をシミュレートするために、デフォルトで40000000秒15か月以上に設定されました。

default value has been lowered to 3600 seconds 、1時間に相当します。

古い動作を保持したい場合は、明示的に設定する必要があります。

spec:
   ...
   switchoverDelay: 40000000

ラベル

バージョン1.18では、クラスターの名前を識別するためにポッドのpostgresql ラベルを非推奨にし、より正規なcnpg.io/cluster ラベルに置き換えました。 postgresql ラベルは維持されなくなりました。

同様に、このバージョンから、role ラベルは非推奨です。新しいラベル cnpg.io/instanceRole が使用されるようになり、将来のリリースではrole ラベルを完全に置き換えます。

既存の動作を維持するためのショートカット

CloudNativePGの動作を明示的にバージョン1.20.2までに保ちたい場合は、新しいバージョンにアップグレードする前に**、すべてのCluster 定義でこれらの値を設定する必要があります。

spec:
   ...
   # Changed in 1.21.0, 1.20.3 and 1.19.5
   startDelay: 30
   stopDelay: 30
   switchoverDelay: 40000000
   # Changed in 1.21.0 only
   enableSuperuserAccess: true
   replicationSlots:
     highAvailability:
       enabled: false

アップグレードが完了したら、以下も追加します。

spec:
   ...
   smartShutdownTimeout: 15

以前のマイナーバージョンから1.20へのアップグレード

CloudNativePG 1.20では、構成より規約を通じて、すぐにPostgresクラスターの復元力と使いやすさを向上させることを目的に、いくつかの機能のデフォルト動作にオペレーターの以前のバージョンからの変更を導入します。

重要

これらの変更はすべて、少なくとも1つのレプリカが存在する場合が関係し、新しい`Cluster` リソースにのみ影響します。

スタンバイからのバックアップ

スタンバイからのバックアップ

CloudNativePG 1.19で導入されましたが、デフォルトでは無効になっています。つまり、ターゲットがスタンバイを優先するように明示的に設定されていない限り、ベースバックアップはプライマリから取得されます。

バージョン1.20から、1つ以上のレプリカが利用可能な場合、オペレーターは最も調整されたスタンバイを優先して完全なベースバックアップを取得します。

CloudNativePG展開を1.20にアップグレードしており、この機能が、作成する新しいCluster リソースの実稼働環境に影響を与える可能性が懸念される場合は、すべてのCluster リソースに次の行を追加することにより、ターゲットを明示的にプライマリに設定できます。

spec:
   ...
   backup:
     target: "primary"

ローリング更新後のプライマリの再起動

Automated rolling updates

CloudNativePGでは常に利用でき、デフォルトでは、最も調整されたレプリカへのスイッチオーバーを実行した後にプライマリを更新します。

バージョン1.20から、プライマリのデフォルトの更新方法をスイッチオーバーから再起動に変更します。ほとんどの場合、これが最も速くて安全な方法です。

CloudNativePG展開を1.20にアップグレードしており、この機能が、作成する新しいCluster リソースの実稼働環境に影響を与える可能性が懸念される場合は、すべてのCluster ファイルに次の行を追加することにより、プライマリの更新方法をスイッチオーバーに明示的に設定できますリソース

spec:
   ...
   primaryUpdateMethod: switchover

高可用性のためのレプリケーションスロット

高可用性のためのレプリケーションスロット

バージョン1.18のCloudNativePGに導入されましたが、デフォルトでは無効になっています。

バージョン1.20は、レプリケーションスロットが高可用性クラスターの復元力と堅牢性を強化するため、将来のリリースでこの機能をデフォルトで有効にするための基礎を準備します。

将来の互換性のために、環境がレプリケーションスロットを必要としないことがすでにわかっている場合は、Cluster リソースに次の行を追加して、管理を明示的に無効にすることをお勧めします。

spec:
   ...
   replicationSlots:
     highAvailability:
       enabled: false