网络、Ingress 与服务治理¶

这部分考什么¶

网络类问题通常是高级运维、云原生平台和 SRE 面试里最容易拉开差距的部分。

原因很简单：网络不是一个孤立知识点，它同时连接了：

Linux 网络栈
TCP/IP 基础
DNS、路由、NAT、负载均衡
Kubernetes Pod / Service / Ingress 网络
网关、证书、限流、灰度、服务治理
线上 502、504、连接超时、DNS 抖动、跨集群访问异常等真实故障

如果只会背概念，面试官稍微追问“请求到底怎么走”“这个故障你怎么定位”，就很容易露怯。

这篇文章的目标是把网络、Ingress 与服务治理串成一条完整主线：

从客户端发起请求开始，理解它如何经过 DNS、负载均衡、Ingress、Service、kube-proxy、CNI，最终到达 Pod；再理解这条链路上如何做证书、灰度、限流、熔断、超时、重试和故障排查。

一、先建立一条完整请求链路¶

面试里最经典的问题是：

浏览器访问一个域名，最终请求是怎么打到 Kubernetes Pod 的？

你可以先用一条链路回答：

浏览器
  -> DNS 解析
  -> 公网/内网负载均衡
  -> Ingress Controller
  -> Kubernetes Service
  -> kube-proxy 转发规则
  -> Pod IP
  -> 容器进程监听端口

如果再展开一点：

用户访问 https://api.example.com
客户端先做 DNS 解析，拿到公网 LB、内网 LB 或网关地址
请求进入四层或七层负载均衡
LB 把流量转发到 Ingress Controller 所在节点或 Pod
Ingress Controller 根据域名、路径、Header 等规则匹配后端 Service
Service 通过 EndpointSlice 找到后端 Pod
节点上的 kube-proxy 规则把 Service 虚拟地址转发到某个 Pod IP
CNI 网络负责让数据包在节点之间正确到达目标 Pod
容器内应用进程处理请求并返回响应

这条链路很重要，因为后面所有网络问题都可以沿着它拆：

域名解析失败：先看 DNS
能解析但连不上：看 LB、安全组、路由、端口
Ingress 返回 404：看 Host、Path、Ingress 规则
返回 502：看 Ingress 到后端 Service/Pod 是否可用
返回 504：看后端响应慢、超时配置、连接池、上游依赖
集群内访问异常：看 Service、Endpoint、kube-proxy、CNI

高级运维面试里，最重要的不是你记住多少组件名，而是你能不能把“现象”放回“链路”里定位。

二、基础网络必须掌握什么¶

1. TCP 和 UDP 的区别¶

TCP 是面向连接、可靠传输的协议。它通过三次握手建立连接，通过序列号、确认应答、重传、流量控制、拥塞控制来保证数据可靠、有序到达。

UDP 是无连接协议，不保证可靠性，也不保证顺序。它的优势是开销小、延迟低、实现简单。

常见场景可以这样记：

TCP：HTTP/HTTPS、MySQL、Redis、SSH、消息队列客户端连接
UDP：DNS 查询、实时音视频、部分日志采集、游戏实时通信

面试表达：

TCP 适合对可靠性和顺序有要求的场景，UDP 适合对延迟敏感、能接受丢包或由应用层自己处理可靠性的场景。生产排障时，如果是 TCP 服务，我会重点看连接建立、连接数、重传、超时和应用响应；如果是 UDP，我会重点看丢包、包大小、网络路径和应用层容错。

2. TCP 三次握手与四次挥手¶

三次握手的核心目的不是“交换三次包”本身，而是确认双方收发能力正常，并协商初始序列号。

简化过程：

Client -> Server: SYN
Server -> Client: SYN + ACK
Client -> Server: ACK

四次挥手的核心是 TCP 是全双工连接，双方的发送方向需要分别关闭。

简化过程：

Client -> Server: FIN
Server -> Client: ACK
Server -> Client: FIN
Client -> Server: ACK

生产排障里，经常会遇到这些状态：

SYN_SENT：客户端发起连接后没有收到响应，常见于网络不通、防火墙拦截、服务端端口未开放
SYN_RECV：服务端收到 SYN 但连接还没完成，可能和半连接队列、攻击或网络异常有关
ESTABLISHED：连接已建立
TIME_WAIT：主动关闭连接的一方保留状态，防止旧报文影响新连接
CLOSE_WAIT：对端已经关闭，本端应用还没关闭 socket，常见于应用连接泄漏

面试里如果被问 TIME_WAIT 很多怎么办，不要一上来就说改内核参数。更好的回答是：

我会先判断它是否真的造成问题。TIME_WAIT 是 TCP 正常机制，数量多不一定是故障。如果端口耗尽或连接失败，再看是否存在短连接过多、连接池配置不合理、客户端频繁主动关闭连接等问题。内核参数可以作为辅助手段，但优先从连接复用、连接池、Keepalive 和业务访问模式上优化。

3. 长连接、短连接与 Keepalive¶

短连接是每次请求都新建连接，请求结束后关闭。实现简单，但连接建立成本高。

长连接是多个请求复用同一个连接，适合高频访问场景，可以减少握手开销。

Keepalive 这个词有两层含义：

HTTP Keep-Alive：复用 TCP 连接发送多个 HTTP 请求
TCP Keepalive：内核探测空闲连接是否仍然有效

线上常见问题：

长连接空闲太久，被 LB、防火墙或 NAT 设备回收，应用侧却以为连接还活着
客户端连接池太小，导致请求排队
服务端连接数过多，文件描述符耗尽
短连接太多，导致握手开销、TIME_WAIT、端口耗尽

实战建议：

服务间高频调用优先使用连接池和长连接
连接池大小要结合 QPS、延迟、实例数评估
客户端超时必须设置，不能无限等待
LB、Ingress、应用框架的 idle timeout 要匹配

4. 四层代理与七层代理¶

四层代理工作在传输层，主要根据 IP 和端口转发，例如 TCP/UDP 负载均衡。

七层代理工作在应用层，可以理解 HTTP、HTTPS、Header、Path、Cookie 等信息。

对比一下：

类型	依据	常见能力	典型组件
四层代理	IP、端口、TCP/UDP 连接	连接转发、端口负载均衡	LVS、云厂商 NLB、四层 SLB
七层代理	HTTP 协议内容	域名路由、路径路由、重写、鉴权、限流、灰度	Nginx、Envoy、Ingress Controller、API Gateway

面试表达：

四层代理更关注连接和端口，性能通常更直接；七层代理能理解应用协议，适合做域名路由、路径转发、证书卸载、Header 改写、灰度和限流。Kubernetes 里 Service 更偏四层抽象，Ingress 更偏七层入口抽象。

5. DNS 解析¶

DNS 的作用是把域名解析成 IP。

常见解析链路：

应用/浏览器
  -> 本地缓存
  -> 操作系统 resolver
  -> 本地 DNS / CoreDNS
  -> 上级 DNS
  -> 权威 DNS

在 Kubernetes 里，集群内 DNS 通常由 CoreDNS 提供。

例如访问：

mysql.default.svc.cluster.local

含义是：

mysql：Service 名称
default：Namespace
svc：Service 域
cluster.local：集群域后缀

常见 DNS 故障：

CoreDNS Pod 不可用
CoreDNS 资源不足导致解析慢
上游 DNS 不稳定
搜索域配置导致解析放大
应用没有正确处理 DNS 缓存和连接复用

排查命令：

kubectl -n kube-system get pod -l k8s-app=kube-dns
kubectl -n kube-system logs deploy/coredns
kubectl exec -it <pod> -- nslookup kubernetes.default
kubectl exec -it <pod> -- cat /etc/resolv.conf

