【问题标题】:Calico CNI pod networking not working across different hosts on EKS Kubernetes worker nodesCalico CNI pod 网络无法跨 EKS Kubernetes 工作节点上的不同主机工作
【发布时间】:2020-01-15 09:56:03
【问题描述】:

我正在运行版本 1.12 的 vanilla EKS Kubernetes。

我使用 CNI Genie 允许自定义选择 pod 在启动时使用的 CNI,并且我已经安装了标准 Calico CNI 设置。

使用 CNI Genie,我将默认 CNI 配置为 AWS CNI (aws-node),所有 pod 都照常启动并从我的 VPC 子网中分配一个 IP。

然后我有选择地使用 calico 作为我正在测试的一些基本 pod 的 CNI。我正在使用默认的 calico 192.168.0.0/16 CIDR 范围。如果 pod 在同一个 EKS 工作节点上,一切都会很好。

Core DNS 也运行良好(只要我保持 coredns pod 在 aws CNI 上运行)。

但是,如果一个 pod 移动到不同的工作节点,那么它们之间的网络在集群内就无法工作。

我检查了 calico 自动配置的工作节点上的路由表,这对我来说是合乎逻辑的。

这是我在所有命名空间中的广泛 pod 列表:

NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE   IP                NODE                                       NOMINATED NODE
default       hello-node1-865588ccd7-64p5x               1/1     Running   0          31m   192.168.106.129   ip-10-0-2-31.eu-west-2.compute.internal    <none>
default       hello-node2-dc7bbcb74-gqpwq                1/1     Running   0          17m   192.168.25.193    ip-10-0-3-222.eu-west-2.compute.internal   <none>
kube-system   aws-node-cm2dp                             1/1     Running   0          26m   10.0.3.222        ip-10-0-3-222.eu-west-2.compute.internal   <none>
kube-system   aws-node-vvvww                             1/1     Running   0          31m   10.0.2.31         ip-10-0-2-31.eu-west-2.compute.internal    <none>
kube-system   calico-kube-controllers-56bfccb786-fc2j4   1/1     Running   0          30m   10.0.2.41         ip-10-0-2-31.eu-west-2.compute.internal    <none>
kube-system   calico-node-flmnl                          1/1     Running   0          31m   10.0.2.31         ip-10-0-2-31.eu-west-2.compute.internal    <none>
kube-system   calico-node-hcmqd                          1/1     Running   0          26m   10.0.3.222        ip-10-0-3-222.eu-west-2.compute.internal   <none>
kube-system   coredns-6c64c9f456-g2h9k                   1/1     Running   0          30m   10.0.2.204        ip-10-0-2-31.eu-west-2.compute.internal    <none>
kube-system   coredns-6c64c9f456-g5lhl                   1/1     Running   0          30m   10.0.2.200        ip-10-0-2-31.eu-west-2.compute.internal    <none>
kube-system   genie-plugin-hspts                         1/1     Running   0          26m   10.0.3.222        ip-10-0-3-222.eu-west-2.compute.internal   <none>
kube-system   genie-plugin-vqd2d                         1/1     Running   0          31m   10.0.2.31         ip-10-0-2-31.eu-west-2.compute.internal    <none>
kube-system   kube-proxy-jm7f7                           1/1     Running   0          26m   10.0.3.222        ip-10-0-3-222.eu-west-2.compute.internal   <none>
kube-system   kube-proxy-nnp76                           1/1     Running   0          31m   10.0.2.31         ip-10-0-2-31.eu-west-2.compute.internal    <none>

如您所见,两个 hello-node pod 正在使用 Calico CNI。

我已经使用两个服务公开了 hello-node pod:

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
hello-node1   ClusterIP   172.20.90.83    <none>        8081/TCP   43m
hello-node2   ClusterIP   172.20.242.22   <none>        8082/TCP   43m

我已确认是否使用 aws CNI 启动 hello-node pod,当它们使用集群服务名称在单独的主机上运行时,我可以在它们之间 ping/curl。

当我像上面那样使用 Calico CNI 时,一切都停止了。

我在这个测试集群中只有两台 EKS 工作主机。这是每个的路由:

K8s Worker 1 路线

[ec2-user@ip-10-0-3-222 ~]$ ip route
default via 10.0.3.1 dev eth0
10.0.3.0/24 dev eth0 proto kernel scope link src 10.0.3.222
169.254.169.254 dev eth0
blackhole 192.168.25.192/26 proto bird
192.168.25.193 dev calia0da7d91dc2 scope link
192.168.106.128/26 via 10.0.2.31 dev tunl0 proto bird onlink

K8s Worker 2 路线

[ec2-user@ip-10-0-2-31 ~]$ ip route
default via 10.0.2.1 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.31
10.0.2.41 dev enif4cf9019f11 scope link
10.0.2.200 dev eni412af1a0e55 scope link
10.0.2.204 dev eni04260ebbbe1 scope link
169.254.169.254 dev eth0
192.168.25.192/26 via 10.0.3.222 dev tunl0 proto bird onlink
blackhole 192.168.106.128/26 proto bird
192.168.106.129 dev cali19da7817849 scope link

