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を使用して別のノードでPodの再作成を強制し、Podと一緒に古い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.新しいノードで新しいプライマリを実行したまま、古いプライマリのノードを正常にドレインできます。