Installation and upgrades

Kubernetesへのインストール

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

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

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

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.29/releases/cnpg-1.29.0.yaml

これは次の方法で確認できます。

kubectl rollout status deployment \
  -n cnpg-system cnpg-controller-manager

`kubectl` の`cnpg` プラグインを使用する

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

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

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

より包括的な例については、 postgresql.cnpg.io/v1 ドキュメントを参照してください。

警告

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

そしてこれによって issue 。 WebhookサービスのtargetPort を許可されるもののいずれかに変更するか、ファイアウォールでWebhookのポート9443 を開く必要があります。

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 です。

注釈

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>

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

オペレーターレベルでの高可用性が必要な場合、オペレーターがリーダー選択をサポートしていることを考慮すると、展開構成で複数のレプリカを指定できます。また、テイントと寛容を利用して、実際のPostgreSQLクラスターが実行されているノードでオペレーターが実行されないことを確認できます。これには、自己管理のKubernetesインストールのコントロールプレーンが含まれる場合があります。

アップグレード

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

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

コントローラと関連するKubernetesリソースをアップグレードする
すべてのPostgreSQLポッドで実行されているインスタンスマネージャーをアップグレードする

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

2番目のステップは、コントローラの更新後に自動的にトリガーされます。デフォルトでは、これにより、展開されたすべてのPostgreSQLクラスターのローリング更新が開始され、新しいインスタンスマネージャーを使用するように一度に1つのインスタンスをアップグレードします。ローリング更新は、 primaryUpdateStrategy オプションによって制御されるスイッチオーバーで終了します。デフォルト値unsupervised は、スイッチオーバーを自動的に完了します。 supervised に設定している場合、ユーザーはkubectl のcnpg プラグインを使用して、新しいプライマリインスタンスを手動でプロモートする必要があります。

デフォルトのローリング更新動作は、インスタンスマネージャーのインプレース更新に置き換えることができます。このアプローチでは、 PostgreSQLインスタンスの再起動が必要ないため、クラスター内のスイッチオーバーを回避します。この機能はデフォルトで無効になっていますが、以下で詳細に説明します。

スプレッドアップグレード

デフォルトでは、すべてのPostgreSQLクラスターは同時にロールアウトされるため、特に複数のクラスターを管理する場合、リソース使用量の急増につながる可能性があります。 CloudNativePGは、 operator level で2つの構成オプションを提供します

これにより、クラスターのロールアウト間、または同じクラスター内のインスタンス間で遅延を導入でき、時間の経過とともにリソース使用量を分散するのに役立ちます。

CLUSTERS_ROLLOUT_DELAY さまざまなPostgreSQLクラスターデフォルト0 のロールアウトの間で待機する秒数を定義します。
INSTANCES_ROLLOUT_DELAY 同じPostgreSQLクラスター内の個々のインスタンスのロールアウトの間で待機する秒数を定義しますデフォルト0 。

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

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

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

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

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

Operator configuration でENABLE_INSTANCE_MANAGER_INPLACE_UPDATES 環境変数を'true' に設定することにより、この機能を有効にできます。

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

バージョン間の互換性

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

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

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

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

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

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

1.29.0または1.28.xへのアップグレード

以前のマイナーバージョンから1.27へのアップグレード

バージョン1.27では、 Liveness Probe のデフォルト動作の変更を導入しました。 shutdown of an isolated primary

livenessProbeTimeout 30秒以内。

この動作がご使用の環境に適していない場合は、次の構成でlivenessプローブの 分離チェック を無効にできます。

spec:
  probes:
    liveness:
      isolationCheck:
        enabled: false

リリースアセットの検証

CloudNativePGは、すべての公式リリースアセットに暗号的に署名します。これらの署名を検証することにより、アセットが公式リポジトリから生成され、自動リリースワークフローを通じて公開されたことが保証されます。

注釈

リリースの完全性とサプライチェーンを参照してください。

詳細については、

前提条件

署名検証 cosign CLI
SBOMと来歴 Docker Buildx

Docker Desktopおよび最新のDockerバージョンに含まれています

オペレーターYAML展開の検証

直接YAMLマニフェストを介してインストールする場合、 GitHub Release page で提供される対応するバンドル .sigstore.json ファイルを使用してマニフェストファイルを確認する必要があります。

次のコマンドを実行します。

cosign verify-blob \
  cnpg-{version}.yaml \
  --bundle cnpg-{version}.sigstore.json \
  --certificate-identity-regexp "^https://github.com/cloudnative-pg/cloudnative-pg/.github/workflows/release-publish.yml@refs/tags/v" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

SLSAの出所の検証

リリースバイナリを検証するには、アーティファクトと来歴ファイル multiple.intoto.jsonl の両方を GitHub release からダウンロードし、実行します。

slsa-verifier verify-artifact <ARTIFACT> \
  --provenance-path multiple.intoto.jsonl \
  --source-uri github.com/cloudnative-pg/cloudnative-pg

オペレーターコンテナイメージの検証

次のコマンドを実行して、CloudNativePGオペレーターイメージの署名を確認します。

cosign verify ghcr.io/cloudnative-pg/cloudnative-pg:{tag} \
  --certificate-identity-regexp="^https://github.com/cloudnative-pg/cloudnative-pg/.github/workflows/release-publish.yml@refs/tags/v" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

完全な透明性を実現するためにOCI証明書を提供します。ソフトウェア部品表SBOMを検査するか、来歴をビルドするには、 docker buildx imagetools コマンドを使用します。

SPDX形式のソフトウェア部品表SBOMを表示するには

docker buildx imagetools inspect ghcr.io/cloudnative-pg/cloudnative-pg:{tag} \
  --format {{ json (index .SBOM "linux/amd64").SPDX }}

SLSA来歴ビルドの詳細を検査するには

docker buildx imagetools inspect ghcr.io/cloudnative-pg/cloudnative-pg:{tag} \
  --format {{ json (index .Provenance "linux/amd64").SLSA }}

注釈

SLSAの出所の検証参照

SLSAビルドレベル3コンプライアンス検証用。

PostgreSQLオペランドイメージの検証

CloudNativePGは、サポートされているすべてのPostgreSQLバージョンのコンテナイメージを postgres-containers の一部として維持します

オペランドイメージとも呼ばれます。

特定のオペランドイメージの署名を検証するには

cosign verify ghcr.io/cloudnative-pg/postgresql:{tag} \
  --certificate-identity-regexp="^https://github.com/cloudnative-pg/postgres-containers/" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com"