🆕 专题一 产品新功能/新版本
1. Kubernetes 1.35（Timbernetes）新功能介绍
像之前的版本一样，发布之后还会有陆陆续续的文章介绍新特性，下面是这些文章的汇总。
通过原地重启 Pod 实现更高效率
Kubernetes v1.35: New level of efficiency with in-place Pod restart
价值：
避免了删除和重新创建 Pod 带来的高昂开销，显著缩短了故障恢复时间（从几分钟缩短到几秒钟）。Pod 的网络身份、存储卷等关键资源得以保留，有助于实现节点级缓存等进一步优化。
使用场景：
- 机器学习/批处理作业的高效重启
- 重新运行初始化容器以获得干净状态
- 处理高频率的相似任务
通过版本化的 z-pages API 增强调试功能
Kubernetes 1.35: Enhanced Debugging with Versioned z-pages APIs
价值：
将原有的纯文本输出转换为机器可读的 JSON 格式，极大简化了自动化脚本、监控工具和调试程序的开发，减少了人工解析和错误。
使用场景：
- 自动化健康检查与监控
- 更好的调试工具
扩展容忍运算符以支持数值比较
Kubernetes v1.35: Extended Toleration Operators to Support Numeric Comparisons (Alpha)
为什么选择扩展容忍度而不是使用节点亲和性？
虽然 NodeAffinity 在表达 Pod 偏好方面功能强大，但污点和容忍度可以提供关键的运维优势：
- 策略导向 ：NodeAffinity 基于 Pod，要求每个工作负载明确选择退出风险节点。Taints 则反转了控制权——节点声明其风险级别，只有风险容忍度匹配的 Pod 才能接入该节点。这提供了一个更安全的默认设置；大多数 Pod 会避开竞价型/抢占型节点，除非它们明确选择加入。
- 驱逐语义 ：NodeAffinity 不具备驱逐功能。Taints 支持带有 tolerationSeconds 的 NoExecute 效果，允许运维人员在节点 SLA 降级或竞价实例收到终止通知时，清空并驱逐 Pod。
- 操作人体工程学 ：集中式节点端策略与其他安全因素（如磁盘压力和内存压力）一致，使集群管理更加直观。
价值：
- 使用 SLA 阈值保护竞价型实例
- 基于 GPU 分层的 AI 工作负载部署
- 成本优化的工作负载放置
- 基于性能的放置
可变持久卷节点亲和性
Kubernetes v1.35: Mutable PersistentVolume Node Affinity (alpha)
价值：
- 增强灵活性
- 优化资源调度
使用场景：
- 区域性存储迁移
- 磁盘升级与兼容性管理
向 CSI 驱动程序传递服务帐户令牌的更佳方式
Kubernetes v1.35: A Better Way to Pass Service Account Tokens to CSI Drivers
价值：
- 增强安全性
- 符合规范与最佳实践
使用 clientcmd 进行统一的 API 服务器访问
Uniform API server access using clientcmd
Job Managed By 特性正式发布
Kubernetes v1.35：Job Managed By 特性正式发布（GA）
云控制器管理器中的基于监视的路由协调
Kubernetes v1.35：云控制器管理器中的基于监视的路由协调
通过 exec 插件 allowList 限制 kubeconfig 调用的可执行文件
拓展阅读
Kubernetes 1.35 features that change Day 2 operations
2. Dragonfly v2.4.0 发布
新增特性：
- 负载感知调度算法
- Vortex 协议支持 P2P 文件传输
- Request SDK
- 指定集群 ID 实现多集群 Kubernetes 简化部署
- Manager 和 Scheduler 组件的性能和资源优化
- 增强预热功能
- 基于镜像 Blob SHA256 计算 ID 以避免重复下载
- 缓存 HTTP 307 重定向 URL
- Go 客户端已弃用，并由 Rust 客户端取代
- 附加功能增强
3. Cluster API v1.12：引入原地更新和链式升级
Cluster API v1.12: Introducing In-place Updates and Chained Upgrades
背景
Cluster API 为 Kubernetes 集群生命周期引入了声明式管理，允许用户和平台团队定义集群的期望状态，并依靠控制器不断调整以达到该状态。
类似于在 Kubernetes 中使用 StatefulSet 或 Deployment 来管理一组 Pod，在 Cluster API 中，您可以使用 KubeadmControlPlane 来管理一组控制平面机器，或者您可以使用 MachineDeployments 来管理一组工作节点。
原地更新
就像 Kubernetes 对 Deployment 中的 Pod 所做的那样，当 Machine 规范发生变化时，Cluster API 也会通过创建新 Machine 并删除旧 Machine 来执行滚动更新。
虽然不可变性的优势尚未得到讨论，但 Kubernetes 和 Cluster API 都经历了类似的历程，引入了各种变更，使用户能够尽可能地减少工作负载中断。
随着时间的推移，Cluster API 也对不可变部署进行了多项改进，包括：
- 支持仅对影响 Kubernetes 资源的变更进行原地传播 ，从而避免不必要的部署。
- 一种使用 PreferNoSchedule 标记过时节点的方法，从而通过优化 Pod 在部署期间的重新调度方式来减少 Pod 的变更。
- 支持先删除后部署策略，从而更容易在裸机/资源受限的环境中执行不可变部署。
从集群 API 维护者的角度来看，原地更新最适用于那些无需节点清空或 Pod 重启的更改；例如：更改机器的用户凭据。另一方面，如果工作负载无论如何都会中断，则只需执行滚动更新即可。
链式升级
允许用户在一次操作中升级多个 Kubernetes 次版本，这通常被称为链式升级。这样，用户可以声明目标 Kubernetes 版本，并让 Cluster API 安全地协调所需的中间步骤，而不是手动管理每个小版本升级。
链式升级无需像传统方式那样先将集群更新到 v1.33.0，再更新到 v1.34.0，最后更新到 v1.35.0，并在每个步骤检查进度，而是可以直接升级到 v1.35.0。
集群 API 负责优化和最小化工作机器的升级步骤，实际上，只要 Kubernetes 版本偏差策略允许，工作机器就会跳过升级到中间 Kubernetes 次要版本。
链式升级对于那些难以跟上 Kubernetes 小版本更新的用户来说最为有用，例如，他们可能希望每年只升级一次，然后每次升级三个版本（n-3 → n）。但请注意：现在可以轻松地一次性升级多个小版本，但这绝不是不经常修补集群的理由！
📰 专题二 新闻与访谈
1. 宣布成立检查点/恢复工作组
Announcing the Checkpoint/Restore Working Group
工作组讨论了几个高层次的方案：
- 优化交互式工作负载（例如 Jupyter notebooks 和 AI 聊天机器人）的资源利用率。
- 加速启动时间较长的应用程序，包括 Java 应用程序和 LLM 推理服务。
- 使用周期性检查点机制来实现长时间运行工作负载（例如分布式模型训练）的容错能力。
- 提供具有透明检查点/恢复功能的感知中断调度 ，允许抢占低优先级 Pod，同时保持应用程序的运行时状态。
- 促进 Pod 在节点间的迁移，以实现负载均衡和维护，而不会中断工作负载。
- 启用取证检查点功能，以调查和分析网络攻击、数据泄露和未经授权的访问等安全事件。
2. Volcano 社区发起 Kthena 子项目
重新定义大模型智能推理：Volcano社区发起Kthena子项目
Kthena 是什么
Kthena 是一个专为 Kubernetes 设计的云原生、高性能 LLM 推理路由和编排、调度系统。它旨在解决在生产环境中大规模编排、部署和服务 LLM 所面临的核心挑战，通过其独特的超节点拓扑感知的亲和性调度，KV Cache 感知的流量调度、Prefill/Decode 分离路由等高级功能，显著提升 GPU/NPU 资源利用率和吞吐，降低推理延迟，赋予企业前所未有的灵活性和控制力。作为 Volcano 的子项目，Kthena 将致力于帮助 Volcano 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。
背景
大语言模型（LLM）正在以前所未有的速度重塑各行各业，但将其高效、经济地部署在生产环境中，特别是基于 Kubernetes 的云原生平台上，仍然困难重重。开发者们普遍面临以下挑战：
- 资源利用率低：LLM 推理，尤其是其独特的 KV Cache 机制，对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用 Round-Robin 算法，无法感知这种负载特性，导致 GPU、NPU 资源闲置与请求排队并存，成本高昂。
- 延迟与吞吐量难以兼顾：LLM 推理分为“Prefill”（处理输入提示）和“Decode”（生成 Token）两个阶段，前者是计算密集型，后者是访存密集型。将两者混合调度，常常导致无法针对性优化，影响整体服务的响应速度和吞吐能力。因此 PD 分离的部署已经成为主流，但如何高效路由和调度，仍是一个难题。
- 多租户与多模型管理复杂：在企业环境中，通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由，是一个复杂的工程难题，业界甚至有些方案将 AI 网关与大模型一一对应。
- 缺乏 K8s 原生集成：许多现有的解决方案要么是外部系统，与 Kubernetes 生态割裂；要么过于复杂，无法满足生产级所需的简单易用性和灵活运维。
核心特性与优势
- 生产级推理编排（ModelServing）
- 开箱即用的模型上线（ModelBooster）
- 智能、模型感知的路由（Kthena Router）
- 成本驱动的自动扩缩容（Autoscaler）
- 主流推理引擎与异构硬件支持
- 内置流量控制与公平性调度
性能提升
基于 Kthena Router 的调度插件架构，在长系统提示词场景（如 4096 tokens）下，采用“KV Cache 感知 + 最少请求”策略相较随机基线：
- 吞吐可提升约 2.73 倍
- TTFT 降低约 73.5%
- 端到端时延降低超过 60%
3. Kubernetes Dashboard 即将归档
Kubernetes Dashboard being retired
建议使用最近添加到 sig-ui 的项目：Headlamp。
4. CNCF 宣布 Dragonfly 项目正式毕业
Dragonfly 在展示生产就绪能力后正式毕业, 为大规模容器和 AI 工作负载提供支持。
Dragonfly 是一个开源的镜像和文件分发系统。
核心亮点：
- Dragonfly 在 CNCF 毕业，展现了生产就绪能力，为大规模容器和 AI 工作负载提供支持。
- Dragonfly 获蚂蚁集团、阿里巴巴、Datadog、滴滴和快手等组织使用，支撑大规模容器镜像和 AI 模型权重分发。
- 自加入 CNCF 以来，Dragonfly 的代码贡献增长超过 3,000%，社区贡献者覆盖超过 130 家公司。
5. External Secrets Operator 将在下一版本中移除对已停止维护的提供商（例如 Alibaba、Device42 和 Passbolt）的支持
RT
6. Kubernetes 将于 2026 年 3 月停止支持 Ingress NGINX
Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees
RT
拓展阅读：
Experimenting with Gateway API using kind
应对 ingress-nginx 归档：为什么现在是迁移到 Cilium 的最佳时机
💬 专题三 讨论与分享
1. Headlamp 2025 项目亮点
Headlamp in 2025: Project Highlights
更新
加入 Kubernetes SIG UI
Headlamp 正式成为 Kubernetes SIG UI 的一部分。此举将路线图和设计讨论更紧密地与 Kubernetes 核心社区联系起来，并巩固了 Headlamp 作为该项目现代化、可扩展用户界面的地位。
Linux 基金会导师计划
通过 Linux 基金会的导师计划与几位学生合作，我们的学员已经在 Headlamp 上留下了明显的印记。
新变化
多集群视图
Headlamp 通过提供一个统一的视图来解决这个问题，让您可以并排比较不同的集群。这使得跨环境的工作负载更容易理解，并减少了查找资源所花费的时间。
项目
Kubernetes 应用通常跨越多个命名空间和资源类型，这使得故障排除就像拼拼图一样。我新增了 “项目”功能 ，为您提供以应用为中心的视图，将跨多个命名空间甚至集群的相关资源分组。这使您能够减少资源蔓延，更快地进行故障排除，并无需深入研究 YAML 文件或集群级列表即可进行协作。
导航和活动
在 Kubernetes 中，日常运维通常意味着需要在多个集群之间切换日志、终端、YAML 文件和仪表盘。重新设计了 Headlamp 的导航，将这些视图视为可以保持打开状态并随时返回的“重要活动”，而不是点击离开后立即消失的一次性视图。
搜索和地图
生产环境中出现故障时，首先要问的两个问题通常是“故障在哪里？”和“故障与什么相关？”升级了搜索功能和地图视图，让您可以更快地从高层次的故障症状找到正确的对象集。
OIDC 和身份验证
投入了大量精力，使 OIDC 设置更加清晰、更具弹性，尤其是在集群内部署方面。
应用目录和 Helm
扩展了通过 Headlamp 部署和获取应用程序的方式，特别是支持原生 Helm 仓库。
性能、可访问性和用户体验
花了大量时间关注那些您每天都能注意到但却不常出现在新闻头条的细节：启动速度、列表视图、日志查看器、辅助功能以及小型网络的用户体验细节。持续的辅助功能自查也帮助我们发现了关键问题，并使 Headlamp 对每个人来说都更加易用。
插件和扩展性
现在查找插件更简单了——无需再在 Artifact Hub 和各种 GitHub 代码库之间来回切换。浏览我们专门的插件页面 ，即可查看 Headlamp 推荐的精选插件目录以及特色插件展示。
新增以下插件：
- Headlamp AI 助手
- Minikube
- Karpenter
- KEDA
- Gatekeeper
- KAITO
2. 使用 Istio 管理高流量服务
背景
本文由 STCLab SRE 团队创作。在 STCLab，运营着高流量的 SaaS 平台，需要实时流量控制和机器人防护。应对数百万并发连接并实时识别恶意机器人，对基础设施稳定性要求极高。为此，STCLab 依赖 Istio。
虽然 Istio 功能丰富，本文重点介绍在生产环境中最关键的几个能力。无论你是正在评估 Istio，还是寻找实用案例，希望这些经验对你有所帮助。
STCLab (에스티씨랩) 是一家韩国专业的流量和资源管理软件技术公司，成立于 2020 年，专注于为 Web 服务提供稳定的流量控制、资源管理及 Bot 检测服务。其核心产品涵盖虚拟等候室（NetFUNNEL）、宏（Macro）/ Bot检测（Mbuster）、API 流量管理（API-Q）以及云自动化扩缩容（Wave Autoscale）。
为什么选择 Istio
Istio 作为控制平面，管理与容器并行部署的 Envoy 代理。每条 Istio 配置（VirtualService、DestinationRule、AuthorizationPolicy）都会转成 Envoy 原生配置。
这点很重要，原因有二：Istio 的抽象能优雅地应对大多数场景；不够用时，EnvoyFilter 可直接调用 Envoy 的底层能力。STCLab 在基础设施中两者兼用。
使用的关键功能
利用 Proxy Protocol 保留真实客户端 IP
对我们的机器人防护平台，准确的客户端 IP 是关键。没有它，机器人检测准确率大幅下降。
挑战是：流量经过 AWS NLB 时，原始客户端 IP 会丢失。我们通过 EnvoyFilter 使用 Proxy Protocol 解决了这个问题。
我们还优先使用 X-Envoy-External-Address 头部替代 X-Forwarded-For，用于安全关键操作。该头由 Envoy 设置，外部客户端无法伪造。
基于 IP 的访问控制
内部 API（如 Swagger 文档）需要保护。我们用 AuthorizationPolicy 限制只允许办公 IP 访问：
DENY 配合 notRemoteIpBlocks 实现白名单，只有明确允许的 IP 才能访问，简单有效。
基于查询参数的路由
我们的内部流量管理平台管理内存中的队列状态。每个租户的请求必须路由到同一后端实例，保持状态一致。
我们通过查询参数实现显式路由：
为何不直接用自动哈希：
这是和应用团队协作的结果。客户端通过 sticky 参数指定目标实例，带来：
- 确定性路由：客户端明确知道请求由哪个实例处理
- 问题隔离：将有问题的租户路由到特定实例，方便排查
- 平滑迁移：维护期间可迁移租户实例
- 替代方案：一致性哈希
对于不需要严格一致性的服务，我们用一致性哈希。
自动将相同 tenant_id 的请求路由至同一后端。我们对虚拟候客室核心队列服务用显式路由，辅助服务则用一致性哈希。
使用 Outlier Detection 作自动故障隔离
一个不健康的 pod 可能拖垮整个服务。我们用 Outlier Detection 自动剔除异常实例：
工作原理：
- 连续 5 次 5xx 响应后剔除 pod
- 剔除后 pod 至少隔离 30 秒
- 不会剔除超过 50% 的 pod，保障可用性
实际效果：最近一次部署时一个 pod 进入崩溃循环，Outlier Detection 在 50 秒内剔除它，流量自动切换到健康 pod，无需人工干预。
长连接的优雅关闭
我们的网关处理超过 10 分钟的长连接。部署时若强制断开，会导致测试失败。
关键规则：terminationGracePeriodSeconds 必须大于 terminationDrainDuration。
关闭流程：
- Pod 收到终止信号
- Envoy 停止接收新连接，健康检查失败
- 现有连接最多保持 terminationDrainDuration（600 秒）
- 开启 EXIT_ON_ZERO_ACTIVE_CONNECTIONS 时，连接快速关闭，Pod 提前退出
- Kubernetes 在 terminationGracePeriodSeconds（660 秒）后发送 SIGKILL
结果：
- 部署期间零连接断开
- 滚动更新时负载测试顺利完成
生产实践要点
以下是使用 Istio 扩展时的经验建议：
- 从简单开始：不要一开始就开启所有功能，只有业务需求明确时才加入复杂功能（如 mTLS、Tracing）
- 注意指标维度：Envoy 产生海量遥测数据，可能导致 Prometheus 崩溃，需精细调优采集指标
- 小心使用 EnvoyFilter：它功能强大但升级时易出问题，必须严格文档和兼容性测试
3. etcd 在有无 Kubernetes 环境下的工作原理对比
How etcd works with and without Kubernetes
etcd 如何融入 Kubernetes
从宏观层面来看，Kubernetes 集群有三类控制平面进程：
- 集中式控制器，如 scheduler, controller-manager, and third-party controllers，用于配置 pod 和其他资源。
- 节点特定的进程，其中最重要的是 Kubelet，它负责根据所需的配置处理设置 pod 和网络等细节。
- API 服务器负责协调所有控制平面进程和节点。
Kubernetes 的一个有趣的设计选择是 API 服务器本身几乎不做什么。
当用户或进程执行 API 调用时，API 服务器：
- 确定 API 调用是否已获得授权（使用 RBAC）。
- 可能通过修改 webhook 来改变 API 调用的有效负载。
- 确定有效载荷是否有效（使用内部验证和验证 webhook）。
- 持久化 API 有效负载并返回请求的信息。
- 可能会通知 API 端点的订阅者对象已更改（稍后会详细介绍）。
从架构上看，API 服务器是一个 CRUD 应用程序，它与 WordPress 等应用程序本质上并没有不同——它的大部分工作都是存储和提供数据。
与 WordPress 一样，它也需要一个数据库来存储持久化数据，而 etcd 正好可以满足这一需求。
为什么选择 etcd
- 一致性
- 可用性
- 持续稳定的表现
- 变更通知
- 其他
etcd 是一个“强一致性、分布式键值存储”。
- 强一致性：etcd 具有严格的可序列化性，这意味着事件的全局顺序是一致的。实际上，当一个客户端成功写入数据后，另一个客户端在写入之前永远不会看到过时的数据。（最终一致性的 NoSQL 数据库则不然。）
- 分布式：与传统的 SQL 数据库不同，etcd 从一开始就设计为可在多个节点上运行。etcd 的特殊设计使其能够在不牺牲数据一致性的前提下实现高可用性（尽管并非 100%）。
- 键值存储：与 SQL 数据库不同，etcd 的数据模型非常简单，它使用键和值，而不是任意的数据关系。这有助于确保其性能相对稳定，至少与传统的 SQL 数据库相比是如此。
- Etcd 允许客户端订阅特定密钥或密钥集的更改。
etcd 的工作原理
etcd 基于 Raft 共识算法运行。集群会选举一个领导者 (Leader) 节点，所有写请求都必须通过领导者，然后复制到其他跟随者 (Follower) 节点。
为了保证可用性，多数节点必须在线才能选举出领导者并保持集群正常运行。例如，3 节点集群可容忍 1 个节点故障，5 节点集群可容忍 2 个节点故障。
通常建议使用奇数个节点（如 3 或 5 个）来平衡可用性和写入性能，因为节点越多，数据复制的开销也越大。
📄 专题四报告查看与分析
1. [IDC，Broadcom 赞助] 现代 IT 基础架构中容器与虚拟机的融合：通过单一平台实现简化
🎤 显然涉及 VMware 的推广与宣传。
IDC 意见
容器和虚拟机之间的重叠远比大多数人想象的要少，并且仍将是未来发展的关键技术。IDC 目前观察到的市场趋势是，软件栈中虚拟机和容器的职责划分更加清晰。虚拟机仍然用于管理和划分服务器，而容器则针对打包和分发应用程序组件进行了优化。IDC 认为，绝大多数出于安全性和可扩展性的考虑，容器将继续在虚拟机中运行。事实上，根据 IDC 的报告，IDC 预测到 2028 年，85% 的容器将在虚拟机中运行。
情况概述
容器的崛起
各种部署类型并非总是互斥的。例如，虚拟化技术出现后，物理服务器并没有消失。相反，随着时间的推移，大多数操作系统和应用程序都被安装在虚拟机（VM）中，而不是裸机上。同样，容器也并未取代虚拟机。虽然容器宿主操作系统可以运行在裸机上，但出于安全性和可管理性的考虑，绝大多数容器仍然运行在虚拟机中。虚拟机和容器本质上是不同的技术，但它们可以协同工作。虚拟机在硬件层面运行，对物理服务器进行分区。容器在操作系统层面运行，本质上是为应用程序提供一个沙箱环境。
容器与虚拟机：共存与融合
在可预见的未来，企业出于各种原因仍需要管理虚拟机技术：
- 虚拟机中有很多现有的应用程序，它们已经投入了数年甚至数十年的时间进行开发，因此没有理由对其进行重建或重构。这些应用程序非常成熟、稳定，而且通常变更频率很低。
- 如今大多数容器都运行在虚拟机层，以受益于虚拟化环境相比裸机更高的安全性和运维效率，未来也依然有很多合理的理由这样做。即使在高度容器化的世界中，用户仍然需要维护虚拟机基础架构。
- 并非应用程序的所有部分都易于容器化。例如，许多用户更倾向于使用集中式数据库，而不是为每个应用程序创建一个数据库实例。此外，数据库是有状态的，而且通常更偏向单体架构，这更适合虚拟机架构。
- 容器虽然非常适合大规模微服务应用，但并非所有应用都适合这种模式。对于小型或早期应用而言，单体架构和有状态工作负载通常开发速度更快，管理也更便捷。此外，企业并非所有部门都已启用容器技术。因此，虚拟机 (VM) 的安装基数仍在增长，尽管增速不及容器。
虚拟机和容器的组合方式正在不断演变。显而易见的是，这两种技术在未来都将发挥重要作用，而将它们孤立地运行会造成基础设施和人力资源方面的巨大效率低下。虚拟机和容器的集成对于多地点和全球部署策略至关重要，它能够实现对传统应用和云原生应用的统一管理。将虚拟机严格地归类为用于传统应用，而将容器归类为用于现代应用可能过于简单。当然，有些容器运行着遗留代码，有些虚拟机运行着现代代码，而且许多应用已经重构到介于遗留代码和完全现代代码之间的某种状态。将虚拟机和容器统一到一个通用平台上，可以通过以下方式简化操作并降低复杂性：
- 尽可能利用通用资源，例如存储和网络。
- 实施通用的安全框架、工具和流程，以确保所有应用程序的安全态势一致。
- 在所有基础设施中推广一致的高可用性、弹性和灾难恢复策略，以确保基于虚拟机和基于容器的工作负载都能受益于强大的运维能力。
- 实现混合模式应用程序的统一管理（预计同时包含虚拟机和容器组件的混合模式应用程序数量将会增加，这使得统一管理对于无缝部署和运维变得更加重要。人工智能革命是造成这一增长的主要因素。虽然许多新的人工智能构建都是以现代化的方式在容器中完成的，但人工智能功能也被移植到许多现有应用程序中，其中许多应用程序运行在虚拟机中。因此，基于虚拟机的应用程序通常会扩展容器功能，这就需要跨两个系统实现一致的部署和可见性。
- 提供对所有基础架构资源、虚拟机和容器的统一自助式访问（这使用户能够在保持治理和控制的同时，独立利用适当的计算类型，从而提高运营效率）。平台工程和创建内部开发人员的趋势日益明显。
- 平台（IDP）也推动市场朝着统一和集中式平台的方向发展，这些平台可以满足大多数企业应用和开发需求。）
- 使平台能够实现统一的现代化云接口，从而提供一个用户友好且 API 驱动的平台，用于配置、自动化和管理所有资源、虚拟机和容器（这对于现代平台工程和平台运维方法尤为重要）。
VMware 技术概况
VMware 解决方案数十年来一直引领着软件定义计算市场。随着时间的推移，其产品不断发展，涵盖了软件定义数据中心、私有云和容器解决方案。2023 年底，博通收购了 VMware，这带来了新的投资，并整合了一个现代化的私有云平台（VMware Cloud Foundation），该平台同时支持虚拟机和容器。
VMware Cloud Foundation (VCF) 是一个综合平台，它将多种 VMware 技术（虚拟机、容器、计算、存储、网络和管理）集成到一个统一的私有云平台中。VCF 包含 VMware vSphere Kubernetes Service (VKS)，它与虚拟机一起运行和管理容器化工作负载。VMware VKS 提供经 CNCF 认证的 Kubernetes 版本，确保平台始终拥有最新的功能和安全更新。VKS 的更新可以独立于 vSphere 进行，并允许同时运行最新的三个 Kubernetes 版本。除了核心的 Kubernetes 集成之外，VCF 还包含其他几个关键的容器组件：
- VKS 集群管理（以前称为 VMware Tanzu Mission Control），是一个全球多集群管理系统，使企业能够管理所有集群。
- 无论 Kubernetes 集群位于何处，VKS 都能提供相应的管理功能。此外，VKS 集群管理还有助于为多个用户群体交付基础设施。平台工程师和应用团队可以随时访问所需的资源，而云管理员可以对单个集群或集群群应用一致的策略。
- Istio Service Mesh 是一款企业级服务网格解决方案，它通过零信任网络、策略驱动的流量控制和可观测性，在多集群和多云环境中提供可靠的控制和安全保障。Istio Service Mesh 可运行于多种应用平台、公有云和运行时环境，包括 Kubernetes 集群。
- 通过与 Canonical 的合作，Ubuntu Linux 操作系统得以集成，从而提供包含 Ubuntu Linux 和基于 VCF Kubernetes 的容器的统一企业级支持堆栈。与 VKS 集成的精简版 Ubuntu 容器是超小型容器镜像，可减少攻击面并提升性能。此外，还将提供包含预编译 vGPU 驱动程序的 GPU 优化镜像，以支持在物理隔离环境中快速部署 AI。
VCF 还包含许多其他原生云服务，例如 Contour 入口控制器、Prometheus 监控、Harbor 容器注册表、ArgoCD 和 Velero 备份。
借助 VKS，VCF 为所有工作负载（传统和现代）、虚拟机和容器提供了一个统一的平台。将 Kubernetes 集成到 VCF 中并使用 vSphere 部署 Kubernetes 具有诸多优势：
- 它为平台工程师提供对虚拟机和容器的自助式访问，同时云管理员可以维护治理和控制。
- VKS 可大规模部署和管理 Kubernetes 集群，内置 CNCF 认证的 Kubernetes，并支持 N-2 个 Kubernetes 版本，以便在规划升级时提供最大的灵活性。
- VCF 通过大规模自动化集群配置、升级和生命周期管理，消除了操作复杂性并降低了成本。
- VKS 继承并共享 vSphere 和 VCF 的强大基础架构功能，例如安全功能和高可用性。
- vSphere 的安全特性，例如 FIPS 模式、端到端数据加密和实时补丁，也扩展到了 Kubernetes 环境。此外，利用 vSphere 虚拟机和 vSphere Supervisor 的安全隔离机制，可以为 Kubernetes 工作负载提供多层隔离（六层隔离）。
- VCF 通过使用统一的 API 和通用工具，确保了操作的一致性。用户可以以一致的方式与计算资源交互，无需使用单独的工具，并降低了培训成本。
- VCF 通过消除信息孤岛、利用现有工具和技能而无需重新培训和流程变更以及统一所有基础设施的生命周期管理来降低总拥有成本。
拓展阅读
另一篇 Broadcom 赞助的文章：Where Should You Run Containers: On VMs or Bare Metal?
2. [CNCF] CNCF Annual Cloud Native Survey: The infrastructure of AI’s future
CNCF Annual Cloud Native Survey: The infrastructure of AI’s future
Kubernetes 作为人工智能平台
云原生基础设施的成熟度
云原生成熟度概况
CNCF 项目
💁♀️ 专题五 产品/方案介绍
本月无。
🤔 专题六 有意思的事与 Meme
本月无。