Tetrate sponsored this post.
1.11 is the third release of Istio in 2021. In this version, the Istio container network interface (CNI) plugin is upgraded to beta. and you can use the CNI plugin to install Istio.
By default, Istio uses init-container to generate redirection rules from application container to sidecar proxies. Changing IPTables rules requires NET_ADMIN and NET_RAW permission, which may not comply with production security requirements. With this new plugin, the community has introduced a new way to configure iptables rules — using Istio CNI.
Istio CNI does not, like Calico or Flannel, bring new IP addresses to a workload. It only serves to change the redirection rules of iptables to workload and needs to collaborate with other CNI plugins like Calico or Flannel. If a workload gets started before Istio CNI starts, it may trigger a race condition issue (i.e., workload pods get started before Istio CNI DaemonSet is ready). The Istio community has provided a repair controller solution, which could be configured by the setting below. You can find further details in the design doc. The following figure shows how the Istio CNI plugin works.
You can use the YAML below to install Istio with the minimal profile, and then install Gateway.
kubectl apply -f - <<EOF
External Control Plane (Beta)
In production, it would be nice if we could separate the responsibilities for applications in different clusters to different operators. Istio introduces an external control plane that allows users to install their operators on different clusters and manage clusters running application containers.
Sidecars residing in remote clusters, including gateway, could be manipulated remotely by the control plane through the ingress gateway in the remote clusters.
Update to Revision and Tag Deployment
In our previous article, we described how Istio introduced an experimental revision tag upgrade for canary upgrades in Istio clusters. Now the revision tag feature has graduated from experimental to stable.
Revision tag setups are similar to 1.10. For example, if you have two revisions installed, such as 1-7-6 for production and 1-8-3 for canary update, you could create two revision tags, like so:
istioctl tag set prod-stable --revision 1-7-6
Istioctl tag set prod-canary --revision 1-8-3
After we have validated that the canary revision works well, we can update production Istio to the newer revision with the following command:
istioctl tag set prod-stable --revision 1-8-3
To view all revision tags and their namespaces, you could run the following command:
istioctl tag list
TAG REVISION NAMESPACES
prod-canary 1-8-3 ...
prod-stable 1-7-6 ...
For more information, please check out the updated canary update documentation.
Kubernetes Multicluster Service (MCS) Support (Experimental)
In KEP 1645, Kubernetes introduced its native multicluster service API, with its alpha implementation here. The MCS custom resource definitions (CRDs) defined APIs for exporting services and their endpoints across multiple clusters. For now, it is still in alpha stage and not ready for production. You can check out Issue 29384 for MCS service discovery on Istio and Issue 33949 for MCS host configuration on Istio.
Istio’s three releases this year generally continue the goal set at the beginning of the year to improve the Day 2 experience, and we’ve seen the Istio community put a lot of effort into security and support for multiple clusters. At the same time, in light of Istio’s steep learning curve, Tetrate has released the free Istio Fundamentals course and Certified Istio Administrator to help you learn and master Istio.
Photo by Bruno Thethe from Pexels.