查看原文
其他

Kubernetes 1.29 新版本来了: 抛弃 iptables ...

The following article is from 道客船长 Author 刘梦姣



大家好,我是 Mengjiao Liu(mengjiao-liu),是此次 Kubernetes v1.29 发布团队成员。

预计太平洋时间 2023 年 12 月 13 日,主题为 Mandala(宇宙)的 Kubernetes 1.29 将正式发布

此版本距离上版本发布时隔 4 个月,是 2023 年的第三个版本。

新版本中 release 团队跟踪了 49 个 enhancements。其中 11 个功能升级为稳定版,19 个已有功能进行优化升级为 Beta,另有多达 19 个 Alpha 级别的全新功能。1.29 版本包含了很多重要功能以及用户体验优化,本文下一小节将详细介绍部分重要功能。

01

重要功能

[网络] KEP-3866:nftables 作为 kube-proxy 后端(Alpha)

在 Kubernetes v1.29 中,Kubernetes 使用 nftables 作为 kube-proxy 新的后端,此功能现在是 Alpha 版本。iptables 存在无法修复的性能问题,随着规则集大小的增加,性能损耗不断增加。很大程度上由于其无法修复的问题, 内核中 iptables 的开发速度已经放缓,并且大部分已经停止。新功能不会添加到 iptables 中,新功能和性能改进主要进入 nftables。nftables 能完成 iptables 能做的所有事情,而且做得更好。

特别是,RedHat 已宣布 iptables 在 RHEL 9 中已弃用,并且可能在几年后的 RHEL 10 中完全删除。Debian 从 Debian 11 (Bullseye) 中的 required 软件包中删除了 iptables。基于上述原因,kube-proxy 引入nftables 作为 kube-proxy 新的后端。

此功能的后续目标是使 nftables 成为 kube-proxy 的默认后端(替代 iptables 和 ipvs)。

管理员必须启用特征门控 NFTablesProxyMode 才能使该功能可用,然后必须使用 --proxy-mode=nftables 标志运行 kube-proxy。

需要注意的是,虽然该 nftables 模式可能与 iptables 模式非常相似,但某些 CNI 插件、NetworkPolicy 实现等可能需要更新才能使用它。这可能会带来一定的兼容性问题。

[存储] KEP-2485:PV/PVC ReadWriteOncePod 访问模式(GA)

在 Kubernetes 中,访问模式是定义如何使用持久存储的方式。这些访问模式是持久卷 (PV) 和持久卷声明 (PVC) 规范的一部分。ReadWriteOncePod 作为第四种访问模式(之前的三种访问模式:ReadWriteOnce、ReadOnlyMany、ReadWriteMany)在 Kubernetes v1.22 中作为 Alpha 功能被引入,在 Kubernetes v1.29 中到达 GA。这一功能的主要目的是提供对存储资源的更灵活的访问控制, 确保只有一个 Pod 能够以读写模式访问该存储。这种限制对于一些特定的应用场景非常有用,例如,确保只有一个 Pod 能够修改存储中的数据,以防止数据冲突或损坏。

此功能也更新了 Kubernetes 调度程序以支持与 ReadWriteOncePod 存储相关的 pod 抢占。这意味着,如果两个 Pod 使用 ReadWriteOncePod 请求 PersistentVolumeClaim,则具有最高优先级的 Pod 将获得对 PersistentVolumeClaim 的访问权限, 而任何具有较低优先级的 pod 将从节点中被抢占,并且无法访问 PersistentVolumeClaim。

下面的示例是使用 ReadWriteOncePod 访问模式创建一个新的 PVC:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: single-writer-only
spec:
  accessModes:
  - ReadWriteOncePod 
  resources:
    requests:
      storage: 1Gi

通过引入 ReadWriteOncePod 功能,Kubernetes 使得用户能够更好地控制存储资源的访问权限,提高了应用程序在容器化环境中对存储的管理灵活性。

[Auth] KEP-3299:KMS v2 增强(GA)

保护 Kubernetes 集群时首先要考虑的事情之一是加密静态的 etcd 数据。KMS 为供应商提供了一个接口,以便利用存储在外部密钥服务中的密钥来执行此加密。

Kubernetes KMS(Key Management Service)对于 secret 的安全管理和加密至关重要。随着 Kubernetes 1.29 版本的发布, 具有特性门控 KMSv2 和 KMSv2KDF 的 KMSv2 功能已升级为 GAKMSv1 特性门控现在默认处于禁用状态。

这已成为一项稳定的功能,专注于改进 KMS 插件框架,这对于安全管理至关重要。这些改进确保 Kubernetes secret 仍然是存储敏感信息的强大且安全的方法。

