Follow this flow to upgrade an existing Istio deployment, including both the control plane and the sidecar proxies, to a new release of Istio. The upgrade process may install new binaries and may change configuration and API schemas. The upgrade process may result in service downtime. To minimize downtime, please ensure your Istio control plane components and your applications are highly available with multiple replicas.
This flow assumes that the Istio components are installed and upgraded in the
Download the new Istio release and change directory to the new release directory.
Control plane upgrade
The Istio control plane components include: Citadel, Ingress gateway, Egress gateway, Pilot, Galley, Policy, Telemetry and Sidecar injector. Choose one of the following two mutually exclusive options to update the control plane:
You can use Kubernetes’ rolling update mechanism to upgrade the control plane components.
This is suitable for cases where
kubectl apply was used to deploy the Istio components,
including configurations generated using
kubectl applyto upgrade all the Istio’s CRDs. Wait a few seconds for the Kubernetes API server to receive the upgraded CRDs:
$ for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done
Add Istio’s core components to a Kubernetes manifest file, for example.
$ helm template install/kubernetes/helm/istio --name istio \ --namespace istio-system > $HOME/istio.yaml
If you want to enable global mutual TLS, set
truefor the last command:
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \ --set global.mtls.enabled=true --set global.controlPlaneSecurityEnabled=true > $HOME/istio-auth.yaml
If using Kubernetes versions prior to 1.9, you should add
Upgrade the Istio control plane components via the manifest, for example:
$ kubectl apply -f $HOME/istio.yaml
$ kubectl apply -f $HOME/istio-auth.yaml
The rolling update process will upgrade all deployments and configmaps to the new version. After this process finishes, your Istio control plane should be updated to the new version. Your existing application should continue to work without any change. If there is any critical issue with the new control plane, you can rollback the changes by applying the yaml files from the old version.
If you installed Istio using Helm and Tiller, the preferred upgrade option is to let Helm take care of the upgrade.
istio-initchart to update all the Istio Custom Resource Definitions (CRDs).
$ helm upgrade --install istio-init install/kubernetes/helm/istio-init --namespace istio-system
Check that all the CRD creation jobs completed successfully to verify that the Kubernetes API server received all the CRDs:
$ kubectl get job --namespace istio-system | grep istio-init-crd
$ helm upgrade istio install/kubernetes/helm/istio --namespace istio-system
After the control plane upgrade, the applications already running Istio will still be using an older sidecar. To upgrade the sidecar, you will need to re-inject it.
If you’re using automatic sidecar injection, you can upgrade the sidecar by doing a rolling update for all the pods, so that the new version of the sidecar will be automatically re-injected. There are some tricks to reload all pods. E.g. There is a sample bash script which triggers the rolling update by patching the grace termination period.
If you’re using manual injection, you can upgrade the sidecar by executing:
$ kubectl apply -f <(istioctl kube-inject -f $ORIGINAL_DEPLOYMENT_YAML)
If the sidecar was previously injected with some customized inject configuration files, you will need to change the version tag in the configuration files to the new version and re-inject the sidecar as follows:
$ kubectl apply -f <(istioctl kube-inject \ --injectConfigFile inject-config.yaml \ --filename $ORIGINAL_DEPLOYMENT_YAML)
Migrating per-service mutual TLS enablement via annotations to authentication policy
For example, if you install Istio with mutual TLS enabled, and disable it for service
foo using a service annotation like below:
kind: Service metadata: name: foo namespace: bar annotations: auth.istio.io/8000: NONE
You need to replace this with this authentication policy and destination rule (deleting the old annotation is optional)
apiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata: name: "disable-mTLS-foo" namespace: bar spec: targets: - name: foo ports: - number: 8000 peers: --- apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "disable-mTLS-foo" namespace: "bar" spec: host: "foo" trafficPolicy: tls: mode: ISTIO_MUTUAL portLevelSettings: - port: number: 8000 tls: mode: DISABLE
If you already have destination rules for
foo, you must edit that rule instead of creating a new one.
When create a new destination rule, make sure to include other settings, i.e
connection pool and
outlier detection if necessary.
foo doesn’t have sidecar, you can skip authentication policy, but still need to add destination rule.
If 8000 is the only port that service
foo provides (or you want to disable mutual TLS for all ports), the policies can be simplified as:
apiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata: name: "disable-mTLS-foo" namespace: bar spec: targets: - name: foo peers: --- apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "disable-mTLS-foo" namespace: "bar" spec: host: "foo" trafficPolicy: tls: mode: DISABLE
mtls_excluded_services configuration to destination rules
If you installed Istio with mutual TLS enabled, and used the mesh configuration option
disable mutual TLS when connecting to these services (e.g Kubernetes API server), you need to replace this by adding a destination rule. For example:
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: "kubernetes-master" namespace: "default" spec: host: "kubernetes.default.svc.cluster.local" trafficPolicy: tls: mode: DISABLE
RbacConfig is deprecated due to a bug. You must
ClusterRbacConfig if you are currently using
RbacConfig. The bug reduces the scope of
the object to be namespace-scoped in some cases. The
ClusterRbacConfig follows the exact same
specification as the
RbacConfig but with the correct cluster scope implementation.
To automate the migration, we developed the
The script is included in the Istio installation package.
Download and run the script with the following command:
$ curl -L https://raw.githubusercontent.com/istio/istio/master/tools/convert_RbacConfig_to_ClusterRbacConfig.sh | sh -
The script automates the following operations:
The script creates the cluster RBAC configuration with same specification as the existing RBAC configuration because Kubernetes doesn’t allow the value of
kind:in a custom resource to change after it’s created.
For example, if you have the following RBAC configuration:
apiVersion: "rbac.istio.io/v1alpha1" kind: RbacConfig metadata: name: default spec: mode: 'ON_WITH_INCLUSION' inclusion: namespaces: ["default"]
The script creates the following cluster RBAC configuration:
apiVersion: "rbac.istio.io/v1alpha1" kind: ClusterRbacConfig metadata: name: default spec: mode: 'ON_WITH_INCLUSION' inclusion: namespaces: ["default"]
The script applies the configuration and waits for a few seconds to let the configuration to take effect.
The script deletes the previous RBAC configuration custom resource after applying the cluster RBAC configuration successfully.