如何将Kubernetes集群所有节点流量通过代理转发？解决ACL限制问题

这问题我之前帮团队处理过类似的，核心就是要把集群里所有Pod的出站流量都收敛到一个统一的出口IP上，刚好你已经有Ingress VIP了，可以结合这个资源来落地。给你几个靠谱的方案，按复杂度和适用场景分：

方案一：节点层面配置SNAT规则（快速落地） #

这个方案最直接，不需要额外部署组件，靠iptables的SNAT规则把所有Pod的出站流量伪装成统一IP（可以是你的Ingress VIP，或者专门的出口节点IP）。

操作步骤： #

1. 确定统一出口IP：选一个有权限访问外部ACL设备的IP，比如你的Ingress VIP（确保这个VIP在集群节点上是可路由的），或者指定一个集群节点的公网/内网IP。
2. 在所有集群节点上配置SNAT规则：
   假设你的Pod网段是10.244.0.0/16，统一出口IP是192.168.1.100，执行以下命令：

   iptables -t nat -A POSTROUTING -s 10.244.0.0/16 ! -d 10.244.0.0/16 -j SNAT --to-source 192.168.1.100
   

   解释：这条规则会把所有Pod发往集群外的流量，源IP替换成统一出口IP。
3. 持久化规则：节点重启后iptables规则会丢失，所以要持久化：
   • 对于Debian/Ubuntu：iptables-save > /etc/iptables/rules.v4
   • 对于CentOS/RHEL：iptables-save > /etc/sysconfig/iptables
     或者用systemd服务自动加载规则。

注意点： #

• 如果出口IP是Ingress VIP，要确保VIP绑定的节点不会故障，或者用keepalived做VIP的高可用切换。
• 这个方案是全局生效的，所有Pod的出站流量都会走统一IP，适合不需要区分Pod流量的场景。

方案二：用Calico/Istio Egress Gateway（云原生管理） #

如果你的集群用Calico做CNI，或者已经部署了Istio服务网格，用Egress Gateway是更符合云原生架构的方案，能通过K8s资源来管理出站流量，还能灵活控制哪些Pod走统一出口。

以Calico为例： #

1. 定义EgressGateway资源：指定出口节点和统一出口IP（比如你的Ingress VIP）：

   apiVersion: projectcalico.org/v3
   kind: EgressGateway
   metadata:
     name: unified-egress-gw
   spec:
     selector: kubernetes.io/hostname == "your-egress-node" # 绑定到Ingress VIP所在的节点
     ipAddresses:
     - 192.168.1.100 # 你的统一出口IP（Ingress VIP）
   

2. 定义EgressPolicy规则：匹配所有Pod，把它们的出站流量导向Egress Gateway：

   apiVersion: projectcalico.org/v3
   kind: EgressPolicy
   metadata:
     name: all-pods-unified-egress
   spec:
     selector: all() # 匹配所有Pod，也可以用标签匹配特定Pod
     egress:
     - action: Allow
       destination:
         nets: ["0.0.0.0/0"] # 所有外部地址
       egressGateway:
         name: unified-egress-gw
   

3. 应用配置：kubectl apply -f egress-gw.yaml 和 kubectl apply -f egress-policy.yaml

优势： #

• 完全通过K8s资源管理，不需要手动操作节点。
• 可以灵活配置不同Pod的出站策略，比如部分Pod走统一出口，部分走节点IP。
• 支持高可用，多个Egress Gateway节点可以做负载均衡。

方案三：部署专用出站代理（适合需要代理功能的场景） #

如果需要对出站流量做缓存、过滤或者协议转换（比如SNMP这类非HTTP协议，可能需要调整代理配置），可以部署一个Squid或者Nginx代理，让所有Pod的流量通过代理出去，代理用统一IP访问外部设备。

操作步骤： #

1. 部署Squid代理：把代理部署到Ingress VIP所在的节点，确保代理的出口IP是VIP：

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: egress-proxy
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: egress-proxy
     template:
       metadata:
         labels:
           app: egress-proxy
       spec:
         nodeSelector:
           kubernetes.io/hostname: "your-egress-node" # 绑定到VIP节点
         containers:
         - name: squid
           image: sameersbn/squid:3.5.27
           ports:
           - containerPort: 3128
           volumeMounts:
           - name: squid-config
             mountPath: /etc/squid3/squid.conf
         volumes:
         - name: squid-config
           configMap:
             name: squid-config
   

2. 配置Squid允许集群Pod访问：创建ConfigMap：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: squid-config
   data:
     squid.conf: |
       http_access allow localnet
       http_access allow localhost
       http_access deny all
       acl localnet src 10.244.0.0/16 # 你的Pod网段
       http_port 3128
       visible_hostname egress-proxy
       # 如果需要支持SNMP，要添加对应的ACL和端口配置
   

3. 暴露代理服务：用ClusterIP暴露代理：

   apiVersion: v1
   kind: Service
   metadata:
     name: egress-proxy
   spec:
     selector:
       app: egress-proxy
     ports:
     - port: 3128
       targetPort: 3128
   

4. 让Pod使用代理：可以手动给Pod添加环境变量：

   env:
   - name: HTTP_PROXY
     value: http://egress-proxy:3128
   - name: HTTPS_PROXY
     value: http://egress-proxy:3128
   - name: NO_PROXY
     value: 10.244.0.0/16,localhost,cluster.local
   

   或者用Admission Webhook自动注入代理配置，避免手动修改每个Pod。

注意点： #

• 对于SNMP这类非HTTP协议，Squid默认不支持，需要用支持UDP的代理（比如snmpd或者直接用NAT方案），或者调整Squid配置支持UDP转发。
• 代理方案适合需要对流量做额外处理的场景，比如日志记录、访问控制等。

总结 #

• 如果追求快速落地，SNAT规则是最优选择，成本最低。
• 如果要云原生管理和灵活控制，Calico/Istio Egress Gateway更合适。
• 如果需要代理功能，专用出站代理是正确方向。

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