Alibaba では、ユーザーよりも先に Kubernetes クラスターの問題を発見して特定するにはどうすればよいでしょうか?

問題を素早く発見して特定する能力は、迅速なシステム回復の基礎となります。問題を迅速に発見して特定することによってのみ、問題を解決し、ユーザーの損失を最小限に抑える方法について話し合うことができます。では、複雑で大規模なシナリオにおいて、ユーザーよりも先に問題を発見し、特定するにはどうすればよいでしょうか?大規模な経営における私たちの経験を共有しますクベネフィットこの記事では、クラスタープロセスで問題を迅速に検出して特定する方法について、いくつかの経験と実践を紹介します。独自に開発した一般的なリンク検出 + 方向検査ツール KubeProbe を使用して、大規模クラスターの安定性の課題に対処する方法について説明します。

リンク検出: 一般的なユーザー行動をシミュレートして、リンクやシステムが異常かどうかを検出する

方向検出: クラスター異常指標をチェックして、現在または将来存在する可能性のあるリスクポイントを見つけます。

システム強化: 問題を発見し、効率を高め、根本原因を分析する

問題を発見した後: 事後チェックと自己修復、チャットオペレーション

01事業背景と課題

クラウドネイティブ

Alibaba Cloud のクラウドネイティブアプリケーションプラットフォームのコンテナサービスチームは、ACK や ASI などの製品を所有し、大規模な Kubernetes クラスターを管理しています。同社は、外部のパブリッククラウドユーザーにKubernetesサービスを提供するだけでなく、アリババグループのクラウド移行やアリババアプリケーションの包括的なコンテナ化の作業も請け負っています。

現在、Tmall/Taobao/Amap/Kaola/Ele.meなど、AlibabaのすべてのビジネスはKubernetesクラスター上で実行され、クラウドネイティブとコンテナ化を実装しています。コンテナサービスは、Alibaba Cloudの管理および制御の基盤です。これらのクラスターでは、Video Cloud/DataWorks/MSE Microservice Engine/MQ Message Queue など、さまざまなクラウドサービスも実行されます。このインフラストラクチャの安定性については、私たちが責任を負う必要があります。

最近では、クラウドネイティブアーキテクチャがますます普及しており、ますます多くの製品やアプリケーションがクラウドネイティブアーキテクチャを選択し始めています。以下は、最新のクラウドネイティブアプリケーションアーキテクチャを大まかに示した図です。アプリケーションはクラウド上で生まれ、成長し、あらゆるレベルで階層化されたサービスが提供されます。この階層化サービスにより、企業やアプリケーションはビジネス層に集中し、プラットフォーム層やインフラストラクチャ層の複雑な概念を意識する必要がなくなります。

安定性の観点から見ると、この種のアプリケーションのアーキテクチャは階層化されており、上位層アプリケーションの安定性は、基盤となるインフラストラクチャのサポートに依存するようになります。さらに、統合ベースは、大規模なリソーススケジューリングの最適化とオフラインコロケーションのシナリオを提供するだけでなく、大規模クラスターの安定性を維持する上でインフラストラクチャチームに大きな課題をもたらします。

以下に、クラウドネイティブアプリケーションアーキテクチャにおけるビジネスアプリケーションとプラットフォームインフラストラクチャの関係を示す 2 つの鮮明な図を示します。 Kubernetes クラスターは非常に複雑です。大規模なマルチクラスタークラスターは言うまでもなく、単一のクラスターには数十または数百のリンクコンポーネントが含まれます。クラスター管理はどうですか? しかし、上位層で実行しているビジネスクラスメイト感じない複雑さはパッケージ化されており、ユーザーにはシンプルで統一されたインターフェースが残されています。。ちょうどタオバオこのようなアプリケーションは実際には非常に複雑ですが、ユーザービュー来るだけこれは単純な注文送信ですが、ボタンには非常に複雑な内容です。なぜこれをするのですか? なぜなら、複雑さは自分たちに任せ、シンプルさはユーザーに任せるからです。家庭。

多くの場合、優れたアプリケーション開発者は必ずしもインフラストラクチャの専門家ではありません。クラウドネイティブにより、ビジネスはビジネスに集中でき、インフラストラクチャはインフラストラクチャに集中できるようになります。同時に、ほとんどの場合、企業はビジネス自体の安定性のみを気にすることができます。企業にはインフラストラクチャとプラットフォーム層の安定性を気にかける能力がないか、または気にかけるために多くの人的資源を投資したくない。したがって、プラットフォーム層とインフラストラクチャの安定性に関しては、複雑さを自分たちに任せ、単純さをユーザーに任せ、安定したプラットフォーム層のサービスをユーザーに提供する必要があります。同時に、私たちは単一ポイントの可用性よりも、グローバルな安定性とグローバルな可用性を重視しています。

コンテナサービスは、アリババグループのビジネスとアリババクラウドの管理・制御/クラウドサービスの基盤です。電子商取引事業/ミドルウェア/セカンドパーティ事業/検索/Alibaba Cloudサービスなど、多様な事業を展開しています。また、自社開発およびオープンソースのコンポーネントが数百あり、年間のコンポーネント変更は数十万件/クラスターは数千件/ノードは数十万件、さらには単一クラスターに1万ノード以上を擁する大規模クラスターもあります。ビジネスアーキテクチャはさらに複雑で、シングルテナントクラスター、マルチテナントクラスター、vc クラスター、フェデレーションクラスターなどのほか、さまざまなオフライン混合展開、統合スケジュール、プロモーション活動などがあります。実行時には、runC、runD など複数の形式もあります。

したがって、コンポーネントの複雑さ、頻繁な変更、さまざまなユーザーシナリオ、大規模なクラスタースケール、複雑なビジネスアーキテクチャはすべて、ビジネスに課題をもたらします。

課題 1: システムリスクをどのように軽減するか。シナリオは複雑であり、ビジネス形態は多様です。重要でない詳細を省略したり、リンクを不注意に扱うと、被害が拡大する可能性があります。

課題 2: ユーザークラスターの安定性をどのように管理するか。ユーザーよりも先に問題を発見して特定する方法は、コンテナサービスの安定した運用を構築するための最優先事項であり、グローバルな高可用性システムの基礎となります。

システムは非常に複雑なので、些細な詳細を省略したり不注意に扱ったりすると、予期せぬ損害が発生する可能性があります。システムリスクを減らすにはどうすればよいでしょうか?さらに、運用中のさまざまな形式のユーザークラスターのグローバルな安定性に対して、どのように責任を負っているのでしょうか。ユーザーよりも先にこれらのクラスター内の既存または差し迫った問題を発見して特定する方法は、クラスターの安定性を確保するための最優先事項であり、Kubernetes グローバル高可用性システムの基礎でもあります。

02考え、計画する

クラウドネイティブ

これらの課題に基づいて、私たちはいくつかの考えと仮定を立てました。次の図は、ユーザーリリース拡張リンクを極端に簡略化したものです。非常に単純化されていますが、リンクが比較的複雑であることがわかります。

ユーザーのスムーズな拡張/リリースを確実にするために、まずいくつかのプリセットを導入します。

プリセット1: リンクは複雑で、多くのコンポーネントがあります。各コンポーネントは個別にアップグレードおよび反復されるため、データ監視では死角なくすべてのシナリオをカバーすることはできません。

プリセット2: リンク内の各コンポーネント/ノードの監視データが正常であっても、クラスターリンク全体が 100% 利用可能であることを保証することはできません。実際のビジネスの完全なリンク検出後にのみ、実際の可用性を判断できます。

プリセット3: クラスターが使用できないことを証明する場合、背理法による証明は参照法による証明よりも確実に優れています。監視データが 100% 正常であっても、リリースが失敗する限り、リンクがブロックされていることがわかります。

単一のクラスターに加えて、複数のクラスターの管理にも注意を払う必要があります。マルチクラスタ管理における不安定要因の例を以下に示します。マルチクラスターのシナリオでは、安定性管理の複雑さが増大することがわかります。他にもプリセットがいくつかあります:

