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」 ）を含む
  });