其他分享
首页 > 其他分享> > OpenKruise v0.8.0 版本发布:K8s 社区首个规模化镜像预热能力

OpenKruise v0.8.0 版本发布:K8s 社区首个规模化镜像预热能力

作者:互联网

头图.png

作者 | 王思宇(酒祝)
来源 | 阿里巴巴云原生公众号

背景

OpenKruise 是阿里云开源的云原生应用自动化管理套件,也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀,是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件,紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

新版本概览

Kruise 在 2021 年 3 月 4 日发布了最新的 v0.8.0 版本(ChangeLog),本文以下对新版本做一个整体的概览介绍。

1. 新增 kruise-daemon 组件

过去已经使用过 OpenKruise 的同学一定知道,Kruise 安装之后运行的组件是 kruise-manager,它是一个中心化部署的 Operator 组件,包含了一系列 controller 控制器以及 webhook。

而从 v0.8.0 开始,我们又增加了 kruise-daemon 这个节点组件,通过 DaemonSet 部署到每个节点上。这样,一直以来社区小伙伴们提的类似镜像预热容器重启等需求,就有途径去实现啦!

1.png

Tips:

2. 规模化镜像预热能力

在 Kubernetes 生态中,过去并没有一个成熟的镜像预热开源解决方案,可能更多的是一些公司在内部会落地一些适配于本地场景的预热,这其中也包括阿里巴巴。不过从 v0.8.0 开始,我们将阿里巴巴所做的镜像预热能力完全通用化输出到 OpenKruise 中,并且阿里内部的镜像预热也完全统一到这套开源的实现上来了。

OpenKruise 镜像预热的具体实现原理,我们会在后续的专项文章中做详细介绍,这里只以一个最简单的例子演示下如何做一个镜像的预热:

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: job-nginx
spec:
  image: nginx:1.9.1   # [required] 完整的镜像名 name:tag
  parallelism: 10      # [optional] 最大并发拉取的节点梳理, 默认为 1
  selector:            # [optional] 指定节点的 名字列表 或 标签选择器 (只能设置其中一种),不设置表示全部节点
    names:
    - node-1
    - node-2
    matchLabels:
      node-type: xxx
  completionPolicy:
    type: Always                  # [optional] 默认为 Always
    activeDeadlineSeconds: 1200   # [optional] 无默认值, 只对 Alway 类型生效
    ttlSecondsAfterFinished: 300  # [optional] 无默认值, 只对 Alway 类型生效
  pullPolicy:                     # [optional] 每个节点上拉镜像的侧脸,默认 backoffLimit=3, timeoutSeconds=600
    backoffLimit: 3
    timeoutSeconds: 300

ImagePullJob 有两种 completionPolicy 类型:

详细信息参考官网文档:https://openkruise.io/zh-cn/docs/imagepulljob.html

3. SidecarSet 全新重构实现

SidecarSet 是一个用于管理 sidecar 容器的控制器。在用户创建了 SidecarSet 之后,Kruise 能为后续创建的符合规定条件的 Pod 中自动注入用户定义的 sidecar 容器,以及对已注入的 sidecar 容器做原地升级同时不影响业务容器的运行。

在过去版本中,SidecarSet 的局限性较多,比如用户无法声明只对某个 namespace 生效、sidecar 原地升级时灰度能力较弱等。在 v0.8.0 中,我们全新重构了 SidecarSet 的 controller 和 webhook,并且在 CRD 定义上新增了一些更多能力的策略字段。举一些例子:

  1. spec.namespace:指定只管理具体某个命名空间的 sidecar 注入和升级
  2. 多种注入策略:
    1. podInjectPolicy:指定 sidecar 容器注入到 Pod 原 containers 列表的前面还是后面
    2. shareVolumePolicy:与 Pod 中原容器共享卷策略
    3. transferEnv:从原 Pod 中哪些容器里共享哪些环境变量
  3. 多种原地升级策略:
    1. maxUnavailable:升级过程中最大不可用数量
    2. partition:保留旧版本的数量(灰度/分批发布)
    3. selector:只升级符合 selector 条件 Pod 中的 sidecar(金丝雀发布)
    4. scatter:按标签打散发布

详细信息参考官网文档:https://openkruise.io/zh-cn/docs/sidecarset.html

4. 新的 feature-gate 机制

过去 OpenKruise 中的 CRD 以及 controller/webhook 开关,主要配置在 CUSTOM_RESOURCE_ENABLE 环境变量中,而其他一些可配置开关则集中在命令行参数中,带来的问题一来是较为分散,二来一些关联多个 CRD 的功能开关其实很难用 CRD 开关来控制。

因此,目前新增的 feature-gate 机制已经代替了 CUSTOM_RESOURCE_ENABLE 环境变量,聚焦于功能层面。

在 v0.8.0 提供了 PodWebhook、KruiseDaemon 两个开关,前者关闭后 kruise 不会对 pod creation 做 webhook 拦截,但同时也会关闭 SidecarSet 功能,后者关闭后不会部署 kruise-daemon 组件,但同时也会关闭镜像预热功能。后续版本中个,我们会逐渐把过去的开关参数统一到 feature-gate 中。

5. 其余一些变化点

其余部分优化:

总结

OpenKruise v0.8.0 新版本,可以说是 Kubernetes 社区中首个提供开源的规模化镜像预热功能的产品了。而在今年后续的版本里,我们还计划提供利用镜像预热来加速应用发布、应用安全防护、Controller 灰度/分片管控等能力,预计在年中将推出 v1.0 大版本。

OpenKruise 是一个成熟的 CNCF 沙箱项目,除了在阿里巴巴内大规模应用之外,在行业内也有着广泛的用户案例:

我们欢迎每一位云原生爱好者共同参与 OpenKruise 的建设,共同打造业界顶尖的云原生应用自动化引擎!

最后的开源要闻

近期,阿里云 DADI (Data Accelerator for Disaggregated Infrastructure) 产品开源了!这是一个容器镜像加速器项目,已经在阿里巴巴内部有了大规模场景的应用。

它的主要原理是消除 image 的下载和解压缩过程,代之以实现细粒度数据块的按需拉取。这样可以削减绝大多数的数据下载工作,同时将计算延迟与数据传输延迟相互隐藏,最终达到大幅削减启动延迟的作用。

DADI 将容器 image 的分层特性与虚拟机 image 的块设备接口相结合,形成全新的分层块设备 image,称为 overlaybd。由于使用了块设备接口,DADI 可以支持原生文件系统,如 ext4、xfs、甚至 ntfs;块设备接口也可以自然地支持虚拟化的安全容器,并且只暴露最小的 attack surface。此外由于块设备 image 简单高效的特性,overlaybd 可以为用户提供更好的 I/O 性能。

有兴趣的同学可以参考论文看一下 Github 项目哦:

如果大家对 OpenKruise 项目感兴趣,有任何希望交流的话题,欢迎大家访问 OpenKruise 官网GitHub

标签:容器,K8s,预热,v0.8,镜像,OpenKruise,sidecar,kruise
来源: https://blog.51cto.com/13778063/2657259