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.
We’ll group the changes to three categories:
Then, we will detail the first two groups of changes.
High impact changes:
Under the radar changes:
appProtocolto select the protocol for a port introduced in Kubernetes 1.18.
Other notable changes:
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.
The most important removed resources here are the
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:
MeshPolicy) for the mesh-wide setting, instead you should provide the root Istio namespace (usually
istio-system) for the
STRICT, finally, there is a dedicated
DISABLEmTLS mode to indicate plain-text communication only (there is
UNSETas well to explicitly declare that settings are inherited).
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.
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.
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! 🙂
appProtocolto select the protocol for a port introduced in Kubernetes 1.18
A new field was added in Kubernetes 1.18 to
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.
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.
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.