Kubernetes Blog

Kubernetes 1.29: 解耦污点管理器与节点生命周期控制器

Tue, 19 Dec 2023 00:00:00 +0000

作者: Yuan Chen (Apple), Andrea Tosatto (Apple)

译者: Allen Zhang

这篇博客讨论在 Kubernetes 1.29 中基于污点的 Pod 驱逐处理的新特性。

背景

在 Kubernetes 1.29 中引入了一项改进，以加强节点上基于污点的 Pod 驱逐处理。本文将讨论对节点生命周期控制器（node-lifecycle-controller）所做的更改，以分离职责并提高代码的整体可维护性。

变动摘要

节点生命周期控制器之前组合了两个独立的功能：

基于节点的条件为节点新增了一组预定义的污点 NoExecute。
对有 NoExecute 污点的 Pod 执行驱逐操作。

在 Kubernetes 1.29 版本中，基于污点的驱逐实现已经从节点生命周期控制器中移出，成为一个名为污点驱逐控制器（taint-eviction-controller）的独立组件。旨在拆分代码，提高代码的可维护性，并方便未来对这两个组件进行扩展。

以下新指标可以帮助你监控基于污点的 Pod 驱逐：

pod_deletion_duration_seconds 表示当 Pod 的污点被激活直到这个 Pod 被污点驱逐控制器删除的延迟时间。
pod_deletions_total 表示自从污点驱逐控制器启动以来驱逐的 Pod 总数。

如何使用这个新特性？

名为 SeparateTaintEvictionController 的特性门控已被添加。该特性在 Kubernetes 1.29 Beta 版本中默认开启。详情请参阅特性门控。

当这项特性启用时，用户可以通过在 kube-controller-manager 通过手动设置 --controllers=-taint-eviction-controller 的方式来禁用基于污点的驱逐功能。

如果想禁用该特性并在节点生命周期中使用旧版本污点管理器，用户可以通过设置 SeparateTaintEvictionController=false 来禁用。

使用案例

该特性将允许集群管理员扩展、增强默认的污点驱逐控制器，并且可以使用自定义的实现方式替换默认的污点驱逐控制器以满足不同的需要。例如：更好地支持在本地磁盘的持久卷中的有状态工作负载。

FAQ

该特性是否会改变现有的基于污点的 Pod 驱逐行为？

不会，基于污点的 Pod 驱逐行为保持不变。如果特性门控 SeparateTaintEvictionController 被关闭，将继续使用之前的节点生命周期管理器中的污点管理器。

启用/使用此特性是否会导致现有 SLI/SLO 中任何操作的用时增加？

不会。

启用/使用此特性是否会导致资源利用量（如 CPU、内存、磁盘、IO 等）的增加？

运行单独的 taint-eviction-controller 所增加的资源利用量可以忽略不计。

了解更多

更多细节请参考 KEP。

特别鸣谢

与任何 Kubernetes 特性一样，从撰写 KEP 到实现新控制器再到审核 KEP 和代码，多名社区成员都做出了贡献，特别感谢：

Aldo Culquicondor (@alculquicondor)
Maciej Szulik (@soltysh)
Filip Křepinský (@atiratree)
Han Kang (@logicalhan)
Wei Huang (@Huang-Wei)
Sergey Kanzhelevi (@SergeyKanzhelev)
Ravi Gudimetla (@ravisantoshgudimetla)
Deep Debroy (@ddebroy)

Kubernetes 1.29：PodReadyToStartContainers 状况进阶至 Beta

Tue, 19 Dec 2023 00:00:00 +0000

作者：Zefeng Chen (independent), Kevin Hannon (Red Hat)

译者：Michael Yao

随着最近发布的 Kubernetes 1.29，PodReadyToStartContainers 状况默认可用。 kubelet 在 Pod 的整个生命周期中管理该状况的值，将其存储在 Pod 的状态字段中。 kubelet 将通过容器运行时从 Pod 沙箱创建和网络配置的角度使用 PodReadyToStartContainers 状况准确地展示 Pod 的初始化状态，

这个特性的动机是什么？

集群管理员以前没有明确且轻松访问的方式来查看 Pod 沙箱创建和初始化的完成情况。从 1.28 版本开始，Pod 中的 Initialized 状况跟踪 Init 容器的执行情况。然而，它在准确反映沙箱创建完成和容器准备启动的方面存在一些限制，无法适用于集群中的所有 Pod。在多租户集群中，这种区别尤为重要，租户拥有包括 Init 容器集合在内的 Pod 规约，而集群管理员管理存储插件、网络插件和容器运行时处理程序。因此，需要改进这个机制，以便为集群管理员提供清晰和全面的 Pod 沙箱创建完成和容器就绪状态的视图。

这个特性有什么好处？

改进可见性：集群管理员可以更清晰和全面地查看 Pod 沙箱的创建完成和容器的就绪状态。这种增强的可见性使他们能够做出更明智的决策，并更有效地解决问题。

指标收集和监控：监控服务可以利用与 PodReadyToStartContainers 状况相关的字段来报告沙箱创建状态和延迟。可以按照每个 Pod 的基数进行指标收集，或者根据 Pod 的各种属性进行聚合，例如 volumes、runtimeClassName、CNI 和 IPAM 插件的自定义注解，以及任意标签和注解，以及 PersistentVolumeClaims 的 storageClassName。这样可以全面监控和分析集群中 Pod 的就绪状态。

增强故障排查能力：通过更准确地表示 Pod 沙箱的创建和容器的就绪状态，集群管理员可以快速识别和解决初始化过程中可能出现的任何问题。这将提高故障排查能力，并减少停机时间。

后续事项

鉴于反馈和采用情况，Kubernetes 团队在 1.29 版本中将 PodReadyToStartContainersCondition 进阶至 Beta版。你的评论将有助于确定该状况是否继续并晋升至 GA，请针对此特性提交更多反馈！

如何了解更多？

请查看关于 PodReadyToStartContainersCondition 的文档，以了解其更多信息及其与其他 Pod 状况的关系。

如何参与？

该特性由 SIG Node 社区推动。请加入我们，与社区建立联系，分享你对这一特性及更多内容的想法和反馈。我们期待倾听你的建议！

Kubernetes 1.29 新的 Alpha 特性：Service 的负载均衡器 IP 模式

Mon, 18 Dec 2023 00:00:00 +0000

作者： Aohan Yang

译者： Allen Zhang

本文介绍 Kubernetes 1.29 中一个新的 Alpha 特性。此特性提供了一种可配置的方式用于定义 Service 的实现方式，本文中以 kube-proxy 为例介绍如何处理集群内从 Pod 到 Service 的流量。

背景

在 Kubernetes 早期版本中，kube-proxy 会拦截指向 type: LoadBalancer Service 关联 IP 地址的流量。这与你为 kube-proxy 所使用的哪种模式无关。

这种拦截实现了预期行为（流量最终会抵达服务后挂载的端点）。这种机制取决于 kube-proxy 的模式，在 Linux 中，运行于 iptables 模式下的 kube-proxy 会重定向数据包到后端端点；在 ipvs 模式下， kube-proxy 会将负载均衡器的 IP 地址配置到节点的一个网络接口上。采用这种拦截有两个原因：

流量路径优化： 高效地重定向 Pod 流量 - 当 Pod 中的容器发送指向负载均衡器 IP 地址的出站包时，会绕过负载均衡器直接重定向到后端服务。

处理负载均衡数据包： 有些负载均衡器发送的数据包设置目标 IP 为负载均衡器的 IP 地址。因此，这些数据包需要被直接路由到正确的后端（可能不在该节点本地），以避免回环。

问题

然而，上述行为存在几个问题：

源 IP（Source IP）： 一些云厂商在传输数据包到节点时使用负载均衡器的 IP 地址作为源 IP。在 kube-proxy 的 ipvs 模式下，存在负载均衡器健康检查永远不会返回的问题。原因是回复的数据包被转发到本地网络接口 kube-ipvs0（绑定负载均衡器 IP 的接口）上并被忽略。

负载均衡器层功能缺失： 某些云厂商在负载均衡器层提供了部分特性（例如 TLS 终结、协议代理等）。绕过负载均衡器会导致当数据包抵达后端服务时这些特性不会生效（导致协议错误等）。

即使新的 Alpha 特性默认关闭，也有临时解决方案，即为 Service 设置 .status.loadBalancer.ingress.hostname 以绕过 kube-proxy 绑定。但这终究只是临时解决方案。

解决方案

总之，为云厂商提供选项以禁用当前这种行为大有裨益。

Kubernetes 1.29 版本为 Service 引入新的 Alpha 字段 .status.loadBalancer.ingress.ipMode 以解决上述问题。该字段指定负载均衡器 IP 的运行方式，并且只有在指定 .status.loadBalancer.ingress.ip 字段时才能指定。

.status.loadBalancer.ingress.ipMode 可选值为："VIP" 和 "Proxy"。默认值为 VIP，即目标 IP 设置为负载均衡 IP 和端口并发送到节点的流量会被 kube-proxy 重定向到后端服务。这种方式保持 kube-proxy 现有行为模式。Proxy 用于阻止 kube-proxy 在 ipvs 和 iptables 模式下绑定负载均衡 IP 地址到节点。此时，流量会直达负载均衡器然后被重定向到目标节点。转发数据包的目的值配置取决于云厂商的负载均衡器如何传输流量。

如果流量被发送到节点然后通过目标地址转换（DNAT）的方式到达 Pod，目的地应当设置为节点和 IP 和端口；
如果流量被直接转发到 Pod，目的地应当被设置为 Pod 的 IP 和端口。

用法

开启该特性的必要步骤：

下载 Kubernetes 最新版本（v1.29.0 或更新）。
通过命令行参数 --feature-gates=LoadBalancerIPMode=true 在 kube-proxy、kube-apiserver 和 cloud-controller-manager 开启特性门控。
对于 type: LoadBalancer 类型的 Service，将 ipMode 设置为合适的值。这一步可能由你在 EnsureLoadBalancer 过程中选择的 cloud-controller-manager 进行处理。

联系我们

通过 Slack 频道 #sig-network, 或者通过邮件列表联系我们。

特别鸣谢

非常感谢 @Sh4d1 的原始提案和最初代码实现。我中途接手并完成了这项工作。同样我们也向其他帮助设计、实现、审查特性代码的贡献者表示感谢（按首字母顺序排列）：

Kubernetes 1.29：修改卷之 VolumeAttributesClass

Fri, 15 Dec 2023 00:00:00 +0000

作者：Sunny Song (Google)

译者：Baofa Fan (DaoCloud)

Kubernetes v1.29 版本引入了一个 Alpha 功能，支持通过变更 PersistentVolumeClaim（PVC）的 volumeAttributesClassName 字段来修改卷。启用该功能后，Kubernetes 可以处理除容量以外的卷属性的更新。允许更改卷属性，而无需通过不同提供商的 API 对其进行管理，这直接简化了当前流程。

你可以在 Kubernetes 文档中，阅读有关 VolumeAttributesClass 的详细使用信息，或者继续阅读了解 Kubernetes 项目为什么支持此功能。

VolumeAttributesClass

新的 storage.k8s.io/v1alpha1 API 组提供了两种新类型：

VolumeAttributesClass

表示由 CSI 驱动程序定义的可变卷属性的规约。你可以在 PersistentVolumeClaim 动态制备时指定它，并且允许在制备完成后在 PersistentVolumeClaim 规约中进行更改。

ModifyVolumeStatus

表示 ControllerModifyVolume 操作的状态对象。

启用此 Alpha 功能后，PersistentVolumeClaim 的 spec.VolumeAttributesClassName 字段指明了在 PVC 中使用的 VolumeAttributesClass。在制备卷时，CreateVolume 操作将应用 VolumeAttributesClass 中的参数以及 StorageClass 中的参数。

当 PVC 的 spec.VolumeAttributesClassName 发生变化时，external-resizer sidecar 将会收到一个 informer 事件。基于当前的配置状态，resizer 将触发 CSI ControllerModifyVolume。更多细节可以在 KEP-3751 中找到。

如何使用它

如果你想在 Alpha 版本中测试该功能，需要在 kube-controller-manager 和 kube-apiserver 中启用相关的特性门控。使用 --feature-gates 命令行参数：

--feature-gates="...,VolumeAttributesClass=true"

它还需要 CSI 驱动程序实现 ModifyVolume API。

用户流程

如果你想看到该功能的运行情况，并验证它在你的集群中是否正常工作，可以尝试以下操作：

定义 StorageClass 和 VolumeAttributesClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-sc-example
provisioner: pd.csi.storage.gke.io
parameters:
  disk-type: "hyperdisk-balanced"
volumeBindingMode: WaitForFirstConsumer

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
  name: silver
driverName: pd.csi.storage.gke.io
parameters:
  provisioned-iops: "3000"
  provisioned-throughput: "50"

定义并创建 PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
spec:
  storageClassName: csi-sc-example
  volumeAttributesClassName: silver
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 64Gi

验证 PersistentVolumeClaim 是否已正确制备：
```
kubectl get pvc
```

创建一个新的名为 gold 的 VolumeAttributesClass：

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
  name: gold
driverName: pd.csi.storage.gke.io
parameters:
  iops: "4000"
  throughput: "60"

使用新的 VolumeAttributesClass 更新 PVC 并应用：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
spec:
  storageClassName: csi-sc-example
  volumeAttributesClassName: gold
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 64Gi

验证 PersistentVolumeClaims 是否具有更新的 VolumeAttributesClass 参数：
```
kubectl describe pvc <PVC_NAME>
```

后续步骤

有关设计的更多信息，请参阅 VolumeAttributesClass KEP
你可以在项目看板上查看或评论 VolumeAttributesClass
为了将此功能推向 Beta 版本，我们需要社区的反馈，因此这里有一个行动倡议：为 CSI 驱动程序添加支持，尝试此功能，考虑它如何帮助解决你的用户遇到的问题...

参与其中

我们始终欢迎新的贡献者。因此，如果你想参与其中，可以加入我们的 Kubernetes 存储特别兴趣小组 (SIG)。

如果你想分享反馈意见，可以在我们的公共 Slack 频道上留言。

特别感谢所有为此功能提供了很好的评论、分享了宝贵见解并帮助实现此功能的贡献者（按字母顺序）：

Baofa Fan (calory)
Ben Swartzlander (bswartz)
Connor Catlett (ConnorJC3)
Hemant Kumar (gnufied)
Jan Šafránek (jsafrane)
Joe Betz (jpbetz)
Jordan Liggitt (liggitt)
Matthew Cary (mattcary)
Michelle Au (msau42)
Xing Yang (xing-yang)

聚焦 SIG Testing

Fri, 24 Nov 2023 00:00:00 +0000

作者: Sandipan Panda

译者: Michael Yao

欢迎阅读又一期的 “SIG 聚光灯” 系列博客，这些博客重点介绍 Kubernetes 项目中各个特别兴趣小组（SIG）所从事的令人赞叹的工作。这篇博客将聚焦 SIG Testing，这是一个致力于有效测试 Kubernetes，让此项目的繁琐工作实现自动化的兴趣小组。 SIG Testing 专注于创建和运行工具和基础设施，使社区更容易编写和运行测试，并对测试结果做贡献、分析和处理。

为了深入了解 SIG Testing 的情况， Sandipan Panda 采访了 Google 高级软件工程师兼 SIG Testing 主席 Michelle Shepardson 以及英特尔软件工程师、架构师兼 SIG Testing 技术负责人 Patrick Ohly。

会见贡献者

Sandipan: 你能简单介绍一下自己吗，谈谈你的职责角色以及你是如何参与 Kubernetes 项目和 SIG Testing 的？

Michelle: 嗨！我是 Michelle，是 Google 高级软件工程师。我最初是为 SIG Testing 开发工具（如 TestGrid 的外部实例）而参与到 Kubernetes 项目的。我是 TestGrid 和 Prow 的轮值人员，现在也是这个 SIG 的主席。

Patrick: 你好！我在英特尔的一个团队中担任软件工程师和架构师，专注于开源云原生项目。当我开始学习 Kubernetes 开发存储驱动时，我最初的问题是“如何在集群中进行测试以及如何记录信息？” 这个兴趣点引发了各种增强提案，直到我（重新）编写了足够多的代码，也正式担任了 SIG Testing 技术负责人（负责 E2E 框架）兼结构化日志工作组负责人。

测试实践和工具

Sandipan: 测试是一个存在多种方法和工具的领域，你们是如何形成现有实践方式的？

Patrick: 我没法谈论早期情况，因为那时我还未参与其中 😆，但回顾一些提交历史可以明显看出，当时开发人员只是看看有什么可用的工具并开始使用这些工具。对于 E2E 测试来说，使用的是 Ginkgo + Gomega。集成一些黑科技是必要的，例如在测试运行后进行清理和对测试进行分类。最终形成了 Ginkgo v2 和重新修订的 E2E 测试最佳实践。关于单元测试，意见非常多样化：一些维护者倾向于只使用 Go 标准库和手动检查。而其他人使用 stretchr/testify 这类辅助工具包。这种多样性是可以接受的，因为单元测试是自包含的：贡献者只需在处理许多不同领域时保持灵活。集成测试介于二者之间，它基于 Go 单元测试，但需要复杂的辅助工具包来启动 API 服务器和其他组件，然后运行更像是 E2E 测试的测试。

SIG Testing 拥有的子项目

Sandipan: SIG Testing 非常多样化。你能简要介绍一下 SIG Testing 拥有的各个子项目吗？

Michelle: 广义上来说，我们拥有与测试框架相关的子项目和基础设施，尽管它们肯定存在重叠。我们的子项目包括：

e2e-framework（外部使用）
test/e2e/framework （用于 Kubernetes 本身）
kubetest2（用于端到端测试）
boskos（用于 e2e 测试的资源租赁）
KIND（在 Docker 中运行 Kubernetes，用于本地测试和开发）
以及 KIND 的云驱动。

我们的基础设施包括：

Prow（基于 K8s 的 CI/CD 和 chatops）
test-infra 仓库中用于分类、分析、覆盖率、Prow/TestGrid 配置生成等的其他工具和实用程序。

如果你有兴趣了解更多并参与到 SIG Testing 的任何子项目中，查阅 SIG Testing 的 README。

主要挑战和成就

Sandipan: 你们面临的一些主要挑战是什么？

Michelle: Kubernetes 从贡献者到代码再到用户等各方面看都是一个庞大的项目。测试和基础设施必须满足这种规模，跟上 Kubernetes 每个仓库的所有变化，同时尽可能地促进开发、改进和发布项目，尽管当然我们并不是唯一参与其中的 SIG。我认为另一个挑战是子项目的人员配置。SIG Testing 有一些已经存在多年的子项目，但其中许多最初的维护者已经转到其他领域或者没有时间继续维护它们。我们需要在这些子项目中培养长期的专业知识和 Owner。

Patrick: 正如 Michelle 所说，规模本身可能就是一个挑战。不仅基础设施要与之匹配，我们的流程也必须与贡献者数量相匹配。记录最佳实践是好的，但还不够好：我们有许多新的贡献者，这是好事，但是让 Reviewer 靠人工解释最佳实践并不可行，这前提是 Reviewer 了解这些最佳实践！如果现有代码不能被立即更新也无济于事，因为代码实在太多了，特别是对于 E2E 测试来说更是如此。在接受现有代码无法通过同样的 linter 检查的同时，为新代码或代码修改应用更严格的 lint 检查对于改善情况会有所帮助。

Sandipan: 有没有一些 SIG 成就使你感到自豪，想要重点说一下？

Patrick: 我有一些拙见，因为我一直在推动这个项目，但我认为现在 E2E 框架和 lint 机制比以前好得多。我们可能很快就能在启用竞争检测的情况下运行集成测试，这很重要，因为目前我们只能对单元测试进行竞争检测，而那些往往不太复杂。

Sandipan: 测试始终很重要，但在 Kubernetes 发布过程中，你的工作是否有任何特殊之处？

Patrick: 测试不稳定…… 如果我们有太多这样的不稳定测试，开发速度就会下降，因为我们无法在没有干净测试运行环境的情况下合并 PR，并且这些环境会越来越少。开发者也会失去对测试的信任，只是“重新测试”直到有了一个干净的运行环境为止，而不会检查失败是否确实与当前更改中的回归有关。

人员和范围

Sandipan: 这个 SIG 中有哪些让你热爱的？

Michelle: 当然是人 🙂。除此之外，我喜欢 SIG Testing 的宽广范围。我觉得即使是小的改动也可以对其他贡献者产生重大影响，即使随着时间的推移我的兴趣发生变化，我也永远不会缺少项目可供我参与。

Patrick: 我的工作是为了让我和其他开发人员的工作变得更好，比如建设在其他地方开发新特性时每天必须使用的工具。

Sandipan: 你们有没有任何好玩/酷炫/日常趣事可以告诉我们？

Patrick: 五年前，我开始致力于 E2E 框架的增强，然后在一段时间内参与活动较少。当我回来并想要测试一些新的增强功能时，我询问如何为新代码编写单元测试，并被指向了一些看起来有些熟悉的、好像以前见过的现有测试。我查看了提交历史，发现这些测试是我自己编写的！你可以决定这是否说明了我的长期记忆力衰退还是这很正常... 无论如何，伙计们，要谨记让每个 Commit 的消息和注释明确、友好；某一刻会有人需要看这些消息和注释 - 甚至可能就是你自己！

展望未来

Sandipan: 在哪些领域和/或子项目上，你们的 SIG 需要帮助？

Michelle: 目前有一些子项目没有人员配置，需要有意愿了解更多的人参与进来。 boskos 和 kubetest2 对我来说尤其突出，因为它们对于测试非常重要，但却缺乏专门的负责人。

Sandipan: 新的 SIG Testing 贡献者可以带来哪些有用的技能？如果他们的背景与编程没有直接关联，有哪些方面可以帮助到这个 SIG？

Michelle: 我认为具备用户共情、清晰反馈和识别模式的能力非常有用。有人使用测试框架或工具，并能用清晰的示例概述痛点，或者能够识别项目中的更广泛的问题并提供数据来支持解决方案。

Sandipan: SIG Testing 的下一步是什么？

Patrick: 对于新代码，更严格的 lint 检查很快将成为强制要求。如果有人愿意承担这项工作，我们可以对一些 E2E 框架的子工具包进行现代化改造。我还看到一个机会，可以统一一些 E2E 和集成测试的辅助代码，但这需要更多的思考和讨论。

Michelle: 我期待为我们的工具和基础设施进行一些可用性改进，并支持更多长期贡献者的贡献和成长，使他们在 SIG 中担任长期角色。如果你有兴趣，请联系我们！

展望未来，SIG Testing 有令人兴奋的计划。你可以通过他们的 Slack 频道与 SIG Testing 的人员取得联系，或参加他们定期举行的每两周的周二会议。如果你有兴趣为社区更轻松地运行测试并贡献测试结果，确保 Kubernetes 在各种集群配置和云驱动中保持稳定，请立即加入 SIG Testing 社区！

Kubernetes 1.29 中的移除、弃用和主要变更

Thu, 16 Nov 2023 00:00:00 +0000

作者: Carol Valencia, Kristin Martin, Abigail McCarthy, James Quigley, Hosam Kamel

译者: Michael Yao (DaoCloud)

和其他每次发布一样，Kubernetes v1.29 将弃用和移除一些特性。一贯以来生成高质量发布版本的能力是开发周期稳健和社区健康的证明。下文列举即将发布的 Kubernetes 1.29 中的一些弃用和移除事项。

Kubernetes API 移除和弃用流程

Kubernetes 项目对特性有一个文档完备的弃用策略。此策略规定，只有当同一 API 有了较新的、稳定的版本可用时，原有的稳定 API 才可以被弃用，各个不同稳定级别的 API 都有一个最短的生命周期。弃用的 API 指的是已标记为将在后续某个 Kubernetes 发行版本中被移除的 API；移除之前该 API 将继续发挥作用（从被弃用起至少一年时间），但使用时会显示一条警告。被移除的 API 将在当前版本中不再可用，此时你必须转为使用替代的 API。

正式发布（GA）或稳定的 API 版本可能被标记为已弃用，但只有在 Kubernetes 主版本变化时才会被移除。
测试版（Beta）或预发布 API 版本在弃用后必须在后续 3 个版本中继续支持。
Alpha 或实验性 API 版本可以在任何版本中被移除，不另行通知。

无论一个 API 是因为某特性从 Beta 进阶至稳定阶段而被移除，还是因为该 API 根本没有成功，所有移除均遵从上述弃用策略。无论何时移除一个 API，文档中都会列出迁移选项。

k8s.gcr.io 重定向到 registry.k8s.io 相关说明

Kubernetes 项目为了托管其容器镜像，使用社区自治的一个名为 registry.k8s.io 的镜像仓库。从最近的 3 月份起，所有流向 k8s.gcr.io 旧仓库的请求开始被重定向到 registry.k8s.io。已弃用的 k8s.gcr.io 仓库最终将被淘汰。有关这一变更的细节或若想查看你是否受到影响，参阅 k8s.gcr.io 重定向到 registry.k8s.io - 用户须知。

Kubernetes 社区自治软件包仓库相关说明

在 2023 年年初，Kubernetes 项目引入了 pkgs.k8s.io, 这是 Debian 和 RPM 软件包所用的社区自治软件包仓库。这些社区自治的软件包仓库取代了先前由 Google 管理的仓库（apt.kubernetes.io 和 yum.kubernetes.io）。在 2023 年 9 月 13 日，这些老旧的仓库被正式弃用，其内容被冻结。

有关这一变更的细节或你若想查看是否受到影响，请参阅弃用公告。

Kubernetes v1.29 的弃用和移除说明

有关 Kubernetes v1.29 计划弃用的完整列表，参见官方 API 移除列表。

移除与云驱动的内部集成（KEP-2395）

对于 Kubernetes v1.29，默认特性门控 DisableCloudProviders 和 DisableKubeletCloudCredentialProviders 都将被设置为 true。这个变更将要求当前正在使用内部云驱动集成（Azure、GCE 或 vSphere）的用户启用外部云控制器管理器，或者将关联的特性门控设置为 false 以选择传统的集成方式。

启用外部云控制器管理器意味着你必须在集群的控制平面中运行一个合适的云控制器管理器；同时还需要为 kubelet（在每个相关节点上）及整个控制平面（kube-apiserver 和 kube-controller-manager）设置命令行参数 --cloud-provider=external。

有关如何启用和运行外部云控制器管理器的细节，参阅管理云控制器管理器和迁移多副本的控制面以使用云控制器管理器。

有关云控制器管理器的常规信息，请参阅 Kubernetes 文档中的云控制器管理器。

移除 `v1beta2` 流量控制 API 组

在 Kubernetes v1.29 中，将不再提供 FlowSchema 和 PriorityLevelConfiguration 的 flowcontrol.apiserver.k8s.io/v1beta2 API 版本。

为了做好准备，你可以编辑现有的清单（Manifest）并重写客户端软件，以使用自 v1.26 起可用的 flowcontrol.apiserver.k8s.io/v1beta3 API 版本。所有现有的持久化对象都可以通过新的 API 访问。 flowcontrol.apiserver.k8s.io/v1beta3 中的显著变化包括将 PriorityLevelConfiguration 的 spec.limited.assuredConcurrencyShares 字段更名为 spec.limited.nominalConcurrencyShares。

弃用针对 Node 的 `status.nodeInfo.kubeProxyVersion` 字段

在 v1.29 中，针对 Node 对象的 .status.kubeProxyVersion 字段将被标记为弃用，准备在未来某个发行版本中移除。这是因为此字段并不准确，它由 kubelet 设置，而 kubelet 实际上并不知道 kube-proxy 版本，甚至不知道 kube-proxy 是否在运行。

了解更多

弃用信息是在 Kubernetes 发布说明（Release Notes）中公布的。你可以在以下版本的发布说明中看到待弃用的公告：

我们将在 Kubernetes v1.29 的 CHANGELOG 中正式宣布与该版本相关的弃用信息。

有关弃用和移除流程的细节，参阅 Kubernetes 官方弃用策略文档。

介绍 SIG etcd

Tue, 07 Nov 2023 00:00:00 +0000

作者：Han Kang (Google), Marek Siarkowicz (Google), Frederico Muñoz (SAS Institute)

译者：Xin Li (Daocloud)

特殊兴趣小组（SIG）是 Kubernetes 项目的基本组成部分，很大一部分的 Kubernetes 社区活动都在其中进行。当有需要时，可以创建新的 SIG，而这正是最近发生的事情。

SIG etcd 是 Kubernetes SIG 列表中的最新成员。在这篇文章中，我们将更好地认识它，了解它的起源、职责和计划。

etcd 的关键作用

如果我们查看 Kubernetes 集群的控制平面内部，我们会发现 etcd，一个一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库 -- 仅此描述就突出了 etcd 所扮演的关键角色，以及它在 Kubernetes 生态系统中的重要性。

由于 etcd 在生态中的关键作用，其项目和社区的健康成为了一个重要的考虑因素，并且人们 2022 年初对项目状态的担忧并没有被忽视。维护团队的变化以及其他因素导致了一些情况需要被解决。

为什么要设立特殊兴趣小组

考虑到 etcd 的关键作用，有人提出未来的方向是创建一个新的特殊兴趣小组。如果 etcd 已经成为 Kubernetes 的核心，创建专门的 SIG 不仅是对这一角色的认可，还会使 etcd 成为 Kubernetes 社区的一等公民。

SIG etcd 的成立为明确 etcd 和 Kubernetes API 机制之间的契约关系创造了一个专门的空间，并防止在 etcd 级别上发生违反此契约的更改。此外，etcd 将能够采用 Kubernetes 提供的 SIG 流程（KEP、 PRR、分阶段特性门控以及其他流程）以提高代码库的一致性和可靠性，这将为 etcd 社区带来巨大的好处。

作为 SIG，etcd 还能够从 Kubernetes 获得贡献者的支持：Kubernetes 维护者对 etcd 的积极贡献将通过增加潜在审核者数量以及与现有测试框架的集成来降低破坏 Kubernetes 更改的可能性。这不仅有利于 Kubernetes，由于它能够更好地参与并塑造 etcd 所发挥的关键作用，从而也将有利于整个 etcd。

关于 SIG etcd

最近创建的 SIG 已经在努力实现其章程和愿景中定义的目标。其目的很明确：确保 etcd 是一个可靠、简单且可扩展的生产就绪存储，用于构建云原生分布式系统并通过 Kubernetes 等编排器管理云原生基础设施。

SIG etcd 的范围不仅仅涉及将 etcd 作为 Kubernetes 组件，还涵盖将 etcd 作为标准解决方案。我们的目标是使 etcd 成为可在任何地方使用的最可靠的键值存储，不受任何 kubernetes 特定限制的约束，并且可以扩展以满足许多不同用例的需求。

我们相信，SIG etcd 的创建将成为项目生命周期中的一个重要里程碑，同时改进 etcd 本身以及 etcd 与 Kubernetes 的集成。我们欢迎所有对 etcd 感兴趣的人访问我们的页面、加入我们的 Slack 频道，并参与 etcd 生命的新阶段。

Gateway API v1.0：正式发布（GA）

Tue, 31 Oct 2023 10:00:00 -0800

作者： Shane Utt (Kong), Nick Young (Isovalent), Rob Scott (Google)

译者： Xin Li (Daocloud)

我们代表 Kubernetes SIG Network 很高兴地宣布 Gateway API v1.0 版本发布！此版本是该项目的一个重要里程碑。几个关键的 API 正在逐步进入 GA（正式发布）阶段，同时其他重要特性已添加到实验（Experimental）通道中。

新增内容

升级到 v1

此版本将 Gateway、 GatewayClass 和 HTTPRoute 升级到 v1 版本，这意味着它们现在是正式发布（GA）的版本。这个 API 版本表明我们对 API 的可感知方面具有较强的信心，并提供向后兼容的保证。需要注意的是，虽然标准（Standard）通道中所包含的这个版本的 API 集合现在被认为是稳定的，但这并不意味着它们是完整的。即便这些 API 已满足毕业标准，仍将继续通过实验（Experimental）通道接收新特性。要了解相关工作的组织方式的进一步信息，请参阅 Gateway API 版本控制策略。

Gateway API 现在有了自己的 Logo！这个 Logo 是通过协作方式设计的，旨在表达这是一组用于路由南北向和东西向流量的 Kubernetes API：

CEL 验证

过去，Gateway API 在安装 API 时绑定了一个验证性质（Validation）的 Webhook。从 v1.0 开始，Webhook 的安装是可选的，仅建议在 Kubernetes 1.24 版本上使用。 Gateway API 现在将 CEL 验证规则包含在 CRD 中。Kubernetes 1.25 及以上版本支持这种新形式的验证，因此大多数安装中不再需要验证性质的 Webhook。

标准（Standard）通道

此发行版本主要侧重于确保现有 Beta 级别 API 定义良好且足够稳定，可以升级为 GA。其背后意味着为了提高与 Gateway API 交互时的整体用户体验而作的各种规范的澄清以及一些改进。

实验（Experimental）通道

此发行版本中包含的大部分更改都限于实验通道。这些更改包括 HTTPRoute 超时、用于 Gateway 访问后端的 TLS 配置、WebSocket 支持、Gateway 基础设施的标签等等。请继续关注后续博客，我们将详细介绍这些新特性。

其他内容

有关此版本中包含的所有更改的完整列表，请参阅 v1.0.0 版本说明。

发展历程

Gateway API 的想法最初是在 4 年前的 KubeCon 圣地亚哥提出的，下一代 Ingress API。那次会议之后，诞生了一个令人难以置信的社区，致力于开发一种可能是 Kubernetes 历史上协作关系最密切的 API。迄今为止，已有超过 170 人为此 API 做出了贡献，而且这个数字还在不断增长。

特别感谢 20 多位愿意在项目中担任正式角色的社区成员，他们付出了时间进行评审并分担项目维护的负担！

我们特别要强调那些在项目早期发展中起到关键作用的荣誉维护者：

尝试一下

与其他 Kubernetes API 不同，你无需升级到最新版本的 Kubernetes 即可获取最新版本的 Gateway API。只要运行的是 Kubernetes 最新的 5 个次要版本之一（1.24+），就可以使用最新版本的 Gateway API。

要尝试此 API，请参照我们的入门指南。

下一步

此版本只是 Gateway API 更广泛前景的开始，将来的 API 版本中还有很多新特性和新想法。

我们未来的一个关键目标是努力稳定和升级 API 的其他实验级特性。这些特性包括支持服务网格、额外的路由类型（GRPCRoute、 TCPRoute、 TLSRoute、 UDPRoute）以及各种实验级特性。

我们还致力于将 ReferenceGrant 移入内置的 Kubernetes API 中，使其不仅仅可用于网关 API。在 Gateway API 中，我们使用这个资源来安全地实现跨命名空间引用，而这个概念现在被其他 SIG 采纳。这个 API 的新版本将归 SIG Auth 所有，在移到内置的 Kubernetes API 时可能至少包含一些修改。

Gateway API 现身于 KubeCon + CloudNativeCon

在 KubeCon 北美（芝加哥）和同场的贡献者峰会上，有几个与 Gateway API 相关的演讲将详细介绍这些主题。如果你今年要参加其中的一场活动，请考虑将它们添加到你的日程安排中。

贡献者峰会：

KubeCon 主要活动：

Gateway API：Kubernetes 历史上协作性最强的 API 已经正式发布

KubeCon 办公时间：

如果你想就相关主题发起讨论或参与头脑风暴，请参加 Gateway API 维护人员在 KubeCon 上举行办公时间会议。要获取有关这些会议的最新更新，请加入 Kubernetes Slack 上的 #sig-network-gateway-api 频道。

参与其中

我们只是初步介绍了 Gateway API 正在进行的工作。有很多机会参与并帮助定义 Ingress 和 Mesh 的 Kubernetes 路由 API 的未来。

如果你对此感兴趣，请加入我们的社区并帮助我们共同构建 Gateway API 的未来！

Kubernetes 中 PersistentVolume 的最后阶段转换时间

Mon, 23 Oct 2023 00:00:00 +0000

作者： Roman Bednář (Red Hat)

译者： Xin Li (DaoCloud)

在最近的 Kubernetes v1.28 版本中，我们（SIG Storage）引入了一项新的 Alpha 级别特性，旨在改进 PersistentVolume（PV）存储管理并帮助集群管理员更好地了解 PV 的生命周期。通过将 lastPhaseTransitionTime 字段添加到 PV 的状态中，集群管理员现在可以跟踪 PV 上次转换到不同阶段的时间，从而实现更高效、更明智的资源管理。

我们为什么需要新的 PV 字段？

Kubernetes 中的 PersistentVolume 在为集群中运行的工作负载提供存储资源方面发挥着至关重要的作用。然而，有效管理这些 PV 可能具有挑战性，特别是在确定 PV 在不同阶段（Pending、Bound 或 Released）之间转换的最后时间时。管理员通常需要知道 PV 上次使用或转换到某些阶段的时间；例如，实施保留策略、执行清理或监控存储运行状况时。

