d161528ae8
Sometimes the calico-etcd pod crashloops when it is being bootstrapped. This occurs intermittently in the gates. Best guess .. when the etcd-anchor pod initially creates the etcd static manifest, it waits for the anchor period (15 seconds) for the etcd pod to become ready. If it is not ready, the next iteration through the loop recreates an identical manifest. The fact that it is a new file causes kubelet to terminate the original container and start up a new one. Kubelet and the container runtime get out of sync, and kubelet can't figure out the correct container id, so the pod ends up crashlooping forever. Manually removing and readding the manifest file doesn't resolve the condition, although a kubelet restart actually does. This "fix" will only write the updated manifest if it is different, and hopefully will prevent the condition from occurring. Change-Id: I4b6b1bf17fd8f0b36d24a741779505b38dba349f |
||
|---|---|---|
| .. | ||
| apiserver | ||
| apiserver-webhook | ||
| controller_manager | ||
| coredns | ||
| etcd | ||
| haproxy | ||
| promenade | ||
| proxy | ||
| scheduler | ||
| .gitignore | ||