Open invidian opened 2 years ago
Yep, agree this is a gap right now.
You can do this after the API server is running (e.g., kubectl replace -f config.yaml
but we have a gap right now where it's hard to do this prior to the Calico API server running.
@caseydavenport would the following workflow be ok for new installations?
@sebhoss yes that should work
kubectl apply --server-side --validate=false -f - <<EOF
apiVersion: projectcalico.org/v3
kind: KubeControllersConfiguration
metadata:
name: default
spec:
controllers:
node:
hostEndpoint:
autoCreate: Enabled
EOF
Or just an ArgoCD template:
apiVersion: projectcalico.org/v3
kind: KubeControllersConfiguration
metadata:
annotations:
argocd.argoproj.io/sync-options: "ServerSideApply=true, Validate=false"
name: default
spec:
controllers:
node:
hostEndpoint:
autoCreate: Enabled
I'm obligated to discourage the use of crd.projectcalico.org/1 in favor of projectcalico.org/v3
More information here: https://github.com/projectcalico/calico/issues/6412
Thank you @caseydavenport I have updated the previous comment
Expected Behavior
KubeControllersConfiguration/default
can be configured declaratively with only non-default values.Current Behavior
Right now,
KubeControllersConfiguration/default
resource is being created automatically once Calico is deployed, which makes user rely on eithercalico-kube-controllers
deployment configuration (e.g. environment variables) or onkubectl patch
orcalicoctl patch
after installing Calico.Possible Solution
Include
KubeControllersConfiguration/default
in the release manifests and Helm chart with empty spec so user can customize it.Others
As a workaround, is it OK to create the following
KubeControllersConfiguration/default
beforecalico-kube-controllers
is running?The status values field remains the same after reconciliation, however, the spec created by the controller looks like following: