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

Kubernetesへのインストール

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

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

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

このマイナーリリースでは次のとおりです。

kubectl apply -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.20/releases/cnpg-1.20.2.yaml

次の方法でそれを確認できます。

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

kubectl にcnpg プラグインを使用する

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

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

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

より包括的な例については、 :ref:``kubectl` に`cnpg` プラグインを使用する<kubectl に`cnpg` プラグインを使用する>` ドキュメントを参照してください。

警告

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

そしてこれによって いくつかの一般的な問題 。 WebhookサービスのtargetPort を許可されたものに変更するか、ファイアウォールでWebhookのポート（9443 ）を開く必要があります。

最新の開発スナップショットのテスト

次の公式パッチリリースの前にCloudNativePGの最新の開発スナップショットをテストまたは評価したい場合は、

cloudnative-pg/artifacts からマニフェストをダウンロードできます

これにより、現在のトランク（メイン）とサポートされている各リリースに簡単にアクセスできます。

たとえば、次のコマンドでオペレーターの最新のスナップショットをインストールできます。

curl -sSfL \
  https://raw.githubusercontent.com/cloudnative-pg/artifacts/main/manifests/operator-manifest.yaml | \
  kubectl apply -f -

代わりに、この特定のマイナーリリースのオペレーターの最新のスナップショットを探している場合は、次を実行できます。

curl -sSfL \
  https://raw.githubusercontent.com/cloudnative-pg/artifacts/release-1.20/manifests/operator-manifest.yaml | \
  kubectl apply -f -

重要

スナップショットはCloudNativePGでサポートされておらず、本番環境での使用を対象としていません。

Helmチャートの使用

オペレーターは、提供された Helmチャートの使用 を使用してインストールできます。

展開の詳細

Kubernetesでは、オペレーターはデフォルトでcnpg-system 名前空間にKubernetes Deployment としてインストールされます。このデプロイメントの名前は、インストール方法によって異なります。マニフェストまたは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>

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

オペレーターレベルで高可用性が必要な場合、オペレーターがリーダー選択をサポートしていれば、デプロイメント構成で複数のレプリカを指定できます。また、テイントと耐性を利用して、実際のPostgreSQLクラスターが実行されているのと同じノードでオペレーターが実行されないようにすることができます（これには、自己管理のKubernetesインストールのコントロールプレーンが含まれる場合もあります）。

アップグレード

重要

リリースノート をよくお読みください

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

警告

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

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

1.コントローラーと関連するKubernetesリソースをアップグレードします

2.すべてのPostgreSQLポッドで実行されているインスタンスマネージャーをアップグレードします

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

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

重要

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

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

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

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

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

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

その結果、PostgreSQLプロセスは更新の影響を受けず、スイッチオーバーを実行する必要がなくなります。コインの反対側は、ポッドが開始後に変更され、不変性の純粋な概念を破ることです。

オペレーター設定 ENABLE_INSTANCE_MANAGER_INPLACE_UPDATES 環境変数を

'true' に設定することにより、この機能を有効にできます。

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

重要

この機能では、すべてのポッド（演算子とオペランド）が同じプラットフォーム/アーキテクチャ（たとえば、すべての`linux/amd64` ）で実行される必要があります。

バージョン間の互換性

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

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

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

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

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

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

以前のマイナーバージョンから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

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

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

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

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

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

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