プリセット4: 大規模なクラスターシナリオでは、データの一貫性の問題がより顕著になり、重大な障害を引き起こす可能性があり、大きな不安定要因になります。

プリセット5: クラスター内の監視およびアラームリンクには、自己依存のリスクがあります。クラスターに障害が発生すると、監視とアラームも同時に失敗する可能性があります。

次に、上記の仮定に基づいたいくつかのソリューションを示します。

探索と解決策

1. リンク検出

リンク検出は、広義の意味でユーザーの行動をシミュレートし、リンクが妨げられていないかどうか、プロセスに異常がないかどうかを検出します。

ユーザーより先にシステムの問題を発見したいのであれば、まずは私たち自身がシステムのユーザーになり、システムを最も多く使用し、最も理解し、常にシステムの状態を把握して使用しているユーザーになる必要があります。

いわゆるリンク検出とは、クラスタ構成リンク内で検出を待機しているさまざまなオブジェクトを検出するために、広義のユーザ動作をシミュレートすることです。ここで注意すべきことは、ここでの利用者とは、狭義のシステムを利用する学生のみを指すのではなく、より広義の利用者、あるいは下流の従属者として理解・拡張できるものである。

また、フルリンク検出を実現すると同時に、回路を分解して回路全体で短絡検出を実現することも非常に必要であり、これもフルリンク検出の補足となります。

2. 監督検査

指示検査とは、パイプラインの検査と同様に、大規模クラスターの異常な指標をチェックして分析し、既存または将来のリスクポイントを見つけることを指します。

たとえば、複数のクラスターがあり、それらは多数のクラスターグループに分割されています。異なるクラスターグループ間の etcd コールド/ホットスタンバイが完全に構成されているかどうか、リスク管理と電流制限の構成が正常かどうか、Webhook のバージョンが正常かどうか、証明書の有効期限が切れそうかどうかなど、コロケーションパラメータが一貫しているかどうかなど。異なるクラスターグループ間では違いがあるかもしれませんが、同じタイプのクラスター間ではバランスが取れているため、対象を絞った検査を行うことができます。

リンク検出の一般的なシナリオを次に示します。

ゲームプランナーと同じように、自分が作ったゲームをプレイしなくても、ゲームの仕組みの問題点を見つけて、ゲームをどんどん良くしていくことができるでしょうか?ユーザーより先にシステムの問題を発見したいのであれば、まずは私たち自身がシステムのユーザーになり、システムを最も多く使用し、最も理解し、常にシステムの状態を把握して使用しているユーザーになる必要があります。

また、いわゆるリンク検出とは、自分自身を自分のシステムのユーザーとして捉え、広義の「ユーザー」の行動をシミュレートして、クラスター/コンポーネント/リンク内で検出待ちのさまざまなオブジェクトを検出することです。

ここで注意すべき点は、ここでいう「ユーザー」とは、狭義のシステムを利用する学生のみを指すのではなく、広義のユーザー、あるいは下流に頼る者とも捉えられるということです。

たとえば、ビジネス部門の同僚がビジネスをリリースしたい場合、Git システム、リリースシステム、そして基盤となるインフラストラクチャプラットフォーム (ASI) を経由する必要があります。これは完全なリンク検出プロセスです。ここで、ビジネスクラスメートはユーザーであり、検出対象はリンク全体になります。

しかし、etcd をシステムサービスと見なすと、APIServer は広い意味でそのユーザーとなり、APIServer が etcd を要求するリンクの検出をシミュレートすることは理にかなっています。

さらに、Zookeeper を操作する MSE、Alibaba Cloud コンソールを通じて ACK クラスターを作成する外部ユーザー、フェデレーションクラスターを操作する PaaS プラットフォーム、さらにはトランスコーディングタスクを開始するビデオクラウドビジネスパーティにも同じ原則が適用されます。

もう一つの注意点は、フルリンク検出は見た目は素晴らしいものの、多くの場合、フルリンク検出も非常に長く、失敗する頃には問題が非常に深刻になっている可能性があるということです。したがって、フルリンク検出を実現すると同時に、リンクを解体してフルリンク内でショートリンク検出を実現することも非常に必要であり、これはフルリンク検出の補足でもあります。

上図は、指示検査のシナリオを示しています。リンクの可用性に重点を置いたリンク検出と比較すると、有向検査の中核は依然として大規模なクラスターシナリオにあります。データの一貫性は非常に難しい問題です。一貫性のないデータは、隠れた危険につながり、将来的に不確実な障害を引き起こす可能性があります。

いわゆるターゲット検査とは、クラスター全体またはリンク内のさまざまなデータや指標の既知の原因をチェックし、不一致やデータの逸脱のポイントを見つけ出し、リスクが発生する可能性があるかどうかを判断し、問題が発生する前に防止することです。

たとえば、同じタイプのクラスターがあります。クラスター A の証明書の有効期間は 3 年未満であるのに対し、他のクラスターの証明書の有効期間は 3 年であることがわかりました。クラスター B の Webhook バージョンは v2 である可能性がありますが、他のクラスターの Webhook バージョンは v3 です。クラスター C のリスク制御電流制限構成にはポッド排除の電流制限がありませんが、他のクラスターにはポッド排除の電流制限が設定されており、これは明らかに期待どおりではありません。たとえば、クラスター D の etcd のコールド/ホットスタンバイが構成されていないか、正しく実行されていない場合は、まずこれを確認できます。

03システム実装

クラウドネイティブ

上で述べた多くの背景の仮定と解決策に基づいて、私たちは巡回/検出プラットフォームを設計し、実装しました。このプラットフォームは KubeProbe と名付けられました (オープンソースではなく、コミュニティ内の同様の名前のプロジェクトとは何の関係もありません)。

私たちは初期の段階でコミュニティプロジェクト Kuberhealthy の使用も検討し、Kuberhealthy にいくつかのコード貢献を行い、いくつかの重大なコードバグを修正しました。結局、その機能は私たちのシナリオに適していなかったため、自分たちで開発して構築することを選択しました。

上の図は中央アーキテクチャであり、中央管理および制御システムを備えることになります。ユーザーのユースケースには、統合されたウェアハウスイメージを通じてアクセスし、共通の SDK ライブラリを使用して検査および検出ロジックをカスタマイズします。あるユースケースをどのクラスタグループで実行するかなど、クラスタとユースケースの関係を中央管理・制御システムで設定し、各種ランタイム設定を行います。定期的なトリガー/手動トリガー/イベントトリガー(リリースなど)などのユースケーストリガー方法をサポートしています。ユースケースがトリガーされると、検査/検出ロジックを実行する Pod がクラスター内に作成されます。このポッドは、さまざまなユーザー定義のビジネス検査/検出ロジックを実行し、成功または失敗後に直接コールバック/メッセージキューを介して中央エンドに通知します。センターはアラームとユースケースリソースのクリーンアップを担当します。

例を挙げてみましょう。たとえば、Kubelet は、当社のコンポーネント運用および保守プラットフォーム上でバッチでリリースされます。各バッチは、事後チェックとして関連するクラスターのリンク検出ユースケースをトリガーします。特定のリリースの事後チェックが失敗したことが判明した場合、被害の拡大を防ぐために、ユーザーの現在のリリースをブロックします。同時に、アラームを発し、関係する同僚に通知して、コンポーネントの新しいバージョンが期待を満たしていないかどうかを調査します。

同時に、サードパーティのイベントコールバックもサポートしており、サードパーティのシステムに迅速に統合できます。

さらに、24 時間 7 時間の中断のない動作を必要とする高頻度、短サイクルの検出ユースケース向けに、別の常駐分散アーキテクチャセットも実装しました。このアーキテクチャは、クラスター内の ProbeOperator を使用してプローブ構成 CRD の変更を監視し、検出ポッドで検出ロジックを繰り返し実行します。このアーキテクチャは、KubeProbe センターが提供するアラーム/根本原因分析/リリースブロッキングなどの追加機能を完全に再利用し、標準 Operator のクラウドネイティブアーキテクチャ設計を採用しています。常駐システムにより、検出頻度が大幅に向上します (検査ポッドの作成とデータのクリーニングのオーバーヘッドがなくなるため)。これにより、基本的に 24 時間 365 日、クラスターのシームレスなカバレッジが実現され、外部統合が容易になります。

言及しなければならないもう 1 つの非常に重要な点は、プラットフォームはプラットフォームレベルの機能サポートのみを提供するという点です。これが実際に機能するかどうかは、このプラットフォーム上に構築されたユースケースが充実しているかどうか、そしてより多くの人が参加してさまざまな検査および検出のユースケースを簡単に作成できるかどうかにかかっています。テストプラットフォームは重要ですが、テストケースはテストプラットフォームよりも重要です。一般的なワークロード検出やコンポーネント検出では、管理リンクと制御リンクで多くの問題を発見できますが、ビジネスレイヤーの問題であっても、実際にはインフラストラクチャレイヤーとビジネスレイヤーの同僚の共同作業に依存する問題が多くあります。

私たちの実践からは、テスターとビジネス学生が貢献したACK＆ASK作成と削除のフルリンク検出と検査、カナリアビジネスのフルリンク容量拡張ケース、現地の生活学生が貢献したPaaSプラットフォームアプリケーション検査など、多くの関連検査ケースがテスターとビジネス学生によって貢献され、多くの安定性の結果と利益も得られました。現在、数十の検査/検出ユースケースを維持していますが、来年には 100 を超える可能性があります。検査・摘発件数は3,000万件近くあり、来年には1億件を超える可能性がある。現在、クラスターの管理と制御の問題と隠れた危険性の99％以上を事前に発見することができ、その効果は非常に良好です。

04問題発見後：根本原因分析とインシデント対応

クラウドネイティブ

次に、問題が発見された後に何が起こるかについて話しましょう。これは医療相談の会話に似た例で、患者が「ああ、気分が悪い！」と気づく場面です。 ” そこで問題が発見されます。医師はさまざまな検査報告書を参照し、情報の集約、分析、推論を行った上で、患者に「あなたは24時間眠っていません。眠れないのは不安だからです。不安の根本的な原因は、期末試験が明後日にあることです」と伝えた。これは、問題の根本原因を特定し、その根本原因に基づいて問題を解決することです。彼は患者にこう言った。「心配しないでください。小学生はもう期末試験を受ける必要がないという知らせを受け取ったばかりです。」このプロセスは迅速に実行する必要があります。

検出リンクからのアラームの内容は混乱していることが多く、データ監視アラームとは異なります。前述のように、リンク検出アラームは患者が体調が悪いと感じているというメッセージである可能性があり、医師としてなぜ体調が悪いのかを判断する必要があります。根本的な原因は何ですか。多くの場合、データ監視自体が原因となります。たとえば、Etcd OOM が発生した場合、既存のオンコールエクスペリエンスでは最良の結果が得られない可能性があります。

さらに、問題を素早く特定し、根本原因を分析することは、ツリー状の検索、経験処理、判断、つまり混沌とした外観から根本原因を推測するプロセスです。核となるのは論理です。

これは、検査項目 1、2、3、4、5... を列挙し、一連の数値を通知する健康診断とは異なります。多くの場合、健康診断センターがあったとしても、あなたの状態を解釈し判断するためには、病院の専門の医師が必要ですよね?

同時に、根本原因分析/問題の自己修復の鍵は、専門家の経験を沈めること、つまり専門家の経験をシステムに沈めることにあります。専門家の経験を蓄積することで得られる最大のメリットは、それを再利用してエクスポートできることです。最も専門的な医師の能力をシステムに組み込めば、医師が各人の状態を分析するのがより便利になるのではないかと想像できます。

これは、KubeProbe が問題を発見した後の全体のプロセスです。まず、独自に構築した集中型の根本原因分析システムを使用して、イベント/ログ/変更/アラーム/コンポーネントのアップグレードなど、障害に関連するすべての情報を集約して分析します。この情報を集約して分析し、イベントを相関させます。最後に、ツリーのような分析システムを通じて、APIServer のタイムアウトや etcd の切断など、特定の検出失敗の原因を事前に特定できます。

