Installation methods
Istio has traditionally supported installation either with the Istio CLI or with Helm.
The Istio CLI was popular on account of providing a straightforward and easy way of getting Istio up and running on a Kubernetes cluster.
Helm has become the preferred and recommended method to install Istio.
Historically Istio also had the Istio in-cluster Operator, a mechanism for installing the service mesh using the Kubernetes Operator pattern. A controller would watch for the application of the IstioOperator resource, and react to it by installing Istio. This method was deprecated and ultimately removed, primarily due security concerns having to do with the operator controller requiring broad permissions to manage Istio resources.
For more details on the history of Istio installation and its nuances, see John Howard's blog posts The Past, Present, and Future of Istio Installation and Everything you need to know about Istio installation.
Today, in ambient mode, to install Istio with Helm, the process is as follows:
- Install the Kubernetes Gateway API CRDs - the Gateway API is a dependency, so must be installed as a prerequisite step.
- Deploy the base Helm chart, which applies Istio's 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.
Thanks to the Kubernetes Gateway API, we can now deploy gateways on-demand in a Kubernetes-native manner using its Gateway resource.
There are good reasons to like Helm:
- Helm is a de facto standard for provisioning systems to Kubernetes, is well-established and approved in enterprise environments.
- Helm is consequently also familiar to many devops engineers.
- The installation is modular, and easily customized.
- Each Helm chart maps to a specific component of the ambient mesh, providing control over the installation process.
This then leads us to the subject of how we install Istio in Gloo Mesh. Gloo Mesh supports Istio installation with Helm, but it also provides an alternative: the Gloo Operator.
The Gloo Operator
The Gloo Operator represents a higher level abstraction for installing Istio. With the Gloo Operator, platform operators do not need to be aware of, or to reference specific components which today make up Istio. The idea is not new, it is basically the operator pattern again.
The installation is declarative; it is driven mainly by the ServiceMeshController resource, where you specify the main configuration parameters for your installation. Applying the resource triggers a controller which then goes about to reconcile your 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.
The Gloo Operator differs significantly from the original Istio Operator both in design, functionality, and in terms of security considerations:
- Gloo Operator translates configuration into validated Helm chart values. It is strictly an abstraction, which minimizes installation errors.
- The Gloo Operator does not require elevated level privileges.
There are several benefits to this approach to installing Istio:
- The end user is shielded from low-level changes in the implementation of Istio.
- The Gloo Operator makes 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.
Example: Installing Istio with the Gloo Operator
To get a feel for how to work with the Gloo Operator, let us walk through an example.
General reference for installing Istio in Gloo Mesh with the Gloo Operator can be found here for single cluster installations, and here for multicluster installations.
Install the Gloo Operator with Helm:
helm install gloo-operator --version 0.2.5 \
oci://us-docker.pkg.dev/solo-public/gloo-operator-helm/gloo-operator \
--namespace gloo-mesh --create-namespace \
--set manager.env.SOLO_ISTIO_LICENSE_KEY=$GLOO_MESH_LICENSE_KEYWait for the gloo-operator pod to be ready:
kubectl wait --for=condition=Ready pod --all -n gloo-mesh --timeout=300sList the pods in the gloo-mesh namespace to visually verify that it is Running:
kubectl get pods -n gloo-meshNext, review the following ServiceMeshController resource:
---
apiVersion: operator.gloo.solo.io/v1
kind: ServiceMeshController
metadata:
name: managed-istio
labels:
app.kubernetes.io/name: managed-istio
spec:
dataplaneMode: Ambient
installNamespace: istio-system
version: 1.26.2The ServiceMeshController resource exposes status conditions that allow you to track the status and phase of the installation, and when it has completed.
We can watch how the status of the ServiceMeshController resource changes as the installation progresses to completion:
watch "kubectl get servicemeshcontrollers.operator.gloo.solo.io managed-istio -o yaml | yq .status"Apply the ServiceMeshController resource to the cluster:
kubectl apply -f artifacts/service-mesh-controller.yamlAt this point, list the pods in istio-system to see Istio's components istiod, istio-cni, and ztunnel running:
kubectl get pods -n istio-systemThe Operator took our specification and turned it into a running instance of Istio.
Summary
Helm is the recommended method for installing Istio open-source. In Gloo Mesh we have an additional option with the Gloo Operator.
Whereas the Helm approach is modular, it exposes many details, which demands knowledge of and expertise with the components that make up Istio. The Gloo Operator on the other hand encapsulates those details and provides a clean interface, and an abstraction over those details.
To continue learning more about the Gloo Operator, check out these resources:
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
