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

Kubernetes へのインストール

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

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

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

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

kubectl apply -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.19/releases/cnpg-1.19.1.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 を許可されたサービスの 1 つに変更するか、ファイアウォールで Webhook のポート (9443 ) を開く必要があります。

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

次の公式パッチ リリースの前に CloudNativePG の最新の開発スナップショットをテストまたは評価する場合は、 cloudnative-pg/artifacts からマニフェストをダウンロードできます。

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

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

curl -sSfL \
  https://raw.githubusercontent.com/cloudnative-pg/artifacts/release-1.19/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 構成で複数のレプリカを指定できます。また、taints と tolerations を利用して、実際の PostgreSQL クラスターが実行されているノードと同じノードでオペレーターが実行されないようにすることもできます (これには、セルフマネージド Kubernetes インストールのコントロール プレーンが含まれる場合もあります)。

アップグレード

重要

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

バージョンによっては追加の手順が必要になる場合があるため、アップグレードを実行する前に確認してください。

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

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

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

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

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

重要

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

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

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

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

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

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

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

オペレーター構成 で ENABLE_INSTANCE_MANAGER_INPLACE_UPDATES 環境変数を

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

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

重要

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

バージョン間の互換性

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

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

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

重要

2022 年に、EDB は、頻繁なオンライン更新が不可能な環境で CloudNativePG の LTS リリースを計画しています。

CloudNativePG 1.19 のリリース ノート ページには、CloudNativePG のすべてのリリース

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

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

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