[节点] KEP-753:原生支持 Sidecar 容器 (Beta)

原生支持 Sidecar 容器 Kubernetes v1.28 中被引入作为 Alpha,v1.29 中升级至 Beta,特性门控 SidecarContainers 默认启用。

从 Kubernetes v1.29 开始,如果你的 Pod 包含一个或多个 sidecar 容器(具有始终重启策略的 init 容器), Kubelet 将延迟向这些 Sidecar 容器发送 TERM 信号,直到最后一个主容器完全终止。Sidecar 容器将以 Pod 规范中定义的相反顺序终止。这可确保 Sidecar 容器继续为 Pod 中的其他容器提供服务,直到不再需要它们为止。

[Auth/Apps] KEP-2799:减少基于 Secret 的服务帐户令牌(Service Account Token)(Beta)

legacy-service-account-token-cleaner 控制器作为 kube-controller-manager 的一部分运行, LegacyServiceAccountTokenCleanUp 特性门控现在可作为 Beta 使用(默认情况下启用)。legacy-service-account-token-cleaner 控制器会循环删除在 --legacy-service-account-token-clean-up-period 指定的时间内未使用的服务帐户令牌密钥(默认为一年)。控制器通过向 Secret 添加名为 kubernetes.io/legacy-token-invalid-since 的标签(以当前日期作为值)来标记 Secret 无效。如果无效的 Secret 在指定时间内没有被使用,控制器将删除它

以下是自动生成的旧令牌的示例,该令牌已标记有 kubernetes.io/legacy-token-last-used 和 kubernetes.io/legacy-token-invalid-since 标签:

apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  namespace: default
  labels:
    kubernetes.io/legacy-token-last-used: 2022-10-24
    kubernetes.io/legacy-token-invalid-since: 2023-10-25
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token

[Windows] KEP-1287:Windows 支持 Pod 资源原地升级(In-Place Update)(Alpha)

Kubernetes v1.29 中,Windows 支持了 Pod 资源原地升级(In-Place Update)功能,允许在不重新创建 Pod 或重新启动容器的情况下更改资源。

[网络] KEP-1880:动态扩展 Service 的可用 IP 范围(Alpha)

Service 是公开在一组 Pod 上运行的应用程序的抽象方式。Service 可以具有集群范围的虚拟 IP 地址, 该地址是从 kube-apiserver 标志中设置的预定义 CIDR 分配的。但是,用户可能希望添加、删除或调整为服务分配的现有 IP 范围, 而无需重新启动 kube-apiserver。

此功能允许集群管理员使用 ServiceCIDR 对象动态调整分配给集群的服务 IP 范围的大小,以处理 IP 耗尽或 IP 重新编号等问题。

在安装引导期间,此功能会根据 kube-apiserver 的 --service-cluster-ip-range 命令行参数的值创建一个名为 kubernetes 的默认 ServiceCIDR 对象。

如果要使用此功能,用户需要启用 MultiCIDRServiceAllocator 特性门控和 networking.k8s.io/v1alpha1 API, 并且创建或删除新的 ServiceCIDR 对象来管理服务的可用 IP 范围。

示例如下:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1alpha1
kind: ServiceCIDR
metadata:
  name: newservicecidr
spec:
  cidrs:
  - 10.96.0.0/24
EOF

[调度] KEP-3633:将 MatchLabelKeys/MismatchLabelKeys 引入 Pod 亲和性和 Pod 反亲和性(Alpha)

Kubernetes v1.29 中 PodAffinity/PodAntiAffinity 中将引入一项增强功能作为 Alpha 版本。它将提高滚动更新期间计算的准确性。此功能向 PodAffinityTerm 引入一个补充字段 MatchLabelKeys。这使用户能够在现有 LabelSelector 之上精细控制 PodAffinity 或 PodAntiAffinity 的范围。

MatchLabelKeys/MismatchLabelKey 是一组 Pod 标签键,用于选择要考虑哪些 Pod。key 用于从传入 Pod 标签中查找 value。MatchLabelKeys 获得的 Pod key-value 标签与 LabelSelector 合并为 key in (value), MismatchLabelKeys 获得的 Pod key-value 与 LabelSelector 合并为 key notin (value), 以选择现有 Pod 组,传入 Pod 时将考虑这些 Pod(反)亲和力。传入 Pod 标签中不存在的键将被忽略。默认值为空。禁止在 MatchLabelKeys/MismatchLabelKey 和 LabelSelector 中同时存在相同的键。另外,如果未设置 LabelSelector,则无法设置 MatchLabelKeys/MatchLabelKeys。这是一个 Alpha 字段,需要启用 MatchLabelKeysInPodAffinity 特性门控。

设置了 MatchLabelSelector 后,新创建的 Pod 的调度会受到影响。所有现有的 Pod 都不受影响。

以 matchLabelKeys 为例,存在 key-value 对 app:database 和 存在 pod-template-hash key 以及值也相同的 Pod 会被调度到同一节点。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-server
...
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
        topologyKey: topology.kubernetes.io/zone
        matchLabelKeys: 
        - pod-template-hash

[Instrumentation] KEP-727:Kubelet 资源指标(GA)

Kubelet 使用 Prometheus 客户端库以 Prometheus 文本展示格式在 /metrics/resource 公开端点。它提供集群级资源指标 API 所需的指标, 用以替代 Summary API 提供的指标杂且多的问题

在 Kubernetes v1.29 中,将以下 kubelet 资源指标升级为 GA:

  • 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 弃用(重命名)指标 scrape_error,改为 resource_scrape_error

[Instrumentation] KEP-3466:Kubernetes 组件运行状况 SLIs(GA)

由 ComponentSLIs 特性门控控制并在 /metrics/slis 端点提供服务的指标现在是 GA 和无条件启用的。特性门控将在 1.31 被移除。

访问 /metrics/slis 端点返回的数据示例如下:

# HELP kubernetes_healthcheck [ALPHA] This metric records the result of a single healthcheck.
# TYPE kubernetes_healthcheck gauge
kubernetes_healthcheck{name="autoregister-completion",type="healthz"} 1
kubernetes_healthcheck{name="autoregister-completion",type="readyz"} 1
kubernetes_healthcheck{name="etcd",type="healthz"} 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="log",type="healthz"} 1
kubernetes_healthcheck{name="log",type="readyz"} 1
kubernetes_healthcheck{name="ping",type="healthz"} 1
kubernetes_healthcheck{name="ping",type="readyz"} 1
# HELP kubernetes_healthchecks_total [ALPHA] This metric records the results of all healthcheck.
# TYPE kubernetes_healthchecks_total counter
kubernetes_healthchecks_total{name="autoregister-completion",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="etcd",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="etcd",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="etcd-readiness",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="informer-sync",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="informer-sync",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="log",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="log",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="readyz"} 15

[存储] KEP-3107:NodeExpandSecret 添加到 CSI 持久卷源(GA)

NodeExpandSecret 功能在 v1.29 中移至 GA。此功能将 NodeExpandSecret 添加到 CSI 持久卷源, 并使 CSI 客户端能够将其作为 NodeExpandVolume 请求的一部分发送到 CSI 驱动程序

[存储] KEP-3751:VolumeAttributesClass(Alpha)

VolumeAttributesClass 功能在 v1.29 中引入,现在处于 Alpha 阶段,默认不启用。需要在 kube-apiserver、 kube-controller-manager、external-provisioner 和 external-resizer 组件都启用 VolumeAttributesClass 特性门控才能使用此功能。

此功能对 Kubernetes 持久卷 API 进行扩展,以允许用户在配置后更改卷属性(例如 IOPS 或吞吐量)

需要注意的是,在 v1.29 中·VolumeAttributesClass 功能可能仅包含 API 更改,其功能尚未实现。实现在 external-provisioner 和 external-resizer 中,将在 Kubernetes v1.29 发布后异步发布。

CSI 对应标准版本为 1.9,各个厂商 CSI 实现的控制器插件, 必须支持 MODIFY_VOLUME 能力。

[Instrumentation] KEP-3077:kube-scheduler 已转换为上下文日志记录(Alpha)

Kubernetes v1.24 中引入的上下文日志记录功能现已成功迁移到两个组件(kube-scheduler 和 kube-controller-manager)以及一些目录。该功能旨在为 Kubernetes 提供更多有用的日志以更好地进行问题追踪、故障排除。目前该功能处于 Alpha 阶段,如需使用请启用 ContextualLogging 特性门控。

示例:

I1113 08:43:37.029524 87144 default_binder.go:53] "Attempting to bind pod to node" logger="Bind.DefaultBinder" pod="kube-system/coredns-69cbfb9798-ms4pq" node="127.0.0.1"

[节点] KEP-127:启用 Pod 安全标准(Pod Security Standards)的用户命名空间支持 (Alpha)