さらに、テキストの関連付けも根本原因を分析するのに適した方法であることを付け加えておきます。機械学習を使用してテキスト認識をトレーニングし、この障害事例に最も関連のある根本原因を関連付けることができます。私たちはこのタイプの AIOps 作業について少し触れただけで、現在も継続的に調査中です。私たちのデータ量は非常に大きく、これが将来の方向性の一つになるはずだと信じています。

KubeProbe 根本原因分析と後処理の完全なプロセス

上の写真の左下には障害の警告が表示されています。根本原因分析システムの結果、最も根本的かつ関連性の高い原因は、API サーバーの接続が切断され、それが回復したことである可能性があることが判明しました。したがって、これは単に時折発生するネットワークジッタである可能性があります。今のところ特に注意する必要はありませんが、信頼度が 90% であることがわかります。

関連する他の理由もいくつか考えられます。たとえば、特定のコンポーネントの場合、この検出は特定のコンポーネントリリースによって開始され、その発行者は XXX です。このリリースが API サーバーに何らかの影響を与えるかどうか、複数のリスト監視が期待どおりに機能しないかどうか、そして API サーバーリスト監視に問題があるかどうかを、信頼度レベル 50% で観察できます。

予備的な理由を受け取った後、二次確認システムに入り、理由の二次確認を行います。たとえば、APIServer のタイムアウト/etcd の切断/ノードのタイムアウトが原因であると判断された場合、APIServer インターフェースを自動的に再プルして、まだタイムアウトになっているかどうか、回復したかどうかを確認します。回復した場合は、通常のアラームを発し、現在はすべて正常だが注意が必要であることをユーザーに伝えます。回復しない場合は、非常に深刻であり、最優先事項となります。すぐに警察に電話してください。

これがそのアイデアです。システムが特定できない問題があり、引き続き特定できない場合は、高レベルのアラームをトリガーし、関連する根本原因分析識別ツリーロジックを追加します。

アラートが多すぎると、アラートがまったくないのと同じです。私はアラートの海が一番嫌いです。経験上、このような根本原因分析 + 二次確認 + 事後検査システムを構築した後、オンコールコストは 90% 以上削減され、今後も削減し続ける可能性があります。最終状態は無人状態と言えます。同様の作業を試すこともできます。投資額は少なく、効果は大きいと言えます。これらのシステムが構築されて以来、私たちはすべてのアラーム項目（そうです、すべてのアラーム、数千のクラスター、数千万の検出検査）をほとんど労力をかけずにオンコールし、何も見逃していないと誇らしく言うことができます。

最後に、オンコールスタッフのチャットオペレーションに甘いお菓子をプレゼントします。

NLP意味認識に基づくチャットオペレーションシステム

DingTalk が提供する NLP ロボットを使用して、比較的完全なチャットオペレーションシステムを構築しました。これにより、オンコール担当者は、アラームグループでのチャットを通じて、失敗した検出の再実行、クラスターステータスの照会、診断情報の取得、検出ログの照会、クラスターアラームの消音など、KubeProbe 関連の機能を簡単に操作できるようになりました。

上の写真は、当社の Chat-ops システムの運用プロセスを示しています。このプロセスは非常に便利です。

例えば、夜、すでに就寝していたときに、クラスターが以前に障害を起こしたが現在は回復したので注意が必要であるなどのアラームが表示されました。

注意を払うようになったので、一般的なユースケースをもう一度実行したいと思います（1時間など、長い時間がかかる場合があります）。短縮リンクのユースケースはいつでも実行されている可能性があるため、ロボットに再度実行するように指示します。ロボットは私のセマンティクスを認識し、クラスターを再度実行します。実行後、クラスターのステータスを確認できます。これはとても便利です。夜間に仕事中、外出中、またはベッドにいるときに、システムを快適にオンコールできる場合があります。