三、Kubernetes 网络模型¶

1. Kubernetes 网络的核心假设¶

Kubernetes 网络模型有几个关键假设：

每个 Pod 都有独立 IP
Pod 之间可以直接通过 Pod IP 通信
Pod 内所有容器共享同一个网络命名空间
Service 为一组动态 Pod 提供稳定访问入口
网络实现由 CNI 插件负责

这意味着在 Kubernetes 里，不应该把 Pod 当成“宿主机上的一个随机端口进程”，而应该把它理解成有独立 IP 的最小运行单元。

2. Pod 网络¶

Pod 内的容器共享网络命名空间，所以同一个 Pod 内的容器：

共享 IP
共享端口空间
可以通过 localhost 互相访问

不同 Pod 之间通常通过 Pod IP 通信。至于 Pod IP 如何跨节点可达，取决于 CNI 实现。

常见 CNI 模式包括：

Overlay 网络：例如 VXLAN，把 Pod 流量封装后跨节点传输
路由模式：通过路由规则让 Pod 网段互通
云厂商 VPC CNI：Pod 直接使用 VPC 内地址或弹性网卡能力

不同模式的取舍：

Overlay 对底层网络要求较低，但有封装开销
路由模式性能更直接，但对网络路由规划有要求
VPC CNI 云上集成好，但受 IP、弹性网卡、实例规格限制

面试里可以这样答：

CNI 的核心职责是给 Pod 分配 IP、创建网络设备、配置路由和网络连通性。Kubernetes 定义网络模型，但具体怎么让 Pod 跨节点互通，是由 CNI 插件实现的。

3. Service 解决什么问题¶

Pod 是不稳定的：

可能被重建
可能被调度到其他节点
IP 会变化
副本数量会扩缩

Service 的价值就是给一组 Pod 提供稳定入口。

Service 通过 Label Selector 选择后端 Pod，然后 Kubernetes 会生成 EndpointSlice，记录当前可用的后端地址。

简化关系：

Service
  -> selector
  -> EndpointSlice
  -> Pod IP:Port

Service 类型：

ClusterIP：默认类型，只能在集群内访问
NodePort：在每个节点打开一个端口，对外暴露服务
LoadBalancer：依赖云厂商负载均衡，把服务暴露到集群外
ExternalName：把 Service 映射成一个外部 DNS 名称

生产中最常见组合：

外部访问
  -> LoadBalancer
  -> Ingress Controller
  -> ClusterIP Service
  -> Pod

4. kube-proxy 的作用¶

kube-proxy 负责把 Service 抽象落到节点转发规则上。

它会监听 Service 和 EndpointSlice 的变化，并在节点上维护转发规则。

常见模式：

iptables：通过 iptables 规则做转发
ipvs：通过 Linux IPVS 做负载均衡

简单理解：

访问 Service ClusterIP
  -> 命中节点上的转发规则
  -> 选择一个后端 Pod IP
  -> 转发到目标 Pod

iptables 和 ipvs 的差异：

iptables 兼容性好，规则基于链式匹配
ipvs 更适合大规模 Service 和高并发转发，负载均衡算法也更丰富

如果 Service 访问异常，排查顺序通常是：

Service 是否存在，端口是否正确
selector 是否匹配到 Pod
EndpointSlice 是否有后端地址
Pod readiness 是否通过
kube-proxy 是否正常
CNI 跨节点网络是否正常

常用命令：

kubectl get svc
kubectl describe svc <service-name>
kubectl get endpointslice
kubectl get pod -o wide
kubectl exec -it <pod> -- curl -v http://<service-name>:<port>

四、Ingress 与网关¶

1. Ingress 解决什么问题¶

Service 可以暴露服务，但它主要是四层抽象。真实生产环境里，我们往往需要：

按域名转发
按路径转发
HTTPS 证书管理
HTTP 到 HTTPS 跳转
路径重写
Header 处理
灰度发布
限流
鉴权

这些是 Ingress 更擅长的事情。

Ingress 本身只是一种 Kubernetes API 对象，真正处理流量的是 Ingress Controller。

常见 Ingress Controller：

Nginx Ingress Controller
Traefik
HAProxy Ingress
Envoy Gateway
云厂商 ALB Ingress Controller

关系可以这样理解：

Ingress 资源：声明路由规则
Ingress Controller：读取规则并配置真实代理
真实代理：Nginx / Envoy / ALB 等，负责处理流量

2. Ingress 基本转发逻辑¶

典型 Ingress 规则：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /user
            pathType: Prefix
            backend:
              service:
                name: user-service
                port:
                  number: 8080

这表示：

请求 Host 是 api.example.com
路径前缀是 /user
转发到 user-service:8080

如果面试官问 Ingress 和 Service 的区别，可以这样答：

Service 解决的是集群内一组 Pod 的稳定访问和四层转发问题，Ingress 解决的是集群外七层 HTTP/HTTPS 入口治理问题。Ingress 通常不会直接转发到 Pod，而是先匹配规则，再转发到 Service，由 Service 再关联后端 Pod。

3. HTTPS、证书与 TLS 终止¶

HTTPS 请求进入集群时，TLS 可以在不同位置终止：

云厂商 LB 终止 TLS
Ingress Controller 终止 TLS
后端应用自己终止 TLS
端到端 TLS，入口只做透传

最常见的是在 Ingress Controller 或云 LB 处做 TLS 终止。

优点：

证书集中管理
后端服务可以使用 HTTP 简化接入
便于做七层路由、Header 处理、限流和审计

需要注意：

入口到后端如果是 HTTP，集群内链路不是加密的
如果合规要求端到端加密，需要后端也支持 TLS
证书过期、证书链不完整、SNI 配置错误都会导致访问失败

Kubernetes 中证书通常放在 Secret：

kubectl create secret tls api-tls \
  --cert=api.crt \
  --key=api.key

Ingress 中引用：

spec:
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls

4. Nginx Ingress 常见能力¶

Nginx Ingress 在生产里常用的能力包括：

路径转发
路径重写
HTTPS 终止
请求体大小限制
连接超时和响应超时
Header 透传
IP 白名单
基础限流
Canary 灰度

常见配置点：

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "5"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-body-size: "20m"

这些配置背后的含义：

proxy-connect-timeout：Ingress 连接后端的超时时间
proxy-read-timeout：Ingress 等待后端响应的超时时间
proxy-send-timeout：Ingress 向后端发送请求的超时时间
proxy-body-size：请求体大小限制

排障时经常会遇到：

上传文件失败：看 body size
慢接口 504：看 read timeout 和后端处理耗时
偶发 502：看后端 Pod 重启、连接被拒绝、Endpoint 变化
路径不对：看 rewrite 和 pathType

5. Gateway API 与 API Gateway 的区别¶

现在很多新集群会逐步考虑 Gateway API。

简单理解：

Ingress 是较早的 Kubernetes 七层入口抽象，模型相对简单
Gateway API 是更新、更细粒度、更面向角色分工的入口 API
API Gateway 是更完整的应用网关产品或平台能力，通常包含认证、鉴权、限流、计费、开放 API 管理、开发者门户等

三者不是完全互斥关系：

Ingress：基础七层入口
Gateway API：更现代的 Kubernetes 网关抽象
API Gateway：更偏业务 API 治理平台

面试里不需要把 Gateway API 讲得很深，但要能说明：

Ingress 适合基础 HTTP 路由，API Gateway 更关注 API 生命周期和治理能力，Gateway API 则是 Kubernetes 社区对入口网关抽象的进一步演进。

五、服务治理¶

1. 什么是服务治理¶

服务治理解决的问题不是“服务能不能访问”，而是：

