Don't load nonexistent calico-client cert when CNI is Cilium #8338
Conversation
k8s-ci-robot
added
kind/bug
|
That diff is a part of #8220 too |
|
So it is. It is, however, a separate concern that may need to be backported further. |
|
Newer Cilium support doesn't really go back that far though. But just merge in this one if this can make it into the releases that are supposed to be cut this week |
|
I removed this change from my PR. It was not really related anyway. So /lgtm |
|
Thanks for figuring this out @johngmyers & @olemarkus ! /approve |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: johngmyers, justinsb The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
This one is likely to fail aws e2e tests due to the issue being addressed in kubernetes/test-infra#16029 (i.e. not due to this PR) |
|
/test pull-kops-e2e-kubernetes-aws |
1 similar comment
|
/test pull-kops-e2e-kubernetes-aws |
…38-upstream-release-1.17 Automated cherry pick of #8338: Don't load nonexistent calico-client cert when CNI is Cilium
…38-upstream-release-1.15 Automated cherry pick of #8338: Don't load nonexistent calico-client cert when CNI is Cilium
…38-upstream-release-1.16 Automated cherry pick of #8338: Don't load nonexistent calico-client cert when CNI is Cilium
/kind bug
6d01336 stopped generating the "calico-client" keypair and certificate when the CNI was set to Cilium, as the new version of Cilium no longer needed to use the apiserver's etcd cluster. Unfortunately, it failed to stop adding the EtcdTLSBuilder in that case. The result of this is that if the cluster is not using etcd-manager and has etcd TLS enabled, masters will fail to come up looking for "calico-client" certificates that don't exist.