乐趣区

关于云原生:边开飞机边换引擎我们造了个新功能保障业务流量无损迁移

jiezi

作者 | 顾静（子白）
起源 | 阿里巴巴云原生公众号

容器化部署利用能够升高企业老本，晋升研发效率，解放运维人员。据 Gartner 预计，到 2022 年，将有 75% 的企业将在生产中运行容器化应用程序。Kubernetes 是企业部署容器化利用的首选框架。因为 Kubernetes 部署及运维的复杂性，越来越多的客户抉择将业务从 ECS 或者自建的 Kubernetes 迁徙到阿里云托管版 Kubernetes —— ACK 中。然而，如何保障业务流量的平滑迁徙成为一大挑战。

Cloud Controller Manager（CCM）是 ACK 的一个系统核心组件，负责对接 Kubernetes 与云上根底产品如 CLB、VPC、DNS 等。当 Service 的类型设置为 Type=LoadBalancer 时，CCM 会为该 Service 创立或配置阿里云负载平衡 CLB。当 Service 对应的后端 Endpoint 或者集群节点发生变化时，CCM 会自动更新 CLB 的后端虚构服务器组。此外，CCM 还提供了许多阿里云注解，反对丰盛的负载平衡能力。

近期 CCM 公布了一个新个性—— 反对在同一个 CLB 后端挂载集群内节点和集群外 ECS，借助这一个性能够解决业务容器化过程中流量平滑迁徙的难题 。

场景一：利用容器化革新（流量平滑迁徙）

对于一个 CLB，反对将流量转发至集群内及集群外节点

1）操作步骤

  • 登录 CLB 控制台创立 CLB，记录 CLB ID (“lb-xxxxx”)
  • 创立 Service

设置 service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners 为 false，不治理监听信息。

CCM 会主动创立对应的虚构服务器组。

cat <<EOF |kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "lb-xxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners: "false"
  labels:
    app: nignx
  name: my-nginx-svc
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
EOF
  • 登录 CLB 控制台，创立监听并关联虚构服务器组
  • 登录 CLB 控制台，手动在虚构服务器组中增加集群外 ECS 并设置权重

2）预期后果

配置实现后，在 CLB 的虚构服务组里既能够看到集群内的节点，也能够看到集群外的 ECS。集群内利用进行扩缩容时，集群外的 ECS 节点不受影响。

场景二：金丝雀公布

反对金丝雀公布，将流量按比例转发至集群内及集群外节点

迁徙过程中，往往须要逐渐将流量从存量 ECS 迁往 Kubernetes 集群中。CCM 反对通过 annotationservice.beta.kubernetes.io/alicloud-loadbalancer-weight 为 Kubernetes 集群配置权重，从而实现流量的逐渐迁徙。

1）注意事项

  • 不能跨 CLB 复用虚构服务器组
  • 一个虚构服务器组只能与一个端口关联
  • 集群内节点权重由 CCM 组件设置，集群外 ECS 权重须要用户手动设置

2）操作步骤

  • 登录 CLB 控制台创立 CLB、监听及虚构服务器组，记录 CLB ID (“lb-xxxx”) 及虚构服务器组 Id (“rsp-xxx”)
  • 手动在虚构服务器组中增加集群外 ECS 并设置权重
  • 创立 Service
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    # 集群外部权重为 20%
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: nginx-svc
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

3）预期后果

配置实现后，在 CLB 的虚构服务组里既能够看到集群内的节点，也能够看到集群外的 ECS，集群节点的权重依照 annotation 配置。集群内利用进行扩缩容时，集群外的 ECS 节点不受影响。

场景三：多集群业务流量多活与灾备

对于一个 CLB，反对将流量转发至多个 Kubernetes 集群内

企业用户会采取多种措施以保障利用的高可用性，如创立多个集群进行备份、容灾等。这要求业务流量能够通过一个 CLB 接入多个 Kubernetes 集群中，并且反对为 Kubernetes 集群设置不同的权重，如下图所示。

1）注意事项

  • 不能跨 CLB 复用虚构服务器组
  • 一个虚构服务器组只能与一个端口关联
  • 两个集群均已配置 Cluster Id，否则两个集群中的 service 须要不同名称

2）操作步骤

  • 登录 CLB 控制台创立 CLB、监听及虚构服务器组，记录 CLB ID (“lb-xxxx”)  及虚构服务器组 Id (“rsp-xxx”)
  • 集群 A 中创立 Serivce-A，权重设置为 20%
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: service-A
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

3）预期后果

配置实现后，在 clb 的虚构服务组里既能够看到集群 A 内的节点，也能够看到集群 B 的节点。集群节点的权重依照 annotation 主动设置。集群内利用进行扩缩容时，CLB 后端虚构服务器组会自动更新。

总结

出于降本增效的思考，越来越多的企业采纳容器化形式部署利用。在业务迁徙过程中，如何保障业务流量不受损成为一大难题。对于电商类利用而言，业务流量上涨往往会导致交易量上涨，造成重大损失。游戏类利用对业务流量也非常敏感，短暂的流量中断都会显著地影响游戏用户体验；交通类利用的流量上涨会影响交通流量管制、交通故障排险效率。保障业务流量不受损是保障用户业务失常运行的底线。

CCM 公布的反对在同一个 CLB 后端挂载集群内节点和集群外 ECS 的性能，能够一举解决迁徙过程中流量中断的难题。同时，还反对将业务流量转发至多个 Kubernetes 集群内，撑持备份、容灾等需要，保障业务高可用。

退出移动版