访问是否稳定
故障是否隔离
流量是否可控
调用关系是否可观测
发布是否能灰度
依赖异常时是否能降级

在微服务和 Kubernetes 场景下，服务数量多、调用链长，一个服务变慢可能拖垮一批上游服务，所以必须有治理手段。

2. 服务发现¶

服务发现回答的问题是：

调用方如何找到被调用方？

Kubernetes 里最基础的服务发现就是 Service + DNS。

例如：

user-service.default.svc.cluster.local

调用方不需要知道后端 Pod IP，只需要访问 Service 名称。

常见服务发现方式：

Kubernetes Service + CoreDNS
注册中心，如 Nacos、Consul、Eureka
Service Mesh 控制面下发服务发现配置

面试要点：

Kubernetes 原生服务发现适合集群内服务互访，但如果涉及跨集群、多语言治理、复杂流量策略，可能会引入注册中心、网关或 Service Mesh。

3. 超时¶

超时是服务治理里最基础也最容易被忽略的能力。

没有超时会导致：

调用方线程或协程被长期占住
连接池耗尽
请求堆积
故障放大成雪崩

超时应该分层设置：

客户端连接超时
客户端读取超时
Ingress / Gateway 超时
服务间 RPC 超时
数据库和缓存访问超时

关键原则：

超时要小于用户可接受等待时间，也要小于上游网关的超时；下游超时不能无限大，否则上游已经放弃了，下游还在继续消耗资源。

4. 重试¶

重试能提高短暂故障下的成功率，但配置不好会放大流量。

适合重试的情况：

短暂网络抖动
连接重置
临时 503
幂等读请求

不适合盲目重试的情况：

非幂等写请求
下游已经明显过载
大请求或长耗时任务
没有限流保护的核心依赖

面试表达：

重试必须和超时、限流、熔断一起设计。否则下游一慢，上游不断重试，会把一次故障放大成成倍流量，最终导致雪崩。

5. 限流¶

限流的目标是保护系统，不让流量超过系统承载能力。

常见限流维度：

按 IP
按用户
按租户
按 API
按服务实例
按全局 QPS

常见算法：

固定窗口
滑动窗口
漏桶
令牌桶

简单理解：

漏桶更强调平滑流出
令牌桶允许一定突发流量

生产里限流通常放在这些位置：

CDN / WAF
API Gateway
Ingress
服务框架
核心依赖客户端

面试里要强调：

限流不是为了拒绝用户，而是为了保护核心链路。限流策略要配合降级页面、错误码、告警和容量评估，否则只是把问题从系统内部暴露给用户。

6. 熔断与降级¶

熔断是当下游服务异常比例过高时，调用方暂时停止请求下游，避免继续拖垮系统。

典型状态：

Closed：正常调用
Open：熔断打开，快速失败
Half-Open：少量探测请求，判断是否恢复

降级是当依赖不可用时，用较低质量但可接受的结果保证主流程可用。

例子：

推荐服务挂了，返回默认推荐
积分服务慢了，先完成下单，异步补偿积分
评论服务异常，商品详情页先隐藏评论模块

面试表达：

熔断关注的是阻断故障传播，降级关注的是保住核心用户体验。它们通常和超时、限流、重试、告警一起组成稳定性治理闭环。

7. 灰度发布¶

灰度发布是把新版本逐步暴露给一部分流量，观察稳定后再扩大范围。

常见灰度方式：

按权重
按 Header
按 Cookie
按用户 ID
按地域
按租户

在 Kubernetes 里可以通过这些方式实现：

Ingress Canary
网关流量分配
Service Mesh 流量规则
发布平台控制副本和流量权重

灰度的关键不是“能分流”，而是必须有观察和回滚：

错误率
延迟
QPS
资源使用率
业务核心指标
一键回滚能力

六、Service Mesh 的价值¶

1. Service Mesh 解决什么问题¶

