Kubernetes クラスターのアップグレード プロセス
Kubernetes クラスターを使用している場合、ある時点で、実行中のノードを更新する必要があります。 これには、パッケージの更新、カーネルの更新、または新しい仮想マシン イメージの展開が含まれる場合があります。 Kubernetes 用語では、これを次のように呼びます。 .
この投稿は 4 つの投稿シリーズの一部です。
- この郵便受け。
- Kubernetes クラスター内のポッドの正しいシャットダウン
- ポッド削除時の遅延終了
- PodDisruptionBudgets を使用して Kubernetes クラスターのダウンタイムを回避する方法
(近い将来、このシリーズの残りの記事も翻訳される予定です)
この記事では、クラスター内で実行されているノードのダウンタイムをゼロにするために Kubernetes が提供するすべてのツールについて説明します。
問題の定義
最初は素朴なアプローチを採用し、問題を特定してこのアプローチの潜在的なリスクを評価し、サイクル全体で遭遇するそれぞれの問題を解決するための知識を構築します。 その結果、ライフサイクル フック、Readiness Probe、およびポッド中断バジェットを使用してゼロ ダウンタイムの目標を達成する構成が得られます。
旅を始めるために、具体的な例を見てみましょう。 XNUMX つのノードからなる Kubernetes クラスターがあり、アプリケーションが背後にある XNUMX つのポッドで実行されているとします。 Service:
XNUMX つの Kubernetes クラスター ノードで Nginx と Service を実行する XNUMX つのポッドから始めましょう。
クラスター内の XNUMX つのワーカー ノードのカーネル バージョンを更新したいと考えています。 どうやってこれを行うのでしょうか？ 簡単な解決策は、更新された構成で新しいノードを起動し、新しいノードを起動している間に古いノードをシャットダウンすることです。 これは機能しますが、このアプローチにはいくつかの問題があります。
- 古いノードをオフにすると、そのノードで実行されているポッドもオフになります。 正常なシャットダウンのためにポッドをクリアする必要がある場合はどうすればよいでしょうか? 使用している仮想化システムは、クリーンアップ プロセスが完了するまで待機しない可能性があります。
- すべてのノードを同時にオフにするとどうなるでしょうか? ポッドが新しいノードに移動する間、かなりのダウンタイムが発生します。
ノードに変更を加えている間、ワーカー プロセスが実行されていないことを確認しながら、古いノードからポッドを適切に移行する方法が必要です。 または、例のようにクラスターを完全に置き換える場合 (つまり、VM イメージを置き換える場合)、実行中のアプリケーションを古いノードから新しいノードに転送する必要があります。 どちらの場合も、新しいポッドが古いノードでスケジュールされるのを防ぎ、実行中のすべてのポッドをそれらのノードから削除する必要があります。 これらの目標を達成するには、次のコマンドを使用できます kubectl drain.
ノードからのすべてのポッドの再配布
ドレイン操作を使用すると、ノードからすべてのポッドを再配布できます。 ドレインの実行中、ノードはスケジュール不可としてマークされます (フラグ NoSchedule）。 これにより、新しいポッドが表示されなくなります。 次に、ドレインはノードからポッドの削除を開始し、ノード上で現在実行されているコンテナをシャットダウンし、シグナルを送信します。 TERM ポッド内のコンテナ。
しかし kubectl drain ポッドの削除には優れた機能を果たしますが、ドレイン操作が失敗する原因となる可能性のある要因が他に XNUMX つあります。
- アプリケーションは送信時に正常に終了できる必要があります
TERM信号。 ポッドが削除されると、Kubernetes はシグナルを送信します。TERMコンテナを停止し、指定された時間の間コンテナが停止するのを待ちます。その後、コンテナが停止していない場合は強制的に終了します。 いずれの場合でも、コンテナーが信号を正しく認識しない場合でも、現在実行中のポッド (たとえば、データベース トランザクションが進行中) であれば、ポッドを誤って終了する可能性があります。 - アプリケーションを含むすべてのポッドが失われます。 新しいノードで新しいコンテナーが起動される場合、またはコントローラーなしでポッドがデプロイされている場合は、ポッドがまったく再起動されない場合があります。
ダウンタイムの回避
ノードでのドレイン操作などによる自発的な中断によるダウンタイムを最小限に抑えるために、Kubernetes には次の障害処理オプションが用意されています。
このシリーズの残りの部分では、これらの Kubernetes 機能を使用してポッド移行の影響を軽減します。 主な考え方を理解しやすくするために、上記の例を次のリソース構成で使用します。
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15
ports:
- containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
targetPort: 80
port: 80この構成は最小限の例です Deployment、クラスター内の nginx ポッドを管理します。 さらに、設定ではリソースについて説明します。 Service、クラスター内の nginx ポッドにアクセスするために使用できます。
このサイクル全体を通じて、この構成を繰り返し拡張していき、最終的にはダウンタイムを削減するために Kubernetes が提供するすべての機能がこの構成に組み込まれるようにします。
AWS などでダウンタイムをゼロにする Kubernetes クラスター更新の完全に実装およびテストされたバージョンについては、次のサイトにアクセスしてください。 .
私たちのブログの他の記事もお読みください。
出所： habr.com