As discussed during refinement of OSSM-1961, we should move the 2.3 install-cni container into its own pod (deployed via a separate DaemonSet). From 2.3 onwards, we want the operator to deploy one DaemonSet for each OSSM version. This will fix issue OSSM-1961, but also reduce the memory usage for most customers, since the operator will only deploy a specific version of the CNI plugin when the first SMCP of said version is deployed.

The 2.3 operator should thus deploy the existing CNI DaemonSet only when an SMCP version 1.1, 2.0, 2.1 or 2.2 is deployed. If the SMCP version is 2.3, it should deploy a DaemonSet called istio-cni-node-2.3 or something similar, with a single container running the 2.3 version of the CNI installer.

Acceptance criteria:

• operator deploys the correct DaemonSet version when an SMCP of a particular version (2.3 and forward) is deployed
• upgrading the operator from 2.2 to 2.3 does not break existing meshes.
  After deployment, an existing traffic through the proxy and a new pod creation are working and traffic is still route to the application pod.

• OSSM-1961 no longer manifests itself
• the new behavior and how to verify this change is documented (e.g. describe in a new OSSMDOC ticket)
  •  Doc issue: OSSMDOC-709

Non-goals:

• the operator doesn't need to delete DaemonSets when SMCPs are deleted (the operator doesn't do this now; we'll address this in a follow-up issue)