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
appProtocol to 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 (usually istio-system) for the PeerAuthentication resource.
- 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
PERMISSIVE and STRICT, finally, there is a dedicated DISABLE mTLS mode to indicate plain-text communication only (there is UNSET as 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.
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.
