在 Kubernetes 上运行 AI 推理工作负载具有一些独特的特点和挑战，Gateway API Inference Extension 项目旨在解决其中的一些问题。我最近在 kgateway 项目[1] 中写过关于这些新能力的文章，而本文将深入讲解其工作原理。大多数人将 Kubernetes 中的请求路由理解为基于 Gateway API、Ingress 或 Service Mesh（统称为 L7 路由器）的机制。这些实现的原理类似：你定义一些根据请求属性（如 header、path 等）进行匹配的路由规则，L7 路由器会基于这些规则决定请求应发送到哪个后端，并使用某种负载均衡算法（如 轮询、最少请求、环哈希、区域感知、优先级[2] 等）。
在 Kubernetes 生态中，资源编排一直是平台工程领域面临的核心挑战。2024 年底，一个名为Kro[1]（Kubernetes Resource Orchestrator） 的项目横空出世，由 AWS、Google Cloud 和 Microsoft 三大云厂商罕见地联手推出，并以 Apache 2.0 协议开源，立足于解决 Kubernetes 用户对简化 CRD 编排的长期诉求。
在离线混部可以提高整体的资源利用率，不过离线Spark任务部署到混部容器集群需要做一定的改造，本文将从在离线混部中的离线任务的角度，讲述离线任务是如何进行容器化、平台上的离线任务如何平滑地提交到混部集群、离线任务在混部集群中如何调度的完整实现以及过程中的问题解决。
Kubernetes Scheduler 是控制面中的核心组件之一，负责决定每个 Pod 运行在哪个节点上。换句话说，所有使用 Kubernetes 的用户，其 Pod 的命运都掌握在调度器手中。 kube-scheduler-simulator[1] 是一个 Kubernetes 调度器的“模拟器”，最初是我（Kensei Nakada）在 Google Summer of Code 2021[2] 中启动的项目，后续得到了众多贡献者的支持。这个工具的目标是帮助用户深入观察调度器的行为和决策逻辑。 无论你是使用诸如 Pod 亲和性[3] 等调度约束的普通用户，还是开发自定义调度插件的调度器专家，这款模拟器都将成为你理解和测试调度策略的重要助手。
K8s 是容器编排领域的事实标准，作为一名后端开发，如果对 K8s 的技术原理不够了解，未来无论是在日常工作还是求职面试中，可能都会面临一些挑战问题。 本文是腾讯云可观测平台工程师柯开所总结的 K8s 核心技术原理，帮助你轻松拿捏！长文干货预警，建议先点赞转发收藏一键三连再来仔细阅读，对照问题场景印证效果更佳！
Argo Workflows是一个开源的容器原生工作流引擎，允许用户在Kubernetes集群上定义并执行复杂的业务流程。支持对相关流程进行个性化编排，包括执行顺序、相互之间的依赖等等。 Argo Workflows 是以 Kubernetes 自定义资源定义（Custom Resource Definitions，简称 CRD）的形式来实现其功能。CRD 是 Kubernetes 提供的一种机制，它允许用户在不修改 Kubernetes 核心代码的情况下，扩展 API Server，定义新的资源类型。
多集群部署微服务带来了可扩展性和容灾性等优势，但也引入了全局层面的脆弱性——中心控制平面的任何问题都会级联影响所有被管理集群，造成灾难性后果。其中最严重的场景之一是由于Pod删除导致的服务容量丢失。这在Kubernetes复杂的事件链中可能由多种原因引发，例如： 意外删除所有Deployment的owner资源类型的CRD 集群拓扑配置错误，导致用其他集群的spec覆盖当前集群 多集群滚动更新实现缺陷，同时在所有集群触发更新 联邦主集群的etcd磁盘损坏，导致Deployment对象从索引中移除 多个集群同时独立进行Pod驱逐操作，并发度不受控 虽然这些问题均可单独解决，但成因多样且在持续变化的基础设施中难以穷举。更便捷的方式是采用端到端处理：只要全局要求未满足就阻止Pod删除。因此我们开发了Podseidon项目——当跨集群的最小可用性要求不满足时，拒绝删除请求的准入webhook。
本文讲述作者如何解决客户集群中出现的OOM（Out of Memory）和Pod驱逐问题。文章不仅详细记录了问题的发生背景、现象特征，还深入探讨了排查过程中的关键步骤和技术细节。
