[PRODENG-3744] Use KDD datastore by default - #72
Conversation
6815cdc to
67e3cab
Compare
|
after discussion with the team, we decided to not use KDD by default for now, however it could be needed in the future. So keep the code, but set variable to |
| tasks: | ||
| - name: Patch calico-kube-controllers service account | ||
| ansible.builtin.include_tasks: tasks/calico-kdd-patch-tasks.yml | ||
| when: calico_datastore_type_kdd | bool |
There was a problem hiding this comment.
🟡 Medium - KDD repair task is skipped for clusters that enable the datastore through existing install-flag overrides
The new service-account patch runs only when calico_datastore_type_kdd is true, but the code still exposes the generic mke_install_flags override and documents mke-post-install-playbook.yml as a standalone flow. That means a cluster can be installed with --calico-datastore-type-kdd through the existing flag list while this new boolean stays at its default false, causing post-install to skip the fix entirely. In that state calico-kube-controllers keeps running as calico-node and hits the RBAC-forbidden/CrashLoop behavior this PR is meant to prevent, so the repair is unreliable for valid KDD deployments.
Show fix
Drive the patch from the effective install configuration or live cluster state instead of a second manually-synchronized boolean, or at least fail fast when KDD is present in mke_install_flags but calico_datastore_type_kdd is false.
More info - Reply on this comment to give feedback or ignore the issue.
Gate --calico-datastore-type-kdd behind calico_datastore_type_kdd (default true) instead of hardcoding it in mke_install_flags. Known MKE3 issue: with KDD enabled, MKE brings up the calico-kube-controllers Deployment (kube-system) wired to the calico-node ServiceAccount instead of its own calico-kube-controllers ServiceAccount, so it cannot sync from the Kubernetes API. tasks/calico-kdd-patch-tasks.yml patches the Deployment's serviceAccountName via mke-post-install-playbook.yml. That play runs the patch last, after cluster-upgrade-controller/machine-config-controller/ SUC install: installing those was observed to trigger MKE to re-sync its baseline kube-system manifests, reverting the patch if applied before them. Verified against a live cluster end-to-end, including that the fix holds once nothing else in the run mutates the cluster afterward.
67e3cab to
b87c832
Compare
Gate
--calico-datastore-type-kddbehind calico_datastore_type_kdd (default true) instead of hardcoding it in mke_install_flags.Known MKE3 issue: with KDD enabled, MKE brings up the calico-kube-controllers Deployment (kube-system) wired to the calico-node ServiceAccount instead of its own calico-kube-controllers ServiceAccount, so it cannot sync from the Kubernetes API.
tasks/calico-kdd-patch-tasks.yml patches the Deployment's serviceAccountName via mke-post-install-playbook.yml. That play runs the patch last, after cluster-upgrade-controller/machine-config-controller/ SUC install: installing those was observed to trigger MKE to re-sync its baseline kube-system manifests, reverting the patch if applied before them. Verified against a live cluster end-to-end, including that the fix holds once nothing else in the run mutates the cluster afterward.