Service Mesh 的典型代表是 Istio、Linkerd。

它的核心思想是把服务治理能力从业务代码里下沉到基础设施层。

常见架构：

业务容器
  -> Sidecar Proxy
  -> 网络
  -> Sidecar Proxy
  -> 目标业务容器

控制面负责下发规则，数据面负责真正处理流量。

Service Mesh 常见能力：

服务发现
mTLS
流量路由
灰度发布
超时、重试、熔断
可观测性
访问控制

2. Service Mesh 的价值和代价¶

价值：

多语言服务治理统一
业务代码少侵入
流量策略集中管理
服务间调用可观测性更好
mTLS 和零信任能力更容易落地

代价：

架构复杂度增加
Sidecar 带来资源开销
排障链路变长
对平台团队能力要求更高
控制面异常可能影响治理规则下发

面试里不要把 Service Mesh 说成“上了就高级”。更成熟的回答是：

Service Mesh 适合服务规模较大、多语言、多团队、治理要求高的场景。如果只是少量服务，直接用 Kubernetes Service、Ingress、网关和应用框架治理可能更简单。是否引入 Mesh，要看治理收益能不能覆盖复杂度和运维成本。

3. 东西向流量与南北向流量¶

这是服务治理面试里的高频概念。

南北向流量：集群外部和集群内部之间的流量
东西向流量：集群内部服务之间的流量

例子：

用户 -> Ingress -> 服务

这是南北向流量。

订单服务 -> 库存服务 -> 支付服务

这是东西向流量。

常见治理位置：

南北向：CDN、WAF、LB、Ingress、API Gateway
东西向：Service、Sidecar、Service Mesh、RPC 框架

七、线上网络故障怎么排查¶

1. 总体原则¶

网络排障不要一上来就猜原因，要先确定问题在哪一段。

推荐顺序：

先确认现象：完全不通、偶发失败、慢、错误码、只影响部分用户还是全部用户
再确认范围：单服务、单节点、单集群、单可用区、单地域
沿链路分层：DNS、LB、Ingress、Service、Pod、应用、依赖
用最小验证缩小范围：从客户端、网关、集群内 Pod、节点分别测试
同时看变更：发布、扩容、证书、配置、网络策略、云资源变更

一个非常实用的排障图：

用户访问失败
  -> DNS 是否正确
  -> LB 是否健康
  -> Ingress 是否匹配
  -> Service 是否有 Endpoint
  -> Pod 是否 Ready
  -> 应用端口是否监听
  -> 应用依赖是否正常

2. 502 怎么定位¶

502 通常表示网关或代理无法从上游拿到有效响应。

常见原因：

后端 Pod 不存在或未 Ready
Service selector 配错，没有 Endpoint
后端端口配错
Pod 正在重启
应用进程没监听目标端口
Ingress 到后端连接被拒绝
上游连接被 reset

排查路径：

kubectl describe ingress <name>
kubectl describe svc <service-name>
kubectl get endpointslice
kubectl get pod -o wide
kubectl logs <pod>
kubectl exec -it <debug-pod> -- curl -v http://<service-name>:<port>

回答模板：

我会先看 502 是入口层返回还是应用自己返回。若是 Ingress 返回，先检查 Ingress 规则是否命中，再看 Service 是否有 Endpoint，Endpoint 对应的 Pod 是否 Ready，端口是否一致。然后从集群内用 curl 直接访问 Service 和 Pod IP，判断问题是在网关到 Service、Service 到 Pod，还是应用本身。

3. 504 怎么定位¶

504 通常表示网关等待上游响应超时。

常见原因：

后端接口处理慢
数据库、缓存、第三方依赖慢
Ingress 或网关超时配置太短
应用线程池、连接池耗尽
Pod CPU 被限流或资源不足
网络丢包或重传严重

排查路径：

看 Ingress access log，确认 upstream response time
看应用日志，确认请求是否到达应用
看应用处理耗时和依赖耗时
看 Pod CPU、内存、连接池、线程池
看数据库慢查询、缓存延迟、第三方接口
看网关超时配置是否小于业务正常耗时

回答模板：

504 我会重点判断是“请求没到后端”还是“后端处理超时”。如果应用日志没有请求，先查 Ingress 到 Service 的链路；如果应用收到了请求，就看应用耗时、下游依赖、连接池和资源水位。同时检查网关超时配置，避免业务正常耗时超过入口超时。

4. 集群内 Service 不通怎么查¶

排查顺序：

kubectl get svc <service-name>
kubectl describe svc <service-name>
kubectl get endpointslice -l kubernetes.io/service-name=<service-name>
kubectl get pod -l <label> -o wide
kubectl describe pod <pod-name>
kubectl exec -it <debug-pod> -- curl -v http://<service-name>:<port>
kubectl exec -it <debug-pod> -- curl -v http://<pod-ip>:<container-port>

判断逻辑：

Service 不存在：资源或 namespace 错
Service 存在但无 Endpoint：selector 不匹配或 Pod 未 Ready
Endpoint 有但访问 Service 不通：看 kube-proxy、网络策略、端口
访问 Pod IP 不通：看 CNI、Pod 端口、应用监听
Pod IP 通但 Service 不通：重点看 kube-proxy 和 Service 端口映射

5. DNS 解析慢或失败怎么查¶

排查顺序：

kubectl -n kube-system get pod -l k8s-app=kube-dns -o wide
kubectl -n kube-system top pod -l k8s-app=kube-dns
kubectl -n kube-system logs deploy/coredns
kubectl exec -it <pod> -- nslookup kubernetes.default.svc.cluster.local
kubectl exec -it <pod> -- cat /etc/resolv.conf

重点看：

CoreDNS 是否 Ready
CoreDNS 是否 CPU 打满
是否有大量 SERVFAIL、timeout
上游 DNS 是否可用
应用是否频繁创建短连接并重复解析
ndots 和 search domain 是否导致解析请求放大

6. 网络策略导致不通怎么查¶

如果集群启用了 NetworkPolicy，要注意默认行为。

NetworkPolicy 是 namespace 级别的网络访问控制，用来限制 Pod 入站或出站流量。

常见问题：

默认拒绝策略生效后，忘记放行必要流量
放行了业务端口，没放行 DNS
label selector 写错
只写了 ingress，忘了 egress
CNI 插件是否支持 NetworkPolicy

排查命令：

kubectl get networkpolicy -A
kubectl describe networkpolicy <name>
kubectl get pod --show-labels

八、面试高频问法与回答¶

1. Service 和 Ingress 的职责分别是什么？¶

可以这样答：

Service 负责给一组动态 Pod 提供稳定访问入口，主要解决集群内四层访问和负载均衡问题。Ingress 负责集群外 HTTP/HTTPS 七层入口，按域名、路径等规则把流量转发到 Service，并可以做证书、重写、限流、灰度等治理能力。简单说，Service 管后端服务发现和稳定访问，Ingress 管外部七层流量入口。

2. kube-proxy 是不是流量一定经过的组件？¶

要谨慎回答。

更准确的说法：

kube-proxy 不是一个所有流量都经过的代理进程，它主要负责在节点上维护 Service 转发规则。iptables 或 ipvs 模式下，真正的数据包转发发生在内核网络栈中。不同 CNI 或 eBPF 实现可能绕过传统 kube-proxy 模式，例如 Cilium 可以用 eBPF 实现 Service 转发。

3. Pod 能访问 Service，但访问外网不通，怎么查？¶

排查思路：

Pod DNS 是否能解析外部域名
节点是否能访问外网
NAT Gateway 或 SNAT 是否正常
安全组、ACL、防火墙是否放行
NetworkPolicy 是否限制 egress
目标外部服务是否限制来源 IP

