Installation and upgrades ========================= .. raw:: html Kubernetesへのインストール -------------------------- オペレーターマニフェストを直接使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ オペレーターは、Kubernetesの他のリソースと同様に、\ ``kubectl`` を介して適用されるYAMLマニフェストを介してインストールできます。 `latest operator manifest `_ をインストールできます このマイナーリリースでは次のようになります。 .. code:: sh kubectl apply --server-side -f \ https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.0.yaml これは次の方法で確認できます。 .. code:: sh kubectl rollout status deployment \ -n cnpg-system cnpg-controller-manager ``kubectl`` の\ ``cnpg`` プラグインを使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``cnpg`` プラグインを使用して、静的マニフェストにあるデフォルトの構成オプションをオーバーライドできます。 たとえば、デフォルトの最新のマニフェストを生成しますが、ウォッチ名前空間を特定の名前空間のみに変更するには、次のコマンドを実行できます。 .. code:: shell kubectl cnpg install generate \ --watch-namespace "specific-namespace" \ > cnpg_for_specific_namespace.yaml より包括的な例については、 :ref:`postgresql.cnpg.io/v1 ` ドキュメントを参照してください。 .. Warning:: GKEにCloudNativePGをデプロイしており、エラー`... failed to call webhook...` を取得した場合は、公式 `docs `_ で説明しているように、デフォルトでは、ワーカーノードとコントロールプレーン間のトラフィックは、いくつかの特定のポートを除きてファイアウォールによってブロックされていることに注意してください そしてこれによって `issue `_ 。 Webhookサービスの\ ``targetPort`` を許可されるもののいずれかに変更するか、ファイアウォールでWebhookのポート\ ``9443`` を開く必要があります。 　 最新の開発スナップショットのテスト ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 次の公式パッチリリースの前にCloudNativePGの最新の開発スナップショットをテストまたは評価する場合は、 `cloudnative-pg/artifacts `_ からマニフェストをダウンロードできます。 これにより、現在のトランクメインおよびサポートされている各リリースに簡単にアクセスできます。 たとえば、次の使用でオペレーターの最新のスナップショットをインストールできます。 .. code:: sh curl -sSfL \ https://raw.githubusercontent.com/cloudnative-pg/artifacts/main/manifests/operator-manifest.yaml | \ kubectl apply --server-side -f - 代わりに、この特定のマイナーリリースのオペレーターの最新のスナップショットを探している場合は、次を実行できます。 .. code:: sh curl -sSfL \ https://raw.githubusercontent.com/cloudnative-pg/artifacts/release-1.28/manifests/operator-manifest.yaml | \ kubectl apply --server-side -f - .. Note:: スナップショットはCloudNativePGコミュニティでサポートされておらず、運用環境での使用を想定していません。 　 Helmチャートを使用する ^^^^^^^^^^^^^^^^^^^^^^ オペレーターは、提供されている `Helm chart `_ を使用してインストールできます。 OLMを使用する ^^^^^^^^^^^^^ CloudNativePGは、 `Operator Lifecycle Manager (OLM) `_ からインストールすることもできます `OperatorHub.io `_ から直接。 Red Hat OpenShiftでの展開の場合、EDBは、 `Red Hat OpenShift Container Platform `_ から入手可能なCloudNativePGの認定バージョンを提供および完全にサポートしています。 デプロイメントの詳細 -------------------- Kubernetesでは、オペレーターはデフォルトでKubernetes ``Deployment`` として\ ``cnpg-system`` 名前空間にインストールされます。この展開の名前は、インストール方法によって異なります。マニフェストまたは\ ``cnpg`` プラグインを介してインストールされる場合、デフォルトで\ ``cnpg-controller-manager`` と呼ばれます。 Helmを介してインストールされた場合、デフォルト名は\ ``cnpg-cloudnative-pg`` です。 .. Note:: Helmを使用すると、 `*"values.yaml"* file `_ の`fullnameOverride` フィールドを介してデプロイメントの名前をカスタマイズできます。 　 ``kubectl`` の\ ``describe`` コマンドを使用して、詳細情報を取得できます。 .. code:: sh $ kubectl get deployments -n cnpg-system NAME READY UP-TO-DATE AVAILABLE AGE 1/1 1 1 18m .. code:: sh kubectl describe deploy \ -n cnpg-system \ 他の展開と同様に、レプリカセットの上にあり、ローリングアップグレードをサポートします。 CloudNativePGオペレーターのデフォルト構成には、単一のレプリカの展開が付属しており、ほとんどのインストールに適しています。ポッドが実行されているノードに到達できなくなった場合、ポッドは別のノードで再スケジュールされます。 オペレーターレベルでの高可用性が必要な場合、オペレーターがリーダー選択をサポートしていることを考慮すると、展開構成で複数のレプリカを指定できます。また、テイントと寛容を利用して、実際のPostgreSQLクラスターが実行されているノードでオペレーターが実行されないことを確認できます。これには、自己管理のKubernetesインストールのコントロールプレーンが含まれる場合があります。 .. Note:: いくつかのデフォルトオプションをオーバーライドすることにより、オペレーターのデフォルト動作を変更できます。詳細については、 :ref:`Operator configuration ` セクションを参照してください。 　 アップグレード -------------- .. Note:: :ref:`1.14.0以前のリリースノート <1.14.0以前のリリースノート>` をよくお読みください 一部のバージョンは追加の手順を必要とする場合があるため、アップグレードを実行する前に。 　 CloudNativePGオペレーターのアップグレードは、2段階のプロセスです。 1. コントローラと関連するKubernetesリソースをアップグレードする 2. すべてのPostgreSQLポッドで実行されているインスタンスマネージャーをアップグレードする リリースノートに別の記載がない限り、最初のステップは、通常、プレーンなKubernetesインストールの新しいバージョンのマニフェストを適用するか、使用するディストリビューションのネイティブパッケージマネージャーを使用して実行されます上記のセクションの指示に従ってください。 2番目のステップは、コントローラの更新後に自動的にトリガーされます。デフォルトでは、これにより、展開されたすべてのPostgreSQLクラスターのローリング更新が開始され、新しいインスタンスマネージャーを使用するように一度に1つのインスタンスをアップグレードします。ローリング更新は、 ``primaryUpdateStrategy`` オプションによって制御されるスイッチオーバーで終了します。デフォルト値\ ``unsupervised`` は、スイッチオーバーを自動的に完了します。 ``supervised`` に設定している場合、ユーザーは\ ``kubectl`` の\ ``cnpg`` プラグインを使用して、新しいプライマリインスタンスを手動でプロモートする必要があります。 .. Note:: このプロセスは、 :ref:`Rolling updates ` ページで詳細に説明されています。 　 .. Note:: `primaryUpdateStrategy` が`unsupervised` のデフォルト値に設定されている場合、オペレーターのアップグレードはPostgreSQLクラスターでスイッチオーバーをトリガーし、通常は無視できるダウンタイムを発生します。 PostgreSQLクラスターにインスタンスが1つだけある場合、 `supervised` 値は`primaryUpdateStrategy` でサポートされていないため、インスタンスは自動的に再起動されます。いずれの場合も、アプリケーションはPostgreSQLに再接続する必要があります。 　 デフォルトのローリング更新動作は、インスタンスマネージャーのインプレース更新に置き換えることができます。このアプローチでは、 PostgreSQLインスタンスの再起動が必要ないため、クラスター内のスイッチオーバーを回避します。この機能はデフォルトで無効になっていますが、以下で詳細に説明します。 スプレッドアップグレード ^^^^^^^^^^^^^^^^^^^^^^^^ デフォルトでは、すべてのPostgreSQLクラスターは同時にロールアウトされるため、特に複数のクラスターを管理する場合、リソース使用量の急増につながる可能性があります。 CloudNativePGは、 :ref:`operator level ` で2つの構成オプションを提供します これにより、クラスターのロールアウト間、または同じクラスター内のインスタンス間で遅延を導入でき、時間の経過とともにリソース使用量を分散するのに役立ちます。 - ``CLUSTERS_ROLLOUT_DELAY`` さまざまなPostgreSQLクラスターデフォルト\ ``0`` のロールアウトの間で待機する秒数を定義します。 - ``INSTANCES_ROLLOUT_DELAY`` 同じPostgreSQLクラスター内の個々のインスタンスのロールアウトの間で待機する秒数を定義しますデフォルト\ ``0`` 。 インスタンスマネージャーのインプレース更新 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ デフォルトでは、CloudNativePGは、オペレーターが更新されるたびに、クラスターのローリング更新を発行します。オペレーターに同梱される新しいインスタンスマネージャーは、initコンテナを介して各PostgreSQLポッドに追加されます。 ただし、この動作は構成を介して変更でき、インスタンスマネージャーのインプレース更新を有効にできます。これは、コンテナを生きたままにするPID 1プロセスです。 内部的には、CloudNativePGの各インスタンスマネージャーは、完全性検証フェーズが正常に完了し、すべての内部プロセスを正常に終了した後、既存の実行可能ファイルを置き換える新しい実行可能ファイルのインジェクションをサポートします。新しいバイナリで再起動すると、インスタンスマネージャーは既に実行されている *postmaster* をシームレスに採用します。 その結果、PostgreSQLプロセスは更新の影響を受けず、スイッチオーバーを実行する必要はありません。コインの反対側は、Podがスタート後に変更され、不変性の純粋な概念を壊すということです。 :ref:`Operator configuration ` で\ ``ENABLE_INSTANCE_MANAGER_INPLACE_UPDATES`` 環境変数を\ ``'true'`` に設定することにより、この機能を有効にできます。 インプレースアップグレードプロセスでは、ポッド内のinitコンテナイメージは変更されません。したがって、ポッド定義はオペレーターの現在のバージョンを反映しません。 バージョン間の互換性 ^^^^^^^^^^^^^^^^^^^^ CloudNativePGはセマンティックバージョニングに従います。同じAPIバージョン内のオペレーターのすべてのリリースは、以前のAPIバージョンと互換性があります。現在のAPIバージョンはv1で、オペレーターのバージョン1.x.yに対応します。 新機能に加えて、オペレーターの新しいバージョンにはバグ修正と安定性の強化が含まれています。このため、各バージョンは、最も安全で安定したPostgres環境を維持するためにリリースされるため、\**オペレーターの最新バージョンにアップグレードすることを強くお勧めします。 CloudNativePGは現在、少なくとも毎月オペレーターの新しいバージョンをリリースしています。各バージョンが利用可能になったときに更新を適用できない場合は、バージョンをスキップせずに、各バージョンを順番にアップグレードして、定期的に最新の状態になることをお勧めします。 :ref:`1.14.0以前のリリースノート <1.14.0以前のリリースノート>` ページには、CloudNativePGのすべてのリリースバージョンで導入された変更の詳細なリストが含まれており、ソフトウェアの新しいバージョンにアップグレードする前に読む必要があります。 ほとんどのバージョンは直接アップグレード可能であり、その場合、プレーンなKubernetesインストールに新しいマニフェストを適用するか、選択したディストリビューションのネイティブパッケージマネージャーを使用するだけで十分です。 バージョンを直接アップグレードできない場合、新しいバージョンをインストールする前に古いバージョンを削除する必要があります。これはユーザーデータに影響を与えるのではなく、オペレーター自分自身にのみ影響を与えます。 1.28.0または1.27.xへのアップグレード ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Note:: すべてのCloudNativePGユーザーがバージョン1.28.0、または少なくとも現在のマイナーリリース1.27.xなどの最新の安定バージョンにアップグレードすることを強くお勧めします。 　 以前のマイナーバージョンから1.27へのアップグレード ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Note:: すべてのCloudNativePGユーザーがバージョン1.27.0、または少なくとも現在のマイナーリリース1.26.1などの最新の安定バージョンにアップグレードすることを強くお勧めします。 　 バージョン1.27では、 :ref:`Liveness Probe ` のデフォルト動作の変更を導入しました。 :ref:`shutdown of an isolated primary ` ``livenessProbeTimeout`` 30秒以内。 この動作がご使用の環境に適していない場合は、次の構成でlivenessプローブの *分離チェック* を無効にできます。 .. code:: yaml spec: probes: liveness: isolationCheck: enabled: false 以前のマイナーバージョンから1.26へのアップグレード ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Warning:: マネージャーコンポーネント `#6623 `_ の起動プローブの変更のため、オペレーターのアップグレードは、インプレース更新が有効になっている `ENABLE_INSTANCE_MANAGER_INPLACE_UPDATES=true` 場合でも、PostgreSQLクラスターの再起動がトリガーされます。アップグレード後に、アプリケーションはPostgreSQLに再接続する必要があります。 　 ``Cluster`` ``.status`` のバックアップメトリックとフィールドの非推奨 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Barman Cloudのバージョン1.26.0から始まったCloudNativePGのCNPG-Iプラグインに基づいたバックアップとリカバリーにとらわれないアプローチへの移行に伴い、\ ``Cluster`` リソースの\ ``.status`` セクションの次のフィールドの非推奨期間を開始します。 - ``firstRecoverabilityPoint`` - ``firstRecoverabilityPointByMethod`` - ``lastSuccessfulBackup`` - ``lastSuccessfulBackupByMethod`` - ``lastFailedBackup`` 次のPrometheusメトリックも非推奨です。 - ``cnpg_collector_first_recoverability_point`` - ``cnpg_collector_last_failed_backup_timestamp`` - ``cnpg_collector_last_available_backup_timestamp`` .. Warning:: Barman Cloudなどのプラグインベースのバックアップおよびリカバリーソリューションに移行している場合、これらのフィールドとメトリックは同期されず、更新されません。 Barman Cloudとボリュームスナップショットのインコアサポートにまだ依存しているユーザーは、当面はこれらのフィールドを使用し続けることができます。 新しいプラグインベースのアプローチでは、複数のバックアップ方法が同時に動作でき、それぞれがバックアップとリカバリーの独自のタイムラインで動作します。たとえば、一部のプラグインはWALアーカイブなしでスナップショットを提供する場合がありますが、他のプラグインは継続的なアーカイブをサポートします。 この柔軟性のため、 ``Cluster`` リソースで一元化されたステータスフィールドを維持することは、構成されているすべてのバックアップ方法の状態を正確に表していないため、誤解を招くまたは混乱を招く可能性があります。このため、これらのフィールドは非推奨になります。 代わりに、各プラグインは、独自のバックアップステータス情報を公開し、監視と操作の認識のためにインスタンスマネージャーにメトリックを提供します。 ``cnpg`` プラグインの宣言的ハイバネーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このリリースでは、 ``kubectl`` の\ ``cnpg`` プラグインは、命令型から :ref:`declarative approach for cluster hibernation ` に移行します。 ``hibernate on`` および\ ``hibernate off`` コマンドは、宣言的な変更を適用してハイバーネーションを有効または無効にする便利なショートカットになりました。 ``hibernate status`` コマンドは、その目的が標準の\ ``status`` コマンドによって満たされるため、削除されました。