无需停机即可升级 Istio

在撰写本文时，Istio 正在发布 1.11 版本，因此现在是我们讨论一种无需停机即可升级 Istio 的方法的好时机。如果你已经使用 Istio 一段时间并将其部署到你的环境中，那么你可能正在运行一个较旧的版本。从 8 月 24 日起，官方不再支持Istio 1.9 。这意味着你的旧版本不再接收确保安全的关键补丁和更新。

升级是个好主意，所以让我们偿还你的一些技术债务并升级你的 Istio 部署，以便你的应用程序可以利用最新功能并保持安全。本文将介绍一种架构和流程，可帮助你使 Istio 部署恢复合规性，并为你在未来进行更轻松的升级做好准备。

一次升级一个版本

Istio建议你一次升级一个版本，升级到 1.8后，你可以跳过 1.9 到 1.10。这意味着如果你还在使用 Istio 1.6，他们建议你升级 3 次到 1.10（1.6→1.7→1.8→1.10）。通过下面列出的建议架构，你可以通过并排测试这些版本来跳过这些版本。这可能会为你节省数小时，并使你能够安全高效地完成部署或升级。

Istio.io 升级警告

Istio 的两种故障模式

首先，让我们谈谈 Istio 由于中断而影响你的工作负载的两种主要方式。

第一个故障模式是Istio sidecar 的配置丢失。如果你的 istio-agent sidecar 无法与 Istiod 通信，或与发送的配置不兼容，你的工作负载将无法加入网格或与网格通信。这甚至会影响现有的工作负载，导致你可能会尝试访问不再存在的工作负载，新的工作负载也将无法加入。

由于这种类型的中断，建议 istio-agents 匹配并保留与控制平面 (Istiod) 相同的版本。在升级过程中，现有的控制平面部署保持原位而不是直接升级。

Istio 控制平面蓝/绿部署

第二种故障模式通常更为严重，是通过入口网关的流量丢失。与失去控制平面不同，入口网关的中断将对你的用户产生直接影响。由于这是流量流动的关键路径，因此在不停机的情况下升级 Istio 时应格外小心。这包括在升级失败时能够回退到现有正常的网关。这就是为什么建议入口网关进行蓝/绿部署的原因。下面显示的是使用 Kubernetes LoadBalanced 服务的升级示例，该服务可以为流量选择“蓝色”或“绿色”入口网关。

网关蓝/绿部署升级

无需停机即可升级 Istio 的架构

上文提到的两个故障如何解决呢? 接下俩, 我将展示如何在不停机的情况下部署和升级 Istio。该解决方案在很大程度上依赖于 Istio Canary Deployment功能。它在 1.6 中引入，允许我们并排部署多个版本的 Istio 控制平面并迁移工作负载。我们还可以使用相同的机制来使用自己的托管 LoadBalanced 服务来部署入口网关。

零停机下升级 Istio 部署架构

当前最好的方法是使用Istio Operator 来部署 Istio 组件。由于不同版本之间的Operator 兼容性问题，我们必须为每个版本升级部署一个新的Operator。由于这个限制，通过 Helm 部署 Istio 可能比较容易。一旦我们部署了 Operator，我们就可以部署多个 IstioOperator配置（一个用于 Istiod，一个用于网关）。下面是示例配置。

下面是一个带有修订标签的 Istiod 部署示例。它将由 1-9-7 Istio operator 部署。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: 1-9-7
  namespace: istio-system
spec:
  profile: minimal
  tag: 1.9.7
  revision: 1-9-7
 
  # Traffic management feature
  components:
    # Istio Gateway feature
    # Disable gateways deployments because they will be in separate IstioOperator configs
    ingressGateways:
    - name: istio-ingressgateway
      enabled: false
    - name: istio-eastwestgateway
      enabled: false
    egressGateways:
    - name: istio-egressgateway
      enabled: false

这是带有自定义 LoadBalanced 服务的示例网关部署。我们可以使用服务选择器来蓝/绿网关部署的未来版本。注意：我们必须将入口网关服务修改为一个ClusterIP服务，这样它就不会创建自己的负载均衡器。

由于我们创建了自己的 LoadBalanced 服务，因此告诉 Istio 为此网关创建一个 ClusterIP 服务。

apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-gateways
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
    # select the 1-9-7 revision
    version: 1-9-7
  ports:
  - name: status-port
    port: 15021
    targetPort: 15021
  - name: http2
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8443
  - name: tcp
    port: 31400
    targetPort: 31400
  - name: tls
    port: 15443
    targetPort: 15443
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: ingress-gateway-1-9-7
  namespace: istio-gateways
spec:
  profile: empty
  tag: 1.9.7
  revision: 1-9-7
  components:
    ingressGateways:
      - name: istio-ingressgateway-1-9-7
        namespace: istio-gateways
        enabled: true
        label:
          istio: ingressgateway
          version: 1-9-7
          app: istio-ingressgateway
        k8s:
          service:
            # Since we created our own LoadBalanced service, tell istio to create a ClusterIP service for this gateway
            type: ClusterIP

如何迁移你的 Sidecar

部署新的 Istio 控制平面后，你可以将应用程序工作负载迁移到新的 Istiod 部署。如果你已经在使用revision 和revision 标签，可以使用类似更新命名空间标签istio.io/rev=<new_revision>方式更新它。然后，你需要重新创建 Pod 以获取更新的Sidecar。

这是一个用于滚动更新 sidecar 版本的示例。

kubectl rollout restart deployment/nginx -n nginx

迁移到修订版

如果你当前没有使用修订版，迁移到它们仍然很容易并建议你使用。迁移模式与版本之间的升级非常相似。我们建议在现有部署旁边部署相同的 Istio 版本，但添加了修订标签。然后，你可以通过删除istio-injection=enabled标签, 并添加新的修订标签istio.io/rev=<revision>来迁移你的应用程序Sidecar。

然而，迁移网关可能会更加困难。如果你当前的 Istio 部署拥有 LoadBalanced 服务，则在删除现有基础架构时必须格外小心。在某些情况下，迁移到新的 LoadBalanced 服务可能更容易。

演示: 无需停机即可升级 Istio

如果你有兴趣自己尝试，我们已经创建了一个Istio 升级演示Demo来测试它。我们部署了两个版本的 Istio 并迁移 Bookinfo 应用程序，同时从它们请求流量。完成后，我们会查看该流量以确保其正常运行。

译文链接: https://thenewstack.io/upgrading-istio-without-downtime/