从 GKE Pod 通过 VPN 的出站流量

Question

我有一个 VPC 网络，其子网范围为 10.100.0.0/16，节点驻留在其中。 有一个路由和防火墙规则应用于范围 10.180.102.0/23，它路由并允许进出 VPN 隧道的流量。

如果我在 10.100.0.0/16 范围内部署节点，则可以 ping 10.180.102.0/23 范围内的设备。 但是，在该节点内运行的 pod 无法 ping 10.180.102.0/23 范围内的设备。 我认为这与 pod 位于不同的 IP 范围（10.12.0.0/14）有关。

如何配置我的网络，以便我可以与 10.180.102.0/23 范围内的设备进行 ping/通信？

Answer 1

我不太记得究竟如何解决，但我正在发布我必须帮助@tdensmore 的内容。

您必须编辑 ip-masq-agent（这是一个在 GKE 上运行的代理，可以伪装 IP），此配置负责让节点内的 pod 到达 GCP VPC 网络的其他部分，更具体地说是 VPN。 因此，它允许 Pod 与可通过 VPN 访问的设备进行通信。

首先，我们将在kube-system命名空间中工作，我们将放置配置 ip-masq-agent 的 configmap，将其放入config文件中：

nonMasqueradeCIDRs:
  - 10.12.0.0/14  # The IPv4 CIDR the cluster is using for Pods (required)
  - 10.100.0.0/16 # The IPv4 CIDR of the subnetwork the cluster is using for Nodes (optional, works without but I guess its better with it)
masqLinkLocal: false
resyncInterval: 60s

并运行kubectl create configmap ip-masq-agent --from-file config --namespace kube-system

之后，配置 ip-masq-agent，将其放入ip-masq-agent.yml文件中：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: ip-masq-agent
  namespace: kube-system
spec:
  template:
    metadata:
      labels:
        k8s-app: ip-masq-agent
    spec:
      hostNetwork: true
      containers:
      - name: ip-masq-agent
        image: gcr.io/google-containers/ip-masq-agent-amd64:v2.4.1
        args:
            - --masq-chain=IP-MASQ
            # To non-masquerade reserved IP ranges by default, uncomment the line below.
            # - --nomasq-all-reserved-ranges
        securityContext:
          privileged: true
        volumeMounts:
          - name: config
            mountPath: /etc/config
      volumes:
        - name: config
          configMap:
            # Note this ConfigMap must be created in the same namespace as the daemon pods - this spec uses kube-system
            name: ip-masq-agent
            optional: true
            items:
              # The daemon looks for its config in a YAML file at /etc/config/ip-masq-agent
              - key: config
                path: ip-masq-agent
      tolerations:
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      - key: "CriticalAddonsOnly"
        operator: "Exists"

并运行kubectl -n kube-system apply -f ip-masq-agent.yml

注意：自从我这样做以来已经很长时间了，此链接中有更多信息： https : //cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent

Answer 2

我想从 GKE 中 IP 地址的一些术语开始。

网络命名空间：基于MAN 页面，网络命名空间在逻辑上是网络堆栈的另一个副本，具有自己的路由、防火墙规则和网络设备。 这个网络命名空间将节点的物理网络接口与 Pod 连接起来。 此网络命名空间还连接到 Linux 桥接器，允许同一节点上的 Pod 之间进行通信以及外部通信。

Pod IP：分配给 Pod 的 IP 地址，可在“ Pod 地址范围内的集群创建”选项中进行配置。 GKE 将此 IP 分配给 Pod 的网络命名空间中的虚拟网络接口，并路由到节点的物理网络接口，例如 eth0。

节点 IP：分配给节点物理网络接口的 IP 地址为eth0 。 此节点 IP 配置在网络命名空间上以与 Pod 通信。

集群 IP：分配的 IP 地址并在服务的生命周期内保持稳定。 使用网络命名空间来允许节点和外部网络之间的通信。

这是我的信息来源； GKE 网络概述，我还发现了这个注释：

警告：不要手动更改节点，因为它们已被 GKE 覆盖，并且您的集群可能无法正常运行。 直接访问节点的唯一原因是调试配置问题。

---

然后，如果您希望在 GKE 集群和另一个网络之间建立通信，我会建议使用不同的服务：

外部负载均衡器管理来自集群外部和 Google Cloud Virtual Private Cloud (VPC) 网络外部的流量。 他们使用与 GCP 网络关联的转发规则将流量路由到 Kubernetes 节点。

内部负载均衡器管理来自同一 VPC 网络内的流量。 与外部负载平衡器一样，它们使用与 GCP 网络关联的转发规则将流量路由到 Kubernetes 节点。

HTTP(S) 负载均衡器是用于 HTTP(S) 流量的专用外部负载均衡器。 他们使用 Ingress 资源而不是转发规则将流量路由到 Kubernetes 节点。

您可以在本文档中找到有关不同服务的更多详细信息。

总体而言，Pod 无法直接与外部资源通信。 您应该使用服务并将 pod 公开给该服务。