Appearance
02 - VPC 网络与 SLB 负载均衡
本章目标：网络是运维面试的深水区。要求讲清：VPC/vSwitch/路由表的层级模型、安全组与 NACL 差异、EIP 与 NAT 网关 SNAT（挂靠我的真实 SNAT 用例）、SLB 三兄弟选型、监听与健康检查（挂靠 apiserver 统一接入真实用例）、HTTPS 证书托管。水位：概念与选型【必背】，参数细节【理解】，组网进阶【了解】。
2.1 VPC / vSwitch / 路由表——网络底座【必背】
知识点：
- VPC（专有网络）：租户私有的逻辑网络空间，私网网段自选（常用 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 段），租户之间二层隔离。所有资源（ECS/SLB/RDS/ACK）都必须落在某个 VPC 里。
- vSwitch（交换机）：VPC 内的子网，对应一个 AZ。规划建议：按"角色/层"拆子网（如业务子网、中间件子网、数据库子网），而不是所有机器堆一个子网。
- 路由表：控制子网间与出网流向。VPC 内子网默认互通；出公网要挂 NAT 网关/EIP 路由；跨 VPC 走对等连接/云企业网 CEN；上 IDC 走 VPN 网关/专线。
- 关键红线：两个 VPC 网段不能重叠（否则无法对等互通）；选网段要预留扩展空间（默认经验：核心生产 VPC 选 /16 给够余量）。
- 移动云对标：VPC/子网/路由概念完全同构，我在移动云为 K8s 集群规划了独立 VPC + 按角色划分子网 + NAT 出口。
标准回答（面试官问"讲讲你对 VPC 的理解，子网怎么规划"）：
VPC 是租户专属的逻辑网络空间，网段自己定，租户之间二层隔离，云上所有资源都必须挂在某个 VPC 里；VPC 下面是交换机，也就是子网，每个子网对应一个可用区；路由表决定流量走向，VPC 内默认互通，出公网、连其他 VPC、连 IDC 都是配路由实现的。我的子网规划方法是按角色分层而不是按位置堆放：我移动云项目里给 K8s 底座划了独立 VPC，master、worker、中间件、监控分别落不同子网，这样安全组跟着子网角色走、审计和排障也清晰，比如看到来自中间件子网的异常访问一眼就能定位。网段选择我会留足余量选大段，因为 VPC 后续不能随意扩，而且要注意规划的网络之间网段不能重叠——重叠了就没法打通。这套模型在阿里云叫 VPC 加 vSwitch，在移动云名字几乎一样，操作差异只在控制台。
追问 1：两个 VPC 怎么互通？
三条路按场景选。同账号同地域少量 VPC 打通用对等连接，点对点、低延迟、免费流量；多账号多地域的复杂组网用云企业网 CEN，中心化路由，加一个 VPC 就挂一张网，适合有几十个 VPC 的企业级拓扑；连线下 IDC 用 VPN 网关走公网加密，或者专线走物理链路，重要生产一律专线为主 VPN 为备份。我项目里业务集中在单 VPC，没用到 VPC 间互通，但组网概念对标过：这层知识是跨云通用的，移动云、阿里云、华为云都是对等/中心网关/专线三件套，只是产品名不同。
追问 2：VPC 网段怎么选才不留坑？
我有四条经验。一是选私有地址段里"不那么常见"的大段，避免和客户既有网络、专线对端网段撞车——撞了就永远打不通；二是给核心生产 VPC 直接上 /16，子网按 /20 或 /24 切，K8s 场景还要给容器网络留独立网段并且预留 VPC 网段的倍数空间；三是画一张全司网段分配表，跨项目登记，谁也不能私占；四是验证连通性时记得把重叠检查做在方案评审，上线后改网段等于重做。我在移动云项目里是先出网络规划文档、评审通过才创建资源，这一步没省过。
2.2 安全组 vs 网络 ACL【理解】
知识点：
| 维度 | 安全组 | 网络 ACL |
|---|---|---|
| 作用层级 | 实例/网卡级（分布式） | 子网级 |
| 状态 | 有状态（响应流量自动放行） | 无状态（进出都要显式配规则） |
| 默认行为 | 默认拒绝，需显式放行 | 默认放行或拒绝均可配 |
| 规则对象 | IP/CIDR/其他安全组 | IP/CIDR |
| 典型用途 | 实例级精细管控、组间授权 | 子网级粗粒度边界控制 |
- 生产姿势：ACL 做子网边界粗防，安全组做实例精防，两层纵深。阿里云主流实践以安全组为主（ACL 支持有限，概念上对标华为云/AWS 的 Network ACL）。
标准回答（面试官问"安全组和 NACL 有什么区别"）：
核心区别三点：作用层级、状态性、默认行为。层级上安全组贴在实例网卡上，是分布式的；ACL 挂在子网上，是这个子网的边界闸门。状态性是最容易被追问的点——安全组是有状态的，入方向放行了，对应的回包自动放行，配规则只配一半；ACL 是无状态的，进和出要各配一条，规则量翻倍。默认行为上安全组默认拒绝一切，必须显式放行；ACL 通常默认放行，靠规则去挡。我的生产姿势是两层叠加：子网层用 ACL 做粗粒度边界，比如直接拒掉已知恶意网段；实例层用安全组做精细管控，重点用组间授权——按角色建组、组与组互相授权，机器增减时规则自动跟随。我在移动云的 K8s 集群就是安全组组间授权为主，master 组只放行 worker 组和 CLB 网段，这套纵深思路跨云通用。
追问：为什么安全组更适合做主策略？
三个理由。一是管理成本低：有状态特性让规则量减半，组间授权不用维护 IP 清单；二是跟实例生命周期绑定：机器迁移、重建规则跟着安全组走，不会像主机 iptables 那样重装即失；三是审计与合规友好：平台托管、变更留痕，等保检查时直接导规则清单。我在移动云把主策略全收敛在安全组层，主机 iptables 只留兜底默认拒绝，这样策略有单一事实来源，出问题时不会出现"到底哪层放行/挡住"的猜谜。
2.3 EIP 与 NAT 网关 SNAT【必背——真实用例】
知识点：
- 出公网两种模式：
- 每台 ECS 绑 EIP：IP 分散、每台暴露、费用按个算——只适合个别机器。
- NAT 网关 SNAT 统一出口：ECS 无公网 IP，出网统一走 NAT 网关绑定的 EIP——安全（入向不可达）、可控（出口 IP 唯一，白名单好维护）、省钱（一个 EIP 全网共享）。
- SNAT 条目：按 vSwitch/网段配置出口 IP；DNAT 条目：把 EIP 的端口映射到内部实例（等价端口映射）。
- 优先级铁律：实例绑了 EIP 后其出网优先走 EIP，高于 SNAT——生产出口白名单场景要注意。
- 逆向认知：SNAT 后外部无法主动连入——无公网 IP + SNAT 是安全基线配置。
- 移动云对标：我的真实用例——移动云生产环境 K8s 集群业务 ECS 全部无公网 IP，出公网（拉取外部镜像源、yum 源、对接第三方 API）统一走公网 NAT 网关 SNAT 出口，出口 IP 单一，第三方白名单只需登记一个 IP。
标准回答（面试官问"私网机器怎么安全上公网"）：
标准答案是 NAT 网关加 SNAT。做法是：所有业务 ECS 不绑公网 IP，NAT 网关上配 SNAT 条目，指定某个子网或网段的出网流量统一走 NAT 网关绑定的 EIP 出去。这个模式有三个好处：一是安全，机器没有公网 IP，外部主动连不进来，攻击面直接消失；二是可控，全网出口 IP 是唯一的，第三方接口白名单只需要登记一个 IP，出问题抓包排查也简单；三是经济，一个 EIP 服务整段网段。我在移动云生产环境就是这么配的：K8s 集群七台节点全部无公网 IP，拉镜像源、系统更新、调第三方 API 统一走 NAT 网关 SNAT，出口收敛成一个 IP。有一个生产细节我会主动提：如果某台机器后来临时绑了 EIP，它的出网会优先走 EIP 而不是 SNAT 条目，出口 IP 就变了——对有白名单的场景这是隐形故障源，所以变更流程里我会把"动 EIP"列为高风险操作。
追问 1：SNAT 和 DNAT 分别什么场景？
SNAT 是出方向，改源地址，解决"内网机器怎么出公网"，我们集群拉外部镜像源就是这个场景；DNAT 是入方向，改目的地址，把公网 EIP 的端口映射到内网某台机器，解决"外网怎么访问一台没公网 IP 的机器"。方向刚好相反。生产上我的倾向是：入方向优先用负载均衡而不是 DNAT——SLB 自带健康检查、流量分发和弹性，DNAT 是点对点映射，后端挂了它不知道。我们的 apiserver 对外接入走的就是 CLB 四层 VIP 而不是 DNAT 映射单台 master，就是这个原因。DNAT 留给没有负载均衡形态的特殊端口场景，比如临时调试某个内部服务。
追问 2：为什么不给每台机器都绑 EIP？
三个层面反对。安全上每绑一个 EIP 就多一台暴露在公网的机器，攻击面线性增长；管理上十几个出口 IP 意味着十几个要维护的白名单条目和日志源，排障时聚合出口才方便；成本上 EIP 按个计费，NAT 网关模式一个 EIP 共享全段。唯一合理场景是"这台机器确实要独立出入公网且有特殊端口需求"。我项目里的原则是：能走 SNAT 的绝不绑 EIP，能走负载均衡的绝不 DNAT，公网暴露面收敛到只剩 CLB 的 VIP 和堡垒机两个入口。
2.4 SLB 家族：CLB / ALB / NLB【必背】
知识点：阿里云 SLB 是产品家族总称，含三个子产品：
| 维度 | CLB（传统型） | ALB（应用型） | NLB（网络型） |
|---|---|---|---|
| 层级 | 四层（TCP/UDP）+ 七层（HTTP/HTTPS，功能较基础） | 专注七层（HTTP/HTTPS/QUIC） | 专注四层（TCP/UDP/TCPSSL） |
| 定位 | 老牌经典产品，存量主力 | 面向七层业务，强内容路由、HTTPS 卸载、与 ACK/函数计算集成深 | 超高性能四层，亿级并发连接 |
| 转发依据 | 四层按 IP+端口；七层按域名/URL 基础转发 | 域名、路径、Header 等高级转发规则 | IP+端口 |
| 架构 | 集群部署，四层转发走 LVS 类实现 | 七层走 Tengine 类集群 | 高性能四层转发 |
| 典型场景 | 传统四层端口转发（TCP 代理、数据库出口等） | Web 应用、微服务网关、多域名多路径 | 大并发 TCP 长连接（消息、游戏、apiserver 类） |
选型一句话：要按域名/路径/Header 转发、HTTPS 卸载 → ALB；四层超大并发/长连接 → NLB；存量四层端口类转发、简单 TCP 代理 → CLB（我项目同构场景用的就是 CLB 四层 TCP）。
移动云对标：移动云的负载均衡就叫 CLB，我在生产用的是四层 TCP 监听 + VIP——与阿里云 CLB 四层完全同构。
标准回答（面试官问"阿里云负载均衡怎么选型"）：
阿里云 SLB 是一个家族，三个子产品按层级和场景分：ALB 是七层应用型，专吃 HTTP/HTTPS 流量，强项是按域名、路径、Header 做高级转发和 HTTPS 证书卸载，适合 Web 应用和多域名网关场景，单实例能扛百万级 QPS；NLB 是四层网络型，强项是超大并发和长连接，亿级连接级别，适合消息推送、游戏这类 TCP 大流量；CLB 是传统型老产品，四层七层都支持但功能相对基础，存量部署最大，简单四层端口转发是它的舒适区。选型一句话：要内容层转发选 ALB，要四层极致性能选 NLB，传统端口类转发用 CLB 就够。我的实践锚点是移动云——我在生产里用的就是 CLB 四层 TCP 监听做 K8s apiserver 的统一接入，健康检查自动摘除故障 master，这个场景不需要七层内容解析，四层转发加健康检查就是最优解，所以同场景在阿里云我也会选 CLB 或 NLB 四层。
追问 1：四层和七层负载均衡的本质区别？
本质是转发时"看得多深"。四层工作在传输层，只看 IP 和端口，收到连接后原样转发 TCP/UDP 流，不解析应用内容，所以性能高、协议无关——数据库、MQ、apiserver 这类非 HTTP 服务只能用四层；七层工作在应用层，要先完成 HTTP 解析，才能按域名、路径、Cookie、Header 做转发决策，还能做 HTTPS 证书卸载、WAF 联动、会话保持，但每次转发都有解析开销。我的场景判断标准就一条：非 HTTP 协议或需要裸 TCP 性能选四层；需要按业务内容路由或证书统一管理选七层。我在移动云给 apiserver 配的就是四层 TCP——apiserver 是 HTTPS over TCP，负载均衡不需要理解内容，四层透传加健康检查即可，证书留给服务端自己管。
追问 2：ALB 和 Nginx 什么关系，有了 Nginx 还要 ALB 吗？
ALB 内核上和 Nginx/Tengine 是同源思路的七层转发，但 ALB 是托管服务：自动多可用区容灾、弹性扩容、证书托管、和 ACK/安全产品原生集成，这些是自建 Nginx 要自己搭的。选择逻辑：有云上运维团队、流量复杂、要高可用 SLA，托管 ALB 省心；要深度自定义模块、成本敏感、混合部署，自建 Nginx 灵活。我项目里两层都有真实实践：自建 K8s 里业务流量入口是 Ingress Nginx，而 apiserver 接入用云 CLB——对外统一接入交给云负载均衡做高可用，应用层路由交给 Ingress 做业务逻辑，各干各的擅长的事。
2.5 监听与健康检查【必背——真实用例】
知识点：
- 监听（Listener）：负载均衡上"监听什么协议端口 + 转给哪个后端"的规则。CLB 四层监听：TCP/UDP；七层监听：HTTP/HTTPS。
- 健康检查：CLB 集群内节点向各后端服务器定期发探测请求（TCP 探测：能否建连；HTTP 探测：返回 2xx/3xx 视为健康），连续失败达到阈值判定异常并自动停止向其转发，恢复后自动重新纳入。
- 关键参数【理解】：健康检查间隔（秒级）、健康/不健康阈值（连续次数）、响应超时、检查端口（可独立于业务端口）。四层 TCP 探测粒度粗但兼容性最好（任何能建连的服务都能探）。
- 会话保持【理解】：四层基于源 IP，七层基于 Cookie。
- 移动云对标——我的真实用例（全篇最核心的实战点）：移动云 CLB 四层 TCP 监听创建 VIP，后端挂三台 K8s master 的 6443（apiserver），开健康检查：探测间隔秒级、连续失败自动摘除故障 master，kube-apiserver 客户端（kubectl/组件/CI）统一连 VIP。价值：任一 master 故障，CLB 自动把连接导到健康节点，客户端零改动；故障 master 恢复后自动回归负载池。
标准回答（面试官问"讲讲你配置负载均衡健康检查的实战"）：
我拿真实项目讲：移动云上我们 K8s 集群三台 master，客户端统一接入用 CLB 四层 TCP 监听。我在 CLB 上创建 VIP 和 TCP 监听，后端挂三台 master 的 6443 端口，开启健康检查——用 TCP 探测，按秒级间隔发探测，连续几次失败判定不健康，自动把它从转发池摘除，恢复后自动加回来。这套配置解决的是控制面单点问题：三台 master 里任何一台的 apiserver 挂了，CLB 几秒内把新连接全部导给健康节点，kubectl、集群组件、CI 流水线都只连 VIP，完全无感知，不用改任何客户端配置。排查过一次健康检查异常：新加的 master 转发不通，最后定位是 CLB 网段到该节点的 6443 在安全组没放行——补上组间授权立刻恢复。这件事给我的经验是：健康检查失败时先查"探测路径上的网络授权"，再查服务本身。这套参数逻辑在阿里云 CLB 上完全同构。
追问 1：健康检查用什么协议好，TCP 还是 HTTP？
按服务的表达能力选。TCP 探测只验证"端口能建连"，兼容一切 TCP 服务，但粒度粗——服务进程假死但端口还在 LISTEN 时探不出来；HTTP 探测要求服务返回 2xx/3xx 状态码，能验证应用逻辑真的活着，适合 Web 类有健康检查端点的服务。我的配法：Web 业务配 HTTP 探测并约定 /healthz 端点；apiserver 这种协议敏感的服务用 TCP 探测——apiserver 自身有自己的健康接口，但四层监听下 CLB 只做 TCP 探测，深度健康由 K8s 自己的探针体系分层兜底。原则是：健康检查的深度要和服务的能力匹配，探得太浅防不了假死，探得太深又可能误杀。
追问 2：健康检查和 K8s 的探针是什么关系？
两层不同位置的保活机制，配合使用。云负载均衡的健康检查管"节点级"：探测某台机器上的端口是否可达，决定流量是否导给它，粒度是机器；K8s 的 liveness/readiness 探针管"Pod 级"：readiness 失败就把 Pod 从 Service 的 endpoint 里摘掉，liveness 失败直接重启容器，粒度是应用实例。我们的链路是：客户端 → CLB VIP → 节点 6443，CLB 摘的是坏节点，集群内部 Service/Endpoint 摘的是坏 Pod，流量先进到健康节点、再由集群内部机制导到健康 Pod。我在移动云排查健康检查异常时就同时核对过这两层——先看 CLB 后端状态，再进节点看 Pod 探针事件，两层状态对齐了才算真正闭环。
2.6 HTTPS 证书托管【理解】
知识点：
- 阿里云有数字证书管理服务（SSL 证书）：购买/免费申请 DV 证书 → 控制台托管 → 一键部署到 CLB/ALB/CDN/WAF，证书到期自动提醒。
- 负载均衡侧做法：七层 HTTPS 监听上托管证书，SSL 卸载在负载均衡层完成，后端走 HTTP 或重加密。
- 免费证书：个人/测试可用 DV 单域名证书（一年期，需续）；企业生产常买 OV/EV 或通配符。
- 七层转发规则支持域名+路径维度 → 多站点共用一个负载均衡实例。
- 移动云对标：CLB 七层同样支持证书托管（我项目 apiserver 是四层 TCP，证书由 apiserver 自持，未走 LB 卸载——这个细节能讲清更显真实）。
标准回答（面试官问"云上 HTTPS 证书怎么管"）：
云上证书管理的正确姿势是证书托管加统一卸载。阿里云有数字证书管理服务，证书申请下来后托管在平台，可以一键部署到负载均衡、CDN、WAF，到期前自动告警，不用手工登机器换证书。负载均衡侧配 HTTPS 监听时绑定证书，SSL 卸载在负载均衡层完成——解密开销不落在业务机器上，后端可以走内网 HTTP 提升效率，安全要求高的场景也可以到后端再加密一次。我的真实情况是：移动云项目里对外的 apiserver 接入走的是四层 TCP，证书不做 LB 卸载，由 apiserver 自己持证——因为四层是透传，证书必须留在服务端，这也是四层和七层在证书处理上的典型差异，我正好两边都实践过：业务 Web 入口如果要统一管证书，就该上七层 HTTPS 监听做卸载。阿里云这边托管机制同构，概念完全对得上。
2.7 转发算法与会话保持【理解】
知识点：
- 转发算法三档：轮询（默认，均匀分发）、加权轮询（后端性能不齐时加权）、加权最小连接数（长连接场景按当前连接数分）。
- 会话保持：四层基于源 IP（同一源 IP 固定进同一后端）；七层基于 Cookie（平台注入/重写）。
- 生产陷阱：会话保持与滚动发布冲突——老用户被粘在旧版本节点，流量切换不彻底。
- 最佳实践：应用无状态化（会话进 Redis），负载均衡不需要会话保持，调度纯轮询。
- 移动云对标：CLB 同样有调度算法与会话保持配置；我的集群会话放主备 Redis，LB 纯轮询。
标准回答（面试官问"负载均衡的调度和会话保持怎么配"）：
转发算法有三档常用：轮询是均匀分发，适合后端规格一致；加权轮询给性能强的机器更高权重，适合后端配置不齐；加权最小连接数看每台机器当前连接数，把新请求给最闲的，长连接场景分布更均匀。会话保持解决"同一用户的请求要粘在同一后端"：四层基于源 IP 哈希，七层基于 Cookie 注入。但我要主动讲一个生产陷阱：会话保持和滚动发布天然冲突——发布时一部分后端是新旧两个版本，会话保持把老用户持续粘在旧节点，流量切换不彻底、新版本验证不充分。我在移动云的解法是应用无状态化：会话数据放我们本来就有主备热备的 Redis 里，负载均衡完全不配会话保持，调度纯轮询，发布和扩缩容都干净利落。这是架构选择倒逼配置简化的典型案例，也是我在架构里坚持"状态集中存储"的原因——无状态换来每一层的自由。
追问：为什么说无状态化是最佳实践？
因为无状态让每一层都获得自由：负载均衡不用配会话保持、任意算法可调度；扩缩容随时加减机器；发布可以任意滚动重启；故障可以任意摘除节点。代价是要维护一个共享会话存储——通常就是高可用的 Redis，会话过期时间与业务对齐。状态集中之后，"任意一台机器随时可死"成为架构假设而不是祈祷，这是云上弹性能力的底层前提。我的移动云项目里 Redis 主备热备正好承担这个角色，发布期间的会话零丢失。
2.8 VPC 互通与混合云组网【理解】
知识点：
- 对等连接：点对点 VPC 互通，低延迟，两个 VPC 场景首选；N 个 VPC 全互通需要 N×(N-1)/2 条连接，规模大管理爆炸。
- 云企业网 CEN：中心化多 VPC/多地域组网，新 VPC 挂载即全网可达。
- VPN 网关：公网加密隧道连 IDC，成本低、受公网质量影响。
- 物理专线：生产混合云首选，时延稳定带宽保障；标准姿势专线主 + VPN 备。
- 选型口诀：两个 VPC 对等；几十个 VPC/多地域 CEN；连 IDC 生产专线为主。
- 移动云对标：组网概念完全同构（对等/云联网类/专线/VPN）；我的项目单 VPC 集中部署，组网知识用于方案设计。
标准回答（面试官问"VPC 之间怎么互通，连 IDC 呢"）：
VPC 之间的组网按规模选。两个 VPC 点对点打通用对等连接，配置简单、延迟低；但要打通 N 个 VPC 就是平方级的连接数，管理爆炸，这种规模用云企业网——中心化路由，新 VPC 挂上来全网可达，适合多账号多地域的企业级架构。连接线下 IDC 两条路：VPN 网关走公网加密隧道，成本低、见效快，但受公网质量影响；物理专线是生产混合云的正解，时延稳定、带宽有保障，标准做法是专线主、VPN 备的双链路冗余。我项目环境集中在单 VPC，跨 VPC 组网没有生产实操，但这个知识域是完整的——做上云方案时我专门画过组网图：迁移期用 VPN 快速打通验证链路，生产稳定后评估切专线。组网选型的本质是"规模和可靠性等级决定形态"，这套判断逻辑跨云通用，移动云、阿里云、华为云都是这四件套，只是名字不同。
追问 1：混合云组网最需要注意什么？
三条。第一，网段不重叠是红线——VPC 网段、IDC 网段、专线对端网段在规划期统一登记，一旦重叠永远打不通，只能重建；第二，路由完整——两端路由表逐条核对，漏一条就是"一半通一半不通"的经典故障，测试要覆盖所有网段组合；第三，安全边界重构——专线把内网边界延伸到了云端，访问控制要在两端同时收紧，云端资源和 IDC 资源不能因为"都是内网"就互信。我这三条全部写进了网络规划评审清单，规划期比排障期便宜一百倍。
追问 2：跨 VPC 流量收费吗，怎么规划省成本？
对等连接跨 VPC 流量一般按流量计费，同地域内网互通方向有费率；规划上首先是架构降流量——数据库和应用尽量同 VPC 部署，跨 VPC 只留必要的管理和同步流量；其次评估云企业网与多条对等的费率差，规模大时中心网关更划算。我的习惯是把"哪些流量跨 VPC"写进架构文档，流量路径可控，成本才可控。
2.9 SLB 常见故障案例三则【理解——案例复盘】
案例清单：
- 后端负载不均：症状是几台后端 CPU 差异巨大。常见原因三档：调度算法配错（应加权却纯轮询）、会话保持把老用户粘在个别节点、后端某台自身慢（CPU/线程池满）导致"分到一样多、处理不一样快"。
- 健康检查频繁抖动：后端在健康/不健康间反复横跳。原因：探测阈值过严（一次失败就摘）、后端高负载时响应超时、检查端口与服务实际监听不一致。
- 七层监听返回 504：后端处理耗时超过监听的超时配置——慢 SQL、下游依赖阻塞传导到网关。
标准回答（面试官问"负载均衡的故障你处理过吗"）：
我讲一个真实案例加两个典型形态。真实案例是我移动云 apiserver 接入的健康检查异常：新扩 master 不接流量，我按探测链路查——CLB 配置对、服务本机监听对，最后发现是 CLB 网段到新节点的安全组没放行，补组间授权立即恢复，从此扩容检查单里多了"探测路径授权"一项。另外两个典型形态我也有预案：负载不均先查三件事——调度算法是否匹配后端规格、会话保持是否造成粘滞、后端是否有某台自身变慢；健康检查抖动先调阈值和超时的匹配关系，再查后端负载，抖动本质是"探测能力扛不住后端波动"。第三个形态是七层 504，那是后端处理慢传导到网关超时，根因排查要往后端依赖链走。我的方法论是"负载均衡层的问题，一半根因在后面"——它是个透明转发层，监控上要区分"入口指标"和"后端指标"两层看，才不会被表象带偏。
追问 1：502 和 504 怎么区分根因？
502 是网关收到了无效响应——后端进程挂了、连接被重置、返回了不合法内容，偏"连接层坏了"；504 是后端长时间不响应超过网关超时——偏"处理层慢了"。我的定位顺序：502 先看后端进程存活和错误日志，504 先看后端耗时分布和依赖链——数据库、下游接口哪个环节拖住的。两种码都说明问题大概率在后端，负载均衡只是报信的。
追问 2：什么时候该扩后端而不是调参数？
看曲线形态：如果后端水位长期在 70% 以上、响应时间随水位同步上涨，这是容量问题，调参数只是推迟爆炸，正确动作是加节点或升配；如果水位不高但耗时异常，是效率问题——慢 SQL、锁竞争、下游阻塞，扩容没用。我的判据是"水位和耗时要一起看"，单看哪个都会误判。扩容后还要回看调度算法——新节点权重是否合理、健康检查是否放行，扩容引发的问题我在真实案例里吃过一回。
2.10 实操模板
模板 A：负载均衡选型决策表
| 问题 | 若是 | 若否 |
|---|---|---|
| 是否 HTTP/HTTPS 流量？ | 进入 ALB/CLB 七层判断 | 选四层：NLB 或 CLB 四层 |
| 是否需要域名/路径/Header 转发、证书统一卸载？ | ALB（七层首选） | 简单四层转发 → CLB |
| 四层是否超大并发/长连接（万级以上）？ | NLB | CLB 四层（中小规模足够） |
| 是否非 HTTP 协议（数据库/MQ/apiserver）？ | 四层（CLB/NLB TCP） | — |
| 存量环境迁移（保持架构不变）？ | CLB | 新建优先 ALB/NLB |
模板 B：apiserver 统一接入参数清单（我的真实配置口径）
| 配置项 | 我的取值/做法 | 说明 |
|---|---|---|
| 产品形态 | CLB 四层 TCP 监听 | 非 HTTP 内容转发，四层透传 |
| VIP 用途 | 所有客户端（kubectl/组件/CI）统一连此地址 | 故障切换客户端零改动 |
| 后端 | 3 × master:6443 | etcd 三副本仲裁 |
| 健康检查 | TCP 探测，秒级间隔，连续 N 次失败摘除 | 摘除/恢复全自动 |
| 安全组 | master 组放行 CLB 网段 + worker 组访问 6443 | 组间授权，不写裸 IP |
| 证书 | apiserver 自持（四层透传不卸载） | 与七层卸载场景区分 |
| 出口侧 | 集群出网走 NAT 网关 SNAT | 与入向 VIP 分离 |
模板 C：公网暴露面收敛清单（我的出口治理口径）
| 检查项 | 目标状态 |
|---|---|
| ECS 公网 IP | 无——业务网段全部无公网 IP |
| 公网出口 | 仅 NAT 网关 SNAT 一个出口 IP |
| 对外服务入口 | 仅负载均衡 VIP（CLB 四层）一个 |
| 管理入口 | 仅堡垒机，22/3389 不对公网 |
| 安全组 0.0.0.0/0 | 业务安全组清零（仅公共资源例外） |
| 白名单登记 | 出口 IP 已在第三方白名单登记归档 |
模板 D：端口不通四层排查法（顺序执行）
- 查源/目标安全组规则（协议、端口、授权对象）。
- 查主机内服务监听（ss/netstat 是否 LISTEN 于目标地址端口）与主机防火墙。
- 查中间设备：SLB 监听与健康检查状态、NAT/DNAT 映射、K8s Service/NetworkPolicy。
- 链路验证：telnet/nc 探端口、traceroute 定位断点、抓包比对 SYN 是否到达。
2.11 章末自测（一句话答案）
- 阿里云 SLB 家族三个产品？——CLB 传统型、ALB 七层应用型、NLB 四层网络型。
- 要按域名路径转发选哪个？——ALB。
- 四层和七层转发的本质区别？——四层只看 IP 端口透传，七层解析 HTTP 内容按业务规则转发。
- 安全组和 ACL 最大的状态差异？——安全组有状态（回包自动放行），ACL 无状态（进出各配）。
- SNAT 和 DNAT 方向？——SNAT 出公网改源地址，DNAT 入访问改目的地址。
- 实例绑 EIP 后出网走谁？——优先走 EIP，高于 NAT SNAT 条目。
- CLB 健康检查 TCP 探测的局限？——只验证端口可建连，防不了进程假死，深度健康要靠 HTTP 探测或应用探针。
- 我的 apiserver 接入方案一句话？——移动云 CLB 四层 TCP VIP 挂三台 master 6443，健康检查自动摘除，客户端统一连 VIP。
- 四层监听下 HTTPS 证书在哪里？——服务端自持（透传不卸载）；要卸载就上七层 HTTPS 监听。
- 出公网为什么首选 NAT SNAT 而不是每机绑 EIP？——暴露面收敛、出口 IP 唯一白名单好维护、成本更低。
- 会话保持与滚动发布的冲突？——粘滞让老用户持续打旧版本节点，无状态化后显式关闭会话保持。
- 内网 DNS 解析异常排查口诀？——nslookup 验证结果、查私有解析区绑定、查 resolv.conf 是否被改、跨实例对比隔离。
- 四层拿真实 IP 与七层的差异？——四层透传源 IP 即真实 IP，七层要在 X-Forwarded-For 头里取。
2.12 高频追问补充包（连环追问应对）
追问 A：SLB 本身能抗 DDoS 吗？
云负载均衡自带基础防护能力，配合平台 DDoS 原生防护可以抗常见流量攻击；超大攻击要上高防类产品——清洗中心扩容能力强。我的分层认知：负载均衡解决"流量怎么分"，DDoS 防护解决"流量过不过得来"，WAF 解决"进来的流量干不干净"，三者是串联的纵深不是互相替代。
追问 B：长连接应用选什么调度算法？
加权最小连接数更合适——长连接下轮询按"新建连接"分发，老连接常驻会导致先启动的节点积压；最小连接数看实时连接数分新请求，天然均衡。我的真实场景里 apiserver 的 gRPC 类长连接就是这个逻辑，虽然 CLB 四层 TCP 我没细调算法，但这个选型原理是清楚的。
追问 C：客户端真实 IP 四层和七层怎么获取？
四层 TCP 透传时源 IP 本来就是客户端真实 IP，后端直接看得到；七层因为负载均衡代替客户端向后端建连，后端看到的源是 LB 的 IP，真实 IP 在 X-Forwarded-For 头里传递。这个差异影响日志、风控、访问控制——我在排查 apiserver 访问日志时就要区分连接源和真实源。
追问 D：VIP 要变更时客户端怎么办？
理想情况客户端永远配域名不配 IP——DNS 指向 VIP，变更 VIP 只改 DNS，客户端无感。我项目里 kubeconfig 里写的就是 VIP，如果真要换 VIP 就得重发 kubeconfig，这是硬成本——所以接入层地址一旦下发就当"半永久资产"管理，变更要走公告加双跑。这提醒我：接入层规划时域名化能省未来很多事。
追问 E：CLB 和 WAF 怎么串联？
标准串联是公网流量先进 WAF 清洗七层攻击，WAF 回源到 CLB，CLB 再分发到后端——WAF 在前负责过滤，CLB 在后负责分发。证书可以放在 WAF 层统一管理，CLB 到后端走内网。我在移动云的 WAF 就是入口串联架构的一部分，串联的顺序和证书位置是方案评审过的。
追问 F：健康检查正常、后端也健康，但用户说慢，查哪里？
分段计时：用户端到 VIP 的公网段（DNS 解析、公网质量）、VIP 到后端的内网段、后端自身处理段。用拨测和后端日志的耗时分解定位：拨测慢而后端日志快，问题在公网段或 LB；都慢就是后端处理段。我的习惯是先把"慢"拆成数字——每段多少毫秒，再谈优化，凭感觉聊慢没有意义。
追问 G：公网带宽按带宽计费还是按流量计费？
两种模式各有适用：按带宽计费固定峰值、单价稳定，流量大的稳态业务划算；按流量计费用多少付多少，峰谷差大、峰值集中的业务划算，空闲时段不付费。我的判断方法看流量形态：平均流量接近峰值选按带宽，峰谷差大选按流量，拿监控里的带宽曲线算笔账就清楚。移动云项目是包带宽模式——政企预算制，成本可预期优先。
追问 H：一个负载均衡能挂多张证书吗？
七层监听支持多证书：按扩展域名/SNI 匹配，一个入口服务多个域名，各域名挂各的证书；四层透传没有证书概念，证书在服务端。我管理证书的习惯三条：托管在平台证书服务、到期告警必须配、变更留窗口灰度切。证书过期是最高频的"低级事故"——浏览器拦截、API 客户端 TLS 失败，必须机制化消灭，不能靠记忆。
追问 I：负载均衡的日志能分析什么？
七层监听的访问日志可以投递到日志服务：状态码分布、响应耗时分布、来源 IP、URL 热度。实际用途：5xx 突增的定位——按状态码和 URL 聚合秒级缩小范围；CC 攻击识别——单源 IP 频次异常；慢请求分析——耗时分布的尾部谁在贡献。我的建议是至少把 5xx 比例和 P99 耗时的告警配上，日志是负载均衡排障的第一现场，没有日志的排障全靠猜。
追问 J：多地部署怎么统一流量入口？
全局流量管理类产品：在 DNS 层按地域就近或健康状态把用户导到不同地域的入口，每个地域内部再是各自的负载均衡；主备容灾也是它——主地域健康检查失败自动切备地域，健康检查从实例级上升到了地域级。我概念对标过这套架构：它解决的是"单一入口层再之上的可用性"，容灾演练时要专门验证地域切换的实际生效时间，DNS 缓存会让切换比预期慢，这是常见认知差。
2.13 专题：负载均衡上线检查与变更纪律【理解】
知识点（上线六项检查单）：
- 监听协议端口与后端端口核对（四层/七层选型方案阶段定死）。
- 健康检查三件套（间隔/阈值/超时）与业务容忍匹配，不用默认值糊弄。
- 调度算法与会话保持明确决策（无状态则显式关闭会话保持）。
- 安全组放行 LB 网段访问后端端口（组间授权）——我的真实教训项。
- 证书托管 + 到期告警。
- 上线前摘除演练：停一台后端，实测自动摘除与恢复时延。
标准回答（面试官问"负载均衡上线你怎么把关"）：
我有一张固定检查单。上线六项逐条过：监听协议端口与后端端口核对，四层七层的选型在方案阶段就定死不临时改；健康检查的间隔、阈值、超时三件套按业务容忍配置，不用默认值糊弄；调度算法与会话保持做明确决策——我们应用无状态化后会话保持显式关闭，避免滚动发布的粘滞陷阱；安全组放行负载均衡网段访问后端端口，用组间授权——这项是我的真实教训，新节点漏放行导致健康检查异常，从此它进了检查单；证书托管加到期告警；最后一项是摘除演练——上线前手动停一台后端，实测自动摘除和恢复的时延，把高可用机制在上线前触发一次。变更纪律两条：改监听配置要公告窗口，四层长连接会中断；后端增减先授权后挂载，顺序颠倒就是我踩过的坑。这张检查单在移动云 CLB 上线时逐项执行过，迁移到阿里云 CLB/ALB 参数名不同、纪律相同。
追问：为什么上线前一定要做摘除演练？
因为高可用机制只有被触发过一次才算存在：健康检查参数配错、安全组放行不全、后端权重异常，这些问题在"一切正常"时全部隐藏，摘除演练用两分钟把它们暴露在上线前而不是故障中。演练还顺带产出两个实测数字——摘除时延和恢复时延，这两个数就是故障恢复能力的真值，写进 SLA 和应急预案才有底气。我的观点：上线前的演练是买保险，故障中的验证是赔本生意。
2.14 专题：HTTPS 证书运维全流程【理解】
知识点（证书生命周期五环）：
- 选型：DV（域名验证，个人/测试）、OV（组织验证，企业）、EV（增强验证）、通配符（*.example.com，子域多时省心）、多域名 SAN。
- 申请：平台证书服务在线申请/上传第三方证书。
- 托管：统一管理、到期告警、一键部署到 SLB/CDN/WAF。
- 部署：七层 HTTPS 监听绑定证书，SSL 卸载在入口层。
- 续期/更换：提前 30 天窗口更换，灰度验证，旧证书保留可回滚。
标准回答（面试官问"HTTPS 证书运维你怎么管"）：
我把证书管理拆成生命周期五环讲。选型按业务等级：个人测试 DV 就够，企业生产至少 OV——证书里带组织信息可信度更高；子域名多选通配符证书一张管一片，新增子域名不用重新申请；多品牌域名用 SAN 多域名证书。申请和托管环节用平台证书服务统一管：在线申请、集中存放、到期告警、一键部署到负载均衡、CDN、WAF——部署分散在各产品时统一托管尤其重要，否则"哪层哪台配了哪个证书"会变成没人说得清的糊涂账。部署环节七层监听绑定证书，SSL 卸载在入口层完成，后端走内网。续期更换是事故高发环：我的纪律是提前 30 天进窗口、更换后多域名抽样验证、旧证书保留随时回滚——证书过期和"换了新证书部分用户异常"两类事故都源于没有窗口和回滚意识。我的移动云项目里 apiserver 证书的到期台账就是这套管理的产物。证书运维是典型的"小事做成机制"，机制的目的是让低级事故在结构上不可能发生。
追问 1：通配符证书和多域名证书怎么选？
看域名结构：同一主域下子域名会持续增加——API、静态资源、各环境子域——选通配符，一张证书覆盖新增子域，运维成本最低；跨多个不同主域且数量固定——选 SAN 多域名证书，一张覆盖所有明确域名。通配符的风险提示：私钥泄漏时影响面是整个主域，所以通配符证书的私钥管理要更严——只放在入口层，不下发到业务机器。
追问 2：证书更换的操作流程和回滚怎么做？
流程四步：新证书申请验证完成先托管备用；变更窗口内在入口层绑定新证书；抽样验证——各域名浏览器和客户端各验一遍，重点验证书链完整性——链不全会导致部分客户端失败；旧证书保留 30 天再清理。回滚：入口层把绑定切回旧证书即可，分钟级。我强调一个坑：证书链不全是"换了证书反而出问题"的头号原因——中间证书没配全，部分老客户端验证失败，所以抽样验证必须覆盖不同客户端类型，不能只看浏览器。
追问 K：内网 DNS 解析异常怎么排查？
云上内网解析由平台 DNS 服务承载，排查四步：先在实例上 nslookup 目标内网域名，确认解析结果是否正确；解析错误查私有域名记录配置——私有域名解析区是否绑定到对应 VPC；解析超时查实例的 DNS 服务器配置——/etc/resolv.conf 是否被改过，这是经典人为故障；最后看是否为缓存问题，换一台实例对比解析结果隔离故障面。我的经验：私有域名解析区绑定 VPC 的范围要和业务 VPC 规划对齐，新增 VPC 忘绑解析区是"新环境一半服务不通"的高频原因。
追问 L：VPC 内流量是免费的吗？有没有容易忽略的流量费？
同 VPC/同地域内网流量一般免费，容易忽略的收费流量有三类：跨地域流量——对等连接和跨地域复制都按量计费；公网出入流量——EIP/带宽按带宽或按流量计费，NAT 网关流量另算；负载均衡的公网流量费。我的成本习惯：流量路径画进架构图，标注每条路径的计费属性——免费内网、计费跨域、计费公网，成本优化的对象就一目了然。OSS 外网流出、快照跨地域复制是我见过最常被忽略的两项。
追问 M：HTTPS 监听转发到后端还是 HTTPS 吗？
默认不是：七层 HTTPS 监听在负载均衡层卸载 TLS，转发到后端默认走 HTTP；有安全要求可配后端再加密（HTTPS 回源或双向认证）。我选型的口径：入口卸载加内网明文是主流——内网段威胁模型不同；合规或零信任要求高时后端重加密，代价是后端也要证书管理。apiserver 是四层透传不走这套，证书自持——两种模式我都实践过，差异能讲清。
追问 N：负载均衡的高可用怎么演练？
三个层次：摘除演练——停一台后端，验证健康检查摘除与恢复时延；可用区演练——模拟单 AZ 后端全挂，验证多可用区分发兜底；实例演练——负载均衡实例本身是集群化服务，主要验证监听配置变更期间的会话影响。我上线前必做摘除演练，季度做一次全链路可用性演练——实测数据（摘除时延、恢复时延、切换时长）写进 SLA 报告，替代假设值。
追问 O：公网入口的突发限流和过载保护怎么做？
分四层设防：负载均衡层——监听连接数和带宽上限，超限的新连接直接拒绝，保住已有连接；WAF/网关层——CC 防护的频次规则挡住恶意刷量；应用层——限流熔断（令牌桶类）保护核心接口；容量层——弹性扩容兜底真实流量增长。我的设计顺序是"先限恶意再保核心"：限流的目标不是拒绝用户，而是流量超过容量时有秩序地拒绝一部分，而不是全部一起倒。这套分层在移动云入口链路里我按 WAF 频次规则加应用限流落地过。
参考资料（链接采集时间 2026-10）
以下链接均于 2026 年 10 月通过搜索与抓取核实可用：
- 负载均衡 SLB 产品家族介绍（CLB/ALB/NLB 定位与选型）：https://help.aliyun.com/zh/slb/product-overview/slb-overview
- CLB 支持的监听类型及使用场景（四层/七层监听说明）：https://help.aliyun.com/zh/slb/classic-load-balancer/user-guide/listener-overview
- CLB 健康检查原理概述：https://help.aliyun.com/zh/slb/classic-load-balancer/user-guide/health-check-overview
- 配置和管理 CLB 健康检查：https://help.aliyun.com/zh/slb/classic-load-balancer/user-guide/configure-and-manage-health-checks
- CLB 健康检查 FAQ：https://help.aliyun.com/zh/slb/classic-load-balancer/support/faq-about-health-checks
- CLB 四层和七层监听的功能特性对比：https://help.aliyun.com/zh/slb/classic-load-balancer/product-overview/functional-characteristics
- NAT 网关用户指南（公网 NAT 网关 SNAT 实现公网访问）：https://help.aliyun.com/zh/nat-gateway/user-guide
- VPC NAT 网关介绍：https://help.aliyun.com/zh/nat-gateway/user-guide/what-is-a-vpc-nat-gateway
- NAT 网关常见问题（EIP 与 SNAT 优先级等）：https://help.aliyun.com/zh/nat-gateway/support
- 安全组应用指导和案例（ECS）：https://help.aliyun.com/zh/ecs/user-guide/security-groups-for-different-use-cases
- NAT 网关产品页：https://www.aliyun.com/product/nat