Kubernetesのアップグレード

Kubernetesクラスターは最新の状態に保つ必要があります。特に ベアメタル でKubernetesクラスターを自己管理している場合、これはさらに重要になります。

定期的な更新を計画して実行することは、メンテナンスのためにクラスターからノードを一時的に削除する制御されたダウンタイムがKubernetesインフラストラクチャに導入されているにもかかわらず、組織が技術的負債を整理し、ビジネスリスクを軽減する方法です（推奨される読書： Embracing Risk Site Reliability Engineeringの本から）。

たとえば、KubernetesがインストールされているLinuxサーバーにセキュリティ更新プログラムを適用したり、RAM、CPU、RAIDコントローラーなどの誤動作したハードウェアコンポーネントを交換したり、クラスターを最新バージョンのKubernetesにアップグレードしたりする必要がある場合があります。

通常、クラスターでのメンテナンス操作は、一度に1つのノードで実行されます。

1.更新するノードからワークロードを追い出す（drain ）

2.実際の操作（システムアップデートなど）の実行

3.ノードをクラスターに再参加する（uncordon ）

上記のプロセスでは、アップグレードの全期間にわたってワークロードを停止するか、別のノードに移行する必要があります。

最新のケースは、サービスの信頼性とKubernetesの自己修復機能の面で予想されるケースですが、一時的に低下したクラスターで動作し、アップグレードされたノードが再度稼働するまで待機することが推奨される場合があります。

特に、PostgreSQLクラスターが ノードローカルストレージ - に依存している場合、それは* PostgreSQLデータベースが実行されているKubernetesワーカーノードにローカルです。ノードローカルストレージ（または単にローカルストレージ*）は、パフォーマンスを向上させるために使用されます。

注釈

データベースファイルがネットワーク上の共有ストレージにある場合、メンテナンスウィンドウを定義する必要はない場合があります。ポッドによって現在使用されているボリュームを、ドレイン後に別のノードで実行されているポッドで再利用できる場合、オペレーターのデフォルトの自己修復動作は正常に機能します（このセクションの残りの部分をスキップできます）。

PostgreSQLのローカルストレージを使用する場合、たとえば、物理ノードまたはノード自分自身を更新します。

警告

メンテナンスウィンドウの期間を可能な限り短い時間に制限します。このフェーズでは、Kubernetesの予想される動作の一部が無効になるか、自己修復、ローリングアップデート、ポッド中断バジェットなどの制限付きで実行されます。

クラスターの nodeMaintenanceWindow オプションには、さらに2つの設定があります。

inProgress ：ノードのメンテナンスウィンドウが現在進行中かどうかを示すブール値。デフォルトでは、off に設定されています。メンテナンスウィンドウ中に、以下のreusePVC オプションがオペレーターによって評価されます。

reusePVC ：メンテナンス操作中に既存のPVCを再利用するかどうかを定義するブール値。デフォルトでは、on に設定されています。 有効にする と、Kubernetesはノードが再び起動するのを待ってから、既存のPVCを再利用します。 PodDisruptionBudget ポリシーは一時的に削除されました。 無効 の場合、KubernetesはPostgreSQLの物理ストリーミングレプリケーションを使用して、新しいPVCを使用して別のノードにポッドを強制的に再作成し、ポッドと一緒に古いPVCを破棄します。このシナリオは、データベースのサイズが小さく、新しいPostgreSQLインスタンスの再クローンにかかる時間が待機するよりも短い場合を除き、通常はお勧めできません。この動作は、インスタンスが1つだけで、reusePVCが無効になっているクラスターには適用されません**。以下のセクションを参照してください。

注釈

kubectl drain コマンドを実行する場合、 --delete-local-data オプションを追加する必要があります。恐れる必要はありません。PostgreSQLデータディレクトリではなく、オペレーターが内部的に使用する別のボリュームを参照しています。

reusePVC がfalse に設定されたシングルインスタンスクラスター

重要

高可用性を保証するために、常に複数のインスタンスでクラスターを作成することをお勧めします。

reusePVC がfalse に設定されたシングルインスタンスクラスター内の唯一のPostgreSQLインスタンスを削除すると、すべてのデータが失われることを意味するため、メンテナンスモードであっても、ユーザーがそのようなインスタンスが実行されているノードをドレインしないようにします。

ただし、そのようなノードのメンテナンスが必要な場合、2つのオプションがあります。

1.ダウンタイムを受け入れてreusePVC を有効にします

2.別のノードにインスタンスをレプリケートし、プライマリを切り替えます

データベースサービスのダウンタイムが環境で許容できる限り、ノードのドレインはnodeMaintenanceWindow をinProgress: true およびreusePVC: true に設定するのと同じくらい簡単です。これにより、元のPVCが使用可能になるとすぐに（ノードがバックアップされるとすぐに）インスタンスを削除して再作成できます。

それ以外の場合は、クラスターをスケールアップし、別のノードで新しいインスタンスを作成し、新しいインスタンスをプライマリに昇格させて、メンテナンス中のノードで元のインスタンスをシャットダウンする必要があります。この場合の唯一のダウンタイムは、スイッチオーバーの期間です。

考えられるアプローチは次のとおりです。

1.現在のインスタンスが実行されているノードをコーディングします。

2.クラスターを2つのインスタンスにスケールアップします。データベースのサイズによっては時間がかかる場合があります。

3.新しいインスタンスが実行されるとすぐに、現在のプライマリが遮断されたノードで実行されていると、オペレーターは自動的にスイッチオーバーを実行します。

4.クラスターを単一のインスタンスにスケールダウンします。これにより、古いインスタンスが削除されます

5.新しいノードで新しいプライマリを実行したままで、古いプライマリのノードを正常にドレインできます。