添加了 UserNamespacesPodSecurityStandards 特性门控,以启用对 Pod 安全标准的用户命名空间支持。启用此功能将修改所有 Pod 安全标准规则以允许设置:spec[.*].securityContext.[runAsNonRoot,runAsUser]。仅当集群中的所有节点都支持用户命名空间功能并启用它时,才应启用此特性门控在未来的 Kubernetes 版本中,特性门控不会升级或默认启用。

[节点] KEP-4191:Kubelet 支持镜像文件系统(Image Filesystem)被分割 (Alpha)

Kubelet 支持镜像文件系统(Image Filesystem)被分割在 v1.29 中被引入作为 Alpha,由特性门控 KubeletSeparateDiskGC 控制是否启用,默认不启用。Kubelet 可以支持将 ImageFilesystem 分为可写层和只读层,可写层与 Kubelet 位于同一磁盘上,镜像可以位于单独的文件系统上。

[节点] KEP-4210:添加对 ImageMaximumGCAge 字段的支持 (Alpha)

将 ImageMaximumGCAge 字段添加到 Kubelet 配置中,该字段允许用户设置镜像在被垃圾收集之前未使用的最长期限该字段由特性门控 ImageMaximumGCAge 控制,当前为 Alpha,默认不启用。

[Auth] KEP-4193:绑定服务帐户令牌增强 (Alpha)

Kubernetes v1.29 新增了 4 个特性门控来增强绑定服务帐户令牌。kube-apiserver 现在通过 ServiceAccountTokenJTI 特性门控添加了对 Alpha 版本的支持, 以在其发放的服务账户令牌中添加 jti(JWT ID)声明。此外,在令牌发放时,还会在审计日志中添加 authentication.kubernetes.io/credential-id 审计注释,并在使用令牌进行身份验证时, 在额外的用户信息中添加 authentication.kubernetes.io/credential-id 条目。

kube-apiserver 现在通过 ServiceAccountTokenPodNodeInfo 特性门控添加了对 Alpha 版本的支持, 以在服务账户令牌中添加节点名称(以及节点存在时的 UID)作为额外声明。这些令牌与 Pod 绑定,并在使用令牌进行身份验证时, 还会提供 authentication.kubernetes.io/node-name 和 authentication.kubernetes.io/node-uid 作为额外的用户信息。

kube-apiserver 现在通过 ServiceAccountTokenNodeBinding 特性门控添加了对 Alpha 版本的支持,以允许 TokenRequests 直接将令牌绑定到节点, 并在使用令牌时进行验证(通过 ServiceAccountTokenNodeBindingValidation 特性门控),以确保节点名称和 UID 仍然存在


02

升级
注意事项

EventedPLEG 存在严重问题

EventedPLEG 功能 使用事件驱动的 PLEG)在 Kubernetes v1.27 中已经升级为 Beta,但是默认不开启。在 v1.29 测试中发现了严重问题,建议不要启用它!社区正在进行调查和修复,但尚未找到具体原因。

SchedulerQueueingHints 特性门控默认设置为禁用状态

对于 Kubernetes 项目来说,调度器的吞吐量多年来一直是一个永恒的挑战,SIG Scheduling 一直在努力通过许多增强来提高调度吞吐量。QueueingHint 功能为优化重新排队效率带来了新的可能性,可以显著减少无用的调度重试

在 v1.28 中,只有一个 alpha 插件 (DRA) 支持 QueueingHint, 在 v1.29 中,一些稳定的插件开始实现 QueueingHint。

QueueingHint 从 v1.28 引入以来就是 Beta 状态,直接跳过了 Alpha 阶段,默认启用。但是在 v1.29 中, SchedulerQueueingHints 特性门控默认设置为禁用状态。因为启用它之后内存使用量意外增加,并且某些插件实现的 QueueingHint 中发现了回归问题。建议在 v1.29 中不要启用它,社区正在紧急修复

in-tree cloud providers 的移除升级至 Beta 状态

in-tree cloud providers 的移除在 Kubernetes v1.29 状态升级为 Beta,用户需要注意特性门控 DisableCloudProviders 和 DisableKubeletCloudCredentialProvider 现在默认为 true, 这意味着在默认运行时不与任何云提供商(比如 Azure, GCE,vSphere)任何进行内置集成。如果你仍然需要此功能, 请设置 DisableCloudProviders 和 DisableKubeletCloudCredentialProvider 特性门控为 false 或者使用外部云控制管理器。

有关如何启用和运行外部云控制器管理器的更多信息,请阅读云控制器管理器管理[2]。

如果你需要为旧的 in-tree cloud providers 提供云控制器管理器,请参阅以下链接:

