网站首页 > 技术文章 正文
一、概述
Kubernetes 采用的是基于扁平地址空间的、非NAT的网络模型,每个Pod有自己唯一的IP地址。网络是由CNI(container network interface)插件建立的,而非K8S本身。
二、常见的几种CNI插件介绍
为了使容器之间的通信更加方便,Google 和 CoreOS 主导制定了一个容器网络标准CNI(Conteinre Network Interface) 。
k8s官网:https://kubernetes.io/docs/concepts/cluster-administration/addons/
CNI可允许K8S配置任何CNI插件,常见的CNI插件有以下几种:
1)Flannel(本章讲解)
Flannel是由CoreOS开发的项目,是容器编排系统中最成熟的网络结构示例之一,旨在实现更好的容器间和主机间网络。
与其他方案相比,Flannel相对容易安装和配置。它被打包为单个二进制文件flanneld,许多常见的Kubernetes集群部署工具和许多Kubernetes发行版都可以默认安装Flannel。Flannel可以使用Kubernetes集群的现有etcd集群来使用API存储其状态信息,因此不需要专用的数据存储。
详细参考 https://github.com/coreos/flannel
官网:https://coreos.com/flannel/docs/latest/
文档:https://coreos.com/flannel/docs/latest/kubernetes.html
2)Calico
Calico是Kubernetes生态系统中另一种流行的网络选择,它提供收费的技术支持。虽然Flannel被公认为是最简单的选择,但Calico以其性能、灵活性而闻名。Calico的功能更为全面,更为复杂。它不仅提供主机和pod之间的网络连接,还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能。
详细参考 https://github.com/projectcalico/cni-plugin
3)Romana
Romana是Panic Networks在2016年新提出的开源项目,旨在解决Overlay方案给网络带来的开销。虽然目标和Calico基本一致,但其采取的方法却截然不同,具体项目的发展有待观察。
4)Weave Nets
大家都叫惯了weave,实际上目前该产品的名字叫做Weave Nets。
Weave是由Weaveworks提供的一种插件,它提供的模式是在集群中的节点之间创建网状的overlay网络。与Calico一样,Weave也为Kubernetes集群提供网络策略功能。
三、Flannel 组件的解释
- Cni0:网桥设备,每创建一个pod都会创建一对 veth pair,其中一端是pod中的eth0,另一端是Cni0网桥中的端口 (网卡),Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口(网卡)上,Cni0 设备获得的ip地址是该节 点分配到的网段的第一个地址。
- Flannel.1:overlay网络的设备,用来进行vxlan报文的处理(封包和解包),不同node之间的pod数据流量都从 overlay设备以隧道的形式发送到对端。
Flannel的系统文件及目录
$ find / -name flannel
当前node主机IP地址范围
$ cat /run/flannel/subnet.env
四、Flannel网络通信原理实验
1)同节点Pod之间的通信
在容器启动前,会为容器创建一个虚拟Ethernet接口对,这个接口对类似于管道的两端,其中一端在主机命名空间中,另外一端在容器命名空间中,并命名为eth0。在主机命名空间的接口会绑定到网桥。网桥的地址段会取IP赋值给容器的eth0接口。
【实验】这里利用nodeName特性将Pod调度到相同的node节点上(亲和性),创建两个pod
$ cat >p1.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: nginx
name: p1
namespace: default
spec:
nodeName: k8s-node1
containers:
- image: busybox
name: c1
command:
- "ping"
- "baidu.com"
EOF
$ cat >p2.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: busybox
name: p2
namespace: default
spec:
nodeName: k8s-node1
containers:
- image: busybox
name: c2
command:
- "ping"
- "baidu.com"
EOF
执行
$ kubectl apply -f p1.yaml -f p2.yaml
$ kubectl get pod p{1,2}
$ kubectl get pod p{1,2} -o wide
# p1 ping p2
$ kubectl exec -it p1 -- ping 10.244.1.230
工作流程
1、源容器向目标容器发送数据,数据首先发送给 cni0 网桥
查看路由
$ kubectl exec -it p1 -c c1 -- ip route
$ kubectl exec -it p2 -c c2 -- ip route
2、cni0 网桥接受到数据后,将其转交给 flannel.1 虚拟网卡处理
cni0 收到数据包后,docker0的内核栈处理程序会读取这个数据包的目标地址,根据目标地址将数据包发送给下一个路由节点:
$ ip a
$ ip route
3、flannel.1 接受到数据后,对数据进行封装,并发给宿主机的 ens33,再通过ens33出外网,或者访问不同node节点上的pod
针对相同节点上的pod通信,直接cni0 网桥通信,流程如下图:
2)不同节点Pod之间的通信
【实验】这里利用nodeName特性将Pod调度到不同的node节点上(亲和性),创建两个pod
$ cat >p3.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: nginx
name: p3
namespace: default
spec:
nodeName: k8s-node1
containers:
- image: busybox
name: c3
command:
- "ping"
- "baidu.com"
EOF
$ cat >p4.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
labels:
run: busybox
name: p4
namespace: default
spec:
nodeName: k8s-node2
containers:
- image: busybox
name: c4
command:
- "ping"
- "baidu.com"
EOF
执行
$ kubectl apply -f p3.yaml -f p4.yaml
$ kubectl get pod p{3,4}
$ kubectl get pod p{3,4} -o wide
# p3 ping p4
$ kubectl exec -it p3 -- ping 10.244.1.230
工作流程上面已经讲解了,这里就不重复了。流程如下图:
3)Pod与Service之间的通信
在不同节点上的Pod通信中,我们知道了Pod是以IP地址进行通信,但Kubernetes 的集群中, Pod 可能会频繁的销毁和创建,也就是说 Pod 的 IP 不是固定的。为了解决这个问题,Service 提供了访问 Pod 的抽象层,即为一组功能相同的Pod提供单一不变的接入点资源。无论后端的 Pod 如何变化,Service 都作为稳定的前端对外提供服务。同时,Service 还提供了高可用和负载均衡功能,Service 负责将请求转发给正确的 Pod。
【实验】因为在pod基本上都是由控制器管理,不明白控制器的,可以看我这篇文章:Kubernetes(k8s)五种控制器详解,所以这里就创建Service和Deployment
cat >Service-Deployment-test001.yaml<<EOF
apiVersion: v1
kind: Service
metadata:
name: nginx-svc001
labels:
app: nginx-svc001
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
type: NodePort
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-deployment001
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
EOF
执行
$ kubectl apply -f Service-Deployment-test001.yaml
$ kubectl get pod -o wide|grep nginx-deployment001
$ kubectl get svc nginx-svc001
发现每个node节点上都运行了一个pod,curl验证是否正常访问
$ curl 192.168.0.113:30080
$ ipvsadm -Ln|grep -A10 10.1.35.17
$ ss -tnlp|grep 30080
流程图如下:
关于Kubernetes(k8s)CNI(flannel)网络模型的介绍就先到这里了,有疑问的小伙伴,欢迎给我留言哦~
猜你喜欢
- 2024-10-23 容器工程师:引领容器技术潮流,塑造行业未来!
- 2024-10-23 11张图带你彻底了解Kubernetes架构,绝对要收藏的!
- 2024-10-23 深入理解Kubernetes网络策略 kubernetes的网络方案
- 2024-10-23 Kubernetes 网络、监控技术全面解读
- 2024-10-23 Docker术语大全,建议收藏! docker简单介绍
- 2024-10-23 Cilium eBPF 网络解析 bt文件解析
- 2024-10-23 在生产环境中,阿里云如何构建高性能云原生容器网络?
- 2024-10-23 kubernetes系列教程(十二)详解DaemonSet控制器
- 2024-10-23 kubernetes 集群组件介绍 kubernetes集群搭建
- 2024-10-23 如何做容器化集群管理?保障容器能被有序访问是关键
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)