k8s+isulad 国产化技术栈云原生技术栈搭建1-VPC
为响应政策，最近在捣鼓国产化云原生平台的搭建。在搭建过程中遇到了问题记录下来，以备后续查找。
我选用了中国电子云的云平台来搭建K8S集群，选用的技术栈是华为开源的openeuler+k8s+isulad框架，参考官网文档资料：iSulad+k8s环境部署 | 文档 | openEuler社区
搭建过程中遇到的第一个问题是：创建K8S集群Master节点高可用网络不通问题。
按照我前面博客中写过的：在3个Master节点上使用keepalived建立虚拟地址，通过配置设置切换优先级，当虚拟地址所在的主机宕机时，虚拟地址按照优先级顺序自动切换至下一个Master节点，以确保控制节点的可用性。其确保高可用的k8s中的服务主要是注册服务etcd和接口服务apiserver。只不过当前的环境Master节点不是通过物理机部署，而是在中国电子云云服务器ECS中创建的虚拟机上部署的，操作系统安装的是OpenEuler-x86_64_LTS。
keepalived的安装配置方法基本和前面写的“k8s学习笔记——keepalived非容器”相同（创作中心-CSDN），其配置脚本如下：
// /etc/keepalived/keepalvied.conf
global_defs {router_id LVS_2
}vrrp_script checkhaproxy {script "/usr/bin/check-haproxy.sh"interval 3weight -30
}vrrp_instance VI_2 {state MASTER //备用节点BACKUPinterface enp3s1 //主网卡接口virtual_router_id 41 //其他节点号要一致priority 100 //值越大优先级越大nopreemptadvert_int 1authentication {auth_type PASSauth_pass txgm2m85331919}garp_master_refresh 5garp_master_delay 1unicast_src_ip 22.12.70.141 //当前主机ip，启用单播模式防止默认的多播系统阻断unicast_peer { // 其他master节点地址22.12.70.142 22.12.70.143}virtual_ipaddress {22.12.70.140/25 dev enp3s1 //虚拟地址} track_interface {enp3s1}track_script {checkhaproxy}
}
按照以前的配置在master1节点，ip：22.12.70.141的地址上通过ip addr命令查看可以看到ip：22.12.70.140的虚拟地址，将master1节点虚拟机关机，虚拟地址22.12.70.140也能浮动到master2节点上。但是虚拟地址22.12.70.140只能在本地ping通，其他主机节点均不通，无论是跨网段还是本网段。在DeepSeek上询问此问题，它起初判断定位是：ARP广播问题、防火墙阻止VRRP/ICMP、网络设备限制。按照AI给的解决方案逐一排查：
检查防火墙，防火墙是关闭的；怀疑是多播被禁止了，于是又在配置文件中配置了unicast_src_ip，还是不管有；通过sudo tcpdump -i enp3s1 host 22.12.70.140命令在master1上监听，其他节点ping该节点：
10:03:00.828170 ARP, Request who-has k8s-isulad-master1 tell k8s-isulad-master3, length 42
10:03:00.828179 ARP, Reply k8s-isulad-master1 is-at 06:37:85:22:35:4d (oui Unknown), length 28也能收到arp数据包，从其他网段traceroute 22.12.70.140 能到达网关，再往下就不通了；就怀疑是控制策略问题，又按照其解决方案对/etc/sysctl.conf文件配置了一通，还在master1节点上给22.12.70.140地址配置了vip的策略路由，结果统统不管用。为恢复配置索性又重装了系统。问题依旧存在。
通过上述尝试，我怀疑问题不应该出在master节点上，有可能是网络的VXLAN的问题。于是我到网关节点的交换机上进行测试，发现除了虚拟地址所有地址都可以ping通，在arp映射表中找不到22.12.70.140地址对应的mac地址映射，并且这种现象在我之前配置的物理主机做的高可用虚拟地址上同样存在，这更坚定了我的判断，于是联系了中国电子云的技术售后，给他们讲了此问题。
经过技术售后远程查看，发现问题原因和上述判断都没有关系，而是因为在虚拟机上想配置高可用需要先配置云服务的专有网络VPC，将在ECS中虚拟地址创建到VPC中，并绑定虚拟主机，此虚拟地址才可生效。在物理主机中因为网络不受ECS和VPC控制，所以虚拟地址可以在同网段生效，通过网关配置可以实现跨网段通信，但在ECS中创建的虚拟机因为是软件定义网络，需要先创建VPC专有网络，才能实现通信。按照VPC专有网络配置完后，虚拟地址可正常生效了，上述问题也得到了解决。
通过2天的折腾，发现AI大模型并不是统统是对的，在小众问题中，有可能它给出的方案会误导你去做无用功。在国产化的生态中，厂家的技术支持还是不可或缺的。