过去，Kubernetes 用户在使用 Delete 保留策略时面临数据丢失问题，不得不使用更安全的 Retain 策略。当我们计划引入新的 lastPhaseTransitionTime 字段时，我们希望提供一个更通用的解决方案，可用于各种用例，包括根据卷上次使用时间进行手动清理或根据状态转变时间生成警报。

lastPhaseTransitionTime 如何提供帮助

如果你已启用特性门控（请参阅如何使用它），则每次 PV 从一个阶段转换到另一阶段时， PersistentVolume（PV）的新字段 .status.lastPhaseTransitionTime 都会被更新。

无论是从 Pending 转换到 Bound、Bound 到 Released，还是任何其他阶段转换，都会记录 lastPhaseTransitionTime。对于新创建的 PV，将被声明为处于 Pending 阶段，并且 lastPhaseTransitionTime 也将被记录。

此功能允许集群管理员：

实施保留政策

通过 lastPhaseTransitionTime，管理员可以跟踪 PV 上次使用或转换到 Released 阶段的时间。此信息对于实施保留策略以清理在特定时间内处于 Released 阶段的资源至关重要。例如，现在编写一个脚本或一个策略来删除一周内处于 Released 阶段的所有 PV 是很简单的。

监控存储运行状况

通过分析 PV 的相变时间，管理员可以更有效地监控存储运行状况。例如，他们可以识别处于 Pending 阶段时间异常长的 PV，这可能表明存储配置程序存在潜在问题。

如何使用它

从 Kubernetes v1.28 开始，lastPhaseTransitionTime 为 Alpha 特性字段，因此需要启用 PersistentVolumeLastPhaseTransitionTime 特性门控。

如果你想在该特性处于 Alpha 阶段时对其进行测试，则需要在 kube-controller-manager 和 kube-apiserver 上启用此特性门控。

使用 --feature-gates 命令行参数：

--feature-gates="...,PersistentVolumeLastPhaseTransitionTime=true"

请记住，该特性启用后不会立即生效；而是在 PV 更新以及阶段之间转换时，填充新字段。然后，管理员可以通过查看 PV 状态访问新字段，此状态可以使用标准 Kubernetes API 调用或通过 Kubernetes 客户端库进行检索。

以下示例展示了如何使用 kubectl 命令行工具检索特定 PV 的 lastPhaseTransitionTime：

kubectl get pv <pv-name> -o jsonpath='{.status.lastPhaseTransitionTime}'

未来发展

此特性最初是作为 Alpha 特性引入的，位于默认情况下禁用的特性门控之下。在 Alpha 阶段，我们（Kubernetes SIG Storage）将收集最终用户的反馈并解决发现的任何问题或改进。

一旦收到足够的反馈，或者没有收到投诉，该特性就可以进入 Beta 阶段。 Beta 阶段将使我们能够进一步验证实施并确保其稳定性。

在该字段升级到 Beta 级别和将该字段升级为通用版 (GA) 的版本之间，至少会经过两个 Kubernetes 版本。这意味着该字段 GA 的最早版本是 Kubernetes 1.32，可能计划于 2025 年初发布。

欢迎参与

我们始终欢迎新的贡献者，因此如果你想参与其中，可以加入我们的 Kubernetes 存储特殊兴趣小组（SIG）。

如果你想分享反馈，可以在我们的公共 Slack 频道上分享。如果你尚未加入 Slack 工作区，可以访问 https://slack.k8s.io/ 获取邀请。

特别感谢所有提供精彩评论、分享宝贵意见并帮助实现此特性的贡献者（按字母顺序排列）：

Han Kang (logicalhan)
Jan Šafránek (jsafrane)
Jordan Liggitt (liggitt)
Kiki (carlory)
Michelle Au (msau42)
Tim Bannister (sftim)
Wojciech Tyczynski (wojtek-t)
Xing Yang (xing-yang)

2023 中国 Kubernetes 贡献者峰会简要回顾

Fri, 20 Oct 2023 00:00:00 +0000

作者： Paco Xu 和 Michael Yao (DaoCloud)

2023 年 9 月 26 日，即 KubeCon + CloudNativeCon + Open Source Summit China 2023 第一天，近 50 位社区贡献者济济一堂，在上海聚首 Kubernetes 贡献者峰会。

2023 Kubernetes 贡献者峰会与会者集体合影

这是疫情三年之后，首次在中国本土召开的面对面线下聚会。

开心遇见

首先是本次 KubeCon 活动的联席主席、来自华为云的 Kevin Wang 和来自 Gaint Swarm 的 Puja 做了欢迎致辞。

随后在座的几十位贡献者分别做了简单的自我介绍，80% 以上的与会者来自中国，还有一些贡献者专程从欧美飞到上海参会。其中不乏来自微软、Intel、华为的技术大咖，也有来自 DaoCloud 这样的新锐中坚力量。欢声笑语齐聚一堂，无论是操着欧美口音的英语，还是地道的中国话，都在诠释着舒心与欢畅，表达着尊敬和憧憬。是曾经做出的贡献拉近了彼此，是互相的肯定和成就赋予了这次线下聚会的可能。

Face to face meeting in Shanghai

与会的贡献者不再是简单的 GitHub ID，而是进阶为一个个鲜活的面孔，从静坐一堂，到合照留影，到寻觅彼此辨别 Who is Who 的那一刻起，我们事实上已形成了一个松散的集体。这个 team 结构松散、自由开放，却是为了追逐梦想而成立。

一分耕耘一分收获，每一份努力都已清晰地记录在 Kubernetes 社区贡献中。无论时光如何流逝，社区中不会抹去那些发光的痕迹，璀璨可能是你的 PR、Issue 或 comments，也可能是某次 Meetup 的合影笑脸，还可能是贡献者口口相传的故事。

技术分享和讨论

接下来是 3 个技术分享：

sig-multi-cluster： Karmada 的维护者 Hongcai Ren 介绍了这个 SIG 的职责和作用。这个 SIG 负责设计、讨论、实现和维护多集群管理相关的 API、工具和文档。其中涉及的 Cluster Federation 也是 Karmada 的核心概念之一。

helmfile：来自极狐 GitLab 的 yxxhero 介绍了如何声明式部署 Kubernetes 清单，如何自定义配置，如何使用 Helm 的最新特性 Helmfile 等内容。
sig-scheduling：来自华为云的 william-wang 介绍了 SIG Scheduling 最近更新的特性以及未来的规划。SIG Scheduling 负责设计、开发和测试 Pod 调度相关的组件。

有关 sig-multi-cluster 的技术主题演讲

随后播放了来自 SIG-Node Chair Sergey Kanzhelev 的贡献者招募视频，希望更多贡献者参与到 Kubernetes 社区，特别是社区热门的 SIG-Node 方向。

最后，Kevin 主持了 Unconference 的集体讨论活动，主要涉及到多集群、调度、弹性、AI 等方向。有关 Unconference 会议纪要，参阅 https://docs.qq.com/doc/DY3pLWklzQkhjWHNT

中国贡献者数据

本次贡献者峰会在上海举办，有 90% 的与会者为华人。而在 CNCF 生态体系中，来自中国的贡献数据也在持续增长，目前：

中国贡献者占比 9%
中国贡献量占比 11.7%
全球贡献排名第 2

说明：

以上数据来自 CNCF 首席技术官 Chris Aniszczyk 在 2023 年 9 月 26 日 KubeCon 的主题演讲。另外，由于大量中国贡献者使用 VPN 连接社区，这些统计数据可能与真实数据有所差异。

Kubernetes 贡献者峰会是一个自由开放的 Meetup，欢迎社区所有贡献者参与：

新人
老兵
- 文档
- 代码
- 社区管理
子项目 Owner 和参与者
特别兴趣小组（SIG）或工作小组（WG）人员
活跃的贡献者
临时贡献者

致谢

感谢本次活动的组织者：

Kevin Wang 是本次 KubeCon 活动的联席主席，也是贡献者峰会的负责人
Paco Xu 积极联络场地餐食，联系和邀请国内外贡献者，建立微信群征集议题，会前会后公示活动细节等
Mengjiao Liu 负责组织协调和联络事宜

我们衷心感谢所有参加在上海举办的中国 Kubernetes 贡献者峰会的贡献者们。你们对 Kubernetes 社区的奉献和承诺是无价之宝。让我们携手共进，继续推动云原生技术的边界，塑造这个生态系统的未来。

CRI-O 正迁移至 pkgs.k8s.io

Tue, 10 Oct 2023 00:00:00 +0000

作者：Sascha Grunert

译者：Wilson Wu (DaoCloud)

Kubernetes 社区最近宣布旧的软件包仓库已被冻结，现在这些软件包将被迁移到由 OpenBuildService（OBS）提供支持的社区自治软件包仓库中。很久以来，CRI-O 一直在利用 OBS 进行软件包构建，但到目前为止，所有打包工作都是手动完成的。

CRI-O 社区非常喜欢 Kubernetes，这意味着他们很高兴地宣布：

所有未来的 CRI-O 包都将作为在 pkgs.k8s.io 上托管的官方支持的 Kubernetes 基础设施的一部分提供！

现有软件包将进入一个弃用阶段，目前正在 CRI-O 社区中讨论。新的基础设施将仅支持 CRI-O >= v1.28.2 的版本以及比 release-1.28 新的版本分支。

如何使用新软件包

与 Kubernetes 社区一样，CRI-O 提供 deb 和 rpm 软件包作为 OBS 中专用子项目的一部分，被称为 isv:kubernetes:addons:cri-o。这个项目是一个集合，提供 stable（针对 CRI-O 标记）以及 prerelease（针对 CRI-O release-1.y 和 main 分支）版本的软件包。

稳定版本：

isv:kubernetes:addons:cri-o:stable：稳定软件包
- isv:kubernetes:addons:cri-o:stable:v1.29：v1.29.z 标记
- isv:kubernetes:addons:cri-o:stable:v1.28：v1.28.z 标记

预发布版本：

isv:kubernetes:addons:cri-o:prerelease：预发布软件包
- isv:kubernetes:addons:cri-o:prerelease:main： main 分支
- isv:kubernetes:addons:cri-o:prerelease:v1.29： release-1.29 分支
- isv:kubernetes:addons:cri-o:prerelease:v1.28： release-1.28 分支

v1.29 仓库中尚无可用的稳定版本，因为 v1.29.0 将于 12 月发布。 CRI-O 社区也不支持早于 release-1.28 的版本分支，因为已经有 CI 需求合并到 main 中，只有通过适当的努力才能向后移植到 release-1.28。

例如，如果最终用户想要安装 CRI-O main 分支的最新可用版本，那么他们可以按照与 Kubernetes 相同的方式添加仓库。

基于 `rpm` 的发行版

对于基于 rpm 的发行版，您可以以 root 用户身份运行以下命令来将 CRI-O 与 Kubernetes 一起安装：

添加 Kubernetes 仓库

cat <<EOF | tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
EOF

添加 CRI-O 仓库

cat <<EOF | tee /etc/yum.repos.d/cri-o.repo
[cri-o]
name=CRI-O
baseurl=https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/rpm/repodata/repomd.xml.key
EOF

安装官方包依赖

dnf install -y \
    conntrack \
    container-selinux \
    ebtables \
    ethtool \
    iptables \
    socat

从添加的仓库中安装软件包

dnf install -y --repo cri-o --repo kubernetes \
    cri-o \
    kubeadm \
    kubectl \
    kubelet

基于 `deb` 的发行版

对于基于 deb 的发行版，您可以以 root 用户身份运行以下命令：

安装用于添加仓库的依赖项

apt-get update
apt-get install -y software-properties-common curl

添加 Kubernetes 仓库

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key |
    gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /" |
    tee /etc/apt/sources.list.d/kubernetes.list

添加 CRI-O 仓库

curl -fsSL https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/deb/Release.key |
    gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/deb/ /" |
    tee /etc/apt/sources.list.d/cri-o.list

安装软件包

apt-get update
apt-get install -y cri-o kubelet kubeadm kubectl

启动 CRI-O

systemctl start crio.service

如果使用的是另一个包序列，CRI-O 包路径中项目的 prerelease:/main 前缀可以替换为 stable:/v1.28、stable:/v1.29、prerelease:/v1.28 或 prerelease :/v1.29。

你可以使用 kubeadm init 命令来引导集群，该命令会自动检测后台正在运行 CRI-O。还有适用于 Fedora 38 以及 Ubuntu 22.04 的 Vagrantfile 示例，可在使用 kubeadm 的场景中测试下载的软件包。

它是如何工作的

与这些包相关的所有内容都位于新的 CRI-O 打包仓库中。它包含 Daily Reconciliation GitHub 工作流，支持所有发布分支以及 CRI-O 标签。 OBS 工作流程中的测试管道确保包在发布之前可以被正确安装和使用。所有包的暂存和发布都是在 Kubernetes 发布工具箱（krel）的帮助下完成的，这一工具箱也被用于官方 Kubernetes deb 和 rpm 软件包。

包构建的输入每天都会被动态调整，并使用 CRI-O 的静态二进制包。这些包是基于 CRI-O CI 中的每次提交来构建和签名的，并且包含 CRI-O 在特定架构上运行所需的所有内容。静态构建是可重复的，由 nixpkgs 提供支持，并且仅适用于 x86_64、aarch64 以及 ppc64le 架构。

CRI-O 维护者将很乐意听取有关新软件包工作情况的任何反馈或建议！感谢您阅读本文，请随时通过 Kubernetes Slack 频道 #crio 联系维护人员或在打包仓库中创建 Issue。

聚焦 SIG Architecture: Conformance

Thu, 05 Oct 2023 00:00:00 +0000

作者：Frederico Muñoz (SAS Institute)

译者：Michael Yao (DaoCloud)

这是 SIG Architecture 焦点访谈系列的首次采访，这一系列访谈将涵盖多个子项目。我们从 SIG Architecture：Conformance 子项目开始。

在本次 SIG Architecture 访谈中，我们与 Riaan Kleinhans (ii-Team) 进行了对话，他是 Conformance 子项目的负责人。

关于 SIG Architecture 和 Conformance 子项目

Frederico (FSM)：你好 Riaan，欢迎！首先，请介绍一下你自己，你的角色以及你是如何参与 Kubernetes 的。

Riaan Kleinhans (RK)：嗨！我叫 Riaan Kleinhans，我住在南非。我是新西兰 ii-Team 的项目经理。在我加入 ii 时，本来计划在 2020 年 4 月搬到新西兰，然后新冠疫情爆发了。幸运的是，作为一个灵活和富有活力的团队，我们能够在各个不同的时区以远程方式协作。

ii 团队负责管理 Kubernetes Conformance 测试的技术债务，并编写测试内容来消除这些技术债务。我担任项目经理的角色，成为监控、测试内容编写和社区之间的桥梁。通过这项工作，我有幸在最初的几个月里结识了 Dan Kohn，他对我们的工作充满热情，给了我很大的启发。

FSM：谢谢！所以，你参与 SIG Architecture 是因为合规性的工作？

RK：SIG Architecture 负责管理 Kubernetes Conformance 子项目。最初，我大部分时间直接与 SIG Architecture 交流 Conformance 子项目。然而，随着我们开始按 SIG 来组织工作任务，我们开始直接与各个 SIG 进行协作。与拥有未被测试的 API 的这些 SIG 的协作帮助我们加快了工作进度。

FSM：你如何描述 Conformance 子项目的主要目标和介入的领域？

RM: Kubernetes Conformance 子项目专注于通过开发和维护全面的合规性测试套件来确保兼容性并遵守 Kubernetes 规范。其主要目标包括确保不同 Kubernetes 实现之间的兼容性，验证 API 规范的遵守情况，通过鼓励合规性认证来支持生态体系，并促进 Kubernetes 社区内的合作。通过提供标准化的测试并促进一致的行为和功能， Conformance 子项目为开发人员和用户提供了一个可靠且兼容的 Kubernetes 生态体系。

关于 Conformance Test Suite 的更多内容

FSM：我认为，提供这些标准化测试的一部分工作在于 Conformance Test Suite。你能解释一下它是什么以及其重要性吗？

RK：Kubernetes Conformance Test Suite 检查 Kubernetes 发行版是否符合项目的规范，确保在不同的实现之间的兼容性。它涵盖了诸如 API、联网、存储、调度和安全等各个特性。能够通过测试，则表示实现合理，便于推动构建一致且可移植的容器编排平台。

FSM：是的，这些测试很重要，因为它们定义了所有 Kubernetes 集群必须支持的最小特性集合。你能描述一下决定将哪些特性包含在内的过程吗？在最小特性集的思路与其他 SIG 提案之间是否有所冲突？

RK：SIG Architecture 针对经受合规性测试的每个端点的要求，都有明确的定义。 API 端点只有正式发布且不是可选的特性，才会被（进一步）考虑是否合规。多年来，关于合规性配置文件已经进行了若干讨论，探讨将被大多数终端用户广泛使用的可选端点（例如 RBAC）纳入特定配置文件中的可能性。然而，这一方面仍在不断改进中。

不满足合规性标准的端点被列在 ineligible_endpoints.yaml 中，该文件放在 Kubernetes 代码仓库中，是被公开访问的。随着这些端点的状态或要求发生变化，此文件可能会被更新以添加或删除端点。不合格的端点也可以在 APISnoop 上看到。

对于 SIG Architecture 来说，确保透明度并纳入社区意见以确定端点的合格或不合格状态是至关重要的。

FSM：为新特性编写测试内容通常需要某种强制执行方式。你如何看待 Kubernetes 中这方面的演变？是否有人在努力改进这个流程，使得必须具备测试成为头等要务，或许这从来都不是一个问题？

RK：在 2018 年开始围绕 Kubernetes 合规性计划进行讨论时，只有大约 11% 的端点被测试所覆盖。那时，CNCF 的管理委员会提出一个要求，如果要提供资金覆盖缺失的合规性测试，Kubernetes 社区应采取一个策略，即如果新特性没有包含稳定 API 的合规性测试，则不允许添加此特性。

SIG Architecture 负责监督这一要求，APISnoop 在此方面被证明是一个非常有价值的工具。通过自动化流程，APISnoop 在每个周末生成一个 PR，以突出 Conformance 覆盖范围的变化。如果有端点在没有进行合规性测试的情况下进阶至正式发布，将会被迅速识别发现。这种方法有助于防止积累新的技术债务。

此外，我们计划在不久的将来创建一个发布通知任务，作用是添加额外一层防护，以防止产生新的技术债务。

FSM：我明白了，工具化和自动化在其中起着重要的作用。在你看来，就合规性而言，还有哪些领域需要做一些工作？换句话说，目前标记为优先改进的领域有哪些？

RK：在 1.27 版本中，我们已完成了 “100% 合规性测试” 的里程碑！

当时，社区重新审视了所有被列为不合规的端点。这个列表是收集多年的社区意见后填充的。之前被认为不合规的几个端点已被挑选出来并迁移到一个新的专用列表中，该列表中包含目前合规性测试开发的焦点。同样，可以在 apisnoop.cncf.io 上查阅此列表。

为了确保在合规性项目中避免产生新的技术债务，我们计划建立一个发布通知任务作为额外的预防措施。

虽然 APISnoop 目前被托管在 CNCF 基础设施上，但此项目已慷慨地捐赠给了 Kubernetes 社区。因此，它将在 2023 年底之前转移到社区自治的基础设施上。

FSM：这是个好消息！对于想要提供帮助的人们，你能否重点说明一下协作的价值所在？参与贡献是否需要对 Kubernetes 有很扎实的知识，或否有办法让一些新人也能为此项目做出贡献？

RK：参与合规性测试就像 "洗碗" 一样，它可能不太显眼，但仍然非常重要。这需要对 Kubernetes 有深入的理解，特别是在需要对端点进行测试的领域。这就是为什么与负责测试 API 端点的每个 SIG 进行协作会如此重要。

我们的承诺是让所有人都能参与测试内容编写，作为这一承诺的一部分， ii 团队目前正在开发一个 “点击即部署（click and deploy）” 的解决方案。此解决方案旨在使所有人都能在几分钟内快速创建一个在真实硬件上工作的环境。我们将在准备好后分享有关此项开发的更新。

FSM：那会非常有帮助，谢谢。最后你还想与我们的读者分享些什么见解吗？

RK：合规性测试是一个协作性的社区工作，涉及各个 SIG 之间的广泛合作。 SIG Architecture 在推动倡议并提供指导方面起到了领头作用。然而，工作的进展在很大程度上依赖于所有 SIG 在审查、增强和认可测试方面的支持。

我要衷心感谢 ii 团队多年来对解决技术债务的坚定承诺。特别要感谢 Hippie Hacker 的指导和对愿景的引领作用，这是非常宝贵的。此外，我还要特别表扬 Stephen Heywood 在最近几个版本中承担了大部分测试内容编写工作而做出的贡献，还有 Zach Mandeville 对 APISnoop 也做了很好的贡献。

FSM：非常感谢你参加本次访谈并分享你的深刻见解，我本人从中获益良多，我相信读者们也会同样受益。

公布 2023 年指导委员会选举结果

Mon, 02 Oct 2023 00:00:00 +0000

作者：Kaslin Fields

译者：Xin Li(DaoCloud)

2023 年指导委员会选举现已完成。 Kubernetes 指导委员会由 7 个席位组成，其中 4 个席位于 2023 年进行选举。新任委员会成员的任期为 2 年，所有成员均由 Kubernetes 社区选举产生。

这个社区机构非常重要，因为它负责监督整个 Kubernetes 项目的治理。权力越大责任越大，你可以在其章程中了解有关指导委员会角色的更多信息。

感谢所有在选举中投票的人；你们的参与有助于支持社区的持续健康和成功。

结果

祝贺当选的委员会成员，其两年任期立即开始（按 GitHub 名称字母顺序列出）：

Stephen Augustus (@justaugustus), Cisco
Paco Xu 徐俊杰 (@pacoxu), DaoCloud
Patrick Ohly (@pohly), Intel
Maciej Szulik (@soltysh), Red Hat

他们将与一下连任成员一起工作：

Benjamin Elder (@bentheelder), Google
Bob Killen (@mrbobbytables), Google
Nabarun Pal (@palnabarun), VMware

Stephen Augustus 是回归的指导委员会成员。

十分感谢！

感谢并祝贺本轮选举官员成功完成选举工作：

Bridget Kromhout (@bridgetkromhout)
Davanum Srinavas (@dims)
Kaslin Fields (@kaslin)

感谢名誉指导委员会成员，你们的服务受到社区的赞赏：

Christoph Blecker (@cblecker)
Carlos Tadeu Panato Jr. (@cpanato)
Tim Pepper (@tpepper)

感谢所有前来竞选的候选人。

参与指导委员会

你可以关注指导委员会积压的项目，并通过提交 Issue 或针对其 repo 创建 PR 来参与。他们在太平洋时间每月第一个周一上午 9:30 举行开放的会议。你还可以通过其公共邮件列表 steering@kubernetes.io 与他们联系。

你可以通过在 YouTube 播放列表上观看过去的会议来了解指导委员会会议的全部内容。

如果你想认识一些新当选的指导委员会成员，请参加我们在芝加哥 Kubernetes 贡献者峰会举行的 Steering AMA。

这篇文章是由贡献者通信子项目撰写的。如果你想撰写有关 Kubernetes 社区的故事，请了解有关我们的更多信息。

kubeadm 七周年生日快乐！

Tue, 26 Sep 2023 00:00:00 +0000

作者: Fabrizio Pandini (VMware)

译者: Michael Yao (DaoCloud)

回首向来萧瑟处，七年光阴风雨路！

从 2016 年 9 月发表第一篇博文 How we made Kubernetes insanely easy to install 开始，kubeadm 经历了令人激动的成长旅程，两年后随着 Production-Ready Kubernetes Cluster Creation with kubeadm 这篇博文的发表进阶为正式发布。

此后，持续、稳定且可靠的系列小幅改进一直延续至今。

什么是 kubeadm？（简要回顾）

kubeadm 专注于在现有基础设施上启动引导 Kubernetes 集群并执行一组重要的维护任务。 kubeadm 接口的核心非常简单：通过运行 kubeadm init 创建新的控制平面节点，通过运行 kubeadm join 将工作节点加入控制平面。此外还有用于管理已启动引导的集群的实用程序，例如控制平面升级、令牌和证书续订等。

为了使 kubeadm 精简、聚焦且与供应商/基础设施无关，以下任务不包括在其范围内：

基础设施制备
第三方联网
例如监视、日志记录和可视化等非关键的插件
特定云驱动集成

例如，基础设施制备留给 SIG Cluster Lifecycle 等其他项目来处理，比如 Cluster API。 kubeadm 仅涵盖每个 Kubernetes 集群中的共同要素：控制平面。用户可以在集群创建后安装其偏好的联网方案和其他插件。

kubeadm 在幕后做了大量工作。它确保你拥有所有关键组件：etcd、API 服务器、调度器、控制器管理器。你可以加入更多的控制平面节点以提高容错性，或者加入工作节点以运行你的工作负载。 kubeadm 还为你设置好了集群 DNS 和 kube-proxy；在各组件之间启用 TLS 用于传输加密。

庆祝 kubeadm 的过去、现在和未来！

总之，kubeadm 的故事与 Kubernetes 深度耦合，也离不开这个令人惊叹的社区。

因此庆祝 kubeadm 首先是庆祝这个社区，一群人共同努力寻找一个共同点，一个最小可行工具，用于启动引导 Kubernetes 集群。

kubeadm 这个工具对 Kubernetes 的成功起到了关键作用，其价值主张可以概括为两点：

极致的简单：只需两个命令 kubeadm init 和 kubeadm join 即可完成初始化和接入集群的操作！让大多数用户轻松上手。
明确定义的问题范围：专注于在现有基础设施上启动引导 Kubernetes 集群。正如我们的口号所说：保持简单，保持可扩展！

这个明确的约定是整个 kubeadm 用户群体所依赖的基石，同时本文也是为了与 kubeadm 的使用者们共同欢庆。

我们由衷感谢用户给予的反馈，感谢他们通过 Slack、GitHub、社交媒体、博客、每次 KubeCon 会面以及各种聚会上持续展现的热情。来看看后续的发展！

这么多年来，对人们基于 kubeadm 构建的诸多项目我感到惊叹。迄今已经有很多强大而活跃的项目，例如：

minikube
kind
Cluster API
Kubespray
还有更多；如果你正在使用 Kubernetes，很可能你甚至不知道自己正在使用 kubeadm 😜

这个社区、kubeadm 的用户以及基于 kubeadm 构建的项目，是 kubeadm 七周年庆典的亮点，也是未来怎么发展的基础！

请继续关注我们，并随时与我们联系！

现在尝试使用 kubeadm 安装 Kubernetes
在 GitHub 参与 Kubernetes 项目
在 Slack 与社区交流
关注我们的 Twitter 账号 @Kubernetesio，获取最近更新信息

kubeadm：使用 etcd Learner 安全地接入控制平面节点

Mon, 25 Sep 2023 00:00:00 +0000

作者: Paco Xu (DaoCloud)

译者: Michael Yao (DaoCloud)

kubeadm 工具现在支持 etcd learner 模式，借助 etcd 3.4 版本引入的 learner 模式特性，可以提高 Kubernetes 集群的弹性和稳定性。本文将介绍如何在 kubeadm 中使用 etcd learner 模式。默认情况下，kubeadm 在每个控制平面节点上运行一个本地 etcd 实例。

在 v1.27 中，kubeadm 引入了一个新的特性门控 EtcdLearnerMode。启用此特性门控后，在加入新的控制平面节点时，一个新的 etcd 成员将被创建为 learner，只有在 etcd 数据被完全对齐后此成员才会晋升为投票成员。

使用 etcd learner 模式的优势是什么？

在 Kubernetes 集群中采用 etcd learner 模式具有以下几个优点：

增强了弹性：etcd learner 节点是非投票成员，在完全进入角色之前会追随领导者的日志。这样可以防止新的集群成员干扰投票结果或引起领导者选举，从而使集群在成员变更期间更具弹性。
减少了集群不可用时间：传统的添加新成员的方法通常会造成一段时间集群不可用，特别是在基础设施迟缓或误配的情况下更为明显。而 etcd learner 模式可以最大程度地减少此类干扰。
简化了维护：learner 节点提供了一种更安全、可逆的方式来添加或替换集群成员。这降低了由于误配或在成员添加过程中出错而导致集群意外失效的风险。
改进了网络容错性：在涉及网络分区的场景中，learner 模式允许更优雅的处理。根据新成员所落入的分区，它可以无缝地与现有集群集成，而不会造成中断。

总之，etcd learner 模式可以在成员添加和变更期间提高 Kubernetes 集群的可靠性和可管理性，这个特性对集群运营人员很有价值。

节点如何接入使用这种新模式的集群

创建以 etcd learner 模式支撑的 Kubernetes 集群

关于使用 kubeadm 创建高可用集群的通用说明，请参阅使用 kubeadm 创建高可用集群。

要使用 kubeadm 创建一个后台是 learner 模式的 etcd 的 Kubernetes 集群，按照以下步骤操作：

# kubeadm init --feature-gates=EtcdLearnerMode=true ...
kubeadm init --config=kubeadm-config.yaml

kubeadm 配置文件如下：

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
featureGates:
  EtcdLearnerMode: true

这里，kubeadm 工具部署单节点 Kubernetes 集群，其中的 etcd 被设置为 learner 模式。

将节点接入 Kubernetes 集群

在将控制平面节点接入新的 Kubernetes 集群之前，确保现有的控制平面节点和所有 etcd 成员都健康。

使用 etcdctl 检查集群的健康状况。如果 etcdctl 不可用，你可以运行在容器镜像内的这个工具。你可以直接使用 crictl run 这类容器运行时工具而不是通过 Kubernetes 来执行此操作。

以下是一个使用安全通信来检查 etcd 集群健康状况的客户端命令示例：

ETCDCTL_API=3 etcdctl --endpoints 127.0.0.1:2379 \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  member list
...
dc543c4d307fadb9, started, node1, https://10.6.177.40:2380, https://10.6.177.40:2379, false

要检查 Kubernetes 控制平面是否健康，运行 kubectl get node -l node-role.kubernetes.io/control-plane= 并检查节点是否就绪。

说明：

建议在 etcd 集群中的成员个数为奇数。

在将工作节点接入新的 Kubernetes 集群之前，确保控制平面节点健康。

接下来的步骤

特性门控 EtcdLearnerMode 在 v1.27 中为 Alpha，预计会在 Kubernetes 的下一个小版本发布（v1.29）中进阶至 Beta。
etcd 社区有一个开放问题，目的是使这个过程更加自动化：支持自动将 learner 成员晋升为投票成员。
更多细节参阅 kubeadm 配置格式。

反馈

本文对你有帮助吗？如果你有任何反馈或遇到任何问题，请告诉我们。非常欢迎你提出反馈！你可以参加 SIG Cluster Lifecycle 双周例会或 kubeadm 每周讨论会。你还可以通过 Slack（频道 #kubeadm）或 SIG 邮件列表联系我们。

用户命名空间：对运行有状态 Pod 的支持进入 Alpha 阶段!

Wed, 13 Sep 2023 00:00:00 +0000

作者： Rodrigo Campos Catelin (Microsoft), Giuseppe Scrivano (Red Hat), Sascha Grunert (Red Hat)

译者： Xin Li (DaoCloud)

Kubernetes v1.25 引入用户命名空间（User Namespace）特性，仅支持无状态（Stateless）Pod。 Kubernetes 1.28 在 1.27 的基础上中进行了一些改进后，取消了这一限制。

此特性的精妙之处在于：

使用起来很简单（只需在 Pod 规约（spec）中设置一个 bool）
大多数应用程序不需要任何更改
通过大幅度加强容器的隔离性以及应对评级为高（HIGH）和关键（CRITICAL）的 CVE 来提高安全性。

这篇文章介绍了用户命名空间的基础知识，并展示了：

最近的 Kubernetes v1.28 版本中出现的变化
一个评级为高（HIGH）的漏洞的演示（Demo），该漏洞无法在用户命名空间中被利用
使用此特性的运行时要求
关于用户命名空间的未来版本中可以期待的内容

用户命名空间是什么？

用户命名空间是 Linux 的一项特性，它将容器的用户和组标识符（UID 和 GID）与宿主机上的标识符隔离开来。容器中的标识符可以映射到宿主机上的标识符，其中用于不同容器的主机 UID/GID 从不重叠。更重要的是，标识符可以映射到宿主机上的非特权、非重叠的 UID 和 GID。这基本上意味着两件事：

由于不同容器的 UID 和 GID 映射到宿主机上不同的 UID 和 GID，因此即使它们逃逸出了容器的边界，也很难相互攻击。例如，如果容器 A 在宿主机上使用与容器 B 不同的 UID 和 GID 运行，则它可以对容器 B 的文件和进程执行的操作受到限制：只能读/写允许其他人使用的文件，因为它永远不会拥有所有者或组的权限（宿主机上的 UID/GID 保证对于不同的容器是不同的）。

由于 UID 和 GID 映射到宿主机上的非特权用户，如果容器逃逸出了容器边界，即使它在容器内以 root 身份运行，它在宿主机上也没有特权。这极大地保护了它可以读/写哪些宿主机文件、可以向哪个进程发送信号等。

此外，所授予的权能（Capability）仅在用户命名空间内有效，而在宿主机上无效。

在不使用用户命名空间的情况下，以 root 身份运行的容器在发生逃逸的情况下会获得节点上的 root 权限。如果某些权能被授予容器，那么这些权能在主机上也有效。当使用用户命名空间时，这些情况都会被避免（当然，除非存在漏洞 🙂）。

1.28 版本的变化

正如之前提到的，从 1.28 版本开始，Kubernetes 支持有状态的 Pod 的用户命名空间。这意味着具有用户命名空间的 Pod 可以使用任何类型的卷，不再仅限于以前的部分卷类型。

从 1.28 版本开始，用于激活此特性的特性门控已被重命名，不再是 UserNamespacesStatelessPodsSupport，而应该使用 UserNamespacesSupport。此特性经历了许多更改，对节点主机的要求也发生了变化。因此，Kubernetes 1.28 版本将该特性标志重命名以反映这一变化。

演示

Rodrigo 创建了一个利用 CVE 2022-0492 的演示，用以展现如何在没有用户命名空间的情况下利用该漏洞。他还展示了在容器使用了此特性的 Pod 中无法利用此漏洞的情况。

此漏洞被评为高危，允许一个没有特殊特权的容器读/写宿主机上的任何路径，并在宿主机上以 root 身份启动进程。

如今，容器中的大多数应用程序都以 root 身份运行，或者以半可预测的非 root 用户身份运行（用户 ID 65534 是一个比较流行的选择）。当你运行某个 Pod，而其中带有使用用户名命名空间（userns）的容器时，Kubernetes 以非特权用户身份运行这些容器，无需在你的应用程序中进行任何更改。

这意味着两个以用户 65534 身份运行的容器实际上会被映射到宿主机上的不同用户，从而限制了它们在发生逃逸的情况下能够对彼此执行的操作，如果它们以 root 身份运行，宿主机上的特权也会降低到非特权用户的权限。

节点系统要求

要使用此功能，对 Linux 内核版本以及容器运行时有一定要求。

在 Linux上，你需要 Linux 6.3 或更高版本。这是因为该特性依赖于一个名为 idmap mounts 的内核特性，而 Linux 6.3 中合并了针对 tmpfs 使用 idmap mounts 的支持

如果你使用 CRI-O 与 crun，这一特性在 CRI-O 1.28.1 和 crun 1.9 或更高版本中受支持。如果你使用 CRI-O 与 runc，目前仍不受支持。

containerd 对此的支持目前设定的目标是 containerd 2.0；不管你是否与 crun 或 runc 一起使用，或许都不重要。

请注意，containerd 1.7 添加了对用户命名空间的实验性支持，正如在 Kubernetes 1.25 和 1.26 中实现的那样。1.27 版本中进行的重新设计不受 containerd 1.7 支持，因此它在用户命名空间支持方面仅适用于 Kubernetes 1.25 和 1.26。

containerd 1.7 存在的一个限制是，在 Pod 启动期间需要更改容器镜像中每个文件和目录的所有权。这意味着它具有存储开销，并且可能会显著影响容器启动延迟。containerd 2.0 可能会包括一个实现，可以消除增加的启动延迟和存储开销。如果计划在生产中使用 containerd 1.7 与用户命名空间，请考虑这一点。

这些 Containerd 限制均不适用于 [CRI-O 1.28][CRIO 版本]。

接下来？

展望 Kubernetes 1.29，计划是与 SIG Auth 合作，将用户命名空间集成到 Pod 安全标准（PSS）和 Pod 安全准入中。目前的计划是在使用用户命名空间时放宽 Pod 安全标准（PSS）策略中的检查。这意味着如果使用用户命名空间，那么字段 spec[.*].securityContext、runAsUser、runAsNonRoot、allowPrivilegeEscalation和capabilities 将不会触发违规，此行为可能会通过使用 API Server 特性门控来控制，比如 UserNamespacesPodSecurityStandards 或其他类似的。

