关于阿里云:OpenKruise-v13新增自定义-Pod-Probe-探针能力与大规模集群性能显著提升

1次阅读

共计 7209 个字符，预计需要花费 19 分钟才能阅读完成。

作者：赵明山（立衡）

云原生利用自动化治理套件、CNCF Sandbox 我的项目——OpenKruise，近期公布了 v1.3 版本。

OpenKruise 是针对 Kubernetes 的加强能力套件，聚焦于云原生利用的部署、降级、运维、稳定性防护等畛域。

所有的性能都通过 CRD 等规范形式扩大，能够实用于 1.16 以上版本的任意 Kubernetes 集群。单条 helm 命令即可实现 Kruise 的一键部署，无需更多配置。

在版本 v1.3 中，OpenKruise 提供了新的 CRD 资源 PodProbeMarker，改善了大规模集群的一些性能问题，Advanced DaemonSet 反对镜像预热，以及 CloneSet、WorkloadSpread、Advanced CronJob、SidecarSet 一些新的个性。

Kubernetes 提供了三种默认的 Pod 生命周期治理：

Readiness Probe：用来判断业务容器是否曾经筹备好响应用户申请，如果查看失败，会将该 Pod 从 Service Endpoints 中剔除。
Liveness Probe：用来判断容器的衰弱状态，如果查看失败，kubelet 将会重启该容器。
Startup Probe：用来判断容器是否启动实现，如果定义了该 Probe，那么 Readiness Probe 与 Liveness Probe 将会在它胜利之后再执行。

所以 Kubernetes 中提供的 Probe 能力都曾经限定了特定的语义以及相干的行为。 除此之外，其实还是存在自定义 Probe 语义以及相干行为的需要 ，例如：

GameServer 定义 Idle Probe 用来判断该 Pod 以后是否存在游戏对局 ，如果没有，从老本优化的角度，能够将该 Pod 缩容掉。
K8s Operator 定义 main-secondary Probe 来判断以后 Pod 的角色（main or secondary），降级的时候，能够优先降级 secondary，进而达到降级过程只有一次选主的行为，升高降级过程中服务抖动工夫。

OpenKruise 提供了自定义 Probe 的能力，并将后果返回到 Pod Status 中，用户能够依据该后果决定后续的行为。

PodProbeMarker 配置如下：

apiVersion: apps.kruise.io/v1alpha1
kind: PodProbeMarker
metadata:
  name: game-server-probe
  namespace: ns
spec:
  selector:
    matchLabels:
      app: game-server
  probes:
  - name: Idle
    containerName: game-server
    probe:
      exec: /home/game/idle.sh
      initialDelaySeconds: 10
      timeoutSeconds: 3
      periodSeconds: 10
      successThreshold: 1
      failureThreshold: 3
    markerPolicy:
    - state: Succeeded
      labels:
        gameserver-idle: 'true'
      annotations:
        controller.kubernetes.io/pod-deletion-cost: '-10'
    - state: Failed
      labels:
        gameserver-idle: 'false'
      annotations:
        controller.kubernetes.io/pod-deletion-cost: '10'
        podConditionType: game.io/idle

PodProbeMarker 后果能够通过 Pod 对象查看：

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: game-server
    gameserver-idle: 'true'
  annotations:
    controller.kubernetes.io/pod-deletion-cost: '-10'
  name: game-server-58cb9f5688-7sbd8
  namespace: ns
spec:
  ...
status:
  conditions:
    # podConditionType
  - type: game.io/idle
    # Probe State 'Succeeded' indicates 'True', and 'Failed' indicates 'False'
    status: "True"
    lastProbeTime: "2022-09-09T07:13:04Z"
    lastTransitionTime: "2022-09-09T07:13:04Z"
    # If the probe fails to execute, the message is stderr
    message: ""

1026 [ 1] 引入了提早入队机制，大幅优化了在大规模利用集群下 kruise-manager 拉起时的 CloneSet 控制器工作队列沉积问题，在现实状况下初始化工夫缩小了 80% 以上。
1027 [ 2] 优化 PodUnavailableBudget 控制器 Event Handler 逻辑，缩小无关 Pod 入队数量。
1011 [ 3] 通过缓存机制，优化了大规模集群下 Advanced DaemonSet 反复模仿 Pod 调度计算的 CPU、Memory 耗费。
1015 [ 4] , #1068 [ 5] 大幅升高了大规模集群下的运行时内存耗费。补救了 v1.1 版本中 Disable DeepCopy 的一些疏漏点，缩小 expressions 类型 label selector 的转换耗费。

SidecarSet 通过 ControllerRevision 记录了对于 containers、volumes、initContainers、imagePullSecrets 和 patchPodMetadata 等字段的历史版本，并容许用户在 Pod 创立时抉择特定的历史版本进行注入。

基于这一个性，用户能够躲避在 SidecarSet 灰度公布时，因 Deployment 等 Workload 扩容、降级等操作带来的 SidecarSet 公布危险。如果不抉择注入版本，SidecarSet 将对重建 Pod 默认全都注入最新版本 Sidecar。

SidecarSet 相干 ControllerRevision 资源被搁置在了与 Kruise-Manager 雷同的命名空间中，用户能够应用以下命令来查看：

kubectl get controllerrvisions -n kruise-system -l kruise.io/sidecarset-name=your-sidecarset-name

此外，用户还能够通过 SidecarSet 的 status.latestRevision 字段看到以后版本对应的 ControllerRevision 名称，以不便自行记录。

1. 通过 ControllerRevision 名称指定注入的 Sidecar 版本

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: sidecarset
spec:
  ...
  injectionStrategy:
    revisionName: specific-controllerRevision-name

2. 通过自定义版本标识指定注入的 Sidecar 版本

用户能够通过在发版时，同时给 SidecarSet 打上 apps.kruise.io/sidecarset-custom-version=your-version-id 来标记每一个历史版本，SidecarSet 会将这个 label 向下带入到对应的 ControllerRevision 对象，以便用户进行筛选，并且容许用户在抉择注入历史版本时，应用改 your-version-id 来进行形容。

假如用户只想灰度 10% 的 Pods 到 version-2，并且对于新创建的 Pod 心愿都注入更加稳固的 version-1 版本来管制灰度危险：

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: sidecarset
  labels:
    apps.kruise.io/sidecarset-custom-version: version-2
spec:
  ...
  updateStrategy:
    partition: 90%
  injectionStrategy:
    customVersion: version-1

SidecarSet 反对注入 Pod Annotations，配置如下：

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
spec:
  containers:
  ...
  patchPodMetadata:
  - annotations:
    oom-score: '{"log-agent": 1}'
    custom.example.com/sidecar-configuration: '{"command":"/home/admin/bin/start.sh","log-level":"3"}'
  patchPolicy: MergePatchJson
  - annotations:
    apps.kruise.io/container-launch-priority: Ordered
    patchPolicy: Overwrite | Retain

patchPolicy 为注入的策略，如下：

Retain：默认策略，如果 Pod 中存在 annotation[key]=value，则保留 Pod 原有的 value。只有当 Pod 中不存在 annotation[key] 时，才注入 annotations[key]=value。
Overwrite：与 Retain 对应，当 Pod 中存在 annotation[key]=value，将被强制笼罩为 value2。
MergePatchJson：与 Overwrite 对应，annotations value 为 json 字符串。如果 Pod 不存在该 annotations[key]，则间接注入。如果存在，则进行 json value 合并。例如：Pod 中存在 annotations[oom-score]='{“main”: 2}’，注入后将 value json 合并为 annotations[oom-score]='{“log-agent”: 1, “main”: 2}’。

留神：patchPolicy 为 Overwrite 和 MergePatchJson 时，SidecarSet 原地降级 Sidecar Container 时，可能同步更新该 annotations。然而，如果只批改 annotations 则不能失效，只能搭配 Sidecar 容器镜像一起原地降级。

patchPolicy 为 Retain 时，SidecarSet 原地降级 Sidecar Container 时，将不会同步更新该 annotations。

上述配置后，SidecarSet 在注入 Sidecar Container 时，会注入 Pod annotations，如下：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    apps.kruise.io/container-launch-priority: Ordered
    oom-score: '{"log-agent": 1,"main": 2}'
    custom.example.com/sidecar-configuration: '{"command":"/home/admin/bin/start.sh","log-level":"3"}'
  name: test-pod
