Waiting on namespace which has no pods running about eks-anywhere

[TerryHowe]

That pod listing you give appears to be from the kind bootstrap cluster. Are there any other containers running?

[TerryHowe]

Normally, these type of errors are caused by resource constraints. You may need to increase your RAM and/or disk for Docker or run docker system prune

[gohmc]

How does it related to resources? See the last logged message, the docker run is waiting for non-existent pod in a namespace "eksa-system". On a 2xlarge instance there was at least 50% free memory at the hung point.

[vignesh-goutham]

That is interesting. I'm assuming you are running a linux distro, so docker technically has access to all the memory(mostly). I have seen this waiting for behavior when the engine runs out of memory. Could you share the output of docker info --format '{{json .MemTotal}}'

[jaxesn]

Its actually not waiting for a pod in the eksa-system namespace, instead its waiting for the ControlPlaneReady event which fires from the capi cluster object being created in the eksa-system namespace.

If you this is reproducible for you, maybe looking at the pod logs for the pod in capd-system and the kubelet logs inside the docker container may give us a hint.

[jaxesn]

Sorry I see your previous issue as well. Looks like the podcidr is going to be your issue here. I am going to close this one out and well get the podcidr issue fixed.

Feel free to reopen if you feel closing is an error.

[sagarkundral24]

I found below error in the /var/log/syslog, so I manually pulled that image on the host by doing docker login. That fixed the problem for me.

Error from syslog:

Unable to find image 'kindest/haproxy:v20210715-a6da3463' locally
docker: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit.