This page describes changes you need to be aware of when upgrading from Istio 1.0.x to 1.1.x. Here we detail cases where we intentionally broke backwards compatibility. We also mention cases where backwards compatibility was preserved but new behavior was introduced that would be surprising to someone familiar with the use and operation of Istio 1.0.
For an overview of new features introduced with Istio 1.1, please refer to the 1.1 change notes.
We have increased the control plane and envoy sidecar’s required CPU and memory. It is critical to ensure your cluster have enough resource before proceeding the update.
Istio’s CRDs have been placed into their own Helm chart
istio-init. This prevents loss of custom resource data, facilitates the upgrade process, and enables Istio to evolve beyond a Helm-based installation. The upgrade documentation provides the proper procedures for upgrading from Istio 1.0.6 to Istio 1.1. Please follow these instructions carefully when upgrading. If
certmanageris desired, use the
--set certmanager=trueflag when installing both
istio-initand Istio charts with either
Many installation options have been added, removed, or changed. Refer to Installation Options Changes for a detailed summary of the changes.
istio-remotechart used for multicluster VPN and multicluster split horizon remote cluster installation has been consolidated into the Istio chart. To generate an equivalent
istio-remotechart, use the
Addons are no longer exposed via separate load balancers. Instead addons can now be optionally exposed via the Ingress Gateway. To expose an addon via the Ingress Gateway, please follow the Remotely Accessing Telemetry Addons guide.
The built-in Istio Statsd collector has been removed. Istio retains the capability of integrating with your own Statsd collector, using the
ingressseries of options for configuring a Kubernetes Ingress have been removed. Kubernetes Ingress is still functional and can be enabled using the
--set global.k8sIngress.enabled=trueflag. Check out Securing Kubernetes Ingress with Cert-Manager to learn how to secure your Kubernetes ingress resources.
Outbound traffic policy now defaults to
ALLOW_ANY. Traffic to unknown ports will be forwarded as-is. Traffic to known ports (e.g., port 80) will be matched with one of the services in the system and forwarded accordingly.
During sidecar routing to a service, destination rules for the target service in the same namespace as the sidecar will take precedence, followed by destination rules in the service’s namespace, and finally followed by destination rules in other namespaces if applicable.
We recommend storing gateway resources in the same namespace as the gateway workload (e.g.,
istio-systemin case of
istio-ingressgateway). When referring to gateway resources in virtual services, use the namespace/name format instead of using
The optional egress gateway is now disabled by default. It is enabled in the demo profile for users to explore but disabled in all other profiles by default. If you need to control and secure your outbound traffic through the egress gateway, you will need to enable
gateways.istio-egressgateway.enabled=truemanually in any of the non-demo profiles.
Policy & telemetry
istio-policycheck is now disabled by default. It is enabled in the demo profile for users to explore but disabled in all other profiles. This change is only for
istio-policyand not for
istio-telemetry. In order to re-enable policy checking, run
--set global.disablePolicyChecks=falseand re-apply the configuration.
The Service Graph component has now been deprecated in favor of Kiali.
- RBAC configuration has been modified to implement cluster scoping. The
RbacConfigresource has been replaced with the
ClusterRbacConfigresource. Refer to Migrating
ClusterRbacConfigfor migration instructions.