Kubernetes(k8s)集群部署七、k8s网络通信+service扩展ingress（TLS，认证，地址重写）calico网络插件（允许指定pod访问服务，禁止其他namespace访问服务）

最新推荐文章于 2025-05-22 10:21:30 发布

ninimino

最新推荐文章于 2025-05-22 10:21:30 发布

阅读量1.2k

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.csdn.net/ninimino/article/details/114303868

k8s网络通信

k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel(只解决网络通信，不能解决网络策略)，calico等。
在这里插入图片描述

CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist
插件使用的解决方案如下：
虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

1.容器间通信

同一个pod内的多个容器间的通信，通过lo即可实现；

2.pod之间的通信

2.1同一节点的pod

之间通过cni网桥转发数据包。

2.2不同节点的pod之间的通信

需要网络插件支持。
Flannel vxlan模式跨主机通信原理
注：图片转载
在这里插入图片描述
通过ip n 看缓存

10.244.0.2—>cni0数据包直接路由–>flannel.1(封装数据包，需要知道对端设备mac:ip n 可以获得并且添加对应的vni)---->再次路由到1上的eth0(fdb获取对端主机ip，arp获取mac)----->根据vni进行相应的vtep设备解包，拿到内部源地址（目标地址）如果目标地址是访问cni的会直接从node2上的flannel.1直接路由到cni,进到对应的容器内部，

如图
src: 10.244.1.1 dst: 10.244.0.1
数据包发送到对端后进行解封，拆成10.244.0.1,数据包到达node1之后，从etho口进去，转发到flannel.1接口上进行解包，10.244.0.1就是自己的段，即成为本地的通信

在node1 flannel.1上封装，看到的地址是172地址的传送，到node2上的flannel.1解封，成目标地址

VXLAN，	即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）。
VTEP	：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。
Cni0	网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。
Flannel.1	: TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。
Flanneld	：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。

flannel网络原理

当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备(隧道)进行处理。
VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址 (ip n)，封装成一个内部数据帧（不能正常进行通信），发送给目的VTEP设备。
内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。获得etho地址
linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。
此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。
bridge fdb转发数据库
每个节点对应不同网络端ip，
arp -n 直接看见缓存

flannel支持多种后端：

Vxlan
    vxlan			//报文封装，默认
    Directrouting		//直接路由，跨网段使用vxlan，同网段使用host-gw模式。
host-gw：		//主机网关，性能好，但只能在二层网络中，不支持跨网络如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP：			//性能差，不推荐

主机网关模式直接通过eth0进行通信，不需要flannel.1

# kubectl -n kube-system edit cm kube-flannel-cfg
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "host-gw"   模式直接在此处修改
      }
    }

修改后需更新
kubectl get pod -n kube-system |grep kube-proxy | awk ‘{system(“kubectl delete pod “$1” -n kube-system”)}’ //更新kube-proxy pod
2
配置flannel：如下，同网段使用直接路由方式，不同网段自己直接使用vxlan

# kubectl -n kube-system edit cm kube-flannel-cfg
net-conf.json: |
 {
   "Network": "10.244.0.0/16",
   "Backend": {
     "Type": "vxlan",
     "Directrouting": true      #直连路由
   }
 }

重载
demo可以直接与另一网段直接通信

3.pod和service通信

*: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。

4.pod和外网通信

*iptables的MASQUERADE。

5.Service与集群外部客户端的通信

（ingress、nodeport、loadbalancer）

ingress

一种全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的Ingress 服务。

Ingress由两部分组成：Ingress controller和Ingress服务。

Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。

注：图片转载

在这里插入图片描述
用户访问ingress controller ,访问内部的svc，
官网：https://kubernetes.github.io/ingress-nginx/

docker pull pollyduan/ingress-nginx-controller:v0.44.0
docker tag pollyduan/ingress-nginx-controller:v0.44.0 reg.westos.org/library/ingress-nginx-controller:v0.44.0
docker push reg.westos.org/library/ingress-nginx-controller:v0.44.0
docker pull jettech/kube-webhook-c