开发者社区> CTO技术共享> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

Kubernetes Kruise Rollout

简介: Kubernetes Kruise Rollout
+关注继续查看

Kubernetes Kruise Rollout

image

前言

Cloud Native


Kruise Rollout[1]是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 支持配合流量和实例灰度的金丝雀发布、蓝绿发布、A/B Testing 发布,以及发布过程能够基于 Prometheus Metrics 指标自动化分批与暂停,并提供旁路的无感对接、兼容已有的多种工作负载(Deployment、CloneSet)。


Gateway API

Cloud Native

Ingress API 是 K8s 中针对服务网关的抽象,也是目前 K8s 社区中使用最为广泛的网关资源,其中最具代表性的有 Nginx Ingress Controller。但是 Ingress 资源也存在一些问题,主要是 Ingress 定义比较单一,不能很好的满足一些复杂的网络需求。很多场景下 Ingress 控制器都需要通过定义 Annotations 或者 CRD 的方式来进行扩展,比如,Istio 就扩展了 Virtual Service、DestinationRule 资源。

为了解决上述问题,推动社区使用统一的标准,SIG-NETWORK 社区提出了 Gateway API 资源,它是 Kubernetes 中的一个 API 资源集合,包括 GatewayClass、Gateway、HTTPRoute、TCPRoute、Service 等,这些资源共同为各种网络用例构建模型。目前 Istio、Nginx、Kong 等诸多社区开源项目都已经实现了该接口。而 Kruise Rollout 作为渐进式交付框架,理所当然的需要支持,如下是使用 Gateway API 进行金丝雀发布的例子:


apiVersion: gateway.networking.k8s.io/v1alpha2kind: HTTPRoutemetadata:  name: echoserverspec:  hostnames:  - test.app.domain  rules:  - backendRefs:    - group: ""      name: echoserver      port: 80---apiVersion: rollouts.kruise.io/v1alpha1kind: Rolloutspec:  objectRef:    ...  strategy:    canary:      steps:      - weight: 20        pause: {}      trafficRoutings:      - service: echoserver        gateway:          httpRouteName: echoserver


StatefulSet & Advanced StatefulSet 分批发布

Cloud Native

Kruise Rollout 在 v0.1.0 版本已经支持了无状态应用(Deployment 和 CloneSet)的分批发布能力,而有状态的应用同样有类似的诉求。社区 StatefulSet 本身支持发布过程中保留旧版本 Pod 数量的能力(Order 小于 Partition 的 Pod 保留旧版本),所以 Kruise Rollout 通过该特性也可以非常方便的集成有状态工作负载(包括:Kruise 扩展 的 Advanced StatefulSet)。如下是一个分三批发布的例子: 


apiVersion: apps/v1kind: StatefulSetmetadata:  name: echoserverspec:  replicas: 5  template:    spec:      containers:        - name: echoserver          image: cilium/echoserver:latest---apiVersion: rollouts.kruise.io/v1alpha1kind: Rolloutmetadata:  name: rollouts-demospec:  objectRef:    workloadRef:      apiVersion: apps/v1      kind: StatefulSet      name: echoserver  strategy:    canary:      steps:      - replicas: 1        pause: {}      - replicas: 2        pause: {duration: 60}      - replicas: 2


image


Rollout 批次打标能力

Cloud Native

Kruise Rollout 在设计之初就考虑了很多易用性的问题,它可以与社区很多优秀部署方案快速集成,比如:用户可以使用 Helm 完成应用的 Rollout 交付。随着 Kruise Rollout 使用的用户以及规模的增大,对易用性方面又提出了新的要求,例如:

  • 金丝雀发布过程中,发现业务监控有些许的异常,希望能快速的过滤出第一批发布的 Pod 排查问题
     
  • 容器平台产品规划有发布详情页,希望能够精准的展示每次批次的 Pod,以及 Rollout 的进度、过程

为了满足上述需求,Kruise Rollout 新增了“Pod 批次打标”能力,在 Rollout 过程中能够对每一批次的 Pod 打上对应批次的 Label[apps.kruise.io/rollout-batch-id]={Value 为对应的批次,如:1,2,3...},用法如下:

apiVersion: rollouts.kruise.io/v1alpha1kind: Rolloutmetadata:  name: rollouts-demospec:  ...  # required  rolloutID: v1


  • rolloutID 是针对每次发布的一个发布 ID。该字段由上层 PaaS 平台或用户填写,可以是任意的字符串,前后两次发布需要不同,例如:webserver-20220728120533。为什么一定需要 rolloutID?主要是由于 CloneSet 支持原地升级,针对这种场景 Pod 上面包含的发布批次 Label 有可能是上次发布留下的,所以与 rolloutID 共同使用可以标记此次发布的任意批次。

                     

image


KubeVela 基于 Kruise Rollout 实现金丝雀发布能力

Cloud Native

KubeVela[2]是一款基于 OAM 模型的云原生应用管理平台,具有完善的应用交付、应用分发以及多集群管理等能力。目前 Kruise Rollout 已经集成到 KubeVela 之中,通过 trait 的方式可以非常便捷的实现 Helm Charts 金丝雀发布能力,详情请参考文末文档[3],如下:


apiVersion: core.oam.dev/v1beta1kind: Applicationspec:  components:  - name: canary-demo    type: webservice    properties:      image: barnett/canarydemo:v1    traits:    - type: kruise-rollout      properties:        canary:          steps:          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed          - weight: 20            trafficRoutings:            - type: nginx


Kruise Rollout 作为一种旁路式的渐进式交付框架,能够非常方便的与社区内优秀的应用交付平台集成。用户基本上不需要做额外的改动,只需要一份 Kruise Rollout CRD 定义即可。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Kubernetes-存储(二)
为了能够屏蔽底层存储实现的细节,便于使用和管理,Kubernetes从1.0版本就引入PersistentVolume(PV)和PersistentVolumeClaim(PVC)两个资源对象来实现对存储的管理子系统。
37 0
Kubernetes-存储(一)
对于这个问题其实很简单,容器中持久化的文件生命周期是短暂的,如果容器中程序崩溃宕机,kubelet 就会重新启动,容器中的文件将会丢失,所以对于有状态的应用容器中持久化存储是至关重要的一个环节;另外很多时候一个 Pod 中可能包含多个 Docker 镜像,在 Pod 内数据也需要相互共享,Kubernetes 中 Pod 也可以增加副本数量,遇到故障时 Pod 可以转移到其它节点,为了浮动节点都能够访问统一的持久化存储以及容器间共享数据,Kubernetes 中定义了 Volume 来解决这些问题 ,从本质上讲,Volume 只是一个目录,可能包含一些数据,Pod 中的容器可以访问它。
56 0
Kubernetes----Pod配置容器端口
Kubernetes----Pod配置容器端口
83 0
与 Kubernetes 共存:API 的使用和管理
与 Kubernetes 共存:API 的使用和管理
81 0
使用YAML创建一个 Kubernetes Depolyment
在之前的文章中,我们已经提到过如何使用Kubernetes去创建资源。到目前为止,我们一直仅仅通过命令行去执行,但是这里有一个更加简单有效的方式去创建资源:通过使用YAML创建一个配置文件。在这篇文章,我们将会关注YAML的工作方式以及如何使用YAML创建一个Kubernetes Pod,然后使用Kubernetes创建一个Depolyment。
1794 0
使用 kubeadm 创建 kubernetes 1.9 集群
简介 kubeadm是一个kubernetes官方提供的快速安装和初始化拥有最佳实践(best practice)的kubernetes集群的工具,虽然目前还处于 beta 和 alpha 状态,还不能用在生产环境,但是我们可以通过学习这种部署方法来体会一些官方推荐的kubernetes最佳实践的设计和思想。
1779 0
Kubernetes 的审计日志和采集
基础操作 一个正常运行的 Kubernetes 集群,除了利用访问控制对集群操作的许可进行限制之外,对于操作过程的跟踪审计也是比不可少的,围绕不同的实体,例如用户、节点以及各种工作负载进行观测是很有必要的。
1128 0
Kubernetes之Pod调度
Kubernetes调度器根据特定的算法与策略将pod调度到工作节点上。在默认情况下,Kubernetes调度器可以满足绝大多数需求,例如调度pod到资源充足的节点上运行,或调度pod分散到不同节点使集群节点资源均衡等。
1256 0
使用 kubeadm 创建一个 kubernetes 集群
kubeadm 是一个 kubernetes 官方提供的快速安装和初始化拥有最佳实践(best practice)的 kubernetes 集群的工具,虽然目前还处于 beta 和 alpha 状态,还不能用在生产环境,但是我们可以通过学习这种部署方法来体会一些官方推荐的kubernetes最佳实践的设计和思想。
6570 0
CoreOS发起的友好兼容Kubernetes的存储系统:Torus
本文讲的是CoreOS发起的友好兼容Kubernetes的存储系统:Torus【编者的话】容器和微服务管理一直有一个最棘手的问题就是持久化存储,CoreOS最近发起了一个项目Torus,给Kubernetes用户提供了一个友好兼容的分布式存储集群,也欢迎大家积极参与这个开源项目。
1716 0
+关注
CTO技术共享
专注大数据、架构框架、集群、中间件、分布式、数据库、监控、开源、基础架构等技术分享,助力数字化转型。
279
文章
47
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载