5分間のK8s実践 - ローリングアップデートと正常なシャットダウン

アプリケーションを本番環境にリリースする場合は、現在のシステムやそれを使用しているユーザーを考慮する必要があるため、できるだけシステムを停止せずにバージョンをリリースする必要があります。

したがって、理論的には、リリース プロセス中は以前の v1 バージョンがまだ存在するため、履歴の v1 バージョンを削除する前に、v2 バージョンが正常に起動されるまで待つ必要があります。

v2 バージョンの起動に失敗した場合、v1 バージョンは何も実行せず、引き続き外部サービスを提供できます。

ローリングアップデート

写真

これが私たちが期待するリリースプロセスです。 Kubernetes でこの機能を使用するのも非常に簡単です。仕様の下にある関連するポリシーのみを構成する必要があります。

 spec: strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate

この構成の意味は次のとおりです。

• ローリング アップデートを使用し、もちろん再作成して古いバージョンの Pod を削除します。基本的にこの戦略は使用しません。
• maxSurge: ローリング アップデート プロセス中に予想される Pod 数を超過できる割合。整数を入力することもできます。
• maxUnavailable: ローリング更新プロセス中に使用できないポッドの数が予想値を超える最大パーセンテージ。

このように、Pod イメージを更新すると、Kubernetes はまず新しいバージョンの Pod を作成し、それが正常に起動するのを待ってから、残りの Pod を徐々に更新します。

写真

正常なシャットダウン

ローリング アップグレード プロセス中は、古い Pod を停止する必要があるため、エレガントなシャットダウンの問題は避けられません。

現時点では、次の 2 つの状況に注意する必要があります。

• シャットダウン プロセス中、Pod に入ったリクエストは、終了する前に完了まで実行する必要があります。
• シャットダウン後は、シャットダウンしたポッドにリクエストをルーティングできなくなります。

最初の疑問は、Go を使用している場合、フックを使用して kubernetes から送信される終了信号をリッスンできるかどうかです。

 quit := make(chan os.Signal) signal.Notify(quit, syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGPIPE) go func() { <-quit log.Printf("quit signal received, exit \n") os.Exit(0) }()

ここで対応するリソースの解放が実行されます。

Spring Boot を使用している場合は、対応する構成もあります。

 server: shutdown: "graceful" spring: lifecycle: timeout-per-shutdown-phase: "20s"

アプリケーションが終了信号を受信すると、Spring Boot は新しいリクエストを受け入れなくなり、既存のリクエストが処理されるまで待機します。

ただし、Kubernetes はアプリケーションが Pod タスクを完了するまで無期限に待機することはありません。ポッドで設定できます

terminationGracePeriodSeconds: 30

待機時間を定義するには、30 秒を超えると Pod が強制的に終了されるようにします。

実際の状況に応じて具体的な値を設定できます

spec: containers: - name: example-container image: example-image lifecycle: preStop: exec: command: ["sh", "-c", "sleep 10"]

同時に、preStop をスリープ状態に設定して、削除する Pod が Iptable で更新された後に Kubernetes が Pod を削除するようにすることもできます。

これにより、削除されたポッドにまだリクエストがルーティングされているという 2 番目の状況を回避できます。詳細については、Spring Boot のドキュメントを参照してください。

https://docs.spring.io/spring-boot/docs/2.4.4/reference/htmlsingle/#cloud-deployment-kubernetes-container-lifecycle

ロールバック

ロールバックは実際には一種のアップグレードと見なすことができますが、アップグレードは過去のバージョンへのアップグレードです。 Kubernetes でアプリケーションをロールバックするのは非常に簡単です。

 # 回滚到上一个版本k rollout undo deployment/abc # 回滚到指定版本k rollout undo daemonset/abc --to-revisinotallow=3

同時に、Kubernetes はロールバックも保証できます。

グレースフルリスタート

Kubernetes Pod を正常に再起動する方法に関する前回の記事では、Pod を正常に再起動したい場合は、rollout コマンドを使用してローリング再起動を確実に実行できることを説明しました。

 k rollout restart deployment/nginx

Kubernetes のローリング アップデートは、従来の運用やメンテナンスよりもはるかに簡単です。以前は、いくつかのコマンドを実装するために、複雑な操作および保守スクリプトを作成する必要がありました。