mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-11-11 17:16:18 +00:00
14fe7225c1
CreateOrMutateConfigMap was not resilient when it was trying to Create the ConfigMap. If this operation returned an unknown error the whole operation would fail, because it was strict in what error it was expecting right afterwards: if the error returned by the Create call was a IsAlreadyExists error, it would work fine. However, if an unexpected error (such as an EOF) happened, this call would fail. We are seeing this error specially when running control plane node joins in an automated fashion, where things happen at a relatively high speed pace. It was specially easy to reproduce with kind, with several control plane instances. E.g.: ``` [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace I1130 11:43:42.788952 887 round_trippers.go:443] POST https://172.17.0.2:6443/api/v1/namespaces/kube-system/configmaps?timeout=10s in 1013 milliseconds Post https://172.17.0.2:6443/api/v1/namespaces/kube-system/configmaps?timeout=10s: unexpected EOF unable to create ConfigMap k8s.io/kubernetes/cmd/kubeadm/app/util/apiclient.CreateOrMutateConfigMap /go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/util/apiclient/idempotency.go:65 ``` This change makes this logic more resilient to unknown errors. It will retry on the light of unknown errors until some of the expected error happens: either `IsAlreadyExists`, in which case we will mutate the ConfigMap, or no error, in which case the ConfigMap has been created.