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