升级步骤

本页介绍如何将现有的 Istio 部署（包括控制平面和数据平面）升级到新版本。 升级过程可能涉及到新的二进制文件、配置以及 API 结构等其他更改。升级过程还有可能导致一些服务中断。为了最大限度地减少停机时间，请使用多副本以保证 Istio 控制平面组件和应用程序具有高可用性。

在下面的步骤中，我们假设 Istio 组件在 istio-system 命名空间中安装和升级。

升级步骤

1. 下载新的 Istio 版本并将目录更改为新版本目录。

控制平面升级

Istio 控制平面组件包括：Citadel、Ingress 网关、Egress 网关、Pilot、Galley、Policy、Telemetry 和 Sidecar 注入器。下面提供两种升级控制平面的方法，这两种方法是互斥的：

Sidecar 升级

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

如果使用自动 Sidecar 注入，可以对所有 Pod 进行滚动升级，升级过程中，新版本的 Sidecar 将被自动重新注入。一些技巧可以重新加载所有 Pod。例如，有一个 bash 脚本可以通过对 terminationGracePeriodSeconds 字段的 patch 来触发滚动更新。

如果您使用手动注入，可以通过执行以下命令来升级 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)

把通过注解方式启用的以服务为单位的双向 TLS 配置转化为认证策略

如果对一个服务使用注解方式覆盖了全局双向 TLS 配置，则需要将其替换为认证策略和目的规则。

例如，在安装 Istio 的时候启用了双向 TLS，并使用如下注解在服务 foo 中禁止这一功能：

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

就需要用身份验证策略和目标规则替换它（注解可以删除）

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

如果您已经有 foo 的目标规则，则必须编辑该规则而不是创建新规则。 创建新的目标规则时，如有必要，还可以包含其它配置，例如 load balancer、connection pool 和 outlier detection。 最后，如果 foo 没有 Sidecar，你可以跳过身份验证策略，但仍然需要添加目标规则。

如果 8000 是 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

将 mtls_excluded_services 配置转换为目标规则

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

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 到 ClusterRbacConfig

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

为了自动化迁移过程，我们开发了脚本convert_RbacConfig_to_ClusterRbacConfig.sh. 这个脚本在 Istio 的安装包中。

下载并运行如下命令：

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

这个脚本自动完成下如下操作：

1. 创建跟已经存在的 RBAC 配置一样的集群 RBAC 配置，因为在 Kubernetes 中，已经创建的资源，其 kind 字段是不允许进行修改的。

   例如集群之中创建了下面的 RbacConfig：

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

   这个脚本就会创建如下的 ClusterRbacConfig，来进行替换：

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

2. 应用 ClusterRbacConfig，并等待几秒钟以使配置生效。

3. 在成功应用 ClusterRbacConfig 之后，删除之前的 RbacConfig。