🆕 专题一 产品新功能/新版本
1. Postman 推出新的 AI 增强型 API 工具
Postman Unveils New AI-Enhanced API Tools
Postman 发布了一系列 AI 增强型 API 工具，旨在简化 API 创建和自动化工作流程。主要更新包括：
Agent 模式: 一个 AI 驱动的助手，能够理解自然语言指令并执行设计、测试、文档化和监控 API 等任务，将原本需要数周的工作缩短至数小时。
AI Agent Builder: 一个集成 Model Context Protocol (MCP) 的工具，允许开发者创建多步骤代理来自动化常见的 API 任务。它包含三个功能：测试和评估 LLM、将 API 转换为 MCP 规范以及一个名为 Flow 的可视化拖放式开发工具，用于构建使用 API 调用 AI 的应用程序。
Postman Insights: 一个实时 API 可观测性工具，可以跟踪跨端点和版本的 API 使用情况，检测故障模式并在影响用户之前主动解决问题。它支持 Repro 模式，可立即重现 API 故障。
Postman Monitors: 一个补充 Postman Insights 的工具，允许开发者在生产环境中设置预生产测试，并模拟用户交互来主动测试和监控应用程序和 API 的性能和可用性。
2. Gateway API 1.3.0：流量复制、CORS、Gateway 合并和重试预算的改进
Gateway API v1.3.0：流量复制、CORS、Gateway 合并和重试预算的改进
总结
Gateway API v1.3.0 为 Standard 渠道（Gateway API 的正式发布渠道）带来了一个新功能：
-
基于百分比的流量复制
基于百分比的流量复制是对现有 HTTP 流量复制 支持的增强， 它允许使用 RequestMirror 过滤器类型将 HTTP 请求复制到另一个后端。流量复制在蓝绿部署中特别有用。 它可用于评估流量波动对应用程序性能的影响，而不会影响对客户端的响应。
之前的流量复制功能适用于对 backendRef 的所有请求。基于百分比的流量复制允许用户指定他们想要复制的请求子集，可以通过百分比或分数来指定。当服务接收大量请求时，这特别有用。这个新功能可以用来复制这些请求中的一小部分， 而不是复制所有请求。
并引入了三个新的实验性功能：
-
跨源资源共享（CORS）过滤器
跨源资源共享（CORS）是一种基于 HTTP Header 的机制， 允许网页从与提供网页的域不同的源（域名、协议或端口）访问受限资源。 此功能添加了一个新的 HTTPRoute filter 类型， 称为 "CORS"，用于在响应发送回客户端之前配置跨源请求的处理。
-
Listener 和 Gateway 合并的标准化机制
允许将 listeners 的共享列表附加到一个或多个父 Gateway。 此外，它还扩展了现有的建议，即 Gateway API 实现可以合并来自多个 Gateway 对象的配置。
-
重试预算（Retry Budgets）
允许你为目标服务的所有端点配置重试预算（Retry budgets）。 用于在达到配置的阈值后限制额外的客户端重试。 配置预算时，可以指定可能包含重试在内的活动请求的最大百分比， 以及在计算重试阈值时考虑请求的时间间隔。 此规范的开发将现有的实验性 API 类型 BackendLBPolicy 更改为新的实验性 API 类型 XBackendTrafficPolicy， 以减少具有共同点的策略资源的扩散。
Kubernetes 版本要求
不需要升级到最新版本的 Kubernetes 来获取最新版本的 Gateway API。只要你运行的是 Kubernetes 1.26 或更高版本，你就可以使用此版本的 Gateway API 启动和运行。
拓展阅读
介绍 Gateway API 推理扩展
Gateway API 推理扩展基于已有的 Gateway API 进行构建， 添加了特定于推理的路由能力，同时保留了 Gateway 与 HTTPRoute 的熟悉模型。 通过为现有 Gateway 添加推理扩展，你就能将其转变为一个推理网关（Inference Gateway），从而以“模型即服务”的理念自托管 GenAI/LLM 应用。
此项目的目标是在整个生态系统中改进并标准化对推理工作负载的路由。关键目标包括实现模型感知路由、支持逐个请求的重要性区分、促进安全的模型发布，以及基于实时模型指标来优化负载均衡。为了实现这些目标，此项目希望降低延迟并提高 AI 负载中的加速器（如 GPU）利用率。
Gateway API Benchmarks
Gateway API 旨在替代旧的 Ingress API，但其各种实现的性能和行为差异巨大，现有的符合性测试无法充分反映这些差异。Gateway API Benchmarks 提供了一套全面的基准测试，涵盖了连接路由、路由传播时间、路由更改、路由规模和流量性能等多个方面，以帮助用户更好地理解不同 Gateway API 实现的实际表现。测试对象包括 Cilium、Envoy Gateway、Istio、Kgateway、Kong、Traefik 和 Nginx 等。测试结果表明，这些实现之间存在显著差异，有些实现存在严重的性能瓶颈、内存泄漏、可扩展性问题以及与其他实现的互操作性问题。
3. HAMi v2.6.0：稳定性与异构支持双升级
社区共建再下一城！HAMi v2.6.0 稳定性与异构支持双升级 >>
主要特性
- 异构芯片支持再升级
- 支持 Enflame GCU 共享模式（gcu-share）
- 新增对 Metax GPU / sGPU 的识别与管理
- 调度器&设备插件优化
- 调度日志优化：增强日志结构与可读性，助力问题定位与调度行为追踪。
- 新增 GPU 拓扑感知评分机制：为 NVIDIA GPU 添加拓扑感知得分注册逻辑，为后续支持更精准的拓扑亲和调度打下基础。
- 部署优化与增强
- 支持 ConfigMap 变更触发组件重启：通过为 ConfigMap 注入 checksum 注解，自动滚动重启对应 HAMi 组件，保障配置一致性。
- 支持 NVIDIA RuntimeClass：让容器运行环境配置更灵活，适配不同驱动环境。
- 优化设备卸载逻辑：避免节点管理器中遗留设备信息引发异常。
- 性能与可观测性增强
- 支持 net/http/pprof 运行时性能分析：方便开发者实时诊断与性能调优。
- vGPUmonitor 支持 MIG 模式信息展示：更好支持基于 MIG 的显卡切分方案。
未来展望
HAMi 将持续推动异构计算平台的标准化，进一步兼容更多国产芯片与多样化算力形态。在即将到来的 v2.7.0 版本中，我们计划：
- 新增支持昆仑芯系列芯片，持续拓展国产生态适配能力；
- 紧跟 Kubernetes DRA 规范，提升与主流设计的原生集成能力；
- HAMi-WebUI 深度优化，带来更流畅、直观的异构资源可视化体验。
4. Argo CD v3.1：支持 OCI、CLI 插件、Hydrator 更新、UI 改进等多项内容
简介
- OCI 支持 (Beta): 可以直接从符合 OCI 规范的容器注册表拉取 Kubernetes manifests，增强安全性及可移植性。
- Hydrator 改进: 将 dry 提交与代码提交关联，未来会在 Argo CD UI 中展示更多信息。
- 服务器端 Apply 稳定性提升: 方便从 kubectl 的客户端 Apply 迁移到服务器端 Apply，并支持资源迁移管理。
- UI 参数化操作: 可以直接在 UI 中调整 Deployment 和 StatefulSet 的副本数，简化操作。
- 其他改进: 支持 CLI 插件、应用可显式设置自动同步、AppSet 渐进同步 UI 改进等。
📰 专题二 新闻与访谈
1. 2024 年 CNCF 及前 30 个开源项目活跃度回顾
2024 year in review of CNCF and top 30 open source project velocity
- 气泡的面积与作者数量成正比。
- Y 轴代表拉取 pr 和问题的总数。
- X 轴代表 commint 的数量。
CNCF 项目 – 过去 12 个月
Kubernetes 和 OpenTelemetry 一骑绝尘。
Linux 基金会项目 – 过去 12 个月
Linux、pytorch、Kubernetes 和 OpenTelemetry 属于第一梯队。
前 30 名开源项目 – 过去 12 个月
2. Kaniko 正式被存档
Kaniko 是什么
kaniko 是一种工具，用于在容器或 Kubernetes 集群内从 Dockerfile 构建容器镜像。
3. Kubernetes AI Conformance 介绍
Kubernetes AI Conformance 定义了一套额外的能力、API 和配置，Kubernetes 集群必须（MUST）具备这些，才能在标准 CNCF Kubernetes Conformance 的基础上，可靠高效地运行 AI/ML 工作负载。
一个 Kubernetes 平台或发行版，必须先通过 Kubernetes 合规性认证，才能获得 AI 合规性认证。
合规标准会随着 AI/ML 发展不断更新。每个版本定义一组能力，合规测试验证其存在及正确性。每版声明依赖的最低 Kubernetes 版本，初版依赖 Kubernetes v1.34 及以后版本。
每个平台需每年根据最新合规测试重新运行认证，才能维持合规状态。
更多内容见原文。
💬 专题三 讨论与分享
1. Sealos 在 Reddit 上进行宣传
Sharing our journey: Why we moved from Nginx Ingress to an Envoy-based solution for 2000+ tenants
Follow-up: K8s Ingress for 20k+ domains now syncs in seconds, not minutes.
Sealos 是什么
Sealos ['siːləs] 是基于 Kubernetes 内核的云作系统发行版，专为无缝开发生命周期而设计。在几秒钟内启动全栈环境，轻松推送版本，并无缝扩展生产。
Sealos DevBox 是一个一站式云开发平台，将在线开发、测试和生产环境完美集成。只需一键点击，即可快速创建所需的开发环境和数据库依赖。开发者可以使用熟悉的本地 IDE（如 VSCode、Cursor、JetBrains 等）进行开发，同时享受简化的环境配置和自动化的应用部署体验。平台支持所有主流编程语言和框架，包括 Node.js、Python、Java、Go、PHP、Ruby 等，以及各类前端框架如 React、Vue、Angular 等。
🎤 为什么单独查看它的宣传
Sealos 是一款中国大陆的产品。结合 4 月的 5.2k 星的 Rainbond 在海外为何无人问津 和 5 月的 HAMi 到 Reddit 寻求建议。同样作为希望出海的产品，Sealos 和 HAMi（[KubeCon China 2025] vGPU scheduling across clusters is real — and it saved 200 GPUs at SF Express.）已经在友商寻求建议的帖子回复中找到了自己的答案并付诸行动。
KubeSphere 也来了，但是帖子质量不太行。
2. 从 YAML 到平台：Kubernetes 部署之旅
From YAML to Platforms: The Kubernetes Deployment Journey
在 Kubernetes 环境中部署和管理应用程序远非一成不变。组织经历了重大演变，从初级开始到自动化实践。这种演变将组织面临的问题从“我们能否在 Kubernetes 上运行应用程序”转变为“如何在复杂的 Kubernetes 环境中优化应用程序交付”。
旅程的开始 — Kubernetes 清单
每个组织的 Kubernetes 之旅通常都从一件事开始：YAML 文件 — 而且数量很多。这些 Kubernetes 清单是基础，提供对部署各个方面的详细声明性控制。从配置资源到定义服务行为，YAML 文件充当在 Kubernetes 中部署和管理应用程序的蓝图。
然而，这些 Kubernetes 清单在大规模应用时暴露出其局限性。当组织决定扩展到 Kubernetes 时，对这些 Kubernetes 清单的管理开始成为一个瓶颈。组织面临的一些主要限制是：
- 版本控制挑战： 跟踪数百个 YAML 文件中的更改成为维护的噩梦。
- 配置偏差： 特定于环境的变化迅速增加。
- 缺乏标准化： 不同的团队开发他们的清单模式，从而形成组织孤岛。
- 安全治理： 确保一致的安全控制几乎是不可能的。
- 操作复杂性： 故障排除需要深入研究原始 YAML 文件。
这些限制凸显了在 Kubernetes 清单之上需要更高级别的抽象，这可以帮助组织更有效地管理 YAML 文件，同时提供标准化的工作方式，所有这些都不会影响 Kubernetes 的功能和灵活性。
标准化 Kubernetes 清单 — Helm
Kubernetes 的包管理器 Helm 的出现标志着在编排 Kubernetes 清单方面向前迈出了重要一步。它引入了 charts 的概念，它将所有必需的 Kubernetes 资源捆绑到一个可重用的包中。Helm 图表的模板功能使团队可以更轻松地管理配置并支持大型应用程序部署的自定义。部署复杂的应用程序不再是争论各个清单，而是管理定义明确、版本化的构件。对于组织来说，这意味着提高了跨环境的一致性，并能够更有效地定义应用程序生命周期管理。
但是，对于大规模运维的成熟组织，采用 Helm 通常会带来一些需要仔细考虑的限制：
- 模板逻辑的复杂性： 虽然模板提供了灵活性，但过于复杂的 Helm Chart 可能会变得难以理解、维护和调试。
- 管理嵌套图表的复杂性： 用户在使用高度嵌套的 Helm Chart 时经常会遇到困难。了解在 values.yaml 文件中设置值的级别可能会令人困惑，尤其是在处理具有自己的架构的上游 chart 时。
- 缺乏自动化部署工作流程：Helm 主要专注于打包和部署预构建的应用程序工件（图表）。它本身并不定义或自动化从源代码构建这些构件、运行测试或跨不同环境管理发布管道的过程。
- 缺乏可见性和监控：Helm CLI 不提供内置机制来查看通过其 Chart 部署的应用程序的运行状况和状态。
凭借 Helm 的所有优点和缺点，它为组织提供了一种前进的方法，以一种简化的方式通过 Kubernetes 部署和管理其应用程序，从而处理大量原始 Kubernetes 清单。
自动化交付管道 — CI/CD 集成
当 Kubernetes 得到广泛采用时，组织已经弄清楚了如何在其上部署和运行他们的应用程序。下一个挑战不再是如何运行应用程序，而是如何将频繁的更改交付到这些日益复杂的 Kubernetes 环境中。
为了获得竞争优势并快速满足不断变化的客户需求，组织需要越来越频繁地发布新功能和错误修复，通常每天发布多次。这需要将 CI/CD 管道集成到 Kubernetes 工作流中。
借助 CI/CD，组织实现了构建、测试和部署过程的自动化。使用工具应用清单或 Helm 图表可显著减少人工错误并加快上市时间。Jenkins 和 Circle CI 等工具被用于构建应用程序和部署，而 kubectl 或 Helm 是唯一的选择。后来，Jenkins 组织的能力扩展了 Jenkins 的使用，执行 kubectl apply，并更新了 Helm Chart 的 values.yaml 中的 image 标签。
GitOps 方法
为了加强部署部分，一种专门为 Kubernetes 设计的方法应运而生：GitOps。它定义了专门在 Kubernetes 上执行部署的四个核心支柱：
- 声明
- 版本化且不可变
- 自动拉取
- 持续对账
GitOps 在增强安全性（审计跟踪、不可变基础设施）、改进的合规性（声明式状态）和增强的运维弹性（自动对账和自我修复）方面具有引人注目的优势。
平台方法
在这个阶段，Kubernetes 部署的演变看起来在逻辑上已经完成：从原始 Kubernetes 清单开始，到 Helm 的编排能力，CI/CD 的自动化，最后是 GitOps 来可靠地部署更改。
对于小规模运维的团队来说，这可能是一个完美的画面，但当规模增加时，风险就很高，上述所谓的完美画面就成为瓶颈。团队现在必须应对新的挑战：工具蔓延。即使您拥有一支出色的运维团队，他们现在也可以在不同级别使用工具来抽象复杂性并使用多种工具顺利作。
对于大多数达到大规模的科技组织来说， 云原生技术的固有复杂性带来了双重挑战。运维团队发现自己被一组工具所累，而开发人员则在快速有效地部署代码的摩擦中苦苦挣扎。
这种情况造成了一个恶性循环：开发人员不断提出管道设置的工单，而运维团队则在不断积压的订单中苦苦挣扎。开发人员的挫败感随着每一次延迟而增加，最终削弱了组织的生产力，并使 Kubernetes 本应提供的效率提升付诸东流。
2010 年，Airbnb、Netflix 和 Google 等行业巨头开始构建自己的内部平台，旨在帮助开发人员和运维团队更高效地工作。平台方法旨在为开发人员简化作并减少他们的认知负担，这就是自助服务方法非常适合的地方。
3. Kubernetes 与 Docker Compose：您应该选择哪种编排工具？
Kubernetes vs. Docker Compose: Which Orchestration Tool Should You Choose?
对比总结
| 特性 | Docker Compose | Kubernetes |
|---|---|---|
| 解决的问题 | 单机上的简单多容器应用 | 跨多台机器的复杂应用 |
| 核心概念 | 服务、网络、卷 | Pod、部署、服务 |
| 设置和学习曲线 | 易于设置，快速学习 | 更复杂的设置和学习 |
| 扩缩容 | 限于单个节点 | 跨多个节点的横向扩缩容 |
| 网络 | 简单桥接网络，服务名称 | 集群范围网络，用于外部访问的 Ingress |
| 存储和状态管理 | 用于本地存储的命名卷 | 用于持久性的 PersistentVolumes，StatefulSets |
| CI/CD 和自动化 | Dev Containers 中的简单操作，GitHub Actions | Helm，GitOps，高级自动化 |
| 可观测性和调试 | 基本日志和统计 | 高级指标、跟踪和调试工具 |
| 成本和资源效率 | 轻量级，本地资源使用 | 更高的开销，但通过自动扩缩容实现效率 |
解决的问题
Docker Compose 非常适合本地开发和小型应用程序。它易于设置并在单台计算机上运行：
- 本地开发
- 测试小型应用
- 快速启动服务，例如 Web 服务器、 数据库和 API
- 与团队成员共享设置说明
Kubernetes 专为大型分布式系统而构建。它提供高级扩展、自动化和高可用性，但复杂性更高：
- 在生产环境中运行应用程序
- 管理跨多个容器的流量
- 处理故障和重启
- 需要自动扩展
核心概念
Compose 服务、网络和卷
在 Docker Compose 中，我们将容器分组为服务。每个服务运行一个容器镜像。例如，我们可能有一个用于 Web 应用的服务、一个用于数据库的服务，以及另一个用于缓存的服务。
Compose 还会设置网络，以便我们的服务可以轻松地相互通信。无需向外部暴露端口。卷用于存储需要持久保存的数据，例如数据库文件。通过这种方式，我们不会在容器停止或重启时丢失重要信息。
所有内容都定义在一个单独的 docker-compose.yaml 文件中。它易于阅读且修改迅速。
Kubernetes Pod、部署和服务
Kubernetes 的工作方式有点不同，并且有几个 Kubernetes 构建块。基本单元是一个 Pod，而不是一个容器。一个 Pod 可以运行一个或多个共享存储、网络和设置的容器。
我们使用部署来管理这些 Pod。部署会告诉 Kubernetes 我们想要多少个 Pod 并保持它们运行。如果一个 Pod 崩溃，Kubernetes 会将其恢复。
Kubernetes 中的服务帮助 Pod 相互通信。它们还管理进出集群的流量。
与 Compose 不同，Kubernetes 将这些部分拆分为不同的文件或命令。这需要更多的设置，但给我们带来了更多的控制。
设置和学习曲线
本地安装和配置
Docker Compose 易于设置。如果我们安装了 Docker，我们基本上就准备好了。我们只需编写一个 docker-compose.yaml 文件，运行 docker-compose up，我们的应用就会启动。它非常适合本地开发。无需安装任何其他东西。我们可以快速启动或拆除环境。
Kubernetes 需要更多的设置。对于本地测试，我们可能会使用 Minikube、Kind 或启用了 Kubernetes 的 Docker Desktop 等工具。这些会增加一些额外的步骤。我们还需要学习集群如何工作——即使是在一台机器上运行。
声明式 YAML 复杂度
这两个工具都使用 YAML，但 Kubernetes 将其提升到了另一个层次。在 Docker Compose 中，我们的 YAML 文件简短且易于理解。一个文件通常就能完成任务。
在 Kubernetes 中，我们通常需要为单个应用准备多个 YAML 文件：
- 一个用于 Pod 或部署
- 一个用于服务
- 一个用于存储或配置设置
这使得事情变得更强大，但也更难学习。结构很严格，小错误就可能导致问题。我们花费更多时间理解各个部分如何协同工作。
扩缩容
Docker Compose 中的副本限制
Docker Compose 可以运行服务的多个副本，但它有限制。所有副本都在同一台机器上运行。没有内置的方法可以将它们分布到整个集群中。
我们可以使用 --scale 标志来运行更多容器，但没有自动负载均衡或故障转移。如果机器崩溃，一切都会停止运行。Compose 适用于小型应用或开发工作，但不适用于高流量或关键系统。
Kubernetes 中的横向扩缩容
Kubernetes 是为扩缩容而构建的。它可以运行许多副本——称为 replicas——它们是相同 Pod 在不同机器上的副本。我们设置副本的数量，然后 Kubernetes 处理其余部分。
如果我们需要在高峰时段扩容，Kubernetes 可以自动完成。它还会在 Pod 之间平衡流量，并重启任何失败的 Pod。这使得它非常适合高可用性。如果一个 Pod 或机器宕机，应用仍然可以继续运行。
网络
Compose 桥接和服务名称
Docker Compose 默认创建一个私有桥接网络。同一个 Compose 文件中的所有服务都在这个网络上，并且可以使用服务名称相互通信。
例如，如果我们有一个需要数据库的 Web 应用，该应用可以直接连接到数据库——无需 IP 或特殊设置。这非常适用于小型项目。它简单且自动化。
Kubernetes 集群网络和 Ingress
Kubernetes 使用集群范围的网络。每个 Pod 都会获得自己的 IP。集群内部的服务可以通过 Kubernetes 服务相互通信，这些服务负责处理流量和路由。
对于外部访问，我们通常使用 Ingress。这就像一个智能路由器，控制请求去向何处。它还有助于处理像 HTTPS 和域名这样的事情。Kubernetes 网络功能更强大，但需要更多时间来理解和配置。
存储和状态管理
命名卷 (Named Volumes) vs 持久卷声明 (PersistentVolumeClaims)
在 Docker Compose 中，我们使用命名卷。这些在 Compose 文件中定义，可以在服务之间共享。它们易于设置，并且非常适合本地开发。例如，我们可能为数据库创建一个卷，这样即使容器停止，其数据也能保持安全。
在 Kubernetes 中，我们使用持久卷声明 (PVC)。这些是连接到持久卷 (PV) 的存储请求。它对于更大规模的设置来说更灵活、更好用。我们可以使用云存储、本地磁盘或网络驱动器。PVCs 更复杂，但它们让我们能够将应用与存储分离。
StatefulSets 和数据持久性
对于需要稳定存储的应用，如数据库，Kubernetes 有一个叫做 StatefulSet 的东西。它确保每个 Pod 都有一个唯一的名称和自己的存储。即使 Pod 重启或移动到另一个节点，它也能保留其数据。
Docker Compose 没有完全匹配的功能。所有服务都被视为相同，如果我们进行扩缩容或移动东西，管理长期数据可能会变得棘手。
CI/CD 和自动化
Docker Compose 和 Kubernetes 都可以用于 CI/CD 流水线，但工具和工作流程有所不同。
Compose 中的 Dev Containers 和 GitHub Actions
Docker Compose 在开发流水线中运行良好。我们可以将其与 VS Code 中的 Dev Containers 一起使用，快速启动本地环境。它非常适合测试需要多个服务的应用。
在 GitHub Actions 等 CI 工具中，我们可以在部署或发布应用之前运行 docker-compose up 来测试我们的应用。它简单高效。Compose 非常适合早期阶段的自动化、本地测试和小型团队。
带 Helm 和 GitOps 的 Kubernetes
Kubernetes 专为大规模自动化而设计。我们经常使用 Helm 等工具来管理复杂的部署。Helm 让我们将应用打包成 Chart 并在不同环境中重用配置。
为了实现更高级别的自动化，团队使用 GitOps。这意味着我们将所有的 Kubernetes 设置存储在 Git 中。当我们更新仓库时，Argo CD 或 Flux 等工具会同步更改到集群。这需要更多的设置，但它功能强大，特别是对于管理许多应用或集群的团队。
可观测性和调试
Docker Compose 的日志和统计
Docker Compose 提供了基本的工具来检查发生了什么。我们可以运行 docker-compose logs 来查看我们的容器正在做什么。它会显示每个服务的输出。
我们还可以运行 docker stats 来查看 CPU 和内存使用情况。这对于开发过程中的快速检查很有帮助。为了获得更深入的洞察，我们需要自己添加像 Prometheus 或 Grafana 这样的工具，因为 Compose 默认不包含它们。
Kubernetes 的指标、跟踪和 kubectl debug
Kubernetes 在可观测性方面做得更进一步。我们可以运行 kubectl logs 来检查日志，就像使用 Compose 一样。我们还可以使用 kubectl describe 或 kubectl debug 来深入挖掘 Pod 行为。
Kubernetes 很好地配合以下监控工具工作：
- Prometheus 用于指标
- Grafana 用于仪表盘
- Jaeger 或 OpenTelemetry 用于跟踪
这使得在复杂系统中跟踪问题变得更容易，但它也需要更多的设置和学习。
成本和资源效率
本地资源占用
Docker Compose 轻量级。它在单台机器上运行所有东西。除了容器本身，没有额外的开销。这使得它非常适合本地开发，因为我们不需要太多内存或 CPU 来启动一个小应用。它对于单节点工作来说简单高效。
集群开销和自动扩缩容
Kubernetes 使用更多资源。即使是小型集群也需要像 API 服务器、调度器和控制器管理器这样的后台服务。这些服务保持系统平稳运行，但会增加开销。
尽管如此，Kubernetes 是为自动扩缩容而构建的。它可以根据流量向上或向下扩展 Pod。如果我们使用云提供商，它甚至可以扩展整个集群，增加或删除节点。因此，虽然运行成本更高，但它在大规模部署时效率更高。我们只在我们需要的时付费，并且只支付我们需要的量。
如何选择
选择 Docker Compose
- 你需要一个简单的设置： 如果你正在开发一个小应用或本地环境，Compose 快速且简单。无需担心复杂的配置。
- 你需要进行本地测试： 它非常适合本地开发和测试。你可以在一台机器上启动多个容器，而没有太多开销。
- 你正在构建一个小型团队或独立项目： 如果你没有管理一个大型分布式系统，Docker Compose 可以帮助保持事情可管理。
- 你不需要自动扩缩容： 如果你的应用不需要动态扩缩容，Compose 也能很好地工作。它以简单为宗旨，而非复杂性。
简而言之，当我们需要在单台机器上进行简单、快速且易于管理的操作时，Docker Compose 是一个很好的选择。
选择 Kubernetes
- 你需要管理一个大型系统： 如果你跨多台机器运行多个服务，Kubernetes 有助于组织和扩缩容所有内容。
- 高可用性至关重要： Kubernetes 自动处理 Pod 重启、扩缩容和负载均衡，确保你的应用即使在部分故障时也能保持在线。
- 你需要自动扩缩容： Kubernetes 可以根据流量向上或向下扩缩容 Pod，如果使用云提供商，它甚至可以扩缩容整个集群，增加或删除节点。
- 你正在管理复杂的生产级应用： Kubernetes 专为大型分布式系统而构建，并提供强大的工具用于监控、调试和大规模部署。
- 你需要云和混合环境的灵活性： Kubernetes 适用于云提供商、本地或混合设置，为你提供对基础设施的更多控制。
简而言之，当你的应用需要扩缩容、保持可用并跨多台机器管理时，选择 Kubernetes。
从 Docker Compose 迁移到 Kubernete
从 Docker Compose 迁移到 Kubernetes 似乎是一项艰巨的任务，但如果我们一步步来，它会变得可管理。请遵循以下步骤：
- 了解你当前的设置： 首先审查你的 Docker Compose 配置。确定需要迁移的服务、网络和卷。这将为你提供应用架构的清晰视图。
- 将 Compose 文件转换为 Kubernetes Manifests： 使用 Kompose 等工具自动将 Docker Compose 文件转换为 Kubernetes YAML 文件。你需要调整这些文件以适应你的 Kubernetes 集群设置。
- 设置 Kubernetes 集群： 在迁移之前，你需要一个 Kubernetes 集群。你可以使用 Google Kubernetes Engine (GKE)、Amazon EKS 等服务，或者设置一个 Minikube 等本地集群。
- 创建部署、服务和卷： 在 Kubernetes 中，我们需要为每个服务定义 Deployment、Service 用于内部和外部访问，以及 PersistentVolumeClaim 用于存储。
- 上线前进行本地测试： 一旦你设置好 Kubernetes manifests，请在本地使用 kubectl apply 进行测试。确保在扩展到生产环境之前一切正常工作。
- 逐步迁移： 通过一次迁移一个服务进行迁移。Kubernetes 允许我们同时运行 Docker Compose 和 Kubernetes 服务，从而简化过渡。
- 监控和优化： 迁移后，密切关注资源使用、性能和扩缩容。Kubernetes 为你提供了强大的工具来监控和按需调整配置。
4. 如何在 5 分钟内构建清晰的产品愿景
How to Build a Clear Product Vision in 5 Minutes
需要可以用一句话描述产品的愿景。清晰的产品愿景不是为了在墙上贴一个宏大的宣言。这是一种简单的方法，可以确保不会忽视对客户而言重要的事情。
没有产品的愿景，团队很容易陷入修复随机 Bug、追逐功能需求，或者构建听起来令人兴奋但对用户没有实际价值的东西。
简单的练习
下面是一个简单的练习：
-
询问买家关心什么？
答案揭示了产品的“支柱”。每个产品都有自己的一套“支柱”。它们是人们用来将产品与竞争对手进行比较的核心属性。
-
将每个支柱推向极致
与其问“你会解决什么问题？“（这通常会导致安全的回答，比如”我会调整这个设置“）。不如重构它：”这个产品最好的版本可能是什么？”
当将支柱推向极致时，就是为真正的创新创造空间的时候。
-
编写产品愿景
产品愿景源于一个简单的过程：确定客户最关心的支柱，设想每个支柱的最佳版本，并将它们组合成一个清晰且鼓舞人心的句子。它不必完美或宏大。它只需要是您的团队可以相信的东西 — 一个自然而然地将决策拉向正确方向的愿景。
常见误区
- 不要选择过多的支柱，最多专注于 3-5 个。
- 不要使用模糊的术语，例如 “良好体验”，要具体。
- 不要假设，使用真实的客户声音进行验证。
总结
产品愿景不必复杂。它只需清晰、有抱负，并根植于客户真正关心的地方。它将会议从“我们应该优先做什么？”转变为“我们如何才能更接近这个产品的最佳版本？”。
当愿景足够强大时，它就变成了一种号召。它能使团队保持一致，让艰难的决策变得更容易，提醒每个人为什么这份工作很重要。
简言之：从重要的开始。将其推向极致。然后朝着它努力建设。
5. 迁移到 Kubernetes：从规划到执行
Mastering Kubernetes Migrations From Planning to Execution
为了实现顺利的第 0 天迁移，平台工程师必须解决几个关键因素，包括安全性、应用程序部署、CI/CD 对齐和工具选择，以确保其 Kubernetes 队列可靠、高性能且可长期管理。
奠定技术基础
选择正确的 Kubernetes 发行版是一个早期决定，可能会影响未来的运营。Amazon EKS、GKE 和 AKS 等托管服务简化了集群作，而自托管解决方案可能会提供更好的控制，但需要更多的运营开销。此外，集群架构规划应考虑可用域、自动扩展和存储持久性。
同样重要的是让团队为转向云原生思维方式做好准备。Kubernetes 不仅仅是一个新平台;它要求从根本上改变应用程序的构建、部署和维护方式。 习惯于传统基础设施的工程师必须适应声明式管理、容器化工作负载和动态编排。如果没有这种思维方式的转变，即使是技术上最合理的 Kubernetes 部署也可能难以应对运营效率低下和采用挑战。
为 Kubernetes 选择合适的应用程序
并非所有工作负载都天然适合 Kubernetes，也并非所有迁移都遵循从单体应用到容器的简单路径。在决定进行 Kubernetes 迁移之前，组织应评估容器化是否符合应用程序的架构、性能需求和运营目标。
具有不可预测流量模式、基于微服务架构或需要快速扩展的应用程序，能从 Kubernetes 中获益最多。然而，对延迟高度敏感的工作负载、紧耦合的传统应用程序以及具有复杂许可依赖的软件，可能无法从迁移中获得显著收益。一些应用程序可能更适合其他现代化方法，例如无服务器计算或保留传统的虚拟化环境。
对于那些继续使用 Kubernetes 的人来说，下一步是确定哪些应用程序应该首先容器化。无状态服务最容易迁移，只需最少的更改，并使用 Kubernetes 部署高效扩展。另一方面，有状态应用程序需要仔细规划来处理数据持久性和一致性，通常利用 StatefulSets 和持久性卷声明 （PVC）。
此外， 还必须评估依赖关系 — 在迁移之前，可能需要重新构建某些应用程序以与传统服务分离。依赖共享文件系统、传统中间件或传统会话管理的工作负载可能需要额外的重构才能在 Kubernetes 原生环境中有效运行。在某些情况下，混合方法可能是最佳解决方案，其中特定组件保留在 VM 或裸机上，而其他组件迁移到 Kubernetes。
设置安全集群
Kubernetes 的安全性是一个持续的过程，但第 0 天是必须实施基本防护机制的时候。应在命名空间级别强制实施 RBAC，并为工作负载和用户分配精细权限。使用 Kubernetes 网络策略进行网络分段并通过服务网格实施双向 TLS （mTLS） 可以防止未经授权的横向移动。要自动执行安全和策略， 请考虑使用 Kyverno 或 OPA Gatekeeper（本文产品/方案介绍第 4 个）。同时，像 Cilium（利用 eBPF）这样的网络安全工具可以提供超越标准 Kubernetes 网络策略的高级保护。
还应通过禁用未使用的 API 并使用 Fluentd 或 Kubernetes 原生审计日志记录功能收集审计日志来锁定 Kubernetes API 访问。同时，应使用 Web 应用程序防火墙 （WAF） 和 API 网关（如 Kong 或 Ambassador）保护入口，以便在请求到达后端服务之前对其进行过滤和身份验证。
日志记录和监控对于长期可见性至关重要。为了确保跨工作负载的完全可观测性，请考虑使用 Prometheus 和 Grafana 进行性能监控，使用 Loki 进行日志聚合，并使用 OpenTelemetry 进行跟踪。安全监控还应包括使用 Falco 进行运行时保护，以及通过 Kubernetes 安全态势管理 （KSPM） 解决方案进行异常检测。
使 CI/CD 工作流与 Kubernetes 保持一致
Kubernetes 引入了新的部署模型，这些模型可能需要调整现有的 CI/CD 工作流，但这并不意味着传统管道不兼容。虽然 Kubernetes 的声明性质非常适合 GitOps，其中 ArgoCD 和 Flux 等工具维护版本控制的集群状态，但许多组织成功地将 Kubernetes 与传统的 CI/CD 管道集成，例如 Jenkins、GitLab CI/CD 和 CircleCI。
关键是确保部署与 Kubernetes 以声明方式管理基础设施和应用程序状态的模型保持一致。传统的 CI/CD 管道可以通过合并 Kubernetes 清单、Helm 图表或 Kustomize 来定义应用程序配置。一些团队选择混合方法，其中 GitOps 管理基础设施和应用程序发布，而传统管道处理构建、测试和工件管理。
归根结底，正确的方法取决于组织的现有工具、运营成熟度和安全要求。无论是使用 GitOps、传统 CI/CD，还是两者的组合，重点都应该放在确保可靠性、一致性和跨环境的无缝部署上。
Kubernetes 中的故障排除和运行状况管理
成功的 Kubernetes 迁移并不止于部署，它还需要持续监控、故障排除和主动运行状况管理，以确保稳定性。Kubernetes 引入了一个复杂的动态环境，其中工作负载会不断被调度、重新调度和自动扩展。如果没有适当的可见性和诊断工具，识别和解决问题可能具有挑战性。
主动监控和可观测性
实时可观测性对于检测性能瓶颈、资源限制和故障工作负载至关重要。Prometheus（用于指标）、Loki（用于日志）和 OpenTelemetry（用于分布式跟踪）等 Kubernetes 原生工具提供了对集群运行状况的深入可见性。使用 Grafana 构建的控制面板可帮助团队快速评估系统性能并识别异常情况。
诊断和解决问题
Kubernetes 中的故障排除通常需要深入研究多个层次，从应用程序日志到 Pod 事件和集群范围的配置。kubectl describe 和 kubectl logs 等工具提供基本见解，而 Komodor 和 Lens 等更高级的解决方案将日志、事件和配置聚合到单个界面中，以便更快地进行诊断。Kubernetes 的内置运行情况和就绪情况探测有助于识别出现故障的容器并自动重启它们。
自动修复和自我修复
Kubernetes 通过 ReplicaSets 和 StatefulSets 等内置机制支持自我修复功能，这些机制会自动重新调度失败的 Pod。Horizontal Pod Autoscaleers （HPA） 根据工作负载需求调整资源，而 KEDA 等工具则扩展了此功能以实现事件驱动的扩展。在需要人工干预的情况下，AI 驱动的故障排除助手（例如 Komodor 的 Klaudia）可以提供自动见解和指导性修复步骤。
总结
- 使用 RBAC、网络策略和加密密钥（例如 kube-bench、Kyverno、Open Policy Agent） 从一开始就保护。
- 使用 CI/CD 中的轻量级、安全映像和扫描容器（例如 Trivy、Clair）。
- 使用 GitOps（例如 ArgoCD、Flux）自动部署。
- 将可观测性嵌入到 Prometheus（指标）、Loki（日志）和 OpenTelemetry（跟踪）中。
- 通过渐进式交付（例如 Flagger、Argo Rollouts） 实现更安全的部署。
6. 为什么很多企业没有采用私有 AI
Why more enterprises aren’t adopting private AI, and how to fix it
私有本地 AI 的真正优势
- 私有的本地 AI 环境可确保对敏感数据、流程和知识产权的完全控制。组织可以在其基础设施中保护专有数据集，这可能是法规或合规性的需要。
- 私有 AI 的另一个显着优势是成本可预测性。公有云 AI 平台使用基于令牌或查询的定价结构，该结构最初可能是可管理的，但随着使用量的增加，该结构变得越来越不可预测且成本高昂。私有 AI 通过固定成本结构避免了这种情况。
- 私有本地 AI 可以提高硬件效率。企业 AI 使用案例不需要大量部署高端 GPU 或专用加速器。许多组织可以通过少量的中端 GPU 甚至纯 CPU 配置来实现其 AI 目标，从而在不牺牲性能的情况下降低基础设施费用。
部署私有 AI 时会遇到的重大障碍
- AI pipeline 的复杂性
- 对 AI 捆绑解决方案过度承诺
- 安全性和合规性问题
- 硬件锁定和缺乏灵活性
- 存储复杂性和重复性
- 难以构建和管理 AI 模型
- 不明确的直接商业价值
克服企业 AI 障碍的策略
- 集成、简化的 AI 基础架构
- 内置生成式 AI 功能
- 简化的存储基础设施
- 供应商中立的硬件
- 基于 CPU 的 AI 功能，实现灵活性
- 通过设计集成的安全性
- 即时价值和实用价值
- 更广泛的 IT 问题解决能力
拓展阅读
AI 的消耗
What Does AI Cost? No One Knows.
DevOps 团队关注软件交付速度和效率，FinOps 团队关注云成本优化。两个团队之间目标的不一致。DevOps 团队专注于快速迭代和产品发布，常常忽略 AI 工具的实际成本；而 FinOps 团队则难以获得 AI 工具的成本数据，难以进行有效的成本优化。
企业为何转向模型即服务
AI at scale, without the price tag: Why enterprises are turning to Models-as-a-Service
可以通过第三方托管服务（如 OpenAI、Claude 和 Gemini）访问的 Gen AI 模型很容易上手，但在大规模使用时会变得非常昂贵。此外，还存在数据隐私和安全问题，因为企业数据可能会暴露给这些其他方。Gen AI 和其他模型也可以由企业自托管，但这可能会导致各个业务组之间的重复工作，从而增加成本和上市时间。
随着新一代 AI 模型每隔一周发布一次，以及 AI 进步的速度，企业几乎不可能跟上。模型有数十种选项，从非常大的尺寸（450B 参数）到这些模型的较小版本（量化或更少的参数），再到专家模型的混合。许多开发人员缺乏选择正确模型或优化利用昂贵资源（例如 GPU）所需的专业知识。
随着每个业务组构建自己的 AI 解决方案，企业面临着以下几项挑战：
- 成本高
- 重复
- 复杂
- 缺少技能
- 运营控制
MaaS 使企业能够提供可用作共享资源的开源模型（和所需的 AI 堆栈）。实际上，企业 IT 成为可供整个公司使用的 AI 服务的服务提供商。用户可以选择最先进的前沿模型，也可以选择量化或小型语言模型 （SLM），这些模型小几个数量级，但以极低的成本提供相似的性能。这些模型可以使用私有企业数据进行调整和自定义，并且可以在功能较弱的硬件上运行，消耗更少的能源。可以有多个模型实例来处理不同的使用案例和部署环境。所有这些模型都得到了有效的服务，以充分利用可用的硬件资源。
4 个 AI 实施误区
4 AI Implementation Tips That Most Companies Get Wrong
-
忽视文化建设:
缺乏统一的 AI 愿景和企业文化，导致不同层级员工对 AI 的理解和参与度不足。解决方法是自上而下建立清晰的 AI 愿景，并鼓励各级员工积极参与、实验和分享经验。
-
工具选择不当:
要么采取“一刀切”的方案，要么盲目购买昂贵但实际效用低的工具，甚至出现未经授权的“影子 AI”。解决方法是进行细致的需求分析，选择合适的工具，并重视员工反馈。
-
缺乏风险管理:
没有预先考虑 AI 系统可能出现的故障和安全风险，缺乏相应的应急预案和治理策略。解决方法是建立 AI 治理政策，进行故障演练，并建立完善的监控和反馈机制。
-
忽视持续改进:
缺乏事后复盘和持续改进机制，导致 AI 项目无法持续优化和提升价值。解决方法是建立组织级的复盘流程，鼓励团队分享经验教训，并持续改进 AI 系统和流程。
7. Kubernetes 2.0 会是什么样子
What Would a Kubernetes 2.0 Look Like
作者认为 Kubernetes 做对了什么
- 大规模容器
- 低维护
- 运行中的 Jobs
- 服务可发现和负载均衡
作者希望 2.0 中做什么
- 用 HCL 替换 YAML: HCL 具有更强的类型安全性和可读性，能够避免 YAML 中常见的错误。
- 允许 etcd 替换: 提供更灵活的后端存储方案，例如 kine 或 dqlite，以适应不同规模的集群和硬件配置。
- 原生包管理器: 取代 Helm，开发一个更强大、可靠的包管理系统 KubePkg，支持语义版本控制、依赖关系管理、安全验证等功能。
- 默认使用 IPv6: 将 IPv6 设置为默认网络协议，以简化网络拓扑，解决 IPv4 地址耗尽等问题。
拓展阅读
Introduction to Cloud Native Computing
8. 自 CentOS 以来，AlmaLinux 和 Rocky Linux 是如何分道扬镳的
How AlmaLinux and Rocky Linux Have Diverged Since CentOS
背景
AlmaLinux 和 Rocky Linux 的出现都是为了响应 Red Hat 停止 CentOS Linux 而出现的，旨在提供与 Red Hat Enterprise Linux （RHEL） 兼容的免费、社区驱动的企业级作系统。
- CloudLinux 是一家专门从事 Web 服务器 Linux 的基于 CentOS 的公司，它启动了 AlmaLinux。该发行版转移到了非营利性 AlmaLinux OS Foundation。它的重点是提供稳定的、与 RHEL 兼容的应用程序二进制接口（ABI）平台。可通过 TuxCare 获得商业支持。
- CentOS 联合创始人 Gregory Kurtzer 创立了由 Rocky Enterprise Software Foundation（RESF）管理的 Rocky Linux。此发行版强调社区驱动的方法以及与 RHEL 的 1：1 二进制兼容性。要获得 Rocky 支持，您可以访问 Kurtzer 的公司 CIQ。
这两个发行版都依赖于 Red Hat Package Manager（RPM）和 Dandified Yum（DNF）包管理器。虽然 Red Hat 最近还采用了不可变映像来代替 RHEL 10 的软件包修补 ，但 AlmaLinux 和 Rocky Linux 都没有采用这种方法。
差异
- AlmaLinux 基于 CentOS Stream 源代码构建。AlmaLinux 9.4 和 10.0 已明确重新引入了对设备驱动程序和硬件的支持，而 RHEL 9.4 和 10.0 已放弃这些支持。这包括存储控制器、网络适配器和其他对旧服务器和工作站至关重要的组件。AlmaLinux 将根据请求修补常见漏洞和披露（CVE）， 即使 Red Hat 将其评级为低优先级或中等优先级。
- Rocky Linux 通过消除许多潜在的攻击面和常见的漏洞利用媒介，最大限度地降低了零日漏洞和 CVE 风险。它包括代码级强化，可阻止常用的漏洞利用路径，从而降低攻击成功的风险。它还使用 Linux Kernel Runtime Guard（LKRG）来检测绕过传统安全措施的复杂入侵。其中的所有包裹都经过验证，并通过安全的供应链交付，确保作系统安全交付并始终保持最新状态。
9. 如何编写引人注目的软件发布公告
How to Write Compelling Software Release Announcements
发布公告的特色
发布说明从产品出发，注重客观描述，比较无聊，类似更新日志。
发布公告是对用户体验影响最大的更改的摘要。它以一种清晰、可访问的方式呈现它们，以用户为中心。与旨在详尽的发行说明相比，发行公告仅包含最具影响力的更改。
要决定在发布公告中包含哪些功能，请考虑以下问题：
- 用户在最新版本中可以执行哪些以前无法执行的作？
- 哪些工作流程变得更简单了？
- 哪些工作流程变得更快了？
称其为“更快”而不是“不那么慢”
从用户的角度来看，新版本不仅仅是相同的软件减去一个错误——它是一种明显更好的体验。专注于改进而不是缺陷。与其宣布没有 bug，不如庆祝你如何改善用户体验。
发布公告绝不应包含“各种改进和错误修复”一词。您不妨吹嘘该团队在整个开发过程中自豪地呼吸空气并使用最新版本的 Internet。如果您无法阐明某项更改如何使用户受益，请不要在发布公告中突出显示它。将详尽的更改列表保存到您的发行说明中，但即使在那里，也请省略“各种改进和错误修复”。
简要介绍产品
除了与现有用户建立忠诚度外，发布公告还应激起新的潜在用户的兴趣。在公告的开头，请简要说明您的产品的功能。如果读者不熟悉您的产品，他们至少需要了解什么才能理解您的公告的其余部分？不要用 20 段的介绍来疏远现有用户，因为他们已经知道了。一两句话将为新用户提供上下文，而不会因对现有用户造成过多的噪音而稀释您的公告。
充分利用截屏 + 保持动画演示简短而甜美
RT
在开发过程中规划发布公告
在发布计划的早期考虑发布公告。为了确保发布能够真正为用户带来价值，并避免发布一些对用户体验没有明显提升的功能。
10. 什么时候应该开始使用 kubernetes
When should you start using kubernetes
简介
帖主与同事讨论：是应该从一开始就使用 kubernetes，还是等真正需要时再使用。讨论的点在于 Kubernetes 的复杂性；缺乏人力来管理；其提供的自动伸缩、RBAC、负载均衡等功能短期内并不需要。
具体讨论见原帖，整体看来是建议早点使用，当需要的时候再做可能成本更大。总之，切换需要代价，只是需要结合具体情况权衡来尽量减小代价。
拓展阅读
📄 专题四 报告查看与分析
1. [PaperDuty] 在过去一年中，影响客户的事件增加了 43%，每个事件的成本接近 800,000 美元
调查由 Censuswide 于 5 月 31 日至 6 月 6 日进行。它采访了 500 名 IT 领导者和决策者，他们来自美国 （200）、英国 （150） 和澳大利亚 （150） 拥有 1000+ 名员工的组织。该调查是在线进行的。
⚠️ 报告的发布时间是 2024 年。PagerDuty 公司是一家美国云计算公司，专门为 IT 运维部门提供 SaaS 事件管理平台。所以该报告具有推广自身产品的作用。
认为影响客户的事件有所增加（按行业）
- 旅行：78%
- 金融服务：68%
- 零售：40%
认为事件的影响
- 法律和监管问题：25%
- 创新减慢：35%
- 公司股价受损：24%
- 客户/收入流失：32%
事件的年成本（按行业）
- 金融：$30.5m
- 旅行：$20.3m
- 零售：$8.2m
尚未完全自动化的事件响应任务
缺乏完全自动化的流程意味着团队要处理大量的浪费 —— 那些几乎不增加任何价值的行动或步骤，这些都可能带来巨大的成本。在过去 12 个月中，各组织平均在事件响应人员上花费了 190 万美元。但如果这些响应人员将 38% 的时间花在处理手动事件响应流程上，那么这种劳务成本每年可能达到 70 万美元。
自动化的障碍
- IT 部门内部缺乏协同：24%
- 预算限制：22%
- 人才/专业知识不足：16%
- 数据管理实践不完善：16%
- 高层领导缺乏协同：12%
拓展阅读
Bridging the Gap Between Monitoring and Incident Resolution
实际操作
要实现有效的可观测性驱动型事件管理，首先要了解服务环境。要成功地将可观测性数据转换为可作的工作流，请执行以下操作：
- 进行服务映射
- 记录关键服务依赖关系。
- 定义明确的所有权边界。
- 建立服务级别目标 （SLO）。
- 使用相关元数据创建服务目录。
- 构建智能层
- 部署机器学习以进行模式识别。
- 实施自动化事件分类。
- 创建动态事件路由规则。
- 制定优先评分机制。
- 自动化响应模式
- 确定常见的事件类型。
- 创建自动化诊断例程。
- 尽可能实施自动修复。
- 建立测量和反馈机制。
- 优化上游监控
- 审查和整合监控工具以减少重叠。
- 根据实际事件模式调整警报阈值。
- 实施关联规则以减少警报噪音。
- 在事件管理和监控配置之间创建反馈循环。
效果评估
- 平均确认时间 （MTTA） 缩短。
- 平均解决时间 （MTTR） 的改善。
- 减少警报噪音和误报。
- 提高自动解决百分比。
2. [Spacelift 委托 Panterra Group 制作] 2025 年基础设施自动化报告
The Infrastructure Automation Report, 2025
背景
大量新的自动化工具涌入市场，自动化采用率也创下历史新高。但现实是——许多团队认为他们的表现比实际更好。他们建立了漂亮的新工作流程和自动化流程，但当你深入探究时，结果并没有他们声称的那么令人印象深刻。高故障率、低效的资源利用以及安全和合规方面的漏洞表明，自动化成熟度不仅在于采用新工具，更在于有效地实施它们。
事实是，不仅仅是技术在推动更好的绩效——促使自动化成功的，是流程和团队结构。平台工程、自助服务赋能以及自动化优先的思维文化，是将高绩效团队与那些仅仅在传统工作流程上堆叠新工具的团队区分开来的关键。我们的数据显示，领先的公司实施基础设施即代码最佳实践的可能性是其落后同行的两倍多，为基础设施变更实施自动化测试的可能性是其三倍以上，而实施平台工程团队的可能性更是其五倍。如果没有这些基础要素，自动化工作就会停滞不前，导致运营效率低下、安全盲点以及对进展的错误信念。
值得庆幸的是，自动化可以解决许多这些挑战。通过自动化工作流程实现更快的资源调配，通过自动调配实现按需扩展，版本控制的工具链简化调配和配置管理——这样的例子不胜枚举。我们已经取得了长足的进步。以至于许多组织都相信他们已经完全掌握了基础设施自动化。
但数据讲述了一个不同的故事——一个充满效率低下、瓶颈和错误配置的故事。
对于基础设施自动化水平，许多组织在自我感知与实际执行之间存在着显著差距
虽然 45% 的组织认为他们已经实现了高水平的基础设施自动化，但根据研究，只有 14% 的受访者表现出真正的基础设施自动化领导者的行为和技术模式。
如果这么多组织都认为他们已经达到了自动化成熟度，那么现实为何会讲述一个不同的故事呢？答案在于一个根本性的权衡：速度是以牺牲控制为代价的。这就是我们所称的“速度-控制悖论”——追求更快的部署，却无意中导致了在安全、合规和成本管理方面的失控。
顶尖的组织已经找到了一种方法来驾驭这个速度-控制悖论，在快速部署、开发者自助服务和治理之间取得了平衡。通过调查，基于对组织行为、工具、性能和结果的稳健分析，开发了“基础设施自动化领导力指数”，以识别这些顶尖表现者并分离出成功模式。好消息是，他们的情况并非独一无二。领导者所做的并没有什么特别之处是其他人无法效仿的。主要模式包括：
- 实施开发者自助服务。减少开发者生产力的瓶颈，同时确保应用性能并维护适当的防护措施以降低风险。
- 及早整合安全和合规。确保安全和合规从一开始就是你的自动化战略的一部分，而不仅仅是事后考虑。
- 采纳平台团队方法。自动化速度、控制和安全是一种平衡行为，需要刻意专注来维持。统一的平台团队方法能够实现这一点。
- 优先考虑成本优化。积极管理基础设施资源利用率，以消除过度配置并避免浪费。
- 避免孤立的自动化。集中管理既能调配基础设施（Day 1），又能长期管理资源（Day 2）的自动化。
如今，基础设施团队正在应对日益分布式的架构、多云环境、本地基础设施以及不断增长的工具和流程堆栈——事实上，81% 的团队报告在混合云环境中运行。与此同时，开发团队面临着更快交付、提供卓越用户体验和最小化停机时间的压力。这些团队还必须确保遵守严格的安全和法规要求。许多组织认为他们在速度-控制悖论中取得了正确的平衡，但实际上，他们只是加速了部署频率，而没有设置适当的防护措施。
调查发现，超过 50% 的公司每周花费一周或更多时间来部署基础设施变更到生产环境，并且 43% 的公司需要重新运行其基础设施部署超过四次才能成功。
随着公司变得更加成熟，自动化的重点会发生转移。领导者优先考虑控制；而那些在自动化旅程早期阶段的公司则优先考虑速度。当被问及他们的自动化优先级时，只有 29% 的早期阶段公司专注于控制（正确完成基础设施变更），而只有 39% 的领导者专注于速度。这种差异是显著的。
如果感兴趣的话，也可以做下 自我评估。
解决速度控制悖论
确定领导者
自动化卓越是一个旅程，而不是你一键即可开启的开关。我们开发了基础设施自动化领导力指数，旨在提供一个结构化方法，用于评估从基本自动化实践到先进、可扩展和安全自动化基础设施的管理。
领导者并非一开始就如此。他们克服了大多数公司今天面临或明天将面临的相同挑战。但无论你今天身处何地，你都可以从他们来之不易的努力中学习，并直接跳到他们的位置。
以下是领导者展现的一些关键模式：
- 评估你当前的状态：迈向自动化成熟度的第一步是了解你所处的位置。利用下方自评估工具，根据基础设施自动化领导力指数来衡量你的自动化能力得分。识别你在速度、控制和协作方面的当前优势、劣势和差距。进行自我评估可以帮助组织明确其自动化旅程，并发现可能阻碍进展的盲点。
- 通过自动化降低风险：安全和合规必须是自动化流程中不可或缺的一部分，而不是事后才考虑。将安全性融入到你的基础设施中是终极的“左移”方法。组织可以引入工具和流程，帮助他们轻松识别和修复安全问题和漏洞，而无需等待这些问题进入生产环境并变得关键。通过将策略作为代码，以及利用安全漏洞扫描工具、可观测性平台和测试机制，你可以确保基础设施安全问题和议题在它们成为风险之前就被早期发现。
- 优先考虑速度，但要设置控制标准：在没有正确防护措施的情况下加速自动化会导致不稳定和风险。在关注部署速度之前，请确保合规性、安全性和漂移管理是稳固的。寻求确保合规性的组织通常会引入策略，这些策略对于确保标准化至关重要，因为你的团队将无法调配他们不应该调配的资源。他们还确保资源遵守你的组织施加的防护措施。安全检查，特别是那些检测漏洞的检查，可以确保你的组织是安全的并降低停机风险。通过漂移管理，你可以确保基础设施的预期状态已部署，从而降低配置错误、性能下降和停机时间的可能性。
- 通过自助服务加速开发者效率：自动化应该使工作更轻松，而不是引入新的瓶颈。领导者通过自助服务自动化赋能开发者，同时保持防护措施以降低风险。他们优先考虑基础设施敏捷性，确保能够实时扩展资源以满足需求，而无需等待手动审批或处理复杂的工单系统。通过为开发者启用自助服务，你可以降低成本，提高扩展能力，并增强协作。最终，所有这些好处都将转化为增加的业务价值。
- 优先考虑成本优化作为业务驱动因素：更智能的自动化可以消除过度配置和浪费。通过将策略作为代码与自动化成本估算相结合，你可以在预算周围创建清晰的防护措施。你可以自动拒绝导致过度配置的部署，并确保资源符合预先批准的参数。自助服务模板还可以通过只允许用户部署预先批准的模板来优化成本，确保资源具有可预测的成本并减少人为错误。
- 采用平台工程实现一致性和规模：孤立的自动化工作会造成碎片化和低效率。为了有效扩展，组织应该通过平台工程团队来集中自动化。这些团队标准化基础设施，强制执行最佳实践，并提供平衡自主性与治理的自助服务能力。29% 的领导者已经实施了平台团队，而总受访者中只有 7% 实施了。平台工程确保自动化能够高效扩展，而不会引入混乱。
3. [RedHat] 2024 年红帽产品安全风险报告
Red Hat Product Security Risk Report 2024
The open source paradox: Unpacking risk, equity and acceptance
部分摘抄
⚠️ 具体可以看原文。
开源一直以来都充满悖论：它是由充满激情的开发者免费开发的软件，却又被世界上一些最大的公司商业化和资助。它曾被视为“异类”，甚至被称为“癌症”，但它却是我们所见过的创新和技术进步的最大驱动力。在开源世界中，悖论将永远存在，但在对安全漏洞的理解上，这种悖论体现得尤为明显。
25 年前，Common Vulnerabilities and Exposures (CVE) 项目成立，旨在标准化软件缺陷的命名和跟踪。在其成立的第一年，即 1999 年，共编目了 894 个漏洞，这凸显了即使在相对较小的数量下，对一致性识别的早期需求。
在该项目的前六年，由于更广泛的采用，分配的 CVE 数量激增了 450% 以上。这种增长持续呈指数级，到 2017 年达到近 15,000 个 CVE，两年内增长了 125%。到 2023 年，数量又攀升了 50%，达到 29,000 多个。这种爆炸式增长凸显了软件日益复杂化、软件可用性增加以及更多供应商采用 CVE。
漏洞形势持续急剧扩大。2024 年，分配的 CVE 数量激增 39% 至 40,000 多个，部分原因在于 Linux 内核获得了 CVE 编号机构 (CNA) 状态。如果其他软件领域，如移动应用程序或游戏开发，开始正式跟踪 CVE，这种增长轨迹可能会显著加速。
对未修补漏洞的担忧通常集中在开源上，这主要是因为它具有透明性。我们都可以看到代码和 CVE。相比之下，专有供应商通常不会披露他们认为不值得修复的低影响缺陷，从而造成不透明的风险状况。在开源中生成公开 CVE 的微小缺陷，在专有软件中可能不被报告、不被修复或被悄悄修补。
这种可见性差异造成了双重标准。要求“没有已知漏洞”的政策本质上是针对开源的透明性，而不一定是其更高的风险。关键是，你的组织已经默认接受了你日常使用的专有软件中未披露的微小缺陷的风险。真正的风险管理需要承认这一点。我们必须应用一致的、明确的风险评估，重点关注所有软件的可能可利用性和影响，而不是惩罚开源固有的可见性。
确定行动优先级的关键指标是实际利用。数据分析（利用像网络安全和基础设施安全局 (CISA) 的已知已利用漏洞 (KEV) 目录等来源）持续表明，漏洞利用率仍然非常低——历史上每年远低于 0.5%。这相当于大约每 200 个漏洞中，仅有 1 个被实际利用。知道了这一点，我们应该关注更务实、基于风险的方法。
重点必须转向那些最有可能被利用且可能造成重大损害的漏洞——通常是那些能够实现远程、未经身份验证访问并具有高权限提升的漏洞，我们称之为关键（Critical）或重要（Important）。通过将修复工作集中在这些高风险/高影响的漏洞上，我们可以在现有资源下最大程度地降低风险。这不可避免地意味着战略性地接受那些不太可能被攻击或即使被利用也不会造成实质性影响的漏洞所带来的较低残余风险，这些漏洞大多是低（Low）和中等（Moderate）问题。
有效的风险管理并非消除所有漏洞；它在于优先处理那些构成真实、可能威胁的漏洞，并有意识地接受其他方面可控的风险。
拓展阅读
在 2025.04 的简报中曾经讨论了 CVE CVE 究竟是什么以及摘抄了一篇关于开源的文章 关于大公司积极参与开源。
4. [Octopus Deploy] The State of GitOps report
简介
GitOps 借鉴了 DevOps 和基础设施即代码（IaC）的思想。通过将基础设施和应用程序的定义存储在版本控制中，团队可以使用熟悉的工具进行更改、审查、回滚和审计。就像 DevOps 一样，GitOps 也有文化和技术要素。团队同意让所有更改都通过声明性状态文件进行流动，并就更改进行协作。一旦团队进行更改，高水平的自动化确保它们得到应用。
GitOps 的核心是一个协调循环，它观察系统的当前状态，将其与所需状态进行比较，并进行调整以使当前状态与所需状态保持一致。
重点摘抄
按生产使用比例统计：
按组织规模统计：
按行业统计：
GitOps 的用途：
采用开源 GitOps 工具：
基础设施自动化工具：
GitOps 实践前景：
声明式配置的使用区域：
GitOps 提高安全性：
GitOps 防止配置漂移：
GitOps 提高可审计性：
GitOps 简化合规性：
GitOps 降低了高权限访问：
5. [Broadcom] Private Cloud Outlook 2025: The Cloud Reset
Private Cloud Outlook 2025: The Cloud Reset
摘要
-
私有云现在是战略重点
虽然公有云服务传统上被认为是云工作负载的默认目的地，但报告中提供的受访者数据却描绘了完全不同的情况。
- 93% 的受访者有意识地平衡私有云和公共云的组合，他们 3 年的首要任务是在私有云中构建新的工作负载。
- 69% 的受访者正在考虑将工作负载从公有云转移到私有云，其中三分之一的受访者已经这样做了。
- 84% 的企业在私有云中运行传统和云原生应用程序，消除了其传统形象。
-
安全性、GenAI 和成本可预测性推动了私有云的采用
安全性和合规性是公有云采用和生成式 AI （GenAI） 计划的主要挑战，同时也是将工作负载从公有云遣返到私有云的主要驱动力。
- 92% 的客户信任私有云的安全性和合规性。
- 90% 的受访者重视其财务可见性和可预测性。
-
释放私有云的潜力
为了充分利用私有云的优势，组织必须解决两个关键领域：
- 克服孤立的 IT 团队
- 33% 的组织表示，孤立的 IT 团队是私有云采用的最大挑战。
- 81% 的受访者现在围绕平台团队而不是技术孤岛构建他们的技术组织。
- 缩小技能差距
- 30% 的受访者表示，缺乏内部技能/专业知识是采用私有云的障碍
- 80% 的受访者依赖专业服务来满足云相关需求。
- 克服孤立的 IT 团队
云的使用情况与优先级
-
私有云和公共云的有意混合是常态
92% 的企业混合运行私有云和公共云。四分之三的受访者表示，这种组合是他们有意为之的策略。
-
单一部署模式的雄心现在很少见
只有 15% 的受访者表示他们更喜欢全公有云模式，10% 的受访者赞成纯私有云部署。在实践中，使用公共云和私有云混合使用的组织百分比预计将在未来三年内保持稳定（达到 93%）。
在接下来的三年里。在预测更大变化的受访者中，计划增加支出 （8%） 的受访者几乎是计划削减支出 （3%） 的三倍，私有云和公有云的前景相同。
IT 优先级：新工作负载、效率和安全性
- 在私有云环境中构建新的工作负载 （53%）
- 在公共云环境中构建新的工作负载 （50%）
- 优化云工作负载的成本管理 （45%）
- 提高安全性和灾难恢复 （44%）
Cloud Sentiment：优点和缺点
这两种云部署类型在可靠性和 IT/运营简化方面都获得了很高的满意度。但是，公有云的最高满意度得分是可扩展性，而私有云的最高满意度得分是安全性。
尽管满意度很高，但大约三分之一到一半的受访者没有达到他们最初的云目标。云采用与云影响之间的这种巨大差距归因于各种障碍。使用公有云时，成本、复杂性和合规性方面的问题仍然存在，许多组织认为他们在浪费资金，同时对保护存储在公有云环境中的数据表示强烈担忧。与私有云相关的最大障碍是孤立的 IT 团队和传统 IT 运营模式的盛行。
公有云的 3 大挑战
成本、复杂性和合规性是 IT 决策者最关心的问题
-
成本
近一半的组织 （49%） 认为其公共云支出的四分之一以上被浪费了，31% 的组织认为浪费超过 50%。只有 6% 的受访者认为他们没有浪费任何公共云支出。
-
复杂性
大多数企业都认为，组织孤岛使云管理复杂化，从而难以在公有云中保持可见性、控制和治理。
- 76% 的人认为公有云正在创建新的非核心 IT 孤岛。
- 77% 的人认为这些孤岛正在部署可能不遵循政策或最佳实践的资源。
- 70% 的人认为这些孤岛使 IT 难以管理成本和安全。
-
合规性
公有云服务的全局性和共享性引发了人们对管理公有云中存储的数据的合规性的能力的重大担忧。66% 的受访者表示“非常”或“极度”担心在公共云环境中存储数据。此外，61% 的受访者“非常”或“极度”担心跟上不断变化的合规性要求。
安全问题是私有云的驱动因素
安全问题被认为是采用公有云的主要障碍，是部署生成式 AI 工作负载的最大障碍，也是将工作负载从公有云遣返到私有云的主要原因。44% 的组织将加强云安全性和弹性列为未来三年的首要云优先事项。相比之下，92% 的组织表示，他们信任私有云的安全性和合规性。安全性在私有云环境中获得了最高的满意度评级，四分之一的组织正在利用经过主权认证的私有云解决方案。
工作负载遣返：日益增长的运动
一个特别值得注意的趋势是，69% 的企业正在或考虑将工作负载从公有云环境遣返到私有云环境，其中三分之一的受访者已经遣返了一些工作负载。这不仅仅是将遗留应用程序移回或撤消失败的迁移;它反映了一种基于特定要求的更有意识的工作负载分配方法。
云原生工作负载的首选云环境
云环境适用性实际上并不是由应用程序是特定技术（如虚拟机）还是容器，而是通过将应用程序的需求与可用的云平台特征相匹配。
私有云面临的主要挑战
- 安全性与合规性
- 缺乏内部技能/专业知识
- 供应商平台 Cloud 限制
- 对基于云的 IT 模型的抵制
运行 GenAI 的环境
调查方法
拓展阅读
Private Cloud’s Comeback: Driving the Enterprise IT Reset
Kubernetes Delivers Scalable Analytics in Hybrid Clouds
✍️ 专题五 产品/方案介绍
1. Flux：GitOps 持续交付工具
简介
Flux 是一种工具，用于使 Kubernetes 集群与配置源（如 Git 存储库和 OCI 构件）保持同步，并在有新代码要部署时自动更新配置。Flux 是一组面向 Kubernetes 的持续和渐进式交付解决方案，这些解决方案是开放且可扩展的。
Flux version 2 ("v2") 是从头开始构建的，以使用 Kubernetes 的 API 扩展系统，并与 Prometheus 和 Kubernetes 生态系统的其他核心组件集成。在版本 2 中，Flux 支持多租户并支持同步任意数量的 Git 存储库，以及其他长期要求的功能。
特点
-
适用于应用程序和基础架构的 GitOps
Flux 和 Flagger 使用 Canary、功能标志和 A/B 部署来部署应用程序。Flux 还可以管理任何 Kubernetes 资源。内置了基础架构和工作负载依赖关系管理。 -
声明式 & 自动化
描述系统的整个所需状态 Git 的 Git 中。这包括应用程序、配置、控制面板、监控和其他所有内容。用 YAML 强制遵守声明的系统。您无需运行 kubectl 的 Json 示例，因为所有更改都会自动同步。 -
可审计
一切都通过 pull requests 进行控制。您的 Git 历史记录提供了一系列事务，允许您从任何快照中恢复状态。
功能
- 自动化协调应用部署和渐进式交付 (CD/PD): 通过自动协调机制实现应用部署，并结合 Flagger 支持金丝雀发布、特性标志和 A/B 测试等高级交付策略。 甚至可以自动将容器镜像更新推送到 Git。
- 支持多种集成: 兼容各种 Git 提供商（GitHub、GitLab、Bitbucket 等）、主要容器注册表、OCI 规范，以及所有 CI/CD 工作流提供商。
- 强大的安全特性: 采用基于 Kubernetes RBAC 的细粒度权限控制，支持多 Git 仓库，并与多种安全工具和最佳实践紧密集成。
- 多集群支持: 开箱即用地支持多集群基础设施和应用管理，可以使用一个 Kubernetes 集群管理其他集群，甚至可以创建和管理集群生命周期和集群规模。
- 广泛的工具支持: 支持 Kustomize、Helm 等工具，以及 Slack 等多种通知系统，并支持基于策略的验证 (OPA、Kyverno 等)。
拓展阅读
🚀 KRM-Native GitOps: Yes — Without Flux, No. (FluxCD or Nothing.)
观点：KRM（Kubernetes Resource Model ）原生 GitOps 的最佳实践是使用 FluxCD，而不是 ArgoCD。（KRM-Native GitOps 是一种架构模式。它最终为平台工程带来了真正的简单性。）
作者从多个方面对 FluxCD 和 ArgoCD 的对比：
| 特性 | FluxCD | ArgoCD | 备注 |
|---|---|---|---|
| 架构哲学 | Kubernetes 原生，极简主义，注重一致性 | Kubernetes 兼容，功能丰富，注重用户体验 | Flux 更贴近 Kubernetes 的设计理念；ArgoCD 功能更全面，但可能更复杂 |
| 同步模式 | 默认拉取模式 (Pull) | 默认推送模式 (Push)，也支持拉取模式 | Pull 模式更安全，Push 模式更灵活，但潜在风险更高 |
| 权限管理 | 使用 Kubernetes 原生 RBAC | 自带权限模型，叠加在 Kubernetes RBAC 之上 | Flux 更安全，ArgoCD 的自定义权限模型可能造成安全隐患 |
| 秘密管理 | 原生集成 SOPS，支持加密的 YAML secrets | 官方不推荐在 Git 中管理 Secrets，建议使用外部 Secret Manager | Flux 更符合 GitOps 原则，ArgoCD 需要额外工具和配置 |
| 事件驱动 | 事件驱动 | 轮询 (Polling) | Flux 响应更快，更符合 Kubernetes 的反应式设计；ArgoCD 需要配置轮询间隔 |
| UI | CLI 优先，可配合 Headlamp 等工具使用 | 提供丰富的 Web UI | ArgoCD 的 UI 更直观易用，但可能导致非 GitOps 操作，增加风险；Flux 更注重自动化流程 |
| Helm 支持 | 原生支持 Helm，通过 HelmRelease 和 HelmChart 管理 | 通过 helm template 渲染，不直接使用 Helm API | Flux 更规范地集成 Helm；ArgoCD 对 Helm 的支持较为间接 |
| Kustomize支持 | 原生支持 | 支持，但不如Flux原生集成好 | |
| Gitless GitOps 支持 | 原生支持 OCI artifacts | 支持，但处于实验阶段，社区驱动 | Flux 更成熟地支持 Gitless GitOps |
| 复杂度 | 相对较低 | 相对较高 |
2. llm-d：Kubernetes 原生高性能分布式 LLM 推理框架
简介
llm-d 提供了一条明智的途径，以最快的价值实现时间和极具竞争力的每美元性能，大规模服务大型语言模型。llm-d 基于 vLLM、Kubernetes 和 Inference Gateway 构建，为分布式推理提供了模块化解决方案，具备 KV 缓存感知路由和解耦服务等功能。
特点
- vLLM 优化的推理调度器
llm-d 基于 IGW 的模式构建，通过端点选取器协议 （EPP） 实现可定制的“智能”负载均衡，以定义 vLLM 优化的调度。Inference Scheduler 利用运营遥测，实施筛选和评分算法，以通过 P/D、KV 缓存、SLA 和负载感知做出决策。高级团队可以实施自己的评分器以进一步自定义，同时受益于 IGW 中的其他功能，例如流量控制和延迟感知平衡。 - 使用 vLLM
llm-d 的分解服务利用 vLLM 对分解服务的支持，使用高性能传输库（如 NVIDIA 的 NIXL）在独立实例上运行预填充和解码。在 llm-d 中，我们计划支持使用快速互连（IB、RDMA、ICI）的延迟优化实施，以及使用数据中心网络的吞吐量优化实施。 - 使用 vLLM
llm-d 的分解式前缀缓存使用 vLLM 的 KVConnector API 为以前的计算提供可插拔缓存，包括将 KV 卸载到主机、远程存储和 LMCache 等系统。我们计划支持两种 KV 缓存方案。
拓展阅读
Deep Dive into llm-d and Distributed Inference
llm-d 背后的关键创新是它如何分发推理。它将推理过程分为两个不同的阶段，即预填充和解码，并在单独的工作负载（Pod）中运行。该项目将这种方法称为 “解聚”。
3. kong2eg：使用 Envoy 网关将 Kong 配置迁移到 Envoy
简介
kong2eg 是一种迁移工具，通过将 Kong 集成为 Envoy Gateway 中的外部处理扩展，帮助您从 Kong Gateway 过渡到 Envoy Gateway。这允许继续使用 Kong 插件进行请求和响应转换，而路由和流量控制由 Envoy Gateway 处理。
相关背景
从版本 3.10 开始，Kong 停止为 Kong OSS（开源软件）发布预构建的 Docker 镜像。
Kong Pulls the Plug on FreeOpen Source Support, Users Left Scrambling
We had 2 hours before a prod rollout. Kong OSS 3.10 caught us completely off guard.
4. OPA Gatekeeper：基于 Kubernetes 的策略执行引擎
Simplify Kubernetes Security With Kyverno and OPA Gatekeeper
简介
Open Policy Agent（OPA） Gatekeeper 是专为与 Kubernetes 配合使用而定制的策略执行工具。策略是用 Rego（OPA 的声明性查询语言 ）编写的，用于定义规则并动态实施安全策略。它允许您编写策略来检查 Kubernetes 设置中的某些内容是否违反了定义的规则。
OPA Gatekeeper 充当 Kubernetes 准入控制器，在部署资源之前评估策略，并帮助从一开始就确保合规性。
主要功能
- 策略逻辑与约束分开，使其可以在不同的策略之间重复使用。用 Rego 编写的策略逻辑定义了应该检查的内容（例如：“命名空间必须具有团队标签”），而 constraints 告诉 Gatekeeper 在何时何地应用策略逻辑（例如：“将此规则应用于此集群中的所有命名空间”）。
- 扫描现有资源查找冲突。
与 Kyverno 的对比
关于 Kyverno 的介绍可以见之前的内容 2025.05 云原生相关信息简报 - Kyverno：提供一套全面的工具来管理 Kubernetes 和其他云原生环境的策略即代码（PaC）生命周期。
| 功能 | Kyverno | OPA Gatekeeper |
|---|---|---|
| 策略语言 | YAML | Rego |
| 复杂度 | 简单 | 复杂 |
| 变更支持 | 是 | 否 |
| 自定义资源支持 | 是 | 有限 |
| 灵活性 | 中等 | 高 |
| 学习曲线 | 低 | 高 |
5. Envoy AI Gateway ：通过 Envoy Gateway 处理从客户端到生成式 AI 服务的请求流量
Envoy AI Gateway v0.2 is available
简介
Envoy AI Gateway 是一个开源项目，用于使用 Envoy Gateway 处理从应用程序客户端到生成式 AI 服务的请求流量。旨在通过利用 Envoy 的灵活性和 Kubernetes 原生功能来解决将应用程序连接到 GenAI 服务的复杂性。该项目通过 Envoy 社区的贡献而发展，促进了解决现实世界挑战的协作方法。
产品目标
- 跨提供商和自托管模型的弹性连接 ：创建与 LLM 提供商（如 OpenAI、Anthropic、AWS Bedrock 等）和自托管模型集成的强大、容错连接，通过智能路由和自动故障转移确保高可用性。
- 性能和成本管理的全面可观察性：提供对流量性能、使用模式和成本分析的可见性，使组织能够优化其 GenAI 使用情况并监控服务质量。
- 企业级安全功能 ：实施安全控制，包括精细访问控制、授权策略、速率限制，以访问服务，并确保通过上游身份验证从网关安全出口连接到外部提供商。
- 可扩展架构 ：利用 Envoy 经过验证的可扩展性框架来支持自定义功能的快速开发，使组织能够根据其特定的 AI 基础设施需求调整网关。
- 带有 Envoy 代理的可靠基础 ： 以 Envoy 久经考验的代理技术为基础，提供稳定、高性能和生产就绪的基础，企业可以依赖它来满足其流量处理需求。
与 Envoy Gateway 的关系
它是 Envoy 项目的一部分，与 Envoy Gateway 一起安装，并扩展了 Envoy Gateway 和 Envoy Proxy 的功能，用于 AI 流量处理。
6. Kubebuddy：Kubernetes 健康检查器
简介
KubeBuddy 是一个基于 PowerShell 的 Kubernetes 助手，可帮助您监控集群运行状况、工作负载、网络、安全性等。它会生成 HTML 和基于文本的报告 ，以帮助您快速评估 Kubernetes 环境。
功能
- 集群运行状况监控：检查节点状态、资源使用情况和 Pod 条件。
- 工作负载分析：识别失败的 Pod、重启循环和卡住的 Job。
- 事件报告：汇总 Kubernetes 事件以突出显示错误和警告。
- RBAC 和安全检查：识别过多的权限和错误配置。
- 存储和网络洞察：分析持久性卷、服务和网络策略。
- 可自定义阈值：在 kubebuddy-config.yaml 中配置 warning/critical 级别。
- HTML 和文本报告：生成用于分析和共享的干净报告。
- PowerShell 支持：通过 PowerShell 库安装并在 Windows、macOS 或 Linux 上运行。
- AKS 最佳做法检查：检查 Azure Kubernetes 服务（AKS）集群以获取最佳做法。（目前有 34 个全自动测试）
特点
- 全面诊断
通过一条命令检测节点故障、Pod 崩溃、安全风险和网络问题。 - 无集群入侵
通过您的终端或 Docker 在外部运行，不需要代理或 Helm Charts。 - 可作报告
导出详细的 HTML、JSON 或 CLI 摘要，以便快速了解和共享。 - 干净执行
KubeBuddy 完全在集群外部运行。无代理，无配置偏差，无暴露。 - 无状态设计
扫描不会保留任何内容。无运行时占用空间，无安全包袱。 - 随时随地运行
在本地、CI/CD 或跳转主机上使用它 - 无论您在哪里工作。
7. Volcano：适用于计算密集型工作负载的云原生批量调度系统
简介
Volcano 是一个 Kubernetes 原生的批量调度系统，扩展和增强了标准 kube-scheduler 的能力。它提供了一套全面的功能，专门用于管理和优化各种批处理和弹性工作负载，包括人工智能 （AI） / 机器学习 （ML） /深度学习 （DL）、生物信息学 / 基因组学和其他“大数据”应用程序。
这些工作负载通常利用 AI、大数据和 HPC 框架，例如 Spark、Flink、Ray、TensorFlow、PyTorch、Argo、MindSpore、PaddlePaddle、Kubeflow、MPI、Horovod、MXNet、KubeGene 等，Volcano 与这些框架提供了强大的集成。
Volcano 是云原生计算基金会 （CNCF） 的孵化项目。
特点
- 统一调度
支持 Kubernetes 原生工作负载和主流计算框架（如 TensorFlow、Spark、PyTorch、Ray、Flink 等）的集成任务调度。 - 队列管理
提供多级队列管理能力，实现细粒度资源配额和任务优先级调度。 - 异构设备支持
高效调度 GPU 和 NPU 等异构设备，充分释放硬件计算潜力。 - 网络拓扑感知调度
极大提升 AI 分布式训练场景下的模型训练效率。 - 多集群调度
支持跨集群作业调度，提升资源管理能力，实现大规模负载均衡。 - 在线和离线工作负载协同
通过智能调度策略，实现在线和离线工作负载的协同部署，提高集群资源利用率。 - 负载感知去调度
优化集群负载分布，增强系统稳定性。 - 多种调度策略
支持多种调度策略，如 Gang-Scheduling（组调度）、Fair-Share（公平共享）、Binpack（装箱）、DeviceShare（设备共享）、NUMA-aware scheduling（NUMA 感知调度）、Task Topology（任务拓扑）等。
拓展阅读
Volcano v1.12 正式发布！驱动云原生AI与批量计算向智能高效新阶段演进
同类产品
8. Ratify：制品元数据安全验证工具
简介
Ratify 是一个可扩展的验证框架，针对容器镜像及其他制品。它能检查并制定策略，对 Kubernetes 和 CI/CD 中的现有资源进行审计。Ratify 可管理任意数量的自定义验证器，用于验证镜像元数据，如签名、SBOM、漏洞扫描报告等。
特点
- 端到端的策略驱动验证能力
- 支持多种验证器插件（如 Notation、Cosign、SBOM、漏洞报告、自定义插件）及多云平台（AWS、Azure、阿里云、Venafi 等）
- 在 Kubernetes 中部署不可信应用时通过准入控制进行强制执行
- 支持 Gatekeeper、Trivy 等跨工具生态系统
拓展阅读
Ratify 加入 Notary Project —— 共同加强软件供应链安全！
Notary Project 正在构建一套规范和参考实现，以保障容器镜像及其他 OCI 制品的完整性。Ratify 加入后，Notary 在基于策略的验证和可扩展性方面得到扩展，帮助组织在 CI/CD 环境及 Kubernetes 部署前验证签名、SBOM、漏洞扫描报告等安全元数据。
Ratify 成为官方子项目后，Notary Project 提供了更丰富、更有针对性的解决方案栈来保障软件供应链安全：
- Notation 支持在 CI/CD 流水线中对 OCI 制品进行签名
- Ratify 在容器运行时、Kubernetes 和 CI/CD 流水线中强制执行签名及其他供应链元数据的验证策略
9. Kite：现代 Kubernetes 仪表板
简介
Kite 是一个轻量级的现代 Kubernetes 仪表板，它提供了一个直观的界面来管理和监控 Kubernetes 集群。它提供实时指标、全面的资源管理和美丽的用户体验。
特点
- 现代用户体验
- 多主题支持 - 具有系统首选项检测功能的深色/浅色/彩色主题
- 高级搜索 - 跨所有资源的全局搜索
- 全面的资源管理
- 完整的资源覆盖 - Pod、Deployment、Services、ConfigMap、Secrets、PV、PVC 等
- 实时 YAML 编辑 - 内置 Monaco 编辑器，具有语法高亮和验证功能
- 详细的资源视图 - 包含容器、卷、事件和条件的深入信息
- 资源关系 - 可视化相关资源（例如 Deployment → Pod）之间的连接
- 资源操作 - 直接从 UI 创建、更新、删除、扩展和重新启动资源
- 自定义资源 – 完全支持 CRD（自定义资源定义）
- 监控和可观察性
- 实时指标 - 由 Prometheus 提供支持的 CPU、内存和网络使用情况图表
- 集群概述 - 全面的集群运行状况和资源统计信息
- 实时日志 - 通过筛选和搜索功能实时流式传输 Pod 日志
- Web 终端 - 通过浏览器直接在 Pod 中执行命令
- 认证
- OAuth 集成 - 支持 GitHub 和自定义 OAuth 提供程序
- 用户名/密码 - 使用环境变量进行简单身份验证
🤣 专题六 相关趣事与 Meme
1. 尝试删除 Deployment 中的一部分 Pod 是学习 Kubernetes 的重要部分
Trying to delete a pod that's part of a deployment is an important part of learning k8s.
2. Kubernetes 简单吗
Procrastination of a Kubernetes admin!
3. 处理一个复杂的生产问题
It's A Complex Production Issue !!
4. Google 搜索和 ChatGPT 消耗多少能源？
How Much Energy Do Google Search and ChatGPT Use?
Google 搜索能耗：小但显著
根据谷歌的说法，一次搜索大约需要 0.0003 kWh 的能源。具体来说，这足以为一个 60 瓦的灯泡供电 17 秒。就碳排放量而言，每次搜索会产生大约 0.2 克二氧化碳。
Google 每天处理超过 35 亿次搜索。如果每次搜索需要 0.0003 kWh，则相当于每天 1.05 GWh——大约相当于 30,000 多户美国家庭的每日用电量。
ChatGPT 的能源足迹：巨大且不断增长
每次用户输入提示时，ChatGPT 的庞大语言模型都会处理它，估计消耗 2.9 Wh 的能量 。这几乎是一次 Google 搜索所需时间的 10 倍。每天约有 2 亿次查询，总计约为每天 621.4 MWh。
ChatGPT 的年能耗预计将达到惊人的 226.8 GWh。从这个角度来看，该能量可以：
- 为 313 万辆电动汽车充满电，约占美国所有电动汽车的 95%。
- 为大约 21,602 个美国家庭提供一整年的电力。
- 运行整个芬兰或比利时国家一天。