虽然 Kubernetes 提供了滚动更新作为默认部署策略，但一些用例需要非常规方法来部署或更新集群服务。

1.Kubernetes 部署概念

Kubernetes 使用部署资源，以声明方式更新应用程序。通过部署，集群管理员定义应用程序的生命周期，定义应用程序执行相关更新的方式。Kubernetes 部署提供了一种自动化方式来实现和维护集群对象和应用程序所需的状态。Kubernetes 后端无需人工干预即可管理部署过程，提供了一种安全且可重复的方式来执行应用程序更新工作。

Kubernetes 部署允许集群管理员：

  • 部署 pod 或副本集
  • 更新副本集和 pod
  • 回滚到早期版本
  • 暂停 / 继续部署
  • 扩展部署

2.Kubernetes 对象

Kubernetes 利用许多负载资源对象，将它们作为持久实体来管理集群状态。Kubernetes API 使用 Deployment、ReplicaSet、StatefulSet 和 DaemonSet 资源对应用程序进行​​声明式更新​​。

2.1 部署

Deployment（部署）是一种 Kubernetes 资源，用于定义和识别应用程序的所需状态。集群管理员在部署的 YAML 文件中描述了所需的状态，部署控制器使用该文件将实际状态逐渐更改为所需的状态。为了确保高可用性，部署控制器还不断对过程进行监控，并用健康的集群节点和 pod 替换失败的集群节点和 pod。

2.2 副本集

ReplicaSet（副本集）用于维护特定数量的 pod，以确保高可用性。ReplicaSet 的清单（manifest）文件包括以下字段：

  • 用于识别属于该集合的 pod 有哪些的选择器（selector）
  • 副本数，表示集合中应该有多少个 pod
  • 一个 pod 模板，用于显示新 pod 应创建哪些数据以满足 ReplicaSet 的标准

2.3 有状态集

StatefulSet（有状态集）对象管理​​有状态应用程序​​​中 pod 的​​部署和扩展​​​。该资源基于相同的容器规范管理 pod，然后确保一组 pod 的适当排序和唯一性。StatefulSet 的持久 pod 标识符让集群管理员能够将其负载连接到具有可用性保证的​​持久存储卷​​。

2.4 守护程序集

DaemonSets（守护程序集）确保一组节点运行一个 pod 副本，从而帮助维护应用程序部署。DaemonSet 资源主要用于管理各种代理的部署和生命周期，例如：

  • 每个节点上的集群存储代理
  • 日志收集守护进程
  • 节点监控守护进程

3.使用部署进行更新

Kubernetes 部署提供了一种可预测的方法来启动和停止 pod。这些资源让管理人员可以更轻松地​​迭代和自主部署、回滚更改和管理软件发布周期​​。Kubernetes 提供了各种部署策略来实现更小、更频繁的更新，因为它们提供了以下好处：

  • 更快的客户反馈以获得更好的特性优化
  • 缩短上市时间
  • 提高 DevOps 团队的生产力

默认情况下，Kubernetes 提供滚动更新作为标准部署策略，该策略每次用一个新版本替换一个 pod，以避免集群停机。除此之外，根据特性的目标和类型，Kubernetes 还支持各种高级部署策略——​​包括蓝绿、金丝雀和 A/B 部署​​。

4.Kubernetes 部署的高级策略

在实时生产环境中，将部署配置与路由特性结合使用是非常重要的，这样更新就只会影响特定版本。这使发布团队能够在提交完整版本之前测试实时环境中更新特性的有效性。

4.1 蓝绿部署

在蓝绿策略中，应用程序的新旧实例同时部署。用户可以访问现有版本（蓝色），而新版本（绿色）可供相同数量的实例供站点可靠性工程（SRE）和 QA 团队使用。一旦 QA 团队确认绿色版本通过了所有测试要求，用户就会被重定向到新版本。这是通过更新负载均衡服务的选择器字段中的版本标签来实现的。

