关于阿里云:Kruise-Rollout-v020-版本发布支持-Gateway-APIStatefulSet-分批发布等能力

45次阅读

共计 3244 个字符,预计需要花费 9 分钟才能阅读完成。

作者:赵明山(立衡)

前言

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

Gateway API

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/v1alpha2
kind: HTTPRoute
metadata:
name: echoserver
spec:
hostnames:
- test.app.domain
rules:
- backendRefs:
- group: ""
name: echoserver
port: 80
---
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
spec:
objectRef:
...
strategy:
canary:
steps:
- weight: 20
pause: {}
trafficRoutings:
- service: echoserver
gateway:
httpRouteName: echoserver

StatefulSet & Advanced StatefulSet 分批公布

Kruise Rollout 在 v0.1.0 版本曾经反对了无状态利用(Deployment 和 CloneSet)的分批公布能力,而有状态的利用同样有相似的诉求。社区 StatefulSet 自身反对公布过程中保留旧版本 Pod 数量的能力(Order 小于 Partition 的 Pod 保留旧版本),所以 Kruise Rollout 通过该个性也能够十分不便的集成有状态工作负载(包含:Kruise 扩大 的 Advanced StatefulSet)。如下是一个分三批公布的例子:

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: echoserver
spec:
replicas: 5
template:
spec:
containers:
- name: echoserver
image: cilium/echoserver:latest
---
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
name: rollouts-demo
spec:
objectRef:
workloadRef:
apiVersion: apps/v1
kind: StatefulSet
name: echoserver
strategy:
canary:
steps:
- replicas: 1
pause: {}
- replicas: 2
pause: {duration: 60}
- replicas: 2

Rollout 批次打标能力

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/v1alpha1
kind: Rollout
metadata:
name: rollouts-demo
spec:
...
# required
rolloutID: v1
  • rolloutID 是针对每次公布的一个公布 ID。该字段由下层 PaaS 平台或用户填写,能够是任意的字符串,前后两次公布须要不同,例如:webserver-20220728120533。为什么肯定须要 rolloutID?次要是因为 CloneSet 反对原地降级,针对这种场景 Pod 下面蕴含的公布批次 Label 有可能是上次公布留下的,所以与 rolloutID 独特应用能够标记此次公布的任意批次。

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

KubeVela [2 ] 是一款基于 OAM 模型的云原生利用治理平台,具备欠缺的利用交付、利用散发以及多集群治理等能力。目前 Kruise Rollout 曾经集成到 KubeVela 之中, 通过 trait 的形式能够十分便捷的实现 Helm Charts 金丝雀公布能力 ,详情请参考文末文档 [ 3],如下:

apiVersion: core.oam.dev/v1beta1
kind: Application
spec:
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 定义即可。

欢送大家实用,如果两头遇到任何问题能够 Issue 或者群里沟通。

参考链接:

[1] Kruise Rollout:

https://github.com/openkruise…

*[2] KubeVela*:

https://kubevela.io/

*[3] 文档:*

https://kubevela.net/docs/end…

Github:

https://github.com/openkruise…

Official:

https://openkruise.io/

Slack: Channel in Kubernetes Slack

钉钉扫码退出 OpenKruise 社区交换群:

戳此处,查看 OpenKruise 我的项目官方主页与文档!

正文完
 0