Kubernetesのアップグレード ========================== Kubernetesクラスターは常に更新する必要があります。これは、Kubernetesクラスター、特に **ベアメタル** を自己管理する場合、さらに重要になります。 定期的な更新を計画して実行することは、メンテナンスのためにクラスターからノードを一時的に取り出す制御されたダウンタイムのKubernetesインフラストラクチャに導入されているにもかかわらず、組織が技術的負債をクリーンアップし、ビジネスリスクを削減する方法です。推奨読書 `Embracing Risk `_ サイトリライアビリティーエンジニアリングの本より)。 たとえば、KubernetesがインストールされているLinuxサーバーにセキュリティ更新を適用したり、RAM、CPU、RAIDコントローラなどの誤動作したハードウェアコンポーネントを交換したり、クラスターを最新バージョンのKubernetesにアップグレードしたりする必要がある場合があります。 通常、クラスター内のメンテナンス操作は、次の方法で一度に1ノードずつ実行されます。 1. 更新するノードからのワークロードの削除 ``drain`` 2. 実際の操作の実行たとえば、システムのアップデート 3. ノードのクラスター\ ``uncordon`` への再参加 上記のプロセスでは、アップグレードの期間全体でワークロードを停止するか、別のノードに移行する必要があります。 最新のケースは、サービスの信頼性とKubernetesの自己修復機能の観点から予想されるものですが、一時的に機能が低下したクラスターで動作し、アップグレードされたノードが再び起動するまで待機することをお勧めする状況が発生する場合があります。 特に、PostgreSQLクラスターが **ノードローカルストレージ** -つまり、PostgreSQLデータベースが実行されているKubernetesワーカーノードのローカルな *ストレージに依存している場合* 。ノードローカルストレージまたは単に *ローカルストレージ* は、パフォーマンスを向上させるために使用されます。 .. Note:: データベースファイルがネットワーク上の共有ストレージにある場合、メンテナンスウィンドウを定義する必要はありません。現在ポッドが使用しているボリュームを、ドレイン後に別のノードで実行されているポッドで再利用できる場合、オペレーターのデフォルトの自己修復動作は正常に動作します。その場合、このセクションの残りの部分はスキップできます。 PostgreSQLのローカルストレージを使用する場合、たとえば、物理ノードまたはノード自分自身の更新。 .. Warning:: メンテナンスウィンドウの期間を可能な限り短い時間に制限します。このフェーズでは、Kubernetesの予想される動作の一部が無効になっているか、自己修復、ローリング更新、ポッドの中断バジェットなどの制限付きで実行されています。 クラスターの\ ``nodeMaintenanceWindow`` オプションには、さらに2つの設定があります。 ``inProgress`` ノードのメンテナンスウィンドウが現在進行中かどうかを示すブール値。デフォルトでは、\ ``off`` に設定されています。メンテナンスウィンドウ中に、以下の\ ``reusePVC`` オプションがオペレーターによって評価されます。 ``reusePVC`` メンテナンス操作中に既存のPVCを再利用するかどうかを定義するブール値。デフォルトでは、\ ``on`` に設定されています。 **有効になっている** 、Kubernetesはノードが再び起動するのを待機して、既存のPVCを再利用します。 ``PodDisruptionBudget`` ポリシーは一時的に削除されます。 **無効になっている** 、Kubernetesは、PostgreSQLの物理的ストリーミングレプリケーションに依存して、新しいPVCを使用して別のノードでポッドの再作成を強制し、ポッドとともに古いPVCを破棄します。このシナリオは、データベースのサイズが小さく、新しいPostgreSQLインスタンスの再クローンの作成にかかる時間が待機するよりも短い場合を除き、一般的にお勧めできません。この動作は、インスタンスが1つだけで再利用PVCが無効になっているクラスターには適用されません。以下のセクションを参照してください。 .. Note:: `kubectl drain` コマンドを実行するときは、 `--delete-local-data` オプションを追加する必要があります。恐れないでください。これは、PostgreSQLデータディレクトリではなく、オペレーターが内部的に使用する別のボリュームを参照します。 ``reusePVC`` が\ ``false`` に設定された単一インスタンスクラスター ----------------------------------------------------------------- .. Important:: 高可用性を保証するために、常に複数のインスタンスでクラスターを作成することをお勧めします。 ``reusePVC`` が\ ``false`` に設定されている単一インスタンスクラスター内の唯一のPostgreSQLインスタンスを削除することは、すべてのデータが失われることを意味します。したがって、メンテナンスモードでも、ユーザーがそのようなインスタンスが実行されているノードをドレインできないようにします。 ただし、このようなノードのメンテナンスが必要な場合、2つのオプションがあります。 1. ``reusePVC`` を有効にし、ダウンタイムを受け入れます 2. 別のノードでインスタンスを複製し、プライマリをスイッチオーバーします データベースサービスのダウンタイムがご使用の環境で許容される限り、ノードのドレインは、 ``nodeMaintenanceWindow`` を\ ``inProgress: true`` および\ ``reusePVC: true`` に設定するだけで簡単です。これにより、元のPVCが利用可能になるとすぐにインスタンスを削除して再作成できますたとえば、ノードローカルストレージを使用して、ノードがバックアップされたらすぐに。 それ以外の場合は、クラスターをスケールアップし、別のノードで新しいインスタンスを作成し、新しいインスタンスをプライマリに昇格させて、メンテナンス中のノードで元のインスタンスをシャットダウンする必要があります。この場合の唯一のダウンタイムは、スイッチオーバーの期間です。 考えられるアプローチは次のとおりです。 1. 現在のインスタンスが実行されているノードを遮断します。 2. クラスターを2つのインスタンスにスケールアップします。データベースのサイズによっては、時間がかかる場合があります。 3. 現在のプライマリが遮断されたノードで実行されている場合、新しいインスタンスが実行されると、オペレーターは自動的にスイッチオーバーを実行します。 4. クラスターを単一のインスタンスにスケールダウンします。これにより、古いインスタンスが削除されます