Istio 1.10 Improves Scalability and Revision Control
Continuing its focus on improving user experience, Istio recently announced its production-ready, official 1.10 release. It enhances Istio’s scalability and introduces revision tags for smoother control.
Version 1.10 has the following major updates:
- Supports to watch a set of selected namespaces for better scalability, using discovery selector
- A new revision tag feature to avoid redundant namespaces re-labeling during Istio canary upgrade
- Changed sidecar networking interfaces
- A fresh look for the Istio website, istio.io
- Open design and planning documentations for everyone
- Depreciated Kubernetes first-party JWT support
Enhancing the Scalability of Istio
Previously, the Istio control plane has watched services, endpoints and pods across all namespaces in a cluster. However, this function could affect performance due to the increasing size of pods and services.
Enterprises may not need istiod to watch all namespaces. It may not be sensible for Istio to watch some namespaces, such as a namespace that contains a set of Spark job pods, because rapidly churning resources cause performance issues for the Istio control plane.
In the 1.10 release, discovery selectors exist in the meshConfig part that supports arbitrary namespace label selectors, allowing users to include or exclude namespaces based on expression.
For example, the following command will install Istio with discovery selectors and let Istio watch namespaces with labels istio-discovery: enabled and region: us-east1 or namespaces with the label app equal to cassandra or spark.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
istioctl install --skip-confirmation -f - <<EOF apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: namespace: istio-system spec: meshConfig: discoverySelectors: - matchLabels: istio-discovery: enabled region: us-east1 - matchExpressions: - key: app operator: In values: - cassandra - spark EOF |
For more information about discovery selector, and to compare it to the Sidecar resource, check out this blog post.
Introducing Revision Tags for Smoother Canary Updates
Istio has supported canary upgrades since 1.6. But prior to the 1.10 release, if you wanted to adopt an experimental new release version for a given namespace, you could label a namespace as a canary revision (like istio.io/rev=canary) and restart applications in that namespace. Migrating from canary releases to production requires that you re-label in the namespace, from a canary label like istio.io/rev=canary to a production label like istio.io/rev=prod, which introduces a lot of redundant work. With the Istio 1.10 release, we simplify the upgrade by adopting revision tags.
For example, if you have two revisions installed , such as 1-7-6 is for production and 1-8-0 in the canary install , we could create two revision tags like so:.
|
1 2 3 4 |
```bash istioctl x revision tag set prod --revision 1-7-6 istioctl x revision tag set canary --revision 1-8-0 ``` |
After we’ve validated that the canary version works well, we could migrate the prod tag to the newer revision with the following command:
|
1 2 3 |
```bash istioctl x revision tag set prod --revision 1-8-0 ``` |
Namespaces under prod tag will also migrate to a newer version and injected workloads get restarted using a newer control plane.
For more information, check out the updated canary update documentation.
Sidecar Networking Interface Changes
As we know, Kubernetes provides an individual networking namespace for each pod, and for pod communications, there are two networking interfaces. An application may bind to loopback interface lo to allow calls within a pod, bind to pod ip eth0 to allow pod-to-pod communication or bind to both (typically binding to 0.0.0.0).
Prior to Istio 1.10, the Istio data plane would intercept pod inbound traffic from the eth0 interface and redirect it to lo, which might let applications only bind on the lo interface to receive traffic from other pods or disable pods that only bind to the eth0 interface from receiving other pods’ traffic.
Starting from Istio 1.10, the Istio data plane no longer does the redirection and will only forward traffic through eth0. This approach retains the Kubernetes standard networking behavior and avoids unintended exposure to application pods that bind only to the lo networking interface.
It’s noteworthy that this feature could affect the upgrade from Istio 1.9 to Istio 1.10.
To check whether your current deployment would be affected, run the precheck command: istioctl experimental precheck.
The precheck command can detect any pods binding to localhost (lo interface) and report error IST0143.
If you are still not sure whether you want to migrate, you can disable this change by adopting the following environment variable PILOT_ENABLE_INBOUND_PASSTHROUGH=false in Istio control plane.
For more details on networking interface changes, checkout this blog post.
Conclusion
In summary, the Istio community has addressed user experience and performance optimization in the Istio 1.10 release. The Istio 1.10 release behaves closer to Kubernetes standard behaviors and provides more features for scalability, fine tuning, and revision control. We are looking forward to more features and progress made from the Istio community in 2021!