Deploying a Kubernetes cluster without a pre-installed CNI plugin creates a circular dependency. The cluster remains in a NotReady state, preventing standard pods from scheduling, which in turn prevents GitOps controllers like Flux from deploying the CNI plugin itself.
The resolution requires separating the initial setup from ongoing operations. The CNI must be installed manually via Helm before bootstrapping Flux. Once the CNI is active, the node status transitions to Ready, allowing Flux to take over management of the existing release.
When Flux adopts a manually installed Helm release, it triggers a one-time redeployment of the DaemonSet. This occurs because the Helm controller re-renders the chart using its own SDK, causing minor formatting changes that lead to a reconciliation event. This process may cause temporary service interruptions.
To manage this, administrators should disable automatic rollbacks for CNI updates to prevent network instability. It is recommended to verify the state by comparing pod names and generation counts before and after the reconciliation to confirm that the system has stabilized.
