OpenKruise v0，mybatis 教程 pdf
?
因此，在 Kruise v0.9.0 版本中，我们将阿里内部所做的防级联删除能力输出到社区，期望能为更多的用户带来稳定性保障。在当前版本中如果需要使用该功能，则在[安装或升级 Kruise](
) 的时候需要显式打开 ResourcesDeletionProtection 这个 feature-gate。
?
对于需要防护删除的资源对象，用户可以给其打上 policy.kruise.io/delete-protection 标签，value 可以有两种：
?
Always: 表示这个对象禁止被删除，除非上述 label 被去掉。
Cascading：这个对象如果还有可用的下属资源，则禁止被删除。
目前支持的资源类型、以及 cascading 级联关系如下：
?
[](
)CloneSet 新增功能
==================================================================================
?
[](
)1. 删除优先级
?
[controller.kubernetes.io/pod-deletion-cost](
)? 是从 Kubernetes 1.21 版本后加入的 annotation，ReplicaSet 在缩容时会参考这个 cost 数值来排序。CloneSet 从 Kruise v0.9.0 版本后也同样支持了这个功能。
?
用户可以把这个 annotation 配置到 pod 上，它的 value 数值是 int 类型，表示这个 pod 相较于同个 CloneSet 下其他 pod 的 “删除代价”，代价越小的 pod 删除优先级相对越高。没有设置这个 annotation 的 pod 默认 deletion cost 是 0。
?
注意这个删除顺序并不是强制保证的，因为真实的 pod 的删除类似于下述顺序：
?
未调度 < 已调度
PodPending < PodUnknown < PodRunning
Not ready < ready
较小 pod-deletion cost < 较大 pod-deletion cost
处于 Ready 时间较短 < 较长
容器重启次数较多 < 较少
创建时间较短 < 较长
[](
)2. 配合原地升级的镜像预热
?
当使用 CloneSet 做应用原地升级时，只会升级容器镜像、而 Pod 不会发生重建。这就保证了 Pod 升级前后所在 node 不会发生变化，从而在原地升级的过程中，如果 CloneSet 提前在所有 Pod 节点上先把新版本镜像拉取好，则在后续的发布批次中 Pod 原地升级速度会得到大幅度提高。
?
在当前版本中如果需要使用该功能，则在[安装或升级 Kruise](
) 的时候需要显式打开 PreDownloadImageForInPlaceUpdate 这个 feature-gate。打开后，当用户更新了 CloneSet template 中的镜像、且发布策略支持原地升级，则 CloneSet 会自动为这个新镜像创建 ImagePullJob 对象（OpenKruise 提供的批量镜像预热功能），来提前在 Pod 所在节点上预热新镜像。
?
默认情况下 CloneSet 给 ImagePullJob 配置的并发度是 1，也就是一个个节点拉镜像。如果需要调整，你可以在 CloneSet annotation 上设置其镜像预热时的并发度：
?
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
annotations:
apps.kruise.io/image-predownload-parallelism: "5"
?
[](
)3. 先扩再缩的 Pod 置换方式
?
在过去版本中，CloneSet 的 maxUnavailable、maxSurge 策略只对应用发布过程生效。而从 Kruise v0.9.0 版本开始，这两个策略同样会对 Pod 指定删除生效。
?
也就是说，当用户通过 podsToDelete 或 apps.kruise.io/specified-delete: true 方式（具体见官网文档）来指定一个或多个 Pod 期望删除时，CloneSet 只会在当前不可用 Pod 数量（相对于 replicas 总数）小于 maxUnavailable 的时候才执行删除。同时，如果用户配置了 maxSurge 策略，则 CloneSet 有可能会先创建一个新 Pod、等待新 Pod ready、再删除指定的旧 Pod。
?
具体采用什么样的置换方式，取决于当时的 maxUnavailable 和实际不可用 Pod 数量。比如：
?
对于一个 CloneSet
maxUnavailable=2, maxSurge=1且有一个pod-a处于不可用状态， 如果你对另一个pod-b指定删除， 那么 CloneSet 会立即删除它，然后创建一个新 Pod。对于一个 CloneSet
maxUnavailable=1, maxSurge=1且有一个pod-a处于不可用状态， 如果你对另一个pod-b指定删除， 那么 CloneSet 会先新建一个 Pod、等待它 ready，最后再删除pod-b。对于一个 CloneSet
maxUnavailable=1, maxSurge=1且有一个pod-a处于不可用状态， 如果你对这个pod-a指定删除， 那么 CloneSet 会立即删除它，然后创建一个新 Pod。…
[](
)4. 基于 partition 终态的高效回滚
?
在原生的 workload 中，Deployment 自身发布不支持灰度发布，StatefulSet 有 partition 语义来允许用户控制灰度升级的数量；而 Kruise workload 如 CloneSet、Advanced StatefulSet，也都提供了 partition 来支持灰度分批。
?
对于 CloneSet，Partition 的语义是保留旧版本 Pod 的数量或百分比。比如说一个 100 个副本的 CloneSet，在升级镜像时将 partition 数值阶段性改为 80 -> 60 -> 40 -> 20 -> 0，则完成了分 5 批次发布。
?
但过去，不管是 Deployment、StatefulSet 还是 CloneSet，在发布的过程中如果想要回滚，都必须将 template 信息（镜像）重新改回老版本。后两者在灰度的过程中，将 partition 调小会触发旧版本升级为新版本，但再次 partition 调大则不会处理。
?
从 v0.9.0 版本开始，CloneSet 的 partition 支持了 “终态回滚” 功能。如果在[安装或升级 Kruise](
) 的时候打开了 CloneSetPartitionRollback 这个 feature-gate，则当用户将 partition 调大时，CloneSet 会将对应数量的新版本 Pod 重新回滚到老版本。
?
这样带来的好处是显而易见的：在灰度发布的过程中，只需要前后调节 partition 数值，就能灵活得控制新旧版本的比例数量。但需要注意的是，CloneSet 所依据的 “新旧版本” 对应的是其 status 中的 updateRevision 和 currentRevision：
?
updateRevision：对应当前 CloneSet 所定义的 template 版本。
currentRevision：该 CloneSet 前一次全量发布成功的 template 版本。
[](
)5. 短 hash
?
默认情况下，CloneSet 在 Pod label 中设置的 controller-revision-hash 值为 ControllerRevision 的完整名字，比如：
apiVersion: v1
kind: Pod
metadata:
labels:
controller-revision-hash: demo-cloneset-956df7994
它是通过 CloneSet 名字和 ControllerRevision hash 值拼接而成。通常 hash 值长度为 8~10 个字符，而 Kubernetes 中的 label 值不能超过 63 个字符。因此 CloneSet 的名字一般是不能超过 52 个字符的，如果超过了，则无法成功创建出 Pod。
?
在 v0.9.0 版本引入了 CloneSetShortHash 新的 feature-gate。如果它被打开，CloneSet 只会将 Pod 中的 controller-revision-hash 的值只设置为 hash 值，比如 956df7994，因此 CloneSet 名字的长度不会有任何限制了。（即使启用该功能，CloneSet 仍然会识别和管理过去存量的 revision label 为完整格式的 Pod。）
?
[](
)SidecarSet
===============================================================================
?
[](
)sidecar 热升级功能
?
SidecarSet 是 Kruise 提供的独立管理 sidecar 容器的 workload。用户可以通过 SidecarSet，来在一定范围的 Pod 中注入和升级指定的 sidecar 容器。
?
默认情况下，sidecar 的独立原地升级是先停止旧版本的容器，然后创建新版本的容器。这种方式更加适合不影响 Pod 服务可用性的 sidecar 容器，比如说日志收集 agent，但是对于很多代理或运行时的 sidecar 容器，例如 Istio Envoy，这种升级方法就有问题了。Envoy 作为 Pod 中的一个代理容器，代理了所有的流量，如果直接重启升级，Pod 服务的可用性会受到影响。如果需要单独升级 envoy sidecar，就需要复杂的 grace 终止和协调机制。所以我们为这种 sidecar 容器的升级提供了一种新的解决方案，即热升级（hot upgrade）。
?
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
spec:
...
containers:
name: nginx-sidecar
image: nginx:1.18
lifecycle:
postStart:
exec:
command:
/bin/bash
-c
/usr/local/bin/nginx-agent migrate
upgradeStrategy:
upgradeType: HotUpgrade
hotUpgradeEmptyImage: empty:1.0.0
upgradeType: HotUpgrade 代表该 sidecar 容器的类型是 hot upgrade，将执行热升级方案 hotUpgradeEmptyImage: 当热升级 sidecar 容器时，业务必须要提供一个 empty 容器用于热升级过程中的容器切换。empty 容器同 sidecar 容器具有相同的配置（除了镜像地址），例如：command, lifecycle, probe 等，但是它不做任何工作。
lifecycle.postStart: 状态迁移，该过程完成热升级过程中的状态迁移，该脚本需要由业务根据自身的特点自行实现，例如：nginx 热升级需要完成 Listen FD 共享以及流量排水（reload）。
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论