▲ 点击上方"DevOps和k8s全栈技术"关注公众号
Kubernetes 1.29已正式发布，距离上一个版本发布已过去4个月，是2023年的第三个版本，也是今年的最后一个版本。
在这个新版本中，Release团队跟踪了49个增强功能。其中，11个功能已升级为稳定版，19个现有功能进行了优化并升级为Beta版本，同时还引入了多达19个全新的Alpha级别功能。1.29版本包含了许多重要功能和用户体验的优化。在下一小节中，我们将详细介绍一些重要的功能。
本文介绍了 Kubernetes v1.29 中引入的一些重要功能，涉及网络、存储、认证、节点、Windows 支持、调度等多个领域。这些功能包括 nftables 作为 kube-proxy 后端、PV/PVC ReadWriteOncePod 访问模式、KMS v2 增强、原生支持 Sidecar 容器、减少基于 Secret 的服务账号令牌、Windows 支持 Pod 资源原地升级、动态扩展 Service 的可用 IP 范围、Pod 亲和性和反亲和性的增强、以及新的调度优化特性 QueueingHint。
1. 网络
1.1 KEP-3866: nftables 作为 kube-proxy 后端（Alpha）
在 Kubernetes v1.29 中，引入了 nftables 作为 kube-proxy 新的后端。由于 iptables 存在性能问题，nftables 被引入以解决这些问题，并且成为 kube-proxy 的替代方案。管理员需要启用 NFTablesProxyMode 特征门控，并使用 --proxy-mode=nftables 标志来运行 kube-proxy。注意，使用 nftables 后端可能需要对某些 CNI 插件和 NetworkPolicy 实现进行更新，可能带来一些兼容性问题。下面是一个简单的案例演示如何启用并配置此功能。
步骤 1: 启用 NFTablesProxyMode 特征门控
在 Kubernetes v1.29 中，首先需要启用 NFTablesProxyMode 特征门控。通过编辑 kube-apiserver 的配置文件，添加如下配置：
apiVersion: kubeadm.k8s.io/v1beta3kind: ClusterConfigurationfeatureGates:NFTablesProxyMode: true
步骤 2: 更新 kube-proxy 启动参数
确保 kube-proxy 启动时使用了 --proxy-mode=nftables 参数。可以通过修改 kube-proxy 的启动参数或配置文件来实现。以下是 kube-proxy 的简化配置文件示例：
apiVersion: kubeproxy.config.k8s.io/v1alpha1kind: KubeProxyConfigurationmode: "ipvs"ipvs:scheduler: rrnftables:enabled: true
步骤 3: 部署 kube-proxy
使用修改后的配置文件或更新的命令行参数，部署 kube-proxy。如果是使用 kubeadm 部署，可以通过以下方式更新 kube-proxy：
kubeadm upgrade apply v1.29.0步骤 4: 验证 nftables 启用
检查 kube-proxy 是否已经使用 nftables 作为后端。可以使用以下命令：
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode输出应该包含如下行：
mode: "ipvs"2. 存储
2.1 KEP-2495: PV/PVC ReadWriteOncePod 访问模式（GA）
引入了 ReadWriteOncePod 访问模式，作为对持久存储更灵活访问控制的解决方案。此模式确保只有一个 Pod 能够以读写模式访问存储，适用于特定场景，如避免数据冲突或损坏。还更新了调度程序以支持与 ReadWriteOncePod 存储相关的 pod 抢占。
假设我们有一个需要对某个数据库进行写入操作的应用，并且我们希望确保在任何给定时间只有一个 Pod 能够对数据库进行写入，以避免数据冲突或损坏。在这种情况下，我们可以使用 KEP-2495 引入的 ReadWriteOncePod 访问模式。
场景描述：
1）ReadWriteOncePod 访问模式的 PV/PVC 配置：
# PersistentVolumeapiVersion: v1kind: PersistentVolumemetadata:name: database-pvspec:capacity:storage: 10GiaccessModes:ReadWriteOncePodpersistentVolumeReclaimPolicy: RetainstorageClassName: manualhostPath:path: "/data/database"# PersistentVolumeClaimapiVersion: v1kind: PersistentVolumeClaimmetadata:name: database-pvcspec:accessModes:ReadWriteOncePodresources:requests:: 5Gi
在这个例子中，我们定义了一个名为 database-pv 的 PersistentVolume，以及与之关联的名为 database-pvc 的 PersistentVolumeClaim。accessModes 被设置为 ReadWriteOncePod，以确保只有一个 Pod 能够以读写模式访问存储。
2）Pod 使用 ReadWriteOncePod 访问模式：
apiVersion: v1kind: Podmetadata:name: write-podspec:containers:- name: write-containerimage: my-database-writervolumeMounts:- mountPath: "/data/database"name: storage-volumevolumes:- name: storage-volumepersistentVolumeClaim:claimName: database-pvc
在这个例子中，我们有一个 Pod（write-pod），它引用了我们之前创建的 PersistentVolumeClaim database-pvc。这个 Pod 是唯一能够以读写模式访问数据库存储的实体。
3）调度程序更新和 Pod 抢占：
如果有另一个 Pod 尝试使用相同的 database-pvc 进行写入操作，调度程序将根据抢占规则，确保具有更高优先级的 Pod（例如紧急写入操作的 Pod）获得对存储卷的访问权限。这确保了在写入数据库时的一致性。
通过这个案例，我们可以看到 ReadWriteOncePod 访问模式如何确保在特定场景中只有一个 Pod 能够以读写模式访问存储，同时调度程序的更新确保了抢占的有效性，从而保持对存储的正确、一致性访问。
3. 认证
3.1 KEP-3299: KMS v2 增强（GA）
对 Kubernetes KMS（Key Management Service）进行了增强，将 KMSv2 特性升级为 GA。此功能关注改进 KMS 插件框架，确保 Kubernetes secret 的安全管理和加密仍然是强大而安全的。以下是一个案例演示，说明如何使用 KMSv2 进行 Secrets 加密和解密。
1） 创建 Secrets 对象：
首先，我们创建一个包含敏感信息的 Kubernetes Secrets 对象。假设我们有一个数据库密码需要存储：
apiVersion: v1kind: Secretmetadata:name: db-secrettype: Opaquedata:password: <base64-encoded-password>
确保 <base64-encoded-password> 是实际密码的 Base64 编码。
2）配置 KMSv2 插件：
在 Kubernetes 集群中，配置 KMSv2 插件，例如 Azure Key Vault 或 Google Cloud KMS。确保 KMS 插件已正确配置，并可以与 Kubernetes 集成。
3.）使用 KMSv2 对 Secrets 进行加密：
更新 Secrets 对象，将其配置为使用 KMSv2 进行加密。例如，使用 Annotations 来指定 KMSv2 插件和加密密钥的信息：
apiVersion: v1kind: Secretmetadata:name: db-secretannotations:kubernetes.io/secret-encryptor: "kms-v2://kms-plugin-name/kms-key-name"type: Opaquedata:password: <base64-encoded-password>
其中，kms-plugin-name 是实际的 KMS 插件名称，kms-key-name 是在 KMS 中配置的密钥名称。
4） 应用更新后的 Secrets 对象：
通过执行以下命令来应用更新后的 Secrets 对象：
kubectl apply -f updated-db-secret.yaml5） KMSv2 进行解密：
Kubernetes 将使用配置的 KMSv2 插件和密钥来对 Secrets 进行解密。在容器中，可以访问解密后的敏感信息。
通过这个案例，我们演示了如何使用 KMSv2 对 Kubernetes Secrets 进行加密和解密，以提高敏感信息的安全性。这确保了 Secrets 在存储和传输过程中得到了适当的保护。
4. 节点
4.1 KEP-753: 原生支持 Sidecar 容器 (Beta)
原生支持 Sidecar 容器升级至 Beta 版本，使 Kubelet 延迟发送 TERM 信号给 Sidecar 容器，以确保它们在主容器终止之前继续为其他容器提供服务。
5. Windows 支持
5.1 KEP-1287: Windows 支持 Pod 资源原地升级（Alpha）
Windows 支持了 Pod 资源原地升级，允许在不重新创建 Pod 或重新启动容器的情况下更改资源。
通过一个简单的案例演示如何使用这个功能：
1）创建 Windows Pod 资源定义：
首先，创建一个 Windows Pod 的资源定义文件，例如 windows-pod.yaml：
apiVersion: v1kind: Podmetadata:name: windows-podspec:containers:name: my-containerimage: microsoft/iis:latestresources:requests:memory: "128Mi"cpu: "250m"limits:memory: "256Mi": "500m"
这个示例中，我们创建了一个运行 IIS 的 Windows Pod，并定义了内存和CPU的资源请求和限制。
2）部署 Windows Pod：
通过以下命令部署 Windows Pod：
kubectl apply -f windows-pod.yaml3）检查 Windows Pod 状态：
使用以下命令检查 Pod 是否正常运行：
kubectl get pods4）执行资源原地升级：
现在，我们将使用 kubectl edit 命令来原地修改 Windows Pod 的资源，而不重新创建 Pod：
kubectl edit pod windows-pod编辑窗口将打开，你可以在规格（spec）部分修改资源请求和限制。例如，将内存请求从 "128Mi" 修改为 "256Mi"。
保存并关闭编辑器，Kubernetes 将自动更新 Pod 的资源配置。
5） 检查资源更新：
使用以下命令检查 Pod 是否成功更新：
kubectl describe pod windows-pod确保 Pod 的资源配置已成功更新。
通过这个案例，我们演示了如何在 Kubernetes 1.29 版本中利用 Alpha 版本的 Pod 资源原地升级功能，在不中断服务的情况下修改 Windows Pod 的资源配置。
6. 网络
6.1 KEP-1880: 动态扩展 Service 的可用 IP 范围（Alpha）
允许集群管理员动态调整分配给集群服务 IP 范围的大小，以处理 IP 耗尽或 IP 重新编号等问题。需要启用 MultiCIDRServiceAllocator 特性门控和 networking.k8s.io/v1alpha1 API。
7. 调度
7.1 KEP-3633: 引入 MatchLabelKeys/MismatchLabelKeys 到 Pod 亲和性和反亲和性（Alpha）
引入了 MatchLabelKeys/MismatchLabelKeys 功能，提高了计算 PodAffinity 和 PodAntiAffinity 的准确性。管理员可以在现有 LabelSelector 之上精细控制 PodAffinity 或 PodAntiAffinity 的范围。
7.2 KEP-4247: QueueingHint 为优化 Pod 调度带来新的可能（Beta）
QueueingHint 功能为优化重新排队效率提供了新的可能性，可以显著减少无用的调度重试。该功能已升级为 Beta，不面向用户而是面向开发者，可以使用 SchedulerQueueingHints 特性门控来决定是否禁用它。
8. 监控与仪表板
8.1 KEP-727: Kubelet 资源指标（GA）
Kubelet 现在使用 Prometheus 客户端库，在 /metrics/resource 公开端点提供 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）。
8.2 KEP-3466: Kubernetes 组件运行状况 SLIs（GA）
由 ComponentSLIs 特性门控控制并在 /metrics/slis 端点提供服务的指标现在已经升级为 GA。这些指标提供了组件的运行状况信息，例如 etcd、log、ping 等，以及总体的 kubernetes_healthchecks_total 计数器。
9. 存储
9.1 KEP-3107: NodeExpandSecret 添加到 CSI 持久卷源（GA）
NodeExpandSecret 功能在 v1.29 中移至 GA。此功能使 CSI 客户端能够将其作为 NodeExpandVolume 请求的一部分发送到 CSI 驱动程序，从而对持久卷进行扩展。
9.2 KEP-3751: VolumeAttributesClass（Alpha）
VolumeAttributesClass 功能在 v1.29 中引入，虽然处于 Alpha 阶段，但它为用户提供了在配置后更改持久卷属性的能力，例如 IOPS 或吞吐量。需要在 kube-apiserver、kube-controller-manager、external-provisioner 和 external-resizer 组件都启用 VolumeAttributesClass 特性门控才能使用此功能。
10. 节点
10.1 KEP-3077: kube-scheduler 已转换为上下文日志记录（Alpha）
上下文日志记录功能在 Kubernetes v1.24 中引入，现在已成功迁移到 kube-scheduler。此功能旨在提供更有用的日志以便于问题追踪和故障排除。要使用此功能，请启用 ContextualLogging 特性门控。
10.2 KEP-127: 启用 Pod 安全标准的用户命名空间支持 (Alpha)
增加了 UserNamespacesPodSecurityStandards 特性门控，以启用对 Pod 安全标准的用户命名空间支持。请注意，只有当集群中的所有节点都支持用户命名空间功能并启用它时，才应启用此特性门控。
10.3 KEP-4191: Kubelet 支持镜像文件系统被分割 (Alpha)
Kubelet 现在支持将镜像文件系统（Image Filesystem）分割，该功能在 v1.29 中作为 Alpha 版本引入。使用 KubeletSeparateDiskGC 特性门控可以控制是否启用此功能，默认情况下不启用。此功能允许将 Image Filesystem 分为可写层和只读层，可写层与 Kubelet 位于同一磁盘上，而镜像可以位于单独的文件系统上。
10.4 KEP-4210: 添加对 ImageMaximumGCAge 字段的支持 (Alpha)
添加了 ImageMaximumGCAge 字段到 Kubelet 配置中，允许用户设置镜像在被垃圾收集之前未使用的最长期限。此字段由特性门控 ImageMaximumGCAge 控制，目前为 Alpha，默认不启用。
11. 认证
11.1 KEP-4193: 绑定服务账号令牌增强 (Alpha)
Kubernetes v1.29 新增了 4 个特性门控来增强绑定服务账号令牌。ServiceAccountTokenJTI 特性门控支持在服务账户令牌中添加 JWT ID（jti）声明。ServiceAccountTokenPodNodeInfo 特性门控支持在服务账户令牌中添加节点名称和节点 UID 作为额外声明。ServiceAccountTokenNodeBinding 特性门控支持将令牌直接绑定到节点，并提供验证以确保节点名称和 UID 仍然存在。结合这些功能，可以增强服务账号令牌的安全性和灵活性。
结论
Kubernetes v1.29 引入了多个重要功能，涵盖了网络、存储、认证、节点、Windows 支持和调度、监控与仪表板等多个方面。管理员和开发者可以根据其需求和集群特性选择性地启用这些功能，以提高 Kubernetes 集群的性能、灵活性和安全性。使用这些新功能，用户可以更好地适应不同的工作负载和集群要求。
本周精彩文章推荐
作者微信：luckylucky421302
加微信，可以进学习交流群。
