Kubernetes Blog

Kubernetes v1.31：kubeadm v1beta4

Fri, 23 Aug 2024 00:00:00 +0000

作为 Kubernetes v1.31 发布的一部分，kubeadm 采用了全新版本（v1beta4）的配置文件格式。之前 v1beta3 格式的配置现已正式弃用，这意味着尽管之前的格式仍然受支持，但你应迁移到 v1beta4 并停止使用已弃用的格式。对 v1beta3 配置的支持将在至少 3 次 Kubernetes 次要版本发布后被移除。

在本文中，我将介绍关键的变更；我将解释 kubeadm v1beta4 配置格式，以及如何从 v1beta3 迁移到 v1beta4。

你可以参阅 v1beta4 配置格式的参考文档： kubeadm 配置 (v1beta4)。

自 v1beta3 以来的变更列表

此版本通过修复一些小问题并添加一些新字段来改进 v1beta3 格式。

简单而言，

增加了两个新的配置元素：ResetConfiguration 和 UpgradeConfiguration
对于 InitConfiguration 和 JoinConfiguration，支持 dryRun 模式和 nodeRegistration.imagePullSerial
对于 ClusterConfiguration，新增字段包括 certificateValidityPeriod、caCertificateValidityPeriod、 encryptionAlgorithm、dns.disabled 和 proxy.disabled
所有控制平面组件支持 extraEnvs
extraArgs 从映射变更为支持重复的结构化额外参数
为 init、join、upgrade 和 reset 添加了 timeouts 结构

有关细节请参阅以下官方文档：

在 ClusterConfiguration 下支持控制平面组件的自定义环境变量。可以使用 apiServer.extraEnvs、controllerManager.extraEnvs、scheduler.extraEnvs、etcd.local.extraEnvs。
ResetConfiguration API 类型现在在 v1beta4 中得到支持。用户可以通过将 --config 文件传递给 kubeadm reset 来重置节点。
dryRun 模式现在在 InitConfiguration 和 JoinConfiguration 中可配置。

用支持重复的结构化额外参数替换现有的 string/string 额外参数映射。此变更适用于 ClusterConfiguration - apiServer.extraArgs、controllerManager.extraArgs、 scheduler.extraArgs、etcd.local.extraArgs。也适用于 nodeRegistrationOptions.kubeletExtraArgs。
添加了 ClusterConfiguration.encryptionAlgorithm，可用于设置此集群的密钥和证书所使用的非对称加密算法。可以是 "RSA-2048"（默认）、"RSA-3072"、"RSA-4096" 或 "ECDSA-P256" 之一。
添加了 ClusterConfiguration.dns.disabled 和 ClusterConfiguration.proxy.disabled，可用于在集群初始化期间禁用 CoreDNS 和 kube-proxy 插件。在集群创建期间跳过相关插件阶段将把相同的字段设置为 true。

在 InitConfiguration 和 JoinConfiguration 中添加了 nodeRegistration.imagePullSerial 字段，可用于控制 kubeadm 是顺序拉取镜像还是并行拉取镜像。
当将 --config 传递给 kubeadm upgrade 子命令时，现已在 v1beta4 中支持 UpgradeConfiguration kubeadm API。对于升级子命令，kubelet 和 kube-proxy 的组件配置以及 InitConfiguration 和 ClusterConfiguration 的用法现已弃用，并将在传递 --config 时被忽略。
在 InitConfiguration、JoinConfiguration、ResetConfiguration 和 UpgradeConfiguration 中添加了 timeouts 结构，可用于配置各种超时。 ClusterConfiguration.timeoutForControlPlane 字段被 timeouts.controlPlaneComponentHealthCheck 替换。 JoinConfiguration.discovery.timeout 被 timeouts.discovery 替换。

向 ClusterConfiguration 添加了 certificateValidityPeriod 和 caCertificateValidityPeriod 字段。这些字段可用于控制 kubeadm 在 init、join、upgrade 和 certs 等子命令中生成的证书的有效期。默认值继续为非 CA 证书 1 年和 CA 证书 10 年。另请注意，只有非 CA 证书可以通过 kubeadm certs renew 进行续期。

这些变更简化了使用 kubeadm 的工具的配置，并提高了 kubeadm 本身的可扩展性。

如何将 v1beta3 配置迁移到 v1beta4？

如果你的配置未使用最新版本，建议你使用 kubeadm config migrate 命令进行迁移。

此命令读取使用旧格式的现有配置文件，并写入一个使用当前格式的新文件。

示例

使用 kubeadm v1.31，运行 kubeadm config migrate --old-config old-v1beta3.yaml --new-config new-v1beta4.yaml

我该如何参与？

衷心感谢在此特性的设计、实现和评审中提供帮助的所有贡献者：

Lubomir I. Ivanov (neolit123)
Dave Chen (chendave)
Paco Xu (pacoxu)
Sata Qiu (sataqiu)
Baofa Fan (carlory)
Calvin Chen (calvin0327)
Ruquan Zhao (ruquanzhao)

如果你有兴趣参与 kubeadm 配置的后续讨论，可以通过多种方式与 kubeadm 或 SIG-cluster-lifecycle 联系：

v1beta4 相关事项在 kubeadm issue #2890 中跟踪。
Slack: #kubeadm 或 #sig-cluster-lifecycle
邮件列表

Kubernetes 1.31：通过 VolumeAttributesClass 修改卷进阶至 Beta

Thu, 15 Aug 2024 00:00:00 +0000

在 Kubernetes 中，卷由两个属性描述：存储类和容量。存储类是卷的不可变属性，而容量可以通过卷调整大小进行动态变更。

这使得使用卷的工作负载的垂直扩缩容变得复杂。虽然云厂商和存储供应商通常提供了一些允许指定注入 IOPS 或吞吐量等 IO 服务质量（性能）参数的卷，并允许在工作负载运行期间调整这些参数，但 Kubernetes 没有提供用来更改这些参数的 API。

我们很高兴地宣布，自 Kubernetes 1.29 起以 Alpha 引入的 VolumeAttributesClass KEP 将在 1.31 中进入 Beta 阶段。这一机制提供了一个通用的、Kubernetes 原生的 API，可用来修改诸如所提供的 IO 能力这类卷参数。

类似于 Kubernetes 中所有新的卷特性，此 API 是通过容器存储接口（CSI）实现的。除了 VolumeAttributesClass 特性门控外，特定于制备器的 CSI 驱动还必须支持此特性在 CSI 一侧的全新的 ModifyVolume API。

有关细节请参阅完整文档。在这里，我们展示了常见的工作流程。

动态修改卷属性

VolumeAttributesClass 是一个集群范围的资源，用来指定特定于制备器的属性。这些属性由集群管理员创建，方式上与存储类相同。例如，你可以为卷创建一系列金、银和铜级别的卷属性类，以区隔不同级别的 IO 能力。

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
  name: silver
driverName: your-csi-driver
parameters:
  provisioned-iops: "500"
  provisioned-throughput: "50MiB/s"
---
apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
  name: gold
driverName: your-csi-driver
parameters:
  provisioned-iops: "10000"
  provisioned-throughput: "500MiB/s"

属性类的添加方式与存储类类似。

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

与存储类不同，卷属性类可以被更改：

kubectl patch pvc test-pv-claim -p '{"spec": "volumeAttributesClassName": "gold"}'

Kubernetes 将与 CSI 驱动协作来更新卷的属性。 PVC 的状态将跟踪当前和所需的属性类。 PV 资源也将依据新的卷属性类完成更新，卷属性类也会被依据 PV 当前活跃的属性完成设置。

Beta 阶段的限制

作为一个 Beta 特性，仍有一些特性计划在 GA 阶段推出，但尚未实现。最大的限制是配额支持，详见 KEP 和 sig-storage 中的讨论。

有关此特性在 CSI 驱动中的最新支持信息，请参阅 Kubernetes CSI 驱动列表。

向 Client-Go 引入特性门控：增强灵活性和控制力

Mon, 12 Aug 2024 00:00:00 +0000

Kubernetes 组件使用称为“特性门控（Feature Gates）”的开关来管理添加新特性的风险，特性门控机制使特性能够通过 Alpha、Beta 和 GA 阶段逐步升级。

Kubernetes 组件（例如 kube-controller-manager 和 kube-scheduler）使用 client-go 库与 API 交互，整个 Kubernetes 生态系统使用相同的库来构建控制器、工具、webhook 等。 client-go 现在包含自己的特性门控机制，使开发人员和集群管理员能够更好地控制如何使用客户端特性。

要了解有关 Kubernetes 中特性门控的更多信息，请参阅特性门控。

动机

在没有 client-go 特性门控的情况下，每个新特性都以自己的方式（如果有的话）将特性可用性与特性的启用分开。某些特性可通过更新到较新版本的 client-go 来启用，其他特性则需要在每个使用它们的程序中进行主动配置，其中一些可在运行时使用环境变量进行配置。使用 kube-apiserver 公开的特性门控功能时，有时需要客户端回退机制，以保持与由于版本新旧或配置不同而不支持该特性服务器的兼容性。如果在这些回退机制中发现问题，则缓解措施需要更新到 client-go 的固定版本或回滚。

这些方法都无法很好地支持为某些（但不是全部）使用 client-go 的程序默认启用特性。默认设置的更改不会首先仅为单个组件启用新特性，而是会立即影响所有 Kubernetes 组件的默认设置，从而大大扩大影响半径。

client-go 中的特性门控

为了应对这些挑战，大量的 client-go 特性将使用新的特性门控机制来逐步引入。这一机制将允许开发人员和用户以类似 Kubernetes 组件特性门控的管理方式启用或禁用特性。

作为一种开箱即用的能力，用户只需使用最新版本的 client-go。这种设计带来多种好处。

对于使用通过 client-go 构建的软件的用户：

早期采用者可以针对各个进程分别启用默认关闭的 client-go 特性。
无需构建新的二进制文件即可禁用行为不当的特性。
所有已知的 client-go 特性门控的状态都会被记录到日志中，允许用户检查。

对于开发使用 client-go 构建的软件的人员：

默认情况下，client-go 特性门控覆盖是从环境变量中读取的。如果在 client-go 特性中发现错误，用户将能够禁用它，而无需等待新版本发布。
开发人员可以替换程序中基于默认环境变量的覆盖值以更改默认值、从其他源读取覆盖值或完全禁用运行时覆盖值。 Kubernetes 组件使用这种可定制性将 client-go 特性门控与现有的 --feature-gates 命令行标志、特性启用指标和日志记录集成在一起。

覆盖 client-go 特性门控

注意：这描述了在运行时覆盖 client-go 特性门控的默认方法，它可以由特定程序的开发人员禁用或自定义。在 Kubernetes 组件中，client-go 特性门控覆盖由 --feature-gates 标志控制。

可以通过设置以 KUBE_FEATURE 为前缀的环境变量来启用或禁用 client-go 的特性。例如，要启用名为 MyFeature 的特性，请按如下方式设置环境变量：

KUBE_FEATURE_MyFeature=true

要禁用特性，可将环境变量设置为 false：

KUBE_FEATURE_MyFeature=false

注意：在某些操作系统上，环境变量区分大小写。因此，KUBE_FEATURE_MyFeature 和 KUBE_FEATURE_MYFEATURE 将被视为两个不同的变量。

自定义 client-go 特性门控

基于环境变量的默认特性门控覆盖机制足以满足 Kubernetes 生态系统中许多程序的需求，无需特殊集成。需要不同行为的程序可以用自己的自定义特性门控提供程序替换它。这允许程序执行诸如强制禁用已知运行不良的特性、直接从远程配置服务读取特性门控或通过命令行选项接受特性门控覆盖等操作。

Kubernetes 组件将 client-go 的默认特性门控提供程序替换为现有 Kubernetes 特性门控提供程序的转换层。在所有实际应用场合中，client-go 特性门控与其他 Kubernetes 特性门控的处理方式相同：它们连接到 --feature-gates 命令行标志，包含在特性启用指标中，并在启动时记录。

要替换默认的特性门控提供程序，请实现 Gates 接口并在包初始化时调用 ReplaceFeatureGates，如以下简单示例所示：

import (
 "k8s.io/client-go/features"
)

type AlwaysEnabledGates struct{}

func (AlwaysEnabledGates) Enabled(features.Feature) bool {
 return true
}

func init() {
 features.ReplaceFeatureGates(AlwaysEnabledGates{})
}

需要定义的 client-go 特性完整列表的实现可以通过实现 Registry 接口并调用 AddFeaturesToExistingFeatureGates 来获取它。完整示例请参考 Kubernetes 内部使用。

总结

随着 client-go v1.30 中特性门控的引入，推出新的 client-go 特性变得更加安全、简单。用户和开发人员可以控制自己采用 client-go 特性的步伐。通过为跨 Kubernetes API 边界两侧的特性提供一种通用的培育机制，Kubernetes 贡献者的工作得到了简化。

特别感谢 @sttts 和 @deads2k 对此特性提供的帮助。

聚焦 SIG API Machinery

Wed, 07 Aug 2024 00:00:00 +0000

我们最近与 SIG API Machinery 的主席 Federico Bongiovanni（Google）和 David Eads（Red Hat）进行了访谈，了解一些有关这个 Kubernetes 特别兴趣小组的信息。

介绍

Frederico (FSM)：你好，感谢你抽时间参与访谈。首先，你能做个自我介绍以及你是如何参与到 Kubernetes 的？

David：我在 2014 年秋天开始在 OpenShift （Red Hat 的 Kubernetes 发行版）工作，很快就参与到 API Machinery 的工作中。我的第一个 PR 是修复 kube-apiserver 的错误消息，然后逐渐扩展到 kubectl（kubeconfigs 是我的杰作！）， auth（RBAC 和 *Review API 是从 OpenShift 移植过来的），apps（例如 workqueues 和 sharedinformers）。别告诉别人，但 API Machinery 仍然是我的最爱 :)

Federico：我加入 Kubernetes 没有 David 那么早，但现在也已经超过六年了。在我之前的公司，我们开始为自己的产品使用 Kubernetes，当我有机会直接参与 Kubernetes 的工作时，我放下了一切，登上了这艘船（无意双关）。我在 2018 年初加入 Google 从事 Kubernetes 的相关工作，从那时起一直参与其中。

SIG Machinery 的范围

FSM：只需快速浏览一下 SIG API Machinery 的章程，就可以看到它的范围相当广泛，不亚于 Kubernetes 的控制平面。你能用自己的话描述一下这个范围吗？

David：我们全权负责 kube-apiserver 以及如何高效地使用它。在后端，这包括它与后端存储的契约以及如何让 API 模式随时间演变。在前端，这包括模式的最佳实践、序列化、客户端模式以及在其之上的控制器模式。

Federico：Kubernetes 有很多不同的组件，但控制平面有一个非常关键的任务：它是你与集群的通信层，同时也拥有所有使 Kubernetes 如此强大的可扩展机制。我们不能犯像回归或不兼容变更这样的错误，因为影响范围太大了。

FSM：鉴于这个广度，你们如何管理它的不同方面？

Federico：我们尝试将大量工作组织成较小的领域。工作组和子项目是其中的一部分。 SIG 中的各位贡献者有各自的专长领域，如果一切都失败了，我们很幸运有像 David、Joe 和 Stefan 这样的人，他们真的是“全能型”，这种方式让我在这些年里一直感到惊叹。但另一方面，这也是为什么我们需要更多人来帮助我们在版本变迁之时保持 Kubernetes 的质量和卓越。

不断演变的协作模式

FSM：现有的模式一直是这样，还是随着时间的推移而演变的 - 如果是在演变的，你认为主要的变化以及背后的原因是什么？

David：API Machinery 在随着时间的推移不断发展，既有扩展也有收缩。在尝试满足客户端访问模式时，它很容易在特性和应用方面扩大范围。

一个范围扩大的好例子是我们认识到需要减少客户端写入控制器时的内存使用率而开发了共享通知器。在开发共享通知器和使用它们的控制器模式（工作队列、错误处理和列举器）时，我们大大减少了内存使用率，并消除了许多占用资源较多的列表。缺点是：我们增加了一套新的权能来提供支持，并有效地从 sig-apps 接管了该领域的所有权。

一个更多共享所有权的例子是：构建出合作的资源管理（服务器端应用的目标）， kubectl 扩展为负责利用服务器端应用的权能。这个过渡尚未完成，但 SIG CLI 管理其使用情况并拥有它。

FSM：对于方法之间的权衡，你们有什么指导方针吗？

David：我认为这很大程度上取决于影响。如果影响在立即见效中是局部的，我们会给其他 SIG 提出建议并让他们以自己的节奏推进。如果影响在立即见效中是全局的且没有自然的激励，我们发现需要直接推动采用。

FSM：仍然在这个话题上，SIG Architecture 有一个 API Governance 子项目，它与 SIG API Machinery 是否完全独立，还是有重要的连接点？

David：这些项目有相似的名称并对彼此产生一些影响，但有不同的使命和范围。 API Machinery 负责“如何做”，而 API Governance 负责“做什么”。 API 约定、API 审批过程以及对单个 k8s.io API 的最终决定权属于 API Governance。 API Machinery 负责 REST 语义和非 API 特定行为。

Federico：我真得很喜欢 David 的说法： “API Machinery 负责‘如何做’，而 API Governance 负责‘做什么’”：我们并未拥有实际的 API，但实际的 API 依靠我们存在。

Kubernetes 受欢迎的挑战

FSM：随着 Kubernetes 的采用率上升，我们肯定看到了对控制平面的需求增加：你们对这点的感受如何，它如何影响 SIG 的工作？

David：这对 API Machinery 产生了巨大的影响。多年来，我们经常响应并多次促进了 Kubernetes 的发展阶段。作为几乎所有 Kubernetes 集群上权能的集中编排中心，我们既领导又跟随社区。从广义上讲，我看到多年来 API Machinery 经历了一些发展阶段，活跃度一直很高。

寻找目标：从 pre-1.0 到 v1.3（我们达到了第一个 1000+ 节点/命名空间）。这段时间以快速变化为特征。我们经历了五个不同版本的模式，并满足了需求。我们优化了快速、树内 API 的演变（有时以牺牲长期目标为代价），并首次定义了模式。
满足需求的扩展：v1.3-1.9（直到控制器中的共享通知器）。当我们开始尝试满足客户需求时，我们发现了严重的 CPU 和内存规模限制。这也是为什么我们将 API Machinery 扩展到包含访问模式，但我们仍然非常关注树内类型。我们构建了 watch 缓存、protobuf 序列化和共享缓存。

培育生态系统：v1.8-1.21（直到 CRD v1）。这是我们设计和编写 CRD（视为第三方资源的替代品）的时间，满足我们知道即将到来的即时需求（准入 Webhook），以及我们知道需要的最佳实践演变（API 模式）。这促成了早期采用者的爆发式增长，他们愿意在约束内非常谨慎地工作，以实现服务 Pod 的用例。采用速度非常快，有时超出了我们的权能，并形成了新的问题。

简化部署：v1.22+。在不久之前，我们采用扩展机制来响应运行大规模的 Kubernetes 集群的压力，其中包含大量有时会发生冲突的生态系统项目。我们投入了许多努力，使平台更易于扩展，管理更安全，就算不是很精通 Kubernetes 的人也能做到。这些努力始于服务器端应用，并在如今延续到 Webhook 匹配状况和验证准入策略等特性。

API Machinery 的工作对整个项目和生态系统有广泛的影响。对于那些能够长期投入大量时间的人来说，这是一个令人兴奋的工作领域。

未来发展

FSM：考虑到这些不同的发展阶段，你能说说这个 SIG 的当前首要任务是什么吗？

David：大致的顺序为可靠性、效率和权能。

随着 kube-apiserver 和扩展机制的使用增加，我们发现第一套扩展机制虽然在权能方面相当完整，但在潜在误用方面存在重大风险，影响范围很大。为了减轻这些风险，我们正在致力于减少事故影响范围的特性（Webhook 匹配状况）以及为大多数操作提供风险配置较低的替代机制（验证准入策略）。

同时，使用量的增加使我们更加意识到我们可以同时改进服务器端和客户端的扩缩限制。这里的努力包括更高效的序列化（CBOR），减少 etcd 负载（从缓存中一致读取）和减少峰值内存使用量（流式列表）。

最后，使用量的增加突显了一些长期存在的、我们正在设法填补的差距。这些包括针对 CRD 的字段选择算符， Batch Working Group 渴望利用这些选择算符，并最终构建一种新的方法以防止从有漏洞的节点实施“蹦床式”的 Pod 攻击。

加入有趣的我们

FSM：如果有人想要开始贡献，你有什么建议？

Federico：SIG API Machinery 毫不例外也遵循 Kubernetes 的风格：砍柴和挑水（踏实工作，注重细节）。有多个每周例会对所有人开放，总是有更多的工作要做，人手总是不够。

我承认 API Machinery 并不容易，入门的坡度会比较陡峭。门槛较高，就像我们所讨论的原因：我们肩负着巨大的责任。当然凭借激情和毅力，多年来有许多人已经跟了上来，我们希望更多的人加入。

具体的机会方面，每两周有一次 SIG 会议。欢迎所有人参会和听会，了解小组在讨论什么，了解这个版本中发生了什么等等。

此外，每周两次，周二和周四，我们有公开的 Bug 分类管理会，在会上我们会讨论上次会议以来的所有新内容。我们已经保持这种做法 7 年多了。这是一个很好的机会，你可以志愿审查代码、修复 Bug、改进文档等。周二的会议在下午 1 点（PST），周四是在 EMEA 友好时间（上午 9:30 PST）。我们总是在寻找改进的机会，希望能够在未来提供更多具体的参与机会。

FSM：太好了，谢谢！你们还有什么想与我们的读者分享吗？

Federico：正如我提到的，第一步可能较难，但回报也更大。参与 API Machinery 的工作就是在加入一个影响巨大（百万用户？）的领域，你的贡献将直接影响 Kubernetes 的工作方式和使用方式。对我来说，这已经足够作为回报和动力了！

Kubernetes v1.31 中的移除和主要变更

Fri, 19 Jul 2024 00:00:00 +0000

随着 Kubernetes 的发展和成熟，为了项目的整体健康，某些特性可能会被弃用、删除或替换为更好的特性。本文阐述了 Kubernetes v1.31 版本的一些更改计划，发行团队认为你应当了解这些更改，以便持续维护 Kubernetes 环境。下面列出的信息基于 v1.31 版本的当前状态；这些状态可能会在实际发布日期之前发生变化。

Kubernetes API 删除和弃用流程

Kubernetes 项目针对其功能特性有一个详细说明的弃用策略。此策略规定，只有当某稳定 API 的更新、稳定版本可用时，才可以弃用该 API，并且 API 的各个稳定性级别都有对应的生命周期下限。已弃用的 API 标记为在未来的 Kubernetes 版本中删除，这类 API 将继续发挥作用，直至被删除（从弃用起至少一年），但使用时会显示警告。已删除的 API 在当前版本中不再可用，因此你必须将其迁移到替换版本。

正式发布的（GA）或稳定的 API 版本可被标记为已弃用，但不得在 Kubernetes 主要版本未变时删除。
Beta 或预发布 API 版本在被弃用后，必须保持 3 个发布版本中仍然可用。
Alpha 或实验性 API 版本可以在任何版本中删除，不必提前通知。

无论 API 是因为某个特性从 Beta 版升级到稳定版，还是因为此 API 未成功而被删除，所有删除都将符合此弃用策略。每当删除 API 时，迁移选项都会在文档中传达。

关于 SHA-1 签名支持的说明

在 go1.18（2022 年 3 月发布）中，crypto/x509 库开始拒绝使用 SHA-1 哈希函数签名的证书。虽然 SHA-1 被确定为不安全，并且公众信任的证书颁发机构自 2015 年以来就没有颁发过 SHA-1 证书，但在 Kubernetes 环境中，仍可能存在用户提供的证书通过私人颁发机构使用 SHA-1 哈希函数签名的情况，这些证书用于聚合 API 服务器或 Webhook。如果你依赖基于 SHA-1 的证书，则必须通过在环境中设置 GODEBUG=x509sha1=1 以明确选择重新支持这种证书。

鉴于 Go 的 GODEBUG 兼容性策略，x509sha1 GODEBUG 和对 SHA-1 证书的支持将在 2025 年上半年发布的 go1.24 中完全消失。如果你依赖 SHA-1 证书，请开始放弃使用它们。

请参阅 Kubernetes 问题 #125689，以更好地了解对 SHA-1 支持的时间表，以及 Kubernetes 发布采用 go1.24 的计划时间、如何通过指标和审计日志检测 SHA-1 证书使用情况的更多详细信息。

Kubernetes 1.31 中的弃用和删除

弃用节点的 `status.nodeInfo.kubeProxyVersion` 字段（KEP 4004）

Node 的 .status.nodeInfo.kubeProxyVersion 字段在 Kubernetes v1.31 中将被弃用，并将在后续版本中删除。该字段被弃用是因为其取值原来不准确，并且现在也不准确。该字段由 kubelet 设置，而 kubelet 没有关于 kube-proxy 版本或 kube-proxy 是否正在运行的可靠信息。

在 v1.31 中，DisableNodeKubeProxyVersion 特性门控将默认设置为 true，并且 kubelet 将不再尝试为其关联的 Node 设置 .status.kubeProxyVersion 字段。

删除所有云驱动的树内集成组件

正如之前一篇文章中所强调的， v1.31 版本将删除云驱动集成的树内支持的最后剩余部分。这并不意味着你无法与某云驱动集成，只是你现在必须使用推荐的外部集成方法。一些集成组件是 Kubernetes 项目的一部分，其余集成组件则是第三方软件。

这一里程碑标志着将所有云驱动集成组件从 Kubernetes 核心外部化的过程已经完成（KEP-2395），该过程从 Kubernetes v1.26 开始。这一变化有助于 Kubernetes 进一步成为真正的供应商中立平台。

有关云驱动集成的更多详细信息，请阅读我们的 v1.29 云驱动集成特性的博客。有关树内代码删除的更多背景信息，请阅读（v1.29 弃用博客）。

后一个博客还包含对需要迁移到 v1.29 及更高版本的用户有用的信息。

删除 kubelet `--keep-terminated-pod-volumes` 命令行标志

kubelet 标志 --keep-terminated-pod-volumes 已于 2017 年弃用，将在 v1.31 版本中被删除。

你可以在拉取请求 #122082 中找到更多详细信息。

删除 CephFS 卷插件

CephFS 卷插件已在此版本中删除，并且 cephfs 卷类型已无法使用。

建议你改用 CephFS CSI 驱动程序作为第三方存储驱动程序。如果你在将集群版本升级到 v1.31 之前在使用 CephFS 卷插件，则必须重新部署应用才能使用新驱动。

CephFS 卷插件在 v1.28 中正式标记为已弃用。

删除 Ceph RBD 卷插件

v1.31 版本将删除 Ceph RBD 卷插件及其 CSI 迁移支持， rbd 卷类型将无法继续使用。

建议你在集群中使用 RBD CSI 驱动。如果你在将集群版本升级到 v1.31 之前在使用 Ceph RBD 卷插件，则必须重新部署应用以使用新驱动。

Ceph RBD 卷插件在 v1.28 中正式标记为已弃用。

kube-scheduler 中非 CSI 卷限制插件的弃用

v1.31 版本将弃用所有非 CSI 卷限制调度程序插件，并将从默认插件中删除一些已弃用的插件，包括：

AzureDiskLimits
CinderLimits
EBSLimits
GCEPDLimits

建议你改用 NodeVolumeLimits 插件，因为它可以处理与已删除插件相同的功能，因为这些卷类型已迁移到 CSI。如果你在调度器配置中显式使用已弃用的插件，请用 NodeVolumeLimits 插件替换它们。 AzureDiskLimits、CinderLimits、EBSLimits 和 GCEPDLimits 插件将在未来的版本中被删除。

这些插件将从默认调度程序插件列表中删除，因为它们自 Kubernetes v1.14 以来已被弃用。

展望未来

Kubernetes v1.32 计划删除的官方 API 包括：

将删除 flowcontrol.apiserver.k8s.io/v1beta3 API 版本的 FlowSchema 和 PriorityLevelConfiguration。为了做好准备，你可以编辑现有清单并重写客户端软件以使用自 v1.29 起可用的 flowcontrol.apiserver.k8s.io/v1 API 版本。所有现有的持久化对象都可以通过新 API 访问。flowcontrol.apiserver.k8s.io/v1beta3 中需要注意的变化包括优先级配置 spec.limited.nominalConcurrencyShares 字段仅在未指定时默认为 30，并且显式设置为 0 的话不会被更改为 30。

有关更多信息，请参阅 API 弃用指南。

想要了解更多？

Kubernetes 发行说明中会宣布弃用信息。我们将在 Kubernetes v1.31 中正式宣布弃用信息，作为该版本的 CHANGELOG 的一部分。

你可以在发行说明中看到待弃用的公告：

Kubernetes 的十年

Thu, 06 Jun 2024 00:00:00 +0000

十年前的 2014 年 6 月 6 日，Kubernetes 的第一次提交被推送到 GitHub。第一次提交包含了 250 个文件和 47,501 行的 Go、Bash 和 Markdown 代码，开启了我们今天所拥有的项目。谁能预测到 10 年后，Kubernetes 会成长为迄今为止最大的开源项目之一，拥有来自超过 8,000 家公司、来自 44 个国家的 88,000 名贡献者。

这一里程碑不仅属于 Kubernetes，也属于由此蓬勃发展的云原生生态系统。在 CNCF 本身就有近 200 个项目，有来自 240,000 多名个人贡献者，还有数千名来自更大的生态系统的贡献者的贡献。如果没有 700 多万开发者和更庞大的用户社区， Kubernetes 就不会达到今天的成就，他们一起帮助塑造了今天的生态系统。

Kubernetes 的起源 - 技术的融合

Kubernetes 背后的理念早在第一次提交之前，甚至第一个原型（在 2013 年问世之前就已经存在。在 21 世纪初，摩尔定律仍然成立。计算硬件正以惊人的速度变得越来越强大。相应地，应用程序变得越来越复杂。硬件商品化和应用程序复杂性的结合表明需要进一步将软件从硬件中抽象出来，因此解决方案开始出现。

像当时的许多公司一样，Google 正在快速扩张，其工程师对在 Linux 内核中创建一种隔离形式的想法很感兴趣。 Google 工程师 Rohit Seth 在 2006 年的一封电子邮件中描述了这个概念：

我们使用术语 “容器” 来表示一种结构，通过该结构我们可以对负载的系统资源（如内存、任务等）利用情况进行跟踪和计费。

2013 年 3 月，Solomon Hykes 在 PyCon 上进行了一场名为 “Linux容器的未来”的 5 分钟闪电演讲，介绍了名为 “Docker” 的一款即将被推出的开源工具，用于创建和使用 Linux 容器。Docker 提升了 Linux 容器的可用性，使其比以往更容易被更多用户使用，从而使 Docker 和Linux 容器的流行度飙升。随着 Docker 使 Linux 容器的抽象概念可供所有人使用，以更便于移植且可重复的方式运行应用突然成为可能，但大规模使用的问题仍然存在。

Google 用来管理大规模应用编排的 Borg 系统在 2000 年代中期采用当时所开发的 Linux 容器技术。此后，该公司还开始研发该系统的一个新版本，名为 “Omega”。熟悉 Borg 和 Omega 系统的 Google 工程师们看到了 Docker 所推动的容器化技术的流行。他们意识到对一个开源的容器编排系统的需求，而且意识到这一系统的“必然性”，正如 Brendan Burns 在这篇博文中所描述的。这一认识在 2013 年秋天激发了一个小团队开始着手一个后来成为 Kubernetes 的项目。该团队包括 Joe Beda、Brendan Burns、Craig McLuckie、Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant 和 Daniel Smith。

Kubernetes 十年回顾

Kubernetes 的历史始于 2014 年 6 月 6 日的那次历史性提交，随后， Google 工程师 Eric Brewer 在 2014 年 6 月 10 日的 DockerCon 2014 上的主题演讲(及其相应的 Google 博客)中由宣布了该项目。

在接下来的一年里，一个由主要来自 Google 和 Red Hat 等公司的贡献者组成的小型社区为该项目付出了辛勤的努力，最终在 2015 年 7 月 21 日发布了 1.0 版本。在发布 1.0 版本的同时，Google 宣布将 Kubernetes 捐赠给 Linux 基金会下的一个新成立的分支，即云原生计算基金会 (Cloud Native Computing Foundation，CNCF)。

尽管到了 1.0 版本，但 Kubernetes 项目的使用和理解仍然很困难。Kubernetes 贡献者 Kelsey Hightower 特别注意到了该项目在易用性方面的不足，并于 2016 年 7 月 7 日推出了他著名的 “Kubernetes the Hard Way” 指南的第一次提交。

自从最初的 1.0 版本发布以来，项目经历了巨大的变化，取得了许多重大的成就，例如在 1.16 版本中正式发布的 Custom Resource Definitions (CRD) ，或者在 1.23 版本中推出的全面双栈支持，以及社区从 1.22 版本中移除广泛使用的 Beta API 和弃用 Dockershim 中吸取的“教训”。

自 1.0 版本以来的一些值得注意的更新、里程碑和事件包括：

2016 年 12 月 - Kubernetes 1.5 引入了运行时可插拔性，初步支持 CRI 和 Alpha 版 Windows 节点支持。 OpenAPI 也首次出现，为客户端能够发现扩展 API 铺平了道路。
- 此版本还引入了 Beta 版的 StatefulSet 和 PodDisruptionBudget。

2017 年 4 月 — 引入基于角色的访问控制（RBAC）。
2017 年 6 月 — 在 Kubernetes 1.7 中，ThirdPartyResources 或 "TPRs" 被 CustomResourceDefinitions（CRD）取代。
2017 年 12 月 — Kubernetes 1.9 中，工作负载 API 成为 GA（正式可用）。发布博客中指出：“Deployment 和 ReplicaSet 是 Kubernetes 中最常用的两个对象，在经过一年多的实际使用和反馈后，现在已经稳定下来。”

2018 年 12 月 — 在 1.13 版本中，容器存储接口（CSI）达到 GA，用于引导最小可用集群的 kubeadm 工具达到 GA，并且 CoreDNS 成为默认的 DNS 服务器。
2019 年 9 月 — 自定义资源定义（Custom Resource Definition）在 Kubernetes 1.16 中正式发布。
2020 年 8 月 — Kubernetes 1.19 将发布支持窗口增加到 1 年。
2020 年 12 月 — Dockershim 在 1.20 版本中被弃用。

2021 年 4 月 - Kubernetes 发布节奏变更，从每年发布 4 个版本变为每年发布 3 个版本。
2021 年 7 月 - 在 Kubernetes 1.22 中移除了广泛使用的 Beta API。
2022 年 5 月 - 在 Kubernetes 1.24 中，Beta API 默认被禁用，以减少升级冲突，并移除了 Dockershim，导致用户普遍感到困惑（我们已经改进了我们的沟通方式！）
2022 年 12 月 - 在 1.26 版本中，进行了重大的批处理和作业 API 改进，为更好地支持 AI/ML/批处理工作负载铺平了道路。

附言: 想亲自体会一下这个项目的进展么？可以查看由社区成员 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin 创建的 Kubernetes 1.0 集群搭建教程。

Kubernetes 提供的扩展点多得数不胜数。最初设计用于与 Docker 一起工作，现在你可以插入任何符合 CRI 标准的容器运行时。还有其他类似的接口：用于存储的 CSI 和用于网络的 CNI。而且这还远远不是全部。在过去的十年中，出现了全新的模式，例如使用自定义资源定义（CRD）来支持第三方控制器 - 这现在是 Kubernetes 生态系统的重要组成部分。

在过去十年间，参与构建该项目的社区也得到了巨大的扩展。通过使用 DevStats，我们可以看到过去十年中令人难以置信的贡献量，这使得 Kubernetes 成为了全球第二大开源项目：

88,474 位贡献者
15,121 位代码提交者
4,228,347 次贡献
158,530 个问题
311,787 个拉取请求

Kubernetes 现状

自项目初期以来，项目在技术能力、使用率和贡献方面取得了巨大的增长。项目仍在积极努力改进并更好地为用户服务。

在即将发布的 1.31 版本中，该项目将庆祝一个重要的长期项目的完成：移除内部云提供商代码。在这个 Kubernetes 历史上最大的迁移中，大约删除了 150 万行代码，将核心组件的二进制文件大小减小了约 40%。在项目早期，很明显可扩展性是成功的关键。然而，如何实现这种可扩展性并不总是很清楚。此次迁移从核心 Kubernetes 代码库中删除了各种特定于供应商的功能。现在，特定于供应商的功能可以通过其他可插拔的扩展功能或模式更好地提供，例如自定义资源定义（CRD）或 Gateway API 等 API 标准。 Kubernetes 在为其庞大的用户群体提供服务时也面临着新的挑战，社区正在相应地进行调整。其中一个例子是将镜像托管迁移到新的、由社区拥有的 registry.k8s.io。为用户提供预编译二进制镜像的出口带宽和成本已经变得非常巨大。这一新的仓库变更使社区能够以更具成本效益和性能高效的方式继续提供这些便利的镜像。请务必查看此博客文章并更新你必须使用 registry.k8s.io 仓库的任何自动化设施！

Kubernetes 的未来

十年过去了，Kubernetes 的未来依然光明。社区正在优先考虑改进用户体验和增强项目可持续性的变革。应用程序开发的世界不断演变，Kubernetes 正准备随之变化。

2024 年，人工智能的进展将一种曾经小众的工作负载类型变成了一种非常重要的工作负载类型。分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载的资源密集需求密切相关。贡献者们密切关注新开发的工作负载的需求以及 Kubernetes 如何为它们提供最佳服务。新成立的 Serving 工作组就是社区组织来解决这些工作负载需求的一个例子。未来几年可能会看到 Kubernetes 在管理各种类型的硬件以及管理跨硬件运行的大型批处理工作负载的调度能力方面的改进。

Kubernetes 周围的生态系统将继续发展壮大。未来，为了保持项目的可持续性，像内部供应商代码的迁移和仓库变更这样的举措将变得更加重要。

Kubernetes 的未来 10 年将由其用户和生态系统引领，但最重要的是，由为其做出贡献的人引领。社区对新贡献者持开放态度。你可以在我们的新贡献者课程 https://k8s.dev/docs/onboarding 中找到更多有关贡献的信息。

我们期待与你一起构建 Kubernetes 的未来！

完成 Kubernetes 史上最大规模迁移

Mon, 20 May 2024 00:00:00 +0000

早自 Kubernetes v1.7 起，Kubernetes 项目就开始追求取消集成内置云驱动（KEP-2395）。虽然这些集成对于 Kubernetes 的早期发展和增长发挥了重要作用，但它们的移除是由两个关键因素驱动的：为各云启动维护数百万行 Go 代码的原生支持所带来的日趋增长的复杂度，以及将 Kubernetes 打造为真正的供应商中立平台的愿景。

历经很多发布版本之后，我们很高兴地宣布所有云驱动集成组件已被成功地从核心 Kubernetes 仓库迁移到外部插件中。除了实现我们最初的目标之外，我们还通过删除大约 150 万行代码，将核心组件的可执行文件大小减少了大约 40%，极大简化了 Kubernetes。

由于受影响的组件众多，而且关键代码路径依赖于五个初始云驱动（Google Cloud、AWS、Azure、OpenStack 和 vSphere）的内置集成，因此此次迁移是一项复杂且耗时的工作。为了成功完成此迁移，我们必须从头开始构建四个新的子系统：

云控制器管理器（Cloud controller manager）（KEP-2392）
API 服务器网络代理（KEP-1281）
kubelet 凭证提供程序插件（KEP-2133）
存储迁移以使用 CSI（KEP-625）

就与内置功能实现完全的特性等价而言，每个子系统都至关重要，并且需要迭代多个版本才能使每个子系统达到 GA 级别并具有安全可靠的迁移路径。下面详细介绍每个子系统。

云控制器管理器

云控制器管理器是这项工作中引入的第一个外部组件，取代了 kube-controller-manager 和 kubelet 中直接与云 API 交互的功能。这个基本组件负责通过施加元数据标签来初始化节点。所施加的元数据标签标示节点运行所在的云区域和可用区，以及只有云驱动知道的 IP 地址。此外，它还运行服务控制器，该控制器负责为 LoadBalancer 类型的 Service 配置云负载均衡器。

要进一步了解相关信息，请阅读 Kubernetes 文档中的云控制器管理器。

API 服务器网络代理

API 服务器网络代理项目于 2018 年与 SIG API Machinery 合作启动，旨在取代 kube-apiserver 中的 SSH 隧道功能。该隧道器原用于安全地代理 Kubernetes 控制平面和节点之间的流量，但它重度依赖于 kube-apiserver 中所嵌入的、特定于提供商的实现细节来建立这些 SSH 隧道。

现在，API 服务器网络代理成为 kube-apiserver 中 GA 级别的扩展点。提供了一种通用代理机制，可以通过一个安全的代理将流量从 API 服务器路由到节点，从而使 API 服务器无需了解其运行所在的特定云驱动。此项目还引入了 Konnectivity 项目，该项目在生产环境中的采用越来越多。

你可以在其 README 中了解有关 API 服务器网络代理的更多信息。

kubelet 的凭据提供程序插件

kubelet 凭据提供程序插件的开发是为了取代 kubelet 的内置功能，用于动态获取用于托管在 Google Cloud、AWS 或 Azure 上的镜像仓库的凭据。原来所实现的功能很方便，因为它允许 kubelet 无缝地获取短期令牌以从 GCR、ECR 或 ACR 拉取镜像然而，与 Kubernetes 的其他领域一样，支持这一点需要 kubelet 具有不同云环境和 API 的特定知识。

凭据驱动插件机制于 2019 年推出，为 kubelet 提供了一个通用扩展点用于执行插件的可执行文件，进而为访问各种云上托管的镜像动态提供凭据。可扩展性扩展了 kubelet 获取短期令牌的能力，且不受限于最初的三个云驱动。

要了解更多信息，请阅读用于认证镜像拉取的 kubelet 凭据提供程序。

存储插件从树内迁移到 CSI

容器存储接口（Container Storage Interface，CSI）是一种控制平面标准，用于管理 Kubernetes 和其他容器编排系统中的块和文件存储系统，已在 1.13 中进入正式发布状态。它的设计目标是用可在 Kubernetes 集群中 Pod 内运行的驱动程序替换直接内置于 Kubernetes 中的树内卷插件。这些驱动程序通过 Kubernetes API 与 kube-controller-manager 存储控制器通信，并通过本地 gRPC 端点与 kubelet 进行通信。现在，所有主要云和存储供应商一起提供了 100 多个 CSI 驱动，使 Kubernetes 中运行有状态工作负载成为现实。

然而，如何处理树内卷 API 的所有现有用户仍然是一个重大挑战。为了保持 API 向后兼容性，我们在控制器中构建了一个 API 转换层，把树内卷 API 转换为等效的 CSI API。这使我们能够将所有存储操作重定向到 CSI 驱动程序，为我们在不删除 API 的情况下删除内置卷插件的代码铺平了道路。

你可以在 Kubernetes 树内卷到 CSI 卷的迁移进入 Beta 阶段。

下一步是什么？

过去几年，这一迁移工程一直是 SIG Cloud Provider 的主要关注点。随着这一重要里程碑的实现，我们将把努力转向探索新的创新方法，让 Kubernetes 更好地与云驱动集成，利用我们多年来构建的外部子系统。这包括使 Kubernetes 在混合环境中变得更加智能，其集群中的节点可以运行在公共云和私有云上，以及为外部驱动的开发人员提供更好的工具和框架，以简化他们的集成工作，提高效率。

在规划所有这些新特性、工具和框架的同时，SIG Cloud Provider 并没有忘记另一项同样重要的工作：测试。 SIG 未来活动的另一个重点领域是改进云控制器测试以涵盖更多的驱动。这项工作的最终目标是创建一个包含尽可能多驱动的测试框架，以便我们让 Kubernetes 社区对其 Kubernetes 环境充满信心。

如果你使用的 Kubernetes 版本早于 v1.29 并且尚未迁移到外部云驱动，我们建议你查阅我们之前的博客文章 Kubernetes 1.29：云驱动集成现在是单独的组件。该博客包含与我们所作的变更相关的详细信息，并提供了有关如何迁移到外部驱动的指导。从 v1.31 开始，树内云驱动将被永久禁用并从核心 Kubernetes 组件中删除。

如果你有兴趣做出贡献，请参加我们的每两周一次的 SIG 会议!

Gateway API v1.1：服务网格、GRPCRoute 和更多变化

Thu, 09 May 2024 09:00:00 -0800

继去年十月正式发布 Gateway API 之后，Kubernetes SIG Network 现在又很高兴地宣布 Gateway API v1.1 版本发布。在本次发布中，有几个特性已进阶至标准渠道（GA），特别是对服务网格和 GRPCRoute 的支持也已进阶。我们还引入了一些新的实验性特性，包括会话持久性和客户端证书验证。

新内容

进阶至标准渠道

本次发布有四个备受期待的特性进阶至标准渠道。这意味着它们不再是实验性的概念；包含在标准发布渠道中的举措展现了大家对 API 接口的高度信心，并提供向后兼容的保证。当然，与所有其他 Kubernetes API 一样，标准渠道的特性可以随着时间的推移通过向后兼容的方式演进，我们当然期待未来对这些新特性有进一步的优化和改进。有关细节请参阅 Gateway API 版本控制政策。

服务网格支持

在 Gateway API 中支持服务网格意味着允许服务网格用户使用相同的 API 来管理 Ingress 流量和网格流量，能够重用相同的策略和路由接口。在 Gateway API v1.1 中，路由（如 HTTPRoute）现在可以将一个 Service 作为 parentRef，以控制到特定服务的流量行为。有关细节请查阅 Gateway API 服务网格文档或 Gateway API 实现列表。

例如，你可以使用如下 HTTPRoute 以金丝雀部署深入到应用调用图中的工作负载：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

通过使用一种便于从一个网格迁移到另一个网格的可移植配置，此 HTTPRoute 对象将把发送到 faces 命名空间中的 color Service 的流量按 50/50 拆分到原始的 color Service 和 color2 Service 上。

GRPCRoute

如果你已经在使用实验性版本的 GRPCRoute，我们建议你暂时不要升级到标准渠道版本的 GRPCRoute，除非你正使用的控制器已被更新为支持 GRPCRoute v1。在此之后，你才可以安全地升级到实验性渠道版本的 GRPCRoute v1.1，这个版本同时包含了 v1alpha2 和 v1 的 API。

ParentReference 端口

port 字段已被添加到 ParentReference 中，允许你将资源挂接到 Gateway 监听器、Service 或其他父资源（取决于实现）。绑定到某个端口还允许你一次挂接到多个监听器。

例如，你可以将 HTTPRoute 挂接到由监听器 port 而不是监听器 name 字段所指定的一个或多个特定监听器。

有关细节请参阅挂接到 Gateways。

合规性配置文件和报告

合规性报告 API 被扩展了，添加了 mode 字段（用于指定实现的工作模式）以及 gatewayAPIChannel（标准或实验性）。 gatewayAPIVersion 和 gatewayAPIChannel 现在由套件机制自动填充，并附有测试结果的简要描述。这些报告已通过更加结构化的方式进行重新组织，现在实现可以添加测试是如何运行的有关信息，还能提供复现步骤。

实验性渠道的新增内容

Gateway 客户端证书验证

Gateway 现在可以通过在 tls 内引入的新字段 frontendValidation 来为每个 Gateway 监听器配置客户端证书验证。此字段支持配置可用作信任锚的 CA 证书列表，以验证客户端呈现的证书。

以下示例显示了如何使用存储在 foo-example-com-ca-cert ConfigMap 中的 CACertificate 来验证连接到 foo-https Gateway 监听器的客户端所呈现的证书。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

会话持久性和 BackendLBPolicy

会话持久性通过新的策略（BackendLBPolicy）引入到 Gateway API 中用于服务级配置，在 HTTPRoute 和 GRPCRoute 内以字段的形式用于路由级配置。 BackendLBPolicy 和路由级 API 提供相同的会话持久性配置，包括会话超时、会话名称、会话类型和 cookie 生命周期类型。

以下是 BackendLBPolicy 的示例配置，为 foo 服务启用基于 Cookie 的会话持久性。它将会话名称设置为 foo-session，定义绝对超时时间和空闲超时时间，并将 Cookie 配置为会话 Cookie：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

其他更新

TLS 术语阐述

为了在整个 API 中让我们的 TLS 术语更加一致以实现更广泛的目标，我们对 BackendTLSPolicy 做了一些破坏性变更。这就产生了新的 API 版本（v1alpha3），且将需要这个策略所有现有的实现来正确处理版本升级，例如通过备份数据并在安装这个新版本之前卸载 v1alpha2 版本。

所有引用了 v1alpha2 BackendTLSPolicy 的字段都将需要更新为 v1alpha3。这些字段的具体变更包括：

targetRef 变为 targetRefs 以允许 BackendTLSPolicy 挂接到多个目标
tls 变为 validation
tls.caCertRefs 变为 validation.caCertificateRefs
tls.wellKnownCACerts 变为 validation.wellKnownCACertificates

有关本次发布包含的完整变更列表，请参阅 v1.1.0 发布说明。

Gateway API 背景

Gateway API 的想法最初是在 2019 年 KubeCon San Diego 上作为下一代 Ingress API 提出的。从那时起，一个令人瞩目的社区逐渐形成，共同开发出了可能成为 Kubernetes 历史上最具合作精神的 API。到目前为止，已有超过 200 人为该 API 做过贡献，而且这一数字还在不断攀升。

维护者们要感谢为 Gateway API 做出贡献的每一个人，无论是提交代码、参与讨论、提供创意，还是给予常规支持，我们都在此表示诚挚的感谢。没有这个专注且活跃的社区的支持，我们不可能走到这一步。

试用一下

与其他 Kubernetes API 不同，你不需要升级到最新版本的 Kubernetes 即可获得最新版本的 Gateway API。只要你运行的是 Kubernetes 1.26 或更高版本，你就可以使用这个版本的 Gateway API。

要试用此 API，请参阅入门指南。

参与进来

你有很多机会可以参与进来并帮助为 Ingress 和服务网格定义 Kubernetes 路由 API 的未来。

查阅用户指南以了解可以解决哪些用例。
试用其中一个现有的 Gateway 控制器。
或者加入我们的社区，帮助我们一起构建 Gateway API 的未来！

2023 年 11 月 Gateway API v1.0 中的新实验性特性
2023 年 10 月 Gateway API v1.0：正式发布（GA）
2023 年 10 月介绍 ingress2gateway；简化 Gateway API 升级
2023 年 8 月 Gateway API v0.8.0：引入服务网格支持

Kubernetes 1.30：防止未经授权的卷模式转换进阶到 GA

Tue, 30 Apr 2024 00:00:00 +0000

作者: Raunak Pradip Shah (Mirantis)

译者: Xin Li (DaoCloud)

随着 Kubernetes 1.30 的发布，防止修改从 Kubernetes 集群中现有 VolumeSnapshot 创建的 PersistentVolumeClaim 的卷模式的特性已被升级至 GA！

问题

PersistentVolumeClaim 的卷模式是指存储设备上的底层卷是被格式化为某文件系统还是作为原始块设备呈现给使用它的 Pod。

用户可以利用自 Kubernetes v1.20 以来一直稳定的 VolumeSnapshot 特性，基于 Kubernetes 集群中现有的 VolumeSnapshot 创建 PersistentVolumeClaim（简称 PVC）。 PVC 规约中包括一个 dataSource 字段，它可以指向现有的 VolumeSnapshot 实例。有关如何基于 Kubernetes 集群中现有 VolumeSnapshot 创建 PVC 的更多详细信息，请访问使用卷快照创建 PersistentVolumeClaim。

当利用上述特性时，没有逻辑来验证制作快照的原始卷的模式是否与新创建的卷的模式匹配。

这带来了一个安全漏洞，允许恶意用户潜在地利用主机操作系统中未知的漏洞。

有一个合法的场景允许某些用户执行此类转换。通常，存储备份供应商会在备份操作过程中转换卷模式，通过检索已被更改的块来提高操作效率。这使得 Kubernetes 无法完全阻止此类操作，但给区分可信用户和恶意用户带来了挑战。

防止未经授权的用户转换卷模式

在此上下文中，授权用户是有权对 VolumeSnapshotContents（集群级资源）执行 update 或 patch 操作的用户。集群管理员应仅向受信任的用户或应用程序（例如备份供应商）赋予这些权限。当从 VolumeSnapshot 创建 PVC 时，除了此类授权用户之外的用户将永远不会被允许修改 PVC 的卷模式。

要转换卷模式，授权用户必须执行以下操作：

标识要用作给定命名空间中新创建的 PVC 的数据源的 VolumeSnapshot。
识别与上述 VolumeSnapshot 绑定的 VolumeSnapshotContent。
```
kubectl describe volumesnapshot -n <namespace> <name>
```

在 VolumeSnapshotContent 上添加 snapshot.storage.kubernetes.io/allow-volume-mode-change: "true" 注解，VolumeSnapshotContent 注解必须包含类似于以下清单片段：
```
kind: VolumeSnapshotContent
metadata:
  annotations:
    - snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
...
```

注意：对于预配置的 VolumeSnapshotContents，你必须执行额外的步骤，将 spec.sourceVolumeMode 字段设置为 Filesystem 或 Block，具体取决于用来制作此快照的卷的模式。

一个例子如下所示：

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  annotations:
  - snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
  name: <volume-snapshot-content-name>
spec:
  deletionPolicy: Delete
  driver: hostpath.csi.k8s.io
  source:
    snapshotHandle: <snapshot-handle>
  sourceVolumeMode: Filesystem
  volumeSnapshotRef:
    name: <volume-snapshot-name>
    namespace: <namespace>

对备份或恢复操作期间需要转换卷模式的所有 VolumeSnapshotContent 重复步骤 1 至 3。这可以通过具有授权用户凭据的软件来完成，也可以由授权用户手动完成。

如果 VolumeSnapshotContent 对象上存在上面显示的注解，Kubernetes 将不会阻止卷模式转换。用户在尝试将注解添加到任何 VolumeSnapshotContent 之前应记住这一点。

需要采取的行动

默认情况下，在 external-provisioner v4.0.0 和 external-snapshotter v7.0.0 中启用 prevent-volume-mode-conversion 特性标志。基于 VolumeSnapshot 来创建 PVC 时，卷模式更改将被拒绝，除非已执行上述步骤。

接下来

要确定哪些 CSI 外部 sidecar 版本支持此功能，请前往 CSI 文档页面。对于任何疑问或问题，请加入 Slack 上的 Kubernetes 并在 #csi 或 #sig-storage 频道中发起讨论。或者，在 CSI 外部快照仓库中登记问题。

Kubernetes 1.30：结构化身份认证配置进阶至 Beta

Thu, 25 Apr 2024 00:00:00 +0000

在 Kubernetes 1.30 中，我们（SIG Auth）将结构化身份认证配置（Structured Authentication Configuration）进阶至 Beta。

今天的文章是关于身份认证：找出谁在执行任务，核查他们是否是自己所说的那个人。本文还述及 Kubernetes v1.30 中关于鉴权（决定某些人能访问什么，不能访问什么）的新内容。

动机

Kubernetes 长期以来都需要一个更灵活、更好扩展的身份认证系统。当前的系统虽然强大，但有一些限制，使其难以用在某些场景下。例如，不可能同时使用多个相同类型的认证组件（例如，多个 JWT 认证组件），也不可能在不重启 API 服务器的情况下更改身份认证配置。结构化身份认证配置特性是解决这些限制并提供一种更灵活、更好扩展的方式来配置 Kubernetes 中身份认证的第一步。

什么是结构化身份认证配置？

Kubernetes v1.30 针对基于文件来配置身份认证提供实验性支持，这是在 Kubernetes v1.30 中新增的 Alpha 特性。在此 Beta 阶段，Kubernetes 仅支持配置 JWT 认证组件，这是现有 OIDC 认证组件的下一次迭代。 JWT 认证组件使用符合 JWT 标准的令牌对 Kubernetes 用户进行身份认证。此认证组件将尝试解析原始 ID 令牌，验证其是否由配置的签发方签名。

Kubernetes 项目新增了基于文件的配置，以便提供比使用命令行选项（命令行依然有效，仍受支持）更灵活的方式。对配置文件的支持还使得在即将发布的版本中更容易提供更多改进措施。

结构化身份认证配置的好处

以下是使用配置文件来配置集群身份认证的好处：

多个 JWT 认证组件：你可以同时配置多个 JWT 认证组件。这允许你使用多个身份提供程序（例如 Okta、Keycloak、GitLab）而无需使用像 Dex 这样的中间程序来处理多个身份提供程序之间的多路复用。
动态配置：你可以在不重启 API 服务器的情况下更改配置。这允许你添加、移除或修改认证组件而不会中断 API 服务器。

任何符合 JWT 标准的令牌：你可以使用任何符合 JWT 标准的令牌进行身份认证。这允许你使用任何支持 JWT 的身份提供程序的令牌。最小有效的 JWT 载荷必须包含 Kubernetes 文档中结构化身份认证配置页面中记录的申领。
CEL（通用表达式语言）支持：你可以使用 CEL 来确定令牌的申领是否与 Kubernetes 中用户的属性（例如用户名、组）匹配。这允许你使用复杂逻辑来确定令牌是否有效。

多个受众群体：你可以为单个认证组件配置多个受众群体。这允许你为多个受众群体使用相同的认证组件，例如为 kubectl 和仪表板使用不同的 OAuth 客户端。
使用不支持 OpenID 连接发现的身份提供程序：你可以使用不支持 OpenID 连接发现的身份提供程序。唯一的要求是将发现文档托管到与签发方不同的位置（例如在集群中本地），并在配置文件中指定 issuer.discoveryURL。

如何使用结构化身份认证配置

要使用结构化身份认证配置，你可以使用 --authentication-config 命令行参数在 API 服务器中指定身份认证配置的路径。此配置文件是一个 YAML 文件，指定认证组件及其配置。以下是一个配置两个 JWT 认证组件的示例配置文件：

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# 如果某人具有这些 issuer 之一签发的有效令牌，则此人可以在集群上进行身份认证
jwt:
- issuer:
    url: https://issuer1.example.com
    audiences:
    - audience1
    - audience2
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"
# 第二个认证组件将发现文档公布于与签发方不同的位置
- issuer:
    url: https://issuer2.example.com
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    audiences:
    - audience3
    - audience4
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"

从命令行参数迁移到配置文件

结构化身份认证配置特性旨在与基于命令行选项配置 JWT 认证组件的现有方法向后兼容。这意味着你可以继续使用现有的命令行选项来配置 JWT 认证组件。但是，我们（Kubernetes SIG Auth）建议迁移到新的基于配置文件的方法，因为这种方法更灵活，更好扩展。

Note

如果你同时指定 --authentication-config 和任何 --oidc-* 命令行参数，这是一种错误的配置。在这种情况下，API 服务器会报告错误，然后立即退出。

如果你想切换到使用结构化身份认证配置，你必须移除 --oidc-* 命令行参数，并改为使用配置文件。

以下是如何从命令行标志迁移到配置文件的示例：

命令行参数

--oidc-issuer-url=https://issuer.example.com
--oidc-client-id=example-client-id
--oidc-username-claim=username
--oidc-groups-claim=groups
--oidc-username-prefix=oidc:
--oidc-groups-prefix=oidc:
--oidc-required-claim="hd=example.com"
--oidc-required-claim="admin=true"
--oidc-ca-file=/path/to/ca.pem

在配置文件中没有与 --oidc-signing-algs 相对应的配置项。对于 Kubernetes v1.30，认证组件支持在 oidc.go 中列出的所有非对称算法。

配置文件

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://issuer.example.com
    audiences:
    - example-client-id
    certificateAuthority: <取值是 /path/to/ca.pem 文件的内容>
  claimMappings:
    username:
      claim: username
      prefix: "oidc:"
    groups:
      claim: groups
      prefix: "oidc:"
  claimValidationRules:
  - claim: hd
    requiredValue: "example.com"
  - claim: admin
    requiredValue: "true"

下一步是什么？

对于 Kubernetes v1.31，我们预计该特性将保持在 Beta，我们要收集更多反馈意见。在即将发布的版本中，我们希望调查以下内容：

通过 CEL 表达式使分布式申领生效。
对 issuer.url 和 issuer.discoveryURL 的调用提供 Egress 选择算符配置支持。

你可以在 Kubernetes 文档的结构化身份认证配置页面上了解关于此特性的更多信息。你还可以通过 KEP-3331 跟踪未来 Kubernetes 版本中的进展。

试用一下

在本文中，我介绍了结构化身份认证配置特性在 Kubernetes v1.30 中带来的好处。要使用此特性，你必须使用 --authentication-config 命令行参数指定身份认证配置的路径。从 Kubernetes v1.30 开始，此特性处于 Beta 并默认启用。如果你希望继续使用命令行参数而不想用配置文件，原来的命令行参数也将继续按原样起作用。

我们很高兴听取你对此特性的反馈意见。请在 Kubernetes Slack 上的 #sig-auth-authenticators-dev 频道与我们联系（若要获取邀请，请访问 https://slack.k8s.io/）。

如何参与

如果你有兴趣参与此特性的开发、分享反馈意见或参与任何其他 SIG Auth 项目，请在 Kubernetes Slack 上的 #sig-auth 频道联系我们。

我们也欢迎你参加 SIG Auth 双周会议。

Kubernetes 1.30：验证准入策略 ValidatingAdmissionPolicy 正式发布

Wed, 24 Apr 2024 00:00:00 +0000

我代表 Kubernetes 项目组成员，很高兴地宣布 ValidatingAdmissionPolicy 已经作为 Kubernetes 1.30 发布的一部分正式发布。如果你还不了解这个全新的声明式验证准入 Webhook 的替代方案，请参阅有关这个新特性的上一篇博文。如果你已经对 ValidatingAdmissionPolicy 有所了解并且想要尝试一下，那么现在是最好的时机。

让我们替换一个简单的 Webhook，体验一下 ValidatingAdmissionPolicy。

准入 Webhook 示例

首先，让我们看一个简单 Webhook 的示例。以下是一个强制将 runAsNonRoot、readOnlyRootFilesystem、allowPrivilegeEscalation 和 privileged 设置为最低权限值的 Webhook 代码片段。

func verifyDeployment(deploy *appsv1.Deployment) error {
	var errs []error
	for i, c := range deploy.Spec.Template.Spec.Containers {
		if c.Name == "" {
			return fmt.Errorf("container %d has no name", i)
		}
		if c.SecurityContext == nil {
			errs = append(errs, fmt.Errorf("container %q does not have SecurityContext", c.Name))
		}
		if c.SecurityContext.RunAsNonRoot == nil || !*c.SecurityContext.RunAsNonRoot {
			errs = append(errs, fmt.Errorf("container %q must set RunAsNonRoot to true in its SecurityContext", c.Name))
		}
		if c.SecurityContext.ReadOnlyRootFilesystem == nil || !*c.SecurityContext.ReadOnlyRootFilesystem {
			errs = append(errs, fmt.Errorf("container %q must set ReadOnlyRootFilesystem to true in its SecurityContext", c.Name))
		}
		if c.SecurityContext.AllowPrivilegeEscalation != nil && *c.SecurityContext.AllowPrivilegeEscalation {
			errs = append(errs, fmt.Errorf("container %q must NOT set AllowPrivilegeEscalation to true in its SecurityContext", c.Name))
		}
		if c.SecurityContext.Privileged != nil && *c.SecurityContext.Privileged {
			errs = append(errs, fmt.Errorf("container %q must NOT set Privileged to true in its SecurityContext", c.Name))
		}
	}
	return errors.NewAggregate(errs)
}

查阅什么是准入 Webhook？，或者查看这个 Webhook 的完整代码以便更好地理解下述演示。

策略

现在，让我们尝试使用 ValidatingAdmissionPolicy 来忠实地重新创建验证。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "pod-security.policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
  - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.runAsNonRoot) && c.securityContext.runAsNonRoot)
    message: 'all containers must set runAsNonRoot to true'
  - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.readOnlyRootFilesystem) && c.securityContext.readOnlyRootFilesystem)
    message: 'all containers must set readOnlyRootFilesystem to true'
  - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.allowPrivilegeEscalation) || !c.securityContext.allowPrivilegeEscalation)
    message: 'all containers must NOT set allowPrivilegeEscalation to true'
  - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.Privileged) || !c.securityContext.Privileged)
    message: 'all containers must NOT set privileged to true'

使用 kubectl 创建策略。很好，到目前为止没有任何问题。那我们获取此策略对象并查看其状态。

kubectl get -oyaml validatingadmissionpolicies/pod-security.policy.example.com

  status:
    typeChecking:
      expressionWarnings:
      - fieldRef: spec.validations[3].expression
        warning: |
          apps/v1, Kind=Deployment: ERROR: <input>:1:76: undefined field 'Privileged'
           | object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.Privileged) || !c.securityContext.Privileged)
           | ...........................................................................^
          ERROR: <input>:1:128: undefined field 'Privileged'
           | object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.Privileged) || !c.securityContext.Privileged)
           | ...............................................................................................................................^

系统根据所匹配的类别 apps/v1.Deployment 对策略执行了检查。查看 fieldRef 后，发现问题出现在第 3 个表达式上（索引从 0 开始）。有问题的表达式访问了一个未定义的 Privileged 字段。噢，看起来是一个复制粘贴错误。字段名应该是小写的。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "pod-security.policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
  - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.runAsNonRoot) && c.securityContext.runAsNonRoot)
    message: 'all containers must set runAsNonRoot to true'
  - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.readOnlyRootFilesystem) && c.securityContext.readOnlyRootFilesystem)
    message: 'all containers must set readOnlyRootFilesystem to true'
  - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.allowPrivilegeEscalation) || !c.securityContext.allowPrivilegeEscalation)
    message: 'all containers must NOT set allowPrivilegeEscalation to true'
  - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || !c.securityContext.privileged)
    message: 'all containers must NOT set privileged to true'

再次检查状态，你应该看到所有警告都已被清除。

接下来，我们创建一个命名空间进行测试。

kubectl create namespace policy-test

接下来，我将策略绑定到命名空间。但此时我将动作设置为 Warn，这样此策略将打印出警告而不是拒绝请求。这对于在开发和自动化测试期间收集所有表达式的结果非常有用。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "pod-security.policy-binding.example.com"
spec:
  policyName: "pod-security.policy.example.com"
  validationActions: ["Warn"]
  matchResources:
    namespaceSelector:
      matchLabels:
        "kubernetes.io/metadata.name": "policy-test"

测试策略的执行过程。

kubectl create -n policy-test -f- <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        securityContext:
          privileged: true
          allowPrivilegeEscalation: true
EOF

Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must set runAsNonRoot to true
Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must set readOnlyRootFilesystem to true
Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must NOT set allowPrivilegeEscalation to true
Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must NOT set privileged to true
Error from server: error when creating "STDIN": admission webhook "webhook.example.com" denied the request: [container "nginx" must set RunAsNonRoot to true in its SecurityContext, container "nginx" must set ReadOnlyRootFilesystem to true in its SecurityContext, container "nginx" must NOT set AllowPrivilegeEscalation to true in its SecurityContext, container "nginx" must NOT set Privileged to true in its SecurityContext]

看起来很不错！策略和 Webhook 给出了等效的结果。又测试了其他几种情形后，当我们对策略有信心时，也许是时候进行一些清理工作了。

对于每个表达式，我们重复访问 object.spec.template.spec.containers 和每个 securityContext；
有一个检查某字段是否存在然后访问该字段的模式，这种模式看起来有点繁琐。

幸运的是，自 Kubernetes 1.28 以来，我们对这两个问题都有了新的解决方案。变量组合（Variable Composition）允许我们将重复的子表达式提取到单独的变量中。 Kubernetes 允许为 CEL 使用可选库，这些库非常适合处理可选的字段，你猜对了。

在了解了这两个特性后，让我们稍微重构一下此策略。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "pod-security.policy.example.com"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  variables:
  - name: containers
    expression: object.spec.template.spec.containers
  - name: securityContexts
    expression: 'variables.containers.map(c, c.?securityContext)'
  validations:
  - expression: variables.securityContexts.all(c, c.?runAsNonRoot == optional.of(true))
    message: 'all containers must set runAsNonRoot to true'
  - expression: variables.securityContexts.all(c, c.?readOnlyRootFilesystem == optional.of(true))
    message: 'all containers must set readOnlyRootFilesystem to true'
  - expression: variables.securityContexts.all(c, c.?allowPrivilegeEscalation != optional.of(true))
    message: 'all containers must NOT set allowPrivilegeEscalation to true'
  - expression: variables.securityContexts.all(c, c.?privileged != optional.of(true))
    message: 'all containers must NOT set privileged to true'

策略现在更简洁、更易读。更新策略后，你应该看到它的功用与之前无异。

现在让我们将策略绑定从警告更改为实际拒绝验证失败的请求。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "pod-security.policy-binding.example.com"
spec:
  policyName: "pod-security.policy.example.com"
  validationActions: ["Deny"]
  matchResources:
    namespaceSelector:
      matchLabels:
        "kubernetes.io/metadata.name": "policy-test"

最后，移除 Webhook。现在结果应该只包含来自策略的消息。

kubectl create -n policy-test -f- <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        securityContext:
          privileged: true
          allowPrivilegeEscalation: true
EOF

The deployments "nginx" is invalid: : ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com' denied request: all containers must set runAsNonRoot to true

请注意，根据设计，此策略在第一个导致请求被拒绝的表达式之后停止处理。这与表达式只生成警告时的情况不同。

设置监控

与 Webhook 不同，策略不是一个可以公开其自身指标的专用进程。相反，你可以使用源自 API 服务器的指标来代替。

以下是使用 Prometheus 查询语言执行一些常见监控任务的示例。

找到上述策略执行期间的 95 分位值：

histogram_quantile(0.95, sum(rate(apiserver_validating_admission_policy_check_duration_seconds_bucket{policy="pod-security.policy.example.com"}[5m])) by (le))

找到策略评估的速率：

rate(apiserver_validating_admission_policy_check_total{policy="pod-security.policy.example.com"}[5m])

你可以阅读指标参考了解有关上述指标的更多信息。 ValidatingAdmissionPolicy 的指标目前处于 Alpha 阶段，随着稳定性在未来版本中的提升，将会有更多和更好的指标。

Kubernetes 1.30：只读卷挂载终于可以真正实现只读了

Tue, 23 Apr 2024 00:00:00 +0000

作者: Akihiro Suda (NTT)

译者: Xin Li (DaoCloud)

只读卷挂载从一开始就是 Kubernetes 的一个特性。令人惊讶的是，在 Linux 上的某些条件下，只读挂载并不是完全只读的。从 v1.30 版本开始，这类卷挂载可以被处理为完全只读；v1.30 为递归只读挂载提供 Alpha 支持。

默认情况下，只读卷装载并不是真正的只读

卷挂载可能看似复杂。

你可能期望以下清单使容器中 /mnt 下的所有内容变为只读：

---
apiVersion: v1
kind: Pod
spec:
  volumes:
    - name: mnt
      hostPath:
        path: /mnt
  containers:
    - volumeMounts:
        - name: mnt
          mountPath: /mnt
          readOnly: true

但是，/mnt 下的任何子挂载可能仍然是可写的！例如，假设 /mnt/my-nfs-server 在主机上是可写的。在容器内部，写入 /mnt/* 将被拒绝，但 /mnt/my-nfs-server/* 仍然可写。

新的挂载选项：递归只读

Kubernetes 1.30 添加了一个新的挂载选项 recursiveReadOnly，以使子挂载递归只读。

可以按如下方式启用该选项：

---
apiVersion: v1
kind: Pod
spec:
  volumes:
    - name: mnt
      hostPath:
        path: /mnt
  containers:
    - volumeMounts:
        - name: mnt
          mountPath: /mnt
          readOnly: true
          # NEW
          # 可能的值为 `Enabled`、`IfPossible` 和 `Disabled`。
          # 需要与 `readOnly: true` 一起指定。
          recursiveReadOnly: Enabled

这是通过使用 Linux 内核 v5.12 中添加的 mount_setattr(2) 应用带有 AT_RECURSIVE 标志的 MOUNT_ATTR_RDONLY 属性来实现的。

为了向后兼容，recursiveReadOnly 字段不是 readOnly 的替代品，而是与其结合使用。要获得正确的递归只读挂载，你必须设置这两个字段。

特性可用性

要启用 recursiveReadOnly 挂载，必须使用以下组件：

Kubernetes：v1.30 或更新版本，并启用 RecursiveReadOnlyMounts 特性门控。从 v1.30 开始，此特性被标记为 Alpha。
CRI 运行时：
- containerd：v2.0 或更新版本
OCI 运行时：
- runc：v1.1 或更新版本
- crun: v1.8.6 或更新版本
Linux 内核: v5.12 或更新版本

接下来

Kubernetes SIG Node 希望并期望该特性将在 Kubernetes 的未来版本中升级为 Beta 版本并最终稳定可用（GA），以便用户不再需要手动启用此特性门控。

为了向后兼容，recursive ReadOnly 的默认值仍将保持 Disabled。

怎样才能了解更多？

请查看文档以获取 recursiveReadOnly 挂载的更多详细信息。

如何参与？

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

Kubernetes 1.30：对 Pod 使用用户命名空间的支持进阶至 Beta

Mon, 22 Apr 2024 00:00:00 +0000

Linux 提供了不同的命名空间来将进程彼此隔离。例如，一个典型的 Kubernetes Pod 运行在一个网络命名空间中可以隔离网络身份，运行在一个 PID 命名空间中可以隔离进程。

Linux 有一个以前一直未被容器化应用所支持的命名空间是用户命名空间。这个命名空间允许我们将容器内使用的用户标识符和组标识符（UID 和 GID）与主机上的标识符隔离开来。

这是一个强大的抽象，允许我们以 “root” 身份运行容器：我们在容器内部有 root 权限，可以在 Pod 内执行所有 root 能做的操作，但我们与主机的交互仅限于非特权用户可以执行的操作。这对于限制容器逃逸的影响非常有用。

容器逃逸是指容器内的进程利用容器运行时或内核中的某些未打补丁的漏洞逃逸到主机上，并可以访问/修改主机或其他容器上的文件。如果我们以用户命名空间运行我们的 Pod，容器对主机其余部分的特权将减少，并且此容器可以访问的容器外的文件也将受到限制。

在 Kubernetes v1.25 中，我们仅为无状态 Pod 引入了对用户命名空间的支持。 Kubernetes 1.28 取消了这一限制，目前在 Kubernetes 1.30 中，这个特性进阶到了 Beta！

什么是用户命名空间？

注意：Linux 用户命名空间与 Kubernetes 命名空间是不同的概念。前者是一个 Linux 内核特性；后者是一个 Kubernetes 特性。

用户命名空间是一个 Linux 特性，它将容器的 UID 和 GID 与主机上的隔离开来。容器中的标识符可以被映射为主机上的标识符，并且保证不同容器所使用的主机 UID/GID 不会重叠。此外，这些标识符可以被映射到主机上没有特权的、非重叠的 UID 和 GID。这带来了两个关键好处：

防止横向移动：由于不同容器的 UID 和 GID 被映射到主机上的不同 UID 和 GID，即使这些标识符逃出了容器的边界，容器之间也很难互相攻击。例如，假设容器 A 在主机上使用的 UID 和 GID 与容器 B 不同。在这种情况下，它对容器 B 的文件和进程的操作是有限的：只能读取/写入某文件所允许的操作，因为它永远不会拥有文件所有者或组权限（主机上的 UID/GID 保证对不同容器是不同的）。

增加主机隔离：由于 UID 和 GID 被映射到主机上的非特权用户，如果某容器逃出了它的边界，即使它在容器内部以 root 身份运行，它在主机上也没有特权。这大大保护了它可以读取/写入的主机文件，它可以向哪个进程发送信号等。此外，所授予的权能仅在用户命名空间内有效，而在主机上无效，这就限制了容器逃逸的影响。

用户命名空间 ID 分配

如果不使用用户命名空间，容器逃逸时以 root 运行的容器在节点上将具有 root 特权。如果某些权能授权给了此容器，这些权能在主机上也会有效。如果使用用户命名空间，就不会是这种情况（当然，除非有漏洞 🙂）。

1.30 的变化

在 Kubernetes 1.30 中，除了将用户命名空间进阶至 Beta，参与此特性的贡献者们还：

为 kubelet 引入了一种使用自定义范围进行 UID/GID 映射的方式
为 Kubernetes 添加了一种强制执行的方式让运行时支持用户命名空间所需的所有特性。如果不支持这些特性，Kubernetes 在尝试创建具有用户命名空间的 Pod 时，会显示一个明确的错误。在 1.30 之前，如果容器运行时不支持用户命名空间，Pod 可能会在没有用户命名空间的情况下被创建。
新增了更多的测试，包括在 cri-tools 仓库中的测试。

你可以查阅有关用户命名空间的文档，了解如何配置映射的自定义范围。

演示

几个月前，CVE-2024-21626 被披露。这个 漏洞评分为 8.6（高）。它允许攻击者让容器逃逸，并读取/写入节点上的任何路径以及同一节点上托管的其他 Pod。

Rodrigo 创建了一个滥用 CVE 2024-21626 的演示，演示了此漏洞在没有用户命名空间时的工作方式，而在使用用户命名空间后 得到了缓解。

请注意，使用用户命名空间时，攻击者可以在主机文件系统上执行“其他”权限位所允许的操作。因此，此 CVE 并没有完全被修复，但影响大大降低。

节点系统要求

使用此特性对 Linux 内核版本和容器运行时有一些要求。

在 Linux 上，你需要 Linux 6.3 或更高版本。这是因为此特性依赖于一个名为 idmap 挂载的内核特性，而支持 idmap 挂载与 tmpfs 一起使用的特性是在 Linux 6.3 中合并的。

假设你使用 CRI-O 和 crun；就像往常一样，你可以期待 CRI-O 1.30 支持 Kubernetes 1.30。请注意，你还需要 crun 1.9 或更高版本。如果你使用的是 CRI-O 和 runc，则仍然不支持用户命名空间。

containerd 对此特性的支持目前锁定为 containerd 2.0，同样 crun 也有适用的版本要求。如果你使用的是 containerd 和 runc，则仍然不支持用户命名空间。

请注意，正如在 Kubernetes 1.25 和 1.26 中实现的那样，containerd 1.7 增加了对用户命名空间的实验性支持。我们曾在 Kubernetes 1.27 中进行了重新设计，所以容器运行时需要做一些变更。而 containerd 1.7 并未包含这些变更，所以它仅在 Kubernetes 1.25 和 1.26 中支持使用用户命名空间。

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

containerd 1.7 的这些限制均不适用于 CRI-O。

如何参与？

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

你也可以通过以下方式直接联系我们：

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

SIG Architecture 特别报道：代码组织

Thu, 11 Apr 2024 00:00:00 +0000

作者: Frederico Muñoz (SAS Institute)

译者: Xin Li (DaoCloud)

这是 SIG Architecture Spotlight 系列的第三次采访，该系列将涵盖不同的子项目。我们将介绍 SIG Architecture：代码组织。

在本次 SIG Architecture 聚焦中，我与代码组织子项目的成员 Madhav Jivrajani（VMware）进行了交谈。

介绍代码组织子项目

Frederico (FSM)：你好，Madhav，感谢你百忙之中接受我们的采访。你能否首先向我们介绍一下你自己、你的角色以及你是如何参与 Kubernetes 的？

Madhav Jivrajani (MJ)：你好！我叫 Madhav Jivrajani，担任 SIG 贡献者体验的技术主管和 Kubernetes 项目的 GitHub 管理员。除此之外，我还为 SIG API Machinery 和 SIG Etcd 做出贡献，但最近，我一直在帮助完成 Kubernetes 保留受支持的 Go 版本所需的工作，正是通过这一点，参与到了 SIG Architecture 的代码组织子项目中。

FSM：像 Kubernetes 这样规模的项目在代码组织方面肯定会遇到独特的挑战 -- 这是一个合理的假设吗？如果是这样，你认为 Kubernetes 特有的一些主要挑战是什么？

MJ：这是一个合理的假设！第一个有趣的挑战来自 Kubernetes 代码库的庞大规模。我们有大约 220 万行 Go 代码（由于 dims 和这个子项目中的其他人的努力，该代码正在稳步减少！），而且我们的依赖项（无论是直接还是间接）超过 240 个，这就是为什么拥有一个致力于帮助进行依赖项管理的子项目至关重要：我们需要知道我们正在引入哪些依赖项，这些依赖项处于什么版本，以及帮助确保我们能够以一致的方式管理代码库不同部分的依赖关系的工具。以一致的方式管理代码库不同部分的这些依赖关系。

Kubernetes 的另一个有趣的挑战是，我们在 Kubernetes 发布周期中发布了许多 Go 模块，其中一个例子是 client-go。然而，作为一个项目，我们也希望将所有内容都放在一个仓库中，便获得使用单一仓库的优势，例如原子性的提交…… 因此，代码组织与其他 SIG（例如 SIG Release）合作，以实现将代码从单一仓库发布到下游仓库的自动化过程，下游仓库更容易使用，因为你就不必导入整个 Kubernetes 代码库！

代码组织和 Kubernetes

FSM：对于刚刚开始为 Kubernetes 代码做出贡献的人来说，在代码组织方面他们应该考虑的主要事项是什么？你认为有哪些关键概念？

MJ：我认为至少在开始时要记住的关键事情之一是 staging 目录的概念。在 kubernetes/kubernetes 中，你会遇到一个名为 staging/ 的目录。该目录中的子文件夹充当一堆伪仓库。例如，发布 client-go 版本的 kubernetes/client-go 仓库实际上是一个 staging 仓库。

FSM：那么 staging 目录的概念会从根本上影响贡献？

MJ：准确地说，因为如果你想为任何 staging 仓库做出贡献，你需要将 PR 发送到 kubernetes/kubernetes 中相应的 staging 目录。一旦代码合并到那里，我们就会让一个名为 publishing-bot 的机器人将合并的提交同步到必要的 staging 仓库（例如 kubernetes/client-go）中。通过这种方式，我们可以获得单一仓库的好处，但我们也可以以模块化的形式发布代码以供下游使用。 PS：publishing-bot 需要更多人的帮助！

FSM：说到贡献，贡献者数量非常多，包括个人和公司，也一定是一个挑战：这个子项目是如何运作的以确保大家都遵循标准呢？

MJ：当涉及到项目中的依赖关系管理时，有一个专门团队帮助审查和批准依赖关系更改。这些人为目前 Kubernetes 用于管理依赖的许多工具做了开拓性的工作。这些工具帮助我们确保贡献者可以以一致的方式更改依赖项。这个子项目还开发了其他工具来基于被添加或删除的依赖项的统计信息发出通知： depstat

除了依赖管理之外，这个项目执行的另一项重要任务是管理 staging 仓库。用于实现此目的的工具（publishing-bot）对贡献者完全透明，有助于确保就提交给 kubernetes/kubernetes 的贡献而言，各个 staging 仓库获得的视图是一致的。

代码组织还致力于确保 Kubernetes 一直在使用受支持的 Go 版本。链接所指向的 KEP 中包含更详细的背景信息，用来说明为什么我们需要这样做。我们与 SIG Release 合作，确保我们在 Go 版本上尽可能严格、尽早地测试 Kubernetes；作为这些工作的一部分，我们要处理会破坏我们的 CI 的那些变更。我们如何跟踪此过程的示例可以在此处找到。

发布周期和当前优先级

FSM：在发布周期中有什么变化吗？

MJ：在发布周期内，特别是在代码冻结之前，通常会发生添加、更新、删除依赖项的变更，以及修复需要修复的代码等更改，这些都是我们继续使用受支持的 Go 版本的努力的一部分。

此外，其中一些更改也可以向后移植到我们支持的发布分支。

FSM：就子项目中目前正在进行的主要项目或主题而言你有什么要特别强调的吗？

MJ：我认为最近添加的一个非常有趣且非常有用的变更（我借这个机会特别强调 Tim Hockin 在这方面的工作）是引入 Go 工作空间的概念到Kubernetes 仓库中。我们当前的许多依赖管理和代码发布工具，以及在 Kubernetes 仓库中编辑代码的体验，都可以通过此更改得到显着改善。

收尾

FSM：对这个主题感兴趣的人要怎样开始帮助这个子项目？

MJ：与 Kubernetes 中任何项目的第一步一样，第一步是加入我们的 Slack：slack.k8s.io，然后加入 #k8s-code-organization 频道，你还可以选择参加代码组织办公时间。时区是个困难点，所以请随时查看录音或会议记录并跟进 Slack！

FSM：非常好，谢谢！最后你还有什么想分享的吗？

MJ：代码组织子项目总是需要帮助！特别是像发布机器人这样的领域，所以请不要犹豫，参与到 #k8s-code-organization Slack 频道中。

Kubernetes v1.30 初探

Tue, 12 Mar 2024 00:00:00 +0000

作者: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko

译者: Paco Xu (DaoCloud)

快速预览：Kubernetes v1.30 中令人兴奋的变化

新年新版本，v1.30 发布周期已过半，我们将迎来一系列有趣且令人兴奋的增强功能。从全新的 alpha 特性，到已有的特性升级为稳定版，再到期待已久的改进，这个版本对每个人都有值得关注的内容！

为了让你在正式发布之前对其有所了解，下面给出我们在这个周期中最为期待的增强功能的预览！

Kubernetes v1.30 的主要变化

动态资源分配（DRA）的结构化参数 (KEP-4381)

动态资源分配（DRA）在 Kubernetes v1.26 中作为 alpha 特性添加。它定义了一种替代传统设备插件 device plugin API 的方式，用于请求访问第三方资源。在设计上，动态资源分配（DRA）使用的资源参数对于核心 Kubernetes 完全不透明。这种方法对于集群自动缩放器（CA）或任何需要为一组 Pod 做决策的高级控制器（例如作业调度器）都会带来问题。这一设计无法模拟在不同时间分配或释放请求的效果。只有第三方 DRA 驱动程序才拥有信息来做到这一点。

动态资源分配（DRA）的结构化参数是对原始实现的扩展，它通过构建一个框架来支持增加请求参数的透明度来解决这个问题。驱动程序不再需要自己处理所有请求参数的语义，而是可以使用 Kubernetes 预定义的特定“结构化模型”来管理和描述资源。这一设计允许了解这个“结构化规范”的组件做出关于这些资源的决策，而不再将它们外包给某些第三方控制器。例如，调度器可以在不与动态资源分配（DRA）驱动程序反复通信的前提下快速完成分配请求。这个版本的工作重点是定义一个框架来支持不同的“结构化模型”，并实现“命名资源”模型。此模型允许列出各个资源实例，同时，与传统的设备插件 API 相比，模型增加了通过属性逐一选择实例的能力。

节点交换内存 SWAP 支持 (KEP-2400)

在 Kubernetes v1.30 中，Linux 节点上的交换内存支持机制有了重大改进，其重点是提高系统的稳定性。以前的 Kubernetes 版本默认情况下禁用了 NodeSwap 特性门控。当门控被启用时，UnlimitedSwap 行为被作为默认行为。为了提高稳定性，UnlimitedSwap 行为（可能会影响节点的稳定性）将在 v1.30 中被移除。

更新后的 Linux 节点上的交换内存支持仍然是 beta 级别，并且默认情况下开启。然而，节点默认行为是使用 NoSwap（而不是 UnlimitedSwap）模式。在 NoSwap 模式下，kubelet 支持在启用了磁盘交换空间的节点上运行，但 Pod 不会使用页面文件（pagefile）。你仍然需要为 kubelet 设置 --fail-swap-on=false 才能让 kubelet 在该节点上运行。特性的另一个重大变化是针对另一种模式：LimitedSwap。在 LimitedSwap 模式下，kubelet 会实际使用节点上的页面文件，并允许 Pod 的一些虚拟内存被换页出去。容器（及其父 Pod）访问交换内存空间不可超出其内存限制，但系统的确可以使用可用的交换空间。

Kubernetes 的 SIG Node 小组还将根据最终用户、贡献者和更广泛的 Kubernetes 社区的反馈更新文档，以帮助你了解如何使用经过修订的实现。

阅读之前的博客文章或交换内存管理文档以获取有关 Kubernetes 中 Linux 节点交换支持的更多详细信息。

支持 Pod 运行在用户命名空间 (KEP-127)

用户命名空间是一个仅在 Linux 上可用的特性，它更好地隔离 Pod，以防止或减轻几个高/严重级别的 CVE，包括 2024 年 1 月发布的 CVE-2024-21626。在 Kubernetes 1.30 中，对用户命名空间的支持正在迁移到 beta，并且现在支持带有和不带有卷的 Pod，自定义 UID/GID 范围等等！

结构化鉴权配置(KEP-3221)

对结构化鉴权配置的支持正在晋级到 Beta 版本，并将默认启用。这个特性支持创建具有明确参数定义的多个 Webhook 所构成的鉴权链；这些 Webhook 按特定顺序验证请求，并允许进行细粒度的控制，例如在失败时明确拒绝。配置文件方法甚至允许你指定 CEL 规则，以在将请求分派到 Webhook 之前对其进行预过滤，帮助你防止不必要的调用。当配置文件被修改时，API 服务器还会自动重新加载鉴权链。

你必须使用 --authorization-config 命令行参数指定鉴权配置的路径。如果你想继续使用命令行标志而不是配置文件，命令行方式没有变化。要访问新的 Webhook 功能，例如多 Webhook 支持、失败策略和预过滤规则，需要切换到将选项放在 --authorization-config 文件中。从 Kubernetes 1.30 开始，配置文件格式约定是 beta 级别的，只需要指定 --authorization-config，因为特性门控默认启用。鉴权文档中提供了一个包含所有可能值的示例配置。有关更多详细信息，请阅读鉴权文档。

基于容器资源指标的 Pod 自动扩缩容 (KEP-1610)

基于 ContainerResource 指标的 Pod 水平自动扩缩容将在 v1.30 中升级为稳定版。 HorizontalPodAutoscaler 的这一新行为允许你根据各个容器的资源使用情况而不是 Pod 的聚合资源使用情况来配置自动伸缩。有关更多详细信息，请参阅我们的先前文章，或阅读容器资源指标。

在准入控制中使用 CEL (KEP-3488)

Kubernetes 为准入控制集成了 Common Expression Language (CEL) 。这一集成引入了一种更动态、表达能力更强的方式来判定准入请求。这个特性允许通过 Kubernetes API 直接定义和执行复杂的、细粒度的策略，同时增强了安全性和治理能力，而不会影响性能或灵活性。

将 CEL 引入到 Kubernetes 的准入控制后，集群管理员就具有了制定复杂规则的能力，这些规则可以根据集群的期望状态和策略来评估 API 请求的内容，而无需使用基于 Webhook 的访问控制器。这种控制水平对于维护集群操作的完整性、安全性和效率至关重要，使 Kubernetes 环境更加健壮，更适应各种用例和需求。有关使用 CEL 进行准入控制的更多信息，请参阅 API 文档中的 ValidatingAdmissionPolicy。

我们希望你和我们一样对这个版本的发布感到兴奋。请在未来几周内密切关注官方发布博客，以了解其他亮点！

走进 Kubernetes 读书会（Book Club）

Thu, 22 Feb 2024 00:00:00 +0000

学习 Kubernetes 及其整个生态的技术并非易事。在本次采访中，我们的访谈对象是 Carlos Santana (AWS)，了解他是如何创办 Kubernetes 读书会（Book Club）的，整个读书会是如何运作的，以及大家如何加入其中，进而更好地利用社区学习体验。

Frederico Muñoz (FSM)：你好 Carlos，非常感谢你能接受我们的采访。首先，你能介绍一下自己吗？

Carlos Santana (CS)：当然可以。六年前，我在生产环境中部署 Kubernetes 的经验为我加入 Knative 并通过 Release Team 为 Kubernetes 贡献代码打开了大门。为上游 Kubernetes 工作是我在开源领域最好的经历之一。在过去的两年里，作为 AWS 的高级专业解决方案架构师，我一直在帮助大型企业在 Kubernetes 之上构建他们的内部开发平台（IDP）。未来我的开源贡献将主要集中在 CNOE 和 CNCF 项目，如 Argo、Crossplane 和 Backstage。

创办读书会

FSM：所以你的职业道路把你引向了 Kubernetes，那么是什么动机促使你开始创办读书会呢？

CS：Kubernetes 读书会的想法源于一次 TGIK 直播中的一个临时建议。对我来说，这不仅仅是读一本书，更是创办一个学习社区。这个社区平台不仅是知识的来源，也是一个支持系统，特别是在疫情期间陪我度过了艰难时刻。读书会的这项倡议后来帮助许多成员学会了应对和成长，这让我感到很欣慰。我们在 2021 年 3 月 5 日开始第一本书 Production Kubernetes，花了 36 周时间。目前，一本书不会再花那么长时间了，如今每周会完成一到两章。

FSM：你能介绍一下 Kubernetes 读书会是如何运作的吗？你们如何选书以及如何阅读它们？

CS：我们根据小组的兴趣和需求以集体的方式选书。这种实用的方法有助于成员们（特别是初学者）更容易地掌握复杂的概念。我们每周有两次读书会应对不同的时区，一个针对 EMEA（欧洲、中东及非洲）时区，另一个是由我自己负责的美国时区。每位组织者与他们的联合主持人在 Slack 上甄选一本书，然后安排几个主持人用几周时间讨论每一章。

FSM：如果我没记错的话，Kubernetes 读书会如今已经进行到了第 17 本书。这很了不起：有什么秘诀可以让读书这件事保持活跃吗？

CS：保持俱乐部活跃和吸引人参与的秘诀在于几个关键因素。

首先，一贯性至关重要。我们努力保持定期聚会，只有在重大事件如节假日或 KubeCon 时才会取消聚会。这种规律性有助于成员保持惯性参与，有助于建立一个可靠的社区。

其次，让聚会有趣生动也非常重要。例如，我经常在聚会期间引入提问测验，不仅检测成员们的理解程度，还增加了一些乐趣。这种方法使读书内容更加贴近实际，并帮助成员们理解理论概念在现实世界中的运用方式。

读书会涵盖的话题

FSM：书籍的主要话题包括 Kubernetes、GitOps、安全、SRE 和可观测性：这是否也反映了云原生领域的现状，特别是在受欢迎程度方面？

CS：我们的旅程始于《Production Kubernetes》，为我们专注于实用、生产就绪的解决方案定下了基调。从那时起，我们深入探讨了 CNCF 领域的各个方面，根据不同的主题去选书。每个主题，无论是安全性、可观测性还是服务网格，都是根据其相关性和社区需求来选择的。例如，在我们最近关于 Kubernetes 考试认证的主题中，我们邀请了书籍的作者作为活跃现场的主持人，用他们的专业知识丰富了我们的讨论。

FSM：我了解到此项目最近有一些变化，即被整合到了 CNCF 作为云原生社区组（Cloud Native Community Group）的一部分。你能谈谈这个变化吗？

CS：CNCF 慷慨地接受了读书会作为云原生社区组的一部分。这是读书会发展过程中的重要一步，优化了读书会的运作并扩大了读书会的影响力。这种拉齐对于增强读书会的管理能力至关重要，这点很像 Kubernetes Community Days (KCD) 聚会。现在，读书会有了更稳健的会员结构、活动安排、邮件列表、托管的网络会议和录播系统。

FSM：在过去的六个月里，你参与 CNCF 这件事对 Kubernetes 读书会的成长和参与度产生了什么影响？

CS：自从六个月前成为 CNCF 社区的一部分以来，我们在 Kubernetes 读书会中看到了一些显著的变化。我们的会员人数激增至 600 多人，并在此期间成功组织并举办了超过 40 场活动。更令人鼓舞的是，每场活动的出席人数都很稳定，平均约有 30 人参加。这种增长和参与度清楚地表明了我们与 CNCF 的合作让 Kubernetes 读书会在社区中增强了影响力。

加入读书会

FSM：若有人想加入读书会，他们应该怎么做？

CS：加入读书会只需三步：

首先加入 Kubernetes 读书会社区
然后注册参与在社区页面上列出的活动
最后加入 CNCF Slack 频道 #kubernetes-book-club。

FSM：太好了，谢谢你！最后你还有什么想法要跟大家分享吗？

CS：Kubernetes 读书会不仅仅是一个讨论书籍的专业小组，它是一个充满活力的社区，有许多令人敬佩的志愿者帮助组织和主持聚会。我想借这次机会感谢几位志愿者： Neependra Khare、 Eric Smalling、 Sevi Karakulak、 Chad M. Crowell 和 Walid (CNJ) Shaari。欢迎来 KubeCon 与我们相聚，还能领取你的 Kubernetes 读书会贴纸！

镜像文件系统：配置 Kubernetes 将容器存储在独立的文件系统上

Tue, 23 Jan 2024 00:00:00 +0000

作者: Kevin Hannon (Red Hat)

译者: Michael Yao

磁盘空间不足是运行或操作 Kubernetes 集群时的一个常见问题。在制备节点时，你应该为容器镜像和正在运行的容器留足够的存储空间。容器运行时通常会向 /var 目录写入数据。此目录可以位于单独的分区或根文件系统上。CRI-O 默认将其容器和镜像写入 /var/lib/containers，而 containerd 将其容器和镜像写入 /var/lib/containerd。

在这篇博文中，我们想要关注的是几种不同方式，用来配置容器运行时将其内容存储到别的位置而非默认分区。这些配置允许我们更灵活地配置 Kubernetes，支持在保持默认文件系统不受影响的情况下为容器存储添加更大的磁盘。

需要额外讲述的是 Kubernetes 向磁盘在写入数据的具体位置及内容。

了解 Kubernetes 磁盘使用情况

Kubernetes 有持久数据和临时数据。kubelet 和特定于 Kubernetes 的本地存储的基础路径是可配置的，但通常假定为 /var/lib/kubelet。在 Kubernetes 文档中，这一位置有时被称为根文件系统或节点文件系统。写入的数据可以大致分类为：

临时存储
日志
容器运行时

与大多数 POSIX 系统不同，这里的根/节点文件系统不是 /，而是 /var/lib/kubelet 所在的磁盘。

临时存储

Pod 和容器的某些操作可能需要临时或瞬态的本地存储。临时存储的生命周期短于 Pod 的生命周期，且临时存储不能被多个 Pod 共享。

日志

默认情况下，Kubernetes 将每个运行容器的日志存储为 /var/log 中的文件。这些日志是临时性质的，并由 kubelet 负责监控以确保不会在 Pod 运行时变得过大。

你可以为每个节点自定义日志轮换设置，以管控这些日志的大小，并（使用第三方解决方案）配置日志转储以避免对节点本地存储形成依赖。

容器运行时

容器运行时针对容器和镜像使用两个不同的存储区域。

只读层：镜像通常被表示为只读层，因为镜像在容器处于运行状态期间不会被修改。只读层可以由多个层组成，这些层组合到一起形成最终的只读层。如果容器要向文件系统中写入数据，则在容器层之上会存在一个薄层为容器提供临时存储。

可写层：取决于容器运行时的不同实现，本地写入可能会用分层写入机制来实现（例如 Linux 上的 overlayfs 或 Windows 上的 CimFS）。这一机制被称为可写层。本地写入也可以使用一个可写文件系统来实现，该文件系统使用容器镜像的完整克隆来初始化；这种方式适用于某些基于 Hypervisor 虚拟化的运行时。

容器运行时文件系统包含只读层和可写层。在 Kubernetes 文档中，这一文件系统被称为 imagefs。

容器运行时配置

CRI-O

CRI-O 使用 TOML 格式的存储配置文件，让你控制容器运行时如何存储持久数据和临时数据。 CRI-O 使用了 containers-storage 库。某些 Linux 发行版为 containers-storage 提供了帮助手册条目（man 5 containers-storage.conf）。存储的主要配置位于 /etc/containers/storage.conf 中，你可以控制临时数据和根目录的位置。根目录是 CRI-O 存储持久数据的位置。

[storage]
# 默认存储驱动
driver = "overlay"
# 临时存储位置
runroot = "/var/run/containers/storage"
# 容器存储的主要读/写位置
graphroot = "/var/lib/containers/storage"

graphroot
- 存储来自容器运行时的持久数据
- 如果 SELinux 被启用，则此项必须是 /var/lib/containers/storage
runroot
- 容器的临时读/写访问
- 建议将其放在某个临时文件系统上

以下是为你的 graphroot 目录快速重新打标签以匹配 /var/lib/containers/storage 的方法：

semanage fcontext -a -e /var/lib/containers/storage <你的存储路径>
restorecon -R -v <你的存储路径>

containerd

containerd 运行时使用 TOML 配置文件来控制存储持久数据和临时数据的位置。配置文件的默认路径位于 /etc/containerd/config.toml。

与 containerd 存储的相关字段是 root 和 state。

root
- containerd 元数据的根目录
- 默认为 /var/lib/containerd
- 如果你的操作系统要求，需要为根目录设置 SELinux 标签
state
- containerd 的临时数据
- 默认为 /run/containerd

Kubernetes 节点压力驱逐

Kubernetes 将自动检测容器文件系统是否与节点文件系统分离。当你分离文件系统时，Kubernetes 负责同时监视节点文件系统和容器运行时文件系统。 Kubernetes 文档将节点文件系统称为 nodefs，将容器运行时文件系统称为 imagefs。如果 nodefs 或 imagefs 中有一个磁盘空间不足，则整个节点被视为有磁盘压力。这种情况下，Kubernetes 先通过删除未使用的容器和镜像来回收空间，之后会尝试驱逐 Pod。在同时具有 nodefs 和 imagefs 的节点上，kubelet 将在 imagefs 上对未使用的容器镜像执行垃圾回收，并从 nodefs 中移除死掉的 Pod 及其容器。如果只有 nodefs，则 Kubernetes 垃圾回收将包括死掉的容器、死掉的 Pod 和未使用的镜像。

Kubernetes 提供额外的配置方法来确定磁盘是否已满。kubelet 中的驱逐管理器有一些让你可以控制相关阈值的配置项。对于文件系统，相关测量值有 nodefs.available、nodefs.inodesfree、imagefs.available 和 imagefs.inodesfree。如果容器运行时没有专用磁盘，则 imagefs 被忽略。

用户可以使用现有的默认值：

memory.available < 100MiB
nodefs.available < 10%
imagefs.available < 15%
nodefs.inodesFree < 5%（Linux 节点）

Kubernetes 允许你在 kubelet 配置文件中将 EvictionHard 和 EvictionSoft 设置为用户定义的值。

EvictionHard: 定义限制；一旦超出这些限制，Pod 将被立即驱逐，没有任何宽限期。
EvictionSoft: 定义限制；一旦超出这些限制，Pod 将在按各信号所设置的宽限期后被驱逐。

如果你为 EvictionHard 指定了值，所设置的值将取代默认值。这意味着在你的配置中设置所有信号非常重要。

例如，以下 kubelet 配置可用于配置驱逐信号和宽限期选项。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"
evictionSoft:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"
evictionSoftGracePeriod:
    memory.available:  "1m30s"
    nodefs.available:  "2m"
    nodefs.inodesFree: "2m"
    imagefs.available: "2m"
    imagefs.inodesFree: "2m"
evictionMaxPodGracePeriod: 60s

问题

Kubernetes 项目建议你针对 Pod 驱逐要么使用其默认设置，要么设置与之相关的所有字段。你可以使用默认设置或指定你自己的 evictionHard 设置。如果你漏掉一个信号，那么 Kubernetes 将不会监视该资源。管理员或用户可能会遇到的一个常见误配是将新的文件系统挂载到 /var/lib/containers/storage 或 /var/lib/containerd。 Kubernetes 将检测到一个单独的文件系统，因此你要确保 imagefs.inodesfree 和 imagefs.available 符合你的需要。

另一个令人困惑的地方是，如果你为节点定义了镜像文件系统，则临时存储报告不会发生变化。镜像文件系统（imagefs）用于存储容器镜像层；如果容器向自己的根文件系统写入，那么这种本地写入不会计入容器镜像的大小。容器运行时存储这些本地修改的位置是由运行时定义的，但通常是镜像文件系统。如果 Pod 中的容器正在向基于文件系统的 emptyDir 卷写入，所写入的数据将使用 nodefs 文件系统的空间。 kubelet 始终根据 nodefs 所表示的文件系统来报告临时存储容量和分配情况；当临时写入操作实际上是写到镜像文件系统时，这种差别可能会让人困惑。

后续工作

为了解决临时存储报告相关的限制并为容器运行时提供更多配置选项，SIG Node 正在处理 KEP-4191。在 KEP-4191 中， Kubernetes 将检测可写层是否与只读层（镜像）分离。这种检测使我们可以将包括可写层在内的所有临时存储放在同一磁盘上，同时也可以为镜像使用单独的磁盘。

参与其中

如果你想参与其中，可以加入 Kubernetes Node 特别兴趣小组（SIG）。

如果你想分享反馈，可以分享到我们的 #sig-node Slack 频道。如果你还没有加入该 Slack 工作区，可以访问 https://slack.k8s.io/ 获取邀请。

特别感谢所有提供出色评审、分享宝贵见解或建议主题想法的贡献者。

Peter Hunt
Mrunal Patel
Ryan Phillips
Gaurav Singh

Kubernetes 1.29 中的上下文日志生成：更好的故障排除和增强的日志记录

Wed, 20 Dec 2023 09:30:00 -0800

作者：Mengjiao Liu (DaoCloud), Patrick Ohly (Intel)

译者：Mengjiao Liu (DaoCloud)

代表结构化日志工作组和 SIG Instrumentation，我们很高兴地宣布在 Kubernetes v1.24 中引入的上下文日志记录功能现已成功迁移了两个组件（kube-scheduler 和 kube-controller-manager）以及一些目录。该功能旨在为 Kubernetes 提供更多有用的日志以更好地进行故障排除，并帮助开发人员增强 Kubernetes。

上下文日志记录是什么？

上下文日志记录基于 go-logr API。关键思想是调用者将一个日志生成器实例传递给库，并使用它进行日志记录而不是访问全局日志生成器。二进制文件而不是库负责选择日志记录的实现。go-logr API 围绕结构化日志记录而设计，并支持向日志生成器提供额外信息。

这一设计可以支持某些额外的使用场景：

调用者可以为日志生成器提供额外的信息：
- WithName 添加一个 “logger” 键，并用句点（.）将名称的各个部分串接起来作为取值
- WithValues 添加键/值对
当将此经过扩展的日志生成器传递到函数中，并且该函数使用它而不是全局日志生成器时，所有日志条目中都会包含所给的额外信息，而无需修改生成日志条目的代码。这一特点在高度并行的应用中非常有用。在这类应用中，很难辨识某操作的所有日志条目，因为不同操作的输出是交错的。
运行单元测试时，日志输出可以与当前测试相关联。且当测试失败时，go test 仅显示失败测试的日志输出。默认情况下，该输出也可能更详细，因为它不会在成功的测试中显示。测试可以并行运行，而无需交错输出。

上下文日志记录的设计决策之一是允许将日志生成器作为值附加到 context.Context 之上。由于日志生成器封装了调用所预期的、与日志记录相关的所有元素，因此它是 context 的一部分，而不仅仅是使用它。这一设计的一个比较实际的优点是，许多 API 已经有一个 ctx 参数，或者可以添加一个 ctx 参数。进而产生的额外好处还包括比如可以去掉函数内的 context.TODO() 调用。

如何使用它

从 Kubernetes v1.24 开始，上下文日志记录功能处于 Alpha 状态，因此它需要启用 ContextualLogging 特性门控。如果你想在该功能处于 Alpha 状态时对其进行测试，则需要在 kube-controller-manager 和 kube-scheduler 上启用此特性门控。

对于 kube-scheduler，有一点需要注意，除了启用 ContextualLogging 特性门控之外，插桩行为还取决于日志的详细程度设置。为了避免因 1.29 添加的上下文日志记录工具而降低调度程序的速度，请务必仔细选择何时添加额外的信息：

在 -v3 或更低日志级别中，每个调度周期仅使用一次 WithValues("pod")。这样做可以达到预期效果，即该周期的所有日志消息都包含 Pod 信息。一旦上下文日志记录特性到达 GA 阶段，就可以从所有日志调用中删除 “pod” 键值对。
在 -v4 或更高日志级别中，会生成更丰富的日志条目，其中 WithValues 也用于节点（如果适用），WithName 用于当前操作和插件。

下面的示例展示了这一效果：

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

这一设计的直接好处是在 logger 中可以看到操作和插件名称。pod 和 node 已作为参数记录在 kube-scheduler 代码中的各个日志调用中。一旦 kube-scheduler 之外的其他包也支持上下文日志记录，在这些包（例如，client-go）中也可以看到操作和插件名称。一旦上下文日志记录特性到达 GA 阶段，就可以简化日志调用以避免重复这些值。

在 kube-controller-manager 中，WithName 被用来在日志中输出用户可见的控制器名称，例如：

I1113 08:43:29.284360 87141 graph_builder.go:285] "garbage controller monitor not synced: no monitors" logger="garbage-collector-controller"

logger=”garbage-collector-controller” 是由 kube-controller-manager 核心代码在实例化该控制器时添加的，会出现在其所有日志条目中——只要它所调用的代码支持上下文日志记录。转换像 client-go 这样的共享包还需要额外的工作。

性能影响

在包中支持上下文日志记录，即接受来自调用者的记录器，成本很低。没有观察到 kube-scheduler 的性能影响。如上所述，添加 WithName 和 WithValues 需要更加小心。

在 Kubernetes 1.29 中，以生产环境日志详细程度（-v3 或更低）启用上下文日志不会导致 kube-scheduler 速度出现明显的减慢，并且 kube-controller-manager 速度也不会出现明显的减慢。在 debug 级别，考虑到生成的日志使调试更容易，某些测试用例减速 28% 仍然是合理的。详细信息请参阅有关将该特性升级为 Beta 版的讨论。

对下游用户的影响

日志输出不是 Kubernetes API 的一部分，并且经常在每个版本中都会出现更改，无论是因为开发人员修改代码还是因为不断转换为结构化和上下文日志记录。

如果下游用户对特定日志有依赖性，他们需要了解此更改如何影响他们。

进一步阅读

参阅 Kubernetes 1.24 中的上下文日志记录。
参阅 KEP-3077：上下文日志记录。

如何参与

如果你有兴趣参与，我们始终欢迎新的贡献者加入我们。上下文日志记录为你参与 Kubernetes 开发做出贡献并产生有意义的影响提供了绝佳的机会。通过加入 Structured Logging WG，你可以积极参与 Kubernetes 的开发并做出你的第一个贡献。这是学习和参与社区并获得宝贵经验的好方法。

我们鼓励你探索存储库并熟悉正在进行的讨论和项目。这是一个协作环境，你可以在这里交流想法、提出问题并与其他贡献者一起工作。

如果你有任何疑问或需要指导，请随时与我们联系，你可以通过我们的公共 Slack 频道联系我们。如果你尚未加入 Slack 工作区，可以访问 https://slack.k8s.io/ 获取邀请。

我们要向所有提供精彩评论、分享宝贵见解并协助实施此功能的贡献者表示感谢（按字母顺序排列）：

Aldo Culquicondor (alculquicondor)
Andy Goldstein (ncdc)
Feruzjon Muyassarov (fmuyassarov)
Freddie (freddie400)
JUN YANG (yangjunmyfm192085)
Kante Yin (kerthcet)
Kiki (carlory)
Lucas Severo Alve (knelasevero)
Maciej Szulik (soltysh)
Mengjiao Liu (mengjiao-liu)
Naman Lakhwani (Namanl2001)
Oksana Baranova (oxxenix)
Patrick Ohly (pohly)
songxiao-wang87 (songxiao-wang87)
Tim Allclai (tallclair)
ZhangYu (Octopusjust)
Ziqi Zhao (fatsheep9146)
Zac (249043822)

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.nz) 进行了对话，他是 Conformance 子项目的负责人。

关于 SIG Architecture 和 Conformance 子项目

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

Riaan Kleinhans (RK)：嗨！我叫 Riaan Kleinhans，我住在南非。我是新西兰 ii.nz 的项目经理。在我加入 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）。

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

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

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

（更新于 2024 年 1 月 12 日）

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

旧版托管在 Google 的包仓库于 2024 年 1 月停用。 这些仓库自 2023 年 8 月 31 日起被弃用 ，并自 2023 年 9 月 13 日被冻结 。
有关此变更的更多细节请查阅弃用公告。

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

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

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

Kubernetes 没有为早期版本提供官方的 Linux 包；然而，你的 Linux 发行版可能会提供自己的包。

每个 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) 或邮件列表直接与我们联系。

Kubernetes Blog

Kubernetes v1.31：kubeadm v1beta4

自 v1beta3 以来的变更列表

如何将 v1beta3 配置迁移到 v1beta4？

示例

我该如何参与？

Kubernetes 1.31：通过 VolumeAttributesClass 修改卷进阶至 Beta

动态修改卷属性

Beta 阶段的限制

向 Client-Go 引入特性门控：增强灵活性和控制力

动机

client-go 中的特性门控

覆盖 client-go 特性门控

自定义 client-go 特性门控

总结

聚焦 SIG API Machinery

介绍

SIG Machinery 的范围

不断演变的协作模式

Kubernetes 受欢迎的挑战

未来发展

加入有趣的我们

Kubernetes v1.31 中的移除和主要变更

Kubernetes API 删除和弃用流程

关于 SHA-1 签名支持的说明

Kubernetes 1.31 中的弃用和删除

弃用节点的 status.nodeInfo.kubeProxyVersion 字段（KEP 4004）

删除所有云驱动的树内集成组件

删除 kubelet --keep-terminated-pod-volumes 命令行标志

删除 CephFS 卷插件

删除 Ceph RBD 卷插件

kube-scheduler 中非 CSI 卷限制插件的弃用

展望未来

想要了解更多？

Kubernetes 的十年

Kubernetes 的起源 - 技术的融合

Kubernetes 十年回顾

Kubernetes 现状

Kubernetes 的未来

完成 Kubernetes 史上最大规模迁移

云控制器管理器

API 服务器网络代理

kubelet 的凭据提供程序插件

存储插件从树内迁移到 CSI

下一步是什么？

Gateway API v1.1：服务网格、GRPCRoute 和更多变化

新内容

进阶至标准渠道

服务网格支持

GRPCRoute

ParentReference 端口

合规性配置文件和报告

实验性渠道的新增内容

Gateway 客户端证书验证

会话持久性和 BackendLBPolicy

其他更新

TLS 术语阐述

Gateway API 背景

试用一下

参与进来

相关的 Kubernetes 博文

Kubernetes 1.30：防止未经授权的卷模式转换进阶到 GA

问题

防止未经授权的用户转换卷模式

需要采取的行动

接下来

Kubernetes 1.30：结构化身份认证配置进阶至 Beta

动机

什么是结构化身份认证配置？

结构化身份认证配置的好处

如何使用结构化身份认证配置

从命令行参数迁移到配置文件

Note

命令行参数

配置文件

下一步是什么？

试用一下

如何参与

Kubernetes 1.30：验证准入策略 ValidatingAdmissionPolicy 正式发布

准入 Webhook 示例

弃用节点的 `status.nodeInfo.kubeProxyVersion` 字段（KEP 4004）

删除 kubelet `--keep-terminated-pod-volumes` 命令行标志