flannel调整pod网段，flannel网络

重启虚机后,k8s的kube-apiserver无法正常启动的问题

1、在重启设备后，执行 systemctl status kube-apiserver 命令时，未发现该服务，表明配置文件可能存在错误，因此决定对K8S集群进行重构。在master端检查pod时，发现flannel和coreDNS未启动，容器启动失败。

2、kube-apiserver报错，错误如下：这个错误指明了是与apiserver通信时认证失败造成的，接着就去找哪个组件报错说无法获取apiserver的资源，但是查了kube-controller-manager、kube-scheduler、kube-proxy和kubelet都没有找到相关的错误。

3、为确保API聚合功能在未运行kube-proxy服务的Master节点上正常工作，还需确保kube-apiserver能够访问服务的ClusterIP。这意味着可能需要调整kube-apiserver的启动参数以适应特定的环境需求。在配置完成并重启kube-apiserver后，API聚合功能便得以启用。

4、原因： conntrack表项问题：在K8S环境中，通过NodePort暴露的UDP服务在接收到频繁请求时，由于UDP conntrack表项默认老化时间为30秒，频繁请求可能导致老化失效。当POD重启后，conntrack表中记录的可能是节点IP而非Pod IP，导致后续请求被错误地转发到节点IP而非新的Pod IP。

5、kubeapiserver启动命令参数解释：配置文件路径或网络地址：通常，kubeapiserver的启动命令中会包含指向配置文件的路径，如config参数，用于指定apiserver的配置文件。此外，也可能会有网络地址相关的参数，用于配置集群间的通信或访问。

6、K8S环境下，通过NodePort暴露的UDP服务在Pod重启后出现无法接收数据的问题，引发深入分析。首先，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。

浅谈k8s中cni0和docker0的关系和区别

1、总结来说，cni0和docker0是两个不同的网桥设备，cni0是k8s网络插件的产物，而docker0则主要服务于非k8s容器。理解它们的差异对于深入学习k8s网络至关重要。希望这篇简析能帮助到大家，如需引用，请注明出处。文章来源于渡边灬，原文链接和更多内容可在cnblogs.com/zhangpeiyao...以及jnpfsoft.com/...找到。

2、Flannel在实际部署中为每个Pod分配唯一的IP地址，确保不同节点的subnet互不重叠，实现容器间的直接通信。通过其架构，Flannel实现了Pod之间的互相访问。

3、网络方面，K8s采用了CNI（container network interface）规范。CNI规范简化为三个主要步骤：配置文件指定网络插件，CRI调用插件并传递容器运行时信息，网络插件自行实现网络创建逻辑。这样，K8s能够灵活地接入不同的网络插件，如flannel、calico等，提供丰富的网络解决方案。

k8s网络之flannel(vxlan)

VXLAN（Virtual eXtensible LAN，虚拟可扩展局域网）是一种用于构建overlay网络的虚拟化隧道通信技术。它在三层网络上搭建虚拟二层网络，利用UDP层构建overlay逻辑网络，与物理网络解耦，以满足灵活组网需求。VXLAN不仅适用于虚拟机环境，也适用于容器环境。

Cni0获取的IP地址是该节点分配到的网段的第一个地址，而Flannel.1是overlay网络设备，用于处理VXLAN报文（封装和解包），不同节点间的pod数据流量则通过隧道形式发送到对端。

Flannel是CoreOS团队为kubernetes设计的网络规划服务，其核心功能是为集群中的Docker容器分配全集群唯一的虚拟IP地址，解决不同节点容器可能获得相同内外IP地址的问题。

KubeEdge-Sedna搭建指南--从零开始搭建边云协同应用

KubeEdgeSedna从零开始搭建边云协同应用的指南如下：K8s与容器基础：K8s简介：Kubernetes是容器管理的核心工具，通过弹性分布式系统管理简化应用部署。容器：作为应用程序的轻量级运行环境，容器是K8s的部署单元。

KubeEdge SIG AI持续开放研发成果，致力于提升边缘智能应用在多变环境下的性能与可靠性，通过多任务迁移学习、未知任务的持续学习与改进，以及云侧知识库的支持，构建了一个全面升级的边云协同终身学习框架。