我该如何参与？

你可以通过以下方式与 SIG Node 联系：

你还可以直接联系我们：

GitHub：@rata @giuseppe @saschagrunert
Slack：@rata @giuseppe @sascha

比较本地 Kubernetes 开发工具：Telepresence、Gefyra 和 mirrord

Tue, 12 Sep 2023 00:00:00 +0000

作者: Eyal Bukchin (MetalBear)

译者: Michael Yao (DaoCloud)

Kubernetes 的开发周期是一个不断演化的领域，有许多工具在寻求简化这个过程。每个工具都有其独特的方法，具体选择通常取决于各个项目的要求、团队的专业知识以及所偏好的工作流。

在各种解决方案中，我们称之为“本地 K8S 开发工具”的一个类别已渐露端倪，这一类方案通过将本地运行的组件连接到 Kubernetes 集群来提升 Kubernetes 开发体验。这样可以在云环境中快速测试新代码，避开了 Docker 化、CI 和部署这样的传统周期。

在本文中，我们将比较这个类别中的三个解决方案：Telepresence、Gefyra 和我们自己的挑战者 mirrord。

Telepresence

Telepresence 是这类工具中最早也最成熟的解决方案，它使用 VPN（或更具体地说，一个 tun 设备）将用户的机器（或本地运行的容器）与集群的网络相连。它支持拦截发送到集群中特定服务的传入流量，并将其重定向到本地端口。被重定向的流量还可以被过滤，以避免完全破坏远程服务。它还提供了一些补充特性，如支持文件访问（通过本地挂载卷将其挂载到 Pod 上）和导入环境变量。 Telepresence 需要在用户的机器上安装一个本地守护进程（需要 root 权限），并在集群上运行一个 Traffic Manager 组件。此外，它在 Pod 上以边车的形式运行一个 Agent 来拦截所需的流量。

Gefyra

Gefyra 与 Telepresence 类似，也采用 VPN 连接到集群。但 Gefyra 只支持将本地运行的 Docker 容器连接到集群。这种方法增强了在不同操作系统和本地设置环境之间的可移植性。然而，它的缺点是不支持原生运行非容器化的代码。

Gefyra 主要关注网络流量，不支持文件访问和环境变量。与 Telepresence 不同，Gefyra 不会改变集群中的工作负载，因此如果发生意外情况，清理过程更加简单明了。

mirrord

作为这三个工具中最新的工具，mirrord采用了一种不同的方法，它通过将自身注入到本地二进制文件中（在 Linux 上利用 LD_PRELOAD，在 macOS 上利用 DYLD_INSERT_LIBRARIES），并重写 libc 函数调用，然后代理到在集群中运行的临时代理。例如，当本地进程尝试读取一个文件时，mirrord 会拦截该调用并将其发送到该代理，该代理再从远程 Pod 读取文件。这种方法允许 mirrord 覆盖进程的所有输入和输出，统一处理网络访问、文件访问和环境变量。

通过在进程级别工作，mirrord 支持同时运行多个本地进程，每个进程都在集群中的相应 Pod 上下文中运行，无需将这些进程容器化，也无需在用户机器上获取 root 权限。

摘要

比较 Telepresence、Gefyra 和 mirrord
	Telepresence	Gefyra	mirrord
集群连接作用域	整台机器或容器	容器	进程
开发者操作系统支持	Linux、macOS、Windows	Linux、macOS、Windows	Linux、macOS、Windows (WSL)
传入的流量特性	拦截	拦截	拦截或镜像
文件访问	已支持	不支持	已支持
环境变量	已支持	不支持	已支持
需要本地 root	是	否	否
如何使用	CLI Docker Desktop 扩展	CLI Docker Desktop 扩展	CLI Visual Studio Code 扩展 IntelliJ 插件

结论

Telepresence、Gefyra 和 mirrord 各自提供了独特的方法来简化 Kubernetes 开发周期，每个工具都有其优缺点。Telepresence 功能丰富但复杂，mirrord 提供无缝体验并支持各种功能，而 Gefyra 则追求简单和稳健。

你的选择应取决于项目的具体要求、团队对工具的熟悉程度以及所需的开发工作流。无论你选择哪个工具，我们相信本地 Kubernetes 开发方法都可以提供一种简单、有效和低成本的解决方案，来应对 Kubernetes 开发周期中的瓶颈，并且随着这些工具的不断创新和发展，这种本地方法将变得更加普遍。

Kubernetes 旧版软件包仓库将于 2023 年 9 月 13 日被冻结

Thu, 31 Aug 2023 15:30:00 -0700

作者：Bob Killen (Google), Chris Short (AWS), Jeremy Rickard (Microsoft), Marko Mudrinić (Kubermatic), Tim Bannister (The Scale Factory)

译者：Mengjiao Liu (DaoCloud)

2023 年 8 月 15 日，Kubernetes 项目宣布社区拥有的 Debian 和 RPM 软件包仓库在 pkgs.k8s.io 上正式提供。新的软件包仓库将取代旧的由 Google 托管的软件包仓库：apt.kubernetes.io 和 yum.kubernetes.io。 pkgs.k8s.io 的公告博客文章强调我们未来将停止将软件包发布到旧仓库。

今天，我们正式弃用旧软件包仓库（apt.kubernetes.io 和 yum.kubernetes.io），并且宣布我们计划在 2023 年 9 月 13 日 冻结仓库的内容。

请继续阅读以了解这对于作为用户或分发商的你意味着什么，以及你可能需要采取哪些步骤。

作为 Kubernetes 最终用户，这对我有何影响？

此更改影响直接安装 Kubernetes 的上游版本的用户，无论是按照官方手动安装和升级说明，还是通过使用 Kubernetes 安装工具，该安装工具使用 Kubernetes 项目提供的软件包。

如果你在自己的 PC 上运行 Linux 并使用旧软件包仓库安装了 kubectl，则此更改也会影响你。我们稍后将解释如何检查是否你会受到影响。

如果你使用完全托管的 Kubernetes，例如从云提供商获取服务，那么只有在你还使用旧仓库中的软件包在你的 Linux PC 上安装 kubectl 时，你才会受到此更改的影响。云提供商通常使用他们自己的 Kubernetes 发行版，因此他们不使用 Kubernetes 项目提供的软件包；更重要的是，如果有其他人为你管理 Kubernetes，那么他们通常会负责该检查。

如果你使用的是托管的控制平面但你负责自行管理节点，并且每个节点都运行 Linux，你应该检查你是否会受到影响。

如果你按照官方的安装和升级说明自己管理你的集群，请按照本博客文章中的说明迁移到（新的）社区拥有的软件包仓库。

如果你使用的 Kubernetes 安装程序使用 Kubernetes 项目提供的软件包，请检查安装程序工具的通信渠道，了解有关你需要采取的步骤的信息，最后如果需要，请与维护人员联系，让他们了解此更改。

下图以可视化形式显示了谁受到此更改的影响（单击图表可查看大图）：

这对我作为 Kubernetes 分发商有何影响？

如果你将旧仓库用作项目的一部分（例如 Kubernetes 安装程序工具），则应尽快迁移到社区拥有的仓库，并告知用户此更改以及他们需要采取哪些步骤。

变更时间表

2023 年 8 月 15 日：
Kubernetes 宣布推出一个新的社区管理的 Kubernetes 组件 Linux 软件包源
2023 年 8 月 31 日：
（本公告） Kubernetes 正式弃用旧版软件包仓库
2023 年 9 月 13 日（左右）：
Kubernetes 将冻结旧软件包仓库（apt.kubernetes.io 和 yum.kubernetes.io）。冻结将计划于 2023 年 9 月发布补丁版本后立即进行。

计划于 2023 年 9 月发布的 Kubernetes 补丁（v1.28.2、v1.27.6、v1.26.9、v1.25.14）将把软件包发布到社区拥有的仓库和旧仓库。

在发布 9 月份的补丁版本后，我们将冻结旧仓库，这意味着届时我们将完全停止向旧仓库发布软件包。

对于 2023 年 10 月及以后的 v1.28、v1.27、v1.26 和 v1.25 补丁版本，我们仅将软件包发布到新的软件包仓库 (pkgs.k8s.io)。

未来的次要版本怎么样？

Kubernetes 1.29 及以后的版本将仅发布软件包到社区拥有的仓库（pkgs.k8s.io）。

我可以继续使用旧软件包仓库吗？

旧仓库中的现有软件包将在可预见的未来内保持可用。然而， Kubernetes 项目无法对这会持续多久提供任何保证。已弃用的旧仓库及其内容可能会在未来随时删除，恕不另行通知。

更新: 旧版软件包预计将于 2024 年 1 月被删除。

Kubernetes 项目强烈建议尽快迁移到新的社区拥有的仓库。

鉴于在 2023 年 9 月 13 日截止时间点之后不会向旧仓库发布任何新版本， 你将无法升级到自该日期起发布的任何补丁或次要版本。

尽管该项目会尽一切努力发布安全软件，但有一天 Kubernetes 可能会出现一个高危性漏洞，因此需要升级到一个重要版本。我们所公开的建议将帮助你为未来的所有安全更新（无论是微不足道的还是紧急的）做好准备。

如何检查我是否正在使用旧仓库？

检查你是否使用旧仓库的步骤取决于你在集群中使用的是基于 Debian 的发行版（Debian、Ubuntu 等）还是基于 RPM 的发行版（CentOS、RHEL、Rocky Linux 等）。

在集群中的一个节点上运行以下指令。

基于 Debian 的 Linux 发行版

在基于 Debian 的发行版上，仓库定义（源）位于/etc/apt/sources.list 和 /etc/apt/sources.list.d/中。检查这两个位置并尝试找到如下所示的软件包仓库定义：

deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main

如果你发现像这样的仓库定义，则你正在使用旧仓库并且需要迁移。

如果仓库定义使用 pkgs.k8s.io，则你已经在使用社区托管的仓库，无需执行任何操作。

在大多数系统上，此仓库定义应位于 /etc/apt/sources.list.d/kubernetes.list （按照 Kubernetes 文档的建议），但在某些系统上它可能位于不同的位置。

如果你找不到与 Kubernetes 相关的仓库定义，则很可能你没有使用软件包管理器来安装 Kubernetes，因此不需要执行任何操作。

基于 RPM 的 Linux 发行版

如果你使用的是 yum 软件包管理器，则仓库定义位于 /etc/yum.repos.d，或者 /etc/dnf/dnf.conf 和 /etc/dnf/repos.d/ 如果你使用的是 dnf 软件包管理器。检查这些位置并尝试找到如下所示的软件包仓库定义：

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl

如果你发现像这样的仓库定义，则你正在使用旧仓库并且需要迁移。

如果仓库定义使用 pkgs.k8s.io，则你已经在使用社区托管的仓库，无需执行任何操作。

在大多数系统上，该仓库定义应位于 /etc/yum.repos.d/kubernetes.repo （按照 Kubernetes 文档的建议），但在某些系统上它可能位于不同的位置。

如果你找不到与 Kubernetes 相关的仓库定义，则很可能你没有使用软件包管理器来安装 Kubernetes，那么你不需要执行任何操作。

我如何迁移到新的社区运营的仓库？

有关如何迁移到新的社区管理软件包的更多信息，请参阅 pkgs.k8s.io的公告博客文章。

为什么 Kubernetes 项目要做出这样的改变？

自 Kubernetes v1.5 或过去七年以来，Kubernetes 一直只将软件包发布到 Google 托管的仓库！继迁移到社区管理的注册表 registry.k8s.io 之后，我们现在正在将 Kubernetes 软件包仓库迁移到我们自己的社区管理的基础设施。我们感谢 Google 这些年来持续的托管和支持，但这一转变标志着该项目迁移到完全由社区拥有的基础设施的目标的又一个重要里程碑。

有 Kubernetes 工具可以帮助我迁移吗？

关于迁移工具方面，我们目前没有任何公告。作为 Kubernetes 用户，你必须手动修改配置才能使用新仓库。自动从旧仓库迁移到社区拥有的仓库在技术上具有挑战性，我们希望避免与此相关的任何潜在风险。

致谢

首先，我们要感谢 Alphabet 的贡献。Google 的员工投入了他们的时间；作为一家企业，谷歌既提供了服务于软件包的基础设施，也提供了为这些软件包提供可信数字签名的安全上下文。这些对于 Kubernetes 的采用和成长非常重要。

发布软件可能并不那么引人注目，但很重要。Kubernetes 贡献者社区中的许多人都为我们作为一个项目构建和发布软件包的新方法做出了贡献。

最后，我们要再次感谢 SUSE 的帮助。SUSE 的 OpenBuildService 为新的社区管理的软件包仓库提供支持的技术。

Gateway API v0.8.0：引入服务网格支持

Tue, 29 Aug 2023 10:00:00 -0800

作者： Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google)

译者： Xin Li (Daocloud)

我们很高兴地宣布 Gateway API 的 v0.8.0 版本发布了！通过此版本，Gateway API 对服务网格的支持已达到实验性（Experimental）状态。我们期待你的反馈！

我们很高兴地宣布 Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都是 Gateway API 服务网格支持的完全一致实现。

Gateway API 中的服务网格支持

虽然 Gateway API 最初的重点一直是入站（南北）流量，但几乎从最开始就比较明确，相同的基本路由概念也应适用于服务网格（东西）流量。2022 年，Gateway API 子项目启动了 GAMMA 计划，这是一个专门的供应商中立的工作流，旨在专门研究如何最好地将服务网格支持纳入 Gateway API 资源的框架中，而不需要 Gateway API 的用户重新学习他们了解的有关 API 的一切。

在过去的一年中，GAMMA 深入研究了使用 Gateway API 用于服务网格的挑战和可能的解决方案。最终结果是少量的增强提案，其中包含了很长时间的思考和辩论，并提供允许使用 Gateway API 用于服务网格的最短可行路径。

当使用 Gateway API 时，网格路由将如何工作？

你可以在 Gateway API Mesh 路由文档和 GEP-1426 中找到所有详细信息，但对于 Gateway API v0.8.0 的简短的版本是现在 HTTPRoute 可以设置 parentRef，它是一个 Service，而不仅仅是一个网关。随着我们对服务网格用例的经验不断丰富，我们预计在这个领域会出现更多 GEP -- 绑定到 Service 使得将 Gateway API 与服务网格结合使用成为可能，但仍有几个有趣的用例难以覆盖。

例如，你可以使用 HTTPRoute 在网格中进行 A-B 测试，如下所示：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: demo-app
    port: 5000
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: v1
    backendRefs:
    - name: demo-app-v1
      port: 5000
  - backendRefs:
    - name: demo-app-v2
      port: 5000

任何对 demo-app Service 5000 端口且具有 env: v1 表头的请求都将被路由到 demo-app-v1，而没有该标头的请求都将被路由到 demo-app-v2 -- 并且由于这是由服务网格而不是 Ingress 控制器处理的，A/B 测试可以发生在应用程序的调用图中的任何位置。

如何确定这种方案的可移植性是真的？

Gateway API 一直在其支持的所有功能的一致性测试上投入大量资源，网格也不例外。 GAMMA 面临的挑战之一是，许多测试都认为一个给定实现会提供 Ingress 控制器。许多服务网格不提供 Ingress 控制器，要求符合 GAMMA 标准的网格同时实现 Ingress 控制器似乎并不切实际。这导致在 Gateway API 一致性配置文件的工作重新启动，如 GEP-1709 中所述。

一致性配置文件的基本思想是，我们可以定义 Gateway API 的子集，并允许实现选择（并记录）他们符合哪些子集。 GAMMA 正在添加一个名为 Mesh 的新配置文件，其描述在 GEP-1686 中，仅检查由 GAMMA 定义的网格功能。此时，Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都符合 Mesh 配置文件的标准。

Gateway API v0.8.0 中还有什么？

这个版本的发布都是为了即将到来的 v1.0 版本做准备，其中 HTTPRoute、Gateway 和 GatewayClass 将进级为 GA。与此相关的有两个主要更改： CEL 验证和 API 版本更改。

CEL 验证

第一个重大变化是，Gateway API v0.8.0 起从 Webhook 验证转向使用内置于 CRD 中的信息的 CEL 验证。取决于你使用的 Kubernetes 版本，这一转换的影响有些不同：

Kubernetes 1.25+

CEL 验证得到了完全支持，并且几乎所有验证都是在 CEL 中实现的。（唯一的例外是，标头修饰符过滤器中的标头名称只能进行不区分大小写的验证，更多的相关信息，请参见 issue 2277。）

我们建议在这些 Kubernetes 版本上不使用验证 Webhook。

Kubernetes 1.23 和 1.24

不支持 CEL 验证，但仍可以安装 Gateway API v0.8.0 CRD。当你升级到 Kubernetes 1.25+ 时，这些 CRD 中包含的验证将自动生效。

我们建议在这些 Kubernetes 版本上继续使用验证 Webhook。

Kubernetes 1.22 及更早版本

Gateway API 只承诺支持最新的 5 个 Kubernetes 版本。因此，Gateway API 不再支持这些版本，不幸的是，在这些集群版本中无法安装 Gateway API v0.8.0，因为包含 CEL 验证的 CRD 将被拒绝。

API 版本更改

在我们所准备的 v1.0 版本中，Gateway、GatewayClass 和 HTTPRoute 都会从 v1beta1 升级到 v1 API 版本，对于已升级到 v1beta1 的资源，我们将继续从 v1alpha2 迁移的过程。

有关此更改以及此版本中包含的所有其他内容的更多信息，请参见 v0.8.0 发布说明。

如何开始使用 Gateway API？

Gateway API 代表了 Kubernetes 中负载平衡、路由和服务网格 API 的未来。已经有超过 20 个实现可用（包括入口控制器和服务网格），而这一列表还在不断增长。

如果你有兴趣开始使用 Gateway API，请查阅 API 概念文档和一些指南以尝试使用它。因为这是一个基于 CRD 的 API，所以你可以在任何 Kubernetes 1.23+ 集群上安装最新版本。

如果你有兴趣为 Gateway API 做出贡献，我们非常欢迎你！请随时在仓库中报告问题，或加入讨论。另请查看社区页面，其中包含 Slack 频道和社区会议的链接。我们期待你的光临！！

进一步阅读：

GEP-1324 提供了 GAMMA 目标和一些重要定义的概述。这个 GEP 值得一读，因为它讨论了问题空间。
GEP-1426 定义了如何使用 Gateway API 路由资源（如 HTTPRoute）管理服务网格内的流量。
GEP-1686 在 GEP-1709 的工作基础上，为声明符合 Gateway API 的服务网格定义了一个一致性配置文件。

虽然这些都是实验特性，但请注意，它们可在 standard 发布频道使用，因为 GAMMA 计划迄今为止不需要引入新的资源或字段。

Kubernetes 1.28：用于改进集群安全升级的新（Alpha）机制

Mon, 28 Aug 2023 00:00:00 +0000

作者： Richa Banker (Google)

译者： Xin Li (DaoCloud)

本博客介绍了混合版本代理（Mixed Version Proxy），这是 Kubernetes 1.28 中的一个新的 Alpha 级别特性。当集群中存在多个不同版本的 API 服务器时，混合版本代理使对资源的 HTTP 请求能够被正确的 API 服务器处理。例如，在集群升级期间或当发布集群控制平面的运行时配置时此特性非常有用。

这解决了什么问题？

当集群进行升级时，集群中不同版本的 kube-apiserver 为不同的内置资源集（组、版本、资源）提供服务。在这种情况下资源请求如果由任一可用的 apiserver 提供服务，请求可能会到达无法解析此请求资源的 apiserver 中；因此，它会收到 404（"Not Found"）的响应报错，这是不正确的。此外，返回 404 的错误服务可能会导致严重的后果，例如命名空间的删除被错误阻止或资源对象被错误地回收。

如何解决此问题？

"混合版本代理"新特性为 kube-apiserver 提供了将请求代理到对等的、能够感知所请求的资源并因此能够服务请求的 kube-apiserver。为此，一个全新的过滤器已被添加到 API

处理程序链中的新过滤器检查请求是否为 apiserver 无法解析的 API 组/版本/资源（使用现有的 StorageVersion API）。如果是，它会将请求代理到 ServerStorageVersion 对象中列出的 apiserver 之一。如果所选的对等 apiserver 无法响应（由于网络连接、收到的请求与在 ServerStorageVersion 对象中注册 apiserver-resource 信息的控制器之间的竞争等原因），则会出现 503（"Service Unavailable"）错误响应。
为了防止无限期地代理请求，一旦最初的 API 服务器确定无法处理该请求，就会在原始请求中添加一个（v1.28 新增）HTTP 请求头 X-Kubernetes-APIServer-Rerouted: true。将其设置为 true 意味着原始 API 服务器无法处理该请求，需要对其进行代理。如果目标侧对等 API 服务器看到此标头，则不会对该请求做进一步的代理操作。
要设置 kube-apiserver 的网络位置，以供对等服务器来代理请求，将使用 --advertise-address 或（当未指定--advertise-address时）--bind-address 标志所设置的值。如果网络配置中不允许用户在对等 kube-apiserver 之间使用这些标志中指定的地址进行通信，可以选择将正确的对等地址配置在此特性引入的 --peer-advertise-ip 和 --peer-advertise-port 参数中。

如何启用此特性？

以下是启用此特性的步骤：

下载Kubernetes 项目的最新版本（版本 v1.28.0 或更高版本）
在 kube-apiserver 上使用命令行标志 --feature-gates=UnknownVersionInteroperabilityProxy=true 打开特性门控
使用 kube-apiserver 的 --peer-ca-file 参数为源 kube-apiserver 提供 CA 证书，用以验证目标 kube-apiserver 的服务证书。注意：这是此功能正常工作所必需的参数。此参数没有默认值。
为本地 kube-apiserver 设置正确的 IP 和端口，在代理请求时，对等方将使用该 IP 和端口连接到此 --peer-advertise-port 命令行参数来配置 kube-apiserver。 --peer-advertise-port 命令行参数。如果未设置这两个参数，则默认使用 --advertise-address 或 --bind-address 命令行参数的值。如果这些也未设置，则将使用主机的默认接口。

少了什么东西？

目前，我们仅在确定时将资源请求代理到对等 kube-apiserver。接下来我们需要解决如何在这种情况下处理发现请求。目前我们计划在测试版中提供以下特性：

合并所有 kube-apiserver 的发现数据
使用出口拨号器（egress dialer）与对等 kube-apiserver 进行网络连接

如何进一步了解？

阅读混合版本代理文档
阅读 KEP-4020：未知版本互操作代理

如何参与其中？

通过 Slack：#sig-api-machinery 或邮件列表联系我们。

非常感谢帮助设计、实施和评审此特性的贡献者： Daniel Smith、Han Kang、Joe Betz、Jordan Liggit、Antonio Ojea、David Eads 和 Ben Luddy！

Kubernetes v1.28：介绍原生边车容器

Fri, 25 Aug 2023 00:00:00 +0000

作者：Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)

本文介绍了如何使用新的边车（Sidecar）功能，该功能支持可重新启动的 Init 容器，并且在 Kubernetes 1.28 以 Alpha 版本发布。我们希望得到你的反馈，以便我们尽快完成此功能。

“边车”的概念几乎从一开始就是 Kubernetes 的一部分。在 2015 年，一篇关于复合容器的博客文章（英文）将边车描述为“扩展和增强 ‘main’ 容器”的附加容器。边车容器已成为一种常见的 Kubernetes 部署模式，通常用于网络代理或作为日志系统的一部分。到目前为止，边车已经成为 Kubernetes 用户在没有原生支持情况下使用的概念。缺乏原生支持导致了一些使用摩擦，此增强功能旨在解决这些问题。

在 Kubernetes 1.28 中的边车容器是什么？

Kubernetes 1.28 在 Init 容器中添加了一个新的 restartPolicy 字段，该字段在 SidecarContainers 特性门控启用时可用。

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: secret-fetch
    image: secret-fetch:1.0
  - name: network-proxy
    image: network-proxy:1.0
    restartPolicy: Always
  containers:
  ...

该字段是可选的，如果对其设置，则唯一有效的值为 Always。设置此字段会更改 Init 容器的行为，如下所示：

如果容器退出则会重新启动
任何后续的 Init 容器在 startupProbe 成功完成后立即启动，而不是等待可重新启动 Init 容器退出
由于可重新启动的 Init 容器资源现在添加到主容器的资源请求总和中，所以 Pod 使用的资源计算发生了变化。

Pod 终止继续仅依赖于主容器。 restartPolicy 为 Always 的 Init 容器（称为边车）不会阻止 Pod 在主容器退出后终止。

可重新启动的 Init 容器的以下属性使其非常适合边车部署模式：

无论你是否设置 restartPolicy，初始化容器都有一个明确定义的启动顺序，因此你可以确保你的边车在其所在清单中声明的后续任何容器之前启动。
边车容器不会延长 Pod 的生命周期，因此你可以在短生命周期的 Pod 中使用它们，而不会对 Pod 生命周期产生改变。
边车容器在退出时将被重新启动，这提高了弹性，并允许你使用边车来为主容器提供更可靠地服务。

何时要使用边车容器

你可能会发现内置边车容器对于以下工作负载很有用：

批量或 AI/ML 工作负载，或已运行完成的其他 Pod。这些工作负载将获得最显着的好处。
任何在清单中其他容器之前启动的网络代理。所有运行的其他容器都可以使用代理容器的服务。有关说明，请参阅在 Istio 中使用 Kubernetes 原生 Sidecar。
日志收集容器，现在可以在任何其他容器之前启动并运行直到 Pod 终止。这提高了 Pod 中日志收集的可靠性。
Job，可以将边车用于任何目的，而 Job 完成不会被正在运行的边车阻止。无需额外配置即可确保此行为。

1.28 之前用户如何获得 Sidecar 行为？

在边车功能出现之前，可以使用以下选项来根据边车容器的所需生命周期来实现边车行为：

边车的生命周期小于 Pod 生命周期：使用 Init 容器，它提供明确定义的启动顺序。然而，边车必须退出才能让其他 Init 容器和主 Pod 容器启动。
边车的生命周期等于 Pod 生命周期：使用与 Pod 中的工作负载容器一起运行的主容器。此方法无法让你控制启动顺序，并让边车容器可能会在工作负载容器退出后阻止 Pod 终止。

内置的边车功能解决了其生命周期与 Pod 生命周期相同的用例，并具有以下额外优势：

提供对启动顺序的控制
不阻碍 Pod 终止

将现有边车过渡到新模式

我们建议仅在 Alpha 阶段的短期测试集群中使用边车功能。如果你有一个现有的边车，被配置为主容器，以便它可以在 Pod 的生命周期内运行，则可以将其移至 Pod 规范的 initContainers 部分，并将 restartPolicy 指定为 Always。在许多情况下，边车应该像以前一样工作，并具有定义启动顺序且不会延长 Pod 生命周期的额外好处。

已知问题

内置边车容器的 Alpha 版本具有以下已知问题，我们将在该功能升级为 Beta 之前解决这些问题：

CPU、内存、设备和拓扑管理器不知道边车容器的生命周期和额外的资源使用情况，并且会像 Pod 的资源请求低于实际情况的方式运行。
使用边车时，kubectl describe node 的输出不正确。输出显示的资源使用量低于实际使用量，因为它没有对边车容器使用新的资源使用计算方式。

我们需要你的反馈！

在 Alpha 阶段，我们希望你在环境中尝试边车容器，并在遇到错误或摩擦点时提出问题。我们对以下方面的反馈特别感兴趣：

关闭顺序，尤其是多个边车运行时
碰撞边车的退避超时调整
边车运行时 Pod 就绪性和活性探测的行为

要提出问题，请参阅 Kubernetes GitHub 存储库。

接下来是什么？

除了将要解决的已知问题之外，我们正在努力为边车和主容器添加终止顺序。这将确保边车容器仅在 Pod 主容器退出后终止。

我们很高兴看到 Kubernetes 引入了边车功能，并期望得到反馈。

致谢

自从最初的 KEP 编写以来已经过去了很多年，因此如果我们遗漏了多年来致力于此功能的任何人，我们将深表歉意。这也是识别该功能参与者的最大限度努力。

mrunalp 对于设计的探讨和评论
thockin 多年来对于 API 的讨论和支持
bobbypage 的审查工作
smarterclayton 进行详细审查和反馈
howardjohn 多年来进行的反馈以及在实施过程中的早期尝试
derekwaynecarr 和 dchen1107 的领导力
jpbetz 对 API 和终止排序的设计以及代码审查
Joseph-Irving 和 rata 对于多年前的早期迭代设计和审查
swatisehgal 和 ffromani 对于有关资源管理器影响的早期反馈
alculquicondor 对于解决调度程序版本偏差的相关反馈
wojtek-t 对于 KEP 的 PRR 进行审查
ahg-g 对于 KEP 的调度程序部分进行审查
adisky 处理了 Job 完成问题

Kubernetes 1.28：在 Linux 上使用交换内存的 Beta 支持

Thu, 24 Aug 2023 10:00:00 -0800

作者：Itamar Holder (Red Hat)

译者：Wilson Wu (DaoCloud)

Kubernetes 1.22 版本为交换内存引入了一项 Alpha 支持，用于为在 Linux 节点上运行的 Kubernetes 工作负载逐个节点地配置交换内存使用。现在，在 1.28 版中，对 Linux 节点上的交换内存的支持已升级为 Beta 版，并有许多新的改进。

在 1.22 版之前，Kubernetes 不提供对 Linux 系统上交换内存的支持。这是由于在涉及交换内存时保证和计算 Pod 内存利用率的固有困难。因此，交换内存支持被认为超出了 Kubernetes 的初始设计范围，并且如果在节点上检测到交换内存， kubelet 的默认行为是无法启动。

在 1.22 版中，Linux 的交换特性以 Alpha 阶段初次引入。这代表着一项重大进步，首次为 Linux 用户提供了尝试交换内存特性的机会。然而，作为 Alpha 版本，它尚未开发完成，并存在一些问题，包括对 cgroup v2 支持的不足、指标和 API 统计摘要不足、测试不足等等。

Kubernetes 中的交换内存有许多用例，并适用于大量用户。因此，Kubernetes 项目内的节点特别兴趣小组投入了大量精力来支持 Linux 节点上的交换内存特性的 Beta 版本。与 Alpha 版本相比，启用交换内存后 kubelet 的运行更加稳定和健壮，更加用户友好，并且解决了许多已知缺陷。这次升级到 Beta 版代表朝着实现在 Kubernetes 中完全支持交换内存的目标迈出了关键一步。

如何使用此特性？

通过激活 kubelet 上的 NodeSwap 特性门控，可以在已配置交换内存的节点上使用此特性。此外，你必须禁用 failSwapOn 设置，或者停用已被弃用的 --fail-swap-on 命令行标志。

可以配置 memorySwap.swapBehavior 选项来定义节点使用交换内存的方式。例如：

# 将此段内容放入 kubelet 配置文件
memorySwap:
  swapBehavior: UnlimitedSwap

swapBehavior 的可用配置选项有：

UnlimitedSwap（默认）：Kubernetes 工作负载可以根据请求使用尽可能多的交换内存，最多可达到系统限制。
LimitedSwap：Kubernetes 工作负载对交换内存的使用受到限制。只有 Burstable QoS Pod 才允许使用交换内存。

如果未指定 memorySwap 的配置并且启用了特性门控，则默认情况下， kubelet 将应用与 UnlimitedSwap 设置相同的行为。

请注意，仅 cgroup v2 支持 NodeSwap。针对 Kubernetes v1.28，不再支持将交换内存与 cgroup v1 一起使用。

使用 kubeadm 安装支持交换内存的集群

开始之前

此演示需要安装 kubeadm 工具，安装过程按照 kubeadm 安装指南中描述的步骤进行操作。如果节点上已启用交换内存，则可以继续创建集群。如果未启用交换内存，请参阅提供的启用交换内存说明。

创建交换内存文件并开启交换内存功能

我将演示创建 4GiB 的未加密交换内存。

dd if=/dev/zero of=/swapfile bs=128M count=32
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon -s # 仅在该节点被重新启动后启用该交换内存文件

要在引导时启动交换内存文件，请将诸如 /swapfile swap swap defaults 0 0 的内容添加到 /etc/fstab 文件中。

在 Kubernetes 集群中设置开启交换内存的节点

清晰起见，这里给出启用交换内存特性的集群的 kubeadm 配置文件示例 kubeadm-config.yaml。

---
apiVersion: "kubeadm.k8s.io/v1beta3"
kind: InitConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
featureGates:
  NodeSwap: true
memorySwap:
  swapBehavior: LimitedSwap

接下来使用 kubeadm init --config kubeadm-config.yaml 创建单节点集群。在初始化过程中，如果 kubelet failSwapOn 设置为 true，则会出现一条警告，告知节点上启用了交换内存特性。我们计划在未来的版本中删除此警告。

如何通过 LimitedSwap 确定交换内存限额？

交换内存的配置（包括其局限性）是一项挑战。不仅容易出现配置错误，而且作为系统级属性，任何错误配置都可能危及整个节点而不仅仅是特定的工作负载。为了减轻这种风险并确保节点的健康，我们在交换内存的 Beta 版本中实现了对缺陷的自动配置。

使用 LimitedSwap，不属于 Burstable QoS 类别的 Pod（即 BestEffort/Guaranteed QoS Pod）被禁止使用交换内存。 BestEffort QoS Pod 表现出不可预测的内存消耗模式，并且缺乏有关其内存使用情况的信息，因此很难完成交换内存的安全分配。相反，Guaranteed QoS Pod 通常用于根据工作负载的设置精确分配资源的应用，其中的内存资源立即可用。为了维持上述安全和节点健康保证，当 LimitedSwap 生效时，这些 Pod 将不允许使用交换内存。

在详细计算交换内存限制之前，有必要定义以下术语：

nodeTotalMemory：节点上可用的物理内存总量。
totalPodsSwapAvailable：节点上可供 Pod 使用的交换内存总量（可以保留一些交换内存供系统使用）。
containerMemoryRequest：容器的内存请求。

交换内存限制配置为：(containerMemoryRequest / nodeTotalMemory) × totalPodsSwapAvailable

换句话说，容器能够使用的交换内存量与其内存请求、节点的总物理内存以及节点上可供 Pod 使用的交换内存总量呈比例关系。

值得注意的是，对于 Burstable QoS Pod 中的容器，可以通过设置内存限制与内存请求相同来选择不使用交换内存。以这种方式配置的容器将无法访问交换内存。

此特性如何工作？

我们可以想象可以在节点上使用交换内存的多种可能方式。当节点上提供了交换内存并可用时， SIG 节点建议 kubelet 应该能够遵循如下的配置：

在交换内存特性被启用时能够启动。
默认情况下，kubelet 将指示容器运行时接口（CRI）不为 Kubernetes 工作负载分配交换内存。

节点上的交换内存配置通过 KubeletConfiguration 中的 memorySwap 向集群管理员公开。作为集群管理员，你可以通过设置 memorySwap.swapBehavior 来指定存在交换内存时节点的行为。

kubelet 使用 CRI （容器运行时接口）API 来指示 CRI 配置特定的 cgroup v2 参数（例如 memory.swap.max），配置方式要支持容器所期望的交换内存配置。接下来，CRI 负责将这些设置写入容器级的 cgroup。

如何对交换内存进行监控？

Alpha 版本的一个显著缺陷是无法监控或检视交换内存的使用情况。这个问题已在 Kubernetes 1.28 引入的 Beta 版本中得到解决，该版本现在提供了通过多种不同方法监控交换内存使用情况的能力。

kubelet 的 Beta 版本现在支持收集节点级指标统计信息，可以通过 /metrics/resource 和 /stats/summary kubelet HTTP 端点进行访问。这些信息使得客户端能够在使用 LimitedSwap 时直接访问 kubelet 来监控交换内存使用情况和剩余交换内存情况。此外，cadvisor 中还添加了 machine_swap_bytes 指标，以显示机器上总的物理交换内存容量。

注意事项

在系统上提供可用交换内存会降低可预测性。由于交换内存的性能比常规内存差，有时差距甚至在多个数量级，因而可能会导致意外的性能下降。此外，交换内存会改变系统在内存压力下的行为。由于启用交换内存允许 Kubernetes 中的工作负载使用更大的内存量，而这一用量是无法预测的，因此也会增加嘈杂邻居和非预期的装箱配置的风险，因为调度程序无法考虑交换内存使用情况。

启用交换内存的节点的性能取决于底层物理存储。当使用交换内存时，与固态硬盘或 NVMe 等更较快的存储介质相比，在每秒 I/O 操作数（IOPS）受限的环境（例如具有 I/O 限制的云虚拟机）中，性能会明显变差。

因此，我们不提倡针对有性能约束的工作负载或环境使用交换内存。此外，建议使用 LimitedSwap，因为这可以显著减轻给节点带来的风险。

集群管理员和开发人员应该在生产场景中使用交换内存之前对其节点和应用进行基准测试，我们需要你的帮助！

安全风险