spec:
  containers:
    ...

留神：SidecarSet 从权限、平安的思考不应该注入或批改除 Sidecar Container 之外的 Pod 字段，所以如果想要应用该能力，首先须要配置 SidecarSet_PatchPodMetadata_WhiteList 白名单或通过如下形式敞开白名单校验：

helm install kruise https://… –set featureGates=”SidecarSetPatchPodMetadataDefaultsAllowed =true”

如果你在装置或降级 Kruise 的时候启用了 PreDownloadImageForDaemonSetUpdate feature-gate，DaemonSet 控制器会主动在所有旧版本 pod 所在 node 节点上预热你正在灰度公布的新版本镜像。这对于利用公布减速很有帮忙。

默认状况下 DaemonSet 每个新镜像预热时的并发度都是 1，也就是一个个节点拉镜像。

如果须要调整，你能够通过 apps.kruise.io/image-predownload-parallelism annotation 来设置并发度。

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
metadata:
  annotations:
    apps.kruise.io/image-predownload-parallelism: "10"

默认状况下，CloneSet 将处于 PreparingDelete 状态的 Pod 视为失常，意味着这些 Pod 依然被计算在 replicas 数量中。

在这种状况下：

如果你将 replicas 从 N 改为 N-1，当一个要删除的 Pod 还在 PreparingDelete 状态中时，你从新将 replicas 改为 N，CloneSet 会将这个 Pod 从新置为 Normal 状态。
如果你将 replicas 从 N 改为 N-1 的同时在 podsToDelete 中设置了一个 Pod，当这个 Pod 还在 PreparingDelete 状态中时，你从新将 replicas 改为 N，CloneSet 会等到这个 Pod 真正进入 terminating 之后再扩容一个 Pod 进去。
如果你在不扭转 replicas 的时候指定删除一个 Pod，当这个 Pod 还在 PreparingDelete 状态中时，CloneSet 会等到这个 Pod 真正进入 terminating 之后再扩容一个 Pod 进去。

从 Kruise v1.3.0 版本开始，你能够在 CloneSet 中设置一个 apps.kruise.io/cloneset-scaling-exclude-preparing-delete: “true” 标签，它标记着这个 CloneSet 不会将 PreparingDelete 状态的 Pod 计算在 replicas 数量中。

在这种状况下：

如果你将 replicas 从 N 改为 N-1，当一个要删除的 Pod 还在 PreparingDelete 状态中时，你从新将 replicas 改为 N，CloneSet 会将这个 Pod 从新置为 Normal 状态。
如果你将 replicas 从 N 改为 N-1 的同时在 podsToDelete 中设置了一个 Pod，当这个 Pod 还在 PreparingDelete 状态中时，你从新将 replicas 改为 N，CloneSet 会立刻创立一个新 Pod。
如果你在不扭转 replicas 的时候指定删除一个 Pod，当这个 Pod 还在 PreparingDelete 状态中时，CloneSet 会立刻创立一个新 Pod。

默认状况下，所有 AdvancedCronJob schedule 调度时，都是基于 kruise-controller-manager 容器本地的时区所计算的。

不过，在 v1.3.0 版本中咱们引入了 spec.timeZone 字段，你能够将它设置为任意非法时区的名字。例如，设置 spec.timeZone: “Asia/Shanghai” 则 Kruise 会依据国内的时区计算 schedule 工作触发工夫。

Go 规范库中内置了时区数据库，作为在容器的零碎环境中没有外置数据库时的 fallback 抉择。

你能够通过 Github release [ 6] 页面，来查看更多的改变以及它们的作者与提交记录。

十分欢送你通过 Github/Slack/ 钉钉 / 微信等形式退出咱们来参加 OpenKruise 开源社区。

你是否曾经有一些心愿与咱们社区交换的内容呢？

能够在咱们的社区双周会上分享你的声音，或通过以下渠道参加探讨：

退出社区 Slack channel [ 7] (English)
退出社区钉钉群：搜寻群号 23330762 (Chinese)
退出社区微信群（新）：增加用户 openkruise 并让机器人拉你入群 (Chinese)

[1] #1026