Kubernetes v1.29 是 2023 年的第三个大版本更新,也是今年的最后一个大版本,包含了 49 项主要的更新。 而今年发布的第一个版本 v1.27 有近 60 项,第二个版本 v1.28 有 46 项。尽管 Kubernetes 已经发布快 10 年了,Kubernetes 的生命力仍然很旺盛!
这个版本中有 19 个增强功能正在进入 Alpha 阶段,19 个将升级到 Beta 阶段,而另外 11 个则将升级到稳定版。
可以看出来还是有很多新特性在逐步引入。
我维护的 「k8s生态周报」每篇都有一个叫上游进展的部分,会发一些值得关注的内容。不过正如我上篇提到的那样,最近发生了很多事情,断更了一段时间,这篇恰好都补上,感谢大家的支持。
KEP-2876: 基于 CEL 的 CRD 规则校验正式达到 GA
这个特性对于所有在 Kubernetes 上进行开发的小伙伴来说应该都是非常重要的。因为大多数情况下,我们都是通过 CRD 来实现 Kubernetes 中的功能扩展。
在通过 CRD 实现功能扩展的时候,为了能提供更好的用户体验,和更可靠的输入校验,就需要支持校验了。
CRD 目前原生支持两类校验能力:
基于 CRD 结构定义的校验 OpenAPIv3 的校验规则
例如:
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.13.0
name: kongplugins.configuration.konghq.com
spec:
group: configuration.konghq.com
names:
categories:
- kong-ingress-controller
kind: KongPlugin
listKind: KongPluginList
plural: kongplugins
shortNames:
- kp
singular: kongplugin
scope: Namespaced
versions:
name: v1
schema:
openAPIV3Schema:
description: KongPlugin is the Schema for the kongplugins API.
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
protocols:
description: Protocols configures plugin to run on requests received on
specific protocols.
items:
description: KongProtocol is a valid Kong protocol. This alias is necessary
to deal with https://github.com/kubernetes-sigs/controller-tools/issues/342
enum:
- http
- https
- grpc
- grpcs
- tcp
- tls
- udp
type: string
type: array
type: object
...
x-kubernetes-validations:
- message: Using both config and configFrom fields is not allowed.
rule: '!(has(self.config) && has(self.configFrom))'
- message: Using both configFrom and configPatches fields is not allowed.
rule: '!(has(self.configFrom) && has(self.configPatches))'
- message: The plugin field is immutable
rule: self.plugin == oldSelf.plugin
以上示例中定义了一个名为 KongPlugin
的自定义资源,其中使用 openAPIV3Schema
定义了 OpenAPI schema 的校验规则。
但这些内置规则能达到的效果相对有限,如果想要实现更加丰富的校验规则/特性,则可以使用:
Admission Webhook: 关于 Adminssion webhook 可以参考我之前的文章 理清 Kubernetes 中的准入控制(Admission Controller) | MoeLove 使用自定义验证器:例如基于 Open Policy Agent(OPA) 的 Gatekeeper,关于 OPA 可以参考 Open Policy Agent (OPA) 入门实践 | MoeLove
不过 无论是 Admission webhook 还是自定义验证器,它们与 CRD 自身都是分离的,并且这也会导致开发 CRD 的难度和后续的维护成本增加。
为了能解决这些问题,Kubernetes 社区为 CRD 引入了一种基于 CEL(Common Expression Language)的校验规则,这个规则是可以直接 在 CRD 的声明文件中编写的,无需使用任何 Admission webhook 或者自定义验证器,大大简化了 CRD 的开发和维护成本。
我从社区刚开始想要引入这个功能起就一直在文章中宣传该功能了,持续关注的小伙伴对这个应该不算陌生了。我大概查看了以下文章中都有介绍 Kubernetes 中 CEL 相关特性的演进过程,感兴趣的小伙伴可以逐篇阅读:
两年前的 K8S 生态周报| Kubernetes v1.23.0 正式发布,新特性一览 | MoeLove 一年前的 Kubernetes v1.26 新特性一览 | MoeLove K8S 生态周报| Kubernetes 基于 CEL 的控制系统再添新特性 | MoeLove Kubernetes v1.27 新特性一览 | MoeLove
在 Kubernetes v1.29 版本中基于 CEL 的 CRD 校验能力达到 GA,只需要使用 x-kubernetes-validations
定义校验规则即可, 它足够轻量且安全,可以直接在 kube-apiserver 中运行,我们来看一个例子:
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.13.0
name: kongplugins.configuration.konghq.com
spec:
group: configuration.konghq.com
scope: Namespaced
versions:
name: v1
schema:
openAPIV3Schema:
description: KongPlugin is the Schema for the kongplugins API.
properties:
plugin:
...
x-kubernetes-validations:
- message: Using both config and configFrom fields is not allowed.
rule: '!(has(self.config) && has(self.configFrom))'
- message: The plugin field is immutable
rule: self.plugin == oldSelf.plugin
例如其中的这句 self.plugin == oldSelf.plugin
,self
和 oldSelf
代表了变化前后的资源对象, 一旦定义了 plugin
字段的内容,则不允许修改它。
此外,CEL 还有非常丰富的特性,可以通过在线的 Playground 来体验它 https://playcel.undistro.io/
正如我前面提到的,这个特性引入的时间已经两年多了,在 Kubernetes v1.25 中达到 Beta 并默认开启,如今终于达到了 GA。
额外一说,Kubernetes Gateway API 项目正在将它的所有 Admission webhook 删掉,全部使用基于 CEL 的规则进行校验, 这大概是目前社区中最大的一个用例了。
KEP-3668: 为动态和静态分配预留 NodePort 端口范围达到 stable
众所周知 Kubernetes 原生的 Service 对象有一种 NodePort 的类型,用于将集群内的服务暴露到集群外。
在当前情况下,如果用户想要新建一个 NodePort,并为它固定的指定一个 Port,其实是存在一定的风险的。有可能指定的 Port 已经被分配出去了,这样就会冲突,导致 Service 创建失败。
这个 KEP 提出了为 NodePort 类型的 Services 动、静态地预留一段可选区间,并且支持两种方式进行 Port 配置:
自动化地随机生成(由 Kubernetes 按照规则自动生成) 手工设置(由用户根据需求自行设定)。
举个例子:
kube-apiserver 可以通过 --service-node-port-range
控制 NodePort 可以使用的端口范围,默认是 30000-32767
。在这个 KEP 中引入的计算公式是:min(max($min, node-range-size/$step), $max)
,也就是说:
Service Node Port 范围: 30000-32767 范围大小: 32767 - 30000 = 2767 Band Offset: min(max(16,2767/32),128) = min(86,128) = 86 Static band start: 30000 Static band ends: 30086
按照这种方式计算,也就是 30000-30086 作为 static 段,之后的作为 dynamic 段。
┌─────────────┬─────────────────────────────────────────────┐
│ static │ dynamic │
└─────────────┴─────────────────────────────────────────────┘
◄────────────► ◄────────────────────────────────────────────►
30000 30086 32767
如果用户想要自己指定一个 NodePort 的端口,若在 static 范围内,则相对来说不容易出现冲突。
不过,总体来说这个特性实际上是一个 Kubernetes 内部的特性,多数情况下只要记住一个原则:“手动指定 NodePort 时尽量选择在 static 范围(前段)内即可”。如果用户指定的 Port 在 dynamic 范围内,如果该 Port 尚未被分配,则也可以创建成功。
这种计算方式实际上是来自于 KEP-3070,用于给 Service 分配 ClusterIP 使用的。
KEP-753:SidecarContainers 特性达到 Beta 并默认启用
Sidecars 是一种辅助容器,它们能够给主容器添加额外功能。尽管这种模式在 Service Mesh 场景用例更多,但很多用户也会在非 Service Mesh 场景下使用,比如像日志记录、监控等场景。
但是之前 Sidecars 在这些场景中使用存在一些问题,比如当 Pod 删除的时候,由于 Sidecar 容器的生命周期管理的缺失,会导致这些服务和主容器的生命周期不同步,进而影响服务的可靠性。
这个 KEP 在 Pod 规范中将 Sidecar 容器定义为 init containers 的一部分,并且指定其具有“始终重启”策略。
apiVersion: v1
kind: Pod
metadata:
name: moelove-pod
spec:
initContainers:
- name: log
image: moelove/fluentbit
restartPolicy: Always
...
在 Kubernetes v1.29 版本中该特性将默认启用,同时 Sidecar containers 的停止顺序将按照与它们启动时候相反的顺序来进行,这样一方面可以确保是主容器先停止的,另一方面也便于控制所有组件的生命周期。
KEP-3960: PreStop Hook 引入 Sleep 动作(Alpha)
这个 KEP 也比较有意思,主要是为了简化一个最常见的需求。
很多应用 Pod 在关闭的时候,需要断开连接,以免影响用户流量。所以很多时候会在关闭前设置 PreStop 来进行一些相关的处理或者等待。
但是当前的 PreStop Hook 只支持 exec
和 httpGet
这两种,这个 KEP 是想要实现一种原生的 sleep
操作,例如:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
template:
spec:
containers:
- name: nginx
image: nginx:1.25.3
lifecycle:
preStop:
sleep:
seconds: 5
readinessProbe:
httpGet:
path: /
port: 80
这样就可以很简单了。在引入这个 KEP 之前,需要设置为类似 exec sh -c "sleep 5"
这样,这需要容器内还包含 sleep
这个命令才行。
不过这个特性目前处于 Alpha,能否最终 GA 还需要看看社区的反馈。
KEP-4193:改善 service account token 绑定机制(Alpha)
在 Kubernetes 中,service account token 是保障安全性不可或缺的一环。它们用于验证集群中各个工作负载,并且可以防止未经授权访问。
Kubernetes v1.29 中进一步加强了对这些令牌的安全保护:现在每个 service account 仅能与特定 Pod 实例相关联,在外泄后也无法被滥用。这种方式有效地将 service account 和 Pod 生命周期捆绑在一起,大大减少了攻击者利用盗取 token 进行攻击的可能。
在 v1.29 中 kube-apiserver 有如下相关的 feature gates 可以控制相关的特性,当然除了 KEP-4193 外,这个版本中也推进了 KEP-2799,减少了基于 secret 的 service account token。这有助于缩短 Token 的有效时间,尽可能的减少攻击面。
LegacyServiceAccountTokenCleanUp=true|false (BETA - default=true)
ServiceAccountTokenJTI=true|false (ALPHA - default=false)
ServiceAccountTokenNodeBinding=true|false (ALPHA - default=false)
ServiceAccountTokenNodeBindingValidation=true|false (ALPHA - default=false)
ServiceAccountTokenPodNodeInfo=true|false (ALPHA - default=false)
KEP-727:Kubelet Resource Metrics 达到 GA
这是一个有很长历史的 KEP 了,从开始提出到现在 GA 用了 5 年的时间,中间也发生了很多有趣的事情。这次主要涉及的部分是如下 metrics:
container_cpu_usage_seconds_total
container_memory_working_set_bytes
container_start_time_seconds
node_cpu_usage_seconds_total
node_memory_working_set_bytes
pod_cpu_usage_seconds_total
pod_memory_working_set_bytes
resource_scrape_error
以下是一个示例的输出:
# HELP container_cpu_usage_seconds_total [STABLE] Cumulative cpu time consumed by the container in core-seconds
# TYPE container_cpu_usage_seconds_total counter
container_cpu_usage_seconds_total{container="coredns",namespace="kube-system",pod="coredns-55968cc89d-bhhbx"} 0.195744 1691361886865
# HELP container_memory_working_set_bytes [STABLE] Current working set of the container in bytes
# TYPE container_memory_working_set_bytes gauge
container_memory_working_set_bytes{container="coredns",namespace="kube-system",pod="coredns-55968cc89d-bhhbx"} 1.675264e+07 1691361886865
# HELP container_start_time_seconds [STABLE] Start time of the container since unix epoch in seconds
# TYPE container_start_time_seconds gauge
container_start_time_seconds{container="coredns",namespace="kube-system",pod="coredns-55968cc89d-bhhbx"} 1.6913618235901163e+09 1691361823590
# HELP node_cpu_usage_seconds_total [STABLE] Cumulative cpu time consumed by the node in core-seconds
# TYPE node_cpu_usage_seconds_total counter
node_cpu_usage_seconds_total 514578.636 1691361887931
# HELP node_memory_working_set_bytes [STABLE] Current working set of the node in bytes
# TYPE node_memory_working_set_bytes gauge
node_memory_working_set_bytes 1.9501084672e+10 1691361887931
# HELP pod_cpu_usage_seconds_total [STABLE] Cumulative cpu time consumed by the pod in core-seconds
# TYPE pod_cpu_usage_seconds_total counter
pod_cpu_usage_seconds_total{namespace="kube-system",pod="coredns-55968cc89d-bhhbx"} 1.30598 1691361880003
# HELP pod_memory_working_set_bytes [STABLE] Current working set of the pod in bytes
# TYPE pod_memory_working_set_bytes gauge
pod_memory_working_set_bytes{namespace="kube-system",pod="coredns-55968cc89d-bhhbx"} 1.6715776e+07 1691361880003
# HELP resource_scrape_error [STABLE] 1 if there was an error while getting container metrics, 0 otherwise
# TYPE resource_scrape_error gauge
resource_scrape_error 0
# HELP scrape_error [ALPHA] 1 if there was an error while getting container metrics, 0 otherwise
# TYPE scrape_error gauge
scrape_error 0
KEP-3466: Kubernetes Component Health SLIs 达到 GA
这个 KEP 的主要目的是为了让每个组件暴露它们自己的健康状态,以便于可以根据其健康状态的 SLI 计算集群的 SLO。
很久之前 Kubernetes 中存在一个 ComponentStatus,可以用于查看集群中组件的状态。但正如下方所示,在 v1.19 已经实际上废弃了。
moelove@k8s-test:~$ kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
etcd-0 Healthy ok
controller-manager Healthy ok
我们期望能通过这个 KEP 使用各个组件的健康状态作为 SLI,采集聚合后,计算出集群的 SLO。进而可以给出 SLA。(关于它们之间的关系有兴趣的小伙伴可以搜索下相关内容)
以下是一个示例的输出:
tao@moelove:/$ kubectl get --raw "/metrics/slis"
# HELP kubernetes_healthcheck [STABLE] This metric records the result of a single healthcheck.
# TYPE kubernetes_healthcheck gauge
kubernetes_healthcheck{name="etcd",type="healthz"} 1
kubernetes_healthcheck{name="etcd",type="livez"} 1
kubernetes_healthcheck{name="etcd",type="readyz"} 1
kubernetes_healthcheck{name="etcd-readiness",type="readyz"} 1
kubernetes_healthcheck{name="informer-sync",type="readyz"} 1
kubernetes_healthcheck{name="ping",type="healthz"} 1
kubernetes_healthcheck{name="ping",type="livez"} 1
kubernetes_healthcheck{name="ping",type="readyz"} 1
已知问题
EventedPLEG
这个特性在 v1.27 中升级到了 Beta,但是在新版本的测试中发现了比较多的问题,所以现在将它默认禁用了,待社区修复后会再打开。建议在 v1.29 中先关闭此特性
其他
KEP-2495: PV/PVC ReadWriteOncePod
达到 GANodeExpandSecret 特性达到 GA kube-proxy 有了个 nftables 的新后端
这就是我觉得 Kubernetes v1.29 中主要值得关注的内容了。下次再见!
温馨提示:文章内容系作者个人观点,不代表Docker中文社区对观点赞同或支持。
版权声明:本文为转载文章,来源于 张晋涛 ,版权归原作者所有,欢迎分享本文,转载请保留出处!
发表评论