Open schu opened 5 years ago
So the NXDOMAIN
above actually is an unrelated problem due to https://github.com/docker-library/busybox/issues/48 But the operator uses an older image, busybox:1.28.0-glibc
, so this issue is caused by something else.
kubectl run --rm -ti --restart=Never --image=busybox:1.28.0-glibc busybox
can be used to test.
Have you tried using -type=a
like suggested in https://bugs.busybox.net/show_bug.cgi?id=11161#c4? Maybe it's worth a try?
No I haven't. I meant to say: https://github.com/docker-library/busybox/issues/48 is not an issue for us, since we use an older image, so I don't think we should need the -type=a
workaround.
I haven't managed to reproduce the bug yet today in a few attempts.
Pods by default get a
check-dns
init container. Sometimes a new pod doesn't get past that first init container and hangs:Example description (
kubectl describe pod ...
):The response from kube-dns is NXDOMAIN but that's also the case for a successful setup and nslookup still returns
0
then:I see the issue happening for example after creating a new cluster and doing a restore:
If the pod gets stuck, I redo the restore operation and it usually works then: