📚 课程目录第1章 Ingress高可用与性能优化工程导论

1. Ingress高可用与性能优化工程导论

在 Kubernetes 集群中，Ingress 是南北向流量的统一入口。它把集群外部的 HTTP/HTTPS 请求，按照域名与路径规则转发到集群内部不同的 Service，再由 Service 落到具体的 Pod。看似只是一层“反向代理”，但当业务规模扩大、流量峰值升高、发布频率加快之后，Ingress 往往成为整个系统最先暴露瓶颈、也最难排查的组件之一。本课程的目标，就是围绕 Ingress 的高可用与性能优化，建立一套从原理到落地、从指标到排障的完整工程能力。

课程要解决的核心问题

Ingress 的问题通常不会以“Ingress 坏了”这种形式出现，而是表现为一系列具体现象：某个域名间歇性 502、大促期间 P99 延迟从 80ms 飙升到 2s、证书轮换后部分客户端握手失败、滚动发布时出现少量 503、单节点故障导致入口整体不可用。这些问题背后，分别对应着不同的技术层面：

可用性层面：Ingress Controller 副本数、节点分布、反亲和策略、健康检查、故障转移与优雅退出。
性能层面：连接复用、keepalive、缓冲区、超时参数、worker 进程与连接数、TLS 握手开销。
容量层面：QPS、并发连接、带宽、证书数量、路由规则规模对内存与 reload 时间的影响。
可观测层面：访问日志、指标、链路追踪、错误码分布与延迟分位数。

这四层并不是孤立的。例如，一次配置热更新会触发 Controller 重新加载，如果路由规则过多，reload 时间变长，期间新连接可能被延迟处理，表现为短时延迟抖动；如果此时又叠加了证书更新，TLS 握手成本上升，问题会被进一步放大。因此，本课程强调“系统视角”，而不是孤立地调某一个参数。

技术全景：Ingress 数据面的关键链路

要优化，先要看清请求在 Ingress 内部经历了什么。下图给出了一条典型 HTTPS 请求从客户端到后端 Pod 的关键链路，以及每一段上最值得关注的性能与可用性因素。

从图中可以看到，一次请求要穿过接入、Controller、转发、后端四段。高可用关注的是“任何一段失效时，整体是否还能服务”；性能优化关注的是“每一段的延迟与吞吐是否被充分利用”。两者常常需要一起考虑，例如增加 Controller 副本可以提升可用性，但如果共享同一个外部负载均衡且健康检查配置不当，反而可能把流量打到尚未就绪的副本上。

学习路径与工程方法

本课程不会一上来就堆参数，而是按照“先建立模型，再动手优化，最后形成闭环”的顺序推进。整体学习路径可以概括为四个阶段：

建立数据面模型：理解 Ingress Controller 的进程模型、配置加载机制、连接处理方式，知道一次请求在内部经过哪些阶段。
掌握可用性设计：副本与节点分布、反亲和、PodDisruptionBudget、就绪探针、优雅退出、多入口与故障转移。
掌握性能调优：keepalive、缓冲区、超时、worker 连接数、TLS 优化、路由规模控制与 reload 优化。
建立观测与排障能力：从指标、日志、追踪中定位问题，形成“现象 → 假设 → 验证 → 修复 → 回归”的闭环。

为了让学习更贴近真实工程，课程中会反复使用一组示例参数。例如，假设一个中等规模集群：Ingress Controller 部署 3 个副本，分布在 3 个可用区；入口 QPS 峰值约 8000，平均响应体 40KB，P95 延迟目标 200ms；后端 Service 有 12 个 Pod。这些数字仅作为教学示例，用于说明参数之间的关系，并不代表任何真实环境的实测结果。读者可以替换为自己环境的实际值，再套用同样的分析方法。

学习本课程时，建议准备一个可操作的测试集群，并至少部署一个 Ingress Controller（如 NGINX Ingress Controller 或 Traefik）。每学完一个优化点，就在测试集群上做一次对照实验：记录调整前的 QPS、P95、P99、5xx 比例，调整后再记录一次。只有形成“改前—改后”的对比，才能真正理解参数的作用边界。

核心挑战与常见误区

在真实工程中，Ingress 的高可用与性能问题往往不是单一原因造成的。常见的挑战包括：

配置热更新带来的抖动：路由或证书变更触发 reload，期间连接处理可能短暂变慢，表现为延迟毛刺。
副本“看起来有，实际不可用”：副本数足够，但都调度到同一节点，或就绪探针配置过松，故障时无法真正接管流量。
参数互相冲突：为了降低延迟调小超时，却导致后端稍慢时大量 504；为了提升吞吐调大缓冲区，却增加了内存压力。
观测缺失：只有 CPU 和内存监控，没有按域名、路径、状态码维度的指标，问题出现后无法快速缩小范围。

对应的常见误区是：把 Ingress 当成“配置完就不用管”的静态组件；只关注单点参数，不关注整条链路；把压测结果直接等同于生产表现。本课程会通过具体案例和对照实验，帮助读者避开这些误区。

本课程将交付的能力

完成本课程后，读者应当能够独立完成以下工作：为一个生产级 Ingress 设计高可用部署方案；根据业务流量特征调整关键性能参数；建立覆盖入口链路的监控与告警；在出现 502、504、延迟抖动等问题时，按结构化路径定位原因并验证修复效果。换句话说，本课程的目标不是记住一堆参数，而是形成一套可复用的工程方法：先看清链路，再定位瓶颈，然后小步调整、持续观测、回归验证。

接下来的章节会从 Ingress 的基本工作原理和数据面模型开始，逐步展开到可用性设计、性能调优、观测体系与典型故障排查。每一节都会尽量给出可操作的示例、可观察的指标和可判断的结果，帮助读者把知识转化为实际工程能力。