インストールとアップグレード¶
Kubernetesへのインストール¶
オペレーターマニフェストを直接使用する¶
オペレーターは、 kubectl
を介して適用されるYAMLマニフェストを介して、Kubernetesの他のリソースと同様にインストールできます。
latest operator manifest は次のようにインストールできます。
kubectl apply -f \
https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-1.16.0.yaml
kubectl
コマンドを実行すると、CloudNativePGがKubernetesクラスターにインストールされます。
次の方法で確認できます。
kubectl get deploy -n cnpg-system cnpg-controller-manager
Helmチャートの使用¶
オペレーターは、提供された Helmチャートの使用 を使用してインストールできます。
展開に関する詳細¶
Kubernetesでは、オペレーターはデフォルトでcnpg-controller-manager
と呼ばれるKubernetes Deployment としてcnpg-system
名前空間にインストールされます。次を実行して、詳細を取得できます。
kubectl describe deploy \
-n cnpg-system \
cnpg-controller-manager
他のDeploymentと同様に、ReplicaSetの上にあり、ローリングアップグレードをサポートしています。 CloudNativePGオペレーターのデフォルト構成には、ほとんどのインストールに適した単一のレプリカのDeploymentが付属しています。ポッドが実行されているノードに到達できなくなった場合、ポッドは別のノードで再スケジュールされます。
オペレーターレベルで高可用性が必要な場合、オペレーターがリーダー選択をサポートしていれば、デプロイメント構成で複数のレプリカを指定できます。また、テイントと容認を利用して、実際のPostgreSQLクラスターが実行されているのと同じノードでオペレーターが実行されないようにすることができます（これには、自己管理のKubernetesインストールのコントロールプレーンが含まれる場合もあります）。
アップグレード¶
重要
バージョンによっては追加の手順が必要になる場合があるため、アップグレードを実行する前に リリースノート を注意深くお読みください。
CloudNativePG オペレーターのアップグレードは、次の 2 ステップのプロセスです。
1.コントローラーと関連するKubernetesリソースをアップグレードする
2.すべてのPostgreSQL Podで実行されているインスタンスマネージャーをアップグレードします
リリースノートに特に記載されていない限り、最初のステップは通常、プレーンな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' に設定すると、この機能を有効にできます。
インプレース アップグレード プロセスでは、ポッド内の init コンテナ イメージは変更されません。したがって、Pod定義はオペレーターの現在のバージョンを反映しません。
重要
この機能では、すべてのポッド（演算子とオペランド）が同じプラットフォーム/アーキテクチャ（たとえば、すべての`linux/amd64` ）で実行される必要があります。
バージョン間の互換性¶
CloudNativePGはセマンティックバージョニングに従います。同じ API バージョン内のオペレーターのすべてのリリースは、以前のリリースと互換性があります。現在のAPIバージョンはv1で、バージョン1.x.yに対応しています。
新機能に加えて、オペレーターの新しいバージョンにはバグ修正と安定性の強化が含まれています。このため、最も安全で安定したPostgres環境を維持するために各バージョンがリリースされるため、 ユーザーにはオペレーターの最新バージョンにアップグレードすることを強くお勧めします 。
CloudNativePGは現在、少なくとも月次でオペレーターの新しいバージョンをリリースしています。各バージョンが利用可能になったときに更新を適用できない場合は、バージョンをスキップせずに、各バージョンを順番にアップグレードして、定期的に最新の状態にすることをお勧めします。
重要
2022年、EDBは頻繁なオンライン更新ができない環境でのCloudNativePGのLTSリリースを計画しています。
リリースノート ページには、CloudNativePGのすべてのリリースバージョンで導入された変更の詳細なリストが含まれています。ソフトウェアの新しいバージョンにアップグレードする前に読む必要があります。
ほとんどのバージョンは直接アップグレード可能であり、その場合、プレーンなKubernetesインストールに新しいマニフェストを適用するか、選択したディストリビューションのネイティブパッケージマネージャーを使用するだけで十分です。
バージョンが直接アップグレードできない場合、新しいバージョンをインストールする前に古いバージョンを削除する必要があります。これはユーザーデータには影響しませんが、オペレーター自分自身にのみ影響します。
