Gloo Mesh presents us with two options for installing Istio: Helm and the Gloo Operator.
Which one should you choose?
Helm
Helm is the established, de facto tool for installing software on Kubernetes. There's a lot to like about the uniformity of standardizing on one tool for everything.
When we look at Istio specifically, the open-source project provides two alternatives: the Istio CLI and Helm.
In the Helm installation instructions for ambient mode is the following preface:
We encourage the use of Helm to install Istio for production use in ambient mode. To allow controlled upgrades, the control plane and data plane components are packaged and installed separately.
With open-source Istio, Helm is the method we are encouraged to use.
The procedure to install Istio with Helm in ambient mode is as follows:
- Install the Kubernetes Gateway API CRDs - this is not technically a part of Istio, so much be installed as a prerequisite step.
- Deploy the base Helm chart, which applies the Istio CRDs
- Istiod, Istio's control plane, has its own dedicated chart
- Apply the Helm chart for the Istio CNI agent, which is required for ambient
- Finally, apply the Helm chart for the ztunnel component, Istio ambient's layer 4 proxy
Besides the fact that Helm is a de facto standard, there are additional reasons in favor of Helm:
- Helm is often approved in enterprise environments.
- Helm is familiar to many devops engineers.
- The installation of Istio with Helm is modular, and easily customized.
- Each Helm chart maps to a specific component of the ambient mesh, providing control over the installation process.
The Gloo Operator
The Gloo Operator represents a higher level abstraction for installing Istio.
It is an example of the Kubernetes operator pattern -- a well-established, and a Kubernetes-native way of capturing and automating the complex process of managing the lifecycle of an Istio deployment.
Consequently, installation is declarative, driven mainly by the ServiceMeshController resource, where the main configuration parameters for an installation are specified.
Applying the resource triggers the Gloo Operator (the controller), which then goes about reconciling the cluster to this desired state.
For advanced configuration, there is an ancillary resource, the ConfigMap gloo-extensions-config in the gloo-mesh namespace, for specifying a myriad of additional configuration details.
One important takeaway is that the operational knowledge for installing Istio with all its nuances is captured by the Gloo Operator.
The Gloo operator allows us to think of Istio as a single entity, and not in terms of its components, the details that make up the installation.
There are several benefits to this approach:
- The platform operator is shielded from low-level changes in the implementation of Istio.
- The Gloo Operator makes installations and upgrades simple and easy.
- The Gloo Operator presents a well-defined contract with the platform operator.
- This approach is much simpler, and doesn't require Helm expertise.
Analysis
At first these two options appear to be diametrically opposed. Helm is transparent, gives you control and access to the details of the installation. The Gloo Operator on the other hand is opaque, takes over the responsibility of the knowledge of those details, and presents a high-lever interface for the human operator to work with.
But another way to think of this dichotomy is not as two opposites, but rather by looking at Gloo Operator as a layer above Helm, one that builds on it, with the objective of automating what the consumer would have to do themselves.
The reason we are given two options is to cater to two types of "consumers":
- The enterprise consumer who just wants the helm charts and the recipe for installation, and can take that information and perform their own adaptation of the installation process with their existing automation tooling and infrastructure. This consumer values control, and the ability to carefully introduce Istio into an existing, and already complex environment.
- The more pragmatic consumer who wants a turnkey solution. This consumer values the increased productivity they derive from adopting the Gloo Operator. The Gloo Operator represents to them a sort of delegate, responsible over the knowledge of how to install and upgrade Istio.
Gloo Mesh of course provides both options. Take the time to review and evaluate both approaches, before deciding on which is more suitable to your use case and your environment.
Explore more information about Istio and Gloo Mesh:
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
