如何将GKE上的Airflow连接至RDS？排查集群连通超时问题

你已经完成基础VPC、DNS、防火墙配置且普通VM可连通，说明基础网络层大方向没问题，问题集中在GKE/Composer特有的网络逻辑上，按以下优先级排查：

• 优先检查RDS安全组/网络ACL的放行范围：绝大多数这类问题都是漏放了GKE集群的内部网段。普通VM访问RDS时用的是VPC子网IP，而GKE内的Airflow Pod访问外部资源默认用的是独立分配的Pod IPv4 CIDR、Service IPv4 CIDR地址，这两个段不属于VPC主子网范围，如果你之前只放行了VPC子网段，Pod发出的请求会直接被RDS侧丢弃导致超时。需要把这两个GKE集群专属网段加到RDS对应数据库端口的入站允许规则里。
• 直接在Pod层面验证连通性，不要在节点/普通VM上测试：GKE的Pod网络、DNS解析和节点层面是隔离的，节点能通不代表Pod能通。你可以执行以下命令启动临时调试Pod，在和Airflow Worker相同的网络环境下测试：

# 先获取Composer环境对应的GKE集群凭证
gcloud container clusters get-credentials <你的GKE集群名> --region <集群所在区域>
# 在Composer对应的命名空间启动临时调试容器
kubectl run -it --rm debug --image=busybox --restart=Never --namespace=<Composer环境命名空间，Composer2一般为composer-2-xxxx格式> -- sh
# 容器内先验证DNS解析是否正常
nslookup <你的RDS内网/公网地址>
# 再验证端口连通性
nc -zv <你的RDS地址> <数据库端口，比如MySQL为3306、PostgreSQL为5432>

如果nslookup返回的IP错误，说明你配置的私有DNS规则没有同步到GKE的kube-dns，需要配置Cloud DNS入站转发或者GKE存根域规则，把RDS域名的解析请求转发到你的私有DNS服务器；如果解析正常但端口不通，继续往下排查。

• 检查GKE网络策略拦截：如果你的GKE集群开启了Network Policy，默认会拦截未显式放行的Pod出向流量，需要给Airflow Worker、Scheduler所在的Pod配置出向规则，放行到RDS地址+端口的访问。
• 核对GKE IP伪装（ip-masq-agent）配置：GKE默认仅会对RFC1918规定的私有网段做SNAT，访问这些段时Pod流量会被转换为节点IP；如果你的RDS使用的是公网IP、或者自定义的非RFC1918私有地址段，Pod发出的流量会保留原始Pod IP作为源地址，RDS回包时找不到对应路由就会超时。你可以修改GKE的ip-masq-agent配置，把RDS所属的IP段加入伪装目标列表，让访问RDS的流量统一做SNAT转换为节点IP，匹配你之前配置的防火墙、安全组规则。
• 检查跨VPC路由条目：如果RDS和Composer不在同一个VPC（跨账号/跨云/通过VPC对等连接/Private Service Connect访问），需要确认对等连接的路由表中，除了VPC主子网段，还添加了GKE Pod CIDR、Service CIDR段的路由条目，漏配这两个段的路由是跨VPC场景下GKE访问不通的常见原因。

内容的提问来源于stack exchange，提问作者Guilherme Delmondes