canonical/istio-operators

Create a spec for setting and using Istio CNI by default

DnPlas opened this issue · 3 comments

DnPlas commented

What needs to get done

A spec that outlines the implementation details, changes and the context of how Istio CNI works and how is that different from the current installation (up to istio-operators 1.17/stable). Also to include some of the limitations and potential issues, like the Compatibility with application init containers topic.

The following can be referenced for outlining the process:

Scope and considerations

  • This effort is mainly targeted at the istio-operators in main (so latest/edge) and should be included in the CKF release 1.9
  • The upgrade story between istio-operators 1.17 and newer versions of the charms
  • A stretch goal would be to bring this change to the charms released in 1.8/stable, IFF there are no big breaking changes that could break the stable release

Why it needs to get done

To be able to define the design and implementation details of the newer installation mode (with the CNI plugin).

syncronize-issues-to-jira commented

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5036.

This message was autogenerated

kimwnasptd commented

I took a very brief look on the docs around for CNI, and an extra layer ambient-mesh (which we don't have to focus at all on for now).

Just adding those docs here, since they seemed nice
https://github.com/istio/istio/blob/master/cni/README.md
https://istio.io/latest/blog/2022/introducing-ambient-mesh/
https://istio.io/latest/blog/2023/ambient-ebpf-redirection/

DnPlas commented

The spec file has been created and approved. Though I cannot link the actual document here (as it is not a public doc), the highlights of it are:

  • From the approval of this specification and on, the default installation of the Istio Control Plane using the istio-operators will always come with the Istio CNI plugin with no option to disable it.
    Despite being optional in the upstream project, the CKF team is looking at making their offerings more secure in the longer run by also leveraging Pod Security Admission to prevent the creation of privileged controllers. This requires the Istio CNI plugin to be present.

  • The charm will have the following configuration options:

    • cni-bin-dir, a string to pass the path to CNI binaries
    • cni-conf-dir, a string to pass the path to conflist files describing the CNI configuration

  • To install the Istio CNI plugin with the correct configurations, the following flags and values have to be added to the install command in istio-pilot’s charm code:

diff --git a/charms/istio-pilot/src/charm.py b/charms/istio-pilot/src/charm.py
index 9592374..4eec2d3 100755
--- a/charms/istio-pilot/src/charm.py
+++ b/charms/istio-pilot/src/charm.py
@@ -196,6 +196,12 @@ class Operator(CharmBase):
             	"--set",
             	"profile=minimal",
             	"--set",
+            	f"values.cni.cniBinDir=self.model.config["cni-bin-dir"]",
+            	"--set",
+            	f"values.cni.cniConfDir=self.model.config["cni-conf-dir"]",
+            	"--set",
+            	"components.cni.enabled=<true|false>",
+            	"--set",
             	f"values.global.istioNamespace={self.model.name}",
             	"--set",
             	f"values.pilot.image={pilot_image}",

Closing this issue based on the above.