Kubernetes Egress调用流程是什么？Pod访问外部域名的请求路径问询

先明确两个核心认知纠正：

1. /etc/hosts.allow 是Linux系统tcp_wrappers组件的访问控制配置文件，仅负责IP层的访问放行校验，完全不参与DNS解析流程
2. DNS解析是请求发起后最先执行的动作，远早于流量流出Pod的节点出口阶段

完整流转路径（集群已部署默认CoreDNS场景） #

• 第一步：Pod内应用发起google.com访问请求，首先触发系统DNS解析逻辑，按照Pod内/etc/nsswitch.conf的配置顺序查询解析源：
  • 优先读取Pod内/etc/hosts文件，检查是否存在google.com的静态配置记录，匹配到则直接返回对应IP
  • 未匹配到则读取Pod内/etc/resolv.conf配置的nameserver地址，默认K8s会将该地址指向集群CoreDNS的Service ClusterIP
• 第二步：Pod向CoreDNS发起DNS查询请求：
  • CoreDNS先查询集群内部域名缓存，未命中则向上游配置的公网DNS服务器转发查询请求，获取google.com对应的公网IP返回给Pod
• 第三步：Pod拿到解析后的公网IP后，开始封装请求报文，按网络规则逐层转发：
  • 首先匹配Pod内的路由表，默认所有非集群子网的流量都会转发到Pod的网关，也就是节点上的CNI网桥接口
  • 流量进入节点网络命名空间后，匹配kube-proxy维护的iptables/ipvs规则，确认无集群Service匹配后，走节点的默认路由转发
• 第四步：流量流出节点前，逐层匹配访问控制规则：
  • 如果配置了NetworkPolicy的Egress规则，会先校验当前Pod是否允许访问google.com对应的IP段、端口，规则拒绝的话直接丢包
  • 如果集群部署了Calico、Cilium等CNI的Egress网关，或是Istio等服务网格的Egress控制规则，流量会按配置转发到对应的Egress网关做统一出口处理
  • 只有到这个阶段，才会匹配/etc/hosts.allow//etc/hosts.deny的规则（仅当节点对应服务开启了tcp_wrapper支持时才会生效）
• 第五步：所有校验规则通过后，流量经过节点的公网出口网关，最终到达google.com的服务器

内容的提问来源于stack exchange，提问作者gaurav sinha