在没有加密的系统上启用交换内存会带来安全风险，因为关键信息（例如代表 Kubernetes Secret 的卷）可能会被交换到磁盘。如果未经授权的个人访问磁盘，他们就有可能获得这些机密数据。为了减轻这种风险， Kubernetes 项目强烈建议你对交换内存空间进行加密。但是，处理加密交换内存不是 kubelet 的责任；相反，它其实是操作系统配置通用问题，应在该级别解决。管理员有责任提供加密交换内存来减轻这种风险。

此外，如前所述，启用 LimitedSwap 模式时，用户可以选择通过设置内存限制与内存请求相同来完全禁止容器使用交换内存。这种设置会阻止相应的容器访问交换内存。

展望未来

Kubernetes 1.28 版本引入了对 Linux 节点上交换内存的 Beta 支持，我们将继续为这项特性的正式发布而努力。我希望这将包括：

添加根据 kubelet 在主机上检测到的内容来设置系统预留交换内存量的功能。
添加对通过 cgroup 在 Pod 级别控制交换内存用量的支持。
- 这一点仍在讨论中。
收集测试用例的反馈。
- 我们将考虑引入新的交换内存配置模式，例如在节点层面为工作负载设置交换内存限制。

如果进一步学习？

你可以查看当前文档以了解如何在 Kubernetes 中使用交换内存。

如需了解更多信息，以及协助测试和提供反馈，请参阅 KEP-2400 及其设计提案。

参与其中

随时欢迎你的反馈！SIG Node 定期举行会议并可以通过 Slack（#sig-node 频道）或 SIG 的邮件列表进行联系。 Slack 还提供了专门讨论交换内存的 #sig-node-swap 频道。

如果你想提供帮助或提出进一步的问题，请随时联系 Itamar Holder（Slack 和 GitHub 账号为 @iholder101）。

Kubernetes 1.28：节点 podresources API 正式发布

Wed, 23 Aug 2023 00:00:00 +0000

作者：Francesco Romani (Red Hat)

译者：Wilson Wu (DaoCloud)

podresources API 是由 kubelet 提供的节点本地 API，它用于公开专门分配给容器的计算资源。随着 Kubernetes 1.28 的发布，该 API 现已正式发布。

它解决了什么问题？

kubelet 可以向容器分配独占资源，例如 CPU，授予对完整核心的独占访问权限或内存，包括内存区域或巨页。需要高性能或低延迟（或者两者都需要）的工作负载可以利用这些特性。 kubelet 还可以将设备分配给容器。总的来说，这些支持独占分配的特性被称为“资源管理器（Resource Managers）”。

如果没有像 podresources 这样的 API，了解资源分配的唯一可能选择就是读取资源管理器使用的状态文件。虽然这样做是出于必要，但这种方法的问题是这些文件的路径和格式都是内部实现细节。尽管非常稳定，但项目保留自由更改它们的权利。因此，使用状态文件内容的做法是不可靠的且不受支持的，建议这样做的项目考虑迁移到使用 podresources API 或其他受支持的 API。

API 概述

podresources API 最初被提出是为了实现设备监控。为了支持监控代理，一个关键的先决条件是启用由 kubelet 执行的设备分配自省（Introspection）。 API 的最初目标就是服务于此目的。API 的第一次迭代仅实现了一个函数 List，用于返回有关设备分配给容器的信息。该 API 由 multus CNI 和 GPU 监控工具使用。

自推出以来，podresources API 扩大了其范围，涵盖了设备管理器之外的其他资源管理器。从 Kubernetes 1.20 开始，List API 还报告 CPU 核心和内存区域（包括巨页）；在能够从系统中推断 CPU 和内存的位置时，API 还报告设备的 NUMA 位置。

在 Kubernetes 1.21 中，API 增加了 GetAllocatableResources 函数。这个较新的 API 补充了现有的 List API，并使监控代理能够辨识尚未分配的资源，从而支持在 podresources API 之上构建新的特性，例如 NUMA 感知的调度器插件。

最后，在 Kubernetes 1.27 中，引入了另一个函数 Get，以便对 CNI 元插件（Meta-Plugins）更加友好，简化对已分配给特定 Pod 的资源的访问，而不必过滤节点上所有 Pod 的资源。Get 函数目前处于 Alpha 级别。

使用 API

podresources API 由本地 kubelet 提供，位于 kubelet 运行所在的同一节点上。在 Unix 风格的系统上，通过 Unix 域套接字提供端点；默认路径是 /var/lib/kubelet/pod-resources/kubelet.sock。在 Windows 上，通过命名管道提供端点；默认路径是 npipe://\\.\pipe\kubelet-pod-resources。

为了让容器化监控应用使用 API，套接字应挂载到容器内。一个好的做法是挂载 podresources 套接字端点所在的目录，而不是直接挂载套接字。这种做法将确保 kubelet 重新启动后，容器化监视器应用能够重新连接到套接字。

在下面的 DaemonSet 示例清单中，包含一个假想的使用 podresources API 的监控代理：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: podresources-monitoring-app
  namespace: monitoring
spec:
  selector:
    matchLabels:
      name: podresources-monitoring
  template:
    metadata:
      labels:
        name: podresources-monitoring
    spec:
      containers:
      - args:
        - --podresources-socket=unix:///host-podresources/kubelet.sock
        command:
        - /bin/podresources-monitor
        image: podresources-monitor:latest  # 仅作为样例
        volumeMounts:
        - mountPath: /host-podresources
          name: host-podresources
      serviceAccountName: podresources-monitor
      volumes:
      - hostPath:
          path: /var/lib/kubelet/pod-resources
          type: Directory
        name: host-podresources

我希望你发现以编程方式使用 podresources API 很简单。kubelet API包提供了协议文件和 Go 类型定义；但是，该项目尚未提供客户端包，并且你也不应直接使用现有代码。推荐方法是在你自己的项目中重新实现客户端，复制并粘贴相关功能，就像 multus 项目所做的那样。

在操作使用 podresources API 的容器化监控应用程序时，有几点值得强调，以防止出现“陷阱”：

尽管 API 仅公开数据，并且设计上不允许客户端改变 kubelet 状态，但 gRPC 请求/响应模型要求能对 podresources API 套接字进行读写访问。换句话说，将容器挂载限制为 ReadOnly 是不可能的。
让多个客户端连接到 podresources 套接字并使用此 API 是允许的，因为 API 是无状态的。
kubelet 具有内置限速机制，用以缓解来自行为不当或恶意用户的本地拒绝服务攻击。API 的使用者必须容忍服务器返回的速率限制错误。速率限制目前是硬编码的且作用于全局的，因此行为不当的客户端可能会耗光所有配额，进而导致行为正确的客户端挨饿。

未来的增强

由于历史原因，podresources API 的规范不如典型的 kubernetes API（例如 Kubernetes HTTP API 或容器运行时接口）精确。这会导致在极端情况下出现未指定的行为。我们正在努力纠正这种状态并制定更精确的规范。

动态资源分配（DRA）基础设施是对资源管理的重大改革。与 podresources API 的集成已经在进行中。

我们正在努力推荐或创建可供使用的参考客户端包。

参与其中

此功能由 SIG Node 驱动。请加入我们，与社区建立联系，并分享你对上述功能及其他功能的想法和反馈。我们期待你的回音！

Kubernetes 1.28：Job 失效处理的改进

Mon, 21 Aug 2023 00:00:00 +0000

作者： Kevin Hannon (G-Research), Michał Woźniak (Google)

译者： Xin Li (Daocloud)

本博客讨论 Kubernetes 1.28 中的两个新特性，用于为批处理用户改进 Job： Pod 更换策略和基于索引的回退限制。

这些特性延续了 Pod 失效策略为开端的工作，用来改进对 Job 中 Pod 失效的处理。

Pod 更换策略

默认情况下，当 Pod 进入终止（Terminating）状态（例如由于抢占或驱逐机制）时，Kubernetes 会立即创建一个替换的 Pod，因此这时会有两个 Pod 同时运行。就 API 而言，当 Pod 具有 deletionTimestamp 字段并且处于 Pending 或 Running 阶段时会被视为终止。

对于一些流行的机器学习框架来说，在给定时间运行两个 Pod 的情况是有问题的，例如 TensorFlow 和 JAX，对于给定的索引，它们最多同时运行一个 Pod。如果两个 Pod 使用同一个索引来运行， Tensorflow 会抛出以下错误：

 /job:worker/task:4: Duplicate task registration with task_name=/job:worker/replica:0/task:4

可参考问题报告进一步了解细节。

在前一个 Pod 完全终止之前创建替换的 Pod 也可能会导致资源或预算紧张的集群出现问题，例如：

对于待调度的 Pod 来说，很难分配到集群资源，导致 Kubernetes 需要很长时间才能找到可用节点，直到现有 Pod 完全终止。
如果启用了集群自动扩缩器（Cluster Autoscaler），可能会产生不必要的集群规模扩增。

如何使用？

这是一项 Alpha 级别特性，你可以通过在集群中启用 JobPodReplacementPolicy 特性门控来启用该特性。

kind: Job
metadata:
  name: new
  ...
spec:
  podReplacementPolicy: Failed
  ...

在此 Job 中，Pod 仅在达到 Failed 阶段时才会被替换，而不是在它们处于终止过程中（Terminating）时被替换。

此外，你可以检查 Job 的 .status.termination 字段。该字段的值表示终止过程中的 Job 所关联的 Pod 数量。

kubectl get jobs/myjob -o=jsonpath='{.items[*].status.terminating}'

3 # three Pods are terminating and have not yet reached the Failed phase

这一特性对于外部排队控制器（例如 Kueue）特别有用，它跟踪作业的运行 Pod 的配额，直到从当前终止过程中的 Job 资源被回收为止。

请注意，使用自定义 Pod 失败策略时， podReplacementPolicy: Failed 是默认值。

逐索引的回退限制

默认情况下，带索引的 Job（Indexed Job）的 Pod 失败情况会被统计下来，受 .spec.backoffLimit 字段所设置的全局重试次数限制。这意味着，如果存在某个索引值的 Pod 一直持续失败，则会 Pod 会被重新启动，直到重试次数达到限制值。一旦达到限制值，整个 Job 将被标记为失败，并且对应某些索引的 Pod 甚至可能从不曾被启动。

对于你想要独立处理不同索引值的 Pod 的失败的场景而言，这是有问题的。例如，如果你使用带索引的 Job（Indexed Job）来运行集成测试，其中每个索引值对应一个测试套件。在这种情况下，你可能需要考虑可能发生的脆弱测试（Flake Test），允许每个套件重试 1 次或 2 次。可能存在一些有缺陷的套件，导致对应索引的 Pod 始终失败。在这种情况下，你或许更希望限制有问题的套件的重试，而允许其他套件完成。

此特性允许你：

尽管某些索引值的 Pod 失败，但仍完成执行所有索引值的 Pod。
通过避免对持续失败的、特定索引值的 Pod 进行不必要的重试，更好地利用计算资源。

可以如何使用它？

这是一个 Alpha 特性，你可以通过启用集群的 JobBackoffLimitPerIndex 特性门控来启用此特性。

在集群中启用该特性后，你可以在创建带索引的 Job（Indexed Job）时指定 .spec.backoffLimitPerIndex 字段。

示例

下面的示例演示如何使用此功能来确保 Job 执行所有索引值的 Pod（前提是没有其他原因导致 Job 提前终止，例如达到 activeDeadlineSeconds 超时，或者被用户手动删除），以及按索引控制失败次数。

apiVersion: batch/v1
kind: Job
metadata:
  name: job-backoff-limit-per-index-execute-all
spec:
  completions: 8
  parallelism: 2
  completionMode: Indexed
  backoffLimitPerIndex: 1
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: example # 当此示例容器作为任何 Job 中的第二个或第三个索引运行时（即使在重试之后），它会返回错误并失败
        image: python
        command:
        - python3
        - -c
        - |
          import os, sys, time
          id = int(os.environ.get("JOB_COMPLETION_INDEX"))
          if id == 1 or id == 2:
            sys.exit(1)
          time.sleep(1)

现在，在 Job 完成后检查 Pod：

kubectl get pods -l job-name=job-backoff-limit-per-index-execute-all

返回的输出类似与：

NAME                                              READY   STATUS      RESTARTS   AGE
job-backoff-limit-per-index-execute-all-0-b26vc   0/1     Completed   0          49s
job-backoff-limit-per-index-execute-all-1-6j5gd   0/1     Error       0          49s
job-backoff-limit-per-index-execute-all-1-6wd82   0/1     Error       0          37s
job-backoff-limit-per-index-execute-all-2-c66hg   0/1     Error       0          32s
job-backoff-limit-per-index-execute-all-2-nf982   0/1     Error       0          43s
job-backoff-limit-per-index-execute-all-3-cxmhf   0/1     Completed   0          33s
job-backoff-limit-per-index-execute-all-4-9q6kq   0/1     Completed   0          28s
job-backoff-limit-per-index-execute-all-5-z9hqf   0/1     Completed   0          28s
job-backoff-limit-per-index-execute-all-6-tbkr8   0/1     Completed   0          23s
job-backoff-limit-per-index-execute-all-7-hxjsq   0/1     Completed   0          22s

此外，你可以查看该 Job 的状态：

kubectl get jobs job-backoff-limit-per-index-fail-index -o yaml

输出内容以 status 结尾，类似于：

  status:
    completedIndexes: 0,3-7
    failedIndexes: 1,2
    succeeded: 6
    failed: 4
    conditions:
    - message: Job has failed indexes
      reason: FailedIndexes
      status: "True"
      type: Failed

这里，索引为 1 和 2 的 Pod 都被重试了一次。这两个 Pod 在第二次失败后都超出了指定的 .spec.backoffLimitPerIndex，因此停止重试。相比之下，如果禁用了基于索引的回退，那么有问题的、特定索引的 Pod 将被重试，直到超出全局 backoffLimit，之后在启动一些索引值较高的 Pod 之前，整个 Job 将被标记为失败。

如何进一步了解

阅读面向用户的 Pod 替换策略文档、逐索引的回退限制和 Pod 失效策略
阅读 Pod 替换策略)、逐索引的回退限制和 Pod 失效策略的 KEP。

参与其中

这些功能由 SIG Apps 赞助。社区正在为批处理工作组中的 Kubernetes 用户积极改进批处理场景。工作组是相对短暂的举措，专注于特定目标。WG Batch 的目标是改善批处理工作负载的用户体验、提供对批处理场景的支持并增强常见场景下的 Job API。如果你对此感兴趣，请通过订阅我们的邮件列表或通过 Slack 加入进来。

致谢

与其他 Kubernetes 特性一样，从测试、报告缺陷到代码审查，很多人为此特性做出了贡献。

如果没有 Aldo Culquicondor（Google）提供出色的领域知识和跨整个 Kubernetes 生态系统的知识，我们可能无法实现这些特性。

Kubernetes v1.28：可追溯的默认 StorageClass 进阶至 GA

Fri, 18 Aug 2023 00:00:00 +0000

作者: Roman Bednář (Red Hat)

译者: Michael Yao (DaoCloud)

可追溯的默认 StorageClass 赋值（Retroactive Default StorageClass Assignment）在 Kubernetes v1.28 中宣布进阶至正式发布（GA）！

Kubernetes SIG Storage 团队非常高兴地宣布，在 Kubernetes v1.25 中作为 Alpha 特性引入的 “可追溯默认 StorageClass 赋值” 现已进阶至 GA，并正式成为 Kubernetes v1.28 发行版的一部分。这项增强特性极大地改进了默认的 StorageClasses 为 PersistentVolumeClaim (PVC) 赋值的方式。

启用此特性后，你不再需要先创建默认的 StorageClass，再创建 PVC 来指定存储类。现在，未分配 StorageClass 的所有 PVC 都将被自动更新为包含默认的 StorageClass。此项增强特性确保即使默认的 StorageClass 在 PVC 创建时未被定义， PVC 也不会再滞留在未绑定状态，存储制备工作可以无缝进行。

有什么变化？

PersistentVolume (PV) 控制器已修改为：当未设置 storageClassName 时，自动向任何未绑定的 PersistentVolumeClaim 分配一个默认的 StorageClass。此外，API 服务器中的 PersistentVolumeClaim 准入验证机制也已调整为允许将值从未设置状态更改为实际的 StorageClass 名称。

如何使用？

由于此特性已进阶至 GA，所以不再需要启用特性门控。只需确保你运行的是 Kubernetes v1.28 或更高版本，此特性即可供使用。

有关更多细节，可以查阅 Kubernetes 文档中的默认 StorageClass 赋值。你也可以阅读以前在 v1.26 中宣布进阶至 Beta 的博客文章。

要提供反馈，请加入我们的 Kubernetes 存储特别兴趣小组 (SIG) 或参与公共 Slack 频道上的讨论。

Kubernetes 1.28: 节点非体面关闭进入 GA 阶段（正式发布）

Wed, 16 Aug 2023 10:00:00 -0800

作者： Xing Yang (VMware) 和 Ashutosh Kumar (Elastic)

译者： Xin Li (Daocloud)

Kubernetes 节点非体面关闭特性现已在 Kubernetes v1.28 中正式发布。

此特性在 Kubernetes v1.24 中作为 Alpha 特性引入，并在 Kubernetes v1.26 中转入 Beta 阶段。如果原始节点意外关闭或最终处于不可恢复状态（例如硬件故障或操作系统无响应），此特性允许有状态工作负载在不同节点上重新启动。

什么是节点非体面关闭

在 Kubernetes 集群中，节点可能会按计划正常关闭，也可能由于断电或其他外部原因而意外关闭。如果节点在关闭之前未腾空，则节点关闭可能会导致工作负载失败。节点关闭可以是正常关闭，也可以是非正常关闭。

节点体面关闭特性允许 kubelet 在实际关闭之前检测节点关闭事件、正确终止该节点上的 Pod 并释放资源。

当节点关闭但 kubelet 的节点关闭管理器未检测到时，将造成节点非体面关闭。对于无状态应用程序来说，节点非体面关闭通常不是问题，但是对于有状态应用程序来说，这是一个问题。如果 Pod 停留在关闭节点上并且未在正在运行的节点上重新启动，则有状态应用程序将无法正常运行。

在节点非体面关闭的情况下，你可以在 Node 上手动添加 out-of-service 污点。

kubectl taint nodes <node-name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute

如果 Pod 上没有与之匹配的容忍规则，则此污点会触发节点上的 Pod 被强制删除。挂接到关闭中的节点的持久卷将被解除挂接，新的 Pod 将在不同的运行节点上成功创建。

注意： 在应用 out-of-service 污点之前，你必须验证节点是否已经处于关闭或断电状态（而不是在重新启动中）。

与 out-of-service 节点有关联的所有工作负载的 Pod 都被移动到新的运行节点，并且所关闭的节点已恢复之后，你应该删除受影响节点上的污点。

稳定版中有哪些新内容

随着非正常节点关闭功能提升到稳定状态，特性门控 NodeOutOfServiceVolumeDetach 在 kube-controller-manager 上被锁定为 true，并且无法禁用。

Pod GC 控制器中的指标 force_delete_pods_total 和 force_delete_pod_errors_total 得到增强，以考虑所有 Pod 的强制删除情况。指标中会添加一个 "reason"，以指示 Pod 是否因终止、孤儿、因 out-of-service 污点而终止或因未计划终止而被强制删除。

Attach Detach Controller 中的指标 attachdetach_controller_forced_detaches 中还会添加一个 "reason"，以指示强制解除挂接是由 out-of-service 污点还是超时引起的。

接下来

此特性要求用户手动向节点添加污点以触发工作负载故障转移，并在节点恢复后删除污点。未来，我们计划找到方法来自动检测和隔离关闭/失败的节点，并自动将工作负载故障转移到另一个节点。

如何了解更多？

在此处可以查看有关此特性的其他文档。

我们非常感谢所有帮助设计、实现和审查此功能并帮助其从 Alpha、Beta 到稳定版的贡献者：

Michelle Au (msau42)
Derek Carr (derekwaynecarr)
Danielle Endocrimes (endocrimes)
Baofa Fan (carlory)
Tim Hockin (thockin)
Ashutosh Kumar (sonasingh46)
Hemant Kumar (gnufied)
Yuiko Mouri (YuikoTakada)
Mrunal Patel (mrunalp)
David Porter (bobbypage)
Yassine Tijani (yastij)
Jing Xu (jingxu97)
Xing Yang (xing-yang)

此特性是 SIG Storage 和 SIG Node 之间的协作。对于那些有兴趣参与 Kubernetes 存储系统任何部分的设计和开发的人，请加入 Kubernetes 存储特别兴趣小组（SIG）。对于那些有兴趣参与支持 Pod 和主机资源之间受控交互的组件的设计和开发，请加入 Kubernetes Node SIG。

pkgs.k8s.io：介绍 Kubernetes 社区自有的包仓库

Tue, 15 Aug 2023 20:00:00 +0000

作者：Marko Mudrinić (Kubermatic)

译者：Wilson Wu (DaoCloud)

我很高兴代表 Kubernetes SIG Release 介绍 Kubernetes 社区自有的 Debian 和 RPM 软件仓库：pkgs.k8s.io！这些全新的仓库取代了我们自 Kubernetes v1.5 以来一直使用的托管在 Google 的仓库（apt.kubernetes.io 和 yum.kubernetes.io）。

这篇博文包含关于这些新的包仓库的信息、它对最终用户意味着什么以及如何迁移到新仓库。

ℹ️ 更新（2023 年 8 月 31 日）：旧版托管在 Google 的仓库已被弃用，并将于 2023 年 9 月 13 日开始被冻结。 查看弃用公告了解有关此更改的更多详细信息。

关于新的包仓库，你需要了解哪些信息？

（更新于 2023 年 8 月 31 日）

这是一个明确同意的更改；你需要手动从托管在 Google 的仓库迁移到 Kubernetes 社区自有的仓库。请参阅本公告后面的如何迁移，了解迁移信息和说明。

旧版托管在 Google 的仓库自 2023 年 8 月 31 日起被弃用，并将于 2023 年 9 月 13 日左右被冻结。冻结将在计划于 2023 年 9 月发布补丁之后立即发生。冻结旧仓库意味着我们在 2023 年 9 月 13 日这个时间点之后仅将 Kubernetes 项目的包发布到社区自有的仓库。有关此更改的更多详细信息，请查看弃用公告。

旧仓库中的现有包将在可预见的未来一段时间内可用。然而，Kubernetes 项目无法保证这会持续多久。已弃用的旧仓库及其内容可能会在未来随时被删除，恕不另行通知。

鉴于在 2023 年 9 月 13 日这个截止时间点之后不会向旧仓库发布任何新版本，如果你不在该截止时间点迁移至新的 Kubernetes 仓库，你将无法升级到该日期之后发布的任何补丁或次要版本。也就是说，我们建议尽快迁移到新的 Kubernetes 仓库。

新的 Kubernetes 仓库中包含社区开始接管包构建以来仍在支持的 Kubernetes 版本的包。这意味着 v1.24.0 之前的任何内容都只存在于托管在 Google 的仓库中。

每个 Kubernetes 次要版本都有一个专用的仓库。当升级到不同的次要版本时，你必须记住，仓库详细信息也会发生变化。

为什么我们要引入新的包仓库？

随着 Kubernetes 项目的不断发展，我们希望确保最终用户获得最佳体验。托管在 Google 的仓库多年来一直为我们提供良好的服务，但我们开始面临一些问题，需要对发布包的方式进行重大变更。我们的另一个目标是对所有关键组件使用社区拥有的基础设施，其中包括仓库。

将包发布到托管在 Google 的仓库是一个手动过程，只能由名为 Google 构建管理员的 Google 员工团队来完成。 Kubernetes 发布管理员团队是一个非常多元化的团队，尤其是在我们工作的时区方面。考虑到这一限制，我们必须对每个版本进行非常仔细的规划，确保我们有发布经理和 Google 构建管理员来执行发布。

另一个问题是由于我们只有一个包仓库。因此，我们无法发布预发行版本（Alpha、Beta 和 RC）的包。这使得任何有兴趣测试的人都更难测试 Kubernetes 预发布版本。我们从测试这些版本的人员那里收到的反馈对于确保版本的最佳质量至关重要，因此我们希望尽可能轻松地测试这些版本。最重要的是，只有一个仓库限制了我们对 cri-tools 和 kubernetes-cni 等依赖进行发布，

尽管存在这些问题，我们仍非常感谢 Google 和 Google 构建管理员这些年来的参与、支持和帮助！

新的包仓库如何工作？

新的 Debian 和 RPM 仓库托管在 pkgs.k8s.io。目前，该域指向一个 CloudFront CDN，其后是包含仓库和包的 S3 存储桶。然而，我们计划在未来添加更多的镜像站点，让其他公司有可能帮助我们提供软件包服务。

包通过 OpenBuildService（OBS）平台构建和发布。经过长时间评估不同的解决方案后，我们决定使用 OpenBuildService 作为管理仓库和包的平台。首先，OpenBuildService 是一个开源平台，被大量开源项目和公司使用，如 openSUSE、VideoLAN、Dell、Intel 等。OpenBuildService 具有许多功能，使其非常灵活且易于与我们现有的发布工具集成。它还允许我们以与托管在 Google 的仓库类似的方式构建包，从而使迁移过程尽可能无缝。

SUSE 赞助 Kubernetes 项目并且支持访问其引入的 OpenBuildService 环境（build.opensuse.org），还提供将 OBS 与我们的发布流程集成的技术支持。

我们使用 SUSE 的 OBS 实例来构建和发布包。构建新版本后，我们的工具会自动将所需的制品和包设置推送到 build.opensuse.org。这将触发构建过程，为所有支持的架构（AMD64、ARM64、PPC64LE、S390X）构建包。最后，生成的包将自动推送到我们社区拥有的 S3 存储桶，以便所有用户都可以使用它们。

我们想借此机会感谢 SUSE 允许我们使用 build.opensuse.org 以及他们的慷慨支持，使这种集成成为可能！

托管在 Google 的仓库和 Kubernetes 仓库之间有哪些显著差异？

你应该注意三个显著差异：

每个 Kubernetes 次要版本都有一个专用的仓库。例如，名为 core:/stable:/v1.28 的仓库仅托管稳定 Kubernetes v1.28 版本的包。这意味着你可以从此仓库安装 v1.28.0，但无法安装 v1.27.0 或 v1.28 之外的任何其他次要版本。升级到另一个次要版本后，你必须添加新的仓库并可以选择删除旧的仓库

每个 Kubernetes 仓库中可用的 cri-tools 和 kubernetes-cni 包版本有所不同
- 这两个包是 kubelet 和 kubeadm 的依赖项
- v1.24 到 v1.27 的 Kubernetes 仓库与托管在 Google 的仓库具有这些包的相同版本
- v1.28 及更高版本的 Kubernetes 仓库将仅发布该 Kubernetes 次要版本
  - 就 v1.28 而言，Kubernetes v1.28 的仓库中仅提供 kubernetes-cni 1.2.0 和 cri-tools v1.28
  - 与 v1.29 类似，我们只计划发布 cri-tools v1.29 以及 Kubernetes v1.29 将使用的 kubernetes-cni 版本

包版本的修订部分（1.28.0-00 中的 -00 部分）现在由 OpenBuildService 平台自动生成，并具有不同的格式。修订版本现在采用 -x.y 格式，例如 1.28.0-1.1

这是否会影响现有的托管在 Google 的仓库？

托管在 Google 的仓库以及发布到其中的所有包仍然可用，与之前一样。我们构建包并将其发布到托管在 Google 仓库的方式没有变化，所有新引入的更改仅影响发布到社区自有仓库的包。

然而，正如本文开头提到的，我们计划将来停止将包发布到托管在 Google 的仓库。

如何迁移到 Kubernetes 社区自有的仓库？

使用 `apt`/`apt-get` 的 Debian、Ubuntu 一起其他操作系统

替换 apt 仓库定义，以便 apt 指向新仓库而不是托管在 Google 的仓库。确保将以下命令中的 Kubernetes 次要版本替换为你当前使用的次要版本：
```
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```

下载 Kubernetes 仓库的公共签名密钥。所有仓库都使用相同的签名密钥，因此你可以忽略 URL 中的版本：

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

更新 apt 包索引：
```
sudo apt-get update
```

使用 `rpm`/`dnf` 的 CentOS、Fedora、RHEL 以及其他操作系统

替换 yum 仓库定义，使 yum 指向新仓库而不是托管在 Google 的仓库。确保将以下命令中的 Kubernetes 次要版本替换为你当前使用的次要版本：

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF

迁移到 Kubernetes 仓库后是否可以回滚到托管在 Google 的仓库？

一般来说，可以。只需执行与迁移时相同的步骤，但使用托管在 Google 的仓库参数。你可以在“安装 kubeadm”等文档中找到这些参数。

为什么没有固定的域名/IP 列表？为什么我无法限制包下载？

我们对 pkgs.k8s.io 的计划是使其根据用户位置充当一组后端（包镜像）的重定向器。此更改的本质意味着下载包的用户可以随时重定向到任何镜像。鉴于架构和我们计划在不久的将来加入更多镜像，我们无法提供给你可以添加到允许列表中的 IP 地址或域名列表。

限制性控制机制（例如限制访问特定 IP/域名列表的中间人代理或网络策略）将随着此更改而中断。对于这些场景，我们鼓励你将包的发布版本与你可以严格控制的本地仓库建立镜像。

如果我发现新的仓库有异常怎么办？

如果你在新的 Kubernetes 仓库中遇到任何问题，请在 kubernetes/release 仓库中提交问题。

聚焦 SIG CLI

Thu, 20 Jul 2023 00:00:00 +0000

作者：Arpit Agrawal

译者：Xin Li (Daocloud)

在 Kubernetes 的世界中，大规模管理容器化应用程序需要强大而高效的工具。命令行界面（CLI）是任何开发人员或操作人员工具包不可或缺的一部分，其提供了一种方便灵活的方式与 Kubernetes 集群交互。

SIG CLI 通过专注于 Kubernetes 主要命令行工具 kubectl 的开发和增强，在改善 Kubernetes CLI 体验方面发挥着至关重要的作用。

在本次 SIG CLI 聚焦中，SIG ContribEx-Comms 团队成员 Arpit Agrawal 与 SIG CLI 技术主管兼主席 Katrina Verey 和 SIG CLI Batch 主管 Maciej Szulik 讨论了 SIG CLI 当前项目状态和挑战以及如何参与其中。

因此，无论你是经验丰富的 Kubernetes 爱好者还是刚刚入门，了解 SIG CLI 的重要性无疑将增强你的 Kubernetes 之旅。

简介

Arpit：你们能否向我们介绍一下你自己、你的角色以及你是如何参与 SIG CLI 的？

Maciej：我是 SIG-CLI 的技术负责人之一。自 2014 年以来，我一直在多个领域从事 Kubernetes 工作，并于 2018 年被任命为负责人。

Katrina：自 2016 年以来，我一直作为最终用户使用 Kubernetes，但直到 2019 年底，我才发现 SIG CLI 与我在内部项目中的经验非常吻合。我开始定期参加会议并提交了一些小型 PR，到 2021 年，我专门与 Kustomize 团队进行了更深入的合作。同年晚些时候，我被任命担任目前的职务，担任 Kustomize 和 KRM Functions 的子项目 owner 以及 SIG CLI 技术主管和负责人。

关于 SIG CLI

Arpit：谢谢！你们能否与我们分享一下 SIG CLI 的宗旨和目标？

Maciej：我们的章程有最详细的描述，但简而言之，我们处理所有 CLI 工具，帮助你管理 Kubernetes 资源清单以及与 Kubernetes 集群进行交互。

Arpit：我明白了。请问 SIG CLI 如何致力于推广云原生生态系统中 CLI 开发和使用的最佳实践？

Maciej：在 kubectl 中，我们正在进行多项努力，试图鼓励新的贡献者将现有命令与新标准保持一致。我们发布了几个库，希望能够更轻松地编写与 Kubernetes API 交互的 CLI，例如 cli-runtime 和 kyaml。

Katrina：我们还维护一些 CLI 工具的互操作性规范，例如 KRM 函数规范（GA）和新的 ApplySet 规范（Alpha）。

当前的项目和挑战

Arpit：阅读了一遍 README 文件，发现 SIG CLI 有许多子项目，你能突出讲一些重要的子项目吗？

Maciej：在我看来，值得你投入时间的四个最活跃的子项目是：

kubectl：规范的 Kubernetes CLI。
Kustomize：Kubernetes yaml 清单文件的无模板定制工具。
KUI - 一个针对 Kubernetes 的 GUI 界面，可以将其视为增强版的 kubectl。
krew：kubectl 的插件管理器。

Arpit：SIG CLI 是否有任何正在开展或即将开展的计划或开发工作？

Maciej：在任何给定的时间点，我们总是在开展多项举措。最好加入我们的一个电话会议来了解当前的情况。

对于主要功能，你可以查看我们的开放 KEP。例如，在 1.27 中，我们为 kubectl apply 中的新裁剪模式引入了新的 Alpha 特性，并为 kubectl 添加了插件。目前正在讨论的令人兴奋的想法包括 kubectl 删除的交互模式（KEP 3895）和 kuberc 用户首选项文件（KEP 3104）。

Arpit：你们能否说说 SIG CLI 在改善云本地技术的 CLI 时面临的任何挑战？未来将采取哪些措施来解决这些问题？

Katrina：我们每个决定面临的最大挑战是向后兼容性并确保我们不会影响现有用户。经常发生的情况是，修复表面上的内容似乎很简单，但即使修复 bug 也可能对某些用户造成破坏性更改，这意味着我们需要经历一个较长的弃用过程来更改它，或者在某些情况下我们不能完全改变它。另一个挑战是我们需要在工具上公开 flag 的平衡定制和可用性。例如，我们收到了许多关于新标志的建议，这些建议肯定对某些用户有用，但没有足够大的子集来证明，将它们添加到工具中对每个用户来说都会增加复杂性。 kuberc 提案可能会帮助个人用户设置或覆盖我们无法更改的默认值，甚至通过别名创建自定义子命令，从而帮助解决其中一些问题。

Arpit：随着 Kubernetes 的每个新版本的发布，保持一致性和完整性无疑是一项挑战： SIG CLI 团队如何解决这个问题？

Maciej：这与上一个问题中提到的主题非常相似：每一个新的更改，尤其是对现有命令的更改，都会经过大量的审查，以确保我们不会影响现有用户。在任何时候我们都必须在功能和不影响用户之间保持合理的平衡。

未来计划及贡献

Arpit：你们如何看待 CLI 工具在未来云原生生态系统中的作用？

Maciej：我认为 CLI 工具曾经并将永远是生态系统的重要组成部分。无论是管理员在没有 GUI 的远程计算机上还是在每个 CI/CD 管道中使用，它们都是不可替代的。

Arpit：Kubernetes 是一个社区驱动的项目。对于想要参与 SIG CLI 工作的人有什么建议吗？他们应该从哪里开始？有什么先决条件吗？

Maciej：除了有一点空闲时间和学习新东西的意愿之外，没有任何先决条件 :-)

Katrina：Go 的实用知识通常会有所帮助，但我们也有需要非代码贡献的领域，例如 Kustomize 文档整合项目。

Kubernetes 机密：使用机密虚拟机和安全区来增强你的集群安全性

Thu, 06 Jul 2023 00:00:00 +0000

作者：Fabian Kammel (Edgeless Systems), Mikko Ylinen (Intel), Tobin Feldman-Fitzthum (IBM)

译者：顾欣

在这篇博客文章中，我们将介绍机密计算（Confidential Computing，简称 CC）的概念，以增强任何计算环境的安全和隐私属性。此外，我们将展示云原生生态系统，特别是 Kubernetes，如何从新的计算范式中受益。

机密计算是一个先前在云原生领域中引入的概念。机密计算联盟(Confidential Computing Consortium，简称 CCC) 是 Linux 基金会中的一个项目社区，致力于定义和启用机密计算。在白皮书中，他们为使用机密计算提供了很好的动机。

数据存在于三种状态：传输中、静态存储和使用中。保护所有状态下的敏感数据比以往任何时候都更加关键。现在加密技术常被部署以提供数据机密性（阻止未经授权的查看）和数据完整性（防止或检测未经授权的更改）。虽然现在通常部署了保护传输中和静态存储中的数据的技术，但保护使用中的数据是新的前沿。

机密计算主要通过引入硬件强制执行的可信执行环境（TEE）来解决保护使用中的数据的问题。

可信执行环境

在过去的十多年里，可信执行环境（Trusted Execution Environments，简称 TEEs）以硬件安全模块（Hardware Security Modules，简称 HSMs）和可信平台模块（Trusted Platform Modules，简称 TPMs）的形式在商业计算硬件中得以应用。这些技术提供了可信的环境来进行受保护的计算。它们可以存储高度敏感的加密密钥，并执行关键的加密操作，如签名或加密数据。

TPMs 的优化为降低成本，使它们能够集成到主板中并充当系统的物理根信任。为了保持低成本，TPMs 的范围受到限制，即它们只能存储少量的密钥，并且仅能执行一小部分的加密操作。

