自宅の検証環境に AKS on Azure Stack HCI の k8s の v1.21.x 系を展開した際に名前解決でハマった件について、記録を残しておきたいと思います。
解決ができているわけではないのですが、このようなことも起きるんだなということで現状の調査結果をまとめておこうかと。
v1.20.x 系では発生せず、v1.21.x 系の k8s を展開した際に発生していて、Kubernetes 力が低いこともあり、原因を把握するのにかなり手間がかかりました…。
SR でサポートの方とやり取りをさせていただいた中で、ログの取得方法等も連携いただいたのでその辺も含めてまとめておきたいと思います。
なお、本現象はうちの環境特有で標準的な環境では発生しないと思います。
Contents
DNS の構成
今回使用している環境ですが、DNS の設定が次のようになっています。
- 10.255.255.254 : 検証環境のルーター -> 192.168.0.1 : 末端のルーター
- 10.255.255.254 は、192.168.0.1 を DNS サーバーとして指定してあり、DNS のフォワーダーのような役割として利用
192.168.0.0/24 がプロバイダーの接続に使用しているルーターのセグメントとなっており、10.0.0.0/8 が検証環境のセグメントとなっています。
192.168.0.0/24 と 10.0.0.0/8 を 10.255.255.254 のルーターでつないでいるというような環境となっています。
このような環境の DNS を使用している場合、AKS on Azure Stack HCI で CoreDNS による名前解決が正常に実施することができないという事象が発生しました。
発生していた問題
当初は、AKS on Azure Stack HCI のワークロードクラスターを構築している際には気づかず、Azure Arc Enabled Kubernetes の登録をしようとすると、「azure-arc」の名前空間の中の、いくつかの Pod が起動せず、Enabled k8s の登録を完了することができないというような現象としてとらえていました。
サポートの方とやり取りをする中で、「ワークロードクラスターが参照する DNS を 10.255.255.254 から他の DNS に変更 (例 : 192.168.0.1 or 8.8.8.8)」することで、登録が完了するということが確認でき、参照している DNS によって何らかの問題が発生している可能性が考えられるということまでは分かったのですが、そこから先の対応をどうしようか悩みながらログの確認を行っていました。
成功するパターンと失敗するパターンのログを確認していたところ「azure-arc の clusteridentityoperator の Pod のログ」に次のエラーが出力されていました。
{"Message":"Error: in the HTTP get error : {failed to get regional uri with error: {Get \"https://gbl.his.arc.azure.com/discovery?location=eastus\u0026api-version=1.0-preview\": dial tcp: lookup gbl.his.arc.azure.com on 10.96.0.10:53: server misbehaving}}"
正常に終了している場合は次のようなメッセージが出力されます。
"Message":"URL:\u003e https://eus.his.arc.azure.com"
10.96.0.10 は CoreDNS へのアクセスに使用されているサービスとなります。
ワークロードクラスターに SSH で接続して、「nslookup gbl.his.arc.azure.com -server 10.96.0.10」を実行してみたところ、k8s を v1.21.2 で展開していた環境では名前解決をすることができていませんでした。
v.1.20.7 で展開した環境であれば、正常に名前解決ができています。
「Azure Arc Enabled Kubernetes の登録ができない」と思っていた問題は、実際には「CoreDNS によって名前解決ができない」ということが根本的な問題だったようで、そもそもとして使用している環境で CoreDNS が正常に動作していなかったようです…。
k8s のノードで次のような名前解決ができるか確認しておくとよいのかもしれませんね。
nslookup gbl.his.arc.azure.com -server 127.0.0.53 nslookup gbl.his.arc.azure.com -server 10.96.0.10
v1.20.x と v1.21.x の環境の違い
v1.20.x では正常に実行ができており、v1.21.x では正常に実行できないという状態になっているのですが、今回の問題は「CoreDNS のバージョンの違い」によって発生していたようです。
k8s のバージョンによって、CoreDNS のイメージが異なっていました。
- v1.20.x : ecpacr.azurecr.io/coredns:1.7.0
- v1.21.x : ecpacr.azurecr.io/coredns:v1.8.0
今回の現象ですが、使用されている CoreDNS のバージョンの違いによって発生していたようです。
AKS on Azure Stack HCI で使用されている CoreDNS は MS のリポジトリのイメージを使用していますが、ベースとなっているのは https://coredns.io/ と同じかと思います。
「ecpacr.azurecr.io/coredns」ではなく「coredns/coredns」の 1.7.0 のイメージでは現象は発生せず、1.8.0 / 1.8.6 のイメージを使用すると現象が発生したので、CoreDNS 1.7.0 から 1.8.0 の変更内容が、私の環境では影響を与えているようでした。
今回発生していた問題のワークアラウンド
今回発生していた問題ですが、現時点では調査中ではあるのですが、ひとまず次のような対応のいずれかを実施することで、回避はできています。
今回は DNS として 192.168.0.1 を指定していますが、8.8.8.8 でも今回のケースであれば、事象が解消できるかと思います。
サポートの方に教えていただいたのですが類似の事象として、[SOLVED] Azure Arc – Connect a cluster – Failing もあるようで、こちらも DNS の設定を変更することで対応を行ったようです。
マネージメントクラスターが使用する DNS を変更
何回もクラスターのセットアップを実施していて、面倒なので Windows Admin Center からではなく、コマンドで AKS on Azure Stack HCI の展開を行っており、次のようなコマンドでネットワーク設定を使用して、DNS の設定を展開時に変更して回避しています。
$vnet = New-AksHciNetworkSetting ` -name "aks-default-network" ` -vswitchName "Intel(R) Ethernet Connection (6) I219-LM - Virtual Switch" ` -k8snodeippoolstart "10.4.0.1" -k8snodeippoolend "10.4.0.100" ` -vippoolstart "10.5.0.1" -vippoolend "10.5.0.100" ` -ipaddressprefix "10.0.0.0/8" -gateway "10.255.255.254" ` -dnsservers "192.168.0.1"
正常に実行できていない場合は、「-dnsservers "10.255.255.254" 」を指定していたのですが「-dnsservers "192.168.0.1" 」を指定して、参照する DNS の設定を変更しています。
SSH で k8s のノードにアクセスして「systemd-resolve –status」で確認すると、k8s の各ノードで参照している DNS が指定した DNS になっていることが確認できます。
マネージメントクラスターの DNS の設定は、ワークロードクラスターも同一の設定になりますので、CoreDNS 1.8.0 でも参照ができる DNS が設定された状態になります。
CoreDNS のバージョンを変更
v1.21.x では、v1.8.0 が使用されていますので、試しに v1.21.x で、CoreDNS を 1.7.0 を使用してみたところ、正常に実行できるようになりました。
イメージの変更は Deployment の編集を行ってイメージを「ecpacr.azurecr.io/coredns:v1.8.0」から「ecpacr.azurecr.io/coredns:1.7.0」に変更しています。
export KUBECONFIG=/etc/kubernetes/admin.conf kubectl edit deployment -n kube-system coredns
マネージメントクラスター展開時に指定した DNS で正常に動作しない場合は CoreDNS のイメージを変更することで暫定の回避ができるかと。
CoreDNS の ConfigMap を変更
CoreDNS の設定は ConfigMap で設定されているようで「kubectl describe cm -n kube-system coredns」で確認できます。
デフォルトの設定では「forward . /etc/resolv.conf」が設定されていますので、「kubectl edit cm -n kube-system coredns」で「forward . 192.168.0.1」に変更します。
変更が終わったら「kubectl rollout restart -n kube-system deployment/coredns」で CoreDNS を再起動して設定変更したコンフィグの内容を反映させます。
参考
Azure Arc Enabled Kubernetes で使用されている Helm チャート
「%USERPROFILE%\.Azure\AzureArcCharts\azure-arc-k8sagents」に使用されている Helm のファイル一式が格納されているようですので、Arc Enabled k8s がどのように展開されているかはこのディレクトリを見るとわかるかと思います。
「helm ls」「helm get values azure-arc」で Helm の情報は確認できるかと。
使用されている Helm チャートは条件や、関数がうまく使用されているものとなっているので Helm の勉強をするのにも役に立ちました。
Arc Enabled k8s として登録を行う際には、az connectedk8s connect を利用しますが、AZ CLI の拡張機能についてはソースがhttps://github.com/Azure/azure-cli-extensions/tree/main/src/connectedk8s で公開されていますので、登録がうまくいかない場合、これを確認するのも解決につながる一助になるかもしれませんね。
AKS on Azure Stack HCI のログ取得
結果からみると、上記のように CoreDNS が正常に動作していないという状態だったのですが、トラブルシューティングの中ではいくつかのログ取得を行う必要がありました。
AKS on Azure Stack HCI であれば、次の情報として公開されており、
Azure Arc Enabled Kubernetes であれば、トラブルシューティングの方法は次の情報として公開されています
AKS on Azure Stack HCI / Azure Arc Enabled Kubernetes では、様々な Pod が利用されており、各 Pod を一つ一つ確認するのは手間がかかります。
AKS on Azure Stack HCI では Get-AksHciLogs というコマンドレットが提供されており、このコマンドレットを実行することで、マネージメントクラスターならびに、ワークロードクラスターの様々なログを一度に取得することができます。
コマンドレットを実行すると様々な情報が出力された「akshcilogs.zip」が作成されます。(私の環境であれば「C:\AksHCI\WorkDir\1.0.4.10928」に出力されています)
AKS on Azure Stack HCI のトラブルでは次のコマンドを実行して各種バージョンも含めてログを取得することになるかと思います。
Get-AksHciLogs Get-AksHciEventLog > .\Get-AksHciEventLog.txt Get-AksHciVersion > .\Get-AksHciVersion.txt Get-AksHciConfig | ConvertTo-Json > .\Get-AksHciConfig.txt
追記 : 今回発生していた問題の原因と考えられる挙動
今回発生していた問題ですが、FWX120 の挙動のようです。
FWX120 Rev.11.03.08 リリースノート に、次のような記載がありました。
DNSリカーシブサーバー機能で、EDNS0に対応したクライアントからの問い合わせにエラーを返さないバグを修正した。
今回使用していた環境では、CoreDNS への問い合わせが EDNS0 で実行されていたようなのですが、FWX120 の DNS リカーシブサーバー機能については EDNS0 によるクライアントからの問い合わせは「Format Error」となるようでした。
dig で EDNS0を使用した検索がエラーとなるようであれば、使用している DNS が EDNS0 に対応していないため、エラーになっている可能性を検討する必要がありそうですね。
