Kubernetes プローブの落とし穴

[[342084]]

この記事はWeChatの公開アカウント「Dotnet Plus」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合はDotnet Plus公式アカウントまでご連絡ください。

1. 不条理

過去 1 ～ 2 か月間、本番環境の K8s クラスターでは、短期間の 503 Service Temporarily Unavailable が頻繁に発生しており、積極的に再現することはできません。これはかなり憂鬱でストレスがたまります。

HTTP 5xx 応答ステータス コードは、サーバー側のエラーを定義するために使用されます。

• 500 内部サーバー エラー: 要求されたサーバーで予期しない状況が発生したため、要求を処理できませんでした。これは通常、単一のリクエストに対して行われますが、サイト全体が引き続き処理される場合もあります。
• 502 Bad Gateway エラーは、接続リンク内のサーバーがオフラインまたは利用できないことを示します。
• 503 サービスは利用できませんは、アプリケーションをホストしている実際の Web サーバーに問題があることを意味します。

2. トラブルシューティング記録

• 基本的に2～3日に1回表示され、1回あたり2～3分間続きます。現時点では駅全体は503です。
• 問題を積極的に再現することができなかったため、8 月 26 日に、該当期間の EFK ログ (Impala 接続の問題) を確認しました。ビッグ データの運用と保守を担当する同僚は、Web アプリケーションから Impala に対して開始された要求が Impala クラスターのクロックと一致しておらず、Web アプリケーション ImpalaODBC ドライバーが Impala クラスターに接続できないことを発見しました。

k8s クラスター ノードに入ると、確かに一部のノードのクロック調整サービスが開始されておらず、北京時間よりも 2 ～ 3 分遅れていることが時々わかります。これは確かに、時間差によって Impala 接続認証が失敗する原因を説明できます。

• 8月26日に、すべてのk8sノードのクロックが同期されました。ほぼ1週間経っても問題は発生しませんでした。
• 9月3日、再び503系統の短期間の運行停止が発生しました。 EFK ログには、依然として Impala 接続の問題であることが示されていました。ここのビッグデータの同僚たちは具体的な原因を突き止めることができず、一時的に散発的/ジッターと定義しましたか?
  

3. 思考と推論

障害サイトで Impala 接続の問題が発生するたびに、Impala 接続の問題によって Web アプリケーション サービスがオフラインになる理由がわかりません。

当社のウェブアプリには、toB と toC の両方のビジネスがあります。このサイトは mongodb に大きく依存しており、impala への依存度は低いです。impala が接続できない場合でも、それをチェックできないだけで、サイトの SSO + 注文関連の書き込み操作は引き続き利用できるはずです。

数日前に見たk8sプローブを思い出すと、準備プローブがImpalaを検出したようです。

 // ASP.NetCore で公開される検出ロジック: impala && mongodb
サービス.AddHealthChecks()
       .AddCheck<ImpalaHealthCheck>(nameof(ImpalaHealthCheck)、タグ: new[] { "readyz" })
       .AddCheck<MongoHealthCheck>(nameof(MongoHealthCheck)、タグ: new[] { "readyz" }); 
        
 app.UseHealthChecks( "/readyz" 、新しいHealthCheckOptions
  {
      述語 = ( check ) => check .Tags. （ 「readyz」 ）を含む
  });

準備プローブが Impala の検出に 3 回失敗すると、Pod は Unready としてマークされ、Pod は webapp サービス ロード バランサーから削除されてトラフィックを分散しなくなり、nginx に実用的なバックエンド サービスがなくなり、サイト 503 になる可能性が高くなります。

すぐにベータ環境を見つけ、Impala を切断して仮説を検証します。

4. 問題のレビュー

バグ修正は私が推測したものではなく、純粋に経験に基づいて推測されたものです。はっきりとした推理のアイディアはありませんが、誰もが落とし穴に足を踏み入れる早期警告とみなすことができます。

Docker のヘルスチェックは検出のみ可能ですが、Kubernetes の生存プローブと準備プローブには検出機能だけでなく意思決定機能もあります。

ここで、k8s 準備状況検出戦略に問題があります。

webapp の impala への弱い依存関係に問題があることが検出された場合、webapp サービス全体がオフラインになります。強い依存関係のみを検出する必要があります。強い依存関係の問題は、コンテナの準備ができていないことを示しており、これは準備状況プローブの本来の目的でもあります。