相比之下，HSMs 的优化为提高性能，为更多的密钥提供安全存储，并提供高级物理攻击检测机制。此外，高端 HSMs 可以编程，以便可以编译和执行任意代码。缺点是它们的成本非常高。来自 AWS 的托管 CloudHSM 的费用大约是每小时 1.50 美元，或者约每年 13,500 美元。

近年来，一种新型的 TEE 已经变得流行。像 AMD SEV、 Intel SGX 和 Intel TDX 这样的技术提供了与用户空间紧密集成的 TEE。与支持特定的低功耗或高性能设备不同，这些 TEE 保护普通进程或虚拟机，并且可以以相对较低的开销执行此操作。这些技术各有不同的设计目标、优点和局限性，并且在不同的环境中可用，包括消费者笔记本电脑、服务器和移动设备。

此外，我们应该提及 ARM TrustZone，它针对智能手机、平板电脑和智能电视等嵌入式设备进行了优化，以及 AWS Nitro Enclaves，它们只在 Amazon Web Services 上可用，并且与 Intel 和 AMD 的基于 CPU 的解决方案相比，具有不同的威胁模型。

IBM Secure Execution for Linux 允许你在 IBM Z 系列硬件的可信执行环境内以 KVM 客户端的形式运行 Kubernetes 集群的节点。你可以使用这种硬件增强的虚拟机隔离机制为集群中的租户之间提供稳固的隔离，并通过硬件验证提供关于（虚拟）节点完整性的信息。

安全属性和特性功能

下文将回顾这些新技术所带来的安全属性和额外功能。只有部分解决方案会提供所有属性；我们将在各自的小节中更详细地讨论每项技术。

机密性属性确保在使用 TEE 时信息无法被查看。这为我们提供了非常需要的的功能以保护使用中的数据。根据使用的特定 TEE，代码和数据都可能受到外部查看者的保护。 TEE 架构的差异以及它们在云原生环境中的使用是在设计端到端安全性时的重要考虑因素，目的是为敏感工作负载提供最小的可信计算基础（Trusted Computing Base, 简称 TCB）。 CCC 最近致力于通用术语和支持材料，以帮助解释在不同的 TEE 架构下机密性边界的划分，以及这如何影响 TCB 的大小。

机密性是一个很好的特性，但攻击者仍然可以操纵或注入任意代码和数据供 TEE 执行，因此，很容易泄露关键信息。完整性保证 TEE 拥有者在运行关键计算时，代码和数据都不能被篡改。

可用性是在信息安全背景下经常讨论的一项基本属性。然而，这一属性超出了大多数 TEE 的范围。通常，它们可以被一些更高级别的抽象控制（关闭、重启...）。这可以是 CPU 本身、虚拟机监视器或内核。这是为了保持整个系统的可用性，而不是 TEE 本身。在云环境中运行时，可用性通常由云提供商以服务级别协议（Service Level Agreements，简称 SLAs）的形式保证，并且不能通过加密强制执行。

仅凭机密性和完整性在某些情况下是有帮助的。例如，考虑一个在远程云中运行的 TEE。你如何知道 TEE 是真实的并且正在运行你预期的软件？一旦你发送数据，它可能是一个冒名顶替者窃取你的数据。这个根本问题通过可验证性得到解决。验证允许我们基于硬件本身签发的加密证书来验证 TEE 的身份、机密性和完整性。这个功能也可以以远程验证的形式提供给机密计算硬件之外的客户端使用。

TEEs 可以保存和处理早于或超出可信环境存在时间的信息。这可能意味着重启、跨不同版本或平台迁移的信息。因此，可恢复性是一个重要的特性。在将数据和 TEE 的状态写入持久性存储之前，需要对它们进行封装，以维护保证机密性和完整性。对这种封装数据的访问需要明确定义。在大多数情况下，解封过程与 TEE 绑定的身份有关。因此，确保恢复只能在相同的机密环境中进行。

这不必限制整个系统的灵活性。 AMD SEV-SNP 的迁移代理 (MA) 允许用户将机密虚拟机迁移到不同的主机系统，同时保持 TEE 的安全属性不变。

功能比较

本文的这部分将更深入地探讨具体的实现，比较支持的功能并分析它们的安全属性。

AMD SEV

AMD 的安全加密虚拟化 (SEV)技术是一组功能，用于增强 AMD 服务器 CPU 上虚拟机的安全性。SEV 透明地用唯一密钥加密每个 VM 的内存。 SEV 还可以计算内存内容的签名，该签名可以作为证明初始客户机内存没有被篡改的依据发送给 VM 的所有者。

SEV 的第二代，称为加密状态或 SEV-ES，通过在发生上下文切换时加密所有 CPU 寄存器内容，提供了对虚拟机管理程序的额外保护。

SEV 的第三代，安全嵌套分页或 SEV-SNP，旨在防止基于软件的完整性攻击并降低受损内存完整性相关的风险。 SEV-SNP 完整性的基本原则是，如果虚拟机可以读取私有（加密）内存页，那么它必须始终读取它最后写入的值。

此外，通过允许客户端动态获取远程验证声明，SNP 增强了 SEV 的远程验证能力。

AMD SEV 是以增量方式实施的。每个新的 CPU 代都增加了新功能和改进。 Linux 社区将这些功能作为 KVM 虚拟机管理程序的一部分提供，适用于主机和客户机内核。第一批 SEV 功能在 2016 年被讨论并实施 - 参见 2016 年 Usenix 安全研讨会的 AMD x86 内存加密技术。最新的重大补充是 Linux 5.19 中的 SEV-SNP 客户端支持。

自 2022 年 7 月以来，Microsoft Azure 提供基于 AMD SEV-SNP 的机密虚拟机。类似地，Google Cloud Platform (GCP) 提供基于 AMD SEV-ES 的机密虚拟机。

Intel SGX

Intel 的软件防护扩展自 2015 年起便已推出，并在 Skylake 架构中首次亮相。

SGX 是一套指令集，它使用户能够创建一个叫做 Enclave 的受保护且隔离的进程。它提供了一个反沙箱机制，保护 Enclave 不受操作系统、固件以及任何其他特权执行上下文的影响。

Enclave 内存无法从 Enclave 外部读取或写入，无论当前的权限级别和 CPU 模式如何。调用 Enclave 功能的唯一方式是通过一条执行多个保护检查的新指令。Enclave 的内存是加密的。窃听内存或将 DRAM 模块连接到另一个系统只会得到加密数据。内存加密密钥在每次上电周期时随机更改。密钥存储在 CPU 内部，无法访问。

由于 Enclave 是进程隔离的，操作系统的库不能直接使用；因此，需要 SGX Enclave SDK 来编译针对 SGX 的程序。这也意味着应用程序需要在设计和实现时考虑受信任/不受信任的隔离边界。另一方面，应用程序的构建具有非常小的 TCB。

一种新兴的方法，利用库操作系统（library OSes）来轻松过渡到基于进程的机密计算并避免需要构建自定义应用程序。这些操作系统有助于在 SGX 安全 Enclave 内运行原生的、未经修改的 Linux 应用程序。操作系统库会拦截应用对宿主机操作系统的所有请求，并在应用不知情的情况下安全地处理它们，而应用实际上是在一个受信执行环境（TEE）中运行。

第三代 Xeon 处理器（又称为 Ice Lake 服务器 - "ICX"）及其后续版本采用了一种名为全内存加密 - 多密钥（TME-MK）的技术，该技术使用 AES-XTS，从消费者和 Xeon E 处理器使用的内存加密引擎中脱离出来。这可能增加了 Enclave 页面缓存（EPC）大小（每个 CPU 高达 512 GB）并提高了性能。关于多插槽平台上的 SGX 的更多信息可以在白皮书中找到。

可以从 Intel 获取支持的平台列表。

SGX 在 Azure、阿里云、 IBM 以及更多平台上可用。

Intel TDX

Intel SGX 旨在保护单个进程的上下文，而 Intel 的可信域扩展保护整个虚拟机，因此，它与 AMD SEV 最为相似。

与 SEV-SNP 一样，对 TDX 的客户端支持已经在 Linux Kernel 5.19版本中合并。然而，硬件支持将在 2023 年与 Sapphire Rapids 一同发布：阿里云提供邀请预览实例，同时，Azure 已经宣布其 TDX 预览机会。

开销分析

通过强隔离和增强的安全性，机密计算技术为客户数据和工作负载提供的好处并非免费。量化这种影响是具有挑战性的，并且取决于许多因素：TEE 技术，基准测试，度量标准以及工作负载的类型都对预期的性能开销有巨大的影响。

基于 Intel SGX 的 TEE 很难进行基准测试，正如不同的论文所展示的一样。所选择的 SDK/操作系统库，应用程序本身以及资源需求（特别是大内存需求）对性能有巨大的影响。如果应用程序非常适合在 Enclave 内运行，那么通常可以预期会有一个个位数的百分比的开销。

基于 AMD SEV-SNP 的机密虚拟机不需要对执行的程序和操作系统进行任何更改，因此更容易进行基准测试。一个来自 Azure 和 AMD 的基准测试显示， SEV-SNP VM 的开销 < 10%，有时甚至低至 2%。

尽管存在性能开销，但它应该足够低，以便使真实世界的工作负载能够在这些受保护的环境中运行，并提高我们数据的安全性和隐私性。

机密计算与 FHE、ZKP 和 MPC 的比较

全同态加密（FHE），零知识证明/协议（ZKP）和多方计算（MPC）都是加密或密码学协议的形式，提供与机密计算类似的安全保证，但不需要硬件支持。

全同态加密（也包括部分和有限同态加密）允许在加密数据上执行计算，例如加法或乘法。这提供了在使用中加密的属性，但不像机密计算那样提供完整性保护或认证。因此，这两种技术可以互为补充。

零知识证明或协议是一种隐私保护技术（PPT），它允许一方证明其数据的事实而不泄露关于数据的任何其他信息。 ZKP 可以替代或与机密计算一起使用，以保护相关方及其数据的隐私。同样，多方计算使多个参与方能够共同进行计算，即每个参与方提供其数据以得出结果，但不会泄露给任何其他参与方。

机密计算的应用场景

前面介绍的机密计算平台表明，既可以实现单个容器进程的隔离，从而最小化可信计算单元，也可以实现整个虚拟机的隔离。这已经促使很多有趣且安全的项目涌现：

机密容器

机密容器 (CoCo) 是一个 CNCF 沙箱项目，它在机密虚拟机内隔离 Kubernetes Pod。

CoCo 可以通过 operator 安装在 Kubernetes 集群上。operator 将创建一组运行时类，这些类可以用于在多个不同的平台上的 Enclave 内部署 Pod，包括 AMD SEV，Intel TDX，IBM Z 的安全执行和 Intel SGX。

CoCo 通常与签名和/或加密的容器镜像一起使用，这些镜像在 Enclave 内部被拉取、验证和解密。密钥信息，比如镜像解密密钥，经由受信任的 Key Broker 服务有条件地提供给 Enclave，这个服务在释放任何敏感信息之前验证 TEE 的硬件认证。

CoCo 有几种部署模型。由于 Kubernetes 控制平面在 TCB 之外，因此 CoCo 适合于受管理的环境。在不支持嵌套的虚拟环境中，CoCo 可以借助 API 适配器运行，该适配器在云中启动 Pod VM。 CoCo 还可以在裸机上运行，在多租户环境中提供强大的隔离。

受管理的机密 Kubernetes

Azure 和 GCP 都支持将机密虚拟机用作其受管理的 Kubernetes 的工作节点。

这两项服务通过启用容器工作负载的内存加密，旨在提供更好的工作负载保护和安全保证。然而，它们并没有寻求完全隔离集群或工作负载以防止服务提供者或基础设施的访问。具体来说，它们不提供专用的机密控制平面，也不为机密集群/节点提供可验证的能力。

Azure 在其托管的 Kubernetes 服务中也启用了机密容器。他们支持基于 Intel SGX Enclave 和基于 AMD SEV 虚拟机创建的机密容器。

Constellation

Constellation 是一个旨在提供最佳数据安全的 Kubernetes 引擎。 Constellation 将整个 Kubernetes 集群包装到一个机密上下文中，使其免受底层云基础设施的影响。其中的所有内容始终是加密的，包括在内存中的运行时数据。它保护工作节点和控制平面节点。此外，它已经与流行的 CNCF 软件（如 Cilium，用于安全网络）集成，并提供扩展的 CSI 动程序来安全地写入数据。

Occlum 和 Gramine

Occlum 和 Gramine 是两个开源的操作系统库项目，它们允许在 SGX 信任执行环境（Enclave）中运行未经修改的应用程序。它们是 CCC（Confidential Computing Consortium）下的成员项目，但也存在由公司维护的类似项目和产品。通过使用这些操作系统库项目，现有的容器化应用可以轻松转换为支持机密计算的容器。还有许多经过筛选的预构建容器可供使用。

我们现在处于哪个阶段？供应商、局限性和开源软件生态

正如我们希望你从前面的章节中看到的，机密计算是一种强大的新概念，用于提高安全性，但我们仍处于（早期）阶段。新产品开始涌现，以利用这些独特的属性。

谷歌和微软是首批能够让客户在一个受保护的环境内运行未经修改的应用程序的机密计算服务的主要云提供商。然而，这些服务仅限于计算，而对于机密数据库、集群网络和负载均衡器的端到端解决方案则需要自行管理。

这些技术为极其敏感的工作负载部署到云中提供了可能，并使其能够充分利用 CNCF 领域中的各种工具。

号召行动

如果你目前正在开发一个高安全性的产品，但由于法律要求在公共云上运行面临困难，或者你希望提升你的云原生项目的隐私和安全性：请联系我们强调的所有出色项目！每个人都渴望提高我们生态系统的安全性，而你可以在这个过程中扮演至关重要的角色。

在 CRI 运行时内验证容器镜像签名

Thu, 29 Jun 2023 00:00:00 +0000

作者: Sascha Grunert

译者: Michael Yao (DaoCloud)

Kubernetes 社区自 v1.24 版本开始对基于容器镜像的工件进行签名。在 v1.26 中，相应的增强特性从 alpha 进阶至 beta，引入了针对二进制工件的签名。其他项目也采用了类似的方法，为其发布版本提供镜像签名。这意味着这些项目要么使用 GitHub actions 在自己的 CI/CD 流程中创建签名，要么依赖于 Kubernetes 的镜像推广流程，通过向 k/k8s.io 仓库提交 PR 来自动签名镜像。使用此流程的前提要求是项目必须属于 kubernetes 或 kubernetes-sigs GitHub 组织，这样能够利用社区基础设施将镜像推送到暂存桶中。

假设一个项目现在生成了已签名的容器镜像工件，那么如何实际验证这些签名呢？你可以按照 Kubernetes 官方文档所述来手动验证。但是这种方式的问题在于完全没有自动化，应仅用于测试目的。在生产环境中，sigstore policy-controller 这样的工具有助于进行自动化处理。这些工具使用自定义资源定义（CRD）提供了更高级别的 API，并且利用集成的准入控制器和 Webhook来验证签名。

基于准入控制器的验证的一般使用流程如下：

这种架构的一个主要优点是简单：集群中的单个实例会先验证签名，然后才在节点上的容器运行时中执行镜像拉取操作，镜像拉取是由 kubelet 触发的。这个优点也带来了分离的问题：应拉取容器镜像的节点不一定是执行准入控制的节点。这意味着如果控制器受到攻击，那么无法在整个集群范围内强制执行策略。

解决此问题的一种方式是直接在与容器运行时接口（CRI）兼容的容器运行时中进行策略评估。这种运行时直接连接到节点上的 kubelet，执行拉取镜像等所有任务。 CRI-O 是可用的运行时之一，将在 v1.28 中完全支持容器镜像签名验证。

容器运行时是如何工作的呢？CRI-O 会读取一个名为 policy.json 的文件，其中包含了为容器镜像定义的所有规则。例如，你可以定义一个策略，只允许带有以下标记或摘要的已签名镜像 quay.io/crio/signed：

{
  "default": [{ "type": "reject" }],
  "transports": {
    "docker": {
      "quay.io/crio/signed": [
        {
          "type": "sigstoreSigned",
          "signedIdentity": { "type": "matchRepository" },
          "fulcio": {
            "oidcIssuer": "https://github.com/login/oauth",
            "subjectEmail": "sgrunert@redhat.com",
            "caData": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUI5ekNDQVh5Z0F3SUJBZ0lVQUxaTkFQRmR4SFB3amVEbG9Ed3lZQ2hBTy80d0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNVEV3TURjeE16VTJOVGxhRncwek1URXdNRFV4TXpVMk5UaGFNQ294RlRBVEJnTlZCQW9UREhOcFozTjBiM0psCkxtUmxkakVSTUE4R0ExVUVBeE1JYzJsbmMzUnZjbVV3ZGpBUUJnY3Foa2pPUFFJQkJnVXJnUVFBSWdOaUFBVDcKWGVGVDRyYjNQUUd3UzRJYWp0TGszL09sbnBnYW5nYUJjbFlwc1lCcjVpKzR5bkIwN2NlYjNMUDBPSU9aZHhleApYNjljNWlWdXlKUlErSHowNXlpK1VGM3VCV0FsSHBpUzVzaDArSDJHSEU3U1hyazFFQzVtMVRyMTlMOWdnOTJqCll6QmhNQTRHQTFVZER3RUIvd1FFQXdJQkJqQVBCZ05WSFJNQkFmOEVCVEFEQVFIL01CMEdBMVVkRGdRV0JCUlkKd0I1ZmtVV2xacWw2ekpDaGt5TFFLc1hGK2pBZkJnTlZIU01FR0RBV2dCUll3QjVma1VXbFpxbDZ6SkNoa3lMUQpLc1hGK2pBS0JnZ3Foa2pPUFFRREF3TnBBREJtQWpFQWoxbkhlWFpwKzEzTldCTmErRURzRFA4RzFXV2cxdENNCldQL1dIUHFwYVZvMGpoc3dlTkZaZ1NzMGVFN3dZSTRxQWpFQTJXQjlvdDk4c0lrb0YzdlpZZGQzL1Z0V0I1YjkKVE5NZWE3SXgvc3RKNVRmY0xMZUFCTEU0Qk5KT3NRNHZuQkhKCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="
          },
          "rekorPublicKeyData": "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFMkcyWSsydGFiZFRWNUJjR2lCSXgwYTlmQUZ3cgprQmJtTFNHdGtzNEwzcVg2eVlZMHp1ZkJuaEM4VXIvaXk1NUdoV1AvOUEvYlkyTGhDMzBNOStSWXR3PT0KLS0tLS1FTkQgUFVCTElDIEtFWS0tLS0tCg=="
        }
      ]
    }
  }
}

CRI-O 必须被启动才能将策略用作全局的可信源：

> sudo crio --log-level debug --signature-policy ./policy.json

CRI-O 现在可以在验证镜像签名的同时拉取镜像。例如，可以使用 crictl（cri-tools）来完成此操作：

> sudo crictl -D pull quay.io/crio/signed
DEBU[…] get image connection
DEBU[…] PullImageRequest: &PullImageRequest{Image:&ImageSpec{Image:quay.io/crio/signed,Annotations:map[string]string{},},Auth:nil,SandboxConfig:nil,}
DEBU[…] PullImageResponse: &PullImageResponse{ImageRef:quay.io/crio/signed@sha256:18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a,}
Image is up to date for quay.io/crio/signed@sha256:18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a

CRI-O 的调试日志也会表明签名已成功验证：

DEBU[…] IsRunningImageAllowed for image docker:quay.io/crio/signed:latest
DEBU[…]  Using transport "docker" specific policy section quay.io/crio/signed
DEBU[…] Reading /var/lib/containers/sigstore/crio/signed@sha256=18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a/signature-1
DEBU[…] Looking for sigstore attachments in quay.io/crio/signed:sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig
DEBU[…] GET https://quay.io/v2/crio/signed/manifests/sha256-18b42e8ea347780f35d979a829affa178593a8e31d90644466396e1187a07f3a.sig
DEBU[…] Content-Type from manifest GET is "application/vnd.oci.image.manifest.v1+json"
DEBU[…] Found a sigstore attachment manifest with 1 layers
DEBU[…] Fetching sigstore attachment 1/1: sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45
DEBU[…] Downloading /v2/crio/signed/blobs/sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45
DEBU[…] GET https://quay.io/v2/crio/signed/blobs/sha256:8276724a208087e73ae5d9d6e8f872f67808c08b0acdfdc73019278807197c45
DEBU[…]  Requirement 0: allowed
DEBU[…] Overall: allowed

策略中定义的 oidcIssuer 和 subjectEmail 等所有字段都必须匹配，而 fulcio.caData 和 rekorPublicKeyData 是来自上游 fulcio（OIDC PKI）和 rekor（透明日志）实例的公钥。

这意味着如果你现在将策略中的 subjectEmail 作废，例如更改为 wrong@mail.com：

> jq '.transports.docker."quay.io/crio/signed"[0].fulcio.subjectEmail = "wrong@mail.com"' policy.json > new-policy.json
> mv new-policy.json policy.json

然后移除镜像，因为此镜像已存在于本地：

> sudo crictl rmi quay.io/crio/signed

现在当你拉取镜像时，CRI-O 将报错所需的 email 是错的：

> sudo crictl pull quay.io/crio/signed
FATA[…] pulling image: rpc error: code = Unknown desc = Source image rejected: Required email wrong@mail.com not found (got []string{"sgrunert@redhat.com"})

你还可以对未签名的镜像进行策略测试。为此，你需要将键 quay.io/crio/signed 修改为类似 quay.io/crio/unsigned：

> sed -i 's;quay.io/crio/signed;quay.io/crio/unsigned;' policy.json

如果你现在拉取容器镜像，CRI-O 将报错此镜像不存在签名：

> sudo crictl pull quay.io/crio/unsigned
FATA[…] pulling image: rpc error: code = Unknown desc = SignatureValidationFailed: Source image rejected: A signature was required, but no signature exists

需要强调的是，CRI-O 将签名中的 .critical.identity.docker-reference 字段与镜像仓库进行匹配。例如，如果你要验证镜像 registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.3，则相应的 docker-reference 须是 registry.k8s.io/kube-apiserver-amd64：

> cosign verify registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.3 \
    --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
    --certificate-oidc-issuer https://accounts.google.com \
    | jq -r '.[0].critical.identity."docker-reference"'
…

registry.k8s.io/kubernetes/kube-apiserver-amd64

Kubernetes 社区引入了 registry.k8s.io 作为各种镜像仓库的代理镜像。在 kpromo v4.0.2 版本发布之前，镜像已使用实际镜像签名而不是使用 registry.k8s.io 签名：

> cosign verify registry.k8s.io/kube-apiserver-amd64:v1.28.0-alpha.2 \
    --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
    --certificate-oidc-issuer https://accounts.google.com \
    | jq -r '.[0].critical.identity."docker-reference"'
…

asia-northeast2-docker.pkg.dev/k8s-artifacts-prod/images/kubernetes/kube-apiserver-amd64

将 docker-reference 更改为 registry.k8s.io 使最终用户更容易验证签名，因为他们不需要知道所使用的底层基础设施的详细信息。设置镜像签名身份的特性已通过 sign --sign-container-identity 标志添加到 cosign，并将成为即将发布的版本的一部分。

最近在 Kubernetes 中添加了镜像拉取错误码 SignatureValidationFailed，将从 v1.28 版本开始可用。这个错误码允许最终用户直接从 kubectl CLI 了解镜像拉取失败的原因。例如，如果你使用要求对 quay.io/crio/unsigned 进行签名的策略同时运行 CRI-O 和 Kubernetes，那么 Pod 的定义如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: container
      image: quay.io/crio/unsigned

将在应用 Pod 清单时造成 SignatureValidationFailed 错误：

> kubectl apply -f pod.yaml
pod/pod created

> kubectl get pods
NAME   READY   STATUS                      RESTARTS   AGE
pod    0/1     SignatureValidationFailed   0          4s

