從 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 公開給該服務。