Upgrade Notes
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.
Installation
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. Ifcertmanager
is desired, use the--set certmanager=true
flag when installing bothistio-init
and Istio charts with eithertemplate
ortiller
installation modes.Many installation options have been added, removed, or changed. Refer to Installation Options Changes for a detailed summary of the changes.
The 1.0
istio-remote
chart used for multicluster VPN and multicluster shared gateways remote cluster installation has been consolidated into the Istio chart. To generate an equivalentistio-remote
chart, use the--set global.istioRemote=true
flag.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
--set global.envoyStatsd.enabled=true
flag.The
ingress
series 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=true
flag. Check out Securing Kubernetes Ingress with Cert-Manager to learn how to secure your Kubernetes ingress resources.
Traffic management
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-system
in case ofistio-ingressgateway
). When referring to gateway resources in virtual services, use the namespace/name format instead of usingname.namespace.svc.cluster.local
.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=true
manually in any of the non-demo profiles.
Policy & telemetry
istio-policy
check 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 foristio-policy
and not foristio-telemetry
. In order to re-enable policy checking, runhelm template
with--set global.disablePolicyChecks=false
and re-apply the configuration.The Service Graph component has now been deprecated in favor of Kiali.
Security
- RBAC configuration has been modified to implement cluster scoping. The
RbacConfig
resource has been replaced with theClusterRbacConfig
resource. Refer to MigratingRbacConfig
toClusterRbacConfig
for migration instructions.