> kubectl describe pod pod | tail -n8
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  58s                default-scheduler  Successfully assigned default/pod to 127.0.0.1
  Normal   BackOff    22s (x2 over 55s)  kubelet            Back-off pulling image "quay.io/crio/unsigned"
  Warning  Failed     22s (x2 over 55s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling    9s (x3 over 58s)   kubelet            Pulling image "quay.io/crio/unsigned"
  Warning  Failed     6s (x3 over 55s)   kubelet            Failed to pull image "quay.io/crio/unsigned": SignatureValidationFailed: Source image rejected: A signature was required, but no signature exists
  Warning  Failed     6s (x3 over 55s)   kubelet            Error: SignatureValidationFailed

这种整体行为提供了更符合 Kubernetes 原生体验的方式，并且不依赖于在集群中安装的第三方软件。

还有一些特殊情况需要考虑：例如，如果你希望像策略控制器那样允许按命名空间设置策略，怎么办？好消息是，CRI-O 在 v1.28 版本中即将推出这个特性！CRI-O 将支持 --signature-policy-dir / signature_policy_dir 选项，为命名空间隔离的签名策略的 Pod 定义根路径。这意味着 CRI-O 将查找该路径，并组装一个类似 <SIGNATURE_POLICY_DIR>/<NAMESPACE>.json 的策略，在镜像拉取时如果存在则使用该策略。如果（通过沙盒配置）在镜像拉取时未提供 Pod 命名空间，或者串接的路径不存在，则 CRI-O 的全局策略将用作后备。

另一个需要考虑的特殊情况对于容器运行时中正确的签名验证至关重要：kubelet 仅在磁盘上不存在镜像时才调用容器镜像拉取。这意味着来自 Kubernetes 命名空间 A 的不受限策略可以允许拉取一个镜像，而命名空间 B 则无法强制执行该策略，因为它已经存在于节点上了。最后，CRI-O 必须在容器创建时验证策略，而不仅仅是在镜像拉取时。这一事实使情况变得更加复杂，因为 CRI 在容器创建时并没有真正传递用户指定的镜像引用，而是传递已经解析过的镜像 ID 或摘要。对 CRI 进行小改动有助于解决这个问题。

现在一切都发生在容器运行时中，大家必须维护和定义策略以提供良好的用户体验。策略控制器的 CRD 非常出色，我们可以想象集群中的一个守护进程可以按命名空间为 CRI-O 编写策略。这将使任何额外的回调过时，并将验证镜像签名的责任移交给实际拉取镜像的实例。我已经评估了在纯 Kubernetes 中实现更好的容器镜像签名验证的其他可能途径，但我没有找到一个很好的原生 API 解决方案。这意味着我相信 CRD 是正确的方法，但用户仍然需要一个实际有作用的实例。

感谢阅读这篇博文！如果你对更多内容感兴趣，想提供反馈或寻求帮助，请随时通过 Slack (#crio) 或 SIG Node 邮件列表直接联系我。

dl.k8s.io 采用内容分发网络（CDN）

Fri, 09 Jun 2023 00:00:00 +0000

作者：Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute)

译者：Xin Li (Daocloud)

我们很高兴地宣布，官方 Kubernetes 二进制文件的主页 dl.k8s.io 很快将由 Fastly 提供支持。

Fastly 以其高性能内容分发网络（CDN）而闻名，该网络旨在全球范围内快速可靠地分发内容。凭借其强大的网络，Fastly 将帮助我们实现比以往更快、更可靠地向用户分发官方 Kubernetes 二进制文件。

使用 Fastly 是在经过广泛的评估过程后做出的决定，在该过程中我们仔细评估了几个潜在的内容分发网络提供商。最终，我们选择 Fastly 是因为他们对开放互联网的承诺以及在为一些著名的开源项目（通过他们的 Fast Forward 计划）提供快速和安全的数字体验方面的良好记录。

关于本次更改你需要了解的信息

7 月 24 日星期一，与 dl.k8s.io 域名关联的 IP 地址和后端存储将发生变化。
由于域名将保持不变，因此更改不会影响绝大多数用户。
如果你限制对特定 IP 范围的访问，则对 dl.k8s.io 域的访问可能会停止工作。

如果你认为你可能会受到影响或想了解有关此次更改的更多信息，请继续阅读。

我们为什么要进行此更改

官方 Kubernetes 二进制文件网站 dl.k8s.io 被全世界成千上万的用户使用，目前每月提供超过 5 PB 的二进制文件服务。本次更改将通过充分利用全球 CDN 来改善对这些资源的访问。

这只影响 dl.k8s.io，还是其他域也受到影响？

只有 dl.k8s.io 会受到本次变更的影响。

我公司规定了允许我们访问的域名，此更改会影响域名吗？

不，域名（dl.k8s.io）将保持不变：无需更改，不会影响对 Kubernetes 发布二进制文件站点的访问。

我的公司使用某种形式的 IP 过滤，此更改会影响对站点的访问吗？

如果已经存在基于 IP 的过滤，则当新 IP 地址变为活动状态时，对站点的访问可能会受到影响。

如果我的公司不使用 IP 地址来限制网络流量，我们需要做些什么吗？

不，切换到 CDN 的过程应该是透明的。

会有双运行期吗？

不，这是切换。 但是，你现在可以测试你的网络，检查它们是否可以从 Fastly 路由到新的公共 IP 地址。你应该在 7 月 24 日之前将新 IP 添加到你网络的 allowlist（白名单）中。切换完成后，确保你的网络使用新的 IP 地址连接到 dl.k8s.io 服务。

新 IP 地址是什么？

如果你需要管理下载允许列表，你可以从 Fastly API 中获取需要匹配的范围， JSON 格式地址：公共 IP 地址范围。

你不需要任何凭据即可下载该范围列表。

推荐哪些后续操作？

如果你已经有了基于 IP 的过滤，我们建议你在 7 月 24 日之前采取以下行动：

将新的 IP 地址添加到你的白名单。
对你的网络/防火墙进行测试，以确保你的网络可以路由到新的 IP 地址。

进行更改后，我们建议仔细检查 HTTP 调用是否正在使用新 IP 地址访问 dl.k8s.io。

切换后发现异常怎么办？

如果你在二进制文件下载过程中遇到任何异常，请提交 Issue。

使用 OCI 工件为 seccomp、SELinux 和 AppArmor 分发安全配置文件

Wed, 24 May 2023 00:00:00 +0000

作者: Sascha Grunert

译者: Michael Yao (DaoCloud)

Security Profiles Operator (SPO) 使得在 Kubernetes 中管理 seccomp、SELinux 和 AppArmor 配置文件变得更加容易。它允许集群管理员在预定义的自定义资源 YAML 中定义配置文件，然后由 SPO 分发到整个集群中。安全配置文件的修改和移除也由 Operator 以同样的方式进行管理，但这只是其能力的一小部分。

SPO 的另一个核心特性是能够组合 seccomp 配置文件。这意味着用户可以在 YAML 规约中定义 baseProfileName，然后 Operator 会自动解析并组合系统调用规则。如果基本配置文件有另一个 baseProfileName，那么 Operator 将以递归方式解析配置文件到一定深度。常见的使用场景是为低级容器运行时（例如 runc 或 crun）定义基本配置文件，在这些配置文件中包含各种情况下运行容器所需的系统调用。另外，应用开发人员可以为其标准分发容器定义 seccomp 基本配置文件，并在其上组合针对应用逻辑的专用配置文件。这样开发人员就可以专注于维护更简单且范围限制为应用逻辑的 seccomp 配置文件，而不需要考虑整个基础设施的设置。

但是如何维护这些基本配置文件呢？例如，运行时所需的系统调用数量可能会像主应用一样在其发布周期内发生变化。基本配置文件必须在同一集群中可用，否则主 seccomp 配置文件将无法部署。这意味着这些基本配置文件与主应用配置文件紧密耦合，因此违背了基本配置文件的核心理念。将基本配置文件作为普通文件分发和管理感觉像是需要解决的额外负担。

OCI 工件成为救命良方

Security Profiles Operator 的 v0.8.0 版本支持将基本配置文件作为 OCI 工件进行管理！将 OCI 工件假想为轻量级容器镜像，采用与镜像相同的方式在各层中存储文件，但没有要执行的进程。这些工件可以用于像普通容器镜像一样在兼容的镜像仓库中存储安全配置文件。这意味着这些工件可以被版本化、作用于命名空间并类似常规容器镜像一样添加注解。

若要查看具体的工作方式，可以在 seccomp 配置文件 CRD 内以前缀 oci:// 指定 baseProfileName，例如：

apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: test
spec:
  defaultAction: SCMP_ACT_ERRNO
  baseProfileName: oci://ghcr.io/security-profiles/runc:v1.1.5
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - uname

Operator 将负责使用 oras 拉取内容，并验证工件的 sigstore (cosign) 签名。如果某些工件未经签名，则 SPO 将拒绝它们。随后生成的配置文件 test 将包含来自远程 runc 配置文件的所有基本系统调用加上额外允许的 uname 系统调用。你还可以通过摘要（SHA256）来引用基本配置文件，使要被拉取的工件更为确定，例如通过引用 oci：//ghcr.io/security-profiles/runc@sha256: 380…。

Operator 在内部缓存已拉取的工件，最多可缓存 1000 个配置文件 24 小时，这意味着如果缓存已满、Operator 守护进程重启或超出给定时段后这些工件将被刷新。

因为总体生成的系统调用对用户不可见（我只列出了 SeccompProfile 中的 baseProfileName，而没有列出系统调用本身），所以我为该 SeccompProfile 的最终 syscalls 添加了额外的注解。

以下是我注解后的 SeccompProfile：

> kubectl describe seccompprofile test
Name:         test
Namespace:    security-profiles-operator
Labels:       spo.x-k8s.io/profile-id=SeccompProfile-test
Annotations:  syscalls:
                [{"names":["arch_prctl","brk","capget","capset","chdir","clone","close",...
API Version:  security-profiles-operator.x-k8s.io/v1beta1

SPO 维护者们作为 “Security Profiles” GitHub 组织的成员提供所有公开的基本配置文件。

管理 OCI 安全配置文件

好的，官方的 SPO 提供了许多基本配置文件，但是我如何定义自己的配置文件呢？首先，我们必须选择一个可用的镜像仓库。有许多镜像仓库都已支持 OCI 工件：

Security Profiles Operator 交付一个新的名为 spoc 的命令行界面，这是一个用于管理 OCI 配置文件的小型辅助工具，该工具提供的各项能力不在这篇博文的讨论范围内。但 spoc push 命令可以用于将安全配置文件推送到镜像仓库：

> export USERNAME=my-user
> export PASSWORD=my-pass
> spoc push -f ./examples/baseprofile-crun.yaml ghcr.io/security-profiles/crun:v1.8.3
16:35:43.899886 Pushing profile ./examples/baseprofile-crun.yaml to: ghcr.io/security-profiles/crun:v1.8.3
16:35:43.899939 Creating file store in: /tmp/push-3618165827
16:35:43.899947 Adding profile to store: ./examples/baseprofile-crun.yaml
16:35:43.900061 Packing files
16:35:43.900282 Verifying reference: ghcr.io/security-profiles/crun:v1.8.3
16:35:43.900310 Using tag: v1.8.3
16:35:43.900313 Creating repository for ghcr.io/security-profiles/crun
16:35:43.900319 Using username and password
16:35:43.900321 Copying profile to repository
16:35:46.976108 Signing container image
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.

By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=…
Successfully verified SCT...
tlog entry created with index: 16520520
Pushing signature to: ghcr.io/security-profiles/crun

你可以看到该工具自动签署工件并将 ./examples/baseprofile-crun.yaml 推送到镜像仓库中，然后直接可以在 SPO 中使用此文件。如果需要验证用户名和密码，则可以使用 --username、 -u 标志或导出 USERNAME 环境变量。要设置密码，可以导出 PASSWORD 环境变量。

采用 KEY:VALUE 的格式多次使用 --annotations / -a 标志，可以为安全配置文件添加自定义注解。目前这些对安全配置文件没有影响，但是在后续某个阶段，Operator 的其他特性可能会依赖于它们。

spoc 客户端还可以从兼容 OCI 工件的镜像仓库中拉取安全配置文件。要执行此操作，只需运行 spoc pull：

> spoc pull ghcr.io/security-profiles/runc:v1.1.5
16:32:29.795597 Pulling profile from: ghcr.io/security-profiles/runc:v1.1.5
16:32:29.795610 Verifying signature

Verification for ghcr.io/security-profiles/runc:v1.1.5 --
The following checks were performed on each of these signatures:
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

[{"critical":{"identity":{"docker-reference":"ghcr.io/security-profiles/runc"},…}}]
16:32:33.208695 Creating file store in: /tmp/pull-3199397214
16:32:33.208713 Verifying reference: ghcr.io/security-profiles/runc:v1.1.5
16:32:33.208718 Creating repository for ghcr.io/security-profiles/runc
16:32:33.208742 Using tag: v1.1.5
16:32:33.208743 Copying profile from repository
16:32:34.119652 Reading profile
16:32:34.119677 Trying to unmarshal seccomp profile
16:32:34.120114 Got SeccompProfile: runc-v1.1.5
16:32:34.120119 Saving profile in: /tmp/profile.yaml

现在可以在 /tmp/profile.yaml 或 --output-file / -o 所指定的输出文件中找到该配置文件。我们可以像 spoc push 一样指定用户名和密码。

spoc 使得以 OCI 工件的形式管理安全配置文件变得非常容易，这些 OCI 工件可以由 Operator 本身直接使用。

本文简要介绍了通过 Security Profiles Operator 能够达成的各种最新可能性！如果你有兴趣了解更多，无论是提出反馈还是寻求帮助，请通过 Slack (#security-profiles-operator) 或邮件列表直接与我们联系。

在边缘上玩转 seccomp 配置文件

Thu, 18 May 2023 00:00:00 +0000

作者: Sascha Grunert

译者: Michael Yao (DaoCloud)

[Security Profiles Operator (SPO)][spo] 是一个功能丰富的 Kubernetes [operator][operator]，相比以往可以简化 seccomp、SELinux 和 AppArmor 配置文件的管理。从头开始记录这些配置文件是该 Operator 的关键特性之一，这通常涉及与大型 CI/CD 系统集成。在边缘场景中测试 Operator 的记录能力是 SPO 的最新开发工作之一，非常有助于轻松玩转 seccomp 配置文件。

使用 `spoc record` 记录 seccomp 配置文件

v0.8.0 版本的 Security Profiles Operator 附带一个名为 spoc 的全新命令行接口，是一个能够用来记录和回放 seccomp 配置文件的工具，该工具还有一些其他能力不在这篇博文的讨论范围内。

记录 seccomp 配置文件需要执行一个二进制文件，这个二进制文件可以是一个仅只调用 uname(2) 的简单 Golang 应用程序：

package main

import (
	"syscall"
)

func main() {
	utsname := syscall.Utsname{}
	if err := syscall.Uname(&utsname); err != nil {
		panic(err)
	}
}

可通过以下命令从代码构建一个二进制文件：

> go build -o main main.go
> ldd ./main
        not a dynamic executable

现在可以从 GitHub 下载最新的 spoc 二进制文件，并使用它在 Linux 上运行应用程序：

> sudo ./spoc record ./main
10:08:25.591945 Loading bpf module
10:08:25.591958 Using system btf file
libbpf: loading object 'recorder.bpf.o' from buffer
…
libbpf: prog 'sys_enter': relo #3: patched insn #22 (ALU/ALU64) imm 16 -> 16
10:08:25.610767 Getting bpf program sys_enter
10:08:25.610778 Attaching bpf tracepoint
10:08:25.611574 Getting syscalls map
10:08:25.611582 Getting pid_mntns map
10:08:25.613097 Module successfully loaded
10:08:25.613311 Processing events
10:08:25.613693 Running command with PID: 336007
10:08:25.613835 Received event: pid: 336007, mntns: 4026531841
10:08:25.613951 No container ID found for PID (pid=336007, mntns=4026531841, err=unable to find container ID in cgroup path)
10:08:25.614856 Processing recorded data
10:08:25.614975 Found process mntns 4026531841 in bpf map
10:08:25.615110 Got syscalls: read, close, mmap, rt_sigaction, rt_sigprocmask, madvise, nanosleep, clone, uname, sigaltstack, arch_prctl, gettid, futex, sched_getaffinity, exit_group, openat
10:08:25.615195 Adding base syscalls: access, brk, capget, capset, chdir, chmod, chown, close_range, dup2, dup3, epoll_create1, epoll_ctl, epoll_pwait, execve, faccessat2, fchdir, fchmodat, fchown, fchownat, fcntl, fstat, fstatfs, getdents64, getegid, geteuid, getgid, getpid, getppid, getuid, ioctl, keyctl, lseek, mkdirat, mknodat, mount, mprotect, munmap, newfstatat, openat2, pipe2, pivot_root, prctl, pread64, pselect6, readlink, readlinkat, rt_sigreturn, sched_yield, seccomp, set_robust_list, set_tid_address, setgid, setgroups, sethostname, setns, setresgid, setresuid, setsid, setuid, statfs, statx, symlinkat, tgkill, umask, umount2, unlinkat, unshare, write
10:08:25.616293 Wrote seccomp profile to: /tmp/profile.yaml
10:08:25.616298 Unloading bpf module

我必须以 root 用户身份执行 spoc，因为它将在内部通过复用 Security Profiles Operator 自身的相同代码，运行一个 ebpf 程序。我可以看到 bpf 模块已成功加载，并且 spoc 已将所需的跟踪点附加到该模块。随后该模块将使用其挂载命名空间跟踪主应用程序并处理记录的系统调用数据。 ebpf 程序的本质是监视整个内核的上下文，这意味着 spoc 跟踪系统的所有系统调用，但不会干涉其执行过程。

这些日志表明 spoc 发现了包括 uname 在内的 read、close、mmap 等系统调用。除 uname 之外的所有系统调用都来自 Golang 运行时及其垃圾回收，这已经为我们演示中的简单应用增加了开销。我还可以从日志行 Adding base syscalls: … 中看到 spoc 将一堆基本系统调用添加到了生成的配置文件中。这些系统调用由 OCI 运行时（如 runc 或 crun）使用以便能够运行容器。这意味着 spoc 可用于记录可直接被容器化的 seccomp 配置文件。这种行为可以通过在 spoc 中使用 --no-base-syscalls/-n 禁用，或通过 --base-syscalls/-b 命令行标志进行自定义。这对于使用除了 crun 和 runc 之外的不同 OCI 运行时或者如果我只想记录应用的 seccomp 配置文件并将其与另一个基本配置文件组合时非常有帮助。

生成的配置文件现在位于 /tmp/profile.yaml，但可以使用 --output-file value/-o 标志更改默认位置：

> cat /tmp/profile.yaml

apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  creationTimestamp: null
  name: main
spec:
  architectures:
    - SCMP_ARCH_X86_64
  defaultAction: SCMP_ACT_ERRNO
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - access
        - arch_prctl
        - brk
        - …
        - uname
        - …
status: {}

seccomp 配置文件 CRD 可直接与 Security Profiles Operator 一起使用，统一在 Kubernetes 中进行管理。 spoc 还可以通过使用 --type/-t raw-seccomp 标志生成原始的 seccomp 配置文件（格式为 JSON）：

> sudo ./spoc record --type raw-seccomp ./main
…
52.628827 Wrote seccomp profile to: /tmp/profile.json

> jq . /tmp/profile.json

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["access", "…", "write"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

实用程序 spoc record 允许我们直接在任何能够在内核中运行 ebpf 代码的 Linux 系统上记录复杂的 seccomp 配置文件。但它还可以做更多事情：例如修改 seccomp 配置文件并使用 spoc run 进行测试。

使用 `spoc run` 运行 seccomp 配置文件

spoc 还能够使用 seccomp 配置文件来运行二进制文件，轻松测试对其所做的任何修改。要执行此操作，只需运行：

> sudo ./spoc run ./main
10:29:58.153263 Reading file /tmp/profile.yaml
10:29:58.153311 Assuming YAML profile
10:29:58.154138 Setting up seccomp
10:29:58.154178 Load seccomp profile
10:29:58.154189 Starting audit log enricher
10:29:58.154224 Enricher reading from file /var/log/audit/audit.log
10:29:58.155356 Running command with PID: 437880
>

看起来应用程序已成功退出，这是符合预期的，因为我尚未修改先前记录的配置文件。我还可以使用 --profile/-p 标志指定配置文件的自定义位置，但这并不是必需的，因为我没有修改默认输出位置。spoc 将自动确定它是基于原始的（JSON）还是基于 CRD 的（YAML）seccomp 配置文件，然后将其应用于该进程。

Security Profiles Operator 支持 log enricher 特性，通过解析审计日志提供与 seccomp 相关的额外信息。 spoc run 以同样的方式使用 enricher 向最终用户提供更多数据以调试 seccomp 配置文件。

现在我不得不修改配置文件来查看输出中有价值的信息。例如，我可以移除允许的 uname 系统调用：

> jq 'del(.syscalls[0].names[] | select(. == "uname"))' /tmp/profile.json > /tmp/no-uname-profile.json

然后尝试用新的配置文件 /tmp/no-uname-profile.json 来运行：

> sudo ./spoc run -p /tmp/no-uname-profile.json ./main
10:39:12.707798 Reading file /tmp/no-uname-profile.json
10:39:12.707892 Setting up seccomp
10:39:12.707920 Load seccomp profile
10:39:12.707982 Starting audit log enricher
10:39:12.707998 Enricher reading from file /var/log/audit/audit.log
10:39:12.709164 Running command with PID: 480512
panic: operation not permitted

goroutine 1 [running]:
main.main()
        /path/to/main.go:10 +0x85
10:39:12.713035 Unable to run: launch runner: wait for command: exit status 2

好的，这符合预期！应用的 seccomp 配置文件阻止了 uname 系统调用，导致出现 "operation not permitted" 错误。此错误提示过于宽泛，没有提供关于 seccomp 阻止了什么的任何提示。通常情况下，如果 seccomp 禁止某个系统调用，很难预测应用程序会做出什么行为。可能应用程序像这个简单演示一样终止，但也可能导致奇怪的异常行为使得应用程序根本无法停止。

现在，如果我将配置文件的默认 seccomp 操作从 SCMP_ACT_ERRNO 更改为 SCMP_ACT_LOG，就像这样：

> jq '.defaultAction = "SCMP_ACT_LOG"' /tmp/no-uname-profile.json > /tmp/no-uname-profile-log.json

那么 log enricher 将提示我们 uname 系统调用在使用 spoc run 时被阻止：

> sudo ./spoc run -p /tmp/no-uname-profile-log.json ./main
10:48:07.470126 Reading file /tmp/no-uname-profile-log.json
10:48:07.470234 Setting up seccomp
10:48:07.470245 Load seccomp profile
10:48:07.470302 Starting audit log enricher
10:48:07.470339 Enricher reading from file /var/log/audit/audit.log
10:48:07.470889 Running command with PID: 522268
10:48:07.472007 Seccomp: uname (63)

应用程序现在不会再终止，但 seccomp 将行为记录到 /var/log/audit/audit.log 中，而 spoc 会解析数据以将其直接与我们的程序相关联。将日志消息生成到审计子系统中会带来巨大的性能开销，在生产系统中应小心处理。当在生产环境中以审计模式运行不受信任的应用时，也会带来安全风险。

本文的演示希望让你了解如何使用 Security Profiles Operator 各项特性所赋予的全新辅助工具来调试应用程序的 seccomp 配置文件问题。 spoc 是一个灵活且可移植的二进制文件，适用于资源有限的边缘场景，甚至是 Kubernetes 本身可能无法提供其全部功能的场景中。

感谢阅读这篇博文！如果你有兴趣了解更多，想提出反馈或寻求帮助，请通过 Slack (#security-profiles-operator) 或邮件列表直接与我们联系。

Kubernetes 1.27: KMS V2 进入 Beta 阶段

Tue, 16 May 2023 00:00:00 +0000

作者： Anish Ramasekar, Mo Khan, and Rita Zhang (Microsoft)

译者： Xin Li (DaoCloud)

在 Kubernetes 1.27 中，我们（SIG Auth）将密钥管理服务（KMS）v2 API 带入 Beta 阶段。

KMS 是什么？

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

KMS v1 自 1.10 版以来一直是 Kubernetes 的一项功能特性，该特性从 v1.12 版开始处于 Beta 阶段。KMS v2 在 v1.25 中作为 Alpha 特性引入。

Note

KMS v2 API 与实现在 v1.25 的 Alpha 版本和 v1.27 的 Beta 版本之间发生了一些不兼容的变化。自上一篇博文撰写以来， KMS v2 的设计发生了变化，与本博文中的设计不兼容。如果尝试从启用了 Alpha 特性的旧版本升级到 Beta 版本，将会导致数据丢失。

`v2beta1` 有什么新内容？

KMS 加密驱动使用信封加密方式来加密 etcd 中的数据，使用数据加密密钥（DEK）对数据进行加密。 DEK 使用在远程 KMS 中存储和管理的密钥加密密钥（KEK）进行加密。使用 KMS v1，每次加密都会生成一个新的 DEK。使用 KMS v2，只有在服务器启动时且 KMS 插件通知 API 服务器发生 KEK 轮换时才会生成新的 DEK。

警告

如果你运行的是虚拟机（VM）节点，其中启用此特性的节点使用了 VM 的状态存储，则不得使用 KMS v2。

对于 KMS v2，API 服务器使用带有 12 字节随机数（8 字节原子计数器和 4 字节随机数据）的 AES-GCM 进行加密。在保存和恢复虚拟机时，可能会出现以下问题：

如果 VM 的保存状态不一致或其恢复不正确，计数器值可能会丢失或损坏。这可能会导致系统再次使用同一计数器值，进而在两个不同的消息中使用相同的随机数。
如果 VM 恢复到以前的状态，则计数器值可能会设置回其以前的值，导致再次使用相同的随机数。

虽然这两种情况都可以通过 4 字节随机数部分缓解，但这仍可能会危及加密的安全性。

时序图

加密请求

解密请求

状态请求

生成数据加密密钥（DKE）

性能改进

在 KMS v2 中，我们对 KMS 加密提供程序的性能进行了重大改进。对于 KMS v1，每次加密都会生成一个新的 DEK。这意味着对于每个写入请求，API 服务器都会调用 KMS 插件以使用远程 KEK 加密 DEK。为避免每个读取请求都会调用 KMS 插件， API 服务器必须缓存 DEK。当 API 服务器重新启动时，它必须根据缓存大小为 etcd 存储中的每个 DEK 调用 KMS 插件来填充缓存。这对 API 服务器来说是一个很大的开销。使用 KMS v2，API 服务器在启动时生成一个 DEK 并将其缓存。 API 服务器还调用 KMS 插件以使用远程 KEK 加密 DEK。这是启动时和 KEK 轮换时的一次性调用。在此之后，API 服务器使用缓存的 DEK 来加密资源。这样做减少了对 KMS 插件的调用次数，并改善了 API 服务器请求的整体延迟。

我们进行了一项创建 12,000 个 Secret 的测试，并检测了 API 服务器加密资源所花费的时间。使用的指标是 apiserver_storage_transformation_duration_seconds。对于 KMS v1，测试在具有 2 个节点的托管 Kubernetes v1.25 集群上运行。测试期间集群上没有额外的负载。对于 KMS v2，测试是在具有以下集群配置的 Kubernetes CI 环境中运行的

KMS 驱动	95 分位请求所用时间
KMS v1	160ms
KMS v2	80μs

结果表明，KMS v2 加密驱动比 KMS v1 快三个数量级。

下一步计划

对于 Kubernetes v1.28，我们预计该功能仍处于测试阶段。在即将发布的版本中，我们将致力于：

修改加密程序以消除对 VM 状态存储的限制。
针对密钥轮换，修改 Kubernetes REST API 以实现更强大的特性。
处理无法解密的资源，更多细节参考：KEP

你可以通过阅读使用 KMS 驱动进行数据加密，还可以关注 KEP 来跟踪即将发布的 Kubernetes 版本进度。

行动号召

在这篇博文中，我们介绍了 Kubernetes v1.27 中对 KMS 加密驱动所做的改进。我们还讨论了新的 KMS v2 API 及其工作原理。我们很想听听你对此功能的反馈，特别是，我们希望 Kubernetes KMS 插件实现者在构建与这个新 API 的集成过程中得到反馈。请通过 Kubernetes Slack 上的 #sig-auth-kms-dev 频道与我们联系。

如何参与

如果你有兴趣参与此功能的开发、分享反馈或参与任何其他正在进行的 SIG Auth 项目，请联系 Kubernetes Slack 上的 [#sig-auth](https://kubernetes.slack.com/archives /C0EN96KUY) 频道。

也欢迎你加入每两周举行一次的 SIG Auth 会议，每隔一个星期三举行一次。

致谢

此功能是由来自几家不同公司的贡献者推动的，我们非常感谢所有贡献时间和精力帮助实现这一目标的人。

Kubernetes 1.27：关于加快 Pod 启动的进展

Mon, 15 May 2023 00:00:00 +0000

作者：Paco Xu (DaoCloud), Sergey Kanzhelev (Google), Ruiwen Zhao (Google) 译者：Michael Yao (DaoCloud)

如何在大型集群中加快节点上的 Pod 启动？这是集群管理员可能面临的常见问题。

本篇博文重点介绍了从 kubelet 一侧加快 Pod 启动的方法。它不涉及通过 kube-apiserver 由 controller-manager 创建 Pod 所用的时间，也不包括 Pod 的调度时间或在其上执行 Webhook 的时间。

我们从 kubelet 的角度考虑，在本文提到了一些重要的影响因素，但这并不是详尽罗列。随着 Kubernetes v1.27 的发布，本文强调了在 v1.27 中有助于加快 Pod 启动的重大变更。

并行容器镜像拉取

拉取镜像总是需要一些时间的，更糟糕的是，镜像拉取默认是串行作业。换句话说，kubelet 一次只会向镜像服务发送一个镜像拉取请求。其他的镜像拉取请求必须等到正在处理的拉取请求完成。

要启用并行镜像拉取，请在 kubelet 配置中将 serializeImagePulls 字段设置为 false。当 serializeImagePulls 被禁用时，将立即向镜像服务发送镜像拉取请求，并可以并行拉取多个镜像。

设定并行镜像拉取最大值有助于防止节点因镜像拉取而过载

我们在 kubelet 中引入了一个新特性，可以在节点级别设置并行镜像拉取的限值。此限值限制了可以同时拉取的最大镜像数量。如果有个镜像拉取请求超过了这个限值，该请求将被阻止，直到其中一个正在进行的镜像拉取完成为止。在启用此特性之前，请确保容器运行时的镜像服务可以有效处理并行镜像拉取。

要限制并行镜像拉取的数量，你可以在 kubelet 中配置 maxParallelImagePulls 字段。将 maxParallelImagePulls 的值设置为 n 后，并行拉取的镜像数将不能超过 n 个。超过此限值的任何其他镜像拉取请求都需要等到至少一个正在进行的拉取被完成为止。

你可以在关联的 KEP 中找到更多细节： Kubelet 并行镜像拉取数限值 (KEP-3673)。

提高了 kubelet 默认 API 每秒查询限值

为了在节点上具有多个 Pod 的场景中加快 Pod 启动，特别是在突然扩缩的情况下， kubelet 需要同步 Pod 状态并准备 ConfigMap、Secret 或卷。这就需要大带宽访问 kube-apiserver。

在 v1.27 之前的版本中，kubeAPIQPS 的默认值为 5，kubeAPIBurst 的默认值为 10。然而在 v1.27 中，kubelet 为了提高 Pod 启动性能，将这些默认值分别提高到了 50 和 100。值得注意的是，这并不是我们提高 kubelet 的 API QPS 限值的唯一原因。

现在的情况是 API 请求可能会被过度限制（默认 QPS = 5）
在大型集群中，API 请求仍然可能产生相当大的负载，因为数量很多
我们现在可以轻松控制一个专门为此设计的 PriorityLevel 和 FlowSchema

以前在具有 50 个以上 Pod 的节点中，我们经常在 Pod 启动期间在 kubelet 上遇到 volume mount timeout。特别是在使用裸金属节点时，我们建议集群操作员将 kubeAPIQPS 提高到 20，kubeAPIBurst 提高到 40。

更多细节请参阅 KEP https://kep.k8s.io/1040 和 PR#116121。

事件驱动的容器状态更新

在 v1.27 中，Evented PLEG （PLEG 是英文 Pod Lifecycle Event Generator 的缩写，表示 “Pod 生命周期事件生成器”）进阶至 Beta 阶段。Kubernetes 为 kubelet 提供了两种方法来检测 Pod 的生命周期事件，例如容器中最后一个进程关闭。在 Kubernetes v1.27 中，基于事件的 机制已进阶至 Beta，但默认被禁用。如果你显式切换为基于事件的生命周期变更检测，则 kubelet 能够比依赖轮询的默认方法更快地启动 Pod。默认的轮询生命周期变化机制会增加明显的开销，这会影响 kubelet 处理不同任务的并行能力，并导致性能和可靠性问题。出于这些原因，我们建议你将节点切换为使用基于事件的 Pod 生命周期变更检测。

更多细节请参阅 KEP https://kep.k8s.io/3386 和容器状态从轮询切换为基于 CRI 事件更新。

必要时提高 Pod 资源限值

某些 Pod 在启动过程中可能会耗用大量的 CPU 或内存。如果 CPU 限值较低，则可能会显著降低 Pod 启动过程的速度。为了改善内存管理，Kubernetes v1.22 引入了一个名为 MemoryQoS 的特性门控。该特性使 kubelet 能够在容器、Pod 和 QoS 级别上设置内存 QoS，以便更好地保护和确保在运行 CGroup V2 时的内存质量。尽管此特性门控有一定的好处，但如果 Pod 启动消耗大量内存，启用此特性门控可能会影响 Pod 的启动速度。

Kubelet 配置现在包括 memoryThrottlingFactor。该因子乘以内存限制或节点可分配内存，可以设置 cgroupv2 memory.high 值来执行 MemoryQoS。减小该因子将为容器 cgroup 设置较低的上限，同时增加了回收压力。提高此因子将减少回收压力。默认值最初为 0.8，并将在 Kubernetes v1.27 中更改为 0.9。调整此参数可以减少此特性对 Pod 启动速度的潜在影响。

更多细节请参阅 KEP https://kep.k8s.io/2570。

Kubernetes 1.27: 原地调整 Pod 资源 (alpha)

Fri, 12 May 2023 00:00:00 +0000

作者: Vinay Kulkarni (Kubescaler Labs)

译者：Paco Xu (Daocloud)

如果你部署的 Pod 设置了 CPU 或内存资源，你就可能已经注意到更改资源值会导致 Pod 重新启动。以前，这对于运行的负载来说是一个破坏性的操作。

在 Kubernetes v1.27 中，我们添加了一个新的 alpha 特性，允许用户调整分配给 Pod 的 CPU 和内存资源大小，而无需重新启动容器。首先，API 层面现在允许修改 Pod 容器中的 resources 字段下的 cpu 和 memory 资源。资源修改只需 patch 正在运行的 pod 规约即可。

这也意味着 Pod 定义中的 resource 字段不能再被视为 Pod 实际资源的指标。监控程序必须查看 Pod 状态中的新字段来获取实际资源状况。Kubernetes 通过 CRI（Container Runtime Interface，容器运行时接口）API 调用运行时（例如 containerd）来查询实际的 CPU 和内存的请求和限制。容器运行时的响应会反映在 Pod 的状态中。

此外，Pod 中还添加了对应于资源调整的新字段 restartPolicy。这个字段使用户可以控制在资源调整时容器的行为。

1.27 版本有什么新内容?

除了在 Pod 规范中添加调整策略之外，还在 Pod 状态中的 containerStatuses 中添加了一个名为 allocatedResources 的新字段。该字段反映了分配给 Pod 容器的节点资源。

此外，容器状态中还添加了一个名为 resources 的新字段。该字段反映的是如同容器运行时所报告的、针对正运行的容器配置的实际资源 requests 和 limits。

最后，Pod 状态中添加了新字段 resize。resize 字段显示上次请求待处理的调整状态。此字段可以具有以下值：

Proposed：此值表示请求调整已被确认，并且请求已被验证和记录。
InProgress：此值表示节点已接受调整请求，并正在将其应用于 Pod 的容器。
Deferred：此值意味着在此时无法批准请求的调整，节点将继续重试。当其他 Pod 退出并释放节点资源时，调整可能会被真正实施。
Infeasible：此值是一种信号，表示节点无法承接所请求的调整值。如果所请求的调整超过节点可分配给 Pod 的最大资源，则可能会发生这种情况。

何时使用此功能？

以下是此功能可能有价值的一些示例：

正在运行的 Pod 资源限制或者请求过多或过少。
一些过度预配资源的 Pod 调度到某个节点，会导致资源利用率较低的集群上因为 CPU 或内存不足而无法调度 Pod。
驱逐某些需要较多资源的有状态 Pod 是一项成本较高或破坏性的操作。这种场景下，缩小节点中的其他优先级较低的 Pod 的资源，或者移走这些 Pod 的成本更低。

如何使用这个功能

在 v1.27 中使用此功能，必须启用 InPlacePodVerticalScaling 特性门控。可以如下所示启动一个启用了此特性的本地集群：

root@vbuild:~/go/src/k8s.io/kubernetes# FEATURE_GATES=InPlacePodVerticalScaling=true ./hack/local-up-cluster.sh
go version go1.20.2 linux/arm64
+++ [0320 13:52:02] Building go targets for linux/arm64
    k8s.io/kubernetes/cmd/kubectl (static)
    k8s.io/kubernetes/cmd/kube-apiserver (static)
    k8s.io/kubernetes/cmd/kube-controller-manager (static)
    k8s.io/kubernetes/cmd/cloud-controller-manager (non-static)
    k8s.io/kubernetes/cmd/kubelet (non-static)
...
...
Logs:
  /tmp/etcd.log
  /tmp/kube-apiserver.log
  /tmp/kube-controller-manager.log

  /tmp/kube-proxy.log
  /tmp/kube-scheduler.log
  /tmp/kubelet.log

To start using your cluster, you can open up another terminal/tab and run:

  export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
  cluster/kubectl.sh

# Alternatively, you can write to the default kubeconfig:

  export KUBERNETES_PROVIDER=local

  cluster/kubectl.sh config set-cluster local --server=https://localhost:6443 --certificate-authority=/var/run/kubernetes/server-ca.crt
  cluster/kubectl.sh config set-credentials myself --client-key=/var/run/kubernetes/client-admin.key --client-certificate=/var/run/kubernetes/client-admin.crt
  cluster/kubectl.sh config set-context local --cluster=local --user=myself
  cluster/kubectl.sh config use-context local
  cluster/kubectl.sh

一旦本地集群启动并运行，Kubernetes 用户就可以调度带有资源配置的 pod，并通过 kubectl 调整 pod 的资源。以下演示视频演示了如何使用此功能的示例。

示例用例

云端开发环境

在这种场景下，开发人员或开发团队在本地编写代码，但在和生产环境资源配置相同的 Kubernetes pod 中的构建和测试代码。当开发人员编写代码时，此类 Pod 需要最少的资源，但在构建代码或运行一系列测试时需要更多的 CPU 和内存。这个用例可以利用原地调整 pod 资源的功能（在 eBPF 的一点帮助下）快速调整 pod 资源的大小，并避免内核 OOM（内存不足）Killer 终止其进程。

KubeCon North America 2022 会议演讲中详细介绍了上述用例。

Java进程初始化CPU要求

某些 Java 应用程序在初始化期间 CPU 资源使用量可能比正常进程操作期间所需的 CPU 资源多很多。如果此类应用程序指定适合正常操作的 CPU 请求和限制，会导致程序启动时间很长。这样的 pod 可以在创建 pod 时请求更高的 CPU 值。在应用程序完成初始化后，降低资源配置仍然可以正常运行。

已知问题

该功能在 v1.27 中仍然是 alpha 阶段. 以下是用户可能会遇到的一些已知问题：

containerd v1.6.9 以下的版本不具备此功能的所需的 CRI 支持，无法完成端到端的闭环。尝试调整 Pod 大小将显示为卡在 InProgress 状态，并且 Pod 状态中的 resources 字段永远不会更新，即使新资源配置可能已经在正在运行的容器上生效了。
Pod 资源调整可能会遇到与其他 Pod 更新的冲突，导致 pod 资源调整操作被推迟。
可能需要一段时间才能在 Pod 的状态中反映出调整后的容器资源。
此特性与静态 CPU 管理策略不兼容。

致谢

此功能是 Kubernetes 社区高度协作努力的结果。这里是对在这个功能实现过程中，贡献了很多帮助的一部分人的一点点致意。

@thockin 如此细致的 API 设计和严密的代码审核。
@derekwaynecarr 设计简化和 API & Node 代码审核。
@dchen1107 介绍了 Borg 的大量知识，帮助我们避免落入潜在的陷阱。
@ruiwen-zhao 增加 containerd 支持，使得 E2E 能够闭环。
@wangchen615 实现完整的 E2E 测试并推进调度问题修复。
@bobbypage 提供宝贵的帮助，让 CI 准备就绪并快速排查问题，尤其是在我休假时。
@Random-Liu kubelet 代码审查以及定位竞态条件问题。
@Huang-Wei, @ahg-g, @alculquicondor 帮助完成调度部分的修改。
@mikebrow @marosset 帮助我在 v1.25 代码审查并最终合并 CRI 部分的修改。
@endocrimes, @ehashman 帮助确保经常被忽视的测试处于良好状态。
@mrunalp cgroupv2 部分的代码审查并保证了 v1 和 v2 的清晰处理。
@liggitt, @gjkim42 在合并代码后，帮助追踪遗漏的重要问题的根因。
@SergeyKanzhelev 在冲刺阶段支持和解决各种问题。
@pdgetrf 完成了第一个原型。
@dashpole 让我快速了解 Kubernetes 的做事方式。
@bsalamat, @kgolab 在早期阶段提供非常周到的见解和建议。
@sftim, @tengqm 确保文档易于理解。
@dims 无所不在并帮助在关键时刻进行合并。
发布团队确保了项目保持健康。

非常感谢我非常支持的管理层 Xiaoning Ding 博士和 Ying Xiong 博士，感谢他们的耐心和鼓励。

参考

应用程序开发者参考

集群管理员参考

Kubernetes 1.27：为 NodePort Service 分配端口时避免冲突

Thu, 11 May 2023 00:00:00 +0000

作者: Xu Zhenglun (Alibaba)

译者: Michael Yao (DaoCloud)

在 Kubernetes 中，对于以一组 Pod 运行的应用，Service 可以为其提供统一的流量端点。客户端可以使用 Service 提供的虚拟 IP 地址（或 VIP）进行访问， Kubernetes 为访问不同的后端 Pod 的流量提供负载均衡能力，但 ClusterIP 类型的 Service 仅限于供集群内的节点来访问，而来自集群外的流量无法被路由。解决这个难题的一种方式是使用 type: NodePort Service，这种服务会在集群所有节点上为特定端口建立映射关系，从而将来自集群外的流量重定向到集群内。

Kubernetes 如何为 Services 分配节点端口？

当 type: NodePort Service 被创建时，其所对应的端口将以下述两种方式之一分配：

动态分配：如果 Service 类型是 NodePort 且你没有为 Service 显式设置 nodePort 值， Kubernetes 控制面将在创建时自动为其分配一个未使用的端口。
静态分配：除了上述动态自动分配，你还可以显式指定 nodeport 端口范围配置内的某端口。

你手动分配的 nodePort 值在整个集群范围内一定不能重复。如果尝试在创建 type: NodePort Service 时显式指定已分配的节点端口，将产生错误。

为什么需要保留 NodePort Service 的端口？

有时你可能想要 NodePort Service 运行在众所周知的端口上，便于集群内外的其他组件和用户可以使用这些端口。

在某些复杂的集群部署场景中在同一网络上混合了 Kubernetes 节点和其他服务器，可能有必要使用某些预定义的端口进行通信。尤为特别的是，某些基础组件无法使用用来支撑 type: LoadBalancer Service 的 VIP，因为针对集群实现的虚拟 IP 地址映射也依赖这些基础组件。

现在假设你需要在 Kubernetes 上将一个 Minio 对象存储服务暴露给运行在 Kubernetes 集群外的客户端，协商后的端口是 30009，我们需要创建以下 Service：

apiVersion: v1
kind: Service
metadata:
  name: minio
spec:
  ports:
  - name: api
    nodePort: 30009
    port: 9000
    protocol: TCP
    targetPort: 9000
  selector:
    app: minio
  type: NodePort

然而如前文所述，如果 minio Service 所需的端口 (30009) 未被预留，且另一个 type: NodePort（或者也包括 type: LoadBalancer）Service 在 minio Service 之前或与之同时被创建、动态分配，TCP 端口 30009 可能被分配给了这个 Service；如果出现这种情况，minio Service 的创建将由于节点端口冲突而失败。

如何才能避免 NodePort Service 端口冲突？

Kubernetes 1.24 引入了针对 type: ClusterIP Service 的变更，将集群 IP 地址的 CIDR 范围划分为使用不同分配策略的两块来减少冲突的风险。在 Kubernetes 1.27 中，作为一个 Alpha 特性，你可以为 type: NodePort Service 采用类似的策略。你可以启用新的特性门控 ServiceNodePortStaticSubrange。开启此门控将允许你为 type: NodePort Service 使用不同的端口分配策略，减少冲突的风险。

NodePort 的端口范围将基于公式 min(max(16, 节点端口数 / 32), 128) 进行划分。这个公式的结果将是一个介于 16 到 128 的数字，随着节点端口范围变大，步进值也会变大。此公式的结果决定了静态端口范围的大小。当端口范围小于 16 时，静态端口范围的大小将被设为 0，这意味着所有端口都将被动态分配。

动态端口分配默认使用数值较高的一段，一旦用完，它将使用较低范围。这将允许用户在冲突风险较低的较低端口段上使用静态分配。

示例

默认范围：30000-32767

范围属性	值
service-node-port-range	30000-32767
分段偏移量	`min(max(16, 2768/32), 128)` = `min(max(16, 86), 128)` = `min(86, 128)` = 86
起始静态段	30000
结束静态段	30085
起始动态段	30086
结束动态段	32767

pie showData title 30000-32767 "Static" : 86 "Dynamic" : 2682

必须启用 JavaScript 才能查看此页内容

超小范围：30000-30015

范围属性	值
service-node-port-range	30000-30015
分段偏移量	0
起始静态段	-
结束静态段	-
起始动态段	30000
动态动态段	30015

pie showData title 30000-30015 "Static" : 0 "Dynamic" : 16

必须启用 JavaScript 才能查看此页内容

小（下边界）范围：30000-30127

范围属性	值
service-node-port-range	30000-30127
分段偏移量	`min(max(16, 128/32), 128)` = `min(max(16, 4), 128)` = `min(16, 128)` = 16
起始静态段	30000
结束静态段	30015
起始动态段	30016
结束动态段	30127

pie showData title 30000-30127 "Static" : 16 "Dynamic" : 112

必须启用 JavaScript 才能查看此页内容

大（上边界）范围：30000-34095

范围属性	值
service-node-port-range	30000-34095
分段偏移量	`min(max(16, 4096/32), 128)` = `min(max(16, 128), 128)` = `min(128, 128)` = 128
起始静态段	30000
结束静态段	30127
起始动态段	30128
结束动态段	34095

pie showData title 30000-34095 "Static" : 128 "Dynamic" : 3968

必须启用 JavaScript 才能查看此页内容

超大范围：30000-38191

范围属性	值
service-node-port-range	30000-38191
分段偏移量	`min(max(16, 8192/32), 128)` = `min(max(16, 256), 128)` = `min(256, 128)` = 128
起始静态段	30000
结束静态段	30127
起始动态段	30128
结束动态段	38191

pie showData title 30000-38191 "Static" : 128 "Dynamic" : 8064

必须启用 JavaScript 才能查看此页内容

Kubernetes 1.27：kubectl apply 裁剪更安全、更高效

Tue, 09 May 2023 00:00:00 +0000

作者: Katrina Verey（独立个人）和 Justin Santa Barbara (Google)

译者: Michael Yao (DaoCloud)

通过 kubectl apply 命令执行声明式配置管理是创建或修改 Kubernetes 资源的黄金标准方法。但这种方法也带来了一个挑战，那就是删除不再需要的资源。在 Kubernetes 1.5 版本中，引入了 --prune 标志来解决此问题，允许 kubectl apply 自动清理从当前配置中删除的先前应用的资源。

然而，现有的 --prune 实现存在设计缺陷，会降低性能并导致意外行为。主要问题源于先前的 apply 操作未对已应用的集合进行显式编码，有必要进行易错的动态发现。对象泄漏、意外过度选择资源以及与自定义资源的有限兼容性是这种实现的一些明显缺点。此外，其与客户端 apply 的耦合阻碍了用户升级到更优秀的服务器端 apply 方式。

kubectl 的 1.27 版本引入了 Alpha 版本的重构裁剪实现，解决了这些问题。这个基于 ApplySet 概念的新实现承诺能够提供更好的性能和更好的安全性。

ApplySet 是一个与集群上的父对象相关联的资源组，通过标准化的标签和注解进行标识和配置。附加的标准化元数据允许准确标识集群内的 ApplySet 成员对象，简化了裁剪等操作。

为了充分利用基于 ApplySet 的裁剪，设置 KUBECTL_APPLYSET=true 环境变量，并在 kubectl apply 调用中包括标志 --prune 和 --applyset：

KUBECTL_APPLYSET=true kubectl apply -f <目录> --prune --applyset=<name>

默认情况下，ApplySet 使用 Secret 作为父对象。但是，你也可以通过格式 --applyset=configmaps/<name> 来使用 ConfigMap。如果所需的 Secret 或 ConfigMap 对象尚不存在，则 kubectl 将为你创建它。此外，可以启用自定义资源以用作 ApplySet 父对象。

ApplySet 实现基于新的底层规约，可以通过提高其互操作性来支持更高层次的生态系统工具。这种规约的轻量性使得这些工具可以继续使用现有的对象分组系统，同时选用 ApplySet 的元数据约定以防被其他工具（例如 kubectl）意外更改。

基于 ApplySet 的裁剪提供了一种方法，保证有效解决之前 kubectl 中 --prune 实现的缺陷，还可以帮助优化 Kubernetes 资源管理。请使用这个新特性并与社区分享你的经验。 ApplySet 正处于积极开发中，你的反馈至关重要！

如何参与

如果你想参与 ApplySet 的开发，可以联系 SIG CLI 的开发人员。如需提供有关此特性的反馈，请在 kubernetes/kubectl 代码库上提交 bug 或提出增强请求。

Kubernetes 1.27：介绍用于磁盘卷组快照的新 API

Mon, 08 May 2023 00:00:00 +0000

Author: Xing Yang (VMware)

译者: 顾欣

磁盘卷组快照在 Kubernetes v1.27 中作为 Alpha 特性被引入。此特性引入了一个 Kubernetes API，允许用户对多个卷进行快照，以保证在发生故障时数据的一致性。它使用标签选择器来将多个 PersistentVolumeClaims （持久卷申领）分组以进行快照。这个新特性仅支持 CSI 卷驱动器。

磁盘卷组快照概述

一些存储系统提供了创建多个卷的崩溃一致性快照的能力。卷组快照表示在同一时间点从多个卷中生成的“副本”。卷组快照可以用来重新填充新的卷（预先填充快照数据）或者将现有卷恢复到以前的状态（由快照代表）。

为什么要在 Kubernetes 中添加卷组快照？

Kubernetes 的卷插件系统已经提供了一个强大的抽象层，可以自动化块存储和文件存储的制备、挂接、挂载、调整大小和快照等操作。

所有这些特性的出发点是 Kubernetes 对工作负载可移植性的目标： Kubernetes 致力于在分布式应用和底层集群之间创建一个抽象层，使应用可以对承载它们的集群的特殊属性无感，应用部署不需要特定于某集群的知识。

Kubernetes 已经提供了一个 VolumeSnapshot API，这个 API 提供对持久性卷进行快照的能力，可用于防止数据丢失或数据损坏。然而，还有一些其他的快照功能并未被 VolumeSnapshot API 所覆盖。

一些存储系统支持一致性的卷组快照，允许在同一时间点在多个卷上生成快照，以实现写入顺序的一致性。这对于包含多个卷的应用非常有用。例如，应用可能在一个卷中存储数据，在另一个卷中存储日志。如果数据卷和日志卷的快照在不同的时间点进行，应用将不会保持一致，当灾难发生时从这些快照中恢复，应用将无法正常工作。

确实，你可以首先使应用静默，然后依次为构成应用的每个卷中生成一个独立的快照，等所有的快照都已逐个生成后，再取消应用的静止状态。这样你就可以得到应用一致性的快照。

然而，有时可能无法使应用静默，或者使应用静默的代价过高，因此你希望较少地进行这个操作。相较于生成一致性的卷组快照，依次生成单个快照可能需要更长的时间。由于这些原因，有些用户可能不希望经常使应用静默。例如，用户可能希望每周进行一次需要应用静默的备份，而在每晚进行不需应用静默但带有卷组一致性支持的备份，这种一致性支持将确保组中所有卷的崩溃一致性。

Kubernetes 卷组快照 API

Kubernetes 卷组快照引入了三个新的 API 对象用于管理快照：

VolumeGroupSnapshot：由 Kubernetes 用户（或由你的自动化系统）创建，以请求为多个持久卷申领创建卷组快照。它包含了关于卷组快照操作的信息，如卷组快照的生成时间戳以及是否可直接使用。此对象的创建和删除代表了创建或删除集群资源（一个卷组快照）的意愿。

VolumeGroupSnapshotContent：由快照控制器动态生成的 VolumeGroupSnapshot 所创建。它包含了关于卷组快照的信息，包括卷组快照 ID。此对象代表了集群上制备的一个资源（一个卷组快照）。 VolumeGroupSnapshotContent 对象与其创建时所对应的 VolumeGroupSnapshot 之间存在一对一的映射。

VolumeGroupSnapshotClass：由集群管理员创建，用来描述如何创建卷组快照，包括驱动程序信息、删除策略等。

这三种 API 类型被定义为自定义资源（CRD）。这些 CRD 必须在 Kubernetes 集群中安装，以便 CSI 驱动程序支持卷组快照。

如何使用 Kubernetes 卷组快照

卷组快照是在 external-snapshotter 仓库中实现的。实现卷组快照意味着添加或更改几个组件：

添加了新的 CustomResourceDefinition 用于 VolumeGroupSnapshot 和两个辅助性 API。
向通用快照控制器中添加卷组快照控制器的逻辑。
向通用快照验证 webhook 中添加卷组快照验证 webhook 的逻辑。
添加逻辑以便在快照 sidecar 控制器中进行 CSI 调用。

每个集群只部署一次卷快照控制器、CRD 和验证 webhook，而 sidecar 则与每个 CSI 驱动程序一起打包。

因此，将卷快照控制器、CRD 和验证 webhook 作为集群插件部署是合理的。我强烈建议 Kubernetes 发行版的厂商将卷快照控制器、 CRD 和验证 webhook 打包并作为他们的 Kubernetes 集群管理过程的一部分（独立于所有 CSI 驱动）。

使用 Kubernetes 创建新的卷组快照

一旦定义了一个 VolumeGroupSnapshotClass 对象，并且你有想要一起生成快照的卷，就可以通过创建一个 VolumeGroupSnapshot 对象来请求一个新的卷组快照。

卷组快照的源指定了底层的卷组快照是应该动态创建，还是应该使用预先存在的 VolumeGroupSnapshotContent。

预先存在的 VolumeGroupSnapshotContent 由集群管理员创建。其中包含了在存储系统上实际卷组快照的细节，这些卷组快照可供集群用户使用。

在卷组快照源中，必须设置以下成员之一。

selector - 针对要一起生成快照的 PersistentVolumeClaims 的标签查询。该 labelSelector 将用于匹配添加到 PVC 上的标签。
volumeGroupSnapshotContentName - 指定一个现有的 VolumeGroupSnapshotContent 对象的名称，该对象代表着一个已存在的卷组快照。

在以下示例中，有两个 PVC。

NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
pvc-0       Bound     pvc-a42d7ea2-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
pvc-1       Bound     pvc-a42d81b8-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s

标记 PVC。

% kubectl label pvc pvc-0 group=myGroup
persistentvolumeclaim/pvc-0 labeled

% kubectl label pvc pvc-1 group=myGroup
persistentvolumeclaim/pvc-1 labeled

对于动态制备，必须设置一个选择算符，以便快照控制器可以找到带有匹配标签的 PVC，一起进行快照。

apiVersion: groupsnapshot.storage.k8s.io/v1alpha1
kind: VolumeGroupSnapshot
metadata:
  name: new-group-snapshot-demo
  namespace: demo-namespace
spec:
  volumeGroupSnapshotClassName: csi-groupSnapclass
  source:
    selector:
      matchLabels:
        group: myGroup

在 VolumeGroupSnapshot 的规约中，用户可以指定 VolumeGroupSnapshotClass，其中包含应使用哪个 CSI 驱动程序来创建卷组快照的信息。

作为创建卷组快照的一部分，将创建两个单独的卷快照。

snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2.20.4
snapshot-2026811eb9f0787466171fe189c805a22cdb61a326235cd067dc3a1ac0104900-2023-04-26-2.20.4

如何在 Kubernetes 中使用卷组快照进行恢复

在恢复时，用户可以请求某 VolumeGroupSnapshot 的一部分，即某个 VolumeSnapshot 对象，创建一个新的 PersistentVolumeClaim。这将触发新卷的制备过程，并使用指定快照中的数据进行预填充。用户应该重复此步骤，直到为卷组快照的所有部分创建了所有卷。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc0-restore
  namespace: demo-namespace
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2.20.4
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

作为一个存储供应商，我应该如何为我的 CSI 驱动程序添加对卷组快照的支持？

要实现卷组快照功能，CSI 驱动必须：

实现一个新的组控制器服务。
实现组控制器的 RPC：CreateVolumeGroupSnapshot，DeleteVolumeGroupSnapshot 和 GetVolumeGroupSnapshot。
添加组控制器的特性 CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT。

更多详情请参阅 CSI规范和 Kubernetes-CSI驱动程序开发指南。

对于 CSI 卷驱动程序，它提供了一种建议采用的机制来部署容器化的 CSI 驱动程序以简化流程。

作为所推荐的部署过程的一部分，Kubernetes 团队提供了许多 sidecar（辅助）容器，包括已经更新以支持卷组快照的 external-snapshotter sidecar 容器。

external-snapshotter 会监听 Kubernetes API 服务器上的 VolumeGroupSnapshotContent 对象，并对 CSI 端点触发 CreateVolumeGroupSnapshot 和 DeleteVolumeGroupSnapshot 操作。

有哪些限制？

Kubernetes 的卷组快照的 Alpha 版本具有以下限制：

不支持将现有的 PVC 还原到由快照表示的较早状态（仅支持从快照创建新的卷）。
除了存储系统提供的保证（例如崩溃一致性）之外，不提供应用一致性保证。请参阅此文档，了解有关应用一致性的更多讨论。

下一步是什么？

根据反馈和采用情况，Kubernetes 团队计划在 1.28 或 1.29 版本中将 CSI 卷组快照实现推进到 Beta 阶段。我们有兴趣支持的一些功能包括卷复制、复制组、卷位置选择、应用静默、变更块跟踪等等。

如何获取更多信息？

有关卷组快照功能的设计规约。
卷组快照 API 和控制器的代码仓库。
CSI 关于卷组快照功能的文档。

如何参与其中？

这个项目，就像 Kubernetes 的所有项目一样，是许多不同背景的贡献者共同努力的结果。我代表 SIG Storage，向在过去几个季度中积极参与项目并帮助项目达到 Alpha 版本的贡献者们表示衷心的感谢：

Alex Meade (ameade)
Ben Swartzlander (bswartz)
Humble Devassy Chirammal (humblec)
James Defelice (jdef)
Jan Šafránek (jsafrane)
Jing Xu (jingxu97)
Michelle Au (msau42)
Niels de Vos (nixpanic)
Rakshith R (Rakshith-R)
Raunak Shah (RaunakShah)
Saad Ali (saad-ali)
Thomas Watson (rbo54)
Xing Yang (xing-yang)
Yati Padia (yati1998)

我们还要感谢其他为该项目做出贡献的人，包括帮助审核 KEP和 CSI 规约 PR的其他人员。

对于那些对参与 CSI 设计和开发或 Kubernetes 存储系统感兴趣的人，欢迎加入 Kubernetes存储特别兴趣小组（SIG）。我们随时欢迎新的贡献者。

我们还定期举行数据保护工作组会议。欢迎新的与会者加入我们的讨论。

Kubernetes 1.27：内存资源的服务质量（QoS）Alpha

Fri, 05 May 2023 00:00:00 +0000

作者：Dixita Narang (Google)

译者：Wilson Wu (DaoCloud)

Kubernetes v1.27 于 2023 年 4 月发布，引入了对内存 QoS（Alpha）的更改，用于提高 Linux 节点中的内存管理功能。

对内存 QoS 的支持最初是在 Kubernetes v1.22 中添加的，后来发现了关于计算 memory.high 公式的一些不足。这些不足在 Kubernetes v1.27 中得到解决。

背景

Kubernetes 允许你在 Pod 规约中设置某容器对每类资源的需求。通常要设置的资源是 CPU 和内存。

例如，定义容器资源需求的 Pod 清单可能如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "64Mi"
        cpu: "500m"

spec.containers[].resources.requests

当你为 Pod 中的容器设置资源请求时， Kubernetes 调度器使用此信息来决定将 Pod 放置在哪个节点上。调度器确保对于每种资源类型，已调度容器的资源请求总和小于节点上可分配资源的总量。
spec.containers[].resources.limits

当你为 Pod 中的容器设置资源限制时，kubelet 会强制实施这些限制，以便运行的容器使用的资源不得超过你设置的限制。

当 kubelet 将容器作为 Pod 的一部分启动时，kubelet 会将容器的 CPU 和内存请求和限制传递给容器运行时。容器运行时将 CPU 请求和 CPU 限制设置到容器上。如果系统有空闲的 CPU 时间，就保证为容器分配它们请求的 CPU 数量。容器使用的 CPU 数量不能超过配置的限制，即，如果容器在给定时间片内使用的 CPU 数量超过指定的限制，则容器的 CPU 使用率将受到限制。

在内存 QoS 特性出现之前，容器运行时仅使用内存限制并忽略内存的 request （请求值从前到现在一直被用于影响调度）。如果容器使用的内存超过所配置的限制，则会调用 Linux 内存不足（OOM）杀手机制。

让我们比较一下在有和没有内存 QoS 特性时，Linux 上的容器运行时通常如何在 cgroup 中配置内存请求和限制：

内存请求

内存请求主要由 kube-scheduler 在（Kubernetes）Pod 调度时使用。在 cgroups v1 中，没有任何控件来设置 cgroup 必须始终保留的最小内存量。因此，容器运行时不使用 Pod 规约中设置的内存请求值。

cgroups v2 中引入了一个 memory.min 设置，用于设置给定 cgroup 中的进程确定可用的最小内存量。如果 cgroup 的内存使用量在其有效最小边界内，则该 cgroup 的内存在任何情况下都不会被回收。如果内核无法为 cgroup 中的进程维护至少 memory.min 字节的内存，内核将调用其 OOM 杀手机制。换句话说，内核保证至少有这么多内存可用，或者终止进程（可能在 cgroup 之外）以腾出更多内存。 MemoryQoS 机制将 memory.min 映射到 spec.containers[].resources.requests.memory，以确保 Kubernetes Pod 中容器的内存可用性。

内存限制

memory.limit 指定内存限制，如果容器尝试分配更多内存，超出该限制， Linux 内核将通过 OOM（内存不足）来杀死并终止进程。如果终止的进程是容器内的主（或唯一）进程，则容器可能会退出。

在 cgroups v1 中，memory.limit_in_bytes 接口用于设置内存用量限制。然而，与 CPU 不同的是，内存用量是无法抑制的：一旦容器超过内存限制，它就会被 OOM 杀死。

在 cgroups v2 中，memory.max 类似于 cgroupv1 中的 memory.limit_in_bytes。 MemoryQoS 机制将 memory.max 映射到 spec.containers[].resources.limits.memory 以设置内存用量的硬性限制。如果内存消耗超过此水平，内核将调用其 OOM 杀手机制。

cgroups v2 中还添加了 memory.high 配置。MemoryQoS 机制使用 memory.high 来设置内存用量抑制上限。如果超出了 memory.high 限制，则违规的 cgroup 会受到抑制，并且内核会尝试回收内存，这可能会避免 OOM 终止。

如何工作

Cgroups v2 内存控制器接口和 Kubernetes 容器资源映

MemoryQoS 机制使用 cgroups v2 的内存控制器来保证 Kubernetes 中的内存资源。此特性使用的 cgroupv2 接口有：

memory.max
memory.min
memory.high

内存 QoS 级别

memory.max 映射到 Pod 规约中指定的 limits.memory。 kubelet 和容器运行时在对应的 cgroup 中配置限制值。内核强制执行限制机制以防止容器用量超过所配置的资源限制。如果容器中的进程尝试消耗的资源超过所设置的限制值，内核将终止进程并报告内存不足（OOM）错误。

memory.max 映射到 limit.memory

memory.min 被映射到 requests.memory，这会导致内存资源被预留而永远不会被内核回收。这就是 MemoryQoS 机制确保 Kubernetes Pod 内存可用性的方式。如果没有不受保护的、可回收的内存，则内核会调用 OOM 杀手以提供更多可用内存。

memory.min 映射到 requests.memory

对于内存保护，除了原来的限制内存用量的方式之外，MemoryQoS 机制还会对用量接近其内存限制的工作负载进行抑制，确保系统不会因内存使用的零星增加而不堪重负。当你启用 MemoryQoS 特性时， KubeletConfiguration 中将提供一个新字段 memoryThrottlingFactor。默认设置为 0.9。 memory.high 被映射到通过 memoryThrottlingFactor、requests.memory 和 limits.memory 计算得出的抑制上限，计算方法如下式所示，所得的值向下舍入到最接近的页面大小：

memory.high 公式

注意：如果容器没有指定内存限制，则 limits.memory 将被替换为节点可分配内存的值。

总结：

文件	描述
memory.max	`memory.max` 指定允许容器使用的最大内存限制。如果容器内的进程尝试使用的内存量超过所配置的限制值，内核将终止该进程并显示内存不足（OOM）错误。此配置映射到 Pod 清单中指定的容器内存限制。
memory.min	`memory.min` 指定 cgroup 必须始终保留的最小内存量，即系统永远不应回收的内存。如果没有可用的未受保护的可回收内存，则会调用 OOM 终止程序。此配置映射到 Pod 清单中指定的容器的内存请求。
memory.high	`memory.high` 指定内存用量抑制上限。这是控制 cgroup 内存用量的主要机制。如果 cgroups 内存使用量超过此处指定的上限，则 cgroups 进程将受到抑制并标记回收压力较大。 Kubernetes 使用公式来计算 `memory.high`，具体取决于容器的内存请求、内存限制或节点可分配内存（如果容器的内存限制为空）和抑制因子。有关公式的更多详细信息，请参阅 KEP。

注意：memory.high 仅可在容器级别的 cgroups 上设置，而 memory.min 则可在容器、Pod 和节点级别的 cgroups 上设置。

针对 cgroup 层次结构的 `memory.min` 计算

当发出容器内存请求时，kubelet 在创建容器期间通过 CRI 中的 Unified 字段将 memory.min 传递给后端 CRI 运行时（例如 containerd 或 CRI-O）。容器级别 cgroup 中的 memory.min 将设置为：

$memory.min = pod.spec.containers[i].resources.requests[memory]$

_{对于 Pod 中每个 i^th 容器}

由于 memory.min 接口要求祖先 cgroups 目录全部被设置，因此需要正确设置 Pod 和节点的 cgroups 目录。

Pod 级别 cgroup 中的 memory.min：

$memory.min = \sum_{i=0}^{no. of pods}pod.spec.containers[i].resources.requests[memory]$

_{对于 Pod 中每个 i^th 容器}

节点级别 cgroup 中的 memory.min：

$memory.min = \sum_{i}^{no. of nodes}\sum_{j}^{no. of pods}pod[i].spec.containers[j].resources.requests[memory]$

_{对于节点中每个 i^th Pod 中的每个 j^th 容器}

Kubelet 将直接使用 libcontainer 库（来自 runc 项目）管理 Pod 级别和节点级别 cgroups 的层次结构，而容器 cgroups 限制由容器运行时管理。

支持 Pod QoS 类别

根据用户对 Kubernetes v1.22 中 Alpha 特性的反馈，一些用户希望在 Pod 层面选择不启用 MemoryQoS，以确保不会出现早期内存抑制现象。因此，在 Kubernetes v1.27 中 MemoryQoS 还支持根据服务质量（QoS）对 Pod 类设置 memory.high。以下是按 QoS 类设置 memory.high 的几种情况：

Guaranteed Pods：根据其 QoS 定义，要求 Pod 的内存请求等于其内存限制，并且不允许超配。因此，通过不设置 memory.high，MemoryQoS 特性会针对这些 Pod 被禁用。这样做可以确保 Guaranteed Pod 充分利用其内存请求，也就是其内存限制，并且不会被抑制。

Burstable Pod：根据其 QoS 定义，要求 Pod 中至少有一个容器具有 CPU 或内存请求或限制设置。

当 requests.memory 和 limits.memory 都被设置时，公式按原样使用：

 
     
          
                 当请求和限制被设置时的 memory.high

当设置了 requests.memory 但未设置 limits.memory 时，公式中的 limits.memory 替换为节点可分配内存：

 
     
          
                 当请求和限制未被设置时的 memory.high

BestEffort Pod：根据其 QoS 定义，不需要设置内存或 CPU 限制或请求。对于这种情况， kubernetes 设置 requests.memory = 0 并将公式中的 limits.memory 替换为节点可分配内存：

BestEffort Pod 的 memory.high

总结：只有 Burstable 和 BestEffort QoS 类别中的 Pod 才会设置 memory.high。 Guaranteed QoS 的 Pod 不会设置 memory.high，因为它们的内存是有保证的。

我该如何使用它？

在 Linux 节点上启用 MemoryQoS 特性的先决条件是：

验证是否满足 Kubernetes 对 cgroup v2 支持的相关要求。
确保 CRI 运行时支持内存 QoS。在撰写本文时，只有 Containerd 和 CRI-O 提供与内存 QoS（alpha）兼容的支持。是在以下 PR 中实现的：
- Containerd：Feature: containerd-cri support LinuxContainerResources.Unified #5627。
- CRI-O：implement kube alpha features for 1.22 #5207。

MemoryQoS 在 Kubernetes v1.27 中仍然是 Alpha 特性。你可以通过在 kubelet 配置文件中设置 MemoryQoS=true 来启用该特性：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: true

我如何参与？

非常感谢所有帮助设计、实施和审查此功能的贡献者：

Dixita Narang (ndixita)
Tim Xu (xiaoxubeii)
Paco Xu (pacoxu)
David Porter(bobbypage)
Mrunal Patel(mrunalp)

对于那些有兴趣参与未来内存 QoS 特性讨论的人，你可以通过多种方式联系 SIG Node：

Kubernetes 1.27: StatefulSet PVC 自动删除(beta)

Thu, 04 May 2023 00:00:00 +0000

作者：Matthew Cary (Google)

译者：顾欣 (ICBC)

Kubernetes v1.27 将一种新的策略机制升级到 Beta 阶段，这一策略用于控制 StatefulSets 的 PersistentVolumeClaims（PVCs）的生命周期。这种新的 PVC 保留策略允许用户指定当删除 StatefulSet 或者缩减 StatefulSet 中的副本时，是自动删除还是保留从 StatefulSet 规约模板生成的 PVC。

所解决的问题

StatefulSet 规约可以包含 Pod 和 PVC 模板。当首次创建副本时，Kubernetes 控制平面会为该副本创建一个 PVC （如果不存在）。在 PVC 保留策略出现之前，控制平面不会清理为 StatefulSets 创建的 PVC，该任务通常由集群管理员负责，或者通过一些附加的自动化工具来处理。你需要寻找这些工具，并检查其适用性，然后进行部署。通常管理 PVC 的常见模式，无论是手动管理还是通过诸如 Helm 等工具进行管理，都是由负责管理它们的工具跟踪，具有明确的生命周期。使用 StatefulSets 的工作流必须自行确定由 StatefulSet 创建的 PVC，并确定其生命周期。

在引入这个新特性之前，当一个由 StatefulSet 管理的副本消失时，无论是因为 StatefulSet 正在减少其副本数量，还是因为其 StatefulSet 被删除， PVC 及其支持卷仍然存在，必须手动删除。尽管在数据至关重要时这种行为是合适的，但在许多情况下，这些 PVC 中的持久数据要么是临时的，要么可以从其他来源重建。在这些情况下，删除 StatefulSet 或副本后仍保留 PVC 及其支持卷是不必要的，这会产生成本，并且需要手动清理。

新的 `StatefulSet` PVC 保留策略

新的 StatefulSet PVC 保留策略用于控制是否以及何时删除从 StatefulSet 的 volumeClaimTemplate 创建的 PVC。有两种情况可能需要就此作出决定。

第一种是当删除 StatefulSet 资源时（意味着所有副本也会被删除）。这时的行为由 whenDeleted 策略控制。第二种场景由 whenScaled 控制，即当 StatefulSet 缩减规模时，它会移除一部分而不是全部副本。在这两种情况下，策略可以是 Retain，表示相应的 PVC 不受影响，或者是 Delete，表示 PVC 将被删除。删除操作是通过普通的对象删除完成的，这样可以确保对底层 PV 的所有保留策略都得到遵守。

这个策略形成了一个矩阵，包括四种情况。接下来，我将逐一介绍每种情况并给出一个示例。

whenDeleted 和 whenScaled 都是 Retain。

这与现有的 StatefulSets 行为相匹配，所有 PVC 都不会被删除。这也是默认的保留策略。当 StatefulSet 卷上的数据可能是不可替代的，并且应该仅在手动情况下删除时，这种策略是适当的。

whenDeleted 是 Delete，whenScaled 是 Retain。

在这种情况下，只有在整个 StatefulSet 被删除时，PVC 才会被删除。如果 StatefulSet 进行缩减操作，PVC 将不会受到影响，这意味着如果缩减后再进行扩展，并且使用了来自之前副本的任何数据，PVC 可以被重新关联。这种情况适用于临时的 StatefulSet，例如在 CI 实例或 ETL 流水线中，StatefulSet 上的数据只在其生命周期内需要，但在任务运行时，数据不容易重建。对于先被缩容后被扩容的副本而言，所有已保留的状态都是需要的。

whenDeleted 和 whenScaled 都是 Delete。

当副本不再需要时，PVC 会立即被删除。需要注意的是，这不包括当删除一个 Pod 并重新调度一个新版本时的情况，例如当一个节点被排空并且 Pods 需要迁移到其他地方时。只有在副本不再被需要时，即通过缩减规模或删除 StatefulSet 时，PVC 才会被删除。这种情况适用于数据不需要在其副本的生命周期之外存在的情况。也许数据很容易重建，删除未使用的 PVC 可以节省成本比快速扩展更重要，或者当创建一个新副本时，来自前一个副本的任何数据都无法使用，必须进行重建。

whenDeleted 是 Retain，whenScaled 是 Delete。

这与前面的情况类似，保留 PVC 以便在扩容时进行快速重用的好处微乎其微。一个使用这种策略的例子是 Elasticsearch 集群。通常，你会根据需求调整该工作负载的规模，同时确保有一定数量的副本（例如：3个）一直存在。在缩容时，数据会从被删除的副本迁移走，保留这些 PVC 没有好处。然而，如果需要临时关闭整个 Elasticsearch 集群进行维护，可以通过暂时删除 StatefulSet 然后重建 StatefulSet 来恢复 Elasticsearch 集群。持有 Elasticsearch 数据的 PVC 仍然存在，新的副本将自动使用它们。

请访问文档以查看所有详细信息。

下一步是什么？

试一试吧！在 Kubernetes 1.27 的集群中，StatefulSetAutoDeletePVC 特性门控是 Beta 阶段，使用新的策略创建一个 StatefulSet，进行测试并告诉我们你的想法！

我非常好奇这个所有者引用机制在实践中是否运行良好。例如，我意识到在 Kubernetes 中没有机制可以知道是谁设置了引用，因此 StatefulSet 控制器可能会与设置自己引用的自定义控制器产生冲突。幸运的是，保持现有的保留行为不涉及任何新的所有者引用，因此默认行为将是兼容的。

请在你报告的任何 issue 上标记标签 sig/apps，并将它们指派给 Matthew Cary (@mattcary at GitHub)。

祝您使用愉快！

Kubernetes 1.27：HorizontalPodAutoscaler ContainerResource 类型指标进阶至 Beta

Tue, 02 May 2023 12:00:00 +0800

作者: Kensei Nakada (Mercari)

译者: Michael Yao (DaoCloud)

Kubernetes 1.20 在 HorizontalPodAutoscaler (HPA) 中引入了 ContainerResource 类型指标。

在 Kubernetes 1.27 中，此特性进阶至 Beta，相应的特性门控 (HPAContainerMetrics) 默认被启用。

什么是 ContainerResource 类型指标

ContainerResource 类型指标允许我们根据各个容器的资源使用量来配置自动扩缩。

在下面的示例中，HPA 控制器扩缩目标，以便所有 Pod 的应用程序容器的 CPU 平均利用率约为 60％（请参见算法详情以了解预期副本数的确切计算方式）。

type: ContainerResource
containerResource:
  name: cpu
  container: application
  target:
    type: Utilization
    averageUtilization: 60

与 Resource 类型指标的区别

HPA 已具有 Resource 类型指标。

你可以定义如下的目标资源利用率，然后 HPA 将基于当前利用率扩缩副本。

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

但这个 Resource 类型指标指的是 Pod 的平均利用率。

如果一个 Pod 有多个容器，则利用率计算公式为：

sum{每个容器的资源使用量} / sum{每个容器的资源请求}

每个容器的资源利用率可能没有直接关系，或可能随着负载变化而以不同的速度增长。

例如：

边车容器仅提供日志传输这类辅助服务。如果应用程序不经常记录日志或在其频繁执行的路径中不生成日志，则日志发送器的使用量不会增长。
提供身份验证的边车容器。由于重度缓存，当主要容器的负载增加时，使用量只会略微增加。在当前的混合用量计算方法中，这通常导致 HPA 不会对 Deployment 向上扩容，因为混合的使用量仍然很低。
边车可能在未设置资源的情况下被注入，这会阻止基于利用率进行扩缩。在当前的逻辑中，当未设置资源请求时，HPA 控制器只能根据 Pod 的绝对资源使用量进行扩缩。

在这种情况下，如果仅有一个容器的资源利用率增加，则 Resource 类型指标可能不会建议扩容。

因此，为了实现准确的自动扩缩，你可能需要改为使用 ContainerResource 类型指标来替代这些 Pod。

Beta 版本有哪些新内容？

在 Kubernetes v1.27 中，正如本文开头所述，ContainerResource 类型指标默认可用。（你仍然可以通过 HPAContainerMetrics 特性门禁用它。）

另外，我们已通过从 kube-controller-manager 中公开一些指标来改进 HPA 控制器的可观测性：

metric_computation_total：指标计算的数量。
metric_computation_duration_seconds：HPA 控制器计算一个指标所需的时间。
reconciliations_total：HPA 控制器的协调次数。
reconciliation_duration_seconds：HPA 控制器协调一次 HPA 对象所需的时间。

这些指标具有 action（scale_up、scale_down、none）和 error（spec、internal、none）标签。除此之外，前两个指标还具有 metric_type 标签，该标签对应于 HorizontalPodAutoscaler 的 .spec.metrics[*].type。

所有指标都可用于 HPA 控制器的常规监控，你可以深入洞察哪部分存在问题，在哪里耗时，集群在哪个时间倾向于发生多少次扩缩等问题。

另一件小事是，我们已更改了 SuccessfulRescale 事件的消息，这样每个人都可以检查事件是否来自资源指标或容器资源指标（请参见相关 PR）。

参与其中

此特性由 SIG Autoscaling 进行管理。请加入我们分享反馈。我们期待聆听你的声音！

了解更多

Kubernetes 1.27: StatefulSet 启动序号简化了迁移

Fri, 28 Apr 2023 00:00:00 +0000

作者： Peter Schuurman (Google)

译者： Xin Li (DaoCloud)

Kubernetes v1.26 为 StatefulSet 引入了一个新的 Alpha 级别特性，可以控制 Pod 副本的序号。从 Kubernetes v1.27 开始，此特性进级到 Beta 阶段。序数可以从任意非负数开始，这篇博文将讨论如何使用此功能。

背景

StatefulSet 序号为 Pod 副本提供顺序标识。当使用 OrderedReady Pod 管理策略时， Pod 是从序号索引 0 到 N-1 顺序创建的。

如今使用 Kubernetes 跨集群编排 StatefulSet 迁移具有挑战性。虽然存在备份和恢复解决方案，但这些解决方案需要在迁移之前将应用程序的副本数缩为 0。在当今这个完全互联的世界中，即使是计划内的应用停机可能也无法实现你的业务目标。

你可以使用级联删除或 OnDelete 策略来迁移单个 Pod，但是这很容易出错并且管理起来很乏味。当你的 Pod 出现故障或被逐出时，你将失去 StatefulSet 控制器的自我修复优势。

Kubernetes v1.26 使 StatefulSet 能够负责 {0..N-1} 范围内的一系列序数（序数 0、1、... 直到 N-1）。有了它，你可以缩小源集群中的范围 {0..k-1}，并扩大目标集群中的互补范围 {k..N-1}，同时保证应用程序可用性。这使你在编排跨集群迁移时保留至多一个语义（意味着最多有一个具有给定身份的 Pod 在 StatefulSet 中运行）和[滚动更新](/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/#rolling-update）行为。

我为什么要使用此功能？

假设你在一个集群中运行 StatefulSet，并且需要将其迁移到另一个集群。你需要这样做的原因有很多：

可扩展性：你的 StatefulSet 对于你的集群而言规模过大，并且已经开始破坏集群中其他工作负载的服务质量。
隔离性：你在一个供多个用户访问的集群中运行 StatefulSet，而命名空间隔离是不够的。
集群配置：你想将 StatefulSet 迁移到另一个集群，以使用在当前集群上不存在的某些环境。
控制平面升级：你想将 StatefulSet 迁移到运行着较高版本控制平面，并且无法处承担就地升级控制平面所产生的风险或预留停机时间。

我该如何使用它？

在集群上启用 StatefulSetStartOrdinal 特性门控，并使用自定义的 .spec.ordinals.start 创建一个 StatefulSet。

试试看吧

在此演示中，我将使用新机制将 StatefulSet 从一个 Kubernetes 集群迁移到另一个。 redis-cluster Bitnami Helm chart 将用于安装 Redis。

所需工具：

yq
helm

先决条件

为此，我需要两个可以访问公共网络和存储的 Kubernetes 集群；我已将集群命名为 source 和 destination。具体来说，我需要：

在两个集群上都启用 StatefulSetStartOrdinal 特性门控。
kubectl 的客户端配置允许我以管理员身份访问这两个集群。
两个集群上都安装了相同的 StorageClass，并设置为两个集群的默认 StorageClass。这个 StorageClass 应该提供可从一个或两个集群访问的底层存储。
一种扁平的网络拓扑，允许 Pod 向任一集群中的 Pod 发送数据包和从中接收数据包。如果你在云提供商上创建集群，则此配置可能被称为私有云或私有网络。

在两个集群上创建一个用于演示的命名空间：
```
kubectl create ns kep-3335
```

在 source 集群中部署一个有六个副本的 Redis 集群：

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install redis --namespace kep-3335 \
  bitnami/redis-cluster \
  --set persistence.size=1Gi \
  --set cluster.nodes=6

检查 source 集群中的副本状态：

kubectl exec -it redis-redis-cluster-0 -- /bin/bash -c \
  "redis-cli -c -h redis-redis-cluster -a $(kubectl get secret redis-redis-cluster -o jsonpath="{.data.redis-password}" | base64 -d) CLUSTER NODES;"

2ce30362c188aabc06f3eee5d92892d95b1da5c3 10.104.0.14:6379@16379 myself,master - 0 1669764411000 3 connected 10923-16383                                                                                                                                              
7743661f60b6b17b5c71d083260419588b4f2451 10.104.0.16:6379@16379 slave 2ce30362c188aabc06f3eee5d92892d95b1da5c3 0 1669764410000 3 connected                                                                                             
961f35e37c4eea507cfe12f96e3bfd694b9c21d4 10.104.0.18:6379@16379 slave a8765caed08f3e185cef22bd09edf409dc2bcc61 0 1669764411000 1 connected                                                                                                             
7136e37d8864db983f334b85d2b094be47c830e5 10.104.0.15:6379@16379 slave 2cff613d763b22c180cd40668da8e452edef3fc8 0 1669764412595 2 connected                                                                                                                    
a8765caed08f3e185cef22bd09edf409dc2bcc61 10.104.0.19:6379@16379 master - 0 1669764411592 1 connected 0-5460                                                                                                                                                   
2cff613d763b22c180cd40668da8e452edef3fc8 10.104.0.17:6379@16379 master - 0 1669764410000 2 connected 5461-10922

在 destination 集群中部署一个零副本的 Redis 集群：

helm install redis --namespace kep-3335 \
  bitnami/redis-cluster \
  --set persistence.size=1Gi \
  --set cluster.nodes=0 \
  --set redis.extraEnvVars\[0\].name=REDIS_NODES,redis.extraEnvVars\[0\].value="redis-redis-cluster-headless.kep-3335.svc.cluster.local" \
  --set existingSecret=redis-redis-cluster

将源集群中的 redis-redis-cluster StatefulSet 副本数缩小 1，以删除副本 redis-redis-cluster-5：
```
kubectl patch sts redis-redis-cluster -p '{"spec": {"replicas": 5}}'
```

将依赖从 source 集群迁移到 destionation 集群：以下命令将依赖资源从 source 复制到 destionation，其中与 destionation 集群无关的详细信息已被删除（例如：uid、resourceVersion、status）。

说明：如果使用配置了 reclaimPolicy: Delete 的 StorageClass，你应该在删除之前使用 reclaimPolicy: Retain 修补 source 中的 PV，以保留 destination 中使用的底层存储。有关详细信息，请参阅更改 PersistentVolume 的回收策略。
```
kubectl get pvc redis-data-redis-redis-cluster-5 -o yaml | yq 'del(.metadata.uid, .metadata.resourceVersion, .metadata.annotations, .metadata.finalizers, .status)' > /tmp/pvc-redis-data-redis-redis-cluster-5.yaml
kubectl get pv $(yq '.spec.volumeName' /tmp/pvc-redis-data-redis-redis-cluster-5.yaml) -o yaml | yq 'del(.metadata.uid, .metadata.resourceVersion, .metadata.annotations, .metadata.finalizers, .spec.claimRef, .status)' > /tmp/pv-redis-data-redis-redis-cluster-5.yaml
kubectl get secret redis-redis-cluster -o yaml | yq 'del(.metadata.uid, .metadata.resourceVersion)' > /tmp/secret-redis-redis-cluster.yaml
```
destination 集群中的步骤

说明：对于 PV/PVC，此过程仅在你的 PV 使用的底层存储系统支持复制到 destination 集群时才有效。可能不支持与特定节点或拓扑关联的存储。此外，某些存储系统可能会在 PV 对象之外存储有关卷的附加元数据，并且可能需要更专门的序列来导入卷。
```
kubectl create -f /tmp/pv-redis-data-redis-redis-cluster-5.yaml
kubectl create -f /tmp/pvc-redis-data-redis-redis-cluster-5.yaml
kubectl create -f /tmp/secret-redis-redis-cluster.yaml
```

将 destination 集群中的 redis-redis-cluster StatefulSet 扩容 1，起始序号为 5：

kubectl patch sts redis-redis-cluster -p '{"spec": {"ordinals": {"start": 5}, "replicas": 1}}'

检查 destination 集群中的副本状态：

kubectl exec -it redis-redis-cluster-5 -- /bin/bash -c \
  "redis-cli -c -h redis-redis-cluster -a $(kubectl get secret redis-redis-cluster -o jsonpath="{.data.redis-password}" | base64 -d) CLUSTER NODES;"

我应该看到新副本（标记为 myself）已加入 Redis 集群（IP 地址与 source 集群中的副本归属于不同的 CIDR 块）。

2cff613d763b22c180cd40668da8e452edef3fc8 10.104.0.17:6379@16379 master - 0 1669766684000 2 connected 5461-10922
7136e37d8864db983f334b85d2b094be47c830e5 10.108.0.22:6379@16379 myself,slave 2cff613d763b22c180cd40668da8e452edef3fc8 0 1669766685609 2 connected
2ce30362c188aabc06f3eee5d92892d95b1da5c3 10.104.0.14:6379@16379 master - 0 1669766684000 3 connected 10923-16383
961f35e37c4eea507cfe12f96e3bfd694b9c21d4 10.104.0.18:6379@16379 slave a8765caed08f3e185cef22bd09edf409dc2bcc61 0 1669766683600 1 connected
a8765caed08f3e185cef22bd09edf409dc2bcc61 10.104.0.19:6379@16379 master - 0 1669766685000 1 connected 0-5460
7743661f60b6b17b5c71d083260419588b4f2451 10.104.0.16:6379@16379 slave 2ce30362c188aabc06f3eee5d92892d95b1da5c3 0 1669766686613 3 connected

对剩余的副本重复 #5 到 #7 的步骤，直到 source 集群中的 Redis StatefulSet 副本缩放为 0，并且 destination 集群中的 Redis StatefulSet 健康，总共有 6 个副本。

接下来？

此特性为跨集群拆分 StatefulSet 提供了一项基本支撑技术，但没有规定 StatefulSet 的迁移机制。迁移需要对 StatefulSet 副本的协调，以及对存储和网络层的编排。这取决于使用 StatefulSet 安装的应用程序的存储和网络连接要求。此外，许多 StatefulSet 由 operator 管理，这也增加了额外的迁移复杂性。

如果你有兴趣构建增强功能以简化这些过程，请参与 SIG Multicluster 做出贡献！

官方自动刷新 CVE 订阅源的更新

Tue, 25 Apr 2023 00:00:00 +0000

作者：Cailyn Edwards (Shopify), Mahé Tardy (Isovalent), Pushkar Joglekar

译者：Wilson Wu (DaoCloud)

自从在 1.25 版本中将官方自动刷新 CVE 订阅源作为 Alpha 功能启用以来，我们已经做了一些重大改进和更新。我们很高兴宣布该订阅源的 Beta 版现已发布。这篇博文将列举收到的反馈、所做的更改，还讨论了在未来 Kubernetes 版本中准备使其进阶成为一个稳定功能时你可以如何提供帮助。

来自最终用户的反馈

SIG Security 收到了一些最终用户的反馈：

JSON CVE Feed 的名称与在 JSON Feed 规范中所建议的不符。
除了 JSON Feed 格式之外，订阅源还可以支持 RSS 格式。
可以添加一些元数据来表示整体订阅的实时性，或者特殊 CVE 内容。另一个建议是希望指出哪个 Prow 作业最近对订阅源进行了更新。可以直接在问题汇总中查看更多想法。
网站上的订阅源 Markdown 表应按照 CVE 发布的时间顺序由近到远排列。

变更摘要

在回应中，SIG 对生成 JSON 格式订阅源的脚本进行了修改，让生成的内容符合 JSON Feed 规范，并添加 last_updated 根字段表示整体实时性。此重新设计需要 Kubernetes 网站的相应修复，以便 CVE 订阅源页面基于新格式继续工作。

之后，完全透明的添加了 RSS 订阅源支持，以便最终用户使用订阅源时可以将其作为首选格式。

总而言之，基于 JSON Feed 规范的重新设计（打破了向后兼容性）将允许后续进行更新以解决其余问题，同时令其更加透明且对最终用户的干扰做到较小。

更新

标题	Issue	状态
CVE Feed: JSON feed should pass jsonfeed spec validator	kubernetes/webite#36808	已关闭，详见：kubernetes/sig-security#76
CVE Feed: Add lastUpdatedAt as a metadata field	kubernetes/sig-security#72	已关闭，详见：kubernetes/sig-security#76
Support RSS feeds by generating data in Atom format	kubernetes/sig-security#77	已关闭，详见：kubernetes/website#39513
CVE Feed: Sort Markdown Table from most recent to least recently announced CVE	kubernetes/sig-security#73	已关闭，详见：kubernetes/sig-security#76
CVE Feed: Include a timestamp field for each CVE indicating when it was last updated	kubernetes/sig-security#63	已关闭，详见：kubernetes/sig-security#76
CVE Feed: Add Prow job link as a metadata field	kubernetes/sig-security#71	已关闭，详见：kubernetes/sig-security#83

接下来要做什么？

为了此订阅源进阶至稳定阶段做准备，即 General Availability 阶段，SIG Security 仍将从最终用户持续收集他们使用最新 Beta 版订阅源后的反馈。

为了帮助我们在未来的 Kubernetes 版本中继续改进订阅源，请通过对此跟踪 Issue 添加评论来分享反馈，或者通过 #sig-security-tooling Kubernetes Slack 频道让我们获得更多信息，由此加入 Kubernetes Slack。

Kubernetes 1.27：服务器端字段校验和 OpenAPI V3 进阶至 GA

Mon, 24 Apr 2023 00:00:00 +0000

作者：Jeffrey Ying (Google), Antoine Pelisse (Google)

译者：Michael Yao (DaoCloud)

在 Kubernetes v1.8 之前，YAML 文件中的拼写错误、缩进错误或其他小错误可能会产生灾难性后果（例如像在 replica: 1000 中忘记了结尾的字母 “s”，可能会导致宕机。因为该值会被忽略并且丢失，并强制将副本重置回 1）。当时解决这个问题的办法是：在 kubectl 中获取 OpenAPI v2 并在应用之前使用 OpenAPI v2 来校验字段是否正确且存在。不过当时没有自定义资源定义 (CRD)，相关代码是在当时那样的假设下编写的。之后引入了 CRD，发现校验代码缺乏灵活性，迫使 CRD 在公开其模式定义时做出了一些艰难的决策，使得我们进入了不良校验造成不良 OpenAPI，不良 OpenAPI 无法校验的循环。随着新的 OpenAPI v3 和服务器端字段校验在 1.27 中进阶至 GA，我们现在已经解决了这两个问题。

服务器端字段校验针对通过 create、update 和 patch 请求发送到 apiserver 上的资源进行校验，此特性是在 Kubernetes v1.25 中添加的，在 v1.26 时进阶至 Beta，如今在 v1.27 进阶至 GA。它在服务器端提供了 kubectl 校验的所有功能。

OpenAPI 是一个标准的、与编程语言无关的接口，用于发现 Kubernetes 集群支持的操作集和类型集。 OpenAPI v3 是 OpenAPI 的最新标准，它是自 Kubernetes 1.5 开始支持的 OpenAPI v2 的改进版本。对 OpenAPI v3 的支持是在 Kubernetes v1.23 中添加的， v1.24 时进阶至 Beta，如今在 v1.27 进阶至 GA。

OpenAPI v3

OpenAPI v3 相比 v2 提供了什么？

插件类型

Kubernetes 对 OpenAPI v2 中不能表示或有时在 Kubernetes 生成的 OpenAPI v2 中未表示的某些字段提供了注解。最明显地，OpenAPI v3 发布了 “default” 字段，而在 OpenAPI v2 中被省略。表示多种类型的单个类型也能在 OpenAPI v3 中使用 oneOf 字段被正确表达。这包括针对 IntOrString 和 Quantity 的合理表示。

CRD

在 Kubernetes 中，自定义资源定义 (CRD) 使用结构化的 OpenAPI v3 模式定义，无法在不损失某些字段的情况下将其表示为 OpenAPI v2。这些包括 nullable、default、anyOf、oneOf、not 等等。OpenAPI v3 是 CustomResourceDefinition 结构化模式定义的完全无损表示。

如何使用？

Kubernetes API 服务器的 /openapi/v3 端点包含了 OpenAPI v3 的根发现文档。为了减少传输的数据量，OpenAPI v3 文档以 group-version 的方式进行分组，不同的文档可以通过 /openapi/v3/apis/<group>/<version> 和 /openapi/v3/api/v1 （表示旧版 group）进行访问。有关此端点的更多信息请参阅 Kubernetes API 文档。

众多使用 OpenAPI 的客户侧组件已更新到了 v3，包括整个 kubectl 和服务器端应用。在 client-go 中也提供了 OpenAPI V3 Golang 客户端。

服务器端字段校验

查询参数 fieldValidation 可用于指示服务器应执行的字段校验级别。如果此参数未被传递，服务器端字段校验默认采用 Warn 模式。

Strict：严格的字段校验，在验证失败时报错
Warn：执行字段校验，但错误会以警告的形式给出，而不是使请求失败
Ignore：不执行服务器端的字段校验

kubectl 将跳过客户端校验，并将自动使用 Strict 模式下的服务器端字段校验。控制器默认使用 Warn 模式进行服务器端字段校验。

使用客户端校验时，由于 OpenAPI v2 中缺少某些字段，所以我们必须更加宽容，以免拒绝可能有效的对象。而在服务器端校验中，所有这些问题都被修复了。可以在此处找到更多文档。

未来展望

随着服务器端字段校验和 OpenAPI v3 以 GA 发布，我们引入了更准确的 Kubernetes 资源表示。建议使用服务器端字段校验而非客户端校验，但是通过 OpenAPI v3，客户端可以在必要时自行实现其自身的校验（“左移”），我们保证 OpenAPI 发布的是完全无损的模式定义。

现在的一些工作将进一步改善通过 OpenAPI 提供的信息，例如 CEL 校验和准入以及对内置类型的 OpenAPI 注解。

使用在 OpenAPI v3 中的类型信息还可以构建许多其他工具来编写和转换资源。

如何参与？

这两个特性由 SIG API Machinery 社区驱动，欢迎加入 Slack 频道 #sig-api-machinery，请查阅邮件列表，我们每周三 11:00 AM PT 在 Zoom 上召开例会。

我们对所有曾帮助设计、实现和审查这两个特性的贡献者们表示衷心的感谢。

Alexander Zielenski
Antoine Pelisse
Daniel Smith
David Eads
Jeffrey Ying
Jordan Liggitt
Kevin Delgado
Sean Sullivan

Kubernetes 1.27: 使用 Kubelet API 查询节点日志

Fri, 21 Apr 2023 00:00:00 +0000

作者： Aravindh Puthiyaparambil (Red Hat)

译者： Xin Li (DaoCloud)

Kubernetes 1.27 引入了一个名为节点日志查询的新功能，可以查看节点上运行的服务的日志。

它解决了什么问题？

集群管理员在调试节点上运行的表现不正常的服务时会遇到问题。他们通常必须通过 SSH 或 RDP 进入节点以查看服务日志以调试问题。 节点日志查询功能通过允许集群管理员使用 kubectl 查看日志的方式来帮助解决这种情况。这对于 Windows 节点特别有用，在 Windows 节点中，你会遇到节点进入就绪状态但由于 CNI 错误配置和其他不易通过查看 Pod 状态来辨别的问题而导致容器无法启动的情况。

它是如何工作的？

kubelet 已经有一个 /var/log/ 查看器，可以通过节点代理端点访问。本功能特性通过一个隔离层对这个端点进行增强，在 Linux 节点上通过 journalctl Shell 调用获得日志，在 Windows 节点上通过 Get-WinEvent CmdLet 获取日志。然后它使用命令提供的过滤器来过滤日志。kubelet 还使用启发式方法来检索日志。如果用户不知道给定的系统服务是记录到文件还是本机系统记录器，启发式方法首先检查本机操作系统记录器，如果不可用，它会尝试先从 /var/log/<servicename> 或 /var/log/<servicename>.log 或 /var/log/<servicename>/<servicename>.log 检索日志。

在 Linux 上，我们假设服务日志可通过 journald 获得，并且安装了 journalctl。在 Windows 上，我们假设服务日志在应用程序日志提供程序中可用。另请注意，只有在你被授权的情况下才能获取节点日志（在 RBAC 中，这是对 nodes/proxy 的 get 和 create 访问）。获取节点日志所需的特权也允许特权提升攻击（elevation-of-privilege），因此请谨慎管理它们。

该如何使用它

要使用该功能，请确保为该节点启用了 NodeLogQuery 特性门控，并且 kubelet 配置选项 enableSystemLogHandler 和 enableSystemLogQuery 都设置为 true。然后，你可以查询所有节点或部分节点的日志。下面是一个从节点检索 kubelet 服务日志的示例：

# Fetch kubelet logs from a node named node-1.example
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"

你可以进一步过滤查询以缩小结果范围：

# Fetch kubelet logs from a node named node-1.example that have the word "error"
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"

你还可以从 Linux 节点上的 /var/log/ 获取文件：

kubectl get --raw "/api/v1/nodes/<insert-node-name-here>/proxy/logs/?query=/<insert-log-file-name-here>"

你可以阅读文档获取所有可用选项。

如何提供帮助

请使用该功能并通过在 GitHub 上登记问题或通过 Kubernetes Slack 的 #sig-windows 频道或 SIG Windows 邮件列表联系我们来提供反馈。

Kubernetes 1.27：持久卷的单个 Pod 访问模式升级到 Beta

Thu, 20 Apr 2023 00:00:00 +0000

作者：Chris Henzie (Google)

译者：顾欣 (ICBC)

随着 Kubernetes v1.27 的发布，ReadWriteOncePod 功能已经升级为 Beta 版。在这篇博客文章中，我们将更详细地介绍这个功能，作用以及在 Beta 版本中的发展。

什么是 ReadWriteOncePod

ReadWriteOncePod 是 Kubernetes 在 v1.22 中引入的一种新的访问模式，适用于 PersistentVolume(PVs) 和 PersistentVolumeClaim(PVCs)。此访问模式使你能够将存储卷访问限制在集群中的单个 Pod 上，确保一次只有一个 Pod 可以写入存储卷。这可能对需要单一写入者访问存储的有状态工作负载特别有用。

要了解有关访问模式和 ReadWriteOncePod 如何工作的更多背景信息，请阅读 2021 年介绍 PersistentVolume 的单个 Pod 访问模式的文章中的什么是访问模式和为什么它们如此重要？。

ReadWriteOncePod 的 Beta 版中变化

ReadWriteOncePod Beta 版为使用 ReadWriteOncePod PVC 的 Pod 添加调度器抢占。

调度器抢占允许更高优先级的 Pod 抢占较低优先级的 Pod，以便它们可以在同一节点上运行。在此版本中，如果更高优先级的 Pod 需要相同的 PVC，使用 ReadWriteOncePod PVCs 的 Pod 也可以被抢占。

如何开始使用 ReadWriteOncePod？

随着 ReadWriteOncePod 现已升级为 Beta 版，在 v1.27 及更高版本的集群中将默认启用该功能。

请注意，ReadWriteOncePod 仅支持 CSI 卷。在使用此功能之前，你需要将以下 CSI Sidecars更新至以下版本或更高版本：

要开始使用 ReadWriteOncePod，请创建具有 ReadWriteOncePod 访问模式的 PVC：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: single-writer-only
spec:
  accessModes:
  - ReadWriteOncePod #仅允许一个容器访问且独占写入权限。
  resources:
    requests:
      storage: 1Gi

如果你的存储插件支持动态制备，新创建的持久卷将应用 ReadWriteOncePod 访问模式。

阅读迁移现有持久卷以了解如何迁移现有卷以使用 ReadWriteOncePod。

如何了解更多信息？

请查看 Alpha 版博客和 KEP-2485 以了解关于 ReadWriteOncePod 访问模式的更多详细信息以及对 CSI 规约作更改的动机。

如何参与？

Kubernetes #csi Slack频道以及任何常规的 SIG 存储沟通渠道都是联系 SIG 存储和 CSI 团队的最佳途径。

特别感谢以下人士的仔细的审查和反馈，帮助完成了这个功能：

Abdullah Gharaibeh (ahg-g)
Aldo Culquicondor (alculquicondor)
Antonio Ojea (aojea)
David Eads (deads2k)
Jan Šafránek (jsafrane)
Joe Betz (jpbetz)
Kante Yin (kerthcet)
Michelle Au (msau42)
Tim Bannister (sftim)
Xing Yang (xing-yang)

如果您有兴趣参与 CSI 或 Kubernetes 存储系统的任何部分的设计和开发，请加入 Kubernetes 存储特别兴趣小组(SIG)。我们正在迅速发展，始终欢迎新的贡献者。

Kubernetes 1.27：高效的 SELinux 卷重新标记（Beta 版）

Tue, 18 Apr 2023 10:00:00 -0800

作者：Jan Šafránek (Red Hat)

译者：Wilson Wu (DaoCloud)

问题

在启用了 Security-Enhancled Linux（SELinux）系统上，传统做法是让容器运行时负责为 Pod 及所有卷应用 SELinux 标签。 Kubernetes 仅将 SELinux 标签从 Pod 的 securityContext 字段传递给容器运行时。

然后，容器运行时以递归的方式更改 Pod 容器可见的所有文件上的 SELinux 标签。如果卷上有许多文件，这一过程可能会非常耗时，尤其是当卷位于远程文件系统上时。

Note

如果容器使用卷的 subPath，则系统仅重新标记整个卷的 subPath。这样，使用不同 SELinux 标签的两个 Pod 可以使用同一卷，只要它们使用该卷的不同子路径即可。

如果 Pod 没有从 Kubernetes API 中获得任何 SELinux 标签，则容器运行时会分配一个唯一的随机标签，因此可能逃离容器边界的进程将无法访问主机上任何其他容器的数据。容器运行时仍然使用此随机 SELinux 标签递归地重新标记所有 Pod 卷。

使用挂载选项进行改进

如果 Pod 及其卷满足以下所有条件，Kubernetes 将直接使用正确的 SELinux 标签挂载该卷。这种挂载将在确定时间内完成，容器运行时不需要递归地重新标记其上的任何文件。

操作系统必须支持 SELinux。

如果没有检测到 SELinux 支持，kubelet 和容器运行时不会对 SELinux 执行任何操作。

必须启用特性门控 ReadWriteOncePod 和 SELinuxMountReadWriteOncePod。这些特性门控在 Kubernetes 1.27 中是 Beta 版，在 1.25 中是 Alpha 版。

禁用这些功能中任何一个后，SELinux 标签将始终由容器运行时通过递归遍历卷（或其 subPath）来应用。

Pod 必须在其 Pod 安全上下文中至少设置 seLinuxOptions.level，或者所有 Pod 容器必须在安全上下文中对其进行设置。否则 Kubernetes 将从操作系统默认值（通常是 system_u、system_r 和 container_t）中读取默认的 user、role 和 type。

如果 Kubernetes 不了解任何 SELinux level，容器运行时将在卷挂载后为其分配一个随机级别。在这种情况下，容器运行时仍会递归地对卷进行重新标记。

存储卷必须是访问模式为 ReadWriteOncePod 的持久卷。

这是最初的实现的限制。如上所述，两个 Pod 可以具有不同的 SELinux 标签，但仍然使用相同的卷，只要它们使用不同的 subPath 即可。对于已挂载的带有 SELinux 标签的卷，此场景是无法支持的，因为整个卷已挂载，并且大多数文件系统不支持使用不同的 SELinux 标签多次挂载同一个卷。

如果在你的环境中需要使用两个不同的 SELinux 上下文运行两个 Pod 并使用同一卷的不同 subPath，请在 KEP 问题中发表评论（或对任何现有评论进行投票 - 最好不要重复）。当此特性扩展到覆盖所有卷访问模式时，这类 Pod 可能无法运行。

卷插件或负责卷的 CSI 驱动程序支持使用 SELinux 挂载选项进行挂载。

这些树内卷插件支持使用 SELinux 挂载选项进行挂载：fc、iscsi 和 rbd。

支持使用 SELinux 挂载选项挂载的 CSI 驱动程序必须通过设置 seLinuxMount 字段在其 CSIDriver 实例中声明这一点。

由其他未设置 seLinuxMount: true 的卷插件或 CSI 驱动程序管理的卷将由容器运行时递归地重新标记。

使用 SELinux 上下文挂载

当满足所有上述条件时，kubelet 会将 -o context=<SELinux label> 挂载选项传递给卷插件或 CSI 驱动程序。 CSI 驱动程序提供者必须确保其 CSI 驱动程序支持此安装选项，并且如有必要，CSI 驱动程序要附加 -o context 所需的其他安装选项。

例如，NFS 可能需要 -o context=<SELinux label>,nosharecache，这样来自同一 NFS 服务器的多个卷被挂载时可以具有不同的 SELinux 标签值。类似地，CIFS 可能需要 -o context=<SELinux label>,nosharesock。

在 CSIDriver 实例中设置 seLinuxMount: true 之前，CSI 驱动程序提供者需要在启用 SELinux 的环境中测试其 CSI 驱动程序。

如何了解更多？

容器中的 SELinux：请参阅 Daniel J Walsh 撰写的可视化 SELinux 指南（英文）。请注意，该指南早于 Kubernetes，它以虚拟机为例描述了多类别安全（MCS）模式，但是，类似的概念也适用于容器。

请参阅以下系列博客文章，详细了解容器运行时如何将 SELinux 应用于容器：

阅读 KEP：使用挂载加速 SELinux 卷重新标记

Kubernetes 1.27：更多精细粒度的 Pod 拓扑分布策略进阶至 Beta

Mon, 17 Apr 2023 00:00:00 +0000

作者: Alex Wang (Shopee), Kante Yin (DaoCloud), Kensei Nakada (Mercari)

译者: Michael Yao (DaoCloud)

在 Kubernetes v1.19 中， Pod 拓扑分布约束进阶至正式发布 (GA)。

随着时间的流逝，SIG Scheduling 收到了许多用户的反馈，随后通过 3 个 KEP 积极改进了 Topology Spread（拓扑分布）特性。所有这些特性在 Kubernetes v1.27 中已进阶至 Beta 且默认被启用。

这篇博文介绍了这些特性及其背后的使用场景。

KEP-3022：Pod 拓扑分布中的最小域数

Pod 拓扑分布使用 maxSkew 参数来定义 Pod 可以不均匀分布的程度。

但还有没有一种方式可以控制应分布到的域数。一些用户想要强制在至少指定个数的若干域内分布 Pod；并且如果目前存在的域个数还不够，则使用 cluster-autoscaler 制备新的域。

Kubernetes v1.24 以 Alpha 特性的形式为 Pod 拓扑分布约束引入了 minDomains 参数。通过 minDomains 参数，你可以定义最小域数。

例如，假设有 3 个 Node 具有足够的容量，且新建的 ReplicaSet 在其 Pod 模板中带有以下 topologySpreadConstraints。

...
topologySpreadConstraints:
- maxSkew: 1
  minDomains: 5 # 需要至少 5 个 Node（因为每个 Node 都有唯一的 hostname）
  whenUnsatisfiable: DoNotSchedule # 只有使用 DoNotSchedule 时 minDomains 才有效
  topologyKey: kubernetes.io/hostname
  labelSelector:
    matchLabels:
        foo: bar

在这个场景中，3 个 Pod 将被分别调度到这 3 个 Node 上，但 ReplicaSet 中的其它 2 个 Pod 在更多 Node 接入到集群之前将无法被调度。

你可以想象集群自动扩缩器基于这些不可调度的 Pod 制备新的 Node，因此这些副本最后将分布到 5 个 Node 上。

KEP-3094：计算 podTopologySpread 偏差时考虑污点/容忍度

在本次增强之前，当你部署已经配置了 topologySpreadConstraints 的 Pod 时，kube-scheduler 将在过滤和评分时考虑满足 Pod 的 nodeAffinity 和 nodeSelector 的节点，但不关心传入的 Pod 是否容忍节点污点。这可能会导致具有不可容忍污点的节点成为唯一的分布候选，因此如果 Pod 不容忍污点，则该 Pod 将卡在 Pending 状态。

为了能够在计算分布偏差时针对要考虑的节点作出粒度更精细的决策，Kubernetes 1.25 在 topologySpreadConstraints 中引入了两个新字段 nodeAffinityPolicy 和 nodeTaintPolicy 来定义节点包含策略。

应用这些策略的清单如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # 配置拓扑分布约束
  topologySpreadConstraints:
    - maxSkew: <integer>
      # ...
      nodeAffinityPolicy: [Honor|Ignore]
      nodeTaintsPolicy: [Honor|Ignore]
  # 在此处添加其他 Pod 字段

nodeAffinityPolicy 字段指示 Kubernetes 如何处理 Pod 的 nodeAffinity 或 nodeSelector 以计算 Pod 拓扑分布。如果是 Honor，则 kube-scheduler 在计算分布偏差时会过滤掉不匹配 nodeAffinity/nodeSelector 的节点。如果是 Ignore，则会包括所有节点，不会管它们是否与 Pod 的 nodeAffinity/nodeSelector 匹配。

为了向后兼容，nodeAffinityPolicy 默认为 Honor。

nodeTaintsPolicy 字段定义 Kubernetes 计算 Pod 拓扑分布时如何对待节点污点。如果是 Honor，则只有配置了污点的节点上的传入 Pod 带有容忍标签时该节点才会被包括在分布偏差的计算中。如果是 Ignore，则在计算分布偏差时 kube-scheduler 根本不会考虑节点污点，因此带有未容忍污点的 Pod 的节点也会被包括进去。

为了向后兼容，nodeTaintsPolicy 默认为 Ignore。

该特性在 v1.25 中作为 Alpha 引入。默认被禁用，因此如果要在 v1.25 中使用此特性，则必须显式启用特性门控 NodeInclusionPolicyInPodTopologySpread。在接下来的 v1.26 版本中，相关特性进阶至 Beta 并默认被启用。

KEP-3243：滚动升级后关注 Pod 拓扑分布

Pod 拓扑分布使用 labelSelector 字段来标识要计算分布的 Pod 组。在针对 Deployment 进行拓扑分布时，通常会使用 Deployment 的 labelSelector 作为拓扑分布约束中的 labelSelector。但这意味着 Deployment 的所有 Pod 都参与分布计算，与这些 Pod 是否属于不同的版本无关。因此，在发布新版本时，分布将同时应用到新旧 ReplicaSet 的 Pod，并在新的 ReplicaSet 完全发布且旧的 ReplicaSet 被下线时，我们留下的实际分布可能与预期不符，这是因为旧 ReplicaSet 中已删除的 Pod 将导致剩余 Pod 的分布不均匀。为了避免这个问题，过去用户需要向 Deployment 添加修订版标签，并在每次滚动升级时手动更新（包括 Pod 模板上的标签和 topologySpreadConstraints 中的 labelSelector）。

为了通过更简单的 API 解决这个问题，Kubernetes v1.25 引入了一个名为 matchLabelKeys 的新字段到 topologySpreadConstraints 中。matchLabelKeys 是一个 Pod 标签键列表，用于选择计算分布方式的 Pod。这些键用于查找 Pod 被调度时的标签值，这些键值标签与 labelSelector 进行逻辑与运算，为新增 Pod 计算分布方式选择现有 Pod 组。

借助 matchLabelKeys，你无需在修订版变化时更新 pod.spec。控制器或 Operator 管理滚动升级时只需针对不同修订版为相同的标签键设置不同的值即可。调度程序将基于 matchLabelKeys 自动完成赋值。例如，如果你正配置 Deployment，则可以使用由 Deployment 控制器自动添加的 pod-template-hash 的标签键来区分单个 Deployment 中的不同修订版。

topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: kubernetes.io/hostname
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app: foo
      matchLabelKeys:
        - pod-template-hash

参与其中

这些特性归 Kubernetes SIG Scheduling 管理。

请加入我们分享反馈。我们期待聆听你的声音！

了解更多

“使用更新后的 Go 版本保持 Kubernetes 安全”

Thu, 06 Apr 2023 00:00:00 +0000

作者：Jordan Liggitt (Google)

译者：顾欣 (ICBC)

问题

从 2020 年发布的 v1.19 版本以来，Kubernetes 项目为每个次要版本提供 12-14 个月的补丁维护期。这使得用户可以按照年度升级周期来评估和选用 Kubernetes 版本，并持续一年获得安全修复。

Go 项目每年发布两个新的次要版本，并为最近的两个版本提供安全修复，每个 Go 版本的维护期约为一年。尽管每个新的 Kubernetes 次要版本在最初发布时都是使用受支持的 Go 版本编译构建的，但在这一 Kubernetes 次要版本被停止支持之前，对应的 Go 版本就已经不被支持，并且由于 Kubernetes 从 v1.19 开始延长了补丁支持期，这个差距被进一步扩大。

在编写本文时，包含了可能对安全产生影响的问题修复的 Go 补丁发布版本刚刚过半（88/171）。尽管这些问题中很多都与 Kubernetes 无关，但有些确实相关，因此使用受支持的、已包含了这类修复的 Go 版本是非常重要的。

显而易见的解决方案之一是直接更新 Kubernetes 的发布分支，使用 Go 的新次要版本。然而，Kubernetes 避免在补丁发布中引入破坏稳定性的变更，过去，因为这些变更被认为包含过高的复杂性、风险或破坏性，不适合包含在补丁发布中，所以不能将现有发布分支更新到 Go 的新次要版本。示例包括：

Go 1.6: 默认支持 http/2
Go 1.14: EINTR 问题处理
Go 1.17: 取消 x509 CN 支持, ParseIP 更改
Go 1.18: 默认禁用 x509 SHA-1 证书支持
Go 1.19: 取消当前目录 LookPath 行为

其中一些更改可以基本不会影响 Kubernetes 代码，有些只能通过用户指定的 GODEBUG 环境变量来选择放弃更新，而其他变更则需要侵入式的代码变更或完全无法避免。由于这种不一致性，Kubernetes 的发布分支通常保持使用某个固定的 Go 次要版本，并在每个 Kubernetes 次要版本支持生命周期的最后几个月内，面临无法得到重要的 Go 安全修复的风险。

当某项重要的 Go 安全修复仅出现在较新的 Kubernetes 次要版本时，用户必须在旧的 Kubernetes 次要版本的 12-14 个月支持期结束之前完成升级，以获取这些修复。如果用户没有准备好升级，可能导致 Kubernetes 集群的安全漏洞。即使用户可以接受这种意外升级，这种不确定性也使得 Kubernetes 在年度支持从规划角度看变得不太可靠。

解决方案

我们很高兴地宣布，自2023年1月起，受支持的 Kubernetes 版本与受支持的 Go 版本之间的差距已得到解决。

在过去的一年里，我们与 Go 团队密切合作，以解决采用新的 Go 版本的困难。这些工作推动了一场讨论、提案、 GopherCon 演讲和设计，以提高 Go 的向后兼容性，确保新的 Go 版本至少在两年（四个 Go 版本）内能够与之前的 Go 版本保持兼容的运行时行为。这使得像 Kubernetes 这样的项目能够将发布分支更新到受支持的 Go 版本，而不是将行为上的变更暴露给用户。

所提议的改进正按计划包含在 Go 1.21 中，而且 Go 团队已经在 2022 年底的 Go 1.19 补丁发布中提供了针对兼容性的改进。这些更改使 Kubernetes 1.23+ 在 2023 年 1 月升级到 Go 1.19，并避免了任何用户可见的配置或行为变化。现在所有受支持的 Kubernetes 发布分支都使用受支持的 Go 版本，并且可以使用包含可用的安全修复的、新的 Go 补丁发布。

展望未来，Kubernetes 维护者仍致力于使 Kubernetes 补丁发布尽可能安全且不会造成破坏，因此在现有的 Kubernetes 发布分支更新使用新的 Go 次要版本之前，新的 Go 次要版本必须满足几个要求：

新的 Go 版本必须至少已经推出 3 个月。这给了 Go 社区足够的时间进行报告并解决问题。
新的 Go 版本在新的 Kubernetes 次要版本中至少已经使用了 1 个月。这确保 Kubernetes 所有可能阻塞发布的测试都需要能在新的 Go 版本下通过，并在早期为 Kubernetes 社区对发布候选版本和新次要版本提供反馈时间。
与先前的 Go 版本相比，不能出现新的已知会影响 Kubernetes 的问题。
默认情况下必须保持运行时行为，而无需 Kubernetes 用户/管理员采取任何操作。
Kubernetes 库，如 k8s.io/client-go 必须与每个次要版本最初使用的 Go 版本保持兼容，以便在获取库补丁时，用户不必更新 Go 版本（不过还是鼓励他们使用受支持的 Go 版本构建，因为 Go 1.21 计划中的兼容性改进会使得这一操作变简单）。

所有这些工作的目标是在不引人注意的情况下使 Kubernetes 补丁发布更加安全可靠，并确保在整个支持周期内 Kubernetes 次要版本用起来都是安全的。

非常感谢 Go 团队，尤其是 Russ Cox，他们推动了这些改进，使所有 Go 用户受益，而不仅仅是 Kubernetes。

Kubernetes Blog

Kubernetes 1.29: 解耦污点管理器与节点生命周期控制器

背景

变动摘要

如何使用这个新特性？

使用案例

FAQ

了解更多

特别鸣谢

Kubernetes 1.29：PodReadyToStartContainers 状况进阶至 Beta

这个特性的动机是什么？

这个特性有什么好处？

后续事项

如何了解更多？

如何参与？

Kubernetes 1.29 新的 Alpha 特性：Service 的负载均衡器 IP 模式

背景

问题

解决方案

用法

更多信息

联系我们

特别鸣谢

Kubernetes 1.29：修改卷之 VolumeAttributesClass

VolumeAttributesClass

如何使用它

用户流程

后续步骤

参与其中

聚焦 SIG Testing

会见贡献者

测试实践和工具

SIG Testing 拥有的子项目

主要挑战和成就

人员和范围

展望未来

Kubernetes 1.29 中的移除、弃用和主要变更

Kubernetes API 移除和弃用流程

k8s.gcr.io 重定向到 registry.k8s.io 相关说明

Kubernetes 社区自治软件包仓库相关说明

Kubernetes v1.29 的弃用和移除说明

移除与云驱动的内部集成（KEP-2395）

移除 v1beta2 流量控制 API 组

弃用针对 Node 的 status.nodeInfo.kubeProxyVersion 字段

了解更多

介绍 SIG etcd

etcd 的关键作用

为什么要设立特殊兴趣小组

关于 SIG etcd

Gateway API v1.0：正式发布（GA）

新增内容

升级到 v1

CEL 验证

标准（Standard）通道

实验（Experimental）通道

其他内容

发展历程

尝试一下

下一步

Gateway API 现身于 KubeCon + CloudNativeCon

参与其中

Kubernetes 中 PersistentVolume 的最后阶段转换时间

我们为什么需要新的 PV 字段？

lastPhaseTransitionTime 如何提供帮助

如何使用它

未来发展

欢迎参与

2023 中国 Kubernetes 贡献者峰会简要回顾

开心遇见

技术分享和讨论

中国贡献者数据

致谢

CRI-O 正迁移至 pkgs.k8s.io

如何使用新软件包

基于 rpm 的发行版

添加 Kubernetes 仓库

添加 CRI-O 仓库

安装官方包依赖

从添加的仓库中安装软件包

基于 deb 的发行版

移除 `v1beta2` 流量控制 API 组

弃用针对 Node 的 `status.nodeInfo.kubeProxyVersion` 字段

基于 `rpm` 的发行版

基于 `deb` 的发行版