弊社の運用中の Kubernetes クラスターでは、1 ～ 5 分間の停止が定期的に発生しています。トラブルシューティングを試みていますが、さまざまな情報や知識のギャップに遭遇しており、ご協力いただければ幸いです。
当社のカスタム コードとソフトウェアはすべて高可用性を備えており、少なくとも 2 つのレプリカに展開されており、負荷をかけた状態で高可用性がテストされています。
Kubernetes クラスターはスポット インスタンスを実行しており、そのスポット インスタンスにポッドのみが含まれている場合、停止することなくスムーズに実行され続けます。ただし、そのスポット インスタンスにポッドが含まれているノードが実行される場合kube-dns、停止が発生する傾向がありますが、常に発生するわけではありません。
GKE で 1.25 を実行しているため、使用が制限されていますkube-dns。3 つのノードごとに 1 つのレプリカを実行していますkube-dns(通常は 9 つのノードを実行しています)。そしてkube-dnsconfigmapで最低3ノードを指定しましたkube-dns-autoscaler。また、さまざまな理由からIstio 1.17.1を実行していますが、ないmTLS の場合。中断を 1 回だけ許可する PDB もありますkube-dns。
確認したところ、ほとんどのサービスが互いのリクエストでタイムアウトし始め (istio-proxyアクセス ログにはエラーが記録される傾向があります504 UT)、一部のサービスでは実際にEAI_AGAINエラーが記録され、DNS がタイムアウトしたことを示しています。また、サービス名の組み合わせとサービスの IP アドレスを直接 ping する別のアプリケーションも実行しています (トラブルシューティングの目的でこれを開始)。エラーが発生しているときに、IP アドレスの ping は成功しますが、サービス名のリクエストは成功しないことがわかります。これは、問題に関連していることEAI_AGAINをさらに示しています。kube-dns
また、サイドカーを持つポッドと持たないポッドに対してサービス対IPのpingをチェックしたところistio-proxy、同じ動作が見られ、問題がないによりistio。
私たちが考え始めている唯一のことは、 を実装して、NodeLocal DNSCacheすべてのノードに DNS キャッシュを持たせ、断続的なkube-dns問題を回避できるようにすることです。ただし、これが役立つかどうかはわかりませんし、より大きな問題を隠してしまうのではないかと心配しています。
非本番環境でも同じ問題が発生しているのが確認できますが、まだどこでも再現できていません。これはただ起こるだけです。ノードを再起動/削除しても、この問題は発生しないようです。
kube-dnsまた、GKE がデプロイメント リソースをロックダウンし、ログ レベルを元に戻しているため、ログ レベルを上げることもできません...
この問題をさらにトラブルシューティングして解決する方法についてアドバイスをいただければ幸いです。ありがとうございます