Closed Git4Mark closed 1 year ago
脚本中通过 VLAN_INTERFACE_NAME 制定要使用的节点网卡。
使用前请仔细阅读文档:Underlay 网络安装
VLAN_NIC=${VLAN_NIC:-myeth0} 使用这个参数是一样的吧,我看安装脚本逻辑也是读的这个变量
文档中有环境要求,先检查一下是否满足要求。问题原因应该是 Pod 无法和节点通信,需要检查物理网络的配置。
检查了下,发现是虚拟平台的vswitch网络没开启混杂模式导致的,已解决,不过underlay组网失败时为啥感觉走了geneve隧道呢,是专门做的判断吗,underlay不通时直接走隧道?
Expected Behavior
kube-ovn underlay正常工作
Actual Behavior
kube-ovn underlay模式,pod无法访问service,pod无法访问宿主机(除了pod所在宿主机)
Steps to Reproduce the Problem
1.kubeadm安装k8s,3master,2worker,keepalive+haproxy高可用 2.kube-ovn1.11.3安装underlay模式,安装过程卡在coredns重建,长时间超时退出 3.观察coredns日志发现pod无法访问service,测试网络发现pod访问service ip和宿主机ip均不通 4.卸载kube-ovn重装overlay模式,网络正常 5.卸载kube-ovn(官方脚本+etcd清理)重装underlay模式,pod无法访问service,宿主机ip,宿主机无法访问其它节点上的pod 6.抓包发现pod流量经过了geneve封装(多次卸载重装均是这个结果)
Additional Info
宿主机为vCenter创建的5台虚拟机
Kubernetes version:
Output of
kubectl version
:kube-ovn version:
operation-system/kernel version:
Output of
awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release
: Output ofuname -r
:ovn安装参数