Installation and upgrades¶
Kubernetesでのインストール¶
演算子マニフェストを直接使用する¶
演算子は、 kubectl
を介して適用されるYAMLマニフェストを介して、Kubernetesの他のリソースと同様にインストールできます。
latest operator manifest は次のようにインストールできます。
kubectl apply -f \
https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-1.15.0.yaml
kubectl
コマンドを実行すると、CloudNativePGがKubernetesクラスターにインストールされます。
次の方法で確認できます。
kubectl get deploy -n cnpg-system cnpg-controller-manager
ヘルムチャートの使用¶
演算子は、提供されている ヘルムチャートの使用 を使用してインストールできます。
展開に関する詳細¶
Kubernetesでは、演算子はデフォルトで cnpg-controller-manager
というKubernetes Deployment として cnpg-system
名前空間にインストールされます。以下を実行することにより、詳細情報を取得できます。
kubectl describe deploy \
-n cnpg-system \
cnpg-controller-manager
他の展開と同様に、これはReplicaSetの上にあり、ローリングアップグレードをサポートします。 CloudNativePGオペレーターのデフォルト構成には、ほとんどのインストールに適した単一レプリカのデプロイメントが含まれます。ポッドが実行されているノードにもう到達できない場合、ポッドは別のノードで再スケジュールされます。
演算子レベルで高可用性が必要な場合は、オペレーターがリーダー選出をサポートしているため、展開構成でマルチプルのレプリカを指定することができます。また、汚染と許容をmakeして、実際のP PostgreSQLクラスターが実行されているのと同じノードで演算子が実行されないようにすることができます（これには、自己管理Kubernetesインストールのコントロールプレーンが含まれる場合もあります）。
アップグレード¶
重要
一部のバージョンでは追加の手順が必要になる場合があるため、アップグレードを実行する前に Release notes を注意深くお読みください。
CloudNativePG演算子のアップグレードは2段階のプロセスです。
1.コントローラと関連するKubernetesリソースをアップグレードします2。すべてのPostgreSQLポッドで実行されているインスタンスマネージャをアップグレードする
リリースノートで特に明記されていない限り、最初のステップは通常、プレーンなKubernetesインストールに新しいバージョンのマニフェストを適用するか、使用されているディストリビューションのネイティブパッケージマネージャを使用して行われます（上記のセクションの指示に従ってください）。
2番目のステップは、コントローラを更新した後に自動的に実行されます。デフォルトでは、デプロイされたすべてのPostgreSQLインスタンスのローリング更新をトリガーして、新しいインスタンスマネージャを使用します。ローリング更新プロシージャは、スイッチオーバーで終了します。スイッチオーバーは、デフォルトで
unsupervised に設定された primaryUpdateStrategy
オプションによって制御されます。 supervised
に設定されている場合、ユーザーは kubectl の cnpg
pluginを使用して新しいインスタンスを手動でプロモートすることにより、ローリング更新を完了する必要があります。
重要
primaryUpdateStrategy がデフォルト値 unsupervised に設定されている場合、演算子のアップグレードによりPostgreSQLクラスターでスイッチオーバーがトリガーされ、（通常は無視できる）ダウンタイムが発生します。
バージョン1.10.0以降、ローリング更新の動作は、インスタンスマネージャのインプレース更新に置き換えることができます。後者は、PostgreSQLインスタンスのリスタートを必要とせず、その結果、クラスターでのスイッチオーバーが必要です。この動作は、デフォルトでは無効になっていますが、以下で説明します。
インスタンスマネージャのインプレース更新¶
デフォルトでは、CloudNativePGは、演算子が更新されるたびにクラスターのローリング更新を発行します。オペレーターとともに出荷される新しいインスタンスマネージャは、initコンテナーを介して各PostgreSQLポッドに追加されます。
ただし、この動作は、インスタンスマネージャーのインプレース更新を有効にするように構成によって変更できます。インスタンスマネージャは、コンテナーを存続させるPID 1プロセスです。
内部的には、 インジェクションのバージョン1.10のインスタンスマネージャは、整合性検証フェーズが完了すると、既存の実行可能ファイルを置き換える新しい実行可能ファイルの挿入と、すべての内部プロセスの正常な終了をサポートします。新しいインスタンスマネージャーが新しいバイナリを使用して再起動すると、既に実行されている* postmaster *が採用されます。
その結果、 PostgreSQLプロセスは更新による影響を受けず、スイッチオーバーを実行する必要がありません。コインのもう一方の側面は、ポッドがスタート後に変更され、不変性の純粋な概念を破ることです。
この機能を有効にするには、 Operator configuration で
ENABLE_INSTANCE_MANAGER_INPLACE_UPDATES environment変数を 'true'
に設定します。
インプレースアップグレードプロセスでは、thePods内のinitコンテナーイメージは変更されません。したがって、ポッドの定義は、オペレーターの現在のバージョンを反映しません。
重要
この機能を使用するには、すべてのポッド（演算子とオペランド）が同じプラットフォーム/ architecture（例、すべて linux/amd64 ）で実行されている必要があります。
バージョン間の互換性¶
CloudNativePGはセマンティックバージョニングに従います。同じAPIバージョン内のオペレーターのすべてのリリースは、以前のバージョンと互換性があります。現在のAPIバージョンはv1で、演算子のバージョン1.xyに対応しています。
新しい機能に加えて、演算子の新しいバージョンにはバグ修正と安定性の強化が含まれています。このため、 最も安全で安定（stable）Postgres環境を維持するオーダーに各バージョンがリリースされるため、 演算子の最新バージョンにアップグレードすることを強くお勧めします。
CloudNativePGは現在、毎月少なくとも演算子の新しいバージョンをリリースしています。各バージョンが使用可能になったときに更新を適用できない場合は、バージョンをバージョンにアップグレード処理することをお勧めします。
重要
2022年、 EDBは、頻繁なオンライン更新が不可能な環境でCloudNativePGのLTSリリースを計画しています。
Release notes ページには、CloudNativePGのすべてのリリースバージョンで導入された変更の詳細なリストが含まれており、ソフトウェアの新しいバージョンにアップグレード処理する前に読む必要があります。
ほとんどのバージョンは直接アップグレード可能であり、その場合、単純なKubernetesインストールにnewermanifestを適用するか、選択したディストリビューションのネイティブパッケージマネージャーを使用するだけで十分です。
バージョンを直接アップグレードできない場合は、新しいバージョンをインストールする前に古いバージョンを削除するニーズがあります。これはユーザデータには影響しませんが、演算子自分自身にのみ影響します。
