is there a timeline when helm install method will be deprecated? based on that I can choose whether to use helm or istioctl, due to the bug https://github.com/istio/istio/issues/19475 i am less confident on using istioctl
also, is is possible that I use helm now and later migrate to istioctl method without breaking or without any downtime of existing installation?
Hi, the current tentative plan is to deprecate in 1.6. Yes, you can use helm for now and migrate to istioctl later if you feel more comfortable with that. btw. we’ve fixed the upgrade issue and are awaiting a patch release 1.4.3 for the fix to be available.
thanks, i wonder how helm to istioctl migration will be seamless, do we need to keep helm installed and then do the future upgrades by istioctl?
There’s an istioctl manifest migrate command which will update your config from helm to istioctl format. From that point you would use istioctl to upgrade instead of helm.
@deepak_deore Can you clarify, is only installation with helm install being deprecated, or is then entire concept of a Helm installation being deprecated (helm template | kubectl apply -f -)?
Someone from istio members can answer this question, as far as I understand, they won’t maintain helm package after that is deprecated which means helm template also isn’t recommended.
But lets wait for istio members’ confirmation.
The plan is to deprecate all of helm, at least as something that would be maintained by the Istio team. The exact timing is tbd but we encourage users to switch to istioctl or operator based installation.
Is there a specific reason for this? This will break our entire automation pipeline that is implemented in helm, and from the initial look at istioctl… it seems to be doing less, not more.
The main reason is that we get a more tailored installation/upgrade/maintenance experience with a tool that is written specifically for Istio vs. a general purpose package manager like Helm. In fact, istioctl still uses Helm under the hood, we just add a bunch of customizations to improve the UX. For example, with the new Helm charts, you have to serialize the installation of different components, which would require external tooling if using Helm. There are also challenges with coordinating upgrades using Helm.
I’d like to hear more about which features you’d like to see in istioctl that Helm provides. We get that there’s a large community of Helm users so we want to make the transition painless, including offering some solution for folks that want to continue using Helm. But we really think that the majority of users will have a better experience in the long run with istioctl (or Istio operator).
To echo @Aaron-ML, we deploy everything (including istio 1.4) with helm+helmfile - we are big fans of declarative, gitops style. We write our own helm charts when they don’t exist, hosted on an internal chartmuseum. Guessing when helm is no longer supported we will have to do the same for istio.
Having each application we deploy to kubernetes needing special installation/upgrade instructions & tools would add significant complexity to deployment.
I agree with @Aaron-ML and @dseapy. Most organizations have automated pipelines for infrastructure, and Helm is the de-facto way of managing Kubernetes deployments. Forcing this new tool breaks that. I for one hope @dseapy ends up open-sourcing his Istio charts so we can continue to use Istio without installing this tool.
You can switch to using istio-operator. Just install it using helm or applying the yaml, then you can install and configure istio using its custom resource IstioControlPlane. Moreover, this CR can be managed in a gitops style. I don’t think you need istioctl for automation.
At least that’s how I plan to use it, moving away from helm installation. 
Both istioctl and the operator follow the declarative model (their operation is directly analogous to helm template and tiller respectively) and as @scenusa points out, gitops management can be done on the CR. The main difference is the API - instead of values.yaml, istioctl/operator have a structured and validated API.
I get your point about not having a tool for every package. Operator is the way to go if you don’t want to install istioctl - both share the same API so you can move back and forth.
We’ll continue to support helm, likely through a new chart to deploy the operator. Istioctl will be our recommended solution for folks not wanting to run a management controller in the cluster and we plan to hand over the current helm charts over to the community. Istioctl will probably continue to use helm charts under the hood so folks could use those directly too if that serves them better - it just likely won’t be an officially supported use path due to the problems we’ve had with this approach.
In that case we will likely use the operator chart you mention, and then either make a custom chart or use the incubator raw helm chart for the CRDs. We have done this kind of thing for other charts.
Since this topic seems to come up alot, I’ve worked with @ostromart and @Costin_Manolache to write a post clarifying the future of Helm Support in Istio.