Istio's Helm Support in 2020

I would like to take some time to clarify Istio’s plans for Helm support in 1.5, 1.6, and beyond. By way of background, Istio 1.3 introduced the Istio Operator as an experimental feature which allows administrators greater ease of use and flexibility when installing and operating Istio. The Operator is accessed through the istioctl manifest command, and will enter Beta in the 1.5 release. Under the hood, this operator is built on top of Helm charts, but these charts are completely distinct from the earlier charts, which were packaged in the binary at install/kubernetes/helm/istio.

In Istio 1.6, the original helm charts will be removed from the project. The new charts are a more modular version of the original charts, which relied on subcharts. Moving forward we’re adding support for multiple control plane revisions and modular installation, which are not possible with the old all-in-one charts. The recommended path for installing Istio and managing Istio installations will be using the Operator via Istioctl. For users who would like to continue installing and managing Istio via Helm directly, we will support calling the Helm charts which underlie the operator, and are located at istio/istio/manifests. In 1.5 the charts require Helm2 - with either ‘template’ or tiller. In 1.6 we’ll support both helm3 and helm2. This will increase parity between Helm and non-Helm use cases, and reduce drift between the various installation and management paths.

I hope this information helps to clarify our plans for Helm support. Feel free to reply with any related questions!


Hope that with 1.6, all the options that helm chart installation method provides will be available with istioctl method,


  1. we couldn’t install ingress object for kiali with istioctl and had to install it separately, in our use-case kiali is made available via nginx ingress, helm method supports that.
  2. another one was installing user (custom) ingress g/w isn’t supported with istioctl currently.

Note that in the near future it is likely that third-party add-on components like Kiali will not be possible via istioctl installer, other than perhaps through a “demo” profile of some kind. The alternative would be to go outside istioctl and use the third-party installers (e.g. in Kiali’s case, using the Kiali Operator to perform the installation of Kiali).

Thanks for the update. Is this page still accurate for 1.5 then ?

Following the instructions there:

$ helm install install/kubernetes/helm/istio --name istio --namespace istio-system

Why, when im looking inside of install/kubernetes/helm/istio/values.yaml i still see galley,mixer,pilot still enabled , no references to the istiod component and mtls auto not enabled. I thought in 1.5 they are disabled and mtls is on? @Mitch_Connors

What is the best course of action to get to the new way of managing Istio if coming from a Helm installed setup? Do i remove Istio and reinstall, create new cluster altogether, run Operator (installed with Helm charts) and then start using Istioctl?

I like that we are seeing what the helm support looks like, but I’m more interested in how to move forward in a safe manner.


Yeah, this is my concern too. I’ve actually given this a go today and it’s really not gone well at all. I did it in a test cluster, but it had loads of down time, and I still couldn’t get it working. After installing Istio via Istio Operator I tried to remove the Helm release and it took some of the stuff the Istio Operator had created with it (and then the Istio Operator didn’t try recreate those things either, I had to delete and then recreate my IstioOperator resource for it to install everything again). When I did get Istio up and running again, it didn’t seem to work with the values that had worked with Helm. The HPA for the ingress gateway was pointing at the wrong ref, my ingress gateway was 404ing, and I had some errors around certificates not being present any more (despite restarting all pods), around cert manager CRDs not being present (I’ve got a separate installation of Cert Manager using the latest version?), and not being able to make a PVC for Grafana. I never figured out the 404 issue despite trying for hours, so I went back to using Helm.

I only hope that if the Helm Chart really has been removed that there are some really clear instructions on how to proceed with this migration. Something must have been wrong with my setup, obviously, but if so, there needs to be some clear indication of what somewhere.

1 Like

@Mitch_Connors I see that the operator.yaml manifest has been removed as well as of 1.5

$ kubectl apply -f

Is not valid anymore… is this intentional?

1 Like

Indeed. @Mitch_Connors we’d like to use this or something similar to it.