Closed kzombro-pfl closed 1 year ago
I almost feel like this could be a flannel issue...
Fixed the issue. flannel was struggling to find the default ethernet interface to use and hack away at
i changed the following line in run.ps1
FROM
wins cli process run --path /k/flannel/flanneld.exe --args "--kube-subnet-mgr --kubeconfig-file /k/flannel/kubeconfig.yml" --envs "POD_NAME=$env:POD_NAME POD_NAMESPACE=$env:POD_NAMESPACE"
TO
wins cli process run --path /k/flannel/flanneld.exe --args "--kube-subnet-mgr --kubeconfig-file /k/flannel/kubeconfig.yml --iface-regex=Ethernet0" --envs "POD_NAME=$env:POD_NAME POD_NAMESPACE=$env:POD_NAMESPACE"
and flannel can start up and find the right interface without a hitch.
our windows server has a lot of vEthernet interfaces...
Perhaps we could extend some documentation pointing out that the flanneld.exe args may need to be extended under these circumstances
Describe the bug After restarting a pod in the kube-flannel-ds-windows-amd64 daemonset, the pod crashloops with the following:
Rebooting the windows node appears to fix the issue. However, should the kube-flannel-ds-windows-amd64 restart again, the crashloop starts.
To Reproduce Steps to reproduce the behavior:
Expected behavior The flannel pod should find a valid interface to use; it should restart and be healthy.
Kubernetes (please complete the following information):
Additional context Rebooting the windows node - the flannel pod comes up healthy. On the windows machine with the flapping flannel pod, it is possible to forcibly delete the cbr0 network, and this appears to alleviate the issue but it causes a network interruption we can't afford
Appreciate your insights on this issue Kevin