Kubernetes 1.29 发布：新增特性一览

最新推荐文章于 2024-04-24 14:23:19 发布

韩先超

最新推荐文章于 2024-04-24 14:23:19 发布

阅读量1.1k

点赞数 16

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/weixin_38320674/article/details/135281391

版权

▲ 点击上方"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/v1beta3
kind: ClusterConfiguration
featureGates:
NFTablesProxyMode: true

步骤 2: 更新 kube-proxy 启动参数

确保 kube-proxy 启动时使用了 --proxy-mode=nftables 参数。可以通过修改 kube-proxy 的启动参数或配置文件来实现。以下是 kube-proxy 的简化配置文件示例：

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
scheduler: rr
nftables:
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 配置：

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
name: database-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOncePod
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: "/data/database"


# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: database-pvc
spec:
accessModes:
- ReadWriteOncePod
resources:
requests:
      storage: 5Gi

在这个例子中，我们定义了一个名为 database-pv 的 PersistentVolume，以及与之关联的名为 database-pvc 的 PersistentVolumeClaim。accessModes 被设置为 ReadWriteOncePod，以确保只有一个 Pod 能够以读写模式访问存储。

2）Pod 使用 ReadWriteOncePod 访问模式：

apiVersion: v1
kind: Pod
metadata:
name: write-pod
spec:
containers:
- name: write-container
image: my-database-writer
volumeMounts:
- mountPath: "/data/database"
name: storage-volume
volumes:
- name: storage-volume
persistentVolumeClaim:
      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: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
data:
  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: v1
kind: Secret
metadata:
name: db-secret
annotations:
kubernetes.io/secret-encryptor: "kms-v2://kms-plugin-name/kms-key-name"
type: Opaque
data:
  password: <base64-encoded-password>

其中，kms-plugin-name 是实际的 KMS 插件名称，kms-key-name 是在 KMS 中配置的密钥名称。

4）应用更新后的 Secrets 对象：

通过执行以下命令来应用更新后的 Secrets 对象：

kubectl apply -f updated-db-secret.yaml

5） 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: v1
kind: Pod
metadata:
  name: windows-pod
spec:
  containers:
  - name: my-container
    image: microsoft/iis:latest
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

这个示例中，我们创建了一个运行 IIS 的 Windows Pod，并定义了内存和CPU的资源请求和限制。

2）部署 Windows Pod：

通过以下命令部署 Windows Pod：

kubectl apply -f windows-pod.yaml

3）检查 Windows Pod 状态：

使用以下命令检查 Pod 是否正常运行：

kubectl get pods

4）执行资源原地升级：

现在，我们将使用 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 集群的性能、灵活性和安全性。使用这些新功能，用户可以更好地适应不同的工作负载和集群要求。

参考：https://kubernetes.io/zh-cn/blog/2023/11/16/kubernetes-1-29-upcoming-changes/

本周精彩文章推荐

年底了，总结下这一年，收获满满

K8S网站被10T流量攻击，1秒钟内就快速处理

基于k8s的devOps自动化运维平台架构设计（中英文版本）

基于k8s的大型在线购物网站设计与自动扩缩容实现

Kubernetes最佳实战案例：优化容器化部署与扩展性

现代化战机之路：美国空军U-2侦察机基于Jenkins和k8s的CI/CD架构演进

干掉99%传统运维：基于Jenkins和K8S构建DevOps流水线

合肥电信/Kubernetes技术培训

安全实践：保障 Kubernetes 生产环境的安全性

作者微信：luckylucky421302

加微信，可以进学习交流群。

点亮收藏，服务器10年不宕机

韩先超

关注

16
点赞
踩
21

收藏

觉得还不错? 一键收藏
打赏
0
评论
Kubernetes 1.29 发布：新增特性一览

▲点击上方"DevOps和k8s全栈技术"关注公众号Kubernetes 1.29已正式发布，距离上一个版本发布已过去4个月，是2023年的第三个版本，也是今年的最后一个版本。在这个新版本中，Release团队跟踪了49个增强功能。其中，11个功能已升级为稳定版，19个现有功能进行了优化并升级为Beta版本，同时还引入了多达19个全新的Alpha级别功能。1.29版本包含了许多重要功能和用户体验...
复制链接

扫一扫