如果您想使用 Deployment 将最新的应用程序版本发布给一部分用户（或服务器），您可以为每个版本创建一个 Deployment，此时，应用程序的新旧两个版本都可以同时获得生产上的流量。

使用kubectl执行金丝雀发布

  • 部署第一个版本

第一个版本的 Deployment 包含了 3 个Pod副本，Service 通过 label selector app: nginx 选择对应的 Pod，nginx 的标签为 1.7.9

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: nginx-deployment
  5.   labels:
  6.     app: nginx
  7. spec:
  8.   replicas: 3
  9.   selector:
  10.     matchLabels:
  11.       app: nginx
  12.   template:
  13.     metadata:
  14.       labels:
  15.         app: nginx
  16.     spec:
  17.       containers:
  18.       - name: nginx
  19.         image: nginx:1.7.9
  20. ---
  21. apiVersion: v1
  22. kind: Service
  23. metadata:
  24.   name: nginx-service
  25.   labels:
  26.     app: nginx
  27. spec:
  28.   selector:
  29.     app: nginx
  30.   ports:
  31.   - name: nginx-port
  32.     protocol: TCP
  33.     port: 80
  34.     nodePort: 32600
  35.     targetPort: 80
  36.   type: NodePort
  • 假设此时想要发布新的版本 nginx 1.8.0，可以创建第二个 Deployment： ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment-canary labels: app: nginx track: canary spec: replicas: 1 selector: matchLabels:
    1. app: nginx
    2. track: canary
    template: metadata:
    1. labels:
    2.   app: nginx
    3.   track: canary
    spec:
    1. containers:
    2. - name: nginx
    3.   image: nginx:1.8.0

```

TIP

  • 因为 Service 的LabelSelector 是 app: nginx，由 nginx-deployment 和 nginx-deployment-canary 创建的 Pod 都带有标签 app: nginx，所以，Service 的流量将会在两个 release 之间分配
  • 在新旧版本之间，流量分配的比例为两个版本副本数的比例，此处为 1:3
  • 当您确定新的版本没有问题之后，可以将 nginx-deployment 的镜像标签修改为新版本的镜像标签，并在完成对 nginx-deployment 的滚动更新之后，删除 nginx-deployment-canary 这个 Deployment

使用Kuboard执行金丝雀发布

在 Kuboard 执行金丝雀发布的过程，与使用 kubectl 的过程相同，此处特别说明的一点是，当使用 Kuboard 创建 web-nginx-canary Deployment时，可以在原工作负载上点击 复制 按钮，如下图所示：
image.png

在弹出对话框的 名称 字段中填写 web-nginx-canary，如下图所示：
image.png

如何解决其Pod 的标签被 web-nginx 的Service包含的问题：

  • 当填写部署的名称 web-nginx-canary 之后，将默认创建两个标签，且不可修改：k8s.eip.work/layer:web 和 k8s.eip.work/name:web-nginx-canary
  • 此时，手工创建标签 k8s.eip.work/name:web-nginx，可以覆盖原默认创建的标签
  • 完成创建后，web-nginx-canary 的 Pod 也包含标签 k8s.eip.work/layer:web 和 k8s.eip.work/name:web-nginx，可以被 web-nginx 的Service选中
  • 通过 Kuboard 创建 web-nginx-canary 部署时，无需配置 Service 和 Ingress

image.png

局限性 按照 Kubernetes 默认支持的这种方式进行金丝雀发布，有一定的局限性：

  • 不能根据用户注册时间、地区等请求中的内容属性进行流量分配
  • 同一个用户如果多次调用该 Service，有可能第一次请求到了旧版本的 Pod，第二次请求到了新版本的 Pod


TIP 在 Kubernetes 中不能解决上述局限性的原因是：Kubernetes Service 只在 TCP 层面解决负载均衡的问题，并不对请求响应的消息内容做任何解析和识别。如果想要更完善地实现金丝雀发布，可以考虑如下三种选择：

  • 业务代码编码实现
  • Spring Cloud 灰度发布
  • Istio 灰度发布