当开发人员想要避免​​版本控制问题​​时，蓝绿部署最合适。

让我们假设应用程序的第一个版本是 v1.0.0，而可用的第二个版本是 v2.0.0。

apiVersion: v1
kind: Service
metadata:
  name: darwin-service-a
spec:
  type: LoadBalancer
  selector:
    app: nginx
    version: v1.0.0
  ports:
       - name: http
         port: 80
         targetPort: 80

下面是指向第二个版本的服务：

apiVersion: v1
kind: Service
metadata:
  name: darwin-service-b
spec:
  type: LoadBalancer
  selector:
    app: nginx
    version: v2.0.0
  ports:
       - name: http
         port: 80
         targetPort: http

请求的测试执行且第二个版本被许可后，第一个版本的 selector 就被改为 v2.0.0：

apiVersion: v1
kind: Service
metadata:
  name: darwin-service-a
spec:
  type: LoadBalancer
  selector:
    app: nginx
    version: v2.0.0
  ports:
       - name: http
         port: 80
         targetPort: http

如果应用程序按预期运行，v1.0.0 将被丢弃。

4.2 金丝雀部署

在金丝雀策略中，一部分用户被路由到托管新版本的 pod。该子集逐渐增加，而连接到旧版本的子集则减少。该策略会对比连接到两个版本的用户子集。如果未检测到错误，则将新版本推送给其余用户。

部署第一个应用程序：

$ kubectl apply -f darwin-v1.yaml

将其扩展到所需数量的副本：

$ kubectl scale --replicas=9 deploy darwin-v1

部署版本 2 的一个实例：

$ kubectl apply -f darwin-v2.yaml

如第二个版本成功部署，则对其进行测试：

$ service=$(minikube service darwin --url)$ while sleep 0.1; do curl "$service"; done

如果部署成功，扩展版本 2 的实例数量：

$ kubectl scale --replicas=10 deploy darwin-v2

当所有副本上线后，就可以优雅地删除第一个版本：

$ kubectl delete deploy darwin-v1

4.3 A/B 部署

通过 A/B 部署，管理员可以将特定的用户子集路由到具有一些限制和 / 或条件的较新版本上。这些部署主要用于评估用户群对某些特性的响应。A/B 部署也被称为“暗启动”，​​因为用户在测试期间不了解应用包含哪些新特性​​。

  1. 假设集群上已经安装了 Istio，第一步是部署两个版本的应用：
$ kubectl apply -f darwin-v1.yaml -f darwin-v2.yaml
  1. 然后可以通过 Istio 网关公开这些版本，使用以下命令将请求匹配到第一个服务：
$ kubectl apply -f ./gateway.yaml -f ./virtualservice.yaml
  1. 然后可以使用以下命令根据权重应用 Istio VirtualService 规则：
$ kubectl apply -f ./virtualservice-weight.yaml

这会以 1:10 的比例在版本之间分配流量权重。要转移流量权重，可编辑每个服务的权重，然后通过 Kubernetes CLI 更新 VirtualService 规则。

5.何时使用每种高级部署策略

蓝绿策略

特点：专注于渐进式交付，这对于在应用程序后端测试特性是非常重要的。

优点：实现即时推送和回滚；允许管理员在一次升级中更改整个集群的状态；消除版本控制问题。

缺点：在生产发布之前需要两倍数量的资源和适当的平台测试。

金丝雀策略

特点：在用户仍在运行旧版本的实例时测试新版本；被认为是避免 API 版本控制问题的最佳选择。

优点：通过错误率对比可方便监控性能表现；实现快速回滚；包含用户体验测试。

缺点：微调流量分布的成本很高；推送速度较慢。

A/B 策略

特点：向用户提供新旧应用程序版本，然后对比它们的体验；主要用于前端部署和 QA 测试流程不足的情况。

优点：允许多个版本并行运行；实现性能监控。

缺点：导致部署缓慢；带来了代价高昂的流量均衡。