升级步骤

在下面的步骤中，我们假设 Istio 组件在 namespace 中安装和升级。

Istio 控制平面组件包括：Citadel、Ingress 网关、Egress 网关、Pilot、Policy、Telemetry 和 Sidecar 注入器。我们可以使用 Kubernetes 的滚动更新机制来升级控制平面组件。

您可以使用 Kubernetes 的滚动更新机制来升级控制平面组件。这适用于使用 kubectl apply 部署 Istio 组件的情况，包括使用 helm template 生成的配置。

使用 kubectl apply 升级 Istio 所有的 CRD。稍微等待几秒钟，让 Kubernetes API 服务器接收升级后的 CRD：

$ for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done

例如，将 Istio 的核心组件添加到 Kubernetes 的清单文件中。

$ helm template install/kubernetes/helm/istio --name istio \
--namespace istio-system > $HOME/istio.yaml

如果要启用，请将 global.mtls.enabled 和 global.controlPlaneSecurityEnabled 设置为 true 以获取最后一个命令：

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
--set global.mtls.enabled=true --set global.controlPlaneSecurityEnabled=true > $HOME/istio-auth.yaml

如果使用 1.9 之前的 Kubernetes 版本，则应添加 —set sidecarInjectorWebhook.enabled=false。

通过清单升级 Istio 控制平面组件，例如：

$ kubectl apply -f $HOME/istio.yaml

$ kubectl apply -f $HOME/istio-auth.yaml

滚动更新过程会将所有部署和配置升级到新版本。完成此过程后，您的 Istio 控制平面应该会更新为新版本。您现有的应用程序应该继续工作。如果新控制平面存在任何严重问题，您可以通过应用旧版本的 yaml 文件来回滚更改。

如果你使用 Helm 和 Tiller 安装了 Istio，首选升级选项是让 Helm 负责升级。

升级 istio-init chart 以更新所有 Istio （CRD）。

检查所有的 CRD 创建 job 是否已成功完成，以验证 Kubernetes API 服务器是否已收到所有 CRD：

$ kubectl get job --namespace istio-system | grep istio-init-crd

升级 istio chart：

$ helm upgrade istio install/kubernetes/helm/istio --namespace istio-system

Sidecar 升级

控制平面升级后，已经运行 Istio 的应用程序仍将使用旧版本的 sidecar。要想升级 sidecar，您需要重新注入它。

如果您使用自动 sidecar 注入（automatic sidecar injection），您可以通过对所有 pod 进行滚动升级来升级 sidecar，这样新版本的 sidecar 将被自动重新注入。一些技巧可以重新加载所有 pod。例如，有一个可以通过 patch 优雅结束时长（grace termination period）来触发滚动更新。

如果您使用手动注入，可以通过执行以下命令来升级 sidecar：

$ kubectl apply -f <(istioctl kube-inject -f $ORIGINAL_DEPLOYMENT_YAML)

如果 sidecar 以前被注入了一些定制的注入配置文件，您需要将配置文件中的版本标签更改为新文件版本并像下面这样重新注入 sidecar：

$ kubectl apply -f <(istioctl kube-inject \
     --injectConfigFile inject-config.yaml \
     --filename $ORIGINAL_DEPLOYMENT_YAML)

如果使用 service annotation 覆盖 service 的全局双向 TLS，则需要将其替换为认证策略和。

例如，如果您在启用双向 TLS 的情况下安装 Istio，并使用如下所示的 service annotation 对 service foo 禁用它：

metadata:
  name: foo
  namespace: bar
  annotations:
    auth.istio.io/8000: NONE

您需要用此身份验证策略和目标规则替换它（删除旧 annotation 是可选的）

如果 8000 是 service foo 提供的唯一端口（或者您希望禁用所有端口的双向 TLS），则策略可以简化为：

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

如果您在启用双向 TLS 的情况下安装了 Istio，并且使用网格配置 mtls_excluded_services 来在连接这些服务（例如 Kubernetes API server）时禁用双向 TLS，则需要通过添加目标规则来替换它。例如：

apiVersion: networking.istio.io/v1alpha3
metadata:
  namespace: "default"
spec:
  host: "kubernetes.default.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: DISABLE

RbacConfig 因为 bug 已经被废弃。如果你正在使用 RbacConfig，必须迁移到 ClusterRbacConfig。这个 bug 在某些情况下会将这个对象的范围降低到 namespace 级别。ClusterRbacConfig 的声明跟 RbacConfig 完全一样，但是以正确的集群级别范围实现。

为了自动化迁移，我们开发了脚本convert_RbacConfig_to_ClusterRbacConfig.sh. 这个脚本在中。

下载并运行如下命令：

$ curl -L https://raw.githubusercontent.com/istio/istio/release-1.1git/tools/convert_RbacConfig_to_ClusterRbacConfig.sh | sh -

这个脚本自动化下如下操作：

这个脚本创建跟已经存在的 RBAC 配置一样的集群 RBAC 配置，因为 Kubernetes 不允许自定义资源的 kind: 在被创建之后修改。

例如，如果你创建如下 RBAC 配置：

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    namespaces: ["default"]

这个脚本创建如下的集群 RBAC 配置：

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion: