Istio 1.6 is around the corner and it continues where 1.5 left off: it simplifies the architecture and improves the operational experience. In this post we’ll review what’s new in Istio 1.6 and dig deep on the important changes.
The Backyards 1.3 release is already based on Istio 1.6.
Istio 1.6 changes 🔗︎
We’ll group the changes to three categories:
- High impact changes (mostly backward incompatible removals)
- Under the radar changes (smaller changes, but we believe they are interesting/useful)
- Other changes (honorable mentions)
Then, we will detail the first two groups of changes.
Highlighted changes 🔗︎
High impact changes:
- Legacy Istio control plane components removed completely (Citadel, Galley, Pilot, Sidecar Injector)
- Alpha security policy APIs removed (Authentication and RBAC policies)
- Legacy Helm charts removed
Under the radar changes:
- Gateway deployments can be run without root privileges
- Single mesh multi-cluster enhancement
- Use
appProtocolto select the protocol for a port introduced in Kubernetes 1.18.
Other notable changes:
- SDS is used by default
- WorkloadEntry CRD is introduced for non-Kubernetes workloads to join the mesh
- Experimental support for the Kubernetes Service APIs added
- Gateways status port moved from 15020 to 15021
High impact changes 🔗︎
Legacy Istio control plane components removed completely (Citadel, Galley, Pilot, Sidecar Injector) 🔗︎
Istio 1.5 moved towards a monolithic model with istiod and made it the default option right away. One minor release later, in Istio 1.6, the legacy microservice-based Istio control plane architecture is removed completely.
From earlier minor versions it is advised to upgrade one minor version at a time.
At Istio 1.5, you need to switch to the istiod model and then you should be able to upgrade to 1.6.
To do this, it is advised to use an Istio operator to help you with the process. Our open source Banzai Cloud Istio operator introduced seamless control plane upgrades over a year ago.
Alpha security policy APIs removed (Authentication and RBAC policies) 🔗︎
The most important removed resources here are the MeshPolicy and Policy resources.
These resources were used to manage the mTLS settings mesh-wide, namespace-wide and service specifically.
To achieve the same, you need to migrate your configurations to the new beta API, to PeerAuthentication CRs.
When migrating, you should pay attention to the following changes:
- There is no separate CR (
MeshPolicy) for the mesh-wide setting, instead you should provide the root Istio namespace (usuallyistio-system) for thePeerAuthenticationresource. - With the removed API you could manage mTLS settings based on service names, but with the new API you need to provide workload labels to achieve the same.
- Besides
PERMISSIVEandSTRICT, finally, there is a dedicatedDISABLEmTLS mode to indicate plain-text communication only (there isUNSETas well to explicitly declare that settings are inherited).
Legacy Helm charts removed 🔗︎
If you still use the Helm-based Istio install, now is the time to investigate another option either with istioctl or with our Istio operator, because the legacy Helm charts are removed for Istio 1.6.
Under the radar changes 🔗︎
Gateway deployments can be run without root privileges 🔗︎
The ingress and egress gateway proxy containers can now run without root privileges. The user-facing change due to this modification is that you must use higher listening port numbers for the gateway deployments (higher than 1024).
This is not enabled in upstream Istio by default, but we do enable it in our open source Banzai Cloud Istio operator and in Backyards (now Cisco Service Mesh Manager) for our customers due to security considerations.
Single mesh multi-cluster enhanced 🔗︎
Istio has always supported multiple multi-cluster architectures, but they were usually not easy to configure and were often error prone. This is why we have striven for making multi-cluster management as seamless as possible for our Backyards (now Cisco Service Mesh Manager) customers. With the Istio 1.6 release the single mesh multi-cluster scenario is getting more simple.
Without going into details, in Istio 1.6 there is a mode where there are no active components deployed for the remote clusters, only the sidecar proxies in the application containers (and a few configurations like sidecar configmap, CA cert and mutating webhook config).
We believe this is an important change: it brings us much closer to a solution where Istio could potentially be run as a service in the future. (Note that besides Backyards (now Cisco Service Mesh Manager), which can run on any Kubernetes cluster and your choice of cloud or datacenter, we are actively working on an Istio as a service solution as well.). This might seem far-fetched at first, but actually it is something which will be a reality soon. Stay tuned! :)
Use appProtocol to select the protocol for a port introduced in Kubernetes 1.18 🔗︎
A new field was added in Kubernetes 1.18 to Service and Endpoint resources to specify application protocol in a simple way.
Istio 1.6 supports this new field to determine the protocol used for a given service port.
Takeaway 🔗︎
Istio 1.6 made another step towards reduced complexity, better security, and higher stability which likely predestines Istio to increased production adoption in the future.
If you’d like to kickstart your Istio experience try out Backyards (now Cisco Service Mesh Manager), our Istio distribution. Backyards (now Cisco Service Mesh Manager) operationalizes the service mesh to bring deep observability, convenient management, and policy-based security to modern container-based applications.
Check out how easy it is to set up a multi-cluster service mesh with Backyards, or read more about the latest Backyards release here.
Check out Backyards in action on your own clusters!
Want to know more? Get in touch with us, or delve into the details of the latest release.
Or just take a look at some of the Istio features that Backyards automates and simplifies for you, and which we’ve already blogged about.
