Kubernetes Upgrade and Maintenance ================================== 最新のKubernetesクラスターを維持することは、最適なパフォーマンスとセキュリティを保証するために重要であり、特に自己管理クラスター、特にベアメタルインフラストラクチャで実行されているクラスターの場合。定期的な更新は、メンテナンスのためにクラスターからノードを一時的に削除することに関連するダウンタイムの制御にもかかわらず、技術的負債に対処し、ビジネスリスクを軽減するのに役立ちます。オペレーションでのリスクの受け入れに関する詳細な洞察については、 `Embracing Risk `_ を参照してください。 Site Reliability Engineeringの本からの章。 定期的なアップデートの重要性 ---------------------------- Kubernetesの更新には、基になるLinuxサーバーへのセキュリティ更新の適用、故障したハードウェアコンポーネントの交換、クラスターの最新のKubernetesバージョンへのアップグレードなどのメンテナンスタスクの計画と実行が含まれます。これらのアクティビティは、堅牢で安全なインフラストラクチャを維持するために不可欠です。 クラスター内のメンテナンス操作 ------------------------------ 通常、メンテナンス操作は、 `structured process `_ に従って、一度に1つのノードで実行されます。 1. ワークロードのエビクション ``drain`` ワークロードは更新するノードから正常に移動され、スムーズな移行が保証されます。 2. 操作の実行 システムの更新やハードウェアの交換など、実際のメンテナンス操作が実行されます。 3. ノードのクラスター\ ``uncordon`` への再参加更新されたノードはクラスターに再統合され、その責任を再開する準備が整います。 このプロセスでは、アップグレード期間全体でワークロードを停止するか、クラスター内の他のノードに移行する必要があります。 一時的なPostgreSQLクラスターの低下 ---------------------------------- 標準のアプローチはサービスの信頼性を保証し、Kubernetesの自己修復機能を活用しますが、一時的に機能が低下したクラスターでの動作が受け入れられるシナリオがあります。これは、 **ノードローカルストレージ** に依存するPostgreSQLクラスターに特に関連します。ここで、ストレージはPostgreSQLデータベースを実行しているKubernetesワーカーノードにローカルです。ノードローカルストレージまたは単に *ローカルストレージ* は、パフォーマンスを向上させるために使用されます。 .. Note:: データベースファイルがネットワーク経由でアクセスできる共有ストレージにある場合、オペレーターのデフォルトの自己修復動作は、ドレイン操作の後に別のノードのポッドによってボリュームが再利用されるシナリオを効率的に処理できます。このような場合、このドキュメントの残りのセクションをスキップできます。 ポッドの中断予算 ---------------- デフォルトでは、KubernetesのEDB PostgresはPostgresクラスター操作を保護します。ノードがドレインされ、クラスターのプライマリインスタンスが含まれている場合、スイッチオーバーはドレインの前に発生します。ノードのインスタンスがレプリカにダウングレードされると、ドレインを再開できます。単一インスタンスクラスターの場合、スイッチオーバーは不可能であるため、KubernetesのEDB Postgresは、インスタンスが格納されているノードのドレインを防ぎます。さらに、3つ以上のインスタンスがあるクラスターでは、KubernetesのEDB Postgresは、ドレイン操作中に一度に1つのレプリカのみが正常にシャットダウンされることを保証します。 各PostgreSQL ``Cluster`` には、関連する2つの\ ``PodDisruptionBudget`` リソースが装備されています。 ``kubectl get pdb`` コマンドで簡単に確認できます。 すべての運用Postgresクラスターでポッドの中断バジェットを有効にしたままにすることをお勧めします。これは、 :ref:`API Reference - v1.25.1 ` で詳細に説明しているように、 ``.spec.enablePDB`` オプションを切り替えることにより簡単に管理できます。 開発またはテストに使用されるPostgreSQLクラスター ------------------------------------------------ 開発目的で使用されるPostgreSQLクラスターの場合、多くの場合単一のインスタンスで構成され、ポッドの中断バジェットを無効にすることが重要です。これを行わないと、そのクラスターをホストするノードはドレインされません。 次の例は、1インスタンスの開発クラスターのポッド中断バジェットを無効にする方法を示しています。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: dev spec: instances: 1 enablePDB: false storage: size: 1Gi この構成により、開発アクティビティ中にノードのドレインを制限せずに、よりスムーズなメンテナンス手順が保証されます。 ノードのメンテナンスウィンドウ ------------------------------ .. Important:: KubernetesのEDB Postgresはノードのメンテナンスウィンドウのサポートを継続しますが、以前のセクションで説明したように、現在ポッドの中断バジェットの直接制御に移行することをお勧めします。このセクションは、主に下位互換性のために保持されています。 リリース1.23より前は、Kubernetes用EDB Postgresには、ローカルストレージを処理する際にKubernetesのアップグレードを管理するための宣言的メカニズムが1つだけありました。たとえば、物理ノードのパーティションを拡大したり、ノード自分自身を更新したりしながらキックインします。 .. Warning:: メンテナンスウィンドウの期間を可能な限り短い時間に制限します。このフェーズでは、Kubernetesの予想される動作の一部が無効になっているか、自己修復、ローリング更新、ポッドの中断バジェットなどの制限付きで実行されています。 クラスターの\ ``nodeMaintenanceWindow`` オプションには、さらに2つの設定があります。 ``inProgress`` ノードのメンテナンスウィンドウが現在進行中かどうかを示すブール値。デフォルトでは、\ ``off`` に設定されています。メンテナンスウィンドウ中に、以下の\ ``reusePVC`` オプションがオペレーターによって評価されます。 ``reusePVC`` メンテナンス操作中に既存のPVCを再利用するかどうかを定義するブール値。デフォルトでは、\ ``on`` に設定されています。 **有効になっている** 、Kubernetesはノードが再び起動するのを待機して、既存のPVCを再利用します。 ``PodDisruptionBudget`` ポリシーは一時的に削除されます。 **無効になっている** 、Kubernetesは、PostgreSQLの物理的ストリーミングレプリケーションに依存して、新しいPVCを使用して別のノードでポッドの再作成を強制し、ポッドとともに古いPVCを破棄します。このシナリオは、データベースのサイズが小さく、新しいPostgreSQLインスタンスの再クローンの作成にかかる時間が待機するよりも短い場合を除き、一般的にお勧めできません。この動作は、インスタンスが1つだけで再利用PVCが無効になっているクラスターには適用されません。以下のセクションを参照してください。 .. Note:: `kubectl drain` コマンドを実行するときは、 `--delete-emptydir-data` オプションを追加する必要があります。恐れないでください。これは、PostgreSQLデータディレクトリではなく、オペレーターが内部的に使用する別のボリュームを参照します。 .. Important:: `PodDisruptionBudget` 管理は、 `.spec.enablePDB` フィールドを`false` に設定することにより無効にできます。その場合、オペレーターは`PodDisruptionBudgets` を作成せず、以前に作成されている場合は削除します。 ``reusePVC`` が\ ``false`` に設定された単一インスタンスクラスター ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Important:: 高可用性を保証するために、常に複数のインスタンスでクラスターを作成することをお勧めします。 ``reusePVC`` が\ ``false`` に設定されている単一インスタンスクラスター内の唯一のPostgreSQLインスタンスを削除することは、すべてのデータが失われることを意味します。したがって、メンテナンスモードでも、ユーザーがそのようなインスタンスが実行されているノードをドレインできないようにします。 ただし、このようなノードのメンテナンスが必要な場合、2つのオプションがあります。 1. ``reusePVC`` を有効にし、ダウンタイムを受け入れます 2. 別のノードでインスタンスを複製し、プライマリをスイッチオーバーします データベースサービスのダウンタイムがご使用の環境で許容される限り、ノードのドレインは、 ``nodeMaintenanceWindow`` を\ ``inProgress: true`` および\ ``reusePVC: true`` に設定するだけで簡単です。これにより、元のPVCが利用可能になるとすぐにインスタンスを削除して再作成できますたとえば、ノードローカルストレージを使用して、ノードがバックアップされたらすぐに。 それ以外の場合は、クラスターをスケールアップし、別のノードで新しいインスタンスを作成し、新しいインスタンスをプライマリに昇格させて、メンテナンス中のノードで元のインスタンスをシャットダウンする必要があります。この場合の唯一のダウンタイムは、スイッチオーバーの期間です。 考えられるアプローチは次のとおりです。 1. 現在のインスタンスが実行されているノードを遮断します。 2. クラスターを2つのインスタンスにスケールアップします。データベースのサイズによっては、時間がかかる場合があります。 3. 現在のプライマリが遮断されたノードで実行されている場合、新しいインスタンスが実行されると、オペレーターは自動的にスイッチオーバーを実行します。 4. クラスターを単一のインスタンスにスケールダウンします。これにより、古いインスタンスが削除されます 5. 新しいノードで新しいプライマリを実行したまま、古いプライマリのノードを正常にドレインできるようになりました。