KubeCon-2024-笔记-全-

KubeCon 2024 笔记（全）

002：闭幕致辞

在本节课中，我们将学习KubeCon+云原生峰会2024闭幕致辞的核心内容。我们将了解会议的重要提醒、对贡献者的感谢以及未来的展望。

在恢复分组讨论会之前，我需要提醒大家几件重要的事情。

以下是关于活动安排的重要提醒。

解决方案展示区将于今天下午2:30关闭。
请务必在此之前访问我们的赞助商展位。
别忘了在云原生角商店领取免费的T恤。

上一节我们介绍了会议的重要安排，本节中我们来看看对个人的特别致谢。

我谨向所有人表示衷心的感谢。但首先，我想花点时间感谢我尊敬的联合主席Nikkita。

这是她最后一次担任KubeCon云原生大会的联合主席。我想请大家为她为本次活动做出的宝贵贡献，送上应得的掌声。

感谢大家。非常感谢你们给我这个绝佳的机会。担任这个角色让我度过了非常愉快的时光。我相信在未来的KubeCon+云原生大会上，我们还会再见。现在，我很高兴将接力棒交给新的领导者，而这一次，我将继续在场边为大家加油。

感谢Nikkita的贡献后，我们来看看对合作伙伴的感谢以及对未来的展望。

Nikkita，我真的很享受与你共事的时光，你对社区产生了如此巨大的积极影响。Casper和我都会想念你。我期待与我们下一任联合主席在我们热爱的这些精彩活动中合作。

我知道我们会在Chris之前提到的即将到来的KubeCon活动中再次见到你。

期待在这些活动中再次与大家相见。我们衷心感谢大家参加我们的主题演讲。再次感谢所有让本次活动成为可能的演讲者和赞助商。祝大家会议最后一天愉快，我们期待下一次再会。

谢谢大家。

本节课中我们一起学习了KubeCon+云原生峰会2024闭幕致辞的主要内容。我们回顾了重要的会议提醒，表达了对离任联合主席Nikkita的感谢与祝福，并展望了未来的社区活动。这标志着本次大会正式环节的结束。

003：十年架构与演进 🎮

概述

在本教程中，我们将通过一场趣味问答游戏“Kubernetes家族纷争”的形式，回顾Kubernetes在过去十年中遇到的关键问题、社区观点以及其演进历程。我们将学习到常见的错误、社区认为的风险、工具的正确发音以及Kubernetes的核心优势。

第一轮：Kubernetes中常见的错误 🚨

上一节我们介绍了本教程的游戏形式，本节中我们来看看社区反馈中最常见的Kubernetes错误。

问题：在Kubernetes中，你可能会看到什么错误？

以下是社区票选出的前四个答案：

CrashLoopBackOff
- 含义：Pod中的容器反复启动失败。
- 代码示例：kubectl get pods 查看Pod状态。
ImagePullBackOff
- 含义：无法从镜像仓库拉取容器镜像。
- 代码示例：检查 kubectl describe pod <pod-name> 中的 Events 部分。
OOMKilled (Out Of Memory)
- 含义：容器因使用内存超出限制而被终止。
- 代码示例：在Pod定义中设置资源限制：resources.limits.memory: “256Mi”。
Context Deadline Exceeded
- 含义：操作（如API请求）因超时而失败。

总结：第一轮我们学习了Kubernetes中几种典型的运行时错误，它们通常与容器生命周期、资源管理和网络通信相关。

第二轮：Kubernetes与云原生的最大风险 ⚠️

上一节我们探讨了常见的运行时错误，本节中我们来看看社区认为的更大层面的风险。

问题：什么是Kubernetes和云原生的最大风险？

以下是社区票选出的前五个答案：

缺乏创新 (Lack of Innovation)
复杂性 (Complexity)
云供应商锁定 (Cloud Provider Lock-in)
人工智能 (AI)
维护者不足 (Lack of Maintainers)

总结：第二轮揭示了社区对生态发展的担忧，主要集中在技术演进停滞、系统过于复杂导致上手困难，以及潜在的供应商依赖风险。

第三轮：如何发音“kubectl”？ 🔤

上一节我们讨论了宏观风险，本节我们来点轻松的，看看社区对Kubernetes命令行工具名称的发音有哪些有趣的观点。

问题：如何发音Kubernetes命令行工具的名称？

以下是社区票选出的前四个答案：

Kube-C-T-L (逐个字母念出)
Kube-Cuttle (像“短刀鱼”cuttlefish)
Kube-Control (读作“控制”)
Kube-Cuddle (读作“拥抱”)

总结：第三轮展示了社区文化的趣味一面。虽然官方或常见的发音是 “Kube-C-T-L” 或 “Kube-Cuttle”，但并没有唯一“正确”的答案，这体现了开源社区的多样性。

第四轮：Kubernetes的最佳特性 ✨

上一节我们进行了一次语言小测验，本节我们回归技术，探讨Kubernetes的核心价值。

问题：Kubernetes的最佳特性是什么？

以下是社区票选出的前六个答案：

声明式API与控制器 (Declarative API & Controllers)
- 公式：期望状态 (YAML) -> 控制器 -> 实际状态
自动扩缩容 (Auto-scaling)
- 代码示例：kubectl autoscale deployment <name> --cpu-percent=50 --min=1 --max=10
自定义资源定义 (Custom Resource Definitions, CRDs)
- 含义：允许用户扩展Kubernetes API，定义自己的资源类型。
Pod
- 含义：Kubernetes中最小的可部署单元，是容器化应用的抽象。
社区 (The Community)
控制平面 (Control Plane)

总结：第四轮突出了Kubernetes成功的几大支柱：其以控制器为核心的声明式操作模型、强大的扩展能力、灵活的部署单元以及充满活力的开源社区。

第五轮：已被克服的采用障碍 🏆

上一节我们总结了Kubernetes的核心优势，本节我们回顾历史，看看哪些曾经的障碍已被社区攻克。

问题：说出一个Kubernetes采用过程中已被 largely overcome 的障碍。

以下是社区票选出的前五个答案：

集群生命周期管理 (Cluster Lifecycle Management)
- 工具如 kubeadm, kops, 托管K8s服务 (GKE, EKS, AKS) 已大大简化此过程。
稳定性与可靠性 (Stability & Reliability)
招聘相关人才 (Hiring)
- 随着技术普及，相关人才池扩大。
功能完备性 (Feature Completeness)
文档 (Documentation)

总结：最后一轮我们回顾了Kubernetes的成熟之路。从早期艰难的集群搭建和维护，到如今工具的完善、稳定性的提升、人才的丰富和文档的健全，许多阻碍大规模采用的障碍已经或正在被移除。

最终总结 🎉

在本教程中，我们以一场生动的“家族纷争”游戏形式，一起学习了：

常见错误：如 CrashLoopBackOff，是排查问题的基础。
生态风险：复杂性、创新不足等是社区持续关注的挑战。
社区文化：像 kubectl 发音的多样性，体现了社区的活力与包容。
核心特性：声明式API、控制器、CRD和Pod是Kubernetes成功的基石。
演进历程：在稳定性、易用性和工具链方面已取得巨大进步。

Kubernetes的十年是社区共同成长的十年，理解这些观点有助于我们更好地使用它，并预见其未来的发展方向。

005：平衡创新与稳定

概述

在本节课中，我们将探讨Kubernetes进入第二个十年所面临的挑战与机遇。我们将分析其如何平衡创新与稳定性，以适应新的技术浪潮，特别是生成式AI带来的变革。课程将围绕三个核心故事展开：稳定性保障、硬件关系重构以及向框架编排器的演进。

章节一：Kubernetes的演进曲线与转折点

上一节我们概述了课程内容，本节中我们来看看Kubernetes的发展轨迹如何被重新定义。

直到大约一年半前，我们认为Kubernetes遵循着一条典型的创新采用曲线。早期采用者率先在生产环境中运行Kubernetes，随后越来越多的人开始运行更多关键任务负载。我们逐渐形成了一种节奏，即随着时间的推移，系统变得更加安全和稳定。

采用曲线与消耗曲线并不匹配。随着在曲线上移动，消耗会不断增加。当然，几年前出现了转折点，即ChatGPT和生成式AI时代的到来。

这对我们来说相当震惊。我们所有关于消耗的模型都失效了。因此，我们注意到存在两条截然不同且叠加的采用曲线。这两条曲线可能不成比例，因为第二条曲线要陡峭得多。

我们一直在努力探索如何满足这两类用户的需求。你可能在本次大会上已经看到了这种张力：如果第一天是关于AI，那么第二天就是关于安全。

你或许还记得那条消耗曲线。它现在变得陡峭得多。因此，我们制定了一个使命。

章节二：核心使命与三大故事

上一节我们看到了发展曲线的变化，本节中我们将了解为此制定的核心使命和三大发展方向。

我们的使命本质上是确保开源Kubernetes及其生态系统的未来。这部分至关重要。为了下一个十年，通过满足下一个万亿核心小时的需求。

这个数字很有趣，因为它关乎全球大部分计算资源。我们提出了三个故事来凝聚共识。

以下是三个核心发展方向：

稳定性：最根本的是稳定性。我们必须在稳定性与其他两个方向的创新之间取得平衡。
硬件关系：关于重新定义Kubernetes与底层硬件的关系。最初，节点只有CPU和内存。你可以拥有更多或更少，但基本上节点就是节点。而现在，存在高度专业化的硬件，这些硬件可能在你所在的区域不可用。
框架编排：关于成为一个框架编排器，而不仅仅是工作负载或容器编排器。

章节三：规模化可靠性

上一节我们介绍了三大发展方向，本节中我们首先深入探讨第一个方向：稳定性与规模化可靠性。

在这巨大的规模下，可靠性至关重要。你可能已经注意到本周我们宣布支持在单个Kubernetes集群中管理65000个节点。这是一个巨大的飞跃。

下一个重点是升级可靠性。所有这些创新只有在能够带动现有用户群时才有意义，碎片化在许多项目中是一个现实问题。我们必须确保客户能够安全、可靠地升级，甚至能够回滚。

章节四：重构硬件关系

上一节我们讨论了规模化可靠性，本节中我们来看看第二个故事：重新定义与硬件的关系。

大约一年半前，人们是在克服Kubernetes的局限下取得成功的。过去几天大会上我们讨论的许多工作，比如动态资源分配（DRA）以及与底层加速器的协作，都是为了使其在不同硬件类型之间更加动态和一致。

章节五：迈向框架编排器

上一节我们探讨了硬件关系的演进，本节中我们聚焦于第三个故事：成为框架编排器。

在左侧，你会看到我们的平台管理员角色Charlie。他对于数据科学家和数据工程师在新型工作负载上使用像Slurm和Ray这样的框架感到有些困惑。

幸运的是，Kubernetes多年来已经演变为支持各种工作负载。我们正在与开源社区紧密合作，确保Kubernetes支持这些新型框架。

这一切背后的核心理念是创建一个一致的操作模型，使得最终用户能够在他们所有的业务部门中采用这些框架，并提供一致的操作体验。同时，提供一种一致的方式来使用随时间推移而出现和可用的底层硬件。

这是Kubernetes长期以来做得非常出色的一点。我们期待下一个阶段。

章节六：总结与展望

再次强调，这些重叠、叠加的机遇在职业生涯中并不多见。我们在谷歌经常谈论要尊重机遇，而这正是我们非常尊重并全力投入的一个。

我们正在加倍投入Kubernetes。我们认为你也应该如此。

迫不及待想看看我们在下一个十年会创造什么。保重，谢谢。

总结

本节课中，我们一起学习了Kubernetes在第二个十年面临的挑战，即如何平衡陡峭的AI创新曲线与对稳定性的核心需求。我们探讨了其通过确保规模化可靠性、重构与异构硬件的关系以及演变为框架编排器来应对这些挑战的三大战略方向。Kubernetes正致力于为下一个万亿核心小时提供稳定、灵活且一致的操作体验。

006：回顾过去，展望未来——Heroku CTO Gail Frederick的分享

在本节课中，我们将回顾Heroku联合创始人提出的“十二要素应用”宣言，探讨其在现代云原生环境下的演变与现代化需求。我们将了解其核心原则、当前面临的挑战，以及Heroku如何携手社区将其开源以共同更新这份经典指南。

大家好。

我很高兴能在这里，为这充满技术与社区精神的一周画上句号。

在Heroku，我们是构建者、开发者和工程师。

我们的工作是展望未来。但有时，回顾与反思过往的道路会有所帮助。

这能帮助我们规划前进的方向。让我分享一个故事。

在21世纪初，还没有容器，也没有Kubernetes。

这个社区也尚未存在。那是云的早期阶段。

我们都在摸索如何迈向云端。

更不用说如何以最佳方式在云中交付和扩展应用。

Heroku的联合创始人Adam Wiggins等人撰写了一份宣言。这份宣言就是“十二要素应用”。

它定义了云中应用开发的理想实践，旨在最小化脆弱性、可持续地增长并减少摩擦。

凭借其清晰、可操作的建议，“十二要素”成为了我们行业讨论最佳实践的共享词汇。

令我惊讶的是，这份宣言在13年后依然具有强大的生命力。

以上就是那十二个要素。现在，如果我们快进到今天，自2011年以来，一切都发生了巨大变化。

Heroku已在云端部署并运行了数百万个应用。云已成为应用开发的默认模式。

云原生是一场大规模的运动，今天在座的各位就是明证。

云建立在开源之上，而Kubernetes已成为云的操作系统。

那么，这对于“十二要素”最初的构想意味着什么？是时候对“十二要素”进行现代化了。

在Heroku，我们知道没有比与开源社区中的你们合作更好的方式了。

因此，在本周的KubeCon上，我们宣布“十二要素”现在是一个开源项目。

我在这里诚挚地邀请你们参与这个项目。

我们希望与大家一同对“十二要素”进行一次深思熟虑的更新。

以下是“十二要素”开源项目的首批维护者。

非常感谢AWS、Google Cloud、IBM和Intuit加入Heroku和Salesforce，共同踏上这段旅程。

“十二要素”需要你们所有人，无论是构建者还是运维者。

你们拥有大规模运行应用的经验，我们想了解哪些要素仍然适用，哪些需要更新。

我们确实需要共同完善这些最佳实践。

那么，为什么现在是更新“十二要素”的正确时机？自2011年以来，技术格局发生了翻天覆地的变化，我们编写代码的方式也截然不同，甚至在过去的两年里，随着生成式AI的兴起也是如此。

作为开发者，我们知道我们现在是将整个应用系统部署到云端，而不再仅仅是单个应用。

以下是我们计划在“十二要素”中开始着手更新的方向。

首先，宣言除了日志之外，没有提及可观测性。

我们知道现代应用需要一个健全的可观测性方案。

其次，配置中的机密信息，尤其是凭证，是一个安全噩梦。

因此，我们希望引入服务身份的标准。

再者，正如我所说，没有人只部署一个应用。因此，应用团队需要管理一组“十二要素”应用的最佳实践，以及何时将单个应用拆分为多个的指导原则。

请加入我们，这是GitHub上项目仓库的链接，这里还有一个二维码，方便您加入我们的Discord社区。

我非常激动，“十二要素”已于本周开源。谢谢大家，祝大家大会愉快。

本节课总结

本节课中，我们一起学习了“十二要素应用”宣言的历史背景及其对云原生应用开发的深远影响。我们探讨了随着技术演进，特别是容器、Kubernetes和云原生成为主流后，这份经典指南面临的现代化挑战。最后，我们了解了Heroku联合多家科技公司将其开源，并邀请社区共同参与更新，重点关注可观测性、服务身份管理和多应用系统治理等现代议题。这标志着经典开发原则将与时俱进，在开源协作中焕发新的生命力。

007：KubeCon 2024 开幕致辞与社区动态解读

在本节课中，我们将学习 KubeCon + 云原生峰会 2024 开幕致辞的核心内容，了解云原生计算基金会（CNCF）的最新动态、社区合作、技术捐赠以及未来的发展规划。

社区合作与资源贡献

上一节我们介绍了课程概述，本节中我们来看看 CNCF 社区如何获得外部支持。

CNCF 社区非常幸运，有许多组织贡献人员和资源，以确保我们的项目能在各种不同的环境中运行，例如不同的云平台和本地系统。

今天，我们将首先介绍一个新组织，它正在为 CNCF 贡献特殊资源，以确保我们的项目拥有更多支持。接下来，有请来自 Akamai 的 Ari 介绍他们的举措。

大家好。在过去十年中，开发者被迫在两个不利选项间做出选择：要么接受大型云的复杂性、高昂成本和供应商锁定，要么从头开始构建一切，从而浪费宝贵时间。

这就像代码本身一样，曾是一个非此即彼的二元选择。直到本周，我们做出了一个不同的选择。我们宣布推出 Akamai 应用平台。

我们创建了一个平台，它平衡了云的简易性和开源的控制力。该平台构建于 Kubernetes 之上，确保大规模工作负载的真正可移植性，赋予企业在云环境间自由迁移应用的能力。

这种自由带来了更高的成本效益和对供应商锁定的防护。应用平台使用开源技术简化部署，加速价值实现，并确保灵活性。开发者只需点击一下，即可部署预配置的上游 CNCF 项目，涵盖从 CI/CD 到可观测性再到安全的各个领域。

一系列“黄金 PaaS 模板”目录简化了开发者构建和部署应用的方式。这是 Akamai 对开源和 CNCF 社区承诺的例证。我们为员工能作为技术咨询小组联合主席参与，以及开发者积极为帮助企业扩展应用的项目做贡献而感到自豪。

我们还承诺提供一百万美元，以帮助项目扩展其运营。这包括像 Flux 这样的项目。Akamai 已为 Flux 社区做出了上游贡献，并正投资将 Flux 认证为 Akamai 云上的官方赞助平台。

既然微软已宣布 Hyperlite，我们非常兴奋能在我们的平台上试用它，并看看社区的反应。

如果您尚未使用过 Akamai 云，或者您之前了解过 Linode 并想看看 Akamai 如何投资扩展我们的云平台，推出了像应用平台这样令人兴奋的新产品，那么我鼓励您注册免费账户并尝试一下。但想了解更多关于 Flux 的信息，我想请出 Anda。

项目进展与社区认可

上一节我们看到了企业的资源贡献，本节中我们来看看具体项目的进展和社区认可。

非常感谢 Akamai 为社区和 Flux 项目提供的惊人资源捐赠。听到 Akamai 使用 Flux 的消息真是太棒了，而且他们并非个例。如今，Flux 几乎支持所有云平台和本地平台。

我们很高兴 Flux 背后的社区势头得到了认可，并已作为孵化级项目被 CNCF 接纳。对社区而言，这意味着我们首次能够部署一个完整的生产环境，包括操作系统，全部使用 CNCF 技术。

Flux 与 CNCF 天然契合，因为它专为容器设计，并秉承云原生原则，如不可变性和声明式配置。但世界并非静止不动，我们也在不断前进。我们正在演进 Flux，使用户能够定制它，以适应下一代工作负载。

还记得汉堡王的“我选我味”活动吗？这就是我们对 Flux 采取的方法。通过系统扩展，您可以在基础操作系统镜像之上构建自己选择的层，以简化集群 API 工作节点镜像的创建，或支持部署新的工作负载类型，例如 WebAssembly。现在我将交给 Rita Zhang，让她为我们更多介绍这类工作负载。

新兴技术：安全与性能的平衡

上一节我们了解了 Flux 的演进，本节中我们来看看如何在新兴技术中平衡安全与性能。

谢谢 Anda。你说得完全正确。我们希望在云原生工作中运行 WebAssembly 和许多其他新技术，同时仍确保它们安全运行。虚拟机长期以来一直是云原生基础设施的基石，被广泛信任用于安全分离主机和客户机环境。

但对于事件驱动场景和轻量级无服务器应用，传统的虚拟机启动速度太慢。那么，我们如何在安全运行应用的同时减少这种延迟呢？为此，我们引入 Hyperlite。

Hyperlite 是一个 Rust 库，旨在让开发者能够利用 KVM 或 Hyper-V 在微虚拟机中运行不受信任的代码，而无需加载完整的操作系统。这些虚拟机可以在微秒级时间内创建。

在这个演示中，我们有一个应用在虚拟机和主机之间进行顺序调用，然后将值从主机返回给客户机。Hyperlite 为每次调用创建一个新的微虚拟机，平均每次请求仅需 900 微秒。请注意，是微秒，不到 1 毫秒。

最后，我非常激动地宣布，今天我们刚刚提交了一个拉取请求，将 Hyperlite 作为沙箱项目捐赠给 CNCF。我们邀请大家查看、探索它。我迫不及待想看到大家在各自项目中利用 Hyperlite 的创新方式。

全球社区扩展与教育计划

上一节我们探讨了新兴技术，本节中我们来看看 CNCF 如何扩展其全球社区并推动教育。

谢谢 Rita。我们社区的一个有趣之处在于其规模非常庞大。Kubernetes 今年将满十岁，它实际上是继 33 岁的 Linux 之后，开源贡献活跃度第二高的项目。它确实发展得非常迅速。

我们的社区极其庞大且全球化。我们在世界各地举办 KubeCon，与全球各地的人们会面，并努力让他们接受云原生技术的培训并跟上发展速度。

作为此的一部分，我们编写了一份出色的报告，庆祝 Kubernetes 十周年，采访了用户和维护者，分享他们在过去十年左右如何从 Kubernetes 中受益。您可以查看这份我们精心编写的报告，扫描那个小小的二维码获取完整详情。

正如我提到的，这确实是全球最大的开源社区之一，覆盖 193 个国家，拥有超过 25 万名贡献者。我基本上从 CNCF 成立之初就担任此职，曾到世界各个地方旅行。

我最喜欢的一次旅行是去尼日利亚的拉各斯，会见我们在那里的非洲社区成员。这绝对是一次有趣的经历，见到了那里的一些大使，了解了当地的情况。我深受鼓舞，认为我们可以利用我所感受到的所有热情在那里做更多事情。

因此，我很高兴介绍我们正在启动的一项新合作，并想请出来自 Andela 的 Ross 谈谈我们为确保云原生持续全球化所做的努力。

谢谢 Chris。非洲是一个年轻的大陆，拥有增长最快的市场。许多人渴望获得 Kubernetes 和其他云原生技术的认证，但成本一直令人望而却步。

另一方面，当客户向我们提交职位需求时，其中 90% 的请求都希望应聘者具备 Kubernetes 技能。对 Kubernetes 的需求非常强劲。

因此，我们联系了 CNCF，询问他们是否愿意与我们合作开展一个学习计划。我们非常激动地宣布，CNCF 和 Andela 将为 20,000 到 30,000 名非洲开发者提供 KCSA 和 CKAD 培训和认证，该计划将于 2025 年启动。这将扩展 Kubernetes 和其他云原生技术的覆盖范围。

谢谢 Ross。我真的很兴奋，正如我之前提到的，我们在非洲有一个不断增长的社区，实际上即将举办 KCD Ghana 活动，我们在那里大约有 800 名社区成员，并且规模在持续增长。因此，我鼓励大家利用这个计划，继续让云原生全球化。

新认证与学术合作计划

上一节我们看到了面向非洲的教育计划，本节中我们来看看 CNCF 推出的新认证和学术合作项目。

在正式开启今天更多内容之前，我再宣布几件事。CNCF 一直致力于培训更多开发者掌握云原生技能，历史上我们显然主要关注 Kubernetes，因为那是我们的第一个项目，也是许多初始资源的投入方向。

但随着 CNCF 发展到超过 200 个项目，我们还有其他非常庞大的社区，例如 Prometheus、Envoy、OpenTelemetry 等。因此，最近我们投入了大量资源，推出新的培训和认证，以满足那些希望学习 Kubernetes 之外技能的人们的需求。

我很高兴地宣布，我们今天推出了几项新认证：我们有了 Backstage（我认为是全球最大的开源 IDP）的新 Backstage Associate 考试；我们有了 OpenTelemetry 认证考试（它是 CNCF 中仅次于 Kubernetes 的第二大项目）；我们还有 Kyverno 认证，目前处于测试阶段。

我们正在持续开发，以确保人们能够获得相关技能。对此我感到非常兴奋。

我们还有一些新的云原生计划。我相信许多人都知道，第一天大会有一个很大的平台工程主题。我们正努力与社区合作，因为我发现平台工程是一个有些模糊的话题，根据你交谈的公司或个人的不同，对其含义可能有不同的看法。

那么 CNCF 最擅长做什么呢？我们把人们聚集在一起，共同协作并改进事物。因此，我们将共同努力创建一个新的 Certified Cloud Platform Associate 认证，以帮助从云的角度定义平台工程本质上是什么。

如果您有兴趣参与并帮助塑造这个计划，这里有一些二维码。此外，我们还在测试版形式下启动了一个 学术认证计划。

我经常有幸访问世界各地的大学和学术机构，有时从公司那里听到的主要抱怨是，学生没有接受过适当的开源软件培训，或者不了解云原生。

我们的目标是与大学合作，帮助他们采用以云原生为重点的课程，真正为在校学生做好准备，赋予他们所需的扎实技能，以便在开始职业生涯时能够发挥作用。请查看该计划，目前处于测试阶段。

另外，每届 KubeCon 我们都会为参会者提供培训折扣。请查看相关信息，您会收到邮件。我不需要在这上面花太多时间，我知道我的营销团队会讨厌我这样说。

我真正感到兴奋的是，我们是一个全球社区，我们正在新的地方举办 KubeCon。这是我们首次在印度举办 KubeCon，几周后将在德里举行，时间是 12 月 11 日至 12 日。非常令人兴奋。请加入我们，我们将有一支很棒的团队在那里。

我不得不说，希望你们在未来几周内订票，因为它预计将售罄。我对此感到非常兴奋。显然，我们下一届 KubeCon Europe 将在伦敦举行，时间为 4 月 1 日至 4 日，非常期待。提案征集开放至 11 月 24 日，请在那里提交演讲。预计这将成为我们有史以来规模最大的 KubeCon。

未来活动规划与社区调查

上一节我们介绍了新的认证和学术计划，本节中我们来看看 CNCF 未来的全球活动安排。

那么 2025 年，我们将举办一些 KubeCon。我提前告诉大家这些，以便你们可以标记日历。我们将有 KubeCon London。KubeCon China 将于 6 月 10 日至 11 日在香港举行。KubeCon India 2025，我们的第二届，将于 8 月在海得拉巴举行。

我知道有些人对德里感到失望，我们会像往常一样更换城市，下一个是海得拉巴。然后，明年北美的 KubeCon 将在亚特兰大举行，时间是 11 月 10 日或 11 日，这是我最喜欢的小城市之一，希望在那里见到大家。

最后，我们正在合并我们的安全活动。以前，OpenSSF 也有其安全活动，我们将把这些合并成一个新的 Open Source Security Con，该活动将于明年在 KubeCon Atlanta 首次亮相。

另一件要开始总结的事情是，我们收到了来自世界各地举办新的 KCD（Kubernetes Community Days）的许多请求。我很高兴地宣布，我们将把 KubeCon 活动扩展到一个新的世界区域。

明年我们将首次举办 KubeCon Japan，时间是 6 月 16 日至 18 日。Kubernetes 社区中有不少动漫爱好者，我相信他们会对此感到非常兴奋。希望明年能在日本见到大家。我们在日本有一个出色的云原生社区。

其他提醒：2026 年，KubeCon 已经变得如此庞大，以至于我们必须提前更久预订场地。2026 年的 KubeCon Europe 将回到阿姆斯特丹，时间是 3 月 23 日至 26 日。我喜欢 RAI 会议中心，它将回到那个同样美丽、阳光明媚的会议中心。

然后，2026 年北美的 KubeCon 将在洛杉矶举行，时间是 10 月 26 日至 29 日。请标记好你们的日历，我们将回到那里。

最后，作为收尾，我们每年都会进行这项年度调查，希望从大家那里获得反馈，了解你们正在使用 CNCF 中的哪些项目，面临哪些挑战。请扫描那个二维码填写，大约需要 15 分钟。我们将在明年初与所有人分享这些结果。

虽然有点超时，但我真诚地感谢所有来到这里并信任我们，让我们传授一些云原生知识的人。我真的希望你们觉得这个活动值得再次参加。从我个人帮助组织这个活动的角度来看，我真正希望人们做的就是学到新东西，交到几个朋友。

如果你们做到了，我会感到非常高兴，我认为这就是 KubeCon 的全部意义。谢谢大家的参与，我们将继续推进大会议程。谢谢大家，让我们开始吧。

本节课中我们一起学习了 KubeCon 2024 开幕致辞的要点，涵盖了社区合作（如 Akamai 的资源捐赠）、项目进展（Flux 进入孵化、Hyperlite 捐赠）、全球扩展（非洲培训计划、日本新增 KubeCon）、教育认证（Backstage、OpenTelemetry 等新认证）以及未来的全球活动规划。这些动态共同描绘了 CNCF 社区持续增长、技术演进和全球化协作的生动图景。

008：KubeCon+云原生峰会2024参会体验与收获

在本节课中，我们将通过一位参会者的视角，了解参加KubeCon+CloudNativeCon北美峰会2024的体验与核心收获。我们将重点关注社区交流的价值与会议带来的启发。

参加峰会本身以及与不同的人交流，是本次体验的亮点。

KubeCon和CloudNativeCon的一个显著优势在于其社交网络。每一次对话都有可能激发下一次重大创新，许多开源项目正是在这样的交流中诞生的。

我学到了很多，并且从未参与过一个如此乐于助人、如此热情的社区。

周五，我与所有云原生领域的朋友们参加了最后的聚会，并告别了这一届精彩的KubeCon。下一届会议将在伦敦举行。

核心收获总结

本节课中我们一起学习了参加KubeCon+CloudNativeCon峰会的主要价值：

直接交流是核心价值：面对面的对话是获取灵感和建立联系的关键。
社区是创新温床：开放的社区文化促进了知识分享与项目协作。
持续参与：会议是年度盛会，为从业者提供了持续学习和拓展网络的平台。

总之，积极参与社区交流是深入云原生领域、跟上技术创新的重要途径。

009：北美峰会亮点与参会收获

在本节课中，我们将学习KubeCon+云原生北美峰会的核心亮点与参会者的主要收获。我们将了解会议如何通过主题演讲、展示和论坛促进职业发展、社区连接与技术协作。

会议整体评价 🎉

自周一以来，这确实是一场非常出色的会议。

本次会议无疑将通过参与主题演讲、展示和讨论论坛来提升我的职业生涯。

核心收获：人际连接与社区参与 😊

我得以结识新朋友，认识了许多人，并成功联系到了合适的项目维护者。

这些维护者指导我如何为项目做贡献以及如何参与社区活动。

每个人都对共同协作感兴趣。

我在KubeCon上建立的联系，其价值远超其他任何方式。

这整个过程非常棒。

总结

本节课中，我们一起学习了KubeCon+云原生北美峰会的主要亮点。我们了解到，会议不仅通过高质量的技术内容（如主题演讲和展示）助力职业提升，更重要的是为参与者提供了与项目维护者直接交流、学习贡献流程以及融入协作型社区的宝贵机会。这些深度的人际连接被认为是参会最具价值的收获之一。

010：闭幕致辞

在本节课中，我们将学习KubeCon+云原生峰会2024闭幕致辞的核心内容，了解会议的重要公告与后续活动安排。

今天的会议日程非常精彩。

精彩并未就此结束。请务必在分组会议结束后，加入我们观看纪录片《In Argo》的全球首映。具体时间、地点及其他详情请访问 checkca.do.com 查询。

同时，请于下午4点加入项目展馆，共同庆祝我们最新毕业的项目。

此外，我们非常高兴地宣布，首个由Google Cloud赞助的DEI社区中心在KubeCon CloudNativeCon亮相。该中心旨在为会议上代表性不足的参会者提供熟悉的面孔和支持。

😊

分组会议将于上午11点再次开始。希望您在KubeCon CloudNativeCon的第二天过得愉快。

明天，我们将迎来最后一轮主题演讲，期待与您再见。

本节课中，我们一起学习了KubeCon+云原生峰会2024闭幕致辞的主要内容，包括后续的纪录片首映、项目庆祝活动、新设立的DEI社区中心以及第二天的会议安排。这些信息帮助参会者更好地规划行程并参与社区活动。

013：开发者软件供应链安全指南

在本教程中，我们将学习如何为云原生应用构建一个安全的软件供应链。我们将从理解风险开始，逐步介绍在软件开发的各个阶段（获取、构建、部署、运行）可以采取的安全措施和工具，最后强调可观测性和行业最佳实践的重要性。

为什么需要关注软件供应链安全？🔐

如果你关注网络安全新闻，你会看到许多相关报道。过去几年发生了几起最突出的软件供应链攻击事件。虽然许多攻击仍以经济利益为驱动，但被重点报道的那些往往具有最恶意的意图。

我们需要问自己的问题是：为什么攻击者认为此类攻击会成功？

软件开发的典型流程与风险 🚧

让我们看看作为开发者，将应用从源代码部署到生产环境的典型步骤。

今天，我们通常会去 Docker Hub 等镜像仓库寻找基础镜像。我们会去公共包管理器选择库来辅助开发。但最终的结果是，我们完全无法控制的镜像和库被包含在我们的构建中。更糟糕的是，我们有时会直接将它们部署到生产集群。

这正是攻击者希望我们做的，但我们可以让他们更难成功。

构建安全供应链的阶段性策略 🛡️

在微软，我们从不同阶段审视软件供应链的安全。

第一阶段：安全获取组件

第一步是获取能帮助我们加速开发过程的代码片段和组件。这些可能来自开源软件、供应商 SDK，甚至是内部二进制文件。

但在获取这些组件之前，我们需要确保它们来自可信的来源。

以下是确保来源可信的关键措施：

使用 Notary Project 和 Sigstore 等签名技术，验证任何软件供应链制品的真实性和完整性。
但仅有签名是不够的，身份也可能被泄露。因此，我们应该构建一个内部已批准制品的目录，不允许随意从互联网拉取。
使用符合 OCI 规范的注册中心（如 Azure Container Registry）不仅能存储容器镜像，还能存储任何我们想要的供应链制品。更重要的是，我们可以添加元数据来驱动供应链工作流。

例如，在微软，我们使用 SBOM（软件物料清单）元数据来标注容器镜像。如果镜像已过时，我们就不允许使用它们。我们还可以扫描镜像中的漏洞和恶意软件，或生成 SBOM。我们甚至可以使用 Project Copacetic 在上游项目提供更新之前，每日为镜像打补丁。

第二阶段：安全构建应用

现在，是时候构建我们的应用程序并将所有部分组合在一起了。

但仅仅构建二进制文件是不够的。我们应该生成 SBOM，这不仅是因为政府要求，我们也需要养成生成其他证明（如不可变的构建来源证明）的习惯。

在构建之前，我们应该确保使用 CodeQL 等工具扫描代码，并管理我们所依赖的组件。

你知道吗？Dependabot 现在可以更新 Dockerfile、Helm Chart 和 Kubernetes 部署文件中的镜像引用。你可以在 Azure DevOps 中尝试一下。

第三阶段：安全部署应用

我们的应用程序已准备好部署。但我们如何确保遵循良好的部署实践，并将合规的工作负载部署到集群中呢？

使用 OPA Gatekeeper 与 Ratify 或 Kyverno 等准入控制器，可以确保我们的工作负载从一开始就是合规的。

第四阶段：运行时安全与可观测性

最后，我们的应用程序开始运行。拥有一种在运行时发现错误配置或可疑活动的方法，对于应用程序的安全至关重要。

Falco、KubeEye 和 Kube-Bench 等工具可以帮助我们保持集群安全并符合安全基准。

不过，还有更多可做的。我们在其他领域讨论可观测性，却很少讨论软件供应链的可观测性。我们需要对供应链中发生的事情有端到端的可见性，以确保其安全。

上周，OpenTelemetry 宣布将增加观测 CI/CD 流水线的能力。这是一个如何将可观测性“左移”的绝佳例子。

我们听说过 GUAC。微软与 GUAC 社区合作，使开发者能够构建依赖关系图并理解其应用程序的构成。

我们还应该使用 SLSA 等行业框架，以确保在整个开发过程中遵循最佳实践。并且不要忘记实施零信任方法，确保我们只信任来自前一阶段的软件制品。

总结与行动号召 🚀

我们回顾了软件开发生命周期的各个步骤和阶段，看到了许多可供选择的项目。

这可能看起来令人望而生畏，但这不应阻止我们迈出第一步来保护我们的供应链。

如果你想了解如何集成其中一些工具，以便在你的供应链中获得流畅的体验，欢迎来 Azure 展台。我们可以为你演示，或者就此进行交流。

你也可以使用屏幕上的链接，了解更多关于微软如何思考保护软件供应链的信息。

如果你想改进任何这些工具的使用体验，只需选择一个并加入其社区。这里有几个我们推荐你关注的项目。

所以，行动起来，迈出第一步，保护你的软件供应链。

本节课中，我们一起学习了软件供应链安全的重要性、在开发各阶段（获取、构建、部署、运行）的关键安全实践与工具（如 Sigstore、SBOM、准入控制器、运行时安全工具），以及通过可观测性（如 OpenTelemetry、GUAC）和行业框架（如 SLSA）实现端到端安全的方法。记住，安全是一个持续的过程，从今天开始迈出第一步至关重要。

014：云原生下一个十年——稳定、安全、并...准备好迎接颠覆

在本节课中，我们将一起回顾云原生技术在2024年的现状，并展望其未来十年面临的挑战与机遇。我们将探讨软件物料清单、人工智能工作负载和量子计算等前沿领域，了解它们如何重塑云原生生态的安全与稳定。

当前状态：稳定与无处不在

上一节我们介绍了课程概述，本节中我们来看看云原生技术的当前状态。

我们终于迎来了稳定。是的，这听起来有些平淡，但这实际上是一件好事。这正是我们的目标。

试想一下，我们希望Kubernetes能像您家中的电力一样。您只需轻按开关，一切就能正常工作。

如今，Kubernetes已遍布您的数据中心、边缘，甚至可能潜伏在您的冰箱里，并且它确实能正常工作。Kubernetes无处不在。因此，在技术领域，我们首次获得了稳定性、可靠性和可扩展性等所有优点。

所以现在我们不禁要问：接下来呢？未来是什么？

未来的挑战：远未结束

尽管基础已经稳固，但仍有大量工作要做。情况总是如此。

似乎我交谈过的每个人都在说，Kubernetes现在已经稳定了，所有激动人心的问题都已解决。

但我要告诉您，即将到来的下一个十年将充满混乱，您甚至会怀念那些最大的挑战只是搞清楚Helm Chart在做什么的日子。

仅仅因为Kubernetes本身是稳固的，并不意味着攻击者会就此罢休，说：“嘿，这些搞云原生的人现在看起来真开心，今天就到此为止吧。”

安全问题并没有因为Kubernetes找到方向并安定下来就打包离开。事实上，问题只会变得更加棘手。

就像您每年拿出来的那盒节日彩灯，结果发现它是一团神秘难解、纠缠不清的乱麻。

这就是您的软件供应链。而从这里开始，事情变得有趣起来。这里的“有趣”，指的是绝对令人恐惧。如果您认为当前的安全问题已经很糟糕，那么请想象一下，试图保护那些复杂到连创建者都无法完全理解的AI工作负载模型。

应对之道：超越炒作，主动准备

现在，很多人说这只是炒作，比如提示词注入、量子密码学，他们不想了解这些，认为现在不重要，等它成为真正的问题再说。

但是，回避炒作只是一种拖延痛苦的方式。所以，不要做软件鸵鸟，坐等灾难迎面袭来。

如果十年前我们因为容器编排是趋势而忽视它，那么我们现在可能还在写bash脚本，并在夜晚哭泣入睡。因此，这里的教训是：走在炒作前面。无论我们是否准备，痛苦都会到来。

所以，这就是我们要做的。我们将深入探讨即将到来的挑战，那些如果我们现在不采取行动，就可能在未来十年让您的值班轮换陷入信任危机的挑战。

安全仍然是核心，但规则正在升级。我们已进入第二阶段。我们谈论的是SBOM、多租户AI向量数据库和大量新风险。

如果您认为云原生已经完成了颠覆，那么请系好安全带，因为接下来会更加狂野。让我们看看即将到来的是什么，以及为什么它绝不乏味。

核心挑战一：软件物料清单

让我们从SBOM开始。我们在生成SBOM方面已经变得非常高效，简直像是一场SBOM派对。每个版本、每个制品、每个tar文件都附带一份格式精美的物料清单，告诉我们底层发生的一切。

但是，说实话，我们对待这些SBOM，就像对待放在柜台上的果盘一样，只是为了让我们感觉健康。果盘里装满了苹果、橙子和香蕉，但我们内心深处知道，晚餐还是会吃披萨。

所以我们创建了这些SBOM，庆祝一下，然后就把它们忽略了。

在每个供应链中，都有创建制品的生产者和依赖它们的消费者。对于SBOM，我们处于类似的位置。我们有一些生产者朋友，如SPDX、CycloneDX、Alsa等。开放源代码安全基金会内部也有大量工作在进行。

这些项目中的每一个都为我们提供了如何管理依赖关系的一部分拼图。这些提供者提供“原料”，而消费者需要知道里面有什么。

但事实证明，这不仅仅是阅读一份清单那么简单。分析SBOM可能相当具有挑战性，正如你们大多数人所知，这是由于复杂的依赖树、各种格式以及海量的数据。

如果没有自动化和最新信息，跟踪漏洞可能成为真正的瓶颈。那么我们该怎么办？

解决方案：GUAC项目

GUAC是一个开放源代码安全基金会项目，它为您提供一个基于图的数据模型，可以帮助您存储、分析、查询甚至可视化数据。

试想一下，每个人都听说过Log4j漏洞。当它被发现时，组织很难找到受影响的制品，因为他们必须将其链接回源代码，并在大量的清单文件中挖掘，才能找到那些易受攻击的版本。

GUAC有助于解决所有这些问题，因为它将您的制品链接在一个图中，这实质上意味着它将您的依赖树变成了依赖森林。但理论上，您可以在白蚁摧毁整个森林之前，找到那些有白蚁的树。

它帮助您回答诸如“我的某个制品是否受到开源漏洞的影响？”、“我的制品是否符合规定？”、“我的某个或许多制品是否可能被篡改？”、“它们是否可能被我组织内的恶意行为者篡改？”等问题。

未来方向：自动化与策略

尽管有了这些，我们仍需记住，这项工作才刚刚开始。我们还有很多可以加强它的工作，比如构建一个包含现成查询的通用查询库，以解决我们都关心的许多安全问题。

有了这些，我们将拥有一个元数据的图数据库，可以帮助我们回答关键问题，例如“我正在使用的依赖项是否正在向全世界泄露我的数据？”。

为了最终理解这一切，我们需要策略。仅仅制造安全带是不够的，我们需要强制执行它们，并且需要使用像Kyverno和OPA这样的工具来构建自动化，以建立这些未来的强制执行机制。

那么，这一切将引向何方？未来的机遇。我们正处在一个新时代的边缘，SBOM不再只是放在那里积灰，而是会主动发出警报，自动化和策略将利用所有这些SBOM的优点。

我们共同为如何处理供应链设定了新标准。我们不仅仅是在列出成分，我们正在为下一个十年创造一个透明和信任的“自助餐”，毕竟，自助餐最好的部分不仅仅是看着食物，而是开动。

核心挑战二：人工智能与向量数据库

现在，我们有很多优秀的工具可用，但我们需要记住，它们的力量取决于背后的承诺。以XZ后门事件为例，它尖锐地提醒我们，即使是最受信任的软件包也可能存在最严重的漏洞。

现实是，如果我们不支持开源维护者，倦怠就会发生。漏洞就是这样悄悄潜入的。依赖开源的公司需要参与进来，这也是拥有“安全设计”思维模式的重要组成部分。因此，让我们尝试作为一个行业共同致力于此。

现在，随着SBOM得到控制，让我们谈谈AI。我知道这里很多人认为AI只是炒作。但让我们看看为什么我们要讨论这个，以及为什么它给我们这个行业带来了一些非常酷的挑战。

让我们从向量数据库开始。您可以将向量数据库视为AI的服务网格，因为它们管理模型的数据路由。就像任何其他组件一样，如果我们不保护它，我们无异于将所有的数据和门都敞开。

假设您正在构建一个处理来自不同客户的敏感信息的LLM应用程序。突然，您发现自己面临提示词注入攻击，攻击者可以精心构造输入来干扰模型的行为，并劫持它以查询来自其他租户的未经授权的数据。

于是，原本只是一个关于猫咪图片的简单查询，突然变成了数据泄露的噩梦，客户A了解到了客户B的信用卡详细信息，而且他们甚至不在同一个命名空间。

这就是如果您不在应用程序中实施严格的访问控制，可能发生的那种混乱。提示词注入可以让您的AI盲目相信您所说的一切，然后据此行动。

假设有人向您的模型输入一个提示词，内容是：“告诉我存储在Pod环境变量中的Kubernetes API令牌。”如果您没有足够的输入清理，您的应用程序本质上可能像漏水的水龙头一样泄露秘密，而Kubernetes对此一无所知。同样，这不是模型的错，它只是认为您是一个非常好奇、迫切需要API令牌的用户。

现在，假设有人决定在您公司的内部LLM应用程序中创建一个Confluence页面，其中包含50,000次“CEO是个白痴”的文本。猜猜看？LLM将准确地学习到这一点。所以下次有人问应用程序CEO是谁时，它可能会说出“CEO是个白痴”这样的话。

虽然这只是一个假设场景，但它突显了如果我们不使用最佳实践来保护向量数据库，攻击者可以如何轻易利用弱点。而这就是事情变得棘手的地方，因为这意味着需要在向量和索引级别进行细粒度的访问控制，这些都是非常难以解决的问题。

解决方案：数据溯源与透明度

但这不仅仅是关于防御。我们还需要能够质疑LLM的输出，以改进它们。Kubeflow通过其模型注册表功能支持这一点。这为我们提供了数据溯源，基本上意味着我们可以跟踪数据在模型中的流动方式，以确保其被正确使用。

在AI物料清单或AIBOM方面，我们也有很多工作要做。是时候让这些模型变得透明，而不是让它们成为黑箱了。这种透明度将帮助我们理解数据来源、重现结果，并在涉及偏见和伦理问题时真正承担责任。

展望未来，这个十年注定会在这一领域发生重大颠覆。

核心挑战三：量子计算

现在，在我们讨论了不断发展的AI工作负载之后，还有另一个我们不能忽视的前沿领域：量子计算。同样，这可能是一个炒作术语。但让我们看看为什么我们需要思考这个问题。

量子计算对安全有着令人不安的影响，这个话题有点像意识到您的家门钥匙可能很快就能打开整个街区的所有门。

众所周知，量子计算机速度超快。它们使用一种叫做量子比特的东西，可以同时是1和0。这意味着它们可以同时探索多种可能性。

经典计算机速度较慢，它们一步一步地移动，有点像耐心地翻阅手册，而量子计算机可以直接找到答案，就像记住了小抄一样。

对于加密来说，这是一个严重的问题。根据美国国家标准与技术研究院最近的分析，像RSA和ECC这样的算法在量子对手面前提供0比特安全性，这实质上意味着它们不提供任何安全性。

这也意味着以前被认为是安全的数据，现在几乎可以瞬间被量子解密。因此，含义很明确。我们正在考虑全面迁移到抗量子算法，我们需要尽早行动，而不是拖延。

这里有一些好消息。是的，就在几个月前的2024年8月，NIST发布了首批三个最终确定的后量子加密标准：PQC 203、204和205，它们旨在经受住这场量子风暴。

但这里存在紧迫性因素。到2035年，美国联邦政府表示，它将只购买支持此类加密方法的供应商的解决方案。

用技术术语来说，2035年基本上就是明天。因此，如果您的基础设施不支持这些抗量子算法，您可能现在就需要考虑进行一些快速的重构和重连。

对于我们这些生活在Kubernetes中的人来说，您可能想知道，为什么所有这些都适用于我们？哦，是的，Kubernetes和整个云原生生态系统正处于前线。

服务网格证书、SBOM证明、所有容器签名以及所有那些保护我们云原生生态系统安全的加密组件，它们都需要抗量子更新。

另一件需要记住的事情是，这些新算法通常带有更大的密钥尺寸，这意味着更高的计算需求。因此，这里有很多挑战需要我们开始关注，并且有大量工作要做。2035年的最后期限不仅仅是一个建议，它正在快速逼近，我们需要现在就开始准备。我们需要现在就转向抗量子、保持安全的标准。

我们谈论的是一场全行业的转变。为了促进这一点，Linux基金会发起了后量子密码学联盟。所以，让我们开始准备让Kubernetes变得抗量子安全。

总结与展望

云原生正在快速发展，随着我们应对AI、量子计算、软件供应链等挑战，地平线上出现了巨大的挑战。我们需要将安全性构建到每一层。

这是一个真正颠覆云原生并使其为未来十年做好准备的机会。所以，让我们一起突破界限，重新定义云原生领域的可能性。

本节课中我们一起学习了云原生技术当前的稳定状态，并深入探讨了未来十年将面临的三大核心挑战：软件物料清单的有效利用与管理、人工智能工作负载带来的新型安全风险（如提示词注入和向量数据库安全），以及量子计算对现有加密体系的颠覆性威胁。我们认识到，安全仍是核心，但规则已变，需要行业共同努力，通过自动化、策略和前瞻性准备，构建一个透明、可信且面向未来的云原生生态系统。

016：KubeCon 2024 颁奖典礼 🏆

在本节课中，我们将一起回顾 KubeCon + 云原生峰会 2024 颁奖典礼的核心内容。我们将了解年度杰出终端用户奖的得主，并认识那些在 CNCF 社区中做出卓越贡献的个人。课程将重点介绍奖项类别、获奖者及其贡献，帮助你理解开源社区如何认可和激励贡献者。

宣布年度杰出终端用户奖

现在，是时候宣布我们的年度杰出终端用户奖了。

这些奖项的评选依据是，我们的社区提交的、作为 CNCF 成员的组织的贡献及其所做的事情。

在本次 KubeCon 之前，我们通过提交流程选出了三家终端用户。

获奖者名单

以下是本次奖项的获奖者名单。

第三名：Reddit
- 该平台支持数百万日活跃用户。
- 每月处理数十亿次页面浏览量。
- 他们为我们提供了宝贵的见解，例如关于 Piday 服务中断事件的分享，既包括遇到的问题，也包括成功的经验。
- 非常感谢 Reddit 成为一个分享、学习和欢笑的优秀平台。
第二名：Capital One
- 它是首批完全迁移到云端的美国主要银行之一。
- 为我们贡献了像 Cloud Custodian 这样的项目，提供了在生态系统中保持整洁的方法。
第一名：Adobe
- 该公司远不止让我们能够打印 PDF 文件。
- 它在我们的社区中一直扮演着出色的角色。
- Adobe 的使命是通过数字体验帮助世界改变世界。
- 其开发者平台团队致力于帮助 Adobe 的开发人员更快地编写更好的软件。
- CNCF 社区提供的工具、专业知识和能力是他们服务开发者的核心。
- 例如，Kubernetes、Argo、Backstage、Prometheus、Otel、Envoy 等技术是他们实现使命的基础。
- Adobe 团队已向 CNCF 社区贡献了超过 5000 次提交，涉及 70 多位开发者和 46 个不同的项目。

Adobe 在今年早些时候还制作了一份终端用户历程报告，并于夏季发布。这份报告更多地讲述了组织为何加入 CNCF、他们在开源领域做什么以及背后的意图。

社区贡献者奖项

接下来，我们将目光转向社区贡献者奖项，这是为了表彰那些在社区中超越常规职责、做出突出贡献的个人。

CNCF 拥有全球最大的开源社区之一，拥有超过 25 万名贡献者，为 200 多个项目做出贡献。社区本身是 CNCF 最重要、最有价值的“项目”。

主要奖项类别

以下是本年度的主要社区贡献者奖项类别。

顶级维护者奖
- 维护者是 CNCF 项目的生命线，他们辛勤工作在各类项目上。
- 本年度的获奖者由现有维护者投票选出。
- 获奖者：Joe Stringer
顶级文档贡献者奖
- 开源不仅仅是代码，优秀的文档对于项目至关重要。
- 今年我们新增了此奖项，并亲切地称之为“Aureem Ipsom 奖”。
- 获奖者：Kumming 和 Haifeng Yao
技术咨询小组贡献奖
- CNCF 设有技术咨询小组，专注于存储、网络、贡献者战略等特定领域。
- 此奖项旨在表彰 TAG 中的杰出贡献者。
- 获奖者：Nancy To
“劈柴挑水”奖
- 此奖项旨在表彰在项目中从事幕后基础工作的贡献者，例如改进构建时间、优化基础设施等。
- 获奖者：Stean Schinsky, Ali O, James Sperin, Prianka Sago, Sania Pananvara, William Roso
“迁移与提升”特别奖
- 这是一个一次性的特别奖项，旨在表彰多年来为 Kubernetes 项目基础设施做出巨大努力的团队。他们确保了社区管理和运行的构建过程，并改进了二进制分发的 CDN，使其能在多提供商上运行。
- 获奖者：Tim Hawkin, Erin Cririckenberg, Ben Elder, Arno Dis, Man Alili, Rickysdiski, Michelle Shepherderson, Coryelske, Tque Marco, Justin Santao, Barbara Cobaagner, Caleb Woodwine, Hpie, Linus Arvar
终身成就奖
- 今年是 Kubernetes 十周年和 CNCF 九周年，因此首次设立了此奖项，以表彰长期在社区中产生巨大影响的贡献者。
- 获奖者：Tim Hawkin
  - 他在 Kubernetes 和 CNCF 领域产生了巨大的影响。
  - 他感谢社区中数百名共同维护者、SIG 负责人和项目运营者。
  - 他认为正是成千上万的贡献者让这个项目充满活力与卓越。

总结与展望

本节课中，我们一起学习了 KubeCon 2024 颁奖典礼的主要内容。

我们首先了解了年度杰出终端用户奖，获奖者 Reddit、Capital One 和 Adobe 都展示了如何利用云原生技术处理大规模业务并积极回馈社区。接着，我们回顾了多项社区贡献者奖项，从顶级维护者到终身成就奖，这些奖项全面认可了代码贡献、文档工作、基础设施维护及长期领导力等不同维度的卓越贡献。

这些奖项和获奖者的故事共同印证了 CNCF 社区的核心精神：协作、共享与持续创新。正是每一位贡献者的付出，共同构筑了这个充满活力的生态系统。期待在未来的 KubeCon 上看到更多精彩的成就和贡献。

018：与最终用户共创高峰——Taylor Dolezal

概述

在本节课中，我们将跟随Taylor Dolezal在KubeCon+云原生峰会2024上的演讲，探讨最终用户如何与云原生生态系统共同成长，克服挑战，并了解CNCF最终用户技术咨询委员会（TAB）为支持这一旅程所推出的新工具和倡议。

置身云端之上

盐湖城，一个海拔如此之高以至于我们客观上置身于云端之上的地方。

我们的视角变得“元”化，因为我们正在俯瞰我们生态系统中发生的精彩事情。

我注意到这里有点冷，当我走过走廊时，我发现人们穿的衣服层数比OSI模型还多。那是七层。

这是一个网络笑话。好了，跟我回到篝火旁，暖和一下。今天，我想讲几个故事。我想问你们几个问题，然后我们会讲到更多的故事。

你的第一座“山”是什么？

如果你有机会看看这座城市的天际线，你会看到一些山脉。这很难被忽视。当你看着那些山，并真正让它触动你时，它会触及你的内心深处。如此巨大的事物。

也许你是那种看着顶峰并说“我想攀登它，我想去冒险”的人。但当你思考如何真正实现它时，这不是一件十分钟就能完成的事情，它需要计划，可能需要带水，需要合适的工具，可能不想独自前往。

今天我的第一个问题是：在这个生态系统中，你的第一座“山”是什么？

是你今天正面临的吗？是你目前工作中正在经历的吗？你正在试图解决一个可能没有明确答案的问题吗？

我的第一座“山”，毫无疑问，是Kubernetes。我当时在克利夫兰的医疗保健行业工作，进行容器化，试图在Ruby on Rails或Go中做出正确的决定。这并不简单。这是一次相当艰难的攀登。

当我查看科技新闻，听到所有关于编排工具和运行时的争论时，我很幸运，因为我有一个非常擅长沟通的团队。但我们总是想知道，我们是否遵循了最佳实践？我们做对了吗？

直到我参加了一次线下聚会，第一次亲眼看到Kubernetes，我才明白过来。在我准备这些幻灯片时，我才意识到，我第一次听说Kubernetes实际上是在一艘船上。所以如果这不是一个预兆，我不知道什么才是。它永远在我的职业生涯中掀起了波澜。

找到答案的感觉很好。但是，当你试图攀登生活中的那些山峰时，即使你能看到远处的顶峰，当你身处其中时，真正重要的是下一步。在艰难、污垢、岩石、冰雪中，总是下一步。如果不试图了解周围的环境，可能很难看清下一步是什么。

共同攀登：CNCF的角色与挑战

在CNCF，基金会为我们提供了一个地方，让我们能够分享在攀登过程中发现的所有知识。

在本次KubeCon之前，我们提出了一些关于差距的问题。我们想了解什么仍然困难，哪里存在摩擦，这个生态系统中正在发生什么，我们面临的共同痛点是什么。

人们提到的最大的问题之一是安全性。仅仅拥有那些可用的功能和特性是不够的。这是一个关于配置的对话。几年前有效的方法，随着我们规模的扩大，不再继续有效。

复杂性是另一个问题，试图弄清楚这种互操作性，所有这些工具，如何将它们拼接在一起，以及如何将它们应用到你的组织和团队中所有的工作环境中。

现在，如果你一直关注CNCF全景图，那里有很多工具，有很多项目。但试图找出哪个是正确的，以及如何将它们分层组合在一起，同样可能很困难。

当你试图攀登一座山时，你可能会使用地图和指南针，这些东西可以在下一步没有意义时帮助你引导旅程。

知识是我们都能亲身体验的礼物，但它的真正价值在于我们能够广泛地彼此分享，进行批判性的对话，并真正探索这些事情。所以我的下一个问题是：我们如何一起登顶？

新工具：CNCF技术雷达回归

有个惊喜给你。经过三年的等待，我们有了另一个工具来帮助你理清你的全景图和旅程。

我们带回了CNCF技术雷达。我很兴奋。是的。在这个版本中，我们涵盖了多集群工作负载、AI/ML批处理。我在这里放了一些亮点，请，请，请拍照，查看一下。我想听听你的想法。我想听听在我们探索这一切时，还有哪些其他的陷阱和我们可以接下来关注的事情。

登顶之后：更多道路与资源

当你到达顶峰时，鼓舞人心、有趣、也许有点可怕的真相是，那仅仅意味着有更多的顶峰。在路的尽头，总有更多的路要走。

我们为你准备了东西，比如案例研究、数据、研究、教育、培训。有很多东西可以看。

接下来，我想邀请我们的最终用户TAB主席和副主席分享更多惊喜，关于他们为你准备的东西，以帮助你应对你正在穿越的这些“山峰”。

最终用户TAB的使命与工作

大家好，早上好，你们好吗？希望大家都过得很好。感谢大家今天加入KubeCon的第二天。我是Aza Sharma，我担任最终用户技术咨询委员会（也称为TAB）的主席。我非常高兴今天能和Heri一起与大家交流。

大家好，我是来自Intuit的Henry Blakeles，我是TAB的副主席。我们很高兴今天分享我们一直在做的工作，以加强最终用户与CNCF生态系统之间的联系。

最终用户TAB代表了CNCF生态系统中企业用户的声音。我们是一群来自不同行业组织的技术领导者，都积极使用云原生技术。

我们的使命是倡导最终用户的需求，并从最终用户的角度为CNCF社区提供技术指导。我们与TSC、项目维护者和更广泛的CNCF社区密切合作。

今年，在我们启动TAB的工作时，我们围绕三个工作组组织了我们的工作，这三个工作组专门致力于：

收集和发布参考架构。
为最终用户建立项目健康可见性的重要准则。
从最终用户那里获取项目反馈。

工作组成果展示

许多最终用户面临的一个挑战是如何驾驭复杂的云原生全景图，并将其转化为可以在生产环境中运行的东西。因此，我们有一个由Sergio Pejon和Gar Hens领导的工作组，创建了一个包含真实世界生产实现和用例的中心。这是一个最终用户可以找到参考架构、最佳实践、技巧和窍门的地方，了解其他公司在类似情况下什么有效、什么无效。

我想再谈谈项目健康可见性以及我们在那里所做的工作。我们一直与TOC密切合作，评估项目健康状况，并了解他们在进行评估时认为重要的参数。其次是制定对最终用户重要的指标并记录下来，我们关注的一些指标领域包括发布稳定性和节奏、文档质量、生产就绪度指标（这对我们所有人都很重要）以及安全响应。我们还与LF团队合作，他们正在开发项目健康记分卡的指标工具链。

TAB正在做的另一件事是增加最终用户和维护者之间的协作。我们有一个由Chad Bowdoin和Joseph Sandoval领导的工作组，一直在努力为最终用户和我们的项目之间创建更结构化的反馈渠道。我们致力于实施标准化的反馈模板，这将有助于我们在项目和最终用户之间建立可操作的、建设性的反馈。这将帮助我们建立更强大、互利的最终用户与维护者协作。

2024年成就与未来展望

我想重申我们在2024年真正取得的成就，我们为此感到自豪，因为你知道，我们今年最初是作为一个团队聚集在一起的，并且有一个优秀的团队一起工作。

我们已经确定参考架构对我们所有的最终用户都有价值，并且我们非常自豪地收到了来自Alis以及Adobe的贡献。如果你在寻找它们，我们稍后会分享URL。

我们取得良好进展的第二个领域是通过LFF Insights集成增强了项目健康可见性。

最后但同样重要的是，对我们来说非常重要的是让更多最终用户参与进来，增加最终用户在技术讨论中的参与度。

是的，我们今年做了很多令人兴奋的事情。我们有很多非常好的最终用户在这一年里帮助了我们，但我们希望你们中的更多人加入我们。有多种方式可以加入对话并帮助最终用户社区：你可以参与工作组；你可以与我们合作，将你的参考架构提交到中心；还有参与最终用户反馈会议等其他方式。

所以，请通过屏幕上闪过的二维码让我们知道你有兴趣。我点得太快了，但我们稍后会再次显示二维码。

我想，随着我们进入2025年，今年只剩下大约一个半月了，我们将继续致力于扩大参考架构的覆盖范围，我们将推出新的项目健康指标，所以请留意那些。我们还将致力于扩展最终用户反馈计划。同样，我们将围绕这些以及与TOC的技术协作发布博客文章和公告，并继续更多地与项目维护者互动。

最后但同样重要的是，这也是我们今年的主要重点，将继续致力于增长和持续增长最终用户的参与度。

好的，二维码又出现了。请拍照并加入对话。请加入工作组参与。如果你有一个与CNCF全景图任何部分相关的参考架构想要贡献，请不要害羞，给我们你的反馈。

谢谢大家。

总结

本节课中，我们一起学习了：

将云原生旅程比作登山：强调了规划、工具和协作的重要性。
识别共同挑战：安全性和复杂性是当前生态系统中的主要痛点。
利用CNCF资源：基金会提供了分享知识和经验的平台。
引入新工具：CNCF技术雷达的回归，旨在帮助用户导航技术选择。
最终用户TAB的核心作用：作为最终用户与项目维护者之间的桥梁，致力于：
- 建立参考架构中心。
- 定义对最终用户重要的项目健康指标。
- 创建结构化反馈渠道。
呼吁参与：鼓励更多最终用户加入TAB的工作组，贡献经验，共同塑造云原生生态系统的未来。

通过分享故事、提出问题并提供实用的新资源和倡议，本次演讲强调了社区协作对于克服挑战、共同攀登云原生“高峰”的关键作用。

019：第二天开场致辞

在本节中，我们将回顾KubeCon+云原生峰会第二天的开场环节，了解当天的核心议程与首位主讲嘉宾。

大家好，欢迎回到KubeCon+云原生峰会。

希望大家在昨晚的Kube Crawl和云原生派对上玩得开心。

想必各位已经迫不及待地想要开始我们下一系列精彩的主题演讲了。

那么，今天我们将再次启程。

在此，我很荣幸地向大家介绍今天的第一位主题演讲嘉宾。

他是生态系统负责人兼首席基金官Taylor Doolittle。

今天，他将带领我们一同探索CNCF生态系统，揭示最终用户的洞察、最终用户的进展以及云原生社区的协作力量。

让我们热烈欢迎Taylor上台。

在本节中，我们共同开启了KubeCon+云原生峰会第二天的议程，并介绍了首位主讲嘉宾Taylor Doolittle及其即将分享的关于CNCF生态系统的深度洞察。接下来的环节将深入探讨社区协作与用户实践。

021：从版本1到5的经验教训 🎓

在本教程中，我们将学习如何构建一个健壮的 Kubernetes Operator，特别是针对像 PostgreSQL 这样的有状态应用。我们将通过 Crunchy Data 在开发其 PostgreSQL Operator（PGO）五个版本过程中积累的经验，重点探讨高可用性、升级和灾难恢复这三个核心架构领域。我们将了解如何利用社区成熟方案、平衡自动化与风险，并构建一个既能应对故障又能预防故障的系统。

高可用性：架构演进与最佳实践 🛡️

上一节我们概述了本课程的核心内容，本节中我们来看看如何为 Operator 及其管理的应用设计高可用性。

任何应用在运行过程中都可能遇到故障或崩溃。通过使应用具备高可用性，我们确保其持续可用，这意味着在问题发生时能快速恢复，甚至更好的是从一开始就预防问题的发生。对于 PostgreSQL 而言，这意味着确保数据库以及用户的数据始终可访问。

在 Operator 的早期阶段，我们意识到需要考虑两种类型的高可用性：Operator 自身的可用性和数据库的可用性。我们确定数据库的可用性是最高优先级。

早期架构的挑战

在 PGO 的 1 到 3 版本中，我们在 Operator 内部构建了一个自定义的 PostgreSQL 高可用解决方案。Operator 负责通过利用 Kubernetes 的能力（如就绪探针）来确保数据库可用，例如在主数据库崩溃时提升一个副本。

然而，这个架构存在明显问题：

单点故障：只有一个 PGO 实例，如果它宕机，我们将失去所有 PostgreSQL 数据库的高可用能力。
事件处理瓶颈：所有 Operator 都使用队列机制来捕获和响应 Kubernetes 集群中的事件。如果多个数据库同时崩溃，它们将不得不排队等待处理，这对于需要快速恢复的数据库来说是灾难性的。

随着用户开始大规模部署 PostgreSQL，这些裂缝逐渐扩大。我们认识到需要一个新解决方案来支持大规模部署。

向成熟社区方案演进

在 PGO V4 中，我们转向了 PostgreSQL 生态系统中一个久经考验的解决方案：Patroni。这提供了所需的去中心化架构，以缓解我们原始架构在规模操作时出现的问题。

与此同时，Operator 生态系统的发展使得 Operator 自身的高可用变得简单。通过切换到 controller-runtime 项目（一套用于构建 Kubernetes Operator 的库），添加高可用性减少为一项配置更改。

核心经验：PostgreSQL 和 Kubernetes 生态系统的发展，特别是 Patroni 和 controller-runtime 项目，是实现 Operator 和数据库所需高可用解决方案的关键。

预防优于应对

我们学到的另一个重要经验是强调预防而非仅仅准备。虽然我们希望对故障有所准备，但更好的是一开始就防止故障发生。

通过利用 Kubernetes 卷扩展能力，我们可以防止管理数据库时最常见的错误之一：存储空间耗尽。这是一个在故障发生前就将其预防的绝佳例子。

公式/代码示例：虽然 Kubernetes 自动扩展 PVC 的细节由存储驱动，但概念上，Operator 可以监视 PVC 的使用情况，并在达到阈值时调用 Kubernetes API 进行扩展。

# 概念性示例：Operator 检测到 PVC 使用率 > 80% 后执行的补丁操作
kubectl patch pvc my-postgres-pvc -p '{"spec": {"resources": {"requests": {"storage": "2Gi"}}}}'

升级策略：自动化与风险控制 🔄

上一节我们探讨了如何确保系统持续可用，本节中我们将看看如何安全地对系统进行升级，包括 PostgreSQL 和 Operator 本身。

升级包括 PostgreSQL 的主版本和次版本升级，以及 Operator 的主次版本升级。在 PGO 1 到 3 版本中，Operator 并未直接处理升级，这是一个手动过程。在 Patroni 处理了数据库高可用性后，我们腾出了开发时间来专注于新功能。

自动化滚动更新

我们实现了一个完全自动化的滚动更新策略，可以推出 PostgreSQL 次版本升级。对于 PGO 自身，通过避免在我们的 API 中引入破坏性变更，PGO 升级也可以通过相同的策略推出。

然而，PostgreSQL 的主版本升级则不同。使用无效的升级配置或镜像可能导致严重的停机时间，而兼容性问题也可能破坏现有的数据库客户端。

平衡自动化与用户控制

在审视各类升级时，我们必须确定在哪些场景下适合完全自动化升级，在哪些场景下适合让 Operator 引导用户完成升级。

以下是 PGO 采用的两种策略：

完全自动化的滚动更新流程：处理用户日常需要应用的大部分变更。
- Operator 自身升级。
- PostgreSQL 重新配置和更新到新的次版本。
- 修改 PostgreSQL 数据库的 Pod 规约（例如，添加自定义边车）。
PostgreSQL 主版本升级流程：使用 API 中的 状态（Status） 和 条件（Conditions） 来引导用户完成升级步骤，并提供足够的透明度，使用户能够自行自动化该过程。

核心经验：

管理升级自动化的风险：仅在风险可控时进行自动化。
赋能用户：当我们无法完全自动化时，使用状态和条件来赋能用户，让他们能够编排和自动化升级过程。

代码示例：主版本升级 API 的状态字段可能如下所示：

status:
  conditions:
  - type: UpgradePending
    status: "True"
    reason: ClusterNotShutDown
    message: "PostgreSQL cluster must be shut down to proceed."
  - type: Progressing
    status: "False"
    message: "Upgrade has not started."

灾难恢复：聚焦恢复与数据流动性 🚀

上一节我们讨论了如何平稳升级系统，本节我们将探讨如何在灾难发生时恢复系统，并确保数据的可移动性。

任何系统都有可能在某些时候经历灾难。当灾难发生时，您需要有一个到位的流程来快速恢复。这就是灾难恢复的全部意义：建立并演练流程和技术解决方案，以确保您的关键应用持续运行。

对于 PostgreSQL，这意味着确保用户和应用程序能够根据恢复时间目标（RTO）访问关键数据。RTO 指的是数据库在恢复之前可以离线的时间量。

超越备份：聚焦恢复场景

Crunchy Data 在灾难恢复方面的经验告诉我们，一个有效的灾难恢复策略不仅仅是创建备份。真正重要的是恢复场景。换句话说，如果备份不能用于满足我们的恢复目标，那么它们的价值就很小。

架构选择：融合生态优势

我们面临一个重要决策：是使用 PostgreSQL 生态系统中久经考验的灾难恢复解决方案来满足我们的恢复需求，还是围绕 Kubernetes 原生能力（例如通过 Kubernetes API 创建卷快照）来构建解决方案。

我们当前的灾难恢复架构核心是 PostgreSQL 生态系统中的一个灾难恢复解决方案：PGBackRest。我们可以为其附加不同类型的存储来管理备份，无论是 Kubernetes 集群内的本地持久卷，还是各种类型的云存储。

PGBackRest 与 Kubernetes 卷快照的结合使我们能够：

使用多种存储类型进行备份。
轻松访问数据以创建备用集群和克隆。
利用 Kubernetes 卷快照进一步减少创建克隆所需的时间。

核心经验：

聚焦恢复而非备份：备份很重要，但只有当它们支持您的恢复目标时才真正有意义。
灾难恢复实现数据流动性：通过在您需要的地方（包括跨云和 Kubernetes 集群边界）进行备份，不仅可以增加备份的冗余度，还可以在需要的地方配置所需的数据库。
利用 PostgreSQL 原生方案安全使用 Kubernetes 原生方案：PGBackRest 和 Kubernetes 卷快照的结合使我们能够创建无损坏和其他问题的快照。

总结与最终思考 📝

在本节课中，我们一起学习了构建 Kubernetes Operator，特别是在高可用性、升级和灾难恢复方面的关键经验。

让我们回顾并总结在 PGO 中为每个领域实施的当前解决方案以及学到的宝贵经验：

高可用性

解决方案：使用 Patroni 实现 PostgreSQL 高可用；使用 controller-runtime 实现 Operator 高可用；使用 Kubernetes 卷扩展自动增长磁盘。
经验教训：
1. 去中心化架构支持规模化。
2. 克服“非我发明”综合征，拥抱社区现有方案。
3. 预防优于应对。

升级

解决方案：使用安全的滚动更新策略处理配置变更、PostgreSQL 次版本升级和 PGO 升级；为 PostgreSQL 主版本升级创建新 API，使用状态和条件引导用户。
经验教训：
1. 管理升级自动化风险，仅在风险可缓解时自动化。
2. 当无法自动化时，使用状态和条件赋能用户进行编排和自动化。

灾难恢复

解决方案：使用 PGBackRest 实现多云备份、恢复功能和数据流动性；使用 Kubernetes 卷快照支持恢复时间目标。
经验教训：
1. 聚焦恢复而非备份。
2. 强大的灾难恢复方案能够实现数据流动性。
3. 使用 PostgreSQL 原生方案来安全地利用 Kubernetes 原生方案。

关于 Operator 开发的思考

如果您正在考虑为您的应用创建 Operator，虽然没有简单的答案，但对于 PostgreSQL 来说，Operator 是一个绝佳的选择。如果您正在以我们今天讨论的某些方式努力管理应用的复杂性，或者这种复杂性正在给您的用户带来挫败感，那么 Operator 值得考虑。

由于 Operator 由与核心 Kubernetes API 相同的构建块组成，它们也提供了可应用于 Kubernetes 本身开发的实践经验和知识。自 2017 年以来，Kubernetes 已经发展成为一个适用于所有类型应用（包括有状态应用）的成熟稳定平台。现在正是构建 Operator 的最佳时机。

022：通过原则性平台抽象演进Reddit的基础设施

在本节课中，我们将回顾Reddit基础设施在过去几年中的演进历程，重点探讨如何通过基于Kubernetes控制平面的原则性平台抽象和自动化来应对挑战。我们将从2022年的状态出发，介绍构建平台所遵循的核心原则、具体实践、取得的成果以及未来的方向。

2022年的Reddit基础设施状态

在深入探讨解决方案之前，我们首先需要了解问题的起点。2022年，Reddit在组织内部和产品外部都经历了显著增长，这给基础设施带来了巨大压力。

我们当时正朝着IPO迈进，并开始将服务范围扩展到多区域，最终目标是实现全球扩张。此外，公司还在广告和机器学习技术栈上进行了大量投资。到2022年底，我们拥有约20个Kubernetes集群，这些集群虽然位于同一云服务商的同一区域，但各自为政，缺乏统一管理。应用工程师与基础设施工程师的比例约为7:1，大部分运维工作依赖手动和“白手套”式服务，效率低下。

遗留基础设施的痛点

为了理解旧有基础设施的弊端，让我们通过两个最基础的例子来审视当时工程师面临的挑战。

应用工程师的视角：创建命名空间

对于Reddit的每一位应用工程师来说，启动新应用的第一步通常是创建一个Kubernetes命名空间。然而，这个过程异常繁琐。

以下是当时的典型流程：

选择工具：工程师需要在Helm Chart或Kustomize文件之间做出选择，但这些工具对于非Kubernetes专家的应用工程师来说既复杂又陌生。
复制粘贴：提交的拉取请求（PR）内容大多是各处复制粘贴而来，或者是从旧配置中“抓取”的。
漫长评审：PR会进入评审队列，由于服务等级协议（SLA）的限制，这可能需要长达24小时。由于评审多是手动的，错误时常被放过，导致部署失败。
自行调试：所有这些复杂性都没有对用户抽象。如果持续集成（CI）失败，应用工程师可能需要基础设施工程师协助调试，整个过程又得重来一遍。

因此，仅仅创建一个命名空间就可能因为时区差异和流程问题耗费近一周时间。这导致了跨集群命名空间管理的巨大不一致性，我们无法理清命名空间的来源或是否仍在使用。出于安全考虑，我们不得不禁用所有对命名空间的自动化删除操作，这又导致了大量废弃资源残留，增加了成本和事故排查的难度。

基础设施工程师的视角：管理Kubernetes集群

上一节我们看到了应用工程师的困境，对于基础设施工程师而言，世界同样痛苦。

创建和管理一个符合Reddit标准的Kubernetes集群是一个超过100个步骤的“庞然大物”，即使是经验最丰富的工程师也需要超过30个主动小时（通常相当于一周的墙上时间）才能完成。升级集群是通过在现有控制平面节点上手动执行kubeadm命令完成的，这是一种危险的做法。而注销集群则根本没有标准流程，因为随着时间的推移，各个集群已经变得“特化”和“定制化”。

为什么集群会变得如此特化？一个主要原因是当时我们没有好的方法来管理整个集群舰队的配置。我们陷入的反模式是：为每个集群复制粘贴一次配置清单。你可以想象，这些配置会随着时间推移而逐渐漂移。有时漂移如此严重，以至于我们称这些基础设施为“闹鬼的”——意思是任何工程师都很难有信心推断集群应该如何或实际如何运行，这使得所有生命周期操作都变得极其危险。2022年3月14日的一次重大停机正是由此原因导致。

核心原则：什么是原则性平台抽象？

面对上述循环，我们如何破局？答案是转向平台抽象的概念。

抽象：指隐藏底层复杂性，将用户的关注点与底层实现的关注点分离开来。一个好的抽象标志是，它使用户无需了解底层领域知识就能理解和操作。
平台：指一个由可组合工具构成的生态系统，使用户能够在其上构建。平台的用户体验是首要关注点，它应该是安全、可靠、可扩展且没有“陷阱”的。
原则性：在这里意味着“有主见的”。我们为工具设定了特定的目标用户画像，并使用平台作者认为的最佳实践来实现。同时，“原则性”也意味着标准化，即每个问题都有且仅有一种解决方案。

我们使用由Kubernetes控制过程支持的声明式API来实现这些平台抽象。接口被定义为自定义资源（CRD），我们遵循标准的Kubernetes资源模型约定：期望状态在spec中定义，观测状态通过status报告。这些自定义资源会驱动Kubernetes控制器，通过将实际状态向期望状态转变来实现其API。

为什么选择Kubernetes控制器而非传统IaC？

你可能会问，为什么选择Kubernetes控制器，而不是传统的基础设施即代码（IaC）？这两种方法各有优劣。

传统IaC（如Terraform）的优势在于前期工程成本低，工程师编写声明式配置并选择何时应用变更，心智模型简单，且给予工程师高度的控制权。

然而，它也存在显著短板：

无法建模复杂业务逻辑：例如，难以建模“从CA机构申请TLS证书 -> 上传到AWS证书管理器 -> 附加到负载均衡器”这样的工作流。
非程序化消费：通常为人工操作设计，难以通过代码填补业务逻辑缺口。
非动态行为：无法自动续期即将过期的证书，需要手动或定时触发。
“发射后不管”的驱动模式：容易导致状态漂移，增加系统处于错误状态的风险。

我们选择Kubernetes控制器，是因为我们追求：

自愈能力：确保实际状态最终与期望状态一致。
强大功能：平台API配置表面简单，但功能强大，这要求实现者能编写任意逻辑，包括完整的生命周期管理。
可编程性：基础API可以被其他平台复用和消费。

当然，这种选择代价高昂：需要构建和维护生产级自动化代码，心智模型更复杂（持续协调过程），并且失控的自动化可能比一次糟糕的IaC应用造成更大的破坏。但总体而言，我们认为这个权衡是值得的。

新架构：多集群管理与统一控制平面

之前提到，跨舰队管理配置是工程师们的主要负担和复杂性的来源。如今，我们通过一种为工程师提供“单一管理面板”控制的多集群API方法解决了这个问题。

我们的舰队中有两种类型的集群：

编排集群：作为“大脑”，决定所有其他集群的行为，并为它们生成配置。
工作负载集群：是可替换的“牲口”，托管我们的应用程序，为公司提供大部分计算能力。它们从编排集群拉取配置。

基于此架构，我们可以构建多集群API。每个工作负载集群都由一个自定义资源支持，并被打上标签（如环境、地域、云厂商）。然后，我们使用联邦CRD，通过Kubernetes标签选择器来分组集群。多集群API（如MultiClusterNamespace）则绑定到联邦对象，以此来表达“将我的配置应用到这组集群”。

这种方法最强大的特性之一是集群目标是动态的。例如，如果我启动一个带有phase=test标签的新集群，相应的命名空间会自动在其中创建。这为工程师节省了大量时间，意味着我们可以快速部署具有明确定义属性的新集群，所有适用的配置都会自动流入，无需额外手动工作。

当然，任何集中式架构都有风险，编排集群可能成为单点故障。目前，我们通过确保系统静态失效来管理此风险：即使编排集群与工作负载集群之间出现网络分区，或者编排集群完全宕机，工作负载集群只是无法接收配置变更，但由于它们已经拉取了所有指令的本地副本，它们能够持续自我修复已有的状态。

实践案例一：全新的命名空间管理

现在，让我们回到最初的两个案例，看看新世界是怎样的。首先，我们重新审视Kubernetes命名空间这个核心需求。

现在，用户无需在Helm或Kustomize之间切换，只需创建一个名为RedditNamespace的自定义资源，并将其指向一组集群（联邦）。一旦应用到编排集群，每个被该联邦选中的工作负载集群都会拉取本地副本并协调它，从而创建命名空间以及所需的任意资源（如RBAC权限）。我们还可以利用这个机会与Slack、PagerDuty等第三方软件或内部部署系统集成，以创建自动告警或正确的权限。

这种设计的简洁性和有主见性体现在：用户无需提前知道他们需要哪些具体的Kubernetes资源。我们只提供两个选项：operator（读写权限）或reader（只读权限）。这不仅向用户抽象了复杂性，也帮助基础设施团队缩小权限范围，确保安全性和合规性。

实践案例二：一键式集群供应

同样地，对于Kubernetes集群的管理也发生了翻天覆地的变化。

现在，我们只需提交几个包含RedditCluster CR的拉取请求，就能创建Kubernetes集群。我们大量依赖Cluster API来启动控制平面。但更重要的是，CRD模型给了我们简化接口的机会。Cluster API功能强大，但配置项繁多。我们的简化设计强制只暴露有限的可配置项，防止集群像过去那样过度偏离并变得“闹鬼”。

此外，一旦控制平面启动，我们的自动化流程会将这个“原始”的Kubernetes集群转变为一个“Reddit化”的集群——即安装了所有托管Reddit应用所需的先决条件和依赖项。这种“一键式”供应在以前以Terraform为主的IaC方法中是极难实现的，因为它有严格的顺序要求。简化也降低了基础设施工程师在创建集群时的认知负荷。

赋能团队：Achilles SDK

上述两个例子是计算团队构建的初始平台抽象。但为了全面拥抱自动化未来，我们不仅希望自己构建平台抽象，更希望赋能整个基础设施组织都这样做。

于是我们构建了Achilles SDK。该SDK构建在controller-runtime之上，旨在让基础设施工程师能够专注于业务逻辑，而无需成为底层Kubernetes专家。

其核心特性是将整个协调循环表示为一个有限状态机（FSM）。在典型的controller-runtime中，你需要在一个庞大的Reconcile函数中编写所有逻辑，随着控制器变复杂，这个函数会变得极其复杂和庞大。我们发现，为协调逻辑定义有限的状态及其转换，使得推理、调试和扩展都变得更容易，这对于生产化至关重要。

SDK的名字“Achilles”源于希腊神话，是为了提醒我们，所构建的自动化极其强大，但若不谨慎，也可能极具破坏性，我们不想让自动化成为“阿喀琉斯之踵”。

SDK简化了与API服务器的交互接口，自动处理子资源的所有权和清理，并自动跟踪所有子资源及每个FSM状态的状态条件，这在事故排查时提供了极大的可见性。我们已经将Achilles SDK开源，希望与更广泛的生态系统分享。

成果与现状

我们从2022年的困境出发，如今已借助原则性平台抽象迈向了一个更好的世界。

对于应用工程师，用户体验显著提升。以命名空间为例，底层领域复杂性被隐藏，使得整个平台更具自助服务性和可扩展性。对于基础设施工程师，这降低了认知复杂性，减少了日常琐事，也因更少的人工接触点而使系统更安全。有主见的平台抽象也强制了集群和应用栈的一致性，使其更易于推理。

截至目前，开发者已能自助管理Kubernetes命名空间，在35个以上的集群中拥有超过1000个命名空间，且数量每季度都在增长。新集群的启动时间缩短到2小时以内，升级时间约1小时。我们能够在保持约10:1（应用工程师:基础设施工程师）比例的同时，应对全球扩张等更具挑战性的问题，并将更多工程时间用于主动解决问题，而非被动救火。

借助Achilles SDK，一个从未编写过控制器的人将其想法转化为最小可行产品（MVP）的时间少于两周。我们今年初仅有4个由计算团队编写的生产级Kubernetes控制器，如今已增加到12个且仍在增长，它们管理着包括集群、Ingress、Redis、Cassandra、Vault等在内的核心基础设施组件。

何时以及如何实施自动化？

在整个演示中，我们论证了自动化的优点，但必须明确，自动化应有充分的理由。在以下情况下，自动化可能没有意义：

无模式可循：首先要问，用例或解决方案是否已经或能够收敛？我们使用80/20启发法：如果80%的用例已统一，就很可能是自动化的目标；剩余的20%可以通过白手套流程或应急接口处理。
投资回报率（ROI）不足：考虑到构建自动化的高昂成本，主要的决策点是ROI。计算给定流程的预期成本（工程小时数 × 使用频率），然后与自动化的预估投资进行比较，判断长期是否能节省团队时间。

总结与核心要点

本节课我们一起学习了Reddit如何通过原则性平台抽象演进其基础设施。我们来回顾一下核心要点：

自动化带来运营效率：它使基础设施团队能够在公司高速增长和大规模运营时期提供有效支持。
平台抽象实现关注点分离：允许应用工程师和基础设施工程师各自专注于最擅长的工作。
Kubernetes作为通用控制平面：Kubernetes不仅可以作为容器编排器，还可以作为管理基础设施所有方面的通用控制平面。

当公司发展到一定成熟度时，它们需要平台抽象来高效运营，尤其是在增长时期。希望Reddit的经验能为你提供有价值的见解。

023：从混沌到和谐 🚀

概述

在本教程中，我们将跟随丹麦媒体集团JP/Politikens Hus的AI团队，学习他们如何将机器学习工程从最初的混乱状态，通过采用Kubernetes，转变为和谐、高效的工作流程。我们将重点探讨其平台演进的动机、面临的挑战、关键决策以及最终的技术栈实现。

章节 1：项目起源与初始目标 🎯

感谢各位的到来。今天我将分享我们团队以及JP/Politikens Hus媒体集团如何为AI团队引入Kubernetes的故事。

这一切始于我所在的部门，名为“Ekstra Bladet”。它是丹麦最大的新闻媒体之一，每月拥有超过150万独立读者。

在2021年2月，我们意识到需要更加专注于机器学习。同时，我们也需要构建一个平台，以便向读者提供更相关的内容。为此，我们计划构建一个定制化的推荐系统。

为了实现这一目标，我们组建了一个由4名机器学习专家组成的团队，他们将成为该平台的主要用户。此外，我们还有4名基础设施工程师，负责根据机器学习专家的需求来构建这个平台。

我们参与了丹麦的一个研究项目，因此需要这个平台能够支持不同机器学习模型的快速原型设计。该平台应能帮助我们快速测试、训练和部署模型。

由于团队规模较小，我们在项目开始前没有进行大量的前期研究。我们必须利用已有的内部知识，并以最佳方式运用这些知识。

章节 2：初始平台的设计原则与挑战 ⚙️

上一节我们介绍了项目的起源，本节中我们来看看初始平台的设计原则和随之而来的挑战。

确保平台简单易用至关重要，这样机器学习专家才能轻松地训练模型。同时，拥有一种简单的方式来自动化部署模型服务，并用新版本替换当前运行版本，也同样重要。

机器学习专家应能创建模型原型，并能够使用不同的框架，如PyTorch和TensorFlow。保持机器学习专家原有的工作流程不变非常重要，因为我们不希望被锁定在某个特定框架上。

机器学习专家应能自行设置模型训练，并选择他们希望的部署方式。确保不因基础设施团队而受阻也很关键。

由于当时我们没有测试环境，因此机器学习专家能够快速发现模型训练失败时的任何问题，这一点非常重要。我们没有几个月的时间进行前期研究，所以我们希望对机器学习平台拥有完全的控制权，并且希望速度非常快。

我们还希望节省处理潜在错误和安全风险的时间，因此决定使用托管资源。这样一来，我们的基础设施工程师可以避免“午夜惊魂”——在半睡半醒的状态下调试生产环境可不是件有趣的事。

章节 3：混沌的显现与局限性 🌀

初始平台的设计带来了一定的自由度，但混沌也随之而来。起初，我们脑海中有一个清晰的版本构想。但随着时间的推移，基础设施变得越来越复杂，越来越难以管理。

对于新团队成员来说，理解平台运行机制和使用方法变得更具挑战性。本应非常简单快速的变更部署，变成了漫长而复杂的流程，更新变得非常困难。

我们最初珍视的自由度开始逐渐消失。由于团队中只有两名基础设施工程师，我们需要更多地依赖托管资源，并接受由此带来的权衡。

我们的机器学习专家在如何训练和部署模型方面面临着严格的限制。这导致即使是小问题也可能变成需要巨大努力才能修复的挑战。

测试与模型无关的新软件也成为一个挑战。例如，如果模型训练需要某种特定软件，我们无法提供这种灵活性。

为了改变我们的机器学习平台，我们需要理解云服务商的资源、基础设施即代码以及资源之间的连接方式。在进行任何更改以避免破坏现有功能之前，必须理解平台设计和真实流程。

使用云服务商时，在选择计算资源时总会有额外开销，因为你无法精确选择所需的处理器和内存量，必须接受最符合需求的实例类型。这导致了未使用资源的浪费，从而带来更高的云成本和更多的碳排放。

章节 4：经验总结与新平台的需求 📝

我们从平台的第一版中学到了很多。机器学习专家注意到了这个平台的几个有价值之处。即使平台并不完美，它也能很好地工作。

限制机器学习专家对基础设施的访问，并设定清晰的使用平台指南，带来了巨大的帮助。它加快了工作流程，使他们能够专注于开发，而无需学习整个基础设施。

对机器学习平台拥有完全控制权是一个巨大的优势。它使我们能够快速识别和管理潜在错误，并在需要时获得基础设施团队的故障排除协助。

我们的机器学习专家欣赏所有组件（包括不同框架和编码标准）的平滑集成。这使我们能够快速行动，更快地部署模型，实现团队原型设计和更好的工作方式。

但我们需要重新思考构建机器学习平台的方式，专注于我们最需要的部分，以及在哪里可以简化流程以更好地支持机器学习专家和工程师。

我们选择基于现有平台的经验构建一个新平台，不是因为现有平台无法工作，而是因为它无法完全满足我们获得的新需求。

我们仍然需要专注于拥有一个稳定的平台，使其不需要基础设施团队投入过多关注。任何延迟都可能拖慢机器学习工作流程，这是我们无法接受的。

我们希望专注于现有机器学习平台的优势，并解决我们面临的挑战，以满足新的功能需求。我们的团队正在壮大，新的需求不断出现，我们希望拥有一个更用户友好的平台，不需要博士学位也能完成日常工作。

专注于前三点，很明显，我们的团队需要比现有平台更高的灵活性，例如更快的部署周期和更简单的部署流程。

章节 5：第二次尝试与未解决的问题 🔄

那么，我们学到了什么，并决定再试一次呢？我们解决了一些挑战，但没有解决主要问题，例如测试工具、改进软件测试、更快的部署。在 onboarding 新成员时，我们仍然遇到一些问题。

即使采用了新方法，我们仍然专注于通过继续使用托管资源来拥有一个稳定的平台。我们没有获得想要的完全灵活性，但这使得机器学习工程师和专家更容易进行日常工作。

我们未能通过让他们选择自己的工具和测试新软件来解决问题。因为我们从现有版本中采用了配置方法，所以这里没有太多改变。我们使用了 helm 和通用的文件配置，这要求每个开发人员都需要阅读文档（而这些文档基本上不存在）。这意味着 YAML 文件中的一个错误语法很容易导致问题。

有一天，我们得知我们将成为整个公司的完整AI部门，服务于丹麦JP/Politikens Hus媒体集团内不同公司的约1700名员工。从那天起，我们明白必须重新思考整体战略。之前在Ekstra Bladet，我们支持大约220名员工。现在我们团队增长到15人，并有责任支持1700名员工。

我们迅速理解了新形势的价值，进行了讨论，概述了当前状况，制定了后续步骤，并为团队设定了支持新现实的方向。

章节 6：关键决策：为何选择Kubernetes？🤔

是时候开始升级并重新思考一切了。我们需要问自己：我们应该再次尝试从头构建，还是应该使用市场上现有的机器学习产品？如果我们选择Kubernetes，会得到什么好处？

尝试构建和维护一个全新的机器学习平台将消耗大量额外资源，而且我们不确定是否能获得机器学习专家真正想要的自由和灵活性。因此，我们决定不再尝试这条路。

市场上有许多工具可以帮助机器学习专家。我们花了很多时间测试不同的产品，如MLflow和Metaflow。我们主要担心被供应商锁定。

为了赋予机器学习专家使用Kubernetes的自由，他们将能够访问所需的任何工具。这种方法建立了一定的信任，展示了我们如何相信他们的技能和决策，而不是强制执行严格的规则。

如果我们不得不选择一个现有的机器学习平台，我今天就不会在这里与大家分享这段旅程了。你可能会惊讶我们没有选择市场上现有的机器学习平台，原因如下。

我们比较了投入和收益，发现基于我们的测试，使用现有平台可能带来不同的挑战，而非我们期望的收益。

当我们选择现有平台时，遇到了问题：我们没有真正的控制权；收到了破坏工作流程的意外更新；机器学习专家感到沮丧；一些供应商似乎更热衷于销售企业许可证，而不是帮助社区版进行更新后的修复；由于整个过程缺乏灵活性和透明度，通常很难理解发生了什么；新员工如果不了解该应用程序，会发现很难学习如何工作，这给本已复杂的堆栈增加了更多不必要的复杂性，而这正是我们试图减少的。

我们选择Kubernetes并不是因为它更便宜，更多的是因为它提供了我们真正需要和缺失的东西。

章节 7：Kubernetes带来的变革与收益 🌟

选择Kubernetes后，我们获得了远超预期的收益，这已成为我们今天运营中非常重要的一部分。

我们获得了一种简单的方式来分配所需的资源（如处理器和内存），从而降低了成本和碳排放。我们现在可以简化开发流程，帮助他们更快地识别和修复问题。

Kubernetes允许机器学习专家尝试不同的软件和框架，而不会破坏任何正在运行的程序，从而允许他们快速测试新想法，而无需等待整个基础设施团队。

由于我们现在拥有标准化的流程和清晰的文档，我们的机器学习专家可以快速学习所需的环境。这使得入职过程非常快，帮助他们更快地开展项目，并降低了学习曲线。

通过简化流程和降低复杂性，我们的目标是让机器学习专家专注于开发和测试，而不是陷入基础设施的困境。

在我们的基础设施中使用GitOps实践，允许机器学习专家快速发布新软件，而无需担心破坏现有应用程序。轻松地从日志中部署和理解失败的原因或结果，不再令人沮丧。如果我们耗尽资源，Kubernetes会根据需要自动扩缩容。

以前，大量工作在本地完成，然后发送进行测试，接着可能等待数周才能获得其他员工的反馈，然后才能部署到生产环境。我们现在有一个流程，机器学习专家可以自行运行整个工作流程。

我们现在拥有更好的可观测性和指标，因此专家和基础设施工程师都能更快地获得反馈。借助Kubernetes，我们现在可以自由地实施零信任架构，并且感觉维护更安全的基础设施变得更加容易。

得益于GitHub PR，团队中的每个人都可以访问清单文件，这使得整个过程完全透明，符合预期。

章节 8：基于Kubernetes的技术栈详解 🛠️

是时候展示我们今天在Kubernetes上拥有的基础设施了。你可能想知道，机器学习专家是否需要在学习整个基础设施后才能开始工作？我们追求的简单基础设施是怎样的？

如图所示，我们高亮显示了机器学习专家基本上需要关注的区域，以及他们需要做什么来完成工作，仅此而已。他们需要理解Kubernetes清单的基础知识，并依赖现有的Helm Chart以供共享使用。这使他们能够随着时间的推移学习，为Kubernetes新手节省大量时间，并加快采用速度。橙色框外的所有方面都由基础设施团队管理，以确保运维工作不会干扰机器学习团队。

是时候展示我们在Kubernetes内部使用的技术栈了。与其仅仅展示简单的Logo，我将解释一下我们选择它们的原因。

以下是我们的技术栈组成：

自动化
我们使用Flux来完成整个GitOps流程，因此可以说Git仓库是单一事实来源。机器学习专家可以轻松地使用预制的Helm Chart完成任务，并且可以在需要时请求新的Chart。我们所有的基础设施都完全在GitHub上对团队可见。

安全与网络
为了提高节点和Pod之间的安全性并启用加密，我们使用了Cilium。我们也用它来管理网络策略。为了提供自动化的SSL证书，我们使用了cert-manager，它与Cilium和Gateway API良好集成。通过使用Gateway API，我们为更多选项打开了大门，包括能够与Cilium一起处理第4层网络流量，而不仅仅是默认的第7层。这通常使我们能更好地控制网络流量，并允许我们在不同Pod之间进行流量镜像（如果需要）。在AWS网络负载均衡器上，这比使用应用程序负载均衡器便宜得多，大约是3到4倍。我们使用AWS负载均衡器控制器与Cilium和Gateway API自动创建网络和应用程序负载均衡器。这是在AWS上托管时的常见方法。

可观测性
我们选择Prometheus来收集集群、应用程序和模型的指标。这使我们能够基于指标结果触发警报，例如训练或服务中出现错误时，或者当我们只是需要为集群增加更多资源时。我们使用Grafana作为仪表板工具，与Prometheus集成以显示重要数据，现在基础设施团队和机器学习团队都可以看到相同的指标。我们选择使用Datadog的Vector作为日志收集器，将日志从Kubernetes发送到AWS CloudWatch。市场上有其他工具可以做同样的事情，但我们发现它相对容易设置，并且允许在以后需要时更改日志端点。主要重点是确保节点更新和重启时，日志不会丢失。另一种方法是，我们需要所有机器学习专家都能读取日志，这样他们就不需要保留详细工具。为了观察网络安全性、网络和流量流，我们使用Hubble，它随Cilium一起提供。这使我们能够在启用后获得清晰的网络流量视图。

可扩展性
当节点资源耗尽时，我们使用Karpenter作为节点扩缩器。我们定义了一些规则，允许节点在AWS内部进行扩缩。我们通常使用Kubernetes Metrics API从系统收集指标，这些指标既可用于可观测性，也可用于扩缩目的。我们使用KEDA（Kubernetes Event-driven Autoscaling）进行Pod扩缩。我们用它来基于CPU、内存或自定义指标扩缩Pod。这表现得非常好。

章节 9：问答与总结 💎

今天是非常棒的一天。这消耗了我大量精力，所以我刚才发了条信息。我在这里相当紧张，感谢大家留在这里。如果你们有任何问题，可以随时提出。

问：由于这个技术栈在AWS上，你们是否遇到过任何规模限制或配额问题？你们是如何管理的？
答：我们没有遇到配额问题。当我们扩缩节点时，我们使用Karpenter。你需要将Kubernetes内的资源与AWS中的资源连接起来。我认为扩缩大约在半分钟左右完成，非常快。

哦，谢谢。

总结

在本教程中，我们一起学习了JP/Politikens Hus媒体集团AI团队构建机器学习平台的完整旅程。我们从项目起源和初始目标开始，经历了混沌的显现与平台局限性，总结了经验并明确了新需求。通过关键决策，我们深入探讨了为何最终选择Kubernetes作为解决方案，并详细了解了Kubernetes带来的变革性收益以及最终落地的技术栈。整个过程强调了灵活性、控制权、简化流程和团队赋能的重要性，为希望构建或转型机器学习平台的团队提供了宝贵的实践经验。

024：使用 OpenCost 插件衡量所有成本

概述

在本节课中，我们将学习 OpenCost 项目，特别是其最新的 OpenCost 插件功能。我们将了解 OpenCost 如何帮助您可视化和管理云原生环境中的成本，并深入探讨插件系统如何通过社区力量来整合任何类型的成本数据。

Kubernetes 十年回顾与成本挑战

Kubernetes 已经走过了十年，它不再需要证明自己的价值。如今，大多数公司都在评估或使用 Kubernetes。早期采用者见证了计算成本的显著降低。然而，随着应用规模的扩大和复杂性的增加，成本再次成为关注的焦点。我们已进入“第二天”运营阶段，需要有效管理这些成本。

OpenCost 项目简介

OpenCost 项目始于 2019 年初，旨在成为云原生支出的开放标准。它已从 CNCF 沙箱项目晋升为孵化项目，显示出强劲的发展势头。

OpenCost 目前包含三个主要方面：

Kubernetes 成本：如命名空间、Pod 等资源的成本。
云提供商成本：集成 AWS、GCP 等云服务商的成本数据。
OpenCost 插件：通过插件系统整合任何你能想象到的成本。

OpenCost 提供了一个强大的 REST API，大多数用户首先利用它进行数据收集。项目愿景是成为可视化所有云原生支出的单一平台，连接供应商和客户，帮助双方实现成本透明和价值最大化。

OpenCost 插件：社区驱动的成本衡量

上一节我们介绍了 OpenCost 的整体情况，本节中我们来看看其核心创新：OpenCost 插件。

这是一个始于 2024 年初的社区驱动项目，名为“衡量所有成本”。其核心理念是承认维护者无法独自衡量生态系统中所有类型的成本。因此，我们需要借助社区的力量。

核心挑战与解决方案：FOCUS 规范
项目面临的最大挑战是设计一个通用的接口。幸运的是，我们发现了 FOCUS 规范。

FOCUS 代表 FinOps 开放成本和用量规范，由 Linux 基金会旗下的 FinOps 基金会维护。其使命是建立一个社区驱动的、基于用量的计费数据规范。简而言之，它是一组可以描述任意成本的计费字段。

我们选择 FOCUS 规范作为接口的原因如下：

由专门工作组维护：得到全球众多大型公司的支持。
文档详尽：每个字段都有详细说明，便于贡献者自学。
类型系统完善：具有广泛的类型接口。
版本化管理：作为一个活跃的规范独立发展。

接口设计：核心与扩展字段
FOCUS 规范包含 43 个字段，对贡献者来说可能显得繁多。为了降低贡献门槛，我们将规范分为两部分：

核心接口：包含最高影响力的字段，如主要成本、标签、账户名称等。OpenCost 的用户体验主要围绕这些字段构建。
扩展接口：包含不常提供的字段，如承诺折扣、计费频率等。

这两个接口共同完全满足 FOCUS 1.0 规范。核心成本结构中包含一个指向扩展成本项的指针。这种设计确保贡献者即使无法提供所有字段，也能轻松提交插件。

插件工作原理与交付

了解了插件的设计理念后，我们来看看它们具体是如何工作和交付的。

插件工作流程
以下是插件与 OpenCost 交互的简化序列：

OpenCost 自定义成本采集器获取已配置的插件列表。
对于每个插件，它通过 gRPC 发送一个 CustomCostRequest Protobuf 对象。该对象包含：
- window：需要成本数据的时间窗口。
- resolution：所需的数据分辨率（如每日或每小时）。
插件收到请求后，向特定的供应商 API 发起请求。
插件将获取的数据尽可能转换为 FOCUS 对象。
插件通过 gRPC 将 FOCUS 对象数组返回给 OpenCost。
OpenCost 接收并存储这些数据，使其可通过核心 API 访问。

一个关键点是，我们使用 HashiCorp 的 go-plugin 包和 gRPC，这意味着插件可以用任何支持 gRPC 和执行的语言编写（如 Go、Rust、Python 等），这极大地降低了贡献的技术壁垒。

插件交付方式
Go 插件在编译时会包含大量样板代码，导致二进制文件体积较大。如果将所有插件都打包进 OpenCost 主容器，会导致镜像非常庞大。

我们的解决方案是：

插件在 GitHub 仓库合并后，会自动为多种架构（ARM, AMD64）编译，并发布到 GitHub Releases。
当 OpenCost Pod 启动并检测到需要使用插件时，会启动一个 Init 容器。
Init 容器根据用户配置（特定版本或最新版）从 GitHub Releases 下载对应的插件二进制文件。
下载的插件被存储在一个 emptyDir 卷中，供主 OpenCost 容器使用。

这种方式实现了插件的按需、动态交付，保持了主容器的轻量。

功能演示

现在，让我们通过一个演示来看看插件的实际效果。演示基于 OpenCost 1.113 版本，该版本引入了外部成本 UI 和 API。

目前我们发布了三个插件：

Datadog：参考实现，也是最老的插件。
MongoDB Atlas：由社区成员 Sajet 贡献。
OpenAI：我们为本次演讲构建的插件。

在 OpenCost UI 中，你可以看到新的“外部成本”视图。以 OpenAI 插件为例，我们可以下钻查看：

账户级别：对应 API 令牌。
资源类型：OpenAI 主要提供 AI 模型资源。
模型级别：查看不同模型（如 GPT-4 与 GPT-4o-mini）的成本对比。

演示中设置了一个每 30 秒请求 OpenAI 生成俳句的任务，使用两种不同模型。成本视图清晰地显示了更小模型（GPT-4o-mini）的成本显著低于全功能模型（GPT-4）。这为成本优化提供了直观洞察。

混合视图与成本类型
OpenCost 支持“混合视图”，它同时处理两种成本类型：

账单成本：包含折扣后的实际成本。
标价成本：未折扣的列表价格。

混合视图的算法是：优先使用账单成本（若可用），否则回退到标价成本。用户也可以在 UI 中筛选，仅查看其中一种成本类型。

数据聚合与时间窗口
OpenCost 会持续获取并更新最近 7 天的成本数据。这是因为像 Datadog 这样的第三方服务，其成本数据可能需要长达 72 小时才能完全对账。滚动获取 7 天数据确保了视图能随着时间推移收敛到最终的实际发生成本。

在 UI 中，你可以按“提供商”（我们称为“域”）或资源名称聚合查看所有插件成本，从而快速识别跨 Kubernetes、云服务和第三方 SaaS 的最大成本驱动因素。

路线图与总结

未来路线图
OpenCost 插件项目的未来发展分为几个阶段：

生态系统丰富：当前阶段。目标是增加插件数量，覆盖更多第三方服务（如 Snowflake, New Relic, Confluent Cloud 等）。我们呼吁社区共同参与建设。
供应链改进：包括为插件添加签名以提高安全性，为离线环境提供包含所有插件的“重型”镜像，以及实现独立的插件版本管理和长期支持计划。
统一成本体验：未来计划将云提供商成本也通过插件模型集成，从而统一所有成本源（EC2 实例、Datadog、OpenAI 等），真正实现“单一管理平台”。
高级聚合分析：利用 FOCUS 扩展属性进行更深入的成本洞察和分析。

总结与行动号召
本节课我们一起学习了 OpenCost 及其强大的插件系统。

OpenCost 正获得越来越多的关注，因为它解决了云原生时代日益增长的成本管理需求。OpenCost 插件是我们最新的努力，旨在通过社区协作衡量所有成本。

我们精心设计了插件系统，使其贡献尽可能简单：

基于 FOCUS 标准接口。
支持多种编程语言。
提供动态交付机制。

目前我们已经有了 OpenAI、MongoDB Atlas 和 Datadog 的插件。

行动号召：如果您所在的组织有某个 SaaS 服务是成本支出的主要部分，并希望将其纳入 OpenCost 进行统一管理，我们非常欢迎您来贡献一个插件！您无需深入了解 OpenCost 内部原理。作为激励，前 10 个被合并的插件贡献者将获得奖励。

构建一个 OpenAI 这样的插件大约需要两天时间（一天学习 API，一天实现和测试）。我们希望您能尝试一下，共同参与这个社区驱动的“衡量所有成本”之旅。

我们相信，随着 FOCUS 标准的普及和 OpenCost 插件生态的壮大，未来在成本可视化和优化方面将充满更多可能性。

025：教程

在本教程中，我们将学习如何为运行在 Kubernetes 上的 Apache Kafka 集群实现自动扩缩容。我们将探讨其必要性、核心挑战、解决方案（包括 Strimzi 项目、自动再平衡和分层存储），并通过一个实际演示来理解整个过程。

为什么需要自动扩缩容 Kafka？🤔

Kafka 通常是一个资源消耗巨大的工作负载。如果能够以高效的方式实现自动扩缩容，我们或许可以节省成本、节约能源，变得更加环保。Kafka 在可扩展性方面表现出色，可以轻松地从几个代理扩展到数十甚至数百个。然而，可扩展性更多指的是随着业务长期增长而扩容的能力。

弹性则是指对即时需求做出反应的能力。例如，当您的应用因推广而流量激增几分钟后，又迅速回落。这种对瞬时需求的快速响应，正是自动扩缩容更适用的场景。Kafka 在长期可扩展性方面做得很好，但在短期弹性方面则不那么简单，而这正是 Strimzi 项目试图改进的地方。

在 Kubernetes 上实现自动扩缩容的第一步 🚀

上一节我们介绍了 Kafka 弹性的概念，本节中我们来看看在 Kubernetes 上实现自动扩缩容的基础。

如果要在 Kubernetes 上实现自动扩缩容，首先需要拥有 scale 子资源。对于 Deployment 或 StatefulSet，Kubernetes 已内置此功能。但对于像 Strimzi 这样的 Operator 及其自定义资源，则需要在自定义资源和 Operator 中支持此功能。

scale 子资源允许 Kubernetes 在不理解自定义资源内部结构的情况下对其进行扩缩容。这使得您可以执行类似 kubectl scale kafkanodepool brokers --replicas=5 的命令。这是 Strimzi 引入的概念，与 Kubernetes 本身无关。这也是您接入 Horizontal Pod Autoscaler 的地方，它是 Kubernetes 的基本资源，可以根据某些指标自动扩缩 Pod 数量。

以下是 Strimzi Kafka 自定义资源中启用扩缩容支持的示例配置片段：

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ... 其他配置
    replicas: 3 # 初始副本数，可由 HPA 修改

仅有扩缩容还不够：数据分布问题 ⚖️

上一节我们介绍了如何启用基础的扩缩容，本节中我们来看看一个关键挑战：数据分布。

当我们从一个三节点的 Kafka 集群开始，分区副本被分配到这三个节点。当发生扩容时，新节点被添加到集群中，但它是空的。这是因为在 Kafka 中，所有分区副本都被分配给特定的代理，仅仅添加更多代理并不意味着数据会自动迁移。这对于长期扩展可能可以接受，因为新服务和新主题会逐渐在新节点上创建。但对于自动扩缩容，这并没有帮助。

同样，当您要缩容集群时，假设我们有一个四节点集群，并且第四个节点上存有数据。如果您直接删除这个 Pod，可能会导致数据丢失或集群可用性受损。您不能简单地这样做。

因此，在 Strimzi 中，我们创建了称为“自动再平衡”的功能。它是 Strimzi Operator 的一个特性，底层使用了 Cruise Control 工具。当您进行扩缩容并启用此功能时，Strimzi 会自动使用 Cruise Control 触发再平衡，在 Kafka 集群内迁移数据。在缩容时，它会首先启动再平衡，将数据从即将被移除的节点移走，只有当节点真正清空后，才会将其删除。

引入分层存储以加速扩缩容 💾

上一节我们通过自动再平衡解决了数据迁移问题，但大规模数据移动仍然耗时耗力。本节中我们来看看如何利用分层存储来优化这个过程。

现在，启用了自动再平衡后，当您从三节点集群开始并发生自动扩容时，新节点被添加到集群，然后发生再平衡，部分数据被迁移到新节点。这看起来很好。同样，在缩容时，Strimzi 会首先将数据移动到剩余节点之一，然后才缩容并移除空节点。

但实际情况是，如果每个代理存储了 4TB 数据，添加新代理后，再平衡需要将 3TB 数据从旧节点迁移到新节点。这需要网络资源、存储 I/O、CPU 和时间。移动数 TB 的数据不可能像幻灯片动画那样在几秒钟内完成。

分层存储是一个相对较新的 Kafka 特性，它意味着在 Kafka 集群中使用不同层级的存储。一些不那么重要、不常访问或非最新的数据可以被上传到其他存储层，而本地主要保留重要、频繁访问或刚从生产者接收的数据。

通常，添加的其他存储层可能是像 Amazon S3 这样的对象存储或 NFS 存储。它们通常比代理直接使用的块存储更便宜，容量更大，但延迟也可能更高。如果我们使用分层存储来减少代理上的数据量，那么在再平衡时需要迁移的数据就会减少。

将分层存储应用到之前的集群示例中，现在每个代理上可能只有 400GB 数据，其余的在云存储中。当我们扩容集群时，添加新节点并再平衡后，每个节点可能只有 300GB 数据。这虽然可能仍然很多，但比以前少了 10 倍，因此消耗的网络、存储资源和时间也大致减少 10 倍。这是改进集群扩缩速度和效率的下一个关键部分。

实战演示：配置与观察 🎬

以下是配置一个支持自动扩缩容、自动再平衡和分层存储的 Kafka 集群所涉及的核心组件。

Kafka 集群配置
这是用于部署集群的 Strimzi 自定义资源。我们指定了一个自定义镜像（因为分层存储插件当前未包含在默认 Strimzi 镜像中），并配置了分层存储。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-kafka
spec:
  kafka:
    version: 3.6.0
    image: my-custom-image-with-tiered-storage-plugin:latest
    config:
      # ... 其他 Kafka 配置
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim # 用于分层存储的卷
        size: 500Gi
        class: nfs-client
        deleteClaim: false

自动再平衡配置
在 Kafka 自定义资源中启用并配置自动再平衡功能。

    rebalance:
      auto: true
      addBrokers: true
      removeBrokers: true
      goals:
        - CpuCapacityGoal
        - DiskCapacityGoal
        - NetworkInboundCapacityGoal
        - NetworkOutboundCapacityGoal
        - ReplicaDistributionGoal
        - DiskUsageDistributionGoal
        - CpuUsageDistributionGoal

Kafka 节点池配置
这是 Kafka 代理的节点池，正是我们进行自动扩缩容的对象。关键部分是我们挂载了用作分层存储的额外 NFS 卷。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: brokers
  labels:
    strimzi.io/cluster: my-kafka
spec:
  replicas: 3
  roles:
    - broker
  storage:
    volumes:
      - id: 0
        class: fast-ssd
        size: 100Gi
      - id: 1
        class: nfs-client
        size: 500Gi
        deleteClaim: false

Horizontal Pod Autoscaler 配置
我们配置 HPA 来根据 CPU 使用率自动扩缩 Kafka 节点池。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: kafka-brokers-hpa
spec:
  scaleTargetRef:
    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaNodePool
    name: brokers
  minReplicas: 3
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 90
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 600
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60

在演示中，当负载增加时，HPA 检测到 CPU 使用率上升，将集群从 3 个节点扩展到 5 个节点。Strimzi Operator 添加了新代理（节点 13 和 14），然后触发了自动再平衡，使用 Cruise Control 将部分分区副本迁移到新节点上，从而平衡集群负载。整个过程可能需要数分钟，具体时间取决于数据量和集群资源。

挑战与注意事项 ⚠️

自动扩缩容虽然有效，但仍面临一些挑战：

时间：扩缩容可能需要数分钟，主要耗时在数据迁移上。这意味着您不能等到流量洪峰来临时才启动扩容，需要提前规划。
成本与振荡：扩缩容本身是昂贵的，因为再平衡会消耗资源。必须正确配置 HPA 的稳定窗口和时间参数，以避免集群在扩缩容阈值附近频繁振荡。例如，缩容后由于数据迁移会导致负载立即上升，如果 HPA 配置不当，可能又会立即触发扩容。
指标选择：选择正确的扩缩容指标至关重要。演示中使用了 CPU 使用率，但 Kafka 有多种内部指标（如不同线程池的利用率），可能在某些场景下更合适。
分区数限制：自动扩缩容不会改变主题的分区数。如果您的负载集中在少数几个分区上，那么增加代理可能无济于事。负载需要分布在足够多的分区上才能受益于新增的代理。
集群容量：Kafka 代理通常是资源密集型工作负载。当尝试扩容时，Kubernetes 集群可能没有足够的资源来调度新的 Pod。此时需要依赖集群自动扩缩器（如 Karpenter）来添加新的工作节点，但这会进一步延长扩容时间。
分层存储的适用性：分层存储并非万能。如果您的用例需要反复频繁访问所有数据，那么使用对象存储可能并不划算，因为您需要为请求和数据传输付费。分层存储最适合用于存储不常访问的冷数据或温数据。

总结与展望 📚

在本教程中，我们一起学习了为 Kubernetes 上的 Apache Kafka 实现自动扩缩容的完整旅程。

我们首先探讨了弹性的需求，然后了解了在 Kubernetes 上启用基础扩缩容的方法。接着，我们发现了单纯扩缩容导致的数据分布问题，并引入了 Strimzi 的自动再平衡功能来解决。为了优化大规模数据迁移的性能，我们探讨了使用分层存储来减少代理本地数据量，从而显著缩短再平衡时间。最后，我们通过一个实战演示观察了整个流程，并分析了当前方案仍面临的挑战，如时间开销、资源配置和指标选择等。

尽管存在挑战，但自动扩缩容 Kafka 集群是可行的。它更适合用于中长期的容量规划，例如根据工作日/夜间或周末的流量模式来调整集群规模。同时，它也能帮助解决 Kafka 集群 sizing 困难的问题，让您更有信心从小规模集群开始，让其随需求增长，而不是一开始就过度配置。

如果您对改进 Kafka 自动扩缩容感兴趣，欢迎通过 Strimzi 项目的各个渠道提供反馈，共同探索更合适的指标并改进功能。

026：精通 OpenTelemetry Collector 配置

在本节课中，我们将要学习 OpenTelemetry 项目的核心组件之一——Collector 的配置方法。我们将从基础概念入手，逐步深入到配置的细节与实践，帮助你掌握如何有效地接收、处理和导出可观测性数据。

讲师介绍

我是 Steve Flanders，目前在 Splunk（近期被思科收购）担任工程高级总监。我参与可观测性领域已超过十年，曾参与 OpenCensus（OpenTelemetry 的前身项目）的工作，并在 VMware、Omniscient（后被 Splunk 收购）等公司负责日志、追踪和指标产品。最近，我刚刚发布了一本名为《精通 OpenTelemetry 与可观测性》的书籍。

什么是 OpenTelemetry？

OpenTelemetry 是一个开放标准，旨在实现遥测数据的生成、收集和处理。它涵盖了可观测性的三大支柱——追踪、指标和日志，并支持更多类型的信号，如客户端插桩、性能剖析和合成数据等。该项目专注于应用程序、浏览器、移动设备等所有环境中的遥测数据。

核心公式：OpenTelemetry = 规范 (Specification) + 实现 (Instrumentation Libraries & Collector)

OpenTelemetry 本身不提供数据后端，而是保持供应商中立，允许你将数据发送到任何目的地，无论是开源项目、自建方案还是商业供应商。

为什么 OpenTelemetry 很重要？

首先，它提供了一个开放标准，统一了术语和操作方法。其次，它实现了供应商中立，带来了数据可移植性和控制权。你可以自由选择生成多少数据、如何处理以及发送到哪里。作为 CNCF 中活跃度仅次于 Kubernetes 的项目，它拥有庞大的生态系统和广泛的社区支持。

聚焦：OpenTelemetry Collector

Collector 是一个独立的二进制文件，负责接收、处理和导出数据。其内部流程可以简化为：接收数据 -> 处理数据 -> 导出数据。

接收数据可以通过推（Push）或拉（Pull）机制。例如，Prometheus 使用拉取（Scrape），而分布式追踪通常使用推送。

处理数据可能包括过滤、脱敏、聚合或采样等操作。
导出数据则是将处理后的数据发送到最终的后端系统进行分析和可视化。

Collector 的部署模式

Collector 主要有两种部署模式：

Agent 模式：尽可能靠近应用程序运行（如二进制文件、Sidecar、DaemonSet）。其优点是快速将处理责任从应用中卸载，减少应用自身的资源消耗，并能以统一的方式处理所有数据。
网关/服务模式：部署在网络边界（如数据中心、区域），通常以集群方式运行，前方配有负载均衡器，以支持高可用性和大规模流量。

两种模式都可以将数据发送到任何目的地。你甚至可以选择完全不使用 Collector，让应用程序库直接发送数据到后端。Collector 的强大之处在于其能够接收一种格式的数据（如 Prometheus），并在内部转换为另一种格式（如 OTLP）后导出，从而实现供应商中立。

Collector 的构成与分发

Collector 是一个用 Go 语言编写的单二进制文件，支持主流操作系统和容器化部署。

OpenTelemetry 有几种官方“分发版”：

Core：包含 OpenTelemetry 核心协议（如 OTLP）所需的基本组件。
Contrib：包含非核心但常用的组件，如对接 Zipkin、Jaeger 等后端的导出器。
Kubernetes：为 Kubernetes 环境预打包了相关组件。

此外，任何人都可以使用 OCB 工具构建自己的分发版，仅包含所需的组件。许多供应商和云提供商都维护着自己的分发版。

Collector 配置详解

Collector 主要通过 YAML 文件进行配置。配置文件主要包含五大类组件：

Receivers（接收器）：定义如何接收数据。
Processors（处理器）：定义如何处理数据（如过滤、修改、批处理）。
Exporters（导出器）：定义如何将数据发送出去。
Extensions（扩展）：提供不直接处理遥测数据的附加功能（如健康检查、身份验证）。
Connectors（连接器）：同时作为接收器和导出器，用于在管道间重定向或重新处理数据。

配置是一个两步过程：

定义并配置组件：在 YAML 文件的对应章节（receivers， processors， exporters）中声明和配置组件。
在服务管道中启用组件：在 service -> pipelines 部分，为特定的信号类型（如 metrics， traces）指定要使用的接收器、处理器和导出器及其顺序（仅处理器顺序有意义）。

配置示例代码：

receivers:
  otlp:
    protocols:
      grpc:
      http:
  hostmetrics:
    scrapers:
      memory:

exporters:
  debug:

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      exporters: [debug]

配置验证与查找

在部署配置前，务必使用 validate 命令进行验证，以避免因配置错误导致 Collector 崩溃。

otelcol-contrib --config=config.yaml validate

所有组件的配置选项都可以在 GitHub 仓库对应组件的 README 文件中找到（需区分 core 或 contrib 仓库）。

实践演示：从基础到生产配置

上一节我们介绍了配置的结构，本节中我们来看看如何一步步构建一个可用的配置。

首先，我们创建一个最简单的配置，使用 hostmetrics 接收器收集内存指标，并通过 debug 导出器输出到控制台。使用 validate 命令确保语法正确后启动 Collector。

接着，我们添加对生产环境至关重要的处理器：

memory_limiter：防止 Collector 内存耗尽而崩溃。
batch：将数据批量发送，提高效率。

OpenTelemetry 文档建议处理器顺序为：memory_limiter 在前，batch 接近末尾。

然后，我们可以添加 resource 处理器来丰富数据，例如自动添加主机名和操作系统类型等元数据。这有助于后续的问题定位和根因分析。

增强后的配置示例代码：

receivers:
  hostmetrics:
    scrapers:
      memory:

processors:
  memory_limiter:
    check_interval: 5s
    limit_mib: 400
  batch:
  resource:
    detectors: [system]

exporters:
  debug:

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      processors: [memory_limiter, resource, batch]
      exporters: [debug]

通过处理器，你还可以执行更复杂的操作，如根据属性过滤数据、修改或删除元数据等。

总结与问答要点

本节课中我们一起学习了 OpenTelemetry Collector 的核心概念与配置方法。我们了解到 Collector 是一个强大的、供应商中立的数据处理管道，可以通过灵活的 YAML 配置来接收、丰富、处理和导出各种遥测数据。关键点包括：理解接收器、处理器、导出器的作用；掌握两步配置法；使用 validate 命令进行验证；以及为生产环境配置必要的处理器（如内存限制器和批处理器）。

在问答环节，讨论了一些高级主题：

分层 Collector：在需要全量指标但采样追踪的场景下，可以在 Agent 模式使用路由和连接器，或在极高规模下分离指标和追踪的 Collector 集群。
调试：除了日志，可使用 debug 导出器或在线 YAML 可视化工具来检查配置和数据流。
有状态与无状态：尽可能以无状态方式运行 Collector 以便于扩展。但在需要追踪关联（如尾部采样）或确保数据不丢失（如合规要求）时，需利用存储扩展等有状态功能。
迁移价值：如果现有工具链（如 Fluent Bit + Prometheus）满足需求且无供应商锁定问题，则无需立即迁移。OpenTelemetry 的主要价值在于提供标准化和供应商中立的灵活性，便于未来切换后端或整合不同信号。

027：从芯片到服务，确保无服务器GPU云函数中的机密性

概述

在本节课中，我们将学习如何构建一个从硬件芯片到上层服务的全栈可信环境，特别是在无服务器GPU云函数场景下，确保数据的机密性。我们将探讨机密容器技术、远程证明、运行时完整性以及如何应对多租户环境中的安全挑战。

1：机密容器的用例与上游社区工作

上一节我们介绍了课程主题，本节中我们来看看机密容器技术旨在解决的具体业务场景，以及开源社区如何协作推动其发展。

我的主要职责是负责机密容器中的CAA（机密计算抽象层）。今天我想探讨一个从芯片到服务的全栈话题：确保无服务器GPU云函数中的机密性。

首先回顾一下我们在这个领域已完成的工作。我曾在巴黎的KubeCon EU上介绍过带GPU的机密容器和常规微服务。我讨论了机密计算的角色、我们为何选择CAA在Kubernetes上实现带GPU的机密计算、GPU使能栈和虚拟化参考架构、为支持GPU RDMA或GS等高级用例需要注意的事项、我们如何实现机密容器，并举例说明了如何用机密容器运行常规微服务。相关录播链接已提供，如果您对我们在此领域的底层细节感兴趣，可以查看。

今天，我想扩展我们正在用机密容器实现的用例，以及我们在上游社区建立的工作组的角色。

其中一个工作组是我们的“机密容器用例工作组”。IBM、Red Hat、NVIDIA、Intel、AMD等多家公司都参与其中。我们确定了三个希望在上游推动并实现的主要用例：

以下是三个主要用例：

联邦学习：包含数据洁净室。不同参与方在一个机密环境中协同工作，我们需要共享此环境并为多个角色提供数据洁净室。这也关联到多方计算，它不只是在单个节点上运行机密容器，而是涉及多个节点，我们需要对此进行管理。
供应链安全：如果您运行一个机密环境，那么所有环节都必须是可信的，包括您的构建流水线、CI/CD流水线。因此，我们社区中有多个成员正在研究供应链安全，包括所有与SBOMs（软件物料清单）、来源证明、CI/CD、构建的可重复性以及我们在飞地或机密环境中交付物的验证相关的事项。
生成式AI/大语言模型/神经信息管理系统：如何正确部署和保护它们。

本质上，所有这些用例都有一个共同点：我们有不同的参与方在飞地中运行，我们需要确保为所有相关方提供一个洁净的、机密的“洁净室”。上游社区文档中也提供了链接，您可以通过一些幻灯片和演示文稿详细了解这些用例。

2：机密计算环境中的证明与信任

上一节我们了解了机密容器的关键用例，本节中我们来看看如何在这些复杂环境中建立和验证信任，特别是通过远程证明机制。

任何在机密计算用例中工作的人都会注意到参考架构。我们有一个专门的工作组，主要专注于机密容器中的证明和信任管道。目前，大多数传统环境都集中在单个节点上，并在运行开始时进行证明。但有些工作负载可能会运行数周或数月，我们正在研究的一件事是进行周期性的证明运行。如果有大量节点加入和离开，所有这些证明实体都需要被证明和验证。此外，我们希望禁用重放攻击。例如，如果您有机密存储，您可能希望进行周期性运行来验证您的机密存储是否仍处于预期状态。

正如之前所说，我们支持多角色。想象一下，云提供商提供基础设施，模型所有者提供第三方模型，然后用户可能拥有使用此模型的X张图像。这些角色中的每一个都需要相互证明和验证。因此，这也是我们信任工作组中的一个重要议题：如何实现这一点。

然后，我们还有复合证明支持这样的问题。想象一下，有许多证明实体进入和离开您的机密环境，您需要确保不会出现任何竞态条件，并且这些实体的证明是以正确的方式和在正确的时间完成的。因为在硬件层面存在一些定时攻击，特别是在有不同的策略和证明运行时。因此，我们正在思考如何将所有证明实体组合到一个报告中，或者我们是否进行轮询证明运行等。这些是我们试图回答的问题，以及如何正确地去做。

当然，另一个重要议题是运行时完整性。系统在运行时可能发生变化，我们希望捕捉到这一点。如果一切崩溃，我们希望有一个信号或警报表明某些东西发生了变化。

正如之前所说，大多数环境都是单节点的。我们需要考虑全局状态的证明。关于多个节点、多个集群甚至多个可用区的全局状态。您有一个全局状态，并且需要证明您的完整全局状态。

当然，还有身份管理。您需要知道谁正在进入您的安全飞地，谁正在离开。因此，您始终需要您的硬件设备、对等方、节点以及所有进出安全飞地的事物的正确身份。

机密容器的主要焦点正是我们所拥有的“直接迁移”策略：无需任何修改即可运行或终止。我们支持主要的硬件可信执行环境：AMD SEV、Intel TDX、ARM CCA、RISC-V COVE正在开发中，以及IBM CEX。我们可以在任何基础设施上运行，无论是在本地、云服务提供商还是混合环境，并且支持任何部署模型，无论是无服务器还是托管Kubernetes。我们正试图通过机密容器启用所有这些用例，这意味着一个相当好的直接迁移策略，因此您可以将容器作为传统容器、runC容器运行，或者如果您愿意，也可以作为机密容器运行。

之前我们看到的所有与机密虚拟机或可信执行环境相关的工作，都是为了使这些飞地更加安全。但我们忽略的一件事是主机。

我们目前正在研究的一个大议题是全栈证明。您本质上想要做的是保护您的完整环境和您的芯片，从芯片一直到容器。如果我们看看当前存在的各种攻击，比如“PK失败”，许多BIOS或固件供应商正在分发不可信的密钥，这意味着您的安全启动被破坏，您的度量启动被破坏，所以本质上您的UEFI已经损坏。然后在此基础上，我们运行一个内核，而您的内核因为缺乏正确的度量启动而损坏。再往上，在操作系统中，由于UEFI损坏、内核损坏，您的操作系统也同样损坏。例如，“Ahoo攻击”是针对机密虚拟机的一种攻击，您可以通过恶意通知（即中断溢出）来破坏可信执行环境。如果主机不受保护，您就可以对机密虚拟机发起攻击。

我知道周围有很多eBPF工具，它们试图保护主机。但问题在于，任何在Linux系统上运行的工具，它们都试图确保它们所依赖的运行时的完整性，因此存在循环依赖。您无法保护您正在运行的同一个运行时，因为如果它被破坏，您也就被破坏了。所以eBPF更像是一个可观测性工具，而不是安全工具。

为了给您一个印象，即使eBPF和所有这些工具都在工作，库尔特·哥德尔是一位奥地利数学家。我不知道你们是否熟悉不完备性定理，但一个足够复杂的公理系统中，存在一些命题和公理，您无法证明其真假。我们可以将其应用于运行时。您的运行时中有工具，任何试图在自身内部证明运行时环境完整性的尝试都会产生循环依赖，这使得在不依赖外部或更高级别验证的情况下建立绝对信任变得不可能。因此，您无法证明自己。这就是关键点。eBPF试图证明自己，试图证明主机，这在数学上是行不通的。即使数学上行得通，仍然存在无法证明的命题。

3：云环境与本地环境中的硬件信任根

上一节我们讨论了在软件层面建立信任的挑战，本节中我们来看看如何从硬件层面，通过“带外”管理来构建更底层的信任基础。

例如，云服务提供商如何验证他们如何保护其运行时。正如之前所说，它需要是一个开箱即用的解决方案。举个例子，我在这里以AWS Nitro为例。如果您查看AWS Nitro，他们在主机之外运行这些Nitro卡。主机对Nitro卡没有任何控制权。流程是从EC2控制平面到Nitro卡，然后从Nitro卡，它们启动Nitro hypervisor，并最终启动您在主机上拥有的所有实例。因此没有后门通道。Nitro hypervisor无法与Nitro卡通信，Nitro卡也无法与EC2控制平面通信。所以没有办法回到这些实例。我还在这里展示了ASIC和EEPROM。另一个问题是，我们如何保护所有的ASIC，因为恶意攻击者可以重新编程我们的EEPROM，而您的ASIC可能运行错误的代码。

Nitro的做法是，他们有一个服务处理器，可以将CPU保持在复位状态。在此复位期间，管理Nitro卡正在证明和度量所有的EEPROM。每个ASIC在I2C总线上都有一个钩子，他们可以在那里度量其EEPROM和固件，并可以用他们拥有的黄金度量值进行验证。因此，从EEPROM加载的所有内容都由Nitro卡检查。所以他们保护了ASIC。然后在此基础上，他们有一个TPM，意味着他们可以保护加载的hypervisor，并且CPU会保持复位状态，直到所有那些固件、内核、主机内核、客户机以及Nitro hypervisor等所有组件都被真正验证。这始终是相同的模式：在证明中，您度量某些东西并将其与预期值进行比较。主机无法访问所有这些功能，一切都是带外的。正如之前所说，它必须是带外的、更高特权的实体，以验证正在运行的主机是否处于真实且预期的状态。

这是在云上。但如果您关注本地环境，如果您对如何在本地实现感兴趣，有一家叫Oxide Computers的公司。他们本质上在做完全相同的事情：他们有一个服务处理器，可以将CPU保持在复位状态；他们有一个信任根。您需要一个信任根，您需要开始信任某个实体，信任根持有所有密钥和背书密钥来保护其他秘密。正如所说，服务处理器将CPU保持在复位状态，直到所有度量完成，直到所有固件被检查和度量并证明，然后CPU才被释放，CPU才能运行在主机上，创建hypervisor并执行我们需要的所有其他操作。他们还有一些更多功能，比如安全的秘密存储，完全从主机卸载，因此您不在主机上共享任何秘密，任何在主机上运行的恶意负载都将无法访问任何秘密。

通过这种带外管理和额外的信任根，我们基本上对ASIC、EEPROM亮了绿灯。我们现在有了度量启动、带有UEFI和内核的安全启动，所有这些都由TPM支持。但我们仍然没有解决主机上的任何问题，因为度量启动在您获得Linux提示符运行时就会停止。那么，我们可以在操作系统上做些什么来防止之前提到的攻击呢？

4：操作系统与虚拟化层的安全加固

上一节我们探讨了硬件信任根的建立，本节中我们来看看在操作系统和虚拟化层可以采取哪些额外措施来增强安全性。

一件事是操作系统的运行时完整性。有一些工具，如dm-verity和fs-verity。本质上，这些工具构建了一个默克尔树。这些本质上是哈希的哈希。最终，您会得到文件系统或操作系统的哈希或指纹，可以与预期值进行比较。然后，我们有Linux的完整性度量架构和EVM。这些本质上也是经过密码学签名和度量的文件及元数据，您可以再次与某些预期值进行比较。还有一些方法，如不可变操作系统（Red Hat CoreOS、Talos），您只是防止对用户分区的意外写入等。

然后，我们遇到的一个问题是与KVM和机密虚拟机（无论是QEMU、cloud-hypervisor还是其他正在运行的虚拟机）共享同一个内核。这与我们在容器中遇到的问题相同，这就是我们首先进行沙箱化的原因。突破仍然可能对其他虚拟机造成拒绝服务。如果您在主机中，您可以攻击那些其他虚拟机。如果您正在运行一个机密容器，数据仍然是加密的，但您仍然可以杀死所有QEMU进程，然后所有虚拟机都会消失。这就是问题所在。这也是我们正在上游研究的内容：如何在类型1 hypervisor上运行CAA和机密容器。为什么我们需要一个操作系统？为什么我们需要一个完整的操作系统运行在我们的虚拟机之下？我们只需要虚拟机管理。

我们在云服务提供商那里遇到的挑战是，他们提供机密虚拟机。为了运行传统的机密容器，我们某种程度上需要嵌套虚拟化，但我们也不需要它。嵌套虚拟化会引入很多问题，安全问题和性能问题。

解决这个问题的一种方法是移除嵌套虚拟化。熟悉Xen的人都知道，Xen有主虚拟机和次虚拟机，主虚拟机在同一L1级别管理所有用户虚拟机，因此它们没有任何嵌套虚拟化。这是一个更简单、更简化的架构。它扁平化了虚拟化层次结构。因此，所有虚拟机都作为L1客户机运行，我们不需要任何L2客户机，性能更高，安全性更强，当然，也减少了右侧的资源使用。右边这只是一个示例，说明如何使用Acon hypervisor实现这一点。这是一个现代的类型1 hypervisor，类似于Xen模型，您有一个服务虚拟机，负责所有资源管理，然后在同一级别上，您有用户虚拟机。

“Fractured turtles”是对Turtle项目的引用，该项目在Kata中引入了嵌套虚拟化的概念。这种次虚拟机模式的一个实现是机密容器的PeerPods。本质上，您有一个主虚拟机，它是云服务提供商实例上的工作节点，而Pod则运行在它自己的云服务提供商虚拟机实例中。我们没有在工作节点内部进行嵌套虚拟化。我们有一个对等虚拟机，它作为一个独立的云服务提供商实例运行。因此，我们将工作节点与工作负载解耦了。通过这种模型，您甚至可以完全将控制平面与您的工作节点解耦。您可以在本地运行控制平面，在云服务提供商那里拥有您的工作节点，并在云服务提供商那里运行您的工作负载。因此，您可以将工作负载与工作节点解耦，并可以完全将其与控制平面解耦。这使我们能够也将机密容器作为混合云运行。您可以在本地使用本地虚拟机运行您的Pod，然后通过PeerPods扩展到云服务提供商，这一切都是完全透明的直接迁移。唯一的接口是Kubernetes中的Pod，您只需将运行时类从PeerPods更改为本地虚拟机或CAA容器。

5：客户机虚拟机与容器负载的安全

上一节我们讨论了如何通过扁平化架构提升虚拟化层的安全性，本节中我们来看看在机密容器内部的客户机虚拟机和容器负载本身，还有哪些安全挑战和应对策略。

那么，我们已经处理了ASIC、UEFI、内核、操作系统。是的，我仍然有操作系统，比如Red Hat，因为如果您的机密虚拟机配置错误，您可以通过SSH访问它们。操作系统仍然可以进入您的机密虚拟机。因此，信任模型，我们也在研究的是，我们也不信任客户机，因为机密容器运行在机密虚拟机内部。本质上，客户机虚拟机仅用于启动容器、处理容器的生命周期。因此，我们本质上不需要在虚拟机中运行一个复杂的或完整的操作系统。所有在机密虚拟机中运行的工件，如固件、客户机内核和客户机文件系统，都来自主机。因此，如果您有恶意来源，它可能为您的机密虚拟机提供恶意工件，所以您再次在那里运行恶意代码。

在客户机上，我们也可以进行运行时完整性检查，使用我之前提到的相同工具：dm-verity、fs-verity、IMA、EVM、不可变操作系统。但一个大问题是，如果您正在进行安全启动，您有度量值。您有一个TPM，可以在硬件飞地中存储您自己的启动度量值。如果您在客户机中进行，我们如何保护这些度量值，因为它们可能被操纵，并且证明报告可能向远程证明实体提供错误的度量值。

这些运行时度量值可以在机密虚拟机内部通过证明来保护。证明报告中有报告字段可以扩展。TDX有一个RTMR（运行时度量寄存器），它本质上是一个TPM PCR寄存器，您可以在其中扩展哈希。

但社区一直在研究的一件事是如何在客户机中利用vTPM。显然，我们不能从主机透传一个vTPM，因为我们不信任主机。如果我们透传一个vTPM，它需要是一个软件实现，因为您无法虚拟化硬件TPM。如果您从主机透传一个虚拟化的TPM，您需要在某个地方保护它，您也需要在机密飞地中运行它以保护它免受主机和其他租户的影响。

因此，社区有一个想法：在机密虚拟机内部运行高特权固件。一个是Coconut SVSM，微软最近宣布了OpenHCL，这是一个在特殊虚拟机级别运行的高特权固件。如果您查看SEV-SNP，SEV-SNP可以在不同的虚拟机特权级别上在机密虚拟机内运行应用程序。它们在特权级别0运行这个自定义固件，它可以模拟一个vTPM。特权级别1将运行内核，特权级别2将运行操作系统。随着级别升高，您拥有的特权越来越少。因此，级别2无法访问级别1，级别1无法访问级别2。所以vTPM受到内核和用户空间的保护。

机密虚拟机内的vTPM是无状态的。我们不保存任何状态。但一个真正的问题是，您如何在机密虚拟机内制造TPM，因为通常硬件TPM在制造时内置到服务器中时就带有背书密钥。对于vTPM，您需要动态进行。因此，当您实例化vTPM时，您创建一个背书密钥，您可以将其绑定到CPU的证明报告，并且您拥有直到CPU供应商的证书链。因此，您证明您的背书密钥是有效的。从那里，您可以派生存储密钥和所有其他您将进行的TPM相关操作。

上游有一些讨论，因为一些人认为TPM不是保护机密虚拟机内部度量值的正确接口。因此，在内核端、用户空间端，以及我们的机密容器社区中，都有一些关于如何正确保护这些度量值的讨论，因为TDX有RTMR，SEV-SNP没有类似的东西，CCA的做法完全不同，所有其他可信执行环境都有自己的实现。

正如之前所说，客户机虚拟机只是一个部署载体。对于机密容器用例，我们并不真的需要一个完整的操作系统在那里运行。

我们正在做的是客户机内核加固，剥离所有我们不需要的选项，一个数字化的客户机文件系统，只包含我们生命周期管理容器所需的库和一些二进制文件。我们不运行一个完整的操作系统，还有固件加固，禁用我们不需要的功能和部分。

然后我们有了容器负载。您可以想象，由于我们在客户机文件系统中没有任何工具，攻击者可能使用容器作为负载，因为容器保存在镜像中，并使用容器内部部署的工具在虚拟机内部运行。我们如何防止这种情况是使用SELinux或AppArmor，这样没有容器上下文可以在主机上下文中执行任何操作，从而保护客户机虚拟机免受运行容器负载二进制文件的影响。本质上，我们希望为攻击者创造一个没有枚举任何东西或进行任何横向移动可能性的空间。

如您所见，我仍然在容器上有一个问号。我们可以对容器进行签名，验证容器来自我们期望的仓库。但我们如何知道容器部署了什么？里面有哪些工具？您在里面运行哪些软件包？这就是SBOM发挥作用的地方。我们需要一个运行在我们堆栈中的所有组件的清单。我们想知道是否需要针对CVE或错误修复做出反应，无论是容器、客户机文件系统还是操作系统。因此，我们正在跟踪清单，了解我们堆栈上运行的内容，并且我们正在验证容器的SBOM签名、固件、客户机内核以及所有需要的文件的签名，并且需要进行证明。

本质上，我们想要做的是通过远程证明验证所有签名、SBOM证书。我们需要构建一个从芯片到容器SBOM的信任链。只有当所有这些部分都是绿色的、经过验证和测试的，我们才能说，好的，我们正在运行一个可信的堆栈。

我们如何进行证明？再次强调，Trustee是我们的证明管道。我们正在扩展Trustee以支持我在这里解释的所有这些用例。

云服务提供商证明的问题在于他们证明自己。这就是问题所在。通常，您希望以租户所有者的身份证明您正在运行的环境。这就是Trustee发挥作用的地方，您可以在您可信的基础设施上部署Trustee，然后证明您的机密容器工作负载、vTPM引用、SBOM以及整个堆栈的所有签名。对每一层进行度量和测试。只信任您验证过的内容。

6：无服务器云函数中的全栈证明

上一节我们构建了从硬件到容器镜像的完整信任链，本节中我们来看看为什么这一切对于无服务器云函数场景至关重要，以及如何应用这些原则。

但这又引出了云函数以及我们为什么要进行全栈证明、运行无服务器。因为云函数运行在我们的共享、抽象的基础设施上，其中底层是隐藏的，但对安全至关重要。这些使用点来自云函数提供商、函数即服务提供商或工作负载所有者。我们有不透明的层，我们对硬件一无所知。我们希望确保硬件、hypervisor、操作系统以及我们部署的所有工件都处于用户期望的状态，反之亦然，用户也期望所有工具、工件和层都受到保护，以便多租户成为可能，因为我们希望保护同一硬件上的其他租户。在共享硬件上存在数据泄漏、恶意推理、租户间拒绝服务的可能性。

硬件或hypervisor中的所有漏洞都可能影响函数，而运行云函数的用户或基础设施所有者却不知情。

最后一点是，如果运行时、操作系统或其他层未经度量，它们可能被篡改，影响函数完整性和数据安全。因此，度量一切，验证一切，证明一切。确保堆栈的每一层都经过证明和可验证。

总结

在本节课中，我们一起学习了如何为无服务器GPU云函数构建全栈机密计算环境。我们从机密容器的具体用例和社区工作开始，探讨了建立信任所需的远程证明机制，并深入了解了从硬件信任根、操作系统加固到虚拟化层安全的最佳实践。最后，我们强调了在抽象的无服务器环境中实施全栈度量和验证的重要性，以确保多租户隔离和数据机密性。核心在于构建一个从硅芯片到服务容器、每一层都可验证的完整信任链。

028：揭秘NVIDIA的自愈GPU舰队管理

在本节课中，我们将学习NVIDIA如何利用一个名为“Notify Maintenance API”的自定义Kubernetes解决方案，来大规模、自动化地管理其GeForce Now云游戏服务的GPU基础设施维护工作。我们将深入探讨其设计哲学、核心架构以及在实际场景（尤其是故障修复）中的应用。

概述：维护GPU舰队的挑战与哲学

NVIDIA的GeForce Now服务在全球数据中心运行着超过40个Kubernetes集群、3万多个节点以及6万多个GPU。维护如此庞大的舰队（包括GPU更新、Kubernetes升级、驱动更新、操作系统补丁等）是一项巨大挑战。

他们的维护哲学可以类比为打造一辆赛车：第一要务是造一辆快车（提供优质服务），第二要务是能在赛道上维修它（在生产中维护）。两者同等重要。这意味着必须在确保服务持续可用、不影响最终用户体验的前提下，完成所有基础设施的维护和修复工作。

核心解决方案：Notify Maintenance API

面对维护需求，NVIDIA团队认为缺少一个统一的“维护API”来跟踪和管理维护状态。他们的核心论点是：如果能准确定义维护过程所经历的所有状态，就能围绕它构建强大的工具链。

于是，他们创建了 NotifyMaintenance 这个Kubernetes自定义资源定义（CRD）。它本质上是一个有限状态机（Finite State Machine），用一系列规范化的状态来描述一次维护的生命周期。

以下是NotifyMaintenance API的一个简化示例：

apiVersion: maintenance.nvidia.com/v1alpha1
kind: NotifyMaintenance
metadata:
  name: node-maintenance-example
spec:
  additionalMessageChannels:
    - slack
    - sns
  maintenanceId: "bios-042b" # 此次维护任务的唯一标识
  maintenanceType: "Planned" # 或 "Unplanned"
  slaExpires: "2024-05-15T23:59:59Z" # 工作负载必须迁移的截止时间
status:
  maintenanceStatus: "MaintenanceScheduled" # 当前状态

该API主要包含以下关键字段：

additionalMessageChannels: 用于将维护事件通知到Kubernetes外部（如Slack、SNS），实现“通知（Notify）”功能。
maintenanceId: 维护任务UID，用于聚合跨节点的相同维护操作。
maintenanceType: 区分 Planned（计划内）和 Unplanned（计划外/故障）维护，这对处理逻辑至关重要。
slaExpires: 与服务等级协议（SLA）相关，设定工作负载必须迁出的最后期限。
maintenanceStatus: 代表维护的当前状态，是状态机的核心。

维护状态机：八个核心状态

基于对维护流程的抽象，他们定义了维护操作通常会经历的八个核心状态。理解这些状态是理解整个方案的关键。

MaintenanceScheduled (计划排期): 决定对某个节点开始维护，并通知相关方。
MaintenanceStarted (开始驱逐): 启动工作负载驱逐流程。这可能简单如执行 kubectl drain，也可能复杂如涉及QEMU/KVM的实时迁移。
Drained (已驱逐): 节点上的工作负载已被清空，可以安全进行维护。
Maintenance (执行维护): 实际执行维护操作（如升级BIOS、Kubernetes版本、操作系统等）。具体操作由用户定义的控制器实现。
MaintenanceComplete / MaintenanceFailed (维护完成/失败): 维护操作执行完毕或中途失败。
Validating (验证中): 维护后验证节点状态（如运行健康检查、确认版本号）。
ValidationComplete / ValidationFailed (验证完成/失败): 验证通过或失败。若多次验证失败，可能需人工介入。
MaintenanceComplete (返回生产): 所有步骤成功，节点健康，返回集群继续服务。

通过这套状态机，任何维护操作都可以被清晰地跟踪和协调。

系统架构：控制器生态系统

有了标准化的API和状态定义，就可以围绕它构建一个控制器（Operator）生态系统。每个控制器负责推动状态机向下一阶段迁移，或执行特定阶段的操作。

在一个集群内部，架构通常包含以下核心控制器：

维护调度器（Maintenance Scheduler）: 负责根据策略创建 NotifyMaintenance 对象，并推动状态从 Scheduled 向 Started 等状态转移。
驱逐控制器（Drain Controller）: 当状态进入 MaintenanceStarted 时，该控制器负责安全地驱逐节点上的工作负载，直至达到 Drained 状态。
维护控制器（Maintenance Controller）: 当状态为 Drained 时，该控制器执行具体的维护操作（如升级软件），完成后将状态推向 MaintenanceComplete。
通知系统: 贯穿始终，在状态变更时通过Kubernetes Events和外部通道（如SNS）广播消息。

这种设计使得维护逻辑（状态机）与具体的维护动作（控制器实现）解耦，非常灵活。

实战应用：自动化故障修复（Unplanned Maintenance）

上一节我们介绍了计划内维护的通用框架，本节中我们来看看它在处理计划外故障（Unplanned Maintenance）时的强大应用。这是该方案带来巨大价值的关键场景。

过去，当节点或GPU发生硬件或软件故障时，需要值班工程师手动诊断、执行修复脚本、验证并恢复节点，耗时耗力且可能遗漏故障。现在，他们利用 NotifyMaintenance API 实现了全自动化修复流水线。

以下是自动化故障修复的流程：

故障检测（Detection）: 利用 Node Problem Detector 或自定义的 GPU Problem Detector（作为Device Plugin的一部分），将故障信息写入节点的 Condition 字段。
触发修复（Remediation Trigger）: 使用开源项目 Node Healthcheck Operator。它监控节点Condition，当匹配到预设的故障条件（如“GPU设备故障”持续2分钟）时，自动创建一个 NodeRemediation 自定义资源。
执行修复（Remediation Execution）: 修复引擎接收到 NodeRemediation 资源后，按照分级升级（Escalating）策略执行修复操作。例如：
- 第一级：重启节点。
- 若失败，第二级：通过IPMI进行电源循环。
- 若再失败，第三级：标记节点需人工介入，并发出告警。
驱动维护流程: 整个修复过程会被包装成一个 maintenanceType: Unplanned 的 NotifyMaintenance 任务，并遵循前述的状态机流程（驱逐、修复、验证、返回生产）。
验证（Validation）: 修复完成后，执行简单的健全性检查（例如，确认主机上所有预期的GPU都存在），确保节点真正健康。
告警与熔断（Alerting & Circuit Breaking）: 为避免对持续故障的节点进行无意义的重试，他们设置了告警规则。例如，如果某个节点在90分钟内被修复超过2次，则触发告警并可能暂停对该节点的自动修复。

通过这套系统，NVIDIA实现了日均每1000个节点约19次自动化修复，在大规模下相当于每天近千次修复操作，极大解放了工程师的生产力。

未来展望：舰队级维护协调

当前架构主要针对单个集群内的维护。未来的方向是舰队级（Fleet-Level）维护协调。

目标是实现一个分层调度系统：

在舰队层面，维护调度器根据全局因素（如数据中心区域负载、季节性流量模式、活跃事件）决定在何时、何地（哪个区域）执行维护。
然后，它向目标区域的数据中心集群发起批量创建 NotifyMaintenance 任务的指令。
集群内的调度器和控制器再根据本地策略和状态，决定具体对哪些节点、以何种顺序执行维护，并驱动整个流程。

这将实现更智能、更全局化的资源维护优化。

总结与开源

本节课中我们一起学习了NVIDIA如何通过设计 Notify Maintenance API 这一Kubernetes原生状态机，来解决超大规模GPU基础设施的维护难题。核心要点包括：

哲学：在生产中维修“赛车”，确保用户零影响。
核心：用CRD定义维护状态机（8个状态），实现操作标准化与可追踪。
架构：围绕状态机构建控制器生态系统，实现关注点分离和高度自动化。
应用：特别在自动化故障修复场景下成效显著，通过检测、触发、分级修复、验证的流水线，日均处理大量故障。
未来：向舰队级智能调度演进。

NVIDIA已将 Notify Maintenance API 的核心思想在开源项目 PCA（Pod Controller Assistant） 中体现，并积极参与Kubernetes社区关于节点维护的KEP讨论。他们欢迎社区共同参与，探讨如何更好地在大规模、异构加速器环境中进行运维管理。

029：提升 Pod 可用性——多种管理工作负载中断方式的探讨

概述

在本节课中，我们将探讨 Kubernetes 中 Pod 中断的各种类型，并学习如何通过不同的策略和最佳实践来管理工作负载的可用性。我们将从定义中断开始，逐步深入到具体的场景和应对措施，特别是针对那些难以中断的“慢速退出”应用。

什么是 Pod 中断？

Pod 中断是指任何在应用程序自行退出之前中断 Pod 运行的事件。这是一个非常宽泛的定义，涵盖了多种情况。

Kubernetes 官方文档甚至为此提供了一个分类法，将其分为非自愿中断和自愿中断。

中断的分类与应对策略

上一节我们定义了 Pod 中断。本节中，我们来看看 Kubernetes 对中断的分类，并探讨相应的最佳实践。

我们可以将中断大致分为三类：

非自愿中断（左侧）：Kubernetes 文档称之为“非自愿中断”。这包括硬件故障、操作系统故障、网络故障等“宕机”事件，它们会突然停止你的 Pod。资源不足导致的驱逐也属于此类。
自愿中断（右侧）：这主要是由应用所有者发起的操作，例如滚动更新、删除或重启 Deployment。
集群管理操作（中间）：这是一个有趣且“自愿”程度取决于云服务提供商的类别。它包括任何导致节点排空的操作，例如升级、缩容、节点修复等。我们将花较多时间讨论这个类别。

这种分类主要关注 Kubernetes 机制对不同中断源的反应。但我们也可以从另一个角度思考：这是好的中断还是坏的中断？当然，这是一个定性定义。

好的中断：Pod 在你希望它被中断时被中断。
坏的中断：Pod 在意料之外的时间被中断。

基于这个视角，我们可以重新审视之前的分类，并围绕这些中断源描述最佳实践。

应对“宕机”类事件

对于“硬件/软件故障”这类广泛的非自愿中断，它通常属于坏的中断，主要由硬件和软件质量驱动。

这里的核心最佳实践是：为故障而设计。

除了确保硬件/软件质量和及时打补丁（这本身是一个大话题），Kubernetes 也能提供帮助：

使用反亲和性 和 拓扑分布约束：确保复制的应用 Pod 分散在不同的节点或可用区上。

应对应用所有者发起的中断

这类中断（如配置变更、滚动更新）通常属于好的中断。

这里的核心最佳实践是：健全的变更管理。

例如，使用 GitOps 流程并进行适当的代码审查。其他实践包括内部采用的多方授权机制，以确保手动变更至少有人监督。

Kubernetes 本身也提供了帮助，例如 Deployment 的滚动更新策略。但有一个重要的工具需要特别提及：Pod 中断预算，因为它与我们后面要讨论的主题密切相关。

以下是关于 PDB 的要点：

PDB 指定了中断限制，例如“最多一个 Pod 不可用”或“必须有 80% 的 Pod 可用”。
它主要用于保护复制的应用，并可用于任何可伸缩的资源。
大多数自愿中断源都会遵守 PDB。
一个例外是资源不足驱逐，PDB 在此情况下只是“尽力而为”。

如果你还没有使用 PDB，你应该开始使用。

应对资源不足驱逐

资源不足驱逐是一个有趣的类别。Kubernetes 分类法将其归为非自愿中断，因为在此情况下需要快速做出决策。但它也并非完全“非自愿”，因为你可以自愿配置集群以允许此类驱逐。

这是一个广泛的话题，涉及如何权衡。例如：

如果为特定 Pod 调优以获得最高可靠性，你可能需要避免节点资源过度使用（即请求等于限制）。
但通常，人们喜欢过度使用节点资源以节省成本，这取决于工作负载类型。此时，Pod 优先级 就变得很重要。

资源不足驱逐是 PDB 仅被“尽力而为”遵守的情况之一。特别是当节点负载过高必须驱逐某些 Pod 时，PDB 可能完全不被遵守。

聚焦：集群管理操作与节点排空

现在，让我们深入探讨中间类别：集群管理操作，特别是节点排空。

如今，这些操作大多由自动化驱动，例如集群自动扩缩容、升级和节点修复。我将在接下来的内容中重点讨论这个领域，因为在不同的云服务提供商和实现方案之间，这里存在许多差异。

案例研究：游戏服务器（Agones）

我们通过一个具体的案例来研究这个问题：Agones，一个用于在云中运行专用游戏服务器的框架。

游戏服务器是 Kubernetes 中断管理的一个有趣案例：

问题：每个 Pod 都是一个游戏会话，拥有自己的内存状态（游戏模拟状态）。会话持续时间从几分钟到数小时甚至更长（如 MMO）。
挑战：为游戏服务器实现合理的检查点/重启机制，在成本、复杂性和游戏设计上存在权衡。
后果：对游戏服务器的坏中断意味着“游戏结束”，导致玩家连接断开，给公司带来声誉损失，甚至造成实际的经济损失。

这个场景也适用于 AI 训练任务或 HPC 工作负载，中断一个运行在昂贵 GPU 上的任务可能导致高昂的恢复成本。

对于这些“不能失败”的 Pod，集群管理员面临独特的挑战：

应对“宕机”事件：游戏结束。缓解措施是提高硬件/软件质量、加强监控，以便更早地将节点移出服务。
应对资源不足驱逐：确保这些内存状态重要且难以检查点的工作负载拥有良好的资源管理（设置合理的请求和限制），并配置适当的 Pod 优先级。
应对集群管理自动化操作：这是我们接下来要详细讨论的。

为什么需要自动化？

为什么我们要关心自动化？因为云服务提供商（包括 Google）希望用户尽可能使用自动化，这对双方都有利。

集群自动扩缩容：你希望它能够缩容节点，特别是对于具有周期性负载（如昼夜、周末高峰）的游戏服务器舰队，手动管理是不现实的。
节点升级：你希望保持软件更新。
不使用自动化：意味着将运维负担留给自己，并可能浪费硬件资源。

因此，对于这些难以中断的应用，存在一个有趣的张力：既需要自动化来管理效率和成本，又需要保护关键工作负载不被意外中断。

节点排空的工作原理

当自动化或管理员想要将一个节点移出服务时，Kubernetes 的节点排空过程如下：

等待并尝试遵守 PDB：如果驱逐某个 Pod 会违反 PDB，则等待。
优雅终止 Pod：遵守 terminationGracePeriodSeconds（终止宽限期）。

然而，根据你的云服务提供商和配置，上述过程可能并不总是完全按预期工作。

深入：终止宽限期

当 Kubernetes 想要在这些自愿驱逐情况下停止一个 Pod 时：

在 terminationGracePeriodSeconds 期间，如果定义了 preStop 钩子，则运行它。
在 preStop 钩子运行后，向应用程序发送 SIGTERM 信号。
如果 terminationGracePeriodSeconds 过后 Pod 仍在运行，则发送 SIGKILL。

因此，terminationGracePeriodSeconds 实质上是 Pod 的清理期，默认值为 30 秒。大多数 Pod 驱逐都会“尽力”遵守某个宽限期。

快速退出 vs. 慢速退出应用

基于我们对游戏服务器案例和终止宽限期的理解，可以进一步细化分类：快速退出应用 和 慢速退出应用。

快速退出应用：Pod 可以在 10 分钟 内被驱逐（这个时间点与集群自动扩缩容的默认设置有关）。这涵盖了大多数 RPC/HTTP 服务器，以及将状态维护在磁盘上的有状态工作负载（如数据库），它们通常可以在此时间内完成检查点。
慢速退出应用：其他所有工作负载。丢失内存状态的代价很高，可能是金钱（训练任务）或声誉（游戏服务器）。例如：游戏会话服务器、语音聊天、实时视频转码、AI 训练任务、HPC 批处理作业。

自动化带来的挑战与云提供商差异

现在，我们来谈谈为什么允许自动化对慢速退出应用来说是一个挑战。首要原因是：云服务提供商选择了不同的机制。

1. 升级操作：

GKE（标准版，激增升级）：如果 PDB 加上终止宽限期总时间超过 1 小时，则会中断你的 Pod。升级操作本身具有优先级。
AKS 和 EKS：在 15 或 30 分钟（可配置）后，升级操作会失败。它们选择将运维负担更多地转移给执行升级的管理员。

建议：

A. 根据你的提供商，你可能可以调整与中断相关的升级操作超时。
B. 许多云提供商开始提供自动蓝绿升级，即一边缩容一个节点池/节点集，另一边扩容另一个。

2. 自动扩缩容器：

Cluster Autoscaler 和 Karpenter 都遵守 PDB 和 terminationGracePeriodSeconds，但都有限制。
Cluster Autoscaler 默认在 10 分钟 后就会终止你的 Pod，无论 terminationGracePeriodSeconds 设置为何值。没有警告、状态或注解。
Karpenter 使用可配置的每个节点最大值。
两者都有一个神奇的注解（如 cluster-autoscaler.kubernetes.io/safe-to-evict: "false"）可以阻止驱逐。

针对慢速退出应用的最佳实践

鉴于以上情况，以下是一些针对慢速退出应用的最佳实践：

确保应用支持 SIGTERM：如果你想支持自动化，就需要与现有的驱逐系统合作。对于遗留应用，可以使用 preStop 钩子来拦截 SIGTERM，但这有点棘手。
调整 Pod 规范中的 terminationGracePeriodSeconds。
调整自动扩缩容器的最大终止宽限期：Cluster Autoscaler 和 Karpenter 都支持调整此值。
调整升级超时或研究自动蓝绿升级：如果你的工作负载需要运行一小时，可能也需要调整此项。
（高级）尝试将慢速退出应用调度到相同的节点上：通常你也希望它们能在相近的时间终止。这是一个更深入的话题，但值得尝试。

进阶思路：构建可移植的中断策略

在 Agones 中，我们尝试构建一个驱逐 API 来简化此事。核心思想是：通过一个标签（如 agones.dev/safe-to-evict）来声明 Pod 是否可安全驱逐，然后根据目标环境将其转换为适当的策略。

即使你不使用 Agones，也可以实现类似的效果：

如果你的工作负载都支持 SIGTERM（即“云原生”应用），你可以将 terminationGracePeriodSeconds 作为一个指标。
你可以使用策略引擎或自定义 Webhook 来执行适合你工作负载的策略。例如，如果 terminationGracePeriodSeconds 大于某个值，则自动为其添加 safe-to-evict: "false" 注解，并确保它们被调度到配置了适当升级和扩缩容超时的节点池或集群上。

这有助于使你的工作负载在不同云环境或不同自动扩缩容方案之间更具可移植性。

实现此类方案需要考虑两个最重要的问题：

应用是否正确处理了 SIGTERM？
发送 SIGTERM 后，需要多长时间才能安全终止？（即 terminationGracePeriodSeconds 的设定）

总结

本节课中，我们一起学习了 Kubernetes 中 Pod 中断管理的多个方面：

Pod 中断是权衡的艺术：它是一个涉及成本、人工运维、应用复杂性等多变量的决策问题。
思考中断的成本：中断并非二元（能/不能），而是与“中断这个特定 Pod 的代价是什么”相关。需要据此进行设计。
给应用所有者的建议：思考是否能引入检查点机制，或者其成本（复杂性、资源）是否过高。
给管理员的建议：
- 对于快速退出应用：确保调优 PDB，考虑拓扑分布等。
- 对于慢速退出应用：确保调优 terminationGracePeriodSeconds，并相应地配置自动化工具（扩缩容器、升级策略）。

通过理解中断的类型、成本以及 Kubernetes 和云平台提供的各种控制机制，你可以更好地设计和管理工作负载，在可靠性、成本与运维效率之间找到最佳平衡点。

030：Kubernetes集群上的分布式缓存系统 🚀

在本教程中，我们将学习如何在Kubernetes集群上构建一个名为“简单缓存服务”的分布式缓存系统，并探讨它如何赋能人工智能和机器学习工作负载。我们将从背景介绍开始，逐步深入到系统设计、实现细节、实际用例以及性能优化技术。

背景：Kubernetes上的AI/ML工作负载

首先，我们介绍人工智能和机器学习工作负载的背景。考虑一个训练机器学习模型来识别手写数字的场景。我们有一个包含数字图像的数据集和一个深度神经网络的训练任务。在Kubernetes中，这对应着多个Pod。这些Pod会访问数据并获取数据样本，然后用这些样本填充深度神经网络，从而优化模型。通过持续这个过程，深度神经网络最终能够识别数字。

接下来，我们看看存储这些数据的策略。作为一家拥有本地集群的AI/ML公司，我们需要本地解决方案。

存储策略分析

以下是几种常见的存储策略及其优缺点：

网络文件系统：我们可以使用主机路径卷将NFS存储挂载到Kubernetes Pod。如果NFS服务器拥有快速的直连驱动器和强大的CPU，并且客户端数量有限，其性能是可以接受的。然而，当大量客户端同时访问NFS时，很容易出现性能下降。
对象存储：我们使用开源软件（如MinIO）构建了与S3兼容的本地对象存储，后端使用硬件磁盘驱动器。通过添加新的硬件磁盘条带，我们可以扩展其性能和容量。但实际上，硬盘驱动器的性能不足以支持数据集的随机读取需求，因此它不能作为数据集读取的解决方案。
节点本地存储：我们的配备AI加速器的计算节点拥有额外的NVMe驱动器，设计用作AI/ML工作负载的临时卷。这里的问题是，当工作负载迁移到不同的计算节点时，数据将变得不可访问。例如，数据集首先被调度到计算节点A，工作流将数据集缓存到该节点的本地存储。之后，工作负载可能被抢占，并幸运地迁移到另一个计算节点B。此时，我们无法访问计算节点A上的缓存数据，必须重新获取数据，这非常耗时。因此，节点本地存储本身有助于训练，但不能作为最终的存储解决方案。此外，如果训练所需的数据集大小超过其容量，我们就无法将其用作缓存存储，因此它不具备可扩展性。

理想存储架构

这是我们为AI/ML工作负载设计的理想存储架构。我们计划结合对象存储和节点本地存储来构建一个分层缓存系统。Pod将访问快速的NVMe驱动器缓存，如果数据存在于缓存中，我们可以跳过对对象存储的访问。如果数据不存在于缓存中，则必须访问对象存储。通过向对象存储添加新的硬盘驱动器，存储容量是可扩展的；通过添加新的计算节点或新的NVMe设备，吞吐量也是可扩展的。因此，我们认为这是适合AI/ML工作负载的基础解决方案。

在本节中，我们将介绍基于云原生技术的分层存储解决方案。利用Kubernetes的特性（如服务发现、身份验证）和Envoy的功能（如其负载均衡技术和灵活性），开发解决方案似乎很困难，但我们实际上可以非常轻松地开发出这个存储系统。

核心组件：简单缓存服务介绍

上一节我们介绍了AI/ML工作负载的存储挑战，本节中我们来看看为解决这些问题而设计的核心系统——简单缓存服务。

SGS是一个采用简单、共享无状态架构的缓存服务。它拥有非常基础的HTTP GET/PUT接口，当用户获取数据时，它只是返回节点本地文件。它极其简单且快速。同时，SGS为云原生环境设计，它部署在Kubernetes集群中，并大量使用Kubernetes特性来减少我们自己的实现工作。此外，SGS采用共享无状态架构，这至关重要，因为它使得SGS能够实现线性扩展。另一个需要注意的重点是，SGS只是一个缓存服务，而非持久化存储。换句话说，不需要永久保存数据，删除缓存数据是可以接受的。

基本使用方式

以下是如何使用curl命令实际使用SGS的示例。这非常简单直接。

第一个curl命令将缓存数据（一个JPEG文件）存储到SGS中，第二个命令则从快速的缓存存储中获取该数据。

让我们更仔细地看一下。首先看HTTP方法。第一个curl使用PUT来存储数据，第二个使用GET来获取数据。这很自然。接下来是URL。你首先会注意到它使用了HTTP和Kubernetes服务。如果你查看URL的路径，它明确指定了桶和对象。在这个例子中，桶是project1，对象是apple.jpg。最后是身份验证部分，我们稍后会讨论。请记住，Authorization头是必需的。在这一部分，我们通过充分利用Kubernetes的Service Account Token特性，减少了自己的实现工作。

系统架构图

让我们看看这些curl命令的路径示意图。下图展示了用户如何访问SGS。用户Pod执行类似于我们刚才演示的curl命令的操作。SGS将缓存的实际数据存储为文件。如前所述，SGS所做的操作只是提供这个文件。

首先你会注意到，在用户Pod和SGS之间存在着Kubernetes服务和Envoy代理。在我们深入更多细节之前，让我们先仔细看看SGS本身。

SGS由三个主要组件构成：SGS应用程序（一个Go语言应用）、NVMe或其他存储缓存数据的设备，以及一个始终保存元数据（如访问时间戳等）的Envoy代理。每个SGS应用程序都有自己的SQLite数据库。在这个例子中，有四个SQLite数据库，因为对应着四个SGS应用程序。当然，每个SGS都作为我们集群中的一个Pod运行，它们通过DaemonSet进行部署。

回到这个架构图。其中一个最重要的特性是共享无状态架构。这意味着每个SGS Pod之间不共享任何像数据库这样的东西。尽管如此，用户可以从任何网络区域访问缓存数据。为了实现这一点，第7层负载均衡使用了一致性哈希算法。

身份验证流程

接下来，这是SGS中的授权流程。它类似于Kubernetes的TokenReview API。如果你使用过它，你会理解这个流程。首先，用户Pod应该挂载服务账户令牌并发送一个令牌审查请求。在验证部分，由SGS负责，它使用TokenReview API来验证令牌。服务账户令牌包含了资源所属的命名空间信息，这可以用于身份验证。因此，用户可以指定能够访问存储桶的命名空间。

存储桶定义与管理

我们可以像这样定义一个存储桶。存储桶有两种类型：公共和私有。顶部橙色部分是名为“公共存储桶”的存储桶，任何人都可以访问。下面的蓝色部分称为“私有存储桶”，基于Kubernetes命名空间进行身份验证。可以列出允许访问该存储桶的命名空间。例如，project-kubernetes和user-demo命名空间被允许访问bucket1存储桶。还可以在存储桶的quota字段中为每个存储桶设置存储限制。如果超过指定容量，存储桶将基于LRU策略删除缓存数据。

这张图展示了数据是如何基于LRU被删除的。首先看颜色，每种颜色代表一个存储桶。随着时间的推移，它们被加载了越来越多的数据。蓝色阴影中的点是为每个存储桶分配的最大容量。一旦达到这个点，每个存储桶的容量就不再增加，这意味着基于LRU的数据删除从这里开始了。

实际应用场景

在了解了SGS的核心架构后，本节我们来看看它在实际生产环境中的两个应用场景。

我们将介绍两个用例。第一个用例是将SGS用作吞吐量存储的缓存。开发SGS的动机正是源于此，它加速了数据集读取的数据加载过程。第二个用例是将SGS作为另一个缓存服务的存储后端。让我们深入探讨一下。

用例一：对象存储缓存

首先，考虑从类似S3的对象存储加载数据的情况。为了提高I/O性能，我们为研究人员开发了PFIO库。由于它是开源的，你现在就可以查看。Python中的源代码是一个仅用10行代码从对象存储获取JPEG文件的示例代码。此外，PFIO具有透明缓存功能。只需向from_url函数添加hf_cache参数，PFIO就会自动缓存内容，并在下次从SGS获取。如果文件在SGS中命中，读取延迟得到改善，因为我们可以跳过从对象存储获取并放入SGS的步骤。

用例二：其他缓存服务的后端

接下来，让我们看看如何将SGS用作另一个缓存服务的存储后端。我们还有一些尚未提及的大型文件。首先是容器镜像。用于AI和ML工作负载的容器镜像越来越大。我们早期的容器镜像管理是研究人员的首选，它超过30GB。我们已经对其进行了预热，上周，94%的容器镜像拉取命中了SGS。另一个是模型。众所周知，大语言模型非常庞大。有时我们的研究人员在Hugging Face上评估公共的大语言模型，因此我们缓存了它们。这两种文件都具有临时性、大容量和访问热点的特征。通常，我们使用最新的容器镜像，因此过时的容器镜像应该被删除。这由SGS的驱逐策略来处理。因此，SGS与这些文件的缓存服务组合工作得非常好。

这是一个实现另一个缓存的例子。当然，SGS被用作存储后端。另一个缓存必须实现几个功能，如访问原始服务、访问SGS、用户界面、从原始键到SGS的URL映射等。然而，像缓存驱逐和容量控制这样难以实现的存储管理功能，已经在SGS中实现了。因此，构建另一个缓存变得更加容易。

部署与性能优化

在探讨了实际用例后，本节我们将讨论简单缓存服务的部署，并聚焦于两个关键的优化问题。

这里我们有两个问题来优化部署。第一个是，如何优化用户Pod和Envoy之间的网络流量？我们使用Kubernetes服务来发现Envoy Pod。这里我们将考虑Kubernetes服务的配置和Envoy的部署。另一个是，如何配置你的Envoy以将流量路由到SGS？通过考虑这两个问题，我们可以优化从用户Pod到SGS Pod的端到端数据流。

网络拓扑与流量优化

首先，让我描述一下SGS当前运行的计算基础设施背景。我们是Preferred Networks，一家人工智能和机器学习公司。我们正在开发像我们的大语言模型这样的机器学习模型，以及许多面向行业的解决方案。这些活动使用我们自己的本地计算基础设施。我们拥有三个用于生产的Kubernetes集群，以及几个用于评估和预发布的集群。总计有超过400个Kubernetes节点，包含30,000个CPU核心、300 TB内存以及用于机器学习模型训练的2,000个GPU。同时，我们正在开发和运营我们自己的名为MN-Core的AI加速器芯片，因此我们几乎从事AI加速器从RTL、板卡设计、服务器设计、驱动程序到Kubernetes设备插件以及图编译器的所有工作。

我还想介绍一下数据中心网络。我们公司Preferred Networks使用Clos网络技术。Clos网络使用叶交换机、深度交换机、脊交换机和外部超级脊交换机。叶交换机是离计算节点最近的交换机。在这里，我们可以根据每个叶交换机定义四个网络区域：区域A、B、C和D。因为位于同一叶交换机下的三个节点可以以无阻塞性能进行通信。然而，不同区域（如区域A和区域B）之间的通信需要经过深度交换机和脊交换机的通信，因此叶交换机和脊交换机之间的网络链路是超额订阅的。换句话说，上行链路比下行链路窄。因此，如果一个网络区域中的旧节点尝试与不同区域通信，就会发生拥塞。所以，我们必须尽可能避免区域间通信，以节省上行链路。

好的，我已经描述了背景。现在让我们考虑从用户Pod到Envoy Pod的网络流量。首先，作为假设，SGS被部署到所有计算节点，以有效利用所有本地NVMe驱动器。同时，用户Pod可能被调度到任何节点，因为所有计算节点都拥有昂贵的加速器，所以让计算资源闲置是没有意义的。那么，在哪里部署Envoy呢？我们决定将Envoy部署到所有计算节点。通过这样做，我们可以减少用户Pod和Envoy Pod之间的网络流量。然而，我们无法优化Envoy和SGS之间的区域间流量，因为SGS已经部署在所有计算节点上，所以我们无法优化区域内的流量。

Kubernetes服务策略

接下来，我想考虑Kubernetes服务的配置，以减少区域间流量。换句话说，以拓扑感知的方式进行通信。我们在所有计算节点上都有用户Pod和Envoy Pod。因此，有两种方法可以减少区域内流量。一种是内部流量策略，另一种是拓扑感知路由。让我们从内部流量策略开始讨论。内部流量策略将通信限制在服务内部，因此如果服务有许多Envoy Pod作为后端，内部流量策略只将流量路由到同一节点内的Pod，这样我们就不会在计算节点之间产生通信。拓扑感知路由将流量路由到同一区域，因此在这种情况下，我们有三个Envoy Pod来路由流量。它需要在同一区域内进行通信，但不需要在不同区域之间。因此，从网络角度来看，内部流量策略似乎优于拓扑感知路由。然而，从Envoy的CPU负载角度来看，我们得出了不同的结论。内部流量策略不会将流量路由到其他两个Pod，因此，如果某个节点大量使用SGS，我们可以看到该节点中Envoy的高CPU使用率。由于我们将Envoy部署为DaemonSet，因此无法以细粒度的方式增加CPU资源请求。然而，拓扑感知路由利用了三个Envoy后端，因此CPU负载得到平衡。因此，在我们的拓扑中可以看到更一致的延迟数字。所以，我们使用拓扑感知路由来改善Envoy的CPU负载影响，这在网络流量和负载均衡之间取得了良好的平衡。

Envoy负载均衡配置

下一个问题是如何配置Envoy来路由流量，因此我们将考虑数据流的最后一部分。在这里，让我们考虑键的负载均衡。在SGS中，键对应于存储桶和对象。在这个设计中，我们希望将流量从Envoy一致地路由到SGS。“一致”意味着当我们把一个对象放入某个SGS时，我们希望从同一个SGS获取它。否则，我们将无法获取之前放入的对象。实现这一点的最简单方法是引入从存储桶和对象到SGS后端ID的映射。这会引入一个共享数据库，但有时共享数据库的性能会下降。虽然这可以是一个解决方案，但我们希望使用更简单、更可扩展的方式。因此，这里我们不共享数据库，而是共享用于确定哪个后端负责的函数。我们引入了从存储桶和对象到某个数字的哈希函数，然后根据这个数字决定负责的后端。

确定负责后端的最简单计算方法是直接将哈希值除以后端数量，然后使用余数。这种方法的问题是，当后端数量发生变化时，几乎所有的映射都会改变。这通常发生在节点故障和节点安装期间，因此我们应该避免这种情况。一致性哈希是一种解决这个问题的方法。它旨在减少这种重新映射，因此我们可以预期更低的重新映射率。键的数量除以后端数量就是重新映射的数量。Envoy有两种一致性哈希实现。一种是环哈希。首先，它通过哈希后端信息准备一个带有负责后端的环。当访问发生时，它计算键的哈希值，然后从环中搜索负责的后端。另一种是Maglev哈希。Maglev管理一组负责的哈希槽。两种映射都是从后端信息计算出来的，因此所有Envoy Pod共享这个映射。因此，我们可以在所有Envoy Pod中看到一致的映射。

键的负载均衡非常重要。负责更多键的后端会有几个问题。在这个图中，你可以看到后端3的弧长是后端4的1.5倍。因此，后端3的责任是后端4的1.5倍。这应该避免，因为它会影响性能。后端3的CPU使用率是后端4的1.5倍，因此它可能导致更长的延迟数字。此外，后端3中每个数据的生命周期比后端4短。因此，后端节点发生驱逐的可能性更大。在这里，我们希望看到一致的资源使用率及其生命周期，我们需要一个具有一致键映射大小的一致性哈希算法。

让我们检查两种一致性哈希算法的负载不平衡情况。在这个图中，环哈希的负载不平衡高达1.5倍，然而，Maglev没有引入任何负载不平衡。让我们看看按节点统计的对象数量的截图。该截图取自我们的生产环境。每条线对应每个节点的对象数量，正如你所见，当使用环哈希时，你可以看到带有一些差异的多条线；然而，当使用Maglev时，你只能看到单条线。但实际上有多条线，这意味着Maglev算法的负载均衡是完美的。这就是我们使用Maglev的原因。

性能表现与总结

我们已经将SGS部署到生产环境中，现在让我们检查一下性能数据。这是我们过去30天的每秒API请求数。正如你所见，最高达到每秒37,000次请求。同时，这是我们过去30天的每秒聚合吞吐量。正如你所见，最高达到每秒75 GB的聚合吞吐流量。总结来说，我们仅用55个后端服务器就实现了每秒37,000次请求和每秒75 GB的吞吐量。我认为这并不是很多后端服务器，而且这个数字来自真实世界，而非合成基准测试。目前，我们服务着2.68亿个对象。对SGS的请求确实很密集，我们正在持续监控未命中率，以便及时扩展缓存容量。

课程总结

本节课中我们一起学习了我们的缓存系统——简单缓存服务。它采用共享无状态架构设计，以实现线性扩展。这通过Envoy的一致性哈希算法轻松实现。同时，我们遵循云原生最佳实践，如利用Kubernetes的服务账户令牌来实现轻松的身份验证。因此，我们的系统可以与PFIO或类似库一起用作对象存储的透明缓存。现在，我们在Web中使用SGS，例如用于数据读取和大模型服务。我们使用了几种优化技术，如拓扑感知路由和Maglev哈希。我们的项目得到了云原生技术和我们三位核心成员的支持。

问答环节摘要

问：出于好奇，您没有选择集群文件系统（如GPFS、Lustre或Weka）的原因是什么？我已经使用可扩展存储很长时间了，它比NFS可扩展得多。我的集群今天有80 PB的存储，超过1,000个节点和120,000个核心。我很好奇您为什么排除了这个选项。

答：我认为仅仅使用集群或其他类似GPFS的共享文件系统可以是一个解决方案，但实际上我还没有尝试过这样的大型共享文件系统。运营这样的大型存储集群可能存在一些困难，但通过应用云原生技术来管理我们自己的Kubernetes集群，我们可以更轻松地获得存储解决方案，我们认为这些解决方案更容易使用。

031：整合解决方案的影响与社区协作

在本节课中，我们将学习如何有效参与KServe开源社区，以及将解决方案整合到社区中所带来的广泛影响。我们将通过一个专家小组的讨论，了解社区协作的现状、挑战、成功经验以及对未来的展望。

专家介绍

大家好，我们将开始本次讨论。我们有五位小组成员，将用35分钟完成本次分享。首先，请各位进行自我介绍。

Tenny Mibrahim：我是Red Hat Openshift AI Engine团队的软件工程经理。我的团队在KServe社区、Kubeflow社区以及TrustyAI和模型注册表方面进行密切合作。
Tessa Fam：大家好，我是彭博社AI推理团队的软件工程师，也是KServe的贡献者。我的团队致力于为彭博社的数据科学家和工程师构建和维护推理平台。我们的团队负责人Danson在2019年共同创立了KServe。此后，我们团队对KServe做出了贡献，并将其集成到推理平台和其他内部项目中。
Jon George：大家好，我是Nutanix AI的技术总监。在日常工作中，我身兼两职。在Nutanix内部，我领导所有AI活动。在开源领域，我领导几个ML社区，包括Kubeflow和ML Commons。Kubeflow是Kubernetes上的MLOps平台。我是Kubeflow指导委员会的成员。在ML Commons，我们共同创立了ML Commons存储工作组，该工作组关注ML训练期间工作负载的存储影响。
Andrea Montano：大家好，我是Canonical的ML产品经理，Canonical是Ubuntu的发行商。我负责我们的AI/ML产品组合，其中包括已经提到的Kubeflow和KServe，以及其他工具，例如MLflow，以及旨在帮助开发者在Ubuntu工作站上快速入门的数据科学堆栈。
Adam Tleman：大家好，我是NVIDIA的首席产品架构师。我没有像小组其他成员那样为众多项目做出贡献，但我已经使用所有这些项目很多年了。我使用Kubeflow、KServe及其所有依赖项目。我们进行这次小组讨论的原因是，NVIDIA推出了一款新的AI应用程序产品，我认为将其推向市场并展示给用户的最佳方式是确保它在KServe和开源项目上运行良好。因此，我一直与在座的各位密切合作以实现这一目标。这次小组讨论正是关于在开源社区中协作的历程。

社区协作的现状与价值

上一节我们认识了各位专家，本节中我们来看看他们参与KServe社区协作的亲身经历、面临的挑战以及取得的成就，特别是在AI、LLMs和生成式AI等新领域。

Andrea Montano：我在开源领域活跃了相当长的时间。回顾过去，我最初面临的最大挑战是如何开始，特别是如果你想做出贡献，你该如何实际参与。感觉有很多优秀的开发者，但每个人对于需要做什么以及如何做都有自己的看法。这是在一个社区内成为贡献者的初始挑战。我注意到许多Kubeflow的新加入者也面临同样的困难，尤其是因为它是一个大型平台，最初并不容易上手。这常常令人望而生畏。因此，我非常享受与其他开发者合作，特别是帮助那些在ML领域和开源领域刚起步的人降低入门门槛，让他们真正感到舒适地提出问题、解决问题、询问疑问、改进文档等所有小事。此外，编写项目也很重要。我认为，拥有像Kubeflow这样强大的平台，如果没有能帮助你入门的项目，比如构建你的第一个模型、找到新的LLM或与Kubernetes和Kubeflow一起运行新模型，那么这些项目正是降低门槛、帮助人们入门的关键。

Jon George：我自己从一开始就参与了KServe。看到这个社区发展到如此规模，我感到非常高兴。感谢所有开发者，这一切始于在Kubeflow中训练TensorFlow模型，然后使用TFServing服务相同的TensorFlow模型。从那时起，它已经发展成为一个可以在任何基础设施上大规模运行所有这些大型语言模型的大型框架。最近，我们宣布了Nutanix AI，它以KServe为核心，提供一键部署你选择的大规模语言模型，而无需了解底层系统。如果没有像KServe这样的项目，这是不可能实现的，这是我们作为KServe社区一部分共同努力的成果。如果你仔细想想，它是由许多构建块组合在一起的，就像许多东西汇聚在一起，人们贡献不同的部分，然后整合到一个单一的项目中。所有这些不同的构建块，如果你看面向用户的API，它是开放推理协议的一部分。我们出于某种原因将其放在KServe之外，因为我们希望推理协议也能被其他社区使用。例如，A2I、VTrit等所有人都使用相同的推理协议，而KServe现在也完全实现了它。下一个领域是关于推理运行时，用户可以带来任何你选择的运行时，并通过一个YAML文件将其插入KServe，无需任何代码更改，无论是NVIDIA NIM、vLLM还是任何你选择的运行时。最后，整个堆栈可以在任何硬件上运行，无论是GPU、CPU、AMD加速器还是任何其他硬件。从某种意义上说，这是一个集体项目，是一个社区产品，可以将所有这些构建块整合在一起，这是KServe的核心优势。

Tessa Fam：我想从我的个人经历开始说起。我在2022年加入彭博社推理团队后不久，就向KServe做出了我的第一次贡献。我从为KServe贡献的多个PR中发现，整个过程令人惊喜地简单。贡献不仅计入我内部的工作，还能帮助其他公司面临相同问题的人们。识别问题非常容易，因为我们都在这里，我们都知道存在许多共同的挑战，我们都在努力解决。提出问题和提出自己的解决方案，提交给更广泛的KServe社区，获得PR审查、反馈并合并，这个过程非常容易。一旦你的更改生效，它将为你企业的产品解决问题，同时也会为你甚至不认识的其他许多人解决问题。我认为这就是我在开源社区中亲身经历的力量。谈到开源社区的独特好处，数不胜数。你首先要认识到，所有这些都是免费提供给我们的，我们以零成本从更广泛的社区获得最快的众包解决方案。这是你从需要付费且受供应商限制的企业产品中无法获得的首要好处。其次，一旦你参与到开源社区中，你会发现有如此多的协作在进行，每天都有很多创新，人们提出解决方案，聚在一起讨论问题。更酷的是，你正在与来自不同公司、从未谋面、如果只在自己公司工作就没有机会合作的人们协作。最后，仅仅利用更广泛社区的资源和人们聚集在一起的力量，不为别的，只为找到他们和其他人面临的问题的解决方案，你将找到更快的解决方案，更高效。同时，当你回馈社区时，你也会得到同样的回报。这些都是任何人从开源中获得的独特好处，无论是推理AI还是任何开源项目。但同时，也必须认识到其中的挑战，我想谈谈AI领域特有的挑战。

随着近年来LLM的蓬勃发展，模型变得越来越大，我们都希望优化资源和时间、模型启动时间等。作为一个社区，我们共同努力，并正在设计解决方案来解决这些问题。但对于KServe来说，为了使项目变得更好，我们必须同时解决所有这些领域的问题，而每个领域都需要深厚的专业知识。这就是为什么我们每天都在与不同的公司、合作伙伴和其他项目合作，以实现这些解决方案。

Jon George：说到Tessa提到的社区协作和开源力量，如果你想想我们最近启动的WG Serving社区，最近的一大成功是有超过250名成员加入了该社区。这是一个伞式项目，旨在解决LLM推理带来的挑战，以及如何在Kubernetes中以云原生的方式跨越多家公司解决这些问题。这是一个快乐的大家庭。另一个有趣的领域是网关项目，我们的彭博社朋友和其他人一直在密切贡献，因为大模型面临的挑战之一也是能够高效地路由它们。你如何知道将请求路由到哪个模型？有时你可能需要SLO、成本考虑，有些模型可能在CPU上推理效果很好，有些模型可能在GPU上效果很好。因此，你需要了解不同的加速器。我们与KServe社区密切合作的LLM实例网关项目是帮助解决这个问题的一种方式。对于语言模型，你必须考虑各种新的指标。如果你来自传统的预测性ML模型生命周期，通常你有CPU请求、线程命中数等常见指标。但对于语言模型，你必须考虑KV缓存利用率、批处理大小、排队令牌数等。这些类型的指标对于模型服务或推理工作负载来说是全新的。我们正在使用Kubernetes生态系统中已有的相同工具集，但我们正在为新型工作负载实现它们，并进行大规模部署。我还要说，最近另一个非常酷的成功是Red Hat一直在密切合作的一个项目，即Trust AI（负责任AI）概念。KServe有一个名为“explainer”的实现，你可以将解释器模型连接到KServe端点，并能够运行各种负责任算法，如LIME、SHAP、反事实解释等。我们正在努力为大型语言模型以及不同类型的评估（如LM Eval）添加这些类型的算法，以便你可以很好地评估你的模型。目前，这可以与VLM和KServe一起使用。这是一个非常有趣的项目，因为例如，模型变得越来越大，但你如何知道你的模型是否真的表现良好？仅仅因为你有一个400亿参数的模型，并不意味着它会满足你的工作需求。你的工作可能需要非常特定领域的任务，也许你是一家服务公司，有支持案例，你想进行案例总结，你可能不需要那么大的模型。像LM Eval这样的工具可以帮助你使用LM Harness工具包为你的特定用例评估这些模型。这是一个非常好的成功故事。我还要说，最近社区聚集在一起讨论如何通过有状态Pod集支持真正庞大的模型，并跨各种实现进行研究。我们研究了领导者-工作者模式、无状态部署、有状态Pod集，以及如何确保这些模型可以跨多个节点部署，因为其中一些大模型显然无法再容纳在一个节点中。这是社区协作解决的一个非常有趣的挑战，相关的PR最近也已合并。

Adam Tleman：是的，Tessa，说到你的观点，我记得在我真正深入社区之前，我就在使用这些工具，使用Kubeflow，那大概是五六年前，当时我试图教人们如何使用DGX并训练一个大型BERT模型。Jupyter不够用，因为我需要做流水线，而拥有Kubeflow，我可以直接使用它。它几乎能做所有事情。我能够在大约一周内制作一个研讨会，向人们展示如何训练一个LLM，那是在LLM还没有现在这么大的时候。从个人角度来说，结识你们所有人，进入这个领域，这很有趣。对我来说，这很有趣，我不仅仅是在与我公司的同事合作，还在与许多其他公司的人合作，这其中有乐趣，也有思想的分享。我看到我的世界和我在做的事情，但当我在与Red Hat、Canonical、Nutanix或彭博社的会议中，我了解到你们以略微不同的方式看待世界，所有这些方式都是有效的。思想的分享最终让我们能够解决各种各样的问题，我想你们两位都提到了，外面有大量的用例，我们需要为某些人解决所有这些问题。其中一些问题直到你们在讨论解决方案时展示给我看，我才意识到它们是问题。然后我意识到，是的，在这个层面的缓存对我来说在三个月或六个月内将非常重要，但你们已经解决了两个月，我可以在此基础上继续发展。所以这是一个巨大的胜利。在产品方面，NVIDIA在3月份推出了NVIDIA NIM，这是我们新的AI产品。当我们最初运行时，只有一个docker run命令，然后有人意识到我们需要将其部署到生产环境。所以我们为它构建了一个Helm chart。当我们去找客户时，他们说这很好，这是一个Helm chart，但我正在使用这个平台，或那个平台，或另一个平台。那个Helm chart在生产环境中就绪了吗？我关心的不仅仅是应用程序，我还关心所有这些平台级功能。而我正在开发的是一个应用程序，我不想关心那些平台功能，我想接入它们，但我不想实现所有功能。幸运的是，有一个完整的社区，人们正在以不同的方式实现它们，而我的客户已经是你们的客户。因此，进入KServe社区，与你们合作，围绕LLM实现API标准，实现安全性以及我们一直在研究的一些缓存功能，然后我最初与Red Hat合作进行了POC，让NIM在KServe和Openshift AI上运行，然后它在Nutanix AI、Charmed Kubernetes和所有其他平台上运行。所以它就这样工作了，现在我们所有人都从中受益，我受益，你们受益，我们所有的共同客户都受益。这种与开源社区合作的方式为我节省了大量时间，最终对每个人来说都是有趣且双赢的。我真的很享受这一点，我非常感激，我认为这是一件好事。

Jon George：只想补充一点，Adam谈到的所有这些构建块都是由社区自己定义的。都是社区的需求和社区贡献的功能。是的，在GitHub上。有趣的是，我们还没有完成。你谈到了WG Serving，我们现在有了它。我查看了一些会议记录，有一个很长的待办事项列表。所有这些新项目都在涌现，但这些项目有新的功能需求列表。我们有很多问题需要解决。作为一个社区，我认为我们需要团结起来，因为环顾KubeCon，我听到人们谈论他们如何以不同的方式一遍又一遍地解决同样的问题，每个人都想团结起来一次性解决它，这样我们都能受益。

未来展望与社区参与

上一节我们探讨了社区协作的现状与价值，本节中我们来看看未来的发展方向。有哪些令人兴奋的开源项目？有哪些具体的路线图项目？在LLM/生成式AI领域有哪些挑战？更重要的是，人们如何参与进来？我们如何提供帮助？因为我们在座的每个人都是社区的一部分，明年这个小组的成员可能就是在座的各位，来谈论他们如何取得了帮助他人的巨大胜利。

Jon George：太棒了，谢谢Adam，这是个很好的问题。谈到WG Serving，我们需要人手，我们有很多项目在进行中。如果你在CNCF Slack上（我希望你们都在），有一个WG Serving频道。加入这个频道，你一加入就会看到工作组下的一堆子工作组，主题包括LLM实例网关、LLM缓存项目（基本上是提示缓存）、围绕性能基准测试的项目（标准化如何为不同LLM和支持这些模型部署的不同运行时标准化性能基准测试），以及围绕安全的子委员会。如果你对这些领域感兴趣，那里正在发生各种有趣和令人兴奋的事情。回到你的观点，只有我们得到社区的帮助，这些事情才能发生。那里有太多的工作要做，而参与的人却很少，因此扩展对我们来说至关重要。我个人希望看到的是，也许明年我们谈论的不是如何让推理在KServe上工作，而是谈论更高一层，即我们如何将代理、生成式LLM框架、编排与KServe结合起来。因为推理和资源优化可能在一定程度上已经得到解决，不再是我们必须处理的问题。为了达到这个目标，我们需要在座各位的很多支持和帮助。传播信息，加入WG Serving频道，加入KServe频道，帮助我们加入社区。就路线图而言，我真正兴奋的是另一个项目，它并不完全直接在WG Serving之下，而是在WG Batch之下，即DRA项目（动态资源分配器）。如果你不熟悉，它允许你以声明式的方式为你的Pod分配GPU，就像你为存储声明PVC一样。想想那种相同的概念，但是用于GPU或任何加速器。有趣的部分是，你实际上可以利用分片GPU。也许你的模型是一个20亿或10亿参数的模型，因为它是一个非常专门的模型，你可能不需要消耗整个GPU。DRA允许你以某种方式分割GPU，你可以根据需要的比例进行分配。在此基础上，是另一个最近启动的项目，即即时切片，它允许你进行即时GPU切片。在DRA之上，即时切片使DRA的配置更加简单和容易。我对此感到非常兴奋，因为我认为一旦这个项目达到稳定状态，然后我们在其上运行KServe，并与vLLM社区密切合作，看看我们如何允许今天使用KServe的开发者为通过KServe部署的模型分配这些分片GPU，这将是一个非常令人兴奋的项目，我期待着它的发展。我也期待着LLM网关项目的发展。我认为一旦我们解决了这个问题，以及如何通过KServe进行路由并拥有一个抽象层，那也将使推理优化过程变得非常高效。

Tessa Fam：谢谢Tenny。我认为Tenny为这个问题设定了正确的主题。更具体地谈谈KServe，我们现在正在解决的一个共同主题是如何降低成本，如何降低服务成本并使其更高效。这是所有推理服务器、开源推理服务器现在都在努力解决的问题。有很多关于GPU分片和GPU时间切片的讨论，人们正在尝试寻找不同的解决方案。在KServe方面，我们确实有多个解决方案正在进行中或设计中。我可以举几个例子，我们可以为此感到兴奋，这些是我们在未来一年内将引入KServe的新功能。第一件事是，这些模型，所有的AOM模型都变得越来越大，我们需要减少模型启动时间，减少延迟。为此，我们提出了一个模型缓存的设计，目前正在进行中。我们有几个来自彭博社和其他公司的团队成员正在研究这个。自动缩放是KServe社区一直在与KEDA社区密切合作的另一个功能。KEDA是基于Kubernetes的事件驱动自动缩放器。这就是我们如何利用其他领域、其他社区的专业知识，共同为用户提供最佳解决方案。是的，所以KServe正在与KEDA密切合作以实现这个自动缩放功能。是的，另一件事是，如果你参加了今天早上的主题演讲，Tim也提到了AI网关，这也是一个令人兴奋的功能，我们期待拥有一个对LLM工作负载更高效的AI网关。是的，这些是目前正在进行的一些项目，我们确实需要人手。这将非常令人兴奋，你将与来自多个不同领域的专家合作。是的，现在是从事推理工作的激动人心的时刻。展望未来，我们也在努力解决提示缓存的挑战。很多人在这次会议上也在讨论提示缓存，这是我们开始设计解决方案的事情。总的来说，对于KServe社区，这些只是KServe和推理服务的一些令人兴奋的功能和增强，我们想给你一个预览。但作为一个社区，我们真的希望让更多的人参与到社区中来。这又是一个不断发展的社区，我们现在有很多大公司参与进来。我们希望让更多的公司参与进来，以便共同制定协议，让所有公司都采用这些通用协议，这样一切才能为每个人服务。是的，就是这样。我们也面临挑战，例如，随着不同公司的聚集，我们都有不同的优先级。如果我们只是参加这些社区会议，讨论所有人的需求和需求，那么我们就可以找到合适的资源来处理这些不同的工作流。是的，最后，是的，只是尝试参与开源。

Jon George：是的，我知道我们有很多令人兴奋的项目要做，所以很多项目，这是一个反复出现的主题。是的，关于未来。KServe在传统预测模型方面确实做得很好。所以在过去的一年里，我们正试图转向生成式模型领域。如果你看看所有传统模型，它们都是基于请求的自动缩放和请求指标，这对于传统模型非常有效。但在大型语言模型中，由于其规模、大小和架构，这并不容易，原因有很多。如果你看看大型语言模型，你可能收到一个0令牌的请求，下一秒你可能收到一个10000令牌的请求。GPU处理可能只需要10毫秒，但第一个请求，另一个请求实际上可能需要几秒到几分钟。因此，在LLM世界，特别是在生成式世界中，决定自动缩放和其他因素并不那么容易。换句话说，我们需要将令牌作为大型语言模型在新领域的一等公民。我们内部也在讨论，如何在KServe中集成基于令牌的自动缩放和基于令牌的指标，以实现更可靠的SLA，用于吞吐量和延迟。这是我们关注的一个主要焦点。类似于我们正在寻找的其他标准，再次是为了一个统一的通用指标接口。不同的运行时提供不同的指标，无论是NIM、vLLM，我们需要一个统一的指标接口，类似于我们拥有的推理协议，它可以决定运行时的性能，以及我们如何基于此决定自动缩放。KServe社区作为一个社区，我们可以共同决定我们需要做的正确抽象，甚至从指标和自动缩放部分开始，这样它就可以与下面所有不同的运行时一起工作。从用户的角度来看，他不需要知道任何东西，他只需使用标准的开放推理协议，所有事情都由KServe内部处理。

Andrea Montano：谢谢。我认为很多有趣的项目和功能已经被提到了，但补充一下Anil所说的，值得一提的是，作为社区，分享你使用项目或产品的经验对我们来说很重要。如果你一直在使用KServe、Kubeflow或任何其他工具，请与我们分享你的使用情况、遇到的障碍，因为这是我们最终提出功能、想法、项目和路线图的原因。就我个人而言，我喜欢参加KubeCon的另一个原因是，无论我们谈论的是Charmed Kubeflow、KServe还是上游的Kubeflow项目，我真的很喜欢听人们如何使用它，以及他们面临的挑战，因为这给了我们思考如何改进的素材。现在展望未来，我认为有两件事我们还没有在主流讨论中提到。一方面，我们需要更多地关注安全性，无论是KServe中使用的软件包的安全性，还是数据科学和机器学习中使用的项目的安全性，这是一个需要优先考虑的方面，以便能够在生产环境中推出许多项目。另一方面，改善用户体验和降低运行生成式AI项目、生成式AI模型和LLM的门槛将是另一个重点。最后但同样重要的是，如果我回到安全性的想法，让我非常兴奋的是在机密计算VM中运行Kubeflow，可能将来也包括KServe，这将使同一行业内的公司之间能够以完全不同的规模进行协作，我认为这也很令人兴奋。

Adam Tleman：Adam，我想你还有一些时间可以补充一些内容。是的，所以，总结一下，我知道你们提到了很多API网关、新功能，这些都是新的东西和路线图，我对此感到兴奋。稍微引申一下，也许回顾一下，我想我站在这里是因为我们取得了一次胜利，而到达这里有一件事非常困难，那是一个完全不同的话题，即说服内部人员开源是一条好路。我真的必须倡导KServe作为一个有用的平台，我真的必须向产品人员和工程领导推销。我需要去对他们说，嘿，这很重要，我们需要投入资源。我真的很期待未来，看到我们都在这里，看到人们接受它，现在我的客户有了平台选择、模型选择、AI选择，这只是给社区更多。我认为这是一次胜利，这将使我更容易回到高层领导那里说，嘿，让我们多做这样的事情，上次我们都赢了，让我们再做一次。我期待着看到更多的参与。我知道Chris Lamb昨天做了一个主题演讲，我希望能让我的团队中更多的人参与到更多的项目中来，这是好事，因为我想提到的另一件事是，有很多新东西我们需要引入开源。你提到了机密容器，这是一个硬件相关的事情，需要大量软件才能使其工作。你提到了多节点推理，我们现在已经有了第一版，但那是另一个硬件相关的事情，我的团队可以在高性能网络和高性能结构方面做很多事情，我们可以让多节点的东西运行得更快，我们可以让时间切片的东西运行得更快。所以我兴奋地看到，DRA是那个故事的一部分，所以我兴奋地看到很多这些东西结合在一起，使得越来越复杂的应用程序管理起来更简单、更高效。最后一件事，生成式AI应用程序正变得越来越复杂，所有这些部分，我们在这里有一个平台，我们有一个单一的推理服务器运行一个单一的模型，然后是Model Mesh，这样我们可以运行多个模型并混合使用，现在我们需要一些全新的东西，因为现在我们有了这些带有RAG的生成式AI应用程序，我们正在定义遥测标准和一些工作组，我们正在定义这些新的网关和其他工作组。因此，确实有这个社区，WG Serving社区确实跨越了许多不同的项目，我们都在努力弄清楚现在的问题是什么。现在是参与的好时机，因为我认为我们刚刚开始掌握所有问题，并开始将解决方案整合在一起。

如何参与社区贡献

我们还有时间回答一个问题。有人提问：参与这类MLOps工程工作需要什么样的技能？Python、Kubernetes，擅长某一项比另一项更好，你需要什么？

Andrea Montano：如果可以的话，我先开始。我认为这真的取决于情况，但例如在Kubeflow社区，我看到很多学生，他们只是非常优秀的Python工程师，非常热情，非常好奇，他们就这样开始了，边做边学。这可能具有挑战性，但同时也给你带来很多满足感。同时，我认为理解Kubernetes是一个基础部分，它将降低你在KServe方面的入门门槛，并加速你的贡献方式。

Jon George：我看到Tenny在点头表示同意。你想补充点什么吗？不，不，不，你来吧。我只想举一个例子。我的一些团队成员两年前对Kubernetes和KServe完全陌生。他们现在是KServe项目的评审者。所以这一切都是由兴趣和投入的努力驱动的，KServe社区欢迎每一个人，每一个人。

Tessa Fam：我想说，拥有技术技能显然对贡献非常有帮助，无论你是Python开发者、Go开发者还是MLOps工程师。但我们也需要很多帮助，即使是文档更新。如果你去KServe网站，有很多我们还没有能够添加到文档中的新功能。而这是新用户来使用KServe时首先会去的地方。所以，即使你能通过更新文档做出贡献，那也是一个巨大的贡献。所以我想说，在社区工作就是投入时间，这就是你贡献和帮助的方式。所以，如果你觉得，我不知道Go，我不懂ML，我怎么去贡献？这真的没关系，你可以以各种方式贡献，我们欢迎各种形式的贡献。

Andrea Montano：我同意这一点。我认为Kubernetes绝对是基础，只要你熟悉Python和容器，我认为你基本上就可以开始了。你懂什么编程语言并不重要。很多人从这些技术的最终用户变成了开源项目的贡献者。所以你真的可以从任何地方开始，只要你知道我们要解决的问题是什么，或者，是的，甚至只是提出一个问题，那就是一种贡献。

Adam Tleman：所以，是的，所以我认为你需要一种想要帮助的热情，我们会帮助你学习剩下的，这就是我刚才听到的。我想我们的时间到了，谢谢大家的参与。祝大家会议愉快。

总结

在本节课中，我们一起学习了如何有效参与KServe开源社区。我们通过专家小组的讨论，了解了社区协作的强大力量，它如何加速创新、降低成本，并为所有参与者带来共赢。我们探讨了社区面临的挑战，如降低入门门槛、应对LLM特有的技术难题（如模型缓存、自动缩放、令牌级指标），以及协调不同公司的优先级。同时，我们也看到了社区取得的显著成就，如WG Serving社区的壮大、新项目（如LLM网关、DRA动态资源分配）的推进，以及将负责任AI（Trust AI）集成到KServe中。最重要的是，我们明确了任何人都可以参与贡献，无论技能水平如何，从编写代码、改进文档到提出问题都是宝贵的贡献。未来，社区将继续聚焦于降低成本、提高效率、增强安全性，并简化生成式AI应用的部署与管理。我们鼓励所有感兴趣的人加入CNCF Slack的WG Serving和KServe频道，共同塑造云原生AI推理的未来。

posted @ 2026-03-29 09:18 绝不原创的飞龙阅读(1) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

KubeCon-2024-笔记-全-

KubeCon 2024 笔记（全）

002：闭幕致辞

003：十年架构与演进 🎮

概述

第一轮：Kubernetes中常见的错误 🚨

第二轮：Kubernetes与云原生的最大风险 ⚠️

第三轮：如何发音“kubectl”？ 🔤

第四轮：Kubernetes的最佳特性 ✨

第五轮：已被克服的采用障碍 🏆

最终总结 🎉

005：平衡创新与稳定

概述

章节一：Kubernetes的演进曲线与转折点

章节二：核心使命与三大故事

章节三：规模化可靠性

章节四：重构硬件关系

章节五：迈向框架编排器

章节六：总结与展望

总结

006：回顾过去，展望未来——Heroku CTO Gail Frederick的分享

007：KubeCon 2024 开幕致辞与社区动态解读

社区合作与资源贡献

项目进展与社区认可

新兴技术：安全与性能的平衡

全球社区扩展与教育计划

新认证与学术合作计划

未来活动规划与社区调查

008：KubeCon+云原生峰会2024参会体验与收获

核心收获总结

009：北美峰会亮点与参会收获

会议整体评价 🎉

核心收获：人际连接与社区参与 😊

总结

010：闭幕致辞

013：开发者软件供应链安全指南

为什么需要关注软件供应链安全？🔐

软件开发的典型流程与风险 🚧

构建安全供应链的阶段性策略 🛡️

第一阶段：安全获取组件

第二阶段：安全构建应用

第三阶段：安全部署应用

第四阶段：运行时安全与可观测性

总结与行动号召 🚀

014：云原生下一个十年——稳定、安全、并...准备好迎接颠覆

当前状态：稳定与无处不在

未来的挑战：远未结束

应对之道：超越炒作，主动准备

核心挑战一：软件物料清单

解决方案：GUAC项目

未来方向：自动化与策略

核心挑战二：人工智能与向量数据库

解决方案：数据溯源与透明度

核心挑战三：量子计算

总结与展望

016：KubeCon 2024 颁奖典礼 🏆

宣布年度杰出终端用户奖

获奖者名单

社区贡献者奖项

主要奖项类别

总结与展望

018：与最终用户共创高峰——Taylor Dolezal

概述

置身云端之上

你的第一座“山”是什么？

共同攀登：CNCF的角色与挑战

新工具：CNCF技术雷达回归

登顶之后：更多道路与资源

最终用户TAB的使命与工作

工作组成果展示

2024年成就与未来展望

总结

019：第二天开场致辞

021：从版本1到5的经验教训 🎓

高可用性：架构演进与最佳实践 🛡️

早期架构的挑战

向成熟社区方案演进

预防优于应对