Cloud provider AWS:
https://github.com/kubernetes/cloud-provider-aws
Cloud provider Azure:
https://github.com/kubernetes-sigs/cloud-provider-azure
Cloud provider GCE:
https://github.com/kubernetes/cloud-provider-gcp
Cloud provider OpenStack:
https://github.com/kubernetes/cloud-provider-openstack
Cloud provider vSphere:
https://github.com/kubernetes/cloud-provider-vsphere

Kubernetes 旧版软件包仓库已被冻结

Kubernetes 旧版软件包仓库(apt.kubernetes.io 和 yum.kubernetes.io)已于 2023 年 9 月 13 日被冻结,Kubernetes v1.29 及以后的版本将仅发布软件包到社区拥有的仓库(pkgs.k8s.io)。已弃用的旧仓库及其内容预计将于 2024 年 1 月删除。Kubernetes 项目强烈建议尽快迁移到新的社区拥有的仓库!

更多详情以及如何迁移请参考 Kubernetes 旧版软件包仓库将于 2023 年 9 月 13 日被冻结博客[3]。

其他需要注意的变化

  • 删除网络 ClusterCIDR Alpha API, SIG 对此功能存在合理性怀疑,经过几个月的社区讨论,删除仍在 Alpha 中的现有代码。

  • 弃用 Node 的 status.nodeInfo.kubeProxyVersion 字段,该字段不准确,它是由 kubelet 设置的,kubelet 实际上并不知道 kube-proxy 版本,或者 kube-proxy 是否正在运行。

  • 弃用 FlowSchema 和 PriorityLevelConfiguration 的 flowcontrol.apiserver.k8s.io/v1beta2 API version, 并且 flowcontrol.apiserver.k8s.io/v1beta3已升级为 flowcontrol.apiserver.k8s.io/v1。如果你的清单或客户端软件使用已弃用的 Beta API 组, 则应升级到 v1.29 之前更改这些。

03

版本标志

本次发布的主题是:Mandala(曼陀罗,宇宙)。

与我们一起踏上 Kubernetes v1.29 的宇宙之旅!

这个版本的灵感来自于曼陀罗(Mandala)这一美丽的艺术形式——它是宇宙完美表达的象征。此次发布社区大约有 40 名发布团队成员,得到数百名社区贡献者的支持,他们辛勤工作,将挑战转化为全球数百万人的喜悦。曼陀罗主题反映了社区的相互关联,充满活力。每位贡献者都是一个至关重要的部分,他们像曼陀罗艺术中的多样图案一样,为其中添加了独特的能量。Kubernetes 在协作中茁壮成长,回应着曼陀罗创作中的和谐。

发布标志由 Mario Jason Braganza[4] 制作(基于曼陀罗艺术,感谢 - Fibrel Ojalá[5]), 象征着 Kubernetes 项目及其所有成员的小宇宙。

秉持曼陀罗变革象征的精神,Kubernetes v1.29 庆祝着我们项目的演变。就像 Kubernetes 宇宙中的星星一样,每个贡献者、用户和支持者都为之照亮道路。我们共同创造了一个可能性的世界。

04

参考链接

[1] 贡献列表:
https://www.stackalytics.io/cncf?project_type=cncf-group&release=all&metric=commits&module=github.com/kubernetes/kubernetes&date=120
[2] 云控制器管理器:
https://github.com/DaoCloud-OpenSource/docs/blob/362f9d405db1f6af32032ff7a95937a643c5dfc0/kubernetes/sig-release/v1.29/kubernetes.io/zh-cn/docs/tasks/administer-cluster/running-cloud-controller
[3] Kubernetes 旧版软件包仓库将于 2023 年 9 月 13 日被冻结博客:
https://kubernetes.io/zh-cn/blog/2023/08/31/legacy-package-repository-deprecation/
[4] Mario Jason Braganza:
https://janusworx.com/
[5] Fibrel Ojalá:
https://pixabay.com/users/fibrel-3502541/
[6] Kubernetes 增强特性:
http‍s://kep.k8s‍.io/

[7] Kubernetes 1.29 发布团队:

https://github.com/kubernetes/sig-release/blob/master/releases/release-1.29

[8] Kubernetes 1.29 变更日志:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md

[9] Kubernetes 1.29 主题讨论:
https://github.com/kubernetes/sig-release/discussions/2349

 本文作者 

刘梦姣

「DaoCloud 道客」 开源工程师、

Kubernetes SIG Docs Approver、Kubernetes WG structured logging Reviewer





快速加 K8s学习交流群,与大佬共卷!

扫码加我微,进群和大们零距
继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存