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文件中：< / p>

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 page，网络名称空间在逻辑上是网络堆栈的另一个副本，具有其自己的路由，防火墙规则和网络设备。该网络名称空间将节点的物理网络接口与Pod连接。该网络名称空间还连接到Linux桥接器，该桥接器允许在同一节点上的Pod之间进行通信，并进行外部通信。

Pod IP：：分配给Pod的IP地址，并且可以在 Pod Address Range 选项中创建群集期间进行配置。 GKE将此IP分配给Pod网络名称空间中的虚拟网络接口，并路由到节点的物理网络接口，例如eth0。

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

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

这是我的信息来源； GKE Network Overview在这里也发现了此笔记：

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

然后，如果您希望在GKE群集和另一个网络之间建立通信，则建议使用其他服务：

外部负载平衡器管理来自群集外部和Google Cloud虚拟私有云（VPC）网络外部的流量。他们使用与Google Cloud网络关联的转发规则将流量路由到Kubernetes节点。

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

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

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

总的来说，吊舱无法直接与外部资源进行通信。您应该使用一项服务，并将Pod暴露给该服务。

通过VPN从GKE Pod流出的流量

2 个答案: