EP233：为忙碌工程师解读 Kubernetes
内容提要
本文介绍Kubernetes：在deployment.yaml中声明期望状态，经API服务器校验后存入etcd；控制器管理器确保实际状态与期望一致，调度器按资源与约束将Pod分配到工作节点，kubelet与容器运行时负责运行，Service提供稳定入口，Ingress对外暴露。另简述单/多智能体架构、测试金字塔、LLM深度研究流程及AI智能体生产防护措施。
延伸解读
声明式管理的核心：期望状态与持续调和
Kubernetes 的核心设计是声明式管理：你在 deployment.yaml 中描述期望状态，API 服务器校验后存入 etcd。控制器管理器持续对比期望状态与实际状态，并驱动集群向期望状态收敛。例如，当 Deployment 要求 4 个副本时，控制器会确保始终有 4 个 Pod 在运行。这种机制让运维从“手动操作”转向“定义目标”，系统自动处理故障恢复和扩缩容。
调度与运行：从 Pod 分配到容器启动
调度器根据可用 CPU、内存资源、放置规则和其他约束，决定每个 Pod 运行在哪个工作节点上。工作节点上的 kubelet 跟踪 Pod 分配并确保其正常运行，容器运行时负责下载镜像并启动容器。这一分工将“决策在哪里运行”与“实际运行”解耦，使集群能够灵活利用资源，同时保持各节点的自治性。
服务暴露：Service 与 Ingress 的分层入口
Pod 运行后，Kubernetes Service 为它们提供稳定的访问端点，屏蔽 Pod IP 变化带来的影响。Ingress 或 Gateway 再将 Service 暴露给外部用户。这种分层设计让内部服务发现与外部流量入口各司其职，便于分别管理访问策略和路由规则，是应用对外可用性的关键环节。
智能体架构与测试策略的简要对照
文章还对比了单智能体与多智能体架构：单智能体适合线性、可独立完成的任务，构建简单且成本低；多智能体通过编排器拆分任务并行处理，能力更强但协调成本更高。建议从单智能体开始，仅在上下文或可靠性成为瓶颈时转向多智能体。测试金字塔则强调单元测试为基础，集成测试验证交互，端到端测试模拟真实流程，成本随层级上升而增加。
Q&A
Kubernetes 是如何确保应用的实际状态与期望状态一致的？
在 deployment.yaml 中声明期望状态后，API 服务器会校验并将该状态存入 etcd。控制器管理器运行控制器，持续对比期望状态与实际状态，并采取行动（如创建或维护指定数量的 Pod）使两者匹配。
Kubernetes 中的调度器负责什么？
调度器决定每个 Pod 在哪个工作节点上运行。它会根据可用 CPU 和内存资源、放置规则以及其他约束条件，将 Pod 分配到合适的工作节点。
在 Kubernetes 中，Service 和 Ingress 分别起什么作用？
Service 为 Pod 提供稳定的访问端点；Ingress（或 Gateway）则将该 Service 暴露给外部用户。
什么时候应该使用单智能体而不是多智能体架构？
当任务是一个清晰、线性的序列，一个智能体就能掌握整个问题，并且希望构建简单、易于调试时，适合使用单智能体。单智能体成本更低、更易构建，但在复杂任务上会遇到瓶颈。
测试金字塔包含哪三个层次？各自的特点是什么？
测试金字塔包含三层：单元测试（快速、隔离、低成本，测试单个函数或组件）、集成测试（验证组件间交互，较慢且需要更多设置）、端到端测试（模拟真实用户流程，编写和维护成本高、执行慢）。越往上成本越高。
LLM 进行深度研究时，系统是如何协调多个 AI 智能体工作的？
系统首先理解问题并制定计划，将大问题拆解为小任务；然后每个子智能体负责一个具体任务（如搜索网页、浏览页面或运行代码分析数据）；最后由合成智能体汇总结果、识别主题、去除冗余，并由引用智能体确保每个声明都链接到来源，生成格式良好的最终输出。
生产环境中常见的 AI 智能体防护措施有哪些？
常见防护措施包括：输入筛查（检查提示注入、敏感数据和越界话题，不安全输入返回回退消息）、上下文验证（模型仅基于已验证的上下文推理）、输出验证（检查回答的 groundedness、格式和安全性，失败时最多重试两次后回退）、操作控制（实施限制、记录每次调用，并将低置信度或高风险操作转交人工处理）。
