WindowsデバッグTips
ノードレベルのトラブルシューティング
-
Podが"Container Creating"と表示されたまま動かなくなったり、何度も再起動を繰り返します
pauseイメージがWindows OSのバージョンと互換性があることを確認してください。 最新/推奨のpauseイメージや詳細情報については、Pauseコンテナを参照してください。
備考: コンテナランタイムとしてcontainerdを使用している場合、pauseイメージはconfig.toml設定ファイルのplugins.plugins.cri.sandbox_imageフィールドで指定されます。 -
Podが
ErrImgPullまたはImagePullBackOffのステータスを表示しますPodが互換性のあるWindowsノードにスケジュールされていることを確認してください。
Podに対して互換性のあるノードを指定する方法の詳細については、このガイドを参照してください。
ネットワークのトラブルシューティング
-
Windows Podがネットワークに接続できません
仮想マシンを使用している場合は、すべてのVMのネットワークアダプターでMACスプーフィングが有効になっていることを確認してください。
-
Windows Podから外部リソースにpingできません
Windows Podには、ICMPプロトコル用にプログラムされたアウトバウンドルールはありません。ただし、TCP/UDPはサポートされています。 クラスター外のリソースへの接続を実証する場合は、
ping <IP>を対応するcurl <IP>コマンドに置き換えてください。それでも問題が解決しない場合は、cni.confのネットワーク設定に問題がある可能性が高いです。 この静的ファイルはいつでも編集できます。 設定の更新は、新しく作成されたすべてのKubernetesリソースに適用されます。
Kubernetesのネットワーク要件の1つ(Kubernetesモデルを参照)は、内部でNATせずにクラスター通信が行われることです。 この要件を満たすために、アウトバウンドのNATを発生させたくないすべての通信のためのExceptionListがあります。 ただしこれは、クエリしようとしている外部IPを
ExceptionListから除外する必要があることも意味します。 そうして初めて、Windows Podからのトラフィックが正しくSNATされ、外部からの応答を受信できるようになります。 この点について、cni.confのExceptionListは次のようになります:"ExceptionList": [ "10.244.0.0/16", # クラスターのサブネット "10.96.0.0/12", # Serviceのサブネット "10.127.130.0/24" # 管理(ホスト)のサブネット ] -
Windowsノードが
NodePortタイプのServiceにアクセスできませんノード自身からのローカルNodePortへのアクセスは失敗します。 これは既知の制限です。 NodePortへのアクセスは、他のノードや外部のクライアントからは動作します。
-
コンテナのvNICとHNSエンドポイントが削除されています
この問題は
hostname-overrideパラメーターがkube-proxy に渡されていない場合に発生する可能性があります。 これを解決するためには、ユーザーは次のようにkube-proxyにホスト名を渡す必要があります:C:\k\kube-proxy.exe --hostname-override=$(hostname) -
WindowsノードがService IPを使用してサービスにアクセスできません
これはWindows上のネットワークスタックの既知の制限です。 ただし、Windows PodはService IPにアクセスできます。
-
kubeletの起動時にネットワークアダプターが見つかりません
Windowsのネットワーキングスタックでは、Kubernetesネットワーキングが動作するために仮想アダプターが必要です。 (管理者シェルで)次のコマンドを実行しても結果が返されない場合、kubeletが動作するために必要な前提条件である仮想ネットワークの作成に失敗しています。
Get-HnsNetwork | ? Name -ieq "cbr0" Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"ホストのネットワークアダプターが"Ethernet"ではない場合、
start.ps1スクリプトのInterfaceNameパラメーターを修正することが有益です。 それ以外の場合は、start-kubelet.ps1スクリプトの出力結果を参照して、仮想ネットワークの作成中にエラーが発生していないか確認します。 -
DNS名前解決が正しく動作しません
このセクションのWindowsにおけるDNSの制限について確認してください。
-
kubectl port-forwardが"unable to do port forwarding: wincat not found"で失敗しますこれは、pauseインフラコンテナ
mcr.microsoft.com/oss/kubernetes/pause:3.6にwincat.exeを含める形で、Kubernetes 1.15にて実装されました。 必ずサポートされたKubernetesのバージョンを使用してください。 独自のpauseインフラコンテナをビルドしたい場合は、必ずwincatを含めるようにしてください。 -
Windows Serverノードがプロキシの背後にあるため、Kubernetesのインストールに失敗しています
プロキシの背後にある場合は、次のPowerShell環境変数が定義されている必要があります:
[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
Flannelのトラブルシューティング
-
Flannelを使用すると、クラスターに再参加した後にノードに問題が発生します
以前に削除したノードがクラスターに再参加すると、flanneldはノードに新しいPodサブネットを割り当てようとします。 ユーザーは、次のパスにある古いPodサブネットの設定ファイルを削除する必要があります:
Remove-Item C:\k\SourceVip.json Remove-Item C:\k\SourceVipRequest.json -
Flanneldが"Waiting for the Network to be created"と表示されたままになります
このIssueに関する多数の報告があります; 最も可能性が高いのは、flannelネットワークの管理IPが設定されるタイミングの問題です。 回避策は、
start.ps1を再度実行するか、次のように手動で再起動することです:[Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>") C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1 -
/run/flannel/subnet.envが見つからないためにWindows Podが起動しませんこれはFlannelが正常に起動できなかったことを示しています。
flanneld.exeを再起動するか、Kubernetesマスター上の/run/flannel/subnet.envをWindowsワーカーノード上のC:\run\flannel\subnet.envに手動でコピーして、FLANNEL_SUBNET行を異なる数値に変更します。 例えば、ノードのサブネットを10.244.4.1/24としたい場合は次のようにします:FLANNEL_NETWORK=10.244.0.0/16 FLANNEL_SUBNET=10.244.4.1/24 FLANNEL_MTU=1500 FLANNEL_IPMASQ=true
さらなる調査
これらの手順で問題が解決しない場合は、下記からKubernetesのWindowsノード上でWindowsコンテナを実行するためのヘルプを得ることができます:
- StackOverflowのWindows Server Containerトピック
- Kubernetesの公式フォーラムdiscuss.kubernetes.io
- Kubernetes Slack #SIG-Windowsチャンネル