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
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.
Alpha security policy APIs removed (Authentication and RBAC policies) 🔗︎
The most important removed resources here are the
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 (usually
istio-system) for the
- 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.
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).
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).
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 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, 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! :)
appProtocol to 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, our Istio distribution. Backyards operationalizes the service mesh to bring deep observability, convenient management, and policy-based security to modern container-based applications.