关于kubernetes:Kubernetes-v127-新特性一览

大家好，我是张晋涛。

Kubernetes v1.27 是 2023 年的第一个大版本更新，蕴含了近 60 项次要的更新。 而 1.26 只有 37 项，所以这个版本能够说是一个变动十分显著的版本了。

其中 18 个加强性能正在进入 Alpha 阶段，29 个将降级到 Beta 阶段，而另外 13 个则将降级到稳定版。

只管这个版本中蕴含了这么多的个性变更，但值得一提的是，这个版本应该算是第一个齐全依照即定流程，遵守每个 deadline 的版本。
之前的版本中，每次都或多或少会有一些变数，不过这也从侧面能够看到 release team 做了很多幕后的工作。

我每期的「k8s 生态周报」都有一个叫上游停顿的局部，所以很多值得关注的内容在之前的文章中曾经发过了。
这篇中我会再额定介绍一些之前未涵盖的，和之前介绍过的值得关注的内容。

咱们一起来具体看看吧！

SeccompDefault 达到 Stable

如果想要默认应用 seccomp profile，则必须在每个想要应用它的节点上为 kubelet 启用 --seccomp-default 选项。
如果启用了该选项，则 kubelet 将默认应用由容器运行时定义的 RuntimeDefault seccomp profile，而不是应用 Unconfined（禁用 seccomp）模式。“

默认配置文件旨在提供弱小的安全性设置，并保留工作负载性能。
容器运行时的不同公布版本之间可能存在不同的默认配置文件。

印象里很早之前 Docker 的配置文件就因为修补安全漏洞而调整过。

Pod 调度就绪机制达到 Beta

这个性能实际上是从 Kubernetes v1.26 开始减少的。是 KEP 3521 的第一局部。

首先咱们来简略的回顾一下 Pod 的创立过程。

当 client 通过 kube-apiserver 创立胜利 Pod 资源后，kube-scheduler 会去查看尚未被调度的 Pod，而后为其进行调度，调配 Node。之后 Node 获取到调度到该 Node 上的 Pod 而后进行创立。
这里省略了很多细节，但其余的局部与咱们此处要介绍的内容关系不太大，就不开展了。

根据上述的过程，咱们能够发现，在 Pod 创立胜利后，其实就默认该 Pod 是能够被调度了，kube-scheduler 就应该开始工作了。

但在理论的场景中，Pod 通常还会须要一些其余的资源，最典型的比方存储。在一些环境中，这些资源是须要事后进行创立的，
尤其是在一些云厂商的场景中，还须要检查用户账户中是否还有余额能够用于创立云盘等 。

一但前置的依赖无奈满足，如果 kube-scheduler 曾经实现了 Pod 的调度，那么 kubelet 侧就会处于尝试创立 Pod，但失败的状况。

这个 KEP 的呈现就能够很好的解决这个问题，减少了一个 Pod 是否筹备好被调度的机制。
如果前置依赖不满足，那么 Pod 就无需被调度，这也不会耗费资源。kube-scheduler 和 kubelet 都无需进行解决。
待条件满足，Pod 再被调度和创立即可。

这个机制我个人感觉还是挺好的，甚至我能够有更灵便的策略来管制利用的正本。
比方在大流量，须要动静扩容的场景下，我能够利用此机制事后创立一些 Pod 资源以及筹备好它的依赖，
甚至能够在 Node 上筹备好镜像等。当须要减少正本时，间接标记 Pod 可被调度，

应用时，通过配置 Pod 的 .spec.schedulingGates 即可。

新增 NodeLogQuery 个性 – KEP-2258

咱们通常最习惯应用 kubectl logs 命令来获取 Kubernetes 集群中运行的利用的日志，也能够通过给它传递一些参数来调整它的过滤范畴。

比方：kubectl logs job/hello 来指定获取 hello 这个 job 的日志；也能够减少 -l / --selector='' 来基于 label 进行过滤。

但这并没有扩大到 Node 级别的日志，无奈间接获取到某个 Node 上的全副日志，要想得到这个后果须要写一段很简单的 Shell 来实现。

以后 Kubernetes 社区曾经逐步提供了更多 Node 调试工具，旨在为调试 Node 故障提供对立体验，并更好地反对极简操作系统。通过 KEP 2258: add node log query by LorbusChris · Pull Request #96120 · kubernetes/kubernetes，咱们当初能够近程获取底层 Node 日志。与容器日志记录一样，这是 Kubelet API 的一部分。

对于 Linux 零碎，它查问 journald；对于 Windows 零碎，则查问事件日志 (Event Log)。目前还没有专门针对此性能的 kubectl 命令，但能够应用如下命令进行尝试：

(MoeLove) ➜ kubectl get --raw "/api/v2/nodes/$NODE_NAME/proxy/logs/?query=kubelet

基于 CEL 的 Admission Control

对 Kubernetes 中的 Adminssion Control 感兴趣的小伙伴能够看看我之前的文章：理清 Kubernetes 中的准入管制（Admission Controller) | MoeLove

• KEP-3488: Implement secondary authz for ValidatingAdmissionPolicy by jpbetz · Pull Request #116054 · kubernetes/kubernetes
• KEP-3488: Implement Enforcement Actions and Audit Annotations by jpbetz · Pull Request #115973 · kubernetes/kubernetes

Kubernetes 在 v1.26 减少了一项很重要的个性，那就是容许应用 CEL 进行 Admission Control，具体内容能够参考我之前写的文章：
Kubernetes v1.26 新个性一览 | MoeLove

其中引入了一个新的资源 ValidatingAdmissionPolicy，应用起来如下:

apiVersion: admissionregistration.k8s.io/v1alpha1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: "demo-policy.moelove.info"
 Spec:
   failurePolicy: Fail
   matchConstraints:
     resourceRules:
     - apiGroups:   ["apps"]
       apiVersions: ["v1"]
       operations:  ["CREATE", "UPDATE"]
       resources:   ["deployments"]
   validations:
     - expression: "object.spec.replicas <= 2"

然而在过后也只是实现了 KEP-3488 的一部分。

在这个 PR 中是在实现 Authz 的局部，这容许用 CEL 表达式编写简单的 admission control 规定，
搁置在申明式资源中，而不是构建和部署 webhook。

尽管 admission webhook 始终是咱们灵便的与第三方工具集成的基石，然而对于新用户来说，它们有很多复杂性，新的 CEL 零碎无望接管仅须要对默认规定进行小批改的简略独立案例。

以前，表达式上下文会公开无关以后申请和指标资源的信息，当初通过这个 PR 能够在受权层中动静查看 RBAC 权限。
一些有用的中央可能是应用 RBAC 进行每个字段的更新权限，容许 RBAC 查看特定对象而不应用 resourceNames 零碎，
或基于请求者身份限度对程序敏感字段（例如 finalizers）的拜访而无需生成简单的 RBAC 策略。

例如：

authorizer.group('').resource('pods').namespace('default').check('create').allowed()
authorizer.path('/healthz').check('GET').allowed()
authorizer.requestResource.check('my-custom-verb').allowed()

本次还退出了 #115973，该性能容许在失败时作为次要操作收回审计日志事件，或者如果须要更多数据，能够编写一个或多个 CEL 表达式，以提供具体的值，
这些值将发送到审计子系统。

这既能够在开发新策略时提供弱小的调试选项，也能够进行运行时剖析。
其余 CEL admission 个性包含老本查看，以避免您应用所有这些新性能意外拒绝服务本人的 kube-apiserver，以及改良的类型查看。

总的来说，基于 CEL 的 admission 解决有了很多新的性能，心愿进一步将 webhook 推入到一个无限的用例空间中（避免滥用）。

Pod In-place 原地伸缩能力

这个性能容许在不重启 Pod 的状况下，更新 Pod 的 resources 配置。

• In-place Pod Vertical Scaling feature by vinaykul · Pull Request #102884 · kubernetes/kubernetes

通过 4 年的布局和至多 2 年的开发，在 Kubernetes v1.27 中终于推出了 Pod 的就地资源缩放的第一版。
这个 PR 实现了外围缩放性能和一些相干的 API 解决。
次要性能非常简单，当初能够在现有容器上编辑 resources 配置，而不会导致 API 谬误。

在看到缩放申请后，Kubelet 会立刻采取行动并查看节点是否有足够的资源来满足新的申请。
如果是这样，它将 Status.Resize 字段设置为 InProgress，并持续进行 CRI 调用和其余外部更新。

如果新的大小不适合，将启动其余状态流，但总体目标雷同，即尝试在可能的状况下提供申请的更改。
还有一个新的 per-resource 缩放策略字段，能够设置为 RestartNotRequired（默认值）示意不须要重新启动（但某些运行时依然可能须要这样做），
或设置为 Restart 以强制敞开和重新启动容器（例如具备须要从新计算 -Xmx 堆大小标记的 Java 利用）。

当初短少一个显著的个性是基于缩放的驱赶。目前，Kubelet 不会主动解决它，但如果内部零碎执行 Pod 删除，它将适当地作出反应。

只管当初还处于比拟晚期的阶段，但至多咱们看到了它的变动，期待后续的演进。

一些废除揭示

不再提供的 API 版本：

• Kubeadm v1beta2，能够应用 kubeadm config migrate 迁徙到 v1beta3。
• resource.k8s.io/v1alpha1.PodScheduling：请应用 resource.k8s.io/v1alpha2.PodSchedulingContext。
• DynamicResourceManagement v1alpha1：请应用 v1alpha2。
• CSIStorageCapacity：storage.k8s.io/v1beta1：请应用 v1。

已弃用，在下一个版本公布之前实现代替计划：

• seccomp.security.alpha.kubernetes.io/pod 和 container.seccomp.security.alpha.kubernetes.io annotations：请改用 securityContext.seccompProfile 字段。
• SecurityContextDeny 准入插件。
• service.kubernetes.io/topology-aware-hints annotations：请改用 service.kubernetes.io/topology-mode。

已删除

• Feature gates:

  • IPv6DualStack
  • ExpandCSIVolumes
  • ExpandInUsePersistentVolumes
  • ExpandPersistentVolumes
  • ControllerManagerLeaderMigration
  • CSI Migration
  • CSIInlineVolume
  • EphemeralContainers
  • LocalStorageCapacityIsolation
  • NetworkPolicyEndPort
  • StatefulSetMinReadySeconds
  • IdentifyPodOS
  • DaemonSetUpdateSurge
• appProtocol: kubernetes.io/grpc.
• kube-apiserver 参数: --master-service-namespace.
• CLI 参数: --enable-taint-manager 和 --pod-eviction-timeout.
• kubelet 参数: --container-runtime, --master-service-namespace.
• Azure disk in-tree storage plugin.
• AWS kubelet credential provider: 应用 ecr-credential-provider.

• Metrics:

  • node_collector_evictions_number 被 node_collector_evictions_total 替换
  • scheduler_e2e_scheduling_duration_seconds 被 scheduler_scheduling_attempt_duration_seconds 替换

以上就是 Kubernetes v1.27 版本中我认为次要值得关注的局部。下次再见！

欢送订阅我的文章公众号【MoeLove】