[調査結果の詳細で質問が書き直されました。]
1日に約100,000回のAPI呼び出しを実行する約100個のコンテナーでGoogleContainerEngineクラスターを実行しています。一部のポッドでは、DNS解決で50%の障害が発生し始めました。これを掘り下げたところ、kube-dns
を実行しているノード上のポッドでのみ発生します。また、これは、システム内のノードがメモリ不足のためにシャットダウンされる直前にのみ発生することにも気づきました。
バックグラウンドのresqueジョブは、Google APIにアタッチしてから、S3にデータをアップロードしています。失敗したジョブを見ると、「名前解決の一時的な失敗」で失敗します。これは、「accounts.google.com」と「s3.amazonaws.com」で発生します。
サーバーにログインし、Host
、nslookup
、またはDig
を使用してこれら(または他のホスト)に接続しようとすると、問題なく動作しているようです。 Railsコンソールに接続し、キューで失敗しているのと同じコードを実行すると、失敗することはありません。ただし、前述したように、これらのバックグラウンド障害は断続的であるようです(約kube-dns
を実行しているノードで実行されているワーカーの時間の50%。
これまでのところ、私の暫定的な修正は、失敗していたポッドを削除し、kubernetesに再スケジュールさせ、kubernetesがkube-dns
を実行していないノードにポッドをスケジュールするまでこれを続けることでした。
ちなみに、障害のあるノードを削除しても、これは解決されませんでした。 kubernetesがすべてを他のノードに移動し、問題を移動させただけです。
Kubernetes1.4にアップグレードすることでこれを解決しました。
1.4リリースには、メモリ不足の状態でkubernetesがクラッシュしないようにするためのいくつかの修正が含まれていました。コアの問題が修正されたとは確信していませんが、これはこの問題が発生する可能性を減らすのに役立ったと思います(問題がkube-dns
ノードがOOMにヒットしたときに、kubernetesシステムが不安定なため、インスタンスがクラッシュまたは応答しなくなりました。