Kubernetes 1.25 正式发布,新版本在各个领域提供了 40 项新增强功能和大量错误修复,本篇文章将带您快速了解新版本中每个SIG的突出变化,第一时间做到心中有数!
API Machinery有两个新的、闪亮的增强功能。
自定义资源是 Kubernetes 中用于在 Kubernetes API 中创建和管理新资源的关键扩展点。随着即将发布的版本,CRD validation using expression language 升级为beta。现在可以将验证规则添加到 CRD 模式并与资源规范一起管理它们,而不是部署和使用 webhook 进行验证。
Job resources是在 Kubernetes 中运行一次性任务的方式。然而,Kubernetes 中的作业 API 在故障处理方面很少。有了这个新的alpha 功能,作业规范中的 podFailurePolicy 中有一个新字段。您可以定义如下规则,一个来自Github/Kubernetes的带有故障策略的示例作业规范,并对容器的结果采取措施:
apiVersion: v1
kind: Job
spec:
template:
spec:
containers:
- name: main-job-container
image: job-image
command: ["./program"]
- name: monitoring-job-container
image: job-monitoring
command: ["./monitoring"]
backoffLimit: 3
podFailurePolicy:
rules:
- action: Terminate
onExitCodes:
containerName: main-job-container
operator: In
values: [1,2,3]
- action: Ignore
onPodConditions:
- type: DisruptionTarget
Apps SIG 专注于在 Kubernetes 中部署和管理复杂的应用程序。在 1.25 版本中,这方面有两个重要的增强功能。
minReadySeconds 是 StatefulSet 资源中一个新的但稳定的字段,以确保在 pod 可用后工作负载准备就绪。这些额外的缓冲秒数在容器启动时是有益的,但应用程序需要时间来准备接受请求。
CronJob 实例由资源规范中提供的计划创建。但是,新创建资源的时区取决于控制器管理器的运行位置。使用新的增强功能,您将获得一个新字段 spec.timeZone,您可以在其中使用tz 数据库中的有效时区。
在这里,我们有一个critical depreciation和一个来自授权、身份验证和集群安全策略领域的新 alpha 版本。
在 Kubernetes 1.25 中,PodSecurityPolicy在 1.21 版本贬值后被完全移除。PodSecurityPolicy 是定义 Pod 功能规则的解决方案,但随着时间的推移它变得复杂和混乱。相反,Kubernetes 现在已经实现了具有明确迁移路径的 Pod 安全准入控制器。
Kubernetes 将其所有数据存储在 etcd 中,默认情况下不加密。正因为如此,Kubernetes 提供了诸如密钥管理服务 (KMS) 提供者之类的外部机制,以将数据安全地存储在 etcd 中。新的 v2alpha1增强功能侧重于使 KMS 自动处理密钥轮换。此外,它还改进了 KMS 插件健康检查和 API 服务器与 KMS 之间操作的可观察性。
在即将发布的版本中有两个网络领域的毕业成果。
在入口和出口网络策略中,您需要使用当前的 Kubernetes API 来一一指定每个端口。新的(现已稳定)功能添加了一个名为 endPort 的字段以轻松声明端口范围。例如,您可以应用从端口 32000 到 32768 的规则,如下所示:
spec:
egress:
- ports:
- protocol: TCP
port: 32000
endPort: 32768
Kubernetes 服务资源暴露了集群内外的应用程序。有两种方法可以为服务资源选择 IP:Kubernetes 从配置的范围内分配一个随机 IP,或者用户静态指定同一范围内的 IP。您可以使用已升级为beta的 ServiceIPStaticSubrange 字段划分 IP 范围,并在 Kubernetes 中为服务分配 IP 地址时避免冲突。
在 1.25 版本中,节点区域有三个通用可用性 (GA) 等级,以及一个 beta 和一个 alpha 版本。
调试分布式架构系统总是具有挑战性,因为连接、发送请求和检查结果并不容易。使用临时容器,您可以将容器添加到正在运行的 pod。由于应用程序容器映像很小,没有任何 shell、curl 或调试工具,临时容器有利于快速旋转调试器容器。
例如,您可以使用以下命令将交互式临时busybox 映像附加到db-pod 并开始调试:
$ kubectl debug db-pod -it --image=busybox
Defaulting debug container name to debugger-8xzrl.
If you don't see a command prompt, try pressing enter.
/ #
cgroups 是在节点上组织和管理容器资源的关键 Linux 内核功能之一。在 Kubernetes 的早期,所有容器运行时都是使用 cgroup v1 构建的,但现在 cgroups v2 支持已经升级到普遍可用。使用 cgroups v2,容器工作负载将更安全地工作,包括无根容器,并且更可靠地使用最新的内核功能。
除了 pod 级别的 terminateGracePeriodSeconds 之外,还有一个新的(现在在 liveness probes 中稳定)字段称为 terminateGracePeriodSeconds。这些字段的分离有助于决定 Kubernetes 在正常关闭和活跃度探测失败的情况下将等待多长时间来kill一个容器。
Kubernetes 允许通过定义seccomp配置文件来提高容器安全性;自 1.22 版本以来,它一直是 alpha 功能。默认情况下启用 Seccomp 会添加一个安全层来防止 CVE 和 0-days,现在此功能已在 1.25 版本中 升级为beta 。
使用新的 CPU 架构,每个插槽的 NUMA(非统一内存访问)节点数量有所增加。新的alpha 功能添加了一个新的 CPUManager 策略选项作为 align-by-socket。这样,CPU 将被视为在socket boundaries而不是NUMA boundaries.处匹配。
1.25 版在安全领域有一个关键的增强。
Kubernetes 是最活跃的开源存储库之一,因此存在许多问题和 PR,与 CVE 相关,这些问题和 PR 是无法过滤的。新的alpha 功能可确保在自动化的帮助下标记问题和 PR。这种新方法将让您以最终用户、维护者或平台提供商的身份列出具有相关信息的 CVE。
您将从调度区域获得一个新的 alpha 版本。
PodTopologySpread是 pod API 的一部分,用于定义关于 pod 在集群中如何分布的约束,例如每个区域、区域、节点或任何其他用户定义的拓扑。例如,假设您有一个 20 个节点的集群和一个最少 2 个最多 15 个的自动扩展应用程序。当至少有 2 个实例正在运行时,您不希望它们都运行在同一个节点——或可用区。这些约束很有帮助,因为它们可以在集群出现故障的情况下提高可用性。在 1.25 版本中,Kubernetes 也将尊重滚动升级阶段的传播限制。存储
从存储区域来看,有两个基本的通用版本和一个 alpha 版本。
Pod 使用临时存储来写入它们的日志和 emptyDir 挂载并作为缓存。在没有任何隔离的情况下,节点上的每个 pod 都在“尽力而为”的基础上共享同一个临时存储池。换句话说,pod 不知道为它们分配了多少空间或在节点上留下了多少空间。借助将在即将发布的版本中普遍提供的存储容量隔离功能,Pod 可以从临时池中保留自己的存储。
将 in-tree 插件迁移到外部 CSI 插件在 1.25 版本中逐渐稳定。这是一个重要的步骤,其中包括许多卷插件的删除和折旧:
默认存储类主要由集群管理员在集群创建期间配置。但是,当底层存储提供者或业务需求发生变化时,您还应该更改集群中的默认存储类。新的alpha 功能侧重于将 Kubernetes 行为更改为对没有任何存储类的 PVC 具有追溯性。
Kubernetes 1.25 旨在让 Kubernetes 更加安全、可靠和灵活。确保您已为发布中的最新更改做好准备,并及时升级您的基础架构,可以查看Kubernetes 博客和发行说明,了解有关增强功能和最新更改的更多信息。
原文链接:https://medium.com/@jonathan_37674/kubernetes-version-1-25-everything-you-should-know-92fc1e02b5bd