回答模板：

我会先在 Pod 内分别测试 DNS 和 IP 连通性。如果 IP 通但域名不通，重点查 DNS；如果 IP 也不通，再从节点测试外网，判断是 Pod egress、节点路由、NAT 还是安全策略问题。云上还要看 NAT 网关、路由表、安全组和出口 IP 白名单。

4. 为什么 Service 有 Endpoint 但访问还是失败？¶

可能原因：

targetPort 配错
应用没有监听对应端口
Pod readiness 通过但应用实际不可用
NetworkPolicy 拦截
kube-proxy 规则异常
CNI 跨节点网络异常
应用只监听 127.0.0.1，没有监听 Pod IP

重点表达：

Endpoint 只能说明 Kubernetes 认为后端地址存在，不等于应用一定能正常处理请求。还要继续验证端口监听、应用健康、网络策略和实际 curl 结果。

5. Ingress 返回 404 和 502 有什么区别？¶

回答：

404 通常说明七层路由没有匹配到，或者被后端应用返回了 404；如果是 Ingress 默认后端返回，多半是 Host、Path 或 ingressClass 配置问题。502 通常说明路由匹配到了，但 Ingress 访问上游 Service 或 Pod 失败，比如后端端口错误、Endpoint 不存在、Pod 重启或连接被拒绝。

6. 你是否落地过 Istio 或服务治理方案？¶

如果落地过，可以按这个结构讲：

背景：服务数量、语言栈、治理痛点
范围：先在哪些业务或 namespace 试点
能力：mTLS、灰度、超时、重试、熔断、可观测性
风险：资源开销、排障复杂度、Sidecar 注入、控制面可用性
结果：稳定性、发布效率、故障定位是否改善

如果没落地过，也可以诚实但有结构地答：

我没有在生产大规模落地过 Istio，但理解它的价值和代价。我的判断是，小规模服务可以先用 Ingress、API Gateway、应用框架和 Kubernetes 原生能力解决治理问题；当服务规模、多语言、多团队协作和东西向流量治理复杂到一定程度，再评估 Service Mesh。引入前要先做试点，重点验证性能开销、可观测性、灰度能力和排障流程。

九、复习 Checklist¶

面试前至少要能讲清楚这些问题：

TCP 和 UDP 的区别，以及各自适用场景
三次握手、四次挥手、TIME_WAIT、CLOSE_WAIT 的含义
长连接、短连接、HTTP Keep-Alive、TCP Keepalive 的区别
四层代理和七层代理的区别
DNS 在 Kubernetes 里的解析方式
Kubernetes Pod 网络模型
CNI 插件负责什么
Service、EndpointSlice、Pod 的关系
ClusterIP、NodePort、LoadBalancer 的区别
kube-proxy 的 iptables / ipvs 模式
Ingress 和 Ingress Controller 的关系
Ingress 和 Service 的职责边界
HTTPS 证书和 TLS 终止的位置
502、504、404 的定位思路
服务发现、超时、重试、限流、熔断、降级、灰度的作用
Service Mesh 的价值和引入代价
东西向流量和南北向流量的区别

十、最后总结¶

网络、Ingress 与服务治理可以用一句话串起来：

网络基础决定你能不能看懂请求如何传输，Kubernetes 网络决定你能不能看懂流量如何到 Pod，Ingress 和网关决定你能不能治理入口流量，服务治理决定你能不能在微服务规模变大后仍然保持系统稳定。

高级运维面试里，最有价值的回答不是堆术语，而是把一个问题放到完整链路里：

客户端
  -> DNS
  -> LB
  -> Ingress / Gateway
  -> Service
  -> kube-proxy / CNI
  -> Pod
  -> 应用
  -> 下游依赖

只要你能沿着这条链路讲清楚“流量怎么走、在哪里治理、出了问题怎么定位”，网络这一块就不会只是背题，而会变成你的面试加分项。