第 9 章：让资源收敛变成真实 HTTP 行为

从占位工作负载迈向可验证服务

仅创建一个 Deployment 和 Service，最多证明 Kubernetes 接受了资源关系。若容器没有监听端口，或者 Service targetPort 配错，控制器仍可能报告 ChildrenApplied。因此完整项目需要至少一条穿过实际数据面的请求，才能证明 spec 确实映射成了用户看得见的行为。

本项目采用 Envoy v1.33.2 的固定多架构镜像 digest。配置只包含一个监听八零八零端口的 HTTP connection manager、一条匹配所有路径的路由和 direct-response。用户修改 message，就会改变响应正文。没有引入上游应用，使故障定位能够集中在控制器、代理配置和 Service 连接上。

这是实际代理进程和真实 HTTP 请求，但没有验证上游负载均衡、动态配置推送、TLS 或完整 Gateway API。本书始终把这条教学网关链路与成熟网关产品区分。它足以支撑控制器工程实验，也保留了后续加入路由对象的清晰扩展方向。

配置生成必须编码

message 可能含中文、引号或换行。手工将字符串拼进 YAML，容易让内容变成结构的一部分。代码先调用 JSON 编码器，利用 JSON 字符串也是合法 YAML 标量的性质，把结果放进 inline_string。配置生成的安全性建立在确定的编码规则上，不依赖用户恰好输入简单英文。

配置作为 Envoy 的启动参数写入容器模板。message 改变会使 Pod 模板发生变化，Deployment 负责替换 Pod。这个方案适合小配置和清晰实验，不适合把大量路由规则塞进进程参数。成熟场景可以改为受控 ConfigMap 或 xDS，但需要额外处理配置版本、引用一致性和热更新失败。

本项目选择 Recreate，旧副本先停止，新副本随后启动。它避免测试把旧新响应混合误判为未收敛，却明确允许停机。将策略改成 RollingUpdate 后，需要重新设计兼容窗口与验证方法，不能仅改一个枚举就宣称实现无损发布。

Service 测试必须经过集群网络

kubectl port-forward service/name 通常解析服务后选择一个 Pod，它适合调试，但不能独立证明 ClusterIP 转发和集群 DNS 正常。本项目创建固定 digest 的 BusyBox 客户端 Pod，在其中运行 wget，访问完整 Service DNS 名称与八零端口。

请求路径经过客户端 Pod 的解析与网络、Service 虚拟地址和 Envoy 容器监听端口。它比从 runner 直连 Pod 更接近工作负载真实访问方式。测试保存修改前响应、修改后三次响应、Envoy 实际 imageID 和明确传输路径，读者可以据此判断证据范围。

集群网络的一次成功仍不证明负载或故障切换能力。单节点 kind 的流量路径与多节点生产集群不同，CNI、kube-proxy 模式和网络策略也可能不同。实验结论应写成“该固定环境下链路成立”，而非“所有 Kubernetes 网络环境都能无损服务”。

就绪条件与发布条件分开

容器配置 HTTP readinessProbe，只有 Envoy 能处理本地请求时 Pod 才成为就绪后端。实验随后检查 Deployment 已观察其 generation，更新副本和可用副本均为一，再发请求。它避免只看到旧 Pod 可用就提前检查新配置。

用户将副本数改为零时，Reconciled 仍可为真，但 Service 不应再有可服务后端。一个成熟 Operator 可以单独报告可用数量，让用户区分意图执行正确和服务可用。不能把所有零后端都视为控制器错误，因为这可能正是用户声明的目标。

漂移修复应触及连接两端

测试会改坏 Service 端口和 selector，也会改坏 Envoy 参数与 Pod 标签。修复必须同时恢复入口与工作负载配置。只补 selector 不补 targetPort，可能让流量找到正确 Pod 后仍连错端口；只修容器参数不修标签，则可能让健康代理永远接不到流量。

练习是加入 spec.responseStatus，并限定为二百到五百九十九。先修改 schema 和配置生成，再为不同返回码增加真实 HTTP 断言。最后重新定义 readinessProbe 是否仍应访问同一路径：如果用户有意返回五百，探针可能把正常执行用户配置的实例判为不就绪，这说明业务响应与健康检查接口需要分离。

评审案例：一次成功请求能证明多少

客户端从同一Service连续得到三次新正文，说明更新后的配置在该环境中已可访问。它没有测量并发容量、长连接排空或旧Pod终止时的请求损失。Recreate本来允许中断，因此把这条记录写成“无损升级通过”会直接超出证据。

若后续研究滚动发布，需要让客户端在整个更新窗口持续发送带序号请求，记录失败、延迟和响应版本，并设计连接排空行为。即使失败率为零，也要说明请求速率、连接复用、样本时间和集群拓扑。性能与可用性结论需要自己的实验，而不是借用功能测试的绿色结果。

当前HTTP记录保留修改前后正文和实际镜像身份，足以让读者复查功能链路。将验证范围限制在数据真正覆盖的地方，不会削弱项目价值；它让后续实验知道还缺哪些观察，而不是在笼统的“全部成功”下失去方向。