Status of Istio 1.1


Hey, Istio Community -

I just wanted to write a quick note on the status of the 1.1 release.

Ever since the release of Istio 1.0, we’ve had a flood of adoption and, not surprisingly, a bunch of critical issues. This was expected, of course – for a project of this magnitude, we knew that a wave of adoption would mean a wave of bugs filed.

Addressing those issues so that people could reliably deploy 1.0 in production environments has been our focus for the last several months. Work on 1.1 has continued, but we’ve had to put more effort than we would have hoped going into the 1.0.x patch releases, which has pushed back the 1.1 delivery date.

The major themes for 1.1 are:

  • Scalability: improving the performance of Pilot and the Envoy proxies for meshes with thousands of services
  • Multi-cluster mesh: various features, including the implementation of Galley, a new top-level config ingestion, processing and distribution component.
  • Upgrades: ensuring that people who have adopted 1.0 can smoothly upgrade to newer versions as they come out

The final release timeline for 1.1 is not finalized, but we have begun the release qualification process. We expect to have our first release candidate later this month and a final build sometime in February.


Thanks for the updates.
You haven’t mentioned Istio CNI (, it will be in 1.1 release ?


Yes good reminder, it is planned to be as an experimental feature in v1.1.

Istio CNI integration with Istio 1.0.x

What about the last 1.1 snapshot release? I see here:

that there is a snapshot 4 - but its in “draft”. When I try to download it, getLatestIstio fails:


export ISTIO_VERSION=1.1.0-snapshot.4 curl -L | sh -
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0
100 1631 100 1631 0 0 2183 0 --:–:-- --:–:-- --:–:-- 2183
Downloading istio-1.1.0-snapshot.4 from
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9 0 9 0 0 25 0 --:–:-- --:–:-- --:–:-- 25

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Downloaded into istio-1.1.0-snapshot.4:
ls: cannot access istio-1.1.0-snapshot.4: No such file or directory
sh: line 41: cd: istio-1.1.0-snapshot.4/bin: No such file or directory
Add to your path; e.g copy paste in your shell and/or ~/.profile:
export PATH="$PATH:"


I can confirm that, the 1.1 last snapshot release is not uploaded to github.

But you can download it from:



Cannot download 1.1 snapshot.4
pinned globally #6


What is the status of Istio 1.1 release?
Is it possible to be released in February?


Hope to release soon, I 'm looking forwoard the RouteDirective feature in mixer


Will 1.1 release move “Out of Process Mixer Adapters” to the beta stage? If not, when do we expect that?



@toc Could you provide insight into this?

When do we expect “Out of Process Mixer Adapters” to move to the beta and stable stage?


Yes! Out of process mixer adapters will be beta in 1.1!


istio-1.1 is released. However, could not find any mention of its integration with Prometheus Operator. Could you please confirm the timelines for releasing a combined solution for Mesh, Application Monitoring (Prometheus, Jaeger, Grafana) and Cluster Monitoring (Prometheus Operator).


@javed Supporting Operator-based installations of Prometheus has not been an area of focus to-date for Istio. I believe that several members of the community have gotten Operator-based Prometheus installs to work with the existing Istio addon configuration, however.

One of the items on the discussed roadmap for the Policies and Telemetry WG is better Operator support. We’d love more feedback on how you believe this should work – and what is critical to get right. I think we want to avoid taking on managing the install of the Prometheus Operator within Istio, but generating the right config artifacts to work with the Operator is definitely one thing we want to do.


Thank you for the reply. My query was in reference to the discussion at!topic/istio-users/v6gNN3rizFE.

As of now, to meet the requirements of (i) Mesh/Application Monitoring/Distributed Tracing and of (ii) Kubernetes Cluster Monitoring, the following approach is considered:

(1) Istio-1.0 (helm chart) with tracing enabled, for Mesh/Application Monitoring/Distributed Tracing and
(2) Prometheus Operator (helm chart) for Cluster Monitoring.
Grafana is configured with 2 datasources: (a) Prometheus from Istio deployment for Istio dashboards and (b) Prometheus from Prometheus Operator’s deployment for Cluster Monitoring dashboards.

Could you please inform me, in reference to the present solution, if there is any better approach to meet the above requirements for monitoring.


We should probably move this to a different discussion topic, as this now is completely unrelated to the status of Istio 1.1.

It is entirely possible to configure a prometheus managed by the operator to get your requirement (i). The only things unique about the addon prometheus that Istio enables via helm are the job configuration that directs scrapping (which should be straightforward to move over to Operator based installs) and the mounting of certs for application scrapping in mTLS environments. I believe that others have achieved this task. For 1.2, we want to eliminate the friction around both.