Kubernetes Multus:不同节点上的豆荚之间没有macvlan连接(不能ping)
我遇到了一个问题，我有一个Kubernetes集群，其中有两个工作节点和一个主节点。让我们对它们进行实验室-- W1、W2和M。我有一个部署，它创建了一组CentOS7荚，其中一些是针对每个工作人员的。我使用Multus，以便在每个吊舱上有一个额外的net1接口，映射到工人上的eth1。所有的豆荚都有net1连接到同一个名为“up”的macvlan上。
在W1和W2上，我可以在运行在同一节点上的豆荚之间切换，但是W1中的荚不能在W2中切换另一个豆荚，反之亦然。eth0上的标准kube网络在所有情况下都能工作。就是那个有这个问题的人。
简而言之，这就是问题所在。现在让我更详细地描述一下我们正在使用的设置。
我们有一个有3台物理服务器的实验室，我们在上面部署了Kolla (这是安装在Kubernet上的Openstack )。在这个Openstack安装中，我再次尝试设置一个Kubernetes安装是主节点，工作节点托管在Openstack虚拟机中(即W1、W2、M)是VM在Openstack中运行的。这意味着我们总共有三层虚拟化。我只想提一下，如果有人知道任何可能的线索的话。但我并没有遇到任何与虚拟化相关的问题。还可以提到，这些vm有两个接口eth0和eth1。Eth1是我想要的设备。最后，对于vm和物理服务器，操作系统都是CentOS7。
关于Kubernetes的安装：
- Kubernetes (覆盖云)是使用Kubespray安装的。
- i编辑主机文件，使node1主node2 W1和node3 W2。
- i set kube_network_plugin_multus to true W2用于为net1接口分配ip地址。
- i使用calico作为网络驱动程序。
F 211
下面是用于macvlan网络的配置：
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: up-net
spec:
config: '{
"cniVersion": "0.3.0",
"name": "up-net",
"type": "macvlan",
"master": "eth1",
"mode": "bridge",
"ipam": {
"type": "whereabouts",
"datastore": "kubernetes",
"kubernetes": { "kubeconfig": "/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig" },
"range": "192.168.3.225/28",
"log_file" : "/tmp/whereabouts.log",
"log_level" : "debug"
}
}'下面是豆荚的配置：
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: centos-host
spec:
replicas: 4
selector:
matchLabels:
app: centos-host
template:
metadata:
labels:
app: centos-host
annotations:
k8s.v1.cni.cncf.io/networks: up-net
spec:
containers:
- name: centos-container
image: centos:7
command: ["/bin/sleep", "infinity"]我还没有明确指定他们最终选择的是哪一个工作人员，但通常负载均衡器平均分配四个吊舱。
此外，以下是库贝系统的吊舱：
[centos@node1 ~]$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-8b5ff5d58-msq2m 1/1 Running 1 29h
calico-node-2kg2l 1/1 Running 1 29h
calico-node-4fxwr 1/1 Running 1 29h
calico-node-m4l67 1/1 Running 1 29h
coredns-85967d65-6ksqx 1/1 Running 1 29h
coredns-85967d65-8nbgq 1/1 Running 1 29h
dns-autoscaler-5b7b5c9b6f-567vz 1/1 Running 1 29h
kube-apiserver-node1 1/1 Running 1 29h
kube-controller-manager-node1 1/1 Running 1 29h
kube-multus-ds-amd64-dzmj5 1/1 Running 1 29h
kube-multus-ds-amd64-mvfpc 1/1 Running 1 29h
kube-multus-ds-amd64-sbw8n 1/1 Running 1 29h
kube-proxy-6jgvn 1/1 Running 1 29h
kube-proxy-tzf5t 1/1 Running 1 29h
kube-proxy-vgmh8 1/1 Running 1 29h
kube-scheduler-node1 1/1 Running 1 29h
nginx-proxy-node2 1/1 Running 1 29h
nginx-proxy-node3 1/1 Running 1 29h
nodelocaldns-27bct 1/1 Running 1 29h
nodelocaldns-75cgg 1/1 Running 1 29h
nodelocaldns-ftvn9 1/1 Running 1 29h
whereabouts-4tktv 1/1 Running 0 28h
whereabouts-nfwkz 1/1 Running 0 28h
whereabouts-vxgwr 1/1 Running 0 28h现在，我已经对我所运行的实验进行了说明。
考虑一下worker 1( P1a )上的pods、P1b和W1。工作人员2 (W2)上有P2a和P2b。我使用ping和tcpdump访问连接。
从P1a到P1b的Ping工作正常，tcpdump告诉我W1的eth1设备上有icmp流量。W2也是如此。
但是，当我从P2a中选择P1a时，如下所示：
[root@sample-7b9755db48-gxq5m /]# ping -c 2 192.168.3.228
PING 192.168.3.228 (192.168.3.228) 56(84) bytes of data.
From 192.168.3.227 icmp_seq=1 Destination Host Unreachable
From 192.168.3.227 icmp_seq=2 Destination Host Unreachable
--- 192.168.3.228 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms
pipe 2然而，一个有趣的线索是icmp数据包最终出现在pod上的lo接口上--在本例中：
[root@sample-7b9755db48-gxq5m /]# tcpdump -vnes0 -i lo
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
12:51:57.261003 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 126: (tos 0xc0, ttl 64, id 32401, offset 0, flags [none], proto ICMP (1), length 112)
192.168.3.227 > 192.168.3.227: ICMP host 192.168.3.228 unreachable, length 92
(tos 0x0, ttl 64, id 39033, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.3.227 > 192.168.3.228: ICMP echo request, id 137, seq 1, length 64
12:51:57.261019 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 126: (tos 0xc0, ttl 64, id 32402, offset 0, flags [none], proto ICMP (1), length 112)
192.168.3.227 > 192.168.3.227: ICMP host 192.168.3.228 unreachable, length 92
(tos 0x0, ttl 64, id 39375, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.3.227 > 192.168.3.228: ICMP echo request, id 137, seq 2, length 64你认为我的路由表可能有问题吗？我什么也看不见，但我对社交有点陌生：
[root@sample-7b9755db48-gxq5m /]# ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
192.168.3.224/28 dev net1 proto kernel scope link src 192.168.3.227最后，列出一些我尝试过但没有奏效的事情：
macaddresses).
- 将eth1设置为eth1 on W1、W2和M.
- 的混杂模式，禁用rp_filter for ipv4 (我认为macvlan对W1、W2和M.
- 进行了奇怪的操作)
回答 1
Stack Overflow用户
发布于 2021-02-01 07:41:53
最后，我自己找到了答案。原来是OpenStack安全组织造成了这个问题。我所需要做的更改就是在所有eth1网络端口上禁用端口安全。这是我对每个这样的端口使用的命令：
openstack port set --no-security-group --disable-port-security <id or name of the neutron port>在那之后，机器就可以到达了。无需重新启动服务器或服务等。
不过，我确实觉得奇怪的是，这个问题只发生在二级网络上。无论是哪种情况，希望这都可以帮助其他人在openstack VM中运行kubernetes。
https://stackoverflow.com/questions/65920557
复制相似问题
腾讯云开发者
