Kubernetes プローブから DevOps へ

今日、グループ内で、Kubernetes プローブの設定方法を尋ねる人がいました。付け加えるべきことが多すぎると感じました。いくつかの DevOps プロジェクトでの苦い経験を​​組み合わせて、今日はそれらをすべて一気に終わらせます。さらに、DevOps がなぜ難しいのかも説明します。

プローブの役割

機能的に言​​えば、プローブの役割は非常に単純です。以前、多くの人が明確に理解していないいくつかの概念を明確にする記事を投稿しました。この記事は運用と開発の両方に理解してもらえるようにしたいので、できるだけ簡単に表現するように努めます。

プローブ機能は、アプリケーションが正常に動作しているかどうかを検出するために Kubernetes が提供するチェック メカニズムです。最も一般的な検出方法は HTTP 検出です。アプリケーションはアドレスを公開する必要があります。 Kubernetes は定期的にアドレスを呼び出します。アドレスが 200 ステータス コードを返す場合、アプリケーションは正常であると見なされます。それ以外の場合、アプリケーションは異常であると見なされます。

通常、アプリケーションには、活性プローブと準備プローブの 2 つのプローブを構成する必要があります。生存プローブは、アプリケーションに問題がある場合に再起動をトリガーすることができ、再起動後にアプリケーションが通常の状態に戻ることができる場合があります。準備プローブは、アプリケーションに問題がある場合、トラフィックが遮断され、アプリケーションが呼び出されないようにします。

写真

機能面からのみ見ると、両者の間にはほとんど違いはなく、同じアプリケーション インターフェイスを構成することに問題はないと思われるので、なぜ 2 つの異なるプローブを設定する必要があるのでしょうか。 Kubernetes の開発者が合理的であると「仮定」すると、そこには理由があるはずです。この理由については後で詳しく説明します。まず、運用と保守が直面する問題を見てみましょう。

マクロ経済的意義

運用保守に携わっている友人、特にマイクロサービスアプリケーションの運用保守に携わったことがある人は、基本コンポーネントや上流サービスの障害を見たことがあるのではないでしょうか。可観測性が「良好」であれば、画面が赤い感嘆符でいっぱいになるかもしれません。 「リリース！『安定した分散システムの設計と展開』という本では、この安定性のアンチパターンを「カスケード効果」と呼んでいます。

カスケード効果を生み出すプロセスを次の図に示します。

写真

上流の Pod が利用できない場合、下流の Pod も動作しなくなり、関連するすべての Pod に影響が広がります。

この時点で、可観測性ツールが一度にすべてのエラーを吐き出した場合、運用保守担当者は間違いなく非常に絶望し、特定の Pod 自体に問題があり、他の Pod は依存する Pod の問題のためにエラーを報告していることを知らせてくれるツールがあることを願うでしょう。こうすることで、重要な問題の解決に集中できます。

さらに、このような連鎖的な障害からの回復は、スムーズに進まないことがよくあります。個々のビジネス上の問題が引き続き発生する可能性があり、場合によっては、運用および保守担当者が手動でサービスを再起動する必要があります。彼は、条件が満たされたときにアプリケーションが自動的に回復できることを期待していたに違いありません。

はい、これら 2 つのニーズに対する解決策がプローブです。

プローブの仕組み

これら 2 つのプローブは、Kubernetes プラットフォームとアプリケーション間の通信契約です。エラーが返された場合、アプリケーションは実際には次のことを意味し、次のことを約束します。

• 生存調査：もう無理です。もう一度試してください。それでもうまくいかない場合は、私を殺して再起動してください。
• 準備状況調査: 現在、外部サービスを提供できません。リクエストを転送しないでください。私が頼りにしているサービスに何か問題があるのか​​もしれません。依存するサービスが回復すれば、私も回復できるはずです。

この観点から見ると、2 つのプローブには明確な違いがあります。これら 2 つのプローブは、アプリケーションと連携して、前の章で説明した問題をどのように解決するのでしょうか。

まず、アプリケーションが完全にハングしている状況について説明します。このとき、生存プローブと準備プローブの両方が異常を検出し、確実に再起動をトリガーします。この場合、アプリケーション内で何らかの仮定を行う方法はありません。これは、プローブ メカニズムが効果を発揮する最も直接的な状況です。

