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.
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 https://git.io/getLatestIstio | 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 https://github.com/istio/istio/releases/download/1.1.0-snapshot.4/istio-1.1.0-snapshot.4-linux.tar.gz …
% 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:"
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.
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.
