※当ブログではアフィリエイト広告を利用しています
Azure上のUbuntuでKubernetesクラスターを構築していたのですが、kube-dnsのCPU使用率が異常に高騰しハマったのでメモ。
目次
CPU使用率がおかしい
Kubernetesの導入は問題なく完了したのですが、ノードのCPU使用率が異常に高かった。
おかしいと思い kubectl top pod した結果・・・
$ kubectl top po
NAME CPU(cores) MEMORY(bytes)Mi
kube-dns-sh28a 21248m XXMi
いったい何が起こっているんだ・・・
127.0.0.53 って何?
ログを見てみると、外部の名前解決に失敗しているログがずっと出ており、恐らくこれが原因っぽかった。
kube-dnsの初期設定では、外部ホスト名の名前解決にはホストとなるノードの /etc/resolv.conf を見て名前解決を試みる。
そこでホストの/etc/resolv.conf をみると、「127.0.0.53」という謎のアドレスが。
調べてみると、Ubuntuでは名前解決を行う「systemd-resolve」というサービスが稼働しており、このサービスのなかに定義されているDNSへ問い合わせに行くみたいです。
https://linuxfan.info/ubuntu-1804-resolve-status
当然kube-dnsが稼働しているPodではsystemd-resolveは動いていないので、127.0.0.53に問い合わせても「そんなサーバーない!」となってしまいます。何度失敗してもひたすら「127.0.0.53」へ接続を試みるため、無限ループのような状態に陥ってしまい、CPU使用率が100%近くになっていたということですね。
対応方法
以前書いた記事を参考に、kube-dnsのConfigMapを編集し、別のDNSを指定します。
今回は外部DNSとしてAzureが使うDNSである168.63.129.16を指定してみました。Podを削除して即反映させたところ、リソース使用量が劇的に減りました。
https://blogs.technet.microsoft.com/jpaztech/2016/04/01/about-168-63-129-16/
まとめ
Azureと言わず、UbuntuでKubernetes構築する際にはありがちな問題そうですね。
Kubernetes導入直後でも、kubectl top pod もしくは kubectl top node を使ってリソース使用状況を確認するようにしましょう。
※超軽量Kubernetesのk3sではheapsterが入っていないため、kubectl topは使えません