对我来说,路线: 192.168.25.192/26 via 10.0.3.222 dev tunl0 proto bird onlink

告诉我,来自该工作程序(及其容器/pod)的发往 192.168.25.192/16 子网的流量应该在 tunl0 接口上发送到 10.0.3.222(用于 EC2 主机的 AWS VPC ENI)。

此路由位于 EC2 主机 10.0.2.31 上。因此,换句话说,当从该主机的容器与 calico 子网 192.168.25.192/16 上的容器通信时,网络流量应路由到 10.0.3.222(我的另一个 EKS 工作节点的 ENI IP,其中使用 Calico 的容器在该子网上运行)。

澄清我的测试程序:

  1. 执行到 hello-node1 pod,然后curl http://hello-node2:8082(或 ping hello-node2 pod 的 calico 分配的 IP 地址。

编辑

为了进一步测试这一点,我在运行 hello-node2 pod 的主机上运行 tcpdump,在端口 8080 上捕获(容器侦听此端口)。

我确实在我正在运行的测试容器运行的目标主机上获得了活动,但它似乎并不表示流量下降。

[ec2-user@ip-10-0-3-222 ~]$ sudo tcpdump -vv -x -X -i tunl0 'port 8080'
tcpdump: listening on tunl0, link-type RAW (Raw IP), capture size 262144 bytes
14:32:42.859238 IP (tos 0x0, ttl 254, id 63813, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.2.31.29192 > 192.168.25.193.webcache: Flags [S], cksum 0xf932 (correct), seq 3206263598, win 28000, options [mss 1400,sackOK,TS val 2836614698 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c f945 4000 fe06 9ced 0a00 021f  E..<.E@.........
        0x0010:  c0a8 19c1 7208 1f90 bf1b b32e 0000 0000  ....r...........
        0x0020:  a002 6d60 f932 0000 0204 0578 0402 080a  ..m`.2.....x....
        0x0030:  a913 4e2a 0000 0000 0103 0307            ..N*........
14:32:43.870168 IP (tos 0x0, ttl 254, id 63814, offset 0, flags [DF], proto TCP (6), length 60)
    10.0.2.31.29192 > 192.168.25.193.webcache: Flags [S], cksum 0xf53f (correct), seq 3206263598, win 28000, options [mss 1400,sackOK,TS val 2836615709 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c f946 4000 fe06 9cec 0a00 021f  E..<.F@.........
        0x0010:  c0a8 19c1 7208 1f90 bf1b b32e 0000 0000  ....r...........
        0x0020:  a002 6d60 f53f 0000 0204 0578 0402 080a  ..m`.?.....x....
        0x0030:  a913 521d 0000 0000 0103 0307            ..R.........
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

即使是运行我的目标/测试 pod 的主机上的 calia0da7d91dc2 接口,每当我从另一个主机上的另一个 pod 运行 curl 时,RX 数据包和字节数也会增加。流量肯定在穿越。

[ec2-user@ip-10-0-3-222 ~]$ ifconfig
calia0da7d91dc2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440
        inet6 fe80::ecee:eeff:feee:eeee  prefixlen 64  scopeid 0x20<link>
        ether ee:ee:ee:ee:ee:ee  txqueuelen 0  (Ethernet)
        RX packets 84  bytes 5088 (4.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

是什么阻止了网络在此处的主机之间工作?我错过了什么明显的东西吗?

编辑 2 - Arjun Pandey-parjun8840 的信息

以下是有关我的 Calico 配置的更多信息:

  • 我已禁用所有 AWS EC2 工作程序节点上的源/目标检查
  • 我已按照最新的 calico 文档配置 IP 池以用于跨子网和 NAT 用于集群外的流量

calicoctl configs 注意: 工作负载端点似乎不存在...

 me@mine ~ aws-vault exec my-vault-entry -- kubectl get IPPool --all-namespaces
NAME                  AGE
default-ipv4-ippool   1d

 me@mine ~ aws-vault exec my-vault-entry -- kubectl get IPPool default-ipv4-ippool -o yaml
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  annotations:
    projectcalico.org/metadata: '{"uid":"41bd2c82-d576-11e9-b1ef-121f3d7b4d4e","creationTimestamp":"2019-09-12T15:59:09Z"}'
  creationTimestamp: "2019-09-12T15:59:09Z"
  generation: 1
  name: default-ipv4-ippool
  resourceVersion: "500448"
  selfLink: /apis/crd.projectcalico.org/v1/ippools/default-ipv4-ippool
  uid: 41bd2c82-d576-11e9-b1ef-121f3d7b4d4e
spec:
  blockSize: 26
  cidr: 192.168.0.0/16
  ipipMode: CrossSubnet
  natOutgoing: true
  nodeSelector: all()
  vxlanMode: Never

 me@mine ~ aws-vault exec my-vault-entry -- calicoctl get nodes
NAME
ip-10-254-109-184.ec2.internal
ip-10-254-109-237.ec2.internal
ip-10-254-111-147.ec2.internal

 me@mine ~ aws-vault exec my-vault-entry -- calicoctl get workloadendpoints
WORKLOAD   NODE   NETWORKS   INTERFACE


 me@mine ~

以下是集群中的示例主机和测试容器的容器网络之一的一些网络信息:

主持人ip a

[ec2-user@ip-10-254-109-184 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 02:1b:79:d1:c5:bc brd ff:ff:ff:ff:ff:ff
    inet 10.254.109.184/26 brd 10.254.109.191 scope global dynamic eth0
       valid_lft 2881sec preferred_lft 2881sec
    inet6 fe80::1b:79ff:fed1:c5bc/64 scope link
       valid_lft forever preferred_lft forever
3: eni808caba7453@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
    link/ether c2:be:80:d4:6a:f3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::c0be:80ff:fed4:6af3/64 scope link
       valid_lft forever preferred_lft forever
5: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 192.168.29.128/32 brd 192.168.29.128 scope global tunl0
       valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 02:12:58:bb:c6:1a brd ff:ff:ff:ff:ff:ff
    inet 10.254.109.137/26 brd 10.254.109.191 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::12:58ff:febb:c61a/64 scope link
       valid_lft forever preferred_lft forever
7: enia6f1918d9e2@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
    link/ether 96:f5:36:53:e9:55 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::94f5:36ff:fe53:e955/64 scope link
       valid_lft forever preferred_lft forever
8: enia32d23ac2d1@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default
    link/ether 36:5e:34:a7:82:30 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::345e:34ff:fea7:8230/64 scope link
       valid_lft forever preferred_lft forever
9: cali5e7dde1e39e@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
[ec2-user@ip-10-254-109-184 ~]$

nsenter 在测试容器 pid 上获取 ip a 信息:

[ec2-user@ip-10-254-109-184 ~]$ sudo nsenter -t 15715 -n ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether 9a:6d:db:06:74:cb brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.29.129/32 scope global eth0
       valid_lft forever preferred_lft forever

【问题讨论】:

    标签: kubernetes amazon-eks project-calico


    【解决方案1】:

    我现在不确定确切的解决方案(我没有在 AWS 上测试过 calico,通常我在 AWS 和物理集群 calico 上使用 amazon-vpc-cni-k8s),但下面是我们可以快速完成的事情调查。

    Calico AWS 要求-https://docs.projectcalico.org/v2.3/reference/public-cloud/aws

    kubectl get IPPool --all-namespaces
    NAME                  AGE
    default-ipv4-ippool   15d
    
    kubectl get IPPool default-ipv4-ippool -o yaml
    
    
    ~ calicoctl get nodes
    NAME            
    node1         
    node2        
    node3 
    node4   
    
    ~ calicoctl get workloadendpoints
    
    NODE            ORCHESTRATOR   WORKLOAD                                                   NAME    
    node2               k8s            default.myapp-569c54f85-xtktk                   eth0       
    node1               k8s            kube-system.calico-kube-controllers-5cbcccc885-b9x8s   eth0   
    node1               k8s            kube-system.coredns-fb8b8dcde-2zpw8                    eth0   
    node1               k8s            kube-system.coredns-fb8b8dcfg-hc6zv                    eth0 
    

    如果我们能得到容器网络的详细信息: nsenter -t pid -n ip a

    对于主持人也是如此: ip一个

    【讨论】:

    • 嗨 Arjun,这太好了 - 我查看了最新的 AWS 特定 calico 文档,并使用 calicoctl 重新配置了我的默认 IP 池,以确保它使用 ipip 并启用了跨子网。我应用了新配置并确保启动新主机(并终止旧主机)。请检查我在新的 Edit 2 部分下的原始问题 - 我已经添加了您建议使用 calicoctl 命令和 ip a 和命名空间输入命令获取的所有信息......另外值得注意的是我似乎没有任何工作负载端点。这是正确的吗?上面我的编辑 2 部分中有更多详细信息。
    • 更多信息:(除了我在原始帖子中的更新),我发现了这个:设置我的默认 IPPool 以使用 ipipMode: CrossSubnet 适用于 pod 之间的流量不同的容器主机/节点,但不是当主机位于不同的子网(可用区)时。这似乎违背了 CrossSubnet 的设计目的并且没有意义。将 ipipMode 设置为 Always(始终用于封装)似乎会破坏事情,然后流量无法跨主机或子网工作。
    猜你喜欢
    • 2021-01-12
    • 2020-07-03
    • 2020-05-01
    • 1970-01-01
    • 2019-07-14
    • 1970-01-01
    • 2018-12-19
    • 1970-01-01
    • 2021-01-25
    相关资源
    最近更新 更多