容器 E08：从容器交付到平台，还增加哪些责任
用一个最小控制/数据面案例划线
选择一份固定的 probe-app digest，在专用 kind 集群中声明 Deployment/Service。控制面根据声明维持副本，节点 kubelet 经 CRI 建立 sandbox 与进程，服务入口把真实请求发往 Ready 后端；如果加一条 Operator 自定义策略或服务网格流量规则，就要分别核对其 controller 是否改变对象，以及数据面是否实际对请求作了转发/拒绝。只存在 CRD 或策略 YAML 并不说明该 controller 已运行，也不说明路由规则已经生效。多租户还要求 RBAC、namespace、网络与节点权限一起审视；Kubernetes Namespace 是 API 组织维度，不等于 Linux user namespace 的安全边界。
正例先只用标准 Deployment/Service 把请求关联到 Pod UID 和 PID，再加入一项经过版本核查的策略并观察请求变化；反例让自定义资源存在但控制器停止，仅在独立实验集群中测试“声明被接受、执行无变化”的可观测区别。实验入口与控制面清理和同一制品素材不实现任意 Operator。本云端缺 kind/服务网格/独立租户环境，端到端控制/数据面案例 NOT_RUN，本篇不扩写 Kubernetes 通论。
| 现象 | 控制面证据 | 数据面证据 |
|---|---|---|
| 副本声明成功 | Deployment/Pod UID | 真实 HTTP 响应 |
| 策略对象存在 | controller/reconcile 状态 | 流量被允许或拒绝 |
| namespace 隔开名称 | RBAC 与请求对象 | 网络/内核隔离另验 |
练习
- 预测 controller 未运行时提交一条有效 CRD 对象会否改变请求路径，在独立实验集群保存对象/事件与实际响应。
- 预测同一个 probe-app digest 部署到两个 namespace 就能否形成完整多租户隔离，按 API 权限、网络、节点资源与内核边界逐层核验。
先修：26：Pod 节点执行、33：制品可信、36：交付。相关阅读：Kubernetes 核心概念，不是本篇实验结果。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 29：Pod IP 与 Service 后端如何关联
28 的 Ready影响后端集合，24 的 ADD为 Pod 网络准备地址。Service 提供稳定的访问入口，但入口能否把某次请求转发到一个正在响应的 Pod，需要具体节点转发实现、后端集合和实际请求一同证明。不能说“Pod 有 IP”就说明 Service 一定可用。 三份状态不能互换 Pod 的 IP 是运行时网络路径产生的地址；Service 的名称在集群 DNS 中解析为入口地址或别名，转发机制由节点/插件实现；EndpointSlice 等对象描述可用后端及条件，后端的就绪状态来自 Pod/探针。DNS 返回地址并不是 socket 连通的凭据，网络策略是否真的拦截流量还依赖已启用且支持策略的 CNI 插件；有 NetworkPolicy 对象不等于执行层已经配置过滤。 正例：在固定插件的专用 kind VM 给两个 probe-app Pod 设置不同 /identity 输出，访问 Service 多次，记录 Pod UID、EndpointSlice、节点转发规则/程序状态及每次后端 PID；负例：在仅属于自建 namespace 的测试策略里拒绝一条已允许的来...
2026-10-01
容器 37：从源码到一次真实服务响应
本系列的每个对象都有不同寿命：源码树变化不等于已部署镜像改变；Pod 重建不等于数据卷重建；HTTP 请求成功也不能证明读写结果符合预期。综合实验必须让一条请求沿同一个 digest、容器 ID、Pod UID、宿主 PID、namespace/cgroup、网络路径和卷挂载回溯到源码，而不是把不同实验的截图接成故事。 只用一份 probe-app 从干净的实验目录取独立源码包并校验 SHA，固定基础镜像 digest，按13构建真实镜像，按12分发到受控 registry，再按26将 digest 部署到自建 kind 节点。通过 Service 访问 /identity 取得进程信息，通过 /state 写入一段最多 4096 字节的合成文本；从 Pod UID 到容器 ID、宿主 PID，查 namespace inode、cgroup、网络地址/路由及卷的 mountinfo，最后在同一卷上重建 Pod 后复读内容。每一步记录输入、时间、原始响应与校验值，不能从“yaml 配好了”跳到“持久化成功”。 正常案例需要请求 JSON 中的 PID 和 UID 与节点对象一一对...
2026-06-20
调度器深入：打分、抢占与拓扑约束
调度器（kube-scheduler）是 Kubernetes 控制平面里最容易被低估的组件。它做的事情看起来简单：把没有 nodeName 的 Pod 绑定到某个节点。但"选哪个节点"这个问题背后，隐藏着资源感知、亲和性约束、拓扑分散、优先级抢占等多维度的决策过程。 从 Kubernetes 1.19 起，调度器的内部逻辑通过 Scheduling Framework 对外暴露为一组扩展点。原来散落在代码各处的调度逻辑被重新组织成插件，每个插件只负责一个扩展点。这让调度行为既可预测，又可扩展。 本文的核心问题是：Kubernetes 调度器用什么框架选节点，当资源不足时如何通过抢占让高优先级 Pod 运行？ 调度框架全景图 1234567891011121314151617181920212223242526Pod pending (no nodeName) │ ▼ Scheduler（from ActiveQ by priority） ┌──────────────────────────────────────────────────...
2026-06-20
Helm 与应用打包——从 YAML 到可复用制品
在 Kubernetes 上部署一个生产级应用，往往需要几十个甚至上百个 YAML 文件：Deployment、Service、ConfigMap、Ingress、RBAC 规则、HorizontalPodAutoscaler……这些文件之间存在依赖关系，不同环境（开发、预发、生产）需要不同参数，手工管理极易出错。Helm 正是为了解决这个问题而生：把一组相关的 Kubernetes 资源打包成一个可版本化、可参数化、可共享的制品（Chart），并提供安装、升级、回滚、卸载的生命周期管理。 Helm 的本质是"带版本历史的 YAML 打包器"。它不追踪资源的真实运行状态（那是 Operator 的职责），只记录"这次 install/upgrade 渲染出了哪些 manifest，交给 Kubernetes 执行"。Release 状态存储在集群内的 Secret 对象中（key 为 helm.sh/release.v1），每次升级都新增一个版本，rollback 本质上是重新 apply 旧版本的 manifest 集合。 理解 Helm...
2026-06-20
可观测性——Metrics、Logging、Tracing 的集群实践
一个运行在 Kubernetes 上的分布式系统，出问题时最难回答的问题是"发生了什么"。单机时代，登录服务器查看进程状态和日志文件，基本能还原现场。容器化之后，Pod 随时可能被调度到不同节点，崩溃后立即重启，原始日志消失，这套方法彻底失效。可观测性（Observability）是对这个问题的系统性回答：通过在系统内部埋点、采集、存储和展示三类信号——Metrics（指标）、Logging（日志）、Tracing（链路追踪）——让工程师在不登录服务器的情况下理解系统行为。 Kubernetes 本身对可观测性有明确的架构分工。采集点（kubelet 内嵌的 cAdvisor、node-exporter DaemonSet、应用 SDK）由各组件负责暴露，聚合层（Prometheus、metrics-server）负责拉取和存储，展示层（Grafana、Jaeger UI）负责查询和可视化。这种"采集点内建、存储和展示留给生态"的设计，让 Kubernetes 本身保持简洁，同时允许不同规模的集群选择不同的存储方案。 理解可观测性的关键区分...
2026-06-20
生产集群运维——升级、备份、故障排查与容量规划
把 Kubernetes 集群跑起来是第一步，让它在生产环境中长期稳定运行才是真正的挑战。版本升级、etcd 备份恢复、节点维护、故障排查、容量规划——这些 Day-2 运维场景，每一个都有足以让集群中断服务的操作风险。Kubernetes 为这些场景提供了明确的工具和流程约定，但操作顺序和细节上的失误仍然是生产事故的主要来源。 版本升级是最高风险的操作之一。Kubernetes 的 API 在版本间存在兼容性约束（skew policy），错误的升级顺序——例如先升级 kubelet 而非先升级 control plane——会导致集群进入不一致状态，轻则调度异常，重则 API Server 无法与节点通信。etcd 备份看似简单，但备份时机（必须在升级前）、恢复流程（必须停止 API Server 再恢复）、验证方式（恢复后检查关键对象）如果有任何一步出错，都可能导致数据丢失或集群无法启动。 节点维护（drain + upgrade + uncordon）有 PodDisruptionBudget（PDB）这道安全网，但前提是 PDB 本身配置正确。容量规划需要理解"...