アプリケーション自体に問題が発生した場合、生存プローブは例外を報告し、再起動をトリガーする必要があります。この時点での重要な疑問は、アプリケーションは例外があることをどのようにして知るのかということです。確かに難しいですね。このプローブに対応するインターフェースは、通常の業務のメインロジックをシミュレートでき、依存サービスに問題があり、アプリケーションがこの問題に対処できる場合は、例外は報告されません。

アプリケーションが依存するサービスに障害が発生した場合。アプリケーションの活性プローブが正常を報告し、準備プローブが異常を報告するようにします。この時点で、生存プローブは例外を報告し、アプリケーションの再起動をトリガーしますが、タスクの問題を解決することはできません。代わりに、再起動や関連するエラーが大量に発生し、運用および保守担当者がパニックに陥ることになります。プローブがこのように機能するには、依存するサービスが回復したときにアプリケーションも自身を回復できるという非常に重要な前提条件があります。アプリケーションが自動的に回復できない場合は、おそらくこの時点では生存プローブに例外を報告させることしか選択できず、運用と保守は再起動を繰り返すという終わりのないパニックに直面することになります。

ここでの問題は開発だ

原理は理解できましたが、どうやって解決するのでしょうか？運用と保守に非常に重要な機能は、開発者によって完了される必要があります。まず、開発者はこの記事を書く目的の一つである上記のプロセスを理解し、それを実装する必要があります。

Spring などの開発フレームワークではすでにプローブ関連の機能が提供されており、設定だけで開発が完了する場合もありますが、実際の状況はそれほど単純ではないことがよくあります。たとえば、Spring のドキュメントには次のように書かれています。

「生存性」プローブは外部システムのヘルスチェックに依存してはなりません。

これは、活性プローブが外部システムの状態に依存しないことを意味します。しかし、現実には、この外部システムの定義はそれほど明確ではないかもしれません。外部システムの障害からアプリケーションが回復できない可能性もあります。そのため、外部システムであっても、ライブネスプローブのチェック対象に含める場合があります。

また、これを一度でうまく行うことは難しい可能性が高く、実際に発生する問題に基づいて調整を行う必要があります。開発者が運用保守に参加していなかったり、開発者間のコミュニケーションが円滑でなかったり、開発者がこれを自分の業務として捉えていなかったりすると、プローブの問題は簡単には解決できない可能性があります。

実際、グループ内の人々はプローブのパラメータについて質問していますが、実際にはこれらのパラメータは障害をどれだけ早く発見できるかを制御するだけです。適用したプローブ自体に問題がある場合、これらのパラメータをどれだけ高度に設定しても意味がありません。これは多くのチームの業務状況だと思います。私たちは、自分の部門だけで処理できる事柄については、他のチームに頼らないようにしています。たとえば、どのポッドに問題があるかを直接教えてくれる可観測性ツールが見つかるなら、なぜ開発者を探す必要があるのでしょうか?

現実はどうでしょうか?それは難しすぎる。すべての病気を治せるツールを作るのは難しすぎます。しかし、多くの人々の選択に基づいて、これは開発と運用を効果的に連携させるよりも簡単かもしれない、あるいは少なくともそれほど必死ではないかもしれないことがわかっています。

この記事を例として挙げたいと思います。皆がお互いを理解し、DevOps 精神を維持できることを願っています。上級リーダーもこの問題を認識し、解決方法を検討することができます。次に、プラットフォーム エンジニアリングを検討して、開発者がこの問題にもっと簡単に対処できる優れたプラットフォームを構築できるかどうかを確認する必要があります。結局のところ、私たちは自分たちが書いたプログラムを最もよく知っています。

参照する

• [1] 連鎖反応と連鎖的障害：https://www.bilibili.com/video/BV13Q4y1K7FU/
• [2] 2.9.2.アプリケーション ライフサイクルとプローブの状態: https://docs.spring.io/spring-boot/docs/2.4.1/reference/html/production-ready-features.html#production-ready-kubernetes-probes-external-state
• [3] スケーリングにおけるプローブの重要性といくつかのパラメータの説明 https://yylives.cc/2023/02/25/kubernetes-probes-and-why-they-matter-for-autoscaling/