Kubernetes ノードをより安全にアップグレードする方法

クラスターを新しい Kubernetes バージョンにアップグレードすることに不安を感じていますか?アップグレードを促す理由はいくつかあります。おそらく、次のいずれかを実行したいでしょう。

新しいベータAPIの使用
Kubernetes のバージョン更新を必要とする最新機能
ソフトウェアを最新の状態に保つためのベストプラクティスに従う

理由が何であれ、アップグレード中のダウンタイム (および不安) を最小限に抑えるために、アップグレードプロセスを見直す価値はあります。

どのコンポーネントをアップグレードする必要がありますか?

Kubernetes クラスターは、一連のノードとコントロールプレーンで構成されます。ワーカーノードは、コンテナ化されたアプリケーションを実行するポッドをホストします。コントロールプレーンは、クラスター内のワーカーノードとポッドを管理します。

Kubernetes クラスターのコンポーネント (kubernetes.io より)

Kubernetes クラスターをアップグレードするには、次の順序でこれら 2 つのコンポーネントをアップグレードします。

コントロールプレーンのアップグレード
ワーカーノードのアップグレード

セルフホスト型クラスターとマネージド型クラスターの両方において、コントロールプレーンのアップグレードは非常に簡単です。この投稿では、ワーカーノードのアップグレードのダウンタイムを最小限に抑えることに焦点を当てます。

ワーカーノードのアップグレード

ワーカーノード上の Kubernetes バージョンをアップグレードするには、次の 2 つの戦略があります。

インプレースアップグレード (ローリングアップデートとも呼ばれる)
リモートアップグレード

インプレースアップグレードの場合、ノードは 1 つずつドレインされ、ブロックされるため、ノードに新しいポッドがスケジュールされることはありません。次に、ノードを削除し、更新された Kubernetes バージョンで再作成します。新しいノードが起動して実行されると、次のノードが更新されます。この戦略は、次の視覚化アニメーションのようになります。

Kubernetes クラスター内のノードのインプレースアップグレードを示すアニメーション

インプレースアップグレードの利点は、追加のコンピューティングリソース (単一の追加ノード) が最小限で済むことです。この戦略の欠点は、ノードが 1 つずつドレインされ、アップグレードされるため、かなり長い時間がかかる可能性があることです。さらに、ノードのドレイン中にポッドがシャッフルされるため、ポッドを複数回移動する必要がある場合があります。

地理的アップグレードの場合は、新しい Kubernetes バージョンで新しいノードプールを作成します。すべての新しいノードが実行されると、古いノードプールをブロックし、古いノードを 1 つずつドレインしてから、古いノードプールを削除できます。この戦略は以下のアニメーションで視覚化されています。

Kubernetes クラスター内のノードのアウトオブプレースアップグレードを示すアニメーション

オフサイトアップグレードでは、アップグレード期間を短縮する代わりに、コンピューティングリソースを一時的に 2 倍にする必要があります。アップグレード期間の短縮は、新しくアップグレードされたノードの起動時間の並列化とポッドの移動の最小化によるものです。この戦略では、ポッドは古いノードから新しくアップグレードされたノードに移動されます。

コンピューティングリソースの使用率が一時的に増加しても問題ない場合は、オフサイトアップグレード戦略を使用して処理を高速化することをお勧めします。

K8sリソースを構成する

どのワーカーノードのアップグレード戦略を選択した場合でも、元のノードからアップグレードされたノードにポッドをシャッフルすることになります。リソースが正しく構成されていない場合、ダウンタイムが発生する可能性があります。潜在的な落とし穴をいくつか見てみましょう。

独立ポッド

Pod は、Kubernetes でデプロイ可能な最小のオブジェクトです。これは、クラスター内で実行されているアプリケーションの単一インスタンスを表します。ポッドは一時的なものです。ポッドがノードから削除された場合、ポッドはそれ自体を置き換えません。 Pod は自己修復機能がないため、単一の Pod を直接作成することはお勧めしません。代わりに、Deployment などのコントローラーを使用して、Pod を作成および管理します。

ダウンタイムを最小限に抑えるには、すべてのポッドが ReplicaSet、Deployment、StatefulSet または同様のものによって管理されていることを確認してください。アップグレード後には、個々のポッドを手動で再スケジュールする必要がある場合があります。

展開

クラスター内のポッドのほとんどは、デプロイメントによって制御される可能性があります。デプロイメントは、一意の ID を持たない同一のポッドのグループを表します。デプロイメントでは、アプリケーションの複数のコピーを管理し、いずれかのインスタンスに障害が発生した場合に代替品をデプロイすることで、可用性が向上します。

ダウンタイムをなくすには、アプリケーションに PodDisruptionBudget (PDB) があることを確認してください。 PDB は、同時にシャットダウンできる複製されたアプリケーションのポッドの数を制限することで、より高い可用性を実現します。

たとえば、次の PDB では、停止中 (アップグレードなど) にフロントエンドラベルを持つポッドの 80% が利用可能である必要があると規定されています。これにより、負荷を処理するレプリカの数が、レプリカの合計数の特定の割合を下回ることがなくなります。

 apiバージョン: ポリシー/ v1
 種類: PodDisruptionBudget
 メタデータ:
 名前: デモ
