Istio 1.8 focuses on usability and upgrades
Easier upgrades, formal process for feature requests, experimental updates, and more
On May 24, 2017, IBM and Google announced the launch of Istio, an open technology that enables developers to seamlessly connect, manage, and secure, and control networks of different microservices — regardless of platform, source, or vendor. The Istio 1.8 release adds new features that make Istio easier to upgrade, clearer information about maturity of each feature, better documentation, and tons of exciting experimental features.
Improved upgrade experience
The Istio user community frequently shares valuable feedback that works its way into our release cycles. Many of you requested that we improve the experience of upgrading Istio, addressing the downtime during upgrades, lack of guidance around when and how to upgrade, and the inability to do skip-version upgrades.
With our users in mind, we made a few key updates to 1.8 to clarify when to use in-place upgrades and when to use revision-based upgrades. Specifically:
- Use in-place upgrades if you can tolerate short downtimes. The
istioctl analyzercommand checks if your Istio resources require any changes before upgrading to the new Istio version. The
istioctl upgradecommand checks your upgrade eligibility and highlights any changes of the Istio install configuration for you before you proceed with the upgrade.
- Use revision-based upgrade if you want to thoroughly test the new release and gradually switch to the new control plane and data plane in a fully controller manner. We highly recommend this if you use experimental or alpha or undocumented APIs, for example, Envoy filters.
Manage gateways separately
If you ever worried about the risk of upgrading both the control plane and the critical data plane gateways at the same time, you should check out the newly added ability to manage gateways separately out of the Istio control plane. Prior to 1.8, the Istio control plane and gateway were updated together so there was no guarantee that Istiod was up and running when the gateway was being updated. This separation will enable you to update Istiod first, followed by the gateway, which is useful for either in-place or revision-based upgrades.
Refer to Istio 1.8’s upgrade notes to learn more about upgrades. Want to have someone else manage Istio upgrades for you entirely? Istio on IBM Cloud is offered as a managed add-on that integrates Istio directly with your Kubernetes cluster.
Formal process for adding new features and upgrading existing features
The community is excited about developing new features for Istio, which is a good thing. To manage these feature requests, the Istio Technical Oversight Committee created an enhancements repository.
The enhancements repository helps the Istio community track all new feature requests and provides a well-defined, ticket-based process for progressing a feature through the feature lifecycle stages, promoting existing features from experimental to alpha or beta or stable.
Multicluster is promoted to beta
Prior to Istio 1.8, there were two multicluster deployment models (replicated control plane and shared control plane). In 1.8, these deployment models are consolidated into a single multicluster deployment model which is easier to set up. You can choose different typologies based on your control plane high availability needs and your networks. See the GitHub issue detailing multicluster’s promotion to beta.
External control plane (Istiod) is promoted to alpha
The external control plane model allows the Istio control plane to run outside of the mesh cluster. This allows vendors like IBM to offer Istio-as-a-Service where vendors provide a fully managed Istio control plane experience that runs outside of users’ clusters. See the GitHub issue detailing the external control plane’s promotion to alpha.
Helm v3 is promoted to alpha
As part of the process, we start to require all alpha feature to have automated testing in Istio.io. In Istio 1.8, documentation is actively verified against the code base for every pull request. We added an automated testing framework to most of our pages in Istio.io which has a page tested indicator that indicates if the commands in the page have been automatically tested with each build!
Exciting experimental and alpha features
As the community continue to make Istio simpler to use, many new features were added to Istio 1.8. Below are some of my favorites:
DNS proxy is probably the most exciting experimental feature of 1.8, which is enabled by default in our preview profile. DNS proxy enables the Istio sidecar to serve as DNS for services and is intended to improve usability for DNS resolutions for services running on VM, importing external services to the mesh via Service Entry, and eliminating the need to run CoreDNS or mirror services for cross cluster DNS resolution. Refer to this blog to learn more on this topic.
Virtual machine integration enables users to easily onboard their services running on VMs to Istio service mesh. While this feature did not achieve beta yet, DNS proxy was added to VMs to eliminate the need for exposing kube-dns outside of the Kubernetes cluster. Additionally, auto registration was added for automating the creation of Workload Entry custom resources for services running on VMs, to further simplify operator’s experience for onboarding services running on VMs to the mesh.
Istio profile for OpenShift was added in 1.8. This profile simplifies users’ experiences for installing Istio on OpenShift.
Delay application container until proxy starts was added as a global configuration in 1.7. This feature ensures that application containers doesn’t start until sidecar containers are ready. Based on users’ feedback, we enabled this to be a pod-level configuration.
istioctl bug-report captures relevant cluster information and logs into an archive to help diagnose Istio problems. Run this command and attach the output archive when you submit an Istio bug!
Istio and IBM
IBM is a co-founder and second largest contributor to Istio, and the Istio technology is integral to our hybrid cloud strategy. The improvements in Istio 1.8 are clear and focused towards supporting IBM Cloud services anywhere, and Istio contributors from IBM are instrumental in driving many of these features forward. Istio’s real strength is connecting services running on different environments — whether they be on the edge, on-premises, or in the cloud — into a coherent, secure, observable, and controllable mesh of services.
IBM is incorporating Istio in many of our products, including:
- IBM Cloud Satellite is expected to provide a Mesh component, which uses federated Istio service mesh to connect clusters across locations, enabling policy, security, and visibility among applications. The external control plane deployment model could be leveraged to manage Istio control plane outside of users’ clusters, and Istio multicluster deployment model to provide federated service mesh.
- IBM Cloud Code Engine which leverages Knative and Istio to allow developers to easily deploy and manage modern serverless workloads.
In my view, Istio 1.8 is the best release out of Istio community. The community continues to focus on making Istio simpler to use, not only for single cluster use cases, but also for services running on VMs and multiple clusters as well. The multicluster graduation to beta and external control plane model enable vendors like IBM to offer fully managed, highly available resilient service mesh whether it is Istio on IBM Cloud or IBM Cloud Satellite or Red Hat OpenShift service mesh.
The continuous performance improvement of the control plane and data plane enables other project such as Knative or IBM Cloud Code Engine to build interesting developer experience on top of Istio.
Lin Sun is a Senior Technical Staff Member and Master Inventor at IBM. She is a maintainer on the Istio project and also serves on the Istio Steering Committee and Technical Oversight Committee.