k8s中pod间通信（k8s pod completed）
k8s网络之flannel(vxlan)
VXLAN（Virtual eXtensible LAN，虚拟可扩展局域网）是一种用于构建overlay网络的虚拟化隧道通信技术。它在三层网络上搭建虚拟二层网络，利用UDP层构建overlay逻辑网络，与物理网络解耦，以满足灵活组网需求。VXLAN不仅适用于虚拟机环境，也适用于容器环境。
Cni0获取的IP地址是该节点分配到的网段的第一个地址，而Flannel.1是overlay网络设备，用于处理VXLAN报文（封装和解包），不同节点间的pod数据流量则通过隧道形式发送到对端。
Flannel是CoreOS团队为kubernetes设计的网络规划服务，其核心功能是为集群中的Docker容器分配全集群唯一的虚拟IP地址，解决不同节点容器可能获得相同内外IP地址的问题。
速度： calico+ipip flannel+vxlan cilium+vlan 稳定性：cilium+vlan calico+ipip flannel+vxlan calico 作为老牌网络解决方案，可圈可点，已被 GitHub 等公司用于生产。flannel 配置简单，性能弱低于 calico，redis 测试中稍占上风。大并发下稳定性稍低。
K8s网络组件-Calico
Calico是一种高效的容器网络方案，专为k8s等容器化平台设计，旨在实现容器间的高效互通与隔离控制。设计思想与优势： 三层路由转发：Calico不采用隧道或NAT技术，而是将所有二三层流量转换为三层流量，通过主机上的路由配置完成跨主机转发，从而避免了二层广播带来的复杂性和资源开销。
尽管存在挑战，Calico仍以其高效和灵活的优势，在k8s环境中成为容器网络管理的首选之一。其三层路由技术不仅优化了资源利用，还提高了网络的可扩展性和易调试性。通过合理的网络规划和设计，Calico能够克服其面临的挑战，为k8s集群提供稳定、高效的网络解决方案。
速度： calico+ipip flannel+vxlan cilium+vlan 稳定性：cilium+vlan calico+ipip flannel+vxlan calico 作为老牌网络解决方案，可圈可点，已被 github 等公司用于生产。flannel 配置简单，性能弱低于 calico，redis 测试中稍占上风。大并发下稳定性稍低。
浅谈k8s网络之Flannel网络
1、Flannel是CoreOS团队为Kubernetes设计的网络规划服务，其核心功能是为集群中的Docker容器分配全集群唯一的虚拟IP地址，解决不同节点容器可能获得相同内外IP地址的问题。
2、在Kubernetes集群中使用Flannel插件配置VXLAN网络，以实现节点之间的通信。Flannel是Kubernetes的网络插件，本文通过kubeadm工具安装Kubernetes版本19，网络模式设定为VXLAN。Flannel通过下载并配置`flannel.yml`文件进行安装，之后通过检查安装结果来确认配置成功。
3、Flanneld是flannel在每个主机上的agent，负责从集群网络地址空间获取小的子网subnet，为所在主机内所有容器分配IP地址，并监听K8s集群数据库，为flannel.1设备提供封装数据时所需的mac、ip等网络数据信息。当不同节点上的POD通信时，测试集群定义的flannel网络（Pod CIDR）为170.0/16。
4、稳定性：cilium+vlan calico+ipip flannel+vxlan calico 作为老牌网络解决方案，可圈可点，已被 github 等公司用于生产。flannel 配置简单，性能弱低于 calico，redis 测试中稍占上风。大并发下稳定性稍低。cilium 在大并发环境下，稳定性更好，期待后续版本性能有所提升。
5、首先，flannel网络下，k8s不再依赖docker0作为网桥，而是通过Container Network Interface （CNI）插件，其宿主机上的默认名称为cni0。以Flannel的vxlan模式为例，其工作流程中，docker0被cni0所替代，具体流程是：在命令行通过route -n可以看到cni0和docker0是两个不同的设备。
Kubernetes组件之CoreDNS及DNS解析不通问题
解决方案是修改为直接使用全局DNS服务器的IP进行转发，即forward . 200.0.3。通过此方法解决了域名解析不通的问题。为了测试和调试DNS相关问题，提供了一个容器内的测试工具，该工具内置了nslookup工具、curl等常用工具，方便进行DNS排错。以下是用于测试的yaml脚本示例。
默认情况下，Pod DNS 解析请求被发送至 Kubernetes 内的 CoreDNS，这是在高并发环境下 CoreDNS 负载增高的主要原因。CoreDNS 作为灵活可扩展的 DNS 服务器，用于解析内部的 Pod 和 Service 地址，与 Kubernetes 一同托管于 CNCF。
为了彻底解决此问题，必须重新配置集群环境。先执行kubeadm reset命令，然后在master节点上运行新的kubeadm init命令，并正确指定CIDR网段。此操作需根据网络实际情况进行调整，以确保master节点和工作节点与Calico网络插件间的网络隔离。面对复杂的技术问题，耐心和持续的学习是关键。
另一种情况下，服务器重启后仍遇到coredns异常，可能是由于/etc/resolv.conf文件丢失所致。检查pod的日志和dns配置文件，可以发现类似问题。此问题的解决方式与场景一相同，即重新配置/etc/resolv.conf文件。如果coredns部署后状态在CrashLoopBackOff和Error之间不断切换，查看日志会发现coredns无法启动的迹象。
功能：利用CoreDNS的hosts插件，可以在Kubernetes集群内全局劫持某个域名，实现自定义的域名解析。实现方式：通过配置CoreDNS的hosts插件，每隔5秒重新加载解析信息。当需要解析的域名不在hosts配置中时，可以使用fallthrough继续将请求转发给其他插件处理。支持SRV记录：功能：SRV记录用于指定服务器提供服务的位置。
在Kubernetes（K8s）集群中，CoreDNS是一个关键组件，它负责服务发现和域名解析等功能。当遇到域名解析失败或超时等问题时，需要采取措施进行监控和告警。为实现对CoreDNS服务的监控，可使用CCE集群插件kube-prometheus-stack。它能收集并提供仪表盘视图，帮助实时监控CoreDNS的各项运行指标，确保服务健康运行。
