云原生应用自动化管理套件，CNCF沙盒项目——OpenKruise，最近发布的v1.0 OpenKruise[1]是针对Kubernetes的增强能力套件，专注于云原生应用的部署、升级、运维、稳定性保护等领域。的所有功能都通过CRD等标准方法进行了扩展，这些方法可以应用于任何版本为1.16或更高版本的Kubernetes集群。一个helm命令就可以完成Kruise的一键部署，无需进一步配置。
一般来说，OpenKruise目前提供的功能分为几个方面：
应用工作负载：针对无状态、有状态、守护进程和其他类型应用的高级部署和发布策略，如就地升级、灰度流发布等。边车容器管理：支持独立定义边车容器，完成动态注入、独立就地升级、热升级等功能。增强运维能力：包括容器重启到位、镜像预拉、容器启动顺序保障等。应用区域管理：管理多个区域(可用区域、不同型号等)中应用的部署比例、顺序和优先级。).应用安全保护：帮助应用在Kubernetes上获得更高的安全性和可用性保护。版本分析在1.0版本中，OpenKruise带来了很多新的特性，同时对现有的很多功能进行了增强和优化。首先，从v1.0开始，OpenKruise将CRD/WehhookConfiguration等资源配置的版本从v1beta1升级到v1，因此可以支持Kubernetes v1.22及以上版本的集群，但同时要求Kubernetes的版本不得低于v1.16以下是对v1.0部分功能的简单介绍，详细的ChangeLog列表请参考OpenKruise Github上的发布说明和官网文档。
支持环境变量的就地升级author : @ fill zpp[2]OpenKruise从早期版本开始就支持“就地升级”功能，主要应用于CloneSet和高级StatefulSet工作负载。简单来说，就地升级就是在应用升级的过程中不需要删除或者新建Pod对象，而是通过修改Pod中的容器配置来达到升级的目的。
如上图所示，就地升级期间仅修改了Pod中的字段，因此：
可以避免额外的操作和成本，如调度、分配IP、分配和安装磁盘。更快的图像拉取，因为开源复用了现有旧图像的大部分图层图层，只需要拉取一些被新图像改变的图层。当容器就地升级时，Pod的网络、挂载磁盘和Pod中的其他容器不会受到影响，并且仍然保持运行。但是以前OpenKruise只能原地升级Pod中的image字段，其他字段只能像Deployment一样重建升级。一直以来，我们都收到了很多用户的反馈，希望支持env等更多领域的原地升级——由于kube-apiserver的限制很难做到。经过我们不懈的努力，OpenKruise终于在1.0版中支持通过Downward API实现env环境变量的就地升级比如下面的CloneSet YAML，用户在annotation中定义配置，并将其与对应的env关联起来。在配置的后续修改中，只需要更新annotation value中的值，Kruise将触发引用env中该注释的Pod中所有容器的就地重建，从而使这个新的值配置生效。
API版本： apps.kruise.io/v1阿尔法种类：克隆元数据：’ spec:副本： 1模板：元数据：注释：应用程序配置： ‘.真正的环境价值.spec : containers :-name : APP env :-name : APP _ CONFIG value from : field ref : field path : metadata . annotations[‘ APP-CONFIG ‘]update strategy : type : in placeif可能的同时，在此版本中，我们还取消了过去对镜像就地升级的imageID限制，即两次镜像替换升级使用相同的imageID是具体用法请参考文献[3]。
配置跨命名空间分发Author3360 @ veophi [4]在Secret、ConfigMap等命名空间范围的资源跨命名空间分发和同步的场景下，原生kubernetes目前只支持用户逐个手动分发和同步，非常不方便。典型案例有：
当用户需要使用SidecarSet的imagePullSecrets能力时，首先要在相关的名称空间中重复创建相应的秘密，并确保这些秘密配置的正确性和一致性。当用户想要使用ConfigMap配置一些通用的环境变量时，往往需要将ConfigMap分布在多个命名空间中，后续的修改往往需要多个命名空间之间的同步。因此，面对这些需要跨名称空间进行资源分配和多个同步的场景，我们期望有一个更方便的分配和同步工具来自动完成这些工作。因此，我们设计并实现了新的CRD资源分配。ResourceDistribution目前支持Secret和ConfigMap资源的分发和同步。
API version : apps.kruise.io/v1 alpha 1 kind :资源分布元数据：名称：样品规格：资源： API version : v1 kind :配置图元数据：名称3360游戏-解调数据：目标：命名空间标签选择器3360.#或者包含的命名空间，排除的命名空间如上图YAML所示，ResourceDistribution是一种集群范围的CRD，主要由两个字段组成：resource和targets，其中resource字段用于描述用户要分配的资源，targets字段用于描述用户要分配的目标命名空间。具体用法请参考文献[5]。
容器启动顺序控制Author: @Concurrensee[6]对于一组Kubernetes，多个容器之间可能存在依赖关系。例如，容器B中应用程序进程的运行依赖于容器a中的应用程序。因此，需要多个容器之间的顺序关系：
容器A先启动，成功启动后再启动容器B。容器B先退出，然后容器A可以在退出完成后停止。一般来说，Pod容器启动和退出的顺序是由Kubelet管理的。Kubernetes曾经有一个KEP计划，在容器中添加一个type字段，用来标识不同类型容器的起止优先级。但是由于sig-node对现有的代码架构做了太多的改动，目前这个KEP已经被否决了。因此，OpenKruise在v1.0中提供了一个名为容器启动优先级的功能，用于控制一个Pod中多个容器的强制启动顺序：
对于任何Pod对象，只需要在注释中定义apps.kruise.io/container-launch-priority:顺序，Kruise将确保Pod中的容器按照容器列表的顺序顺序启动。如果要自定义容器中多个容器的启动顺序，在容器env中添加KRUISE_CONTAINER_PRIORITY环境变量，取值为[-2147483647，2147483647]范围内的整数。容器的优先级值越大，它将越早启动。具体用法请参考文献[7]。
Kubectl-kruise命令行工具Author: @hantmac[8]过去，OpenKruise通过kruise-api、client-java等仓库提供Go、Java等语言的Kruise API定义和客户端包，用户可以在自己的应用中引入和使用。但是，仍然有许多用户需要在测试环境中使用命令行灵活地操作工作负载资源。而原生kubectl工具提供的rollout、set image等命令只能应用于原生工作负载类型，如Deployment、StatefulSet等，不能识别OpenKruise中的扩展工作负载类型。所以OpenKruise最近提供了ku ectl-kruise命令行工具，这是ku ectl的一个标准插件，提供了很多适用于OpenKruise工作负载的功能。
# rollout撤消克隆集$ kubectl kruise rollout撤消克隆集/nginx # rollout状态高级有状态集$ ku bectl kruise rollout状态statefulsets.apps.kruise.io/sts-demo#设置克隆映像set $ ku bectl kruise设置映像克隆set/nginx busybox=busybox nginx=nginx 33601。9 .一具体使用方式请参考文档[9]。
其余部分功能改进与优化克隆：
通过规模战略。最大不可用策略支持流式扩容稳定修订判断逻辑变化，当所有豆荚版本与更新修订一致时则标记为currentrevisionworkloadspread :
支持接管存量豆荚到匹配的子集分组中优化webhook在豆荚注入时的更新与重试逻辑高级DaemonSet:
支持对守护程序豆荚做原地升级引入渐进式注释来选择是否按划分限制豆荚创建SidecarSet:
解决SidecarSet过滤屏蔽非活动豆荚在transferenv中新增SourceContainerNameFrom和EnvNames字段，来解决容器名称不一致与大量包封/包围（动词包围的简写)情况下的冗余问题PodUnavailableBudget:
新增”跳过保护”标识预算控制员关注工作量工作负载的复制品变化节点图像：
加入-节点映像创建延迟参数，并默认等待新增节点就绪一段时间后同步创建NodeImageUnitedDeployment:
解决NodeSelectorTerms为无情况下豆荚节点选择或项目长度为0 的问题其他优化：
克鲁斯-守护进程采用工具协议操作豆荚资源暴露缓存重新同步为命令行参数，并在图表中设置默认值为0解决必然发生的事更新时的超文本传送协议（Hyper Text Transport Protocol的缩写）检查器刷新问题去除对分叉控制器-工具的依赖，改为使用原生控制器-工具配合标记注解参考资料[1]开克鲁兹：https://开克鲁兹。io[2]@ fill zpp :https://github。com/fill zpp[3]文档：/docs/core-concepts/in place-update[4]@ veo phi :https://github。com/veo phi[5]文档：/docs/用户手册/资源分发[6]@ Concurrensee :https://github。见[7]文档：/docs/user-manuals/container启动优先级[8]@ hant MAC :https://github。com/hant MAC[9]文档：/docs/CLI-tool/ku bectl-plugin[10]社区双周会：https://石磨。im/docs/gxqmeqoybehz 4 vqo[11]斯莱克channel:https://kubernetes.slack.com/channels/openkruise原文链接：https://开发者。阿里云。com/article/847016 UTM _ content=g _ 1000317976本文为阿里云原创内容，未经允许不得转载。