仕様:
 最小利用可能数: 80 %
 セレクター:
 マッチラベル:
 名前: フロントエンド

ノードをアップグレードできるようにするには、複数のレプリカ (少なくともアップグレード中は一時的に) があることを確認する必要があることに注意してください。

デーモンセット

DaemonSet は、すべての (または一部の) ノードがポッドのコピーを実行することを保証します。デーモンセットは通常、ノード監視またはログ収集に使用され、通常はトラフィックを処理しません。これらのユースケースでは、ワーカーノードのアップグレード中にデータに小さなギャップが生じても通常は許容されます。

ステートフルセット

StatefulSet は、データベースやメッセージキューなどのステートフルアプリケーションを管理するために使用される Kubernetes コントローラーの一種です。 StatefulSets のアップグレードには、Deployment のアップグレードよりも多くの考慮が必要です。

ダウンタイムをなくすには、次の設定がされていることを確認してください。

PodDisruptionBudget を追加します (「デプロイメント」セクションの手順を参照)。クォーラムベースのアプリケーションの場合、実行中のレプリカの数がクォーラムに必要な数 (たとえば、minAvailable: 51%) を下回らないようにします。
複数のコピーがあることを確認してください (少なくともアップグレード中は一時的に)。
すべての PersistentVolume を必ず保存してください。
選択ベースのアプリケーションの場合は、準備プローブが構成されていることを確認します。

StatefulSet 潜在的イベント-1

StatefulSet をアップグレードする際の PodDisruptionBudget (PDB) の重要性を説明するために、分散メッセージングシステム STAN を使用するサンプルクラスターを考えてみましょう。

STAN は Raft のクォーラムコンセンサスに依存しており、決定にはサーバーの過半数 (> 50%) の同意が必要です。このクラスターの STAN StatefulSet には 5 つのレプリカがあります。レプリカの 2 つに障害が発生しても、STAN は引き続き動作します。ただし、2 つ以上のレプリカに障害が発生すると、STAN はクォーラムを失い、動作を停止します。

サンプルクラスターの STAN StatefulSet には PDB がありません。この構成では、アップグレード中に次の理由でクォーラムが失われる可能性があります。

PDB がないため、制御計画では任意の数の STAN ポッドが中断される可能性があることを示しています。

つまり、ノードプールのアップグレードにより、STAN ポッドの 50% 以上が同時に中断される可能性があります。この場合、最初のノードがドレインされると、5 つの STAN ポッドのうち 3 つが直ちに削除されます。
残りの 2 つの STAN ポッドはクォーラムを維持できず、回復不能なデータ損失が発生します。
この障害モードは、以下のアニメーションで視覚化されています。 5 つの正方形は 5 つの STAN ポッドを表します。

アップグレード中にクォーラムを失う Raft アプリケーションのアニメーション。 StatefulSet に PDB がありません

この場合、minAvailable: 51% で構成された PDB は、少なくとも 51% の Pod がドレインノードから直ちに排除されるようにすることで、クォーラム損失を防ぐことができます。

StatefulSet 潜在的イベント 2

StatefulSet をアップグレードする際の準備状況プローブの重要性を説明するために、同じサンプルクラスターを考えてみましょう。

サンプルクラスターの STAN StatefulSet は、PDB (minAvailable: 51%) とライブネスプローブで構成されていますが、準備プローブがありません。この構成では、アップグレード中に次の理由でクォーラムが失われる可能性があります。

コントローラは PDB に従い、特定の時間にダウンしている STAN ノードが半分未満であることを確認します。最初は、ドレインノードから 2 つの STAN ポッドのみが削除されます。
ただし、準備プローブがないため、中断された STAN ポッドがスケジュールされてアクティブ化されると、コントローラーはさらに多くのポッドを中断できます。
活性チェックは実行中のコンテナを示すことを目的としているため、STAN は Raft ログの読み取りを開始する前 (または終了する前) に自身をアクティブとしてマークします。
ただし、2 つの STAN ポッドはまだ Raft ログの読み取りを完了していないため、トラフィックを受け入れる準備ができていません。
コントローラーがさらに多くの STAN ポッドに割り込むと、アクティブな STAN ポッドが 50% 以上あるときに、STAN ポッドの 50% 未満が準備完了になる可能性があります (つまり、一部のポッドは Raft ログから状態を回復するのに忙しい)。
残りの 2 つの STAN ポッドはクォーラムを維持できず、回復不能なデータ損失が発生します。

この障害モードは、以下のアニメーションで視覚化されています。 5 つの正方形は 5 つの STAN ポッドを表します。赤い四角は、ポッドがまだアクティブではないことを示します。黄色の四角は、ポッドがまだ準備ができていないことを示します。

アップグレード中にクォーラムを失う Raft アプリケーションのアニメーション。 StatefulSet に準備プローブがありません。

この場合、準備プローブは、新しく作成された STAN ポッドの準備が整うまで、それ以上の STAN ポッドが中断されるのを防ぎます。準備プローブは、/streaming/serverz 監視エンドポイントに HTTP GET リクエストを送信するように構成できます。このエンドポイントは、STAN サーバーの準備が整うまでリクエストに応答しません。