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ワーカーノードに対してローカルなストレージです。ノード ローカル ストレージ (または単に ローカル ストレージ) を使用して、パフォーマンスを向上させます。

注釈

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

PostgreSQL にローカル ストレージを使用する場合は、nodeMaintenanceWindow オプションを使用してクラスターを一時的に メンテナンスモード にして、標準の自己修復手順が開始されないようにすることをお勧めします。たとえば、物理ノードのパーティションを拡大したり、ノード自体を更新します。

警告

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

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

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

reusePVC : メンテナンス操作中に既存の PVC を再利用するかどうかを定義するブール値。デフォルトでは、on に設定されています。 有効 にすると、Kubernetes はノードが再起動するのを待ってから、既存の PVC を再利用します。 PodDisruptionBudget ポリシーは一時的に削除されます。 無効化 すると、Kubernetes は、PostgreSQL の物理ストリーミングレプリケーションに依存して、新しい PVC を使用して別のノードに Pod を強制的に再作成し、古い PVC を Pod と一緒に破棄します。このシナリオは、データベースのサイズが小さく、新しい 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. クラスターを 1 つのインスタンスにスケールダウンします。これにより、古いインスタンスが削除されます。

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