Kubernetes那点事儿——K8s网络插件calico

K8s网络插件calico

  • 一、两个容器之间网络互通
  • 二、K8s CNI网络模型
    • 1、K8s网络模型
    • 2、CNI网络模型
    • 3、K8s引入插件后的工作过程
    • 4、pause容器
  • 三、Calico网络组件
    • 1、网络模式 overlay ipip
    • 2、网络模式 ubderlay BGP


一、两个容器之间网络互通

Kubernetes那点事儿——K8s网络插件calico_第1张图片

两个容器之间通信存在的问题

  1. 两台docker主机网络是独立
  2. 怎么统一管理多台docker主机的容器ip
  3. 两台docker主机的网段是一个docker内部网络

如果要想将容器1访问容器2,就需要借助宿主机网络。container1 -> host1 <-> host2 -> container2。实现这种跨主机容器通信的技术有:flannel、calico。

二、K8s CNI网络模型

1、K8s网络模型

Kubernetes引入的网络模型提出了下列基本要求。只要满足了这些要求,即可成为一个K8s网络方案供应商。
  1. 每个Pod都有自己单独的IP地址
  2. Pod内部的所有容器共享Pod的IP地址且可以相互自由通信
  3. 一个Node上的容器可以使用IP地址和其它Node上面的容器通信,且不需要通过NAT
  4. 如果Pod使用宿主机网络环境,那么跨Node的容器间可以使用IP地址进行通信,且不需要通过NAT
  5. 一个Node上面的agent(比如system daemon, kubelet等)可以使用IP地址和位于该Node上面的所有容器通信,且不需要通过NAT
  6. Pod之间容器通信所涉及到的隔离问题通过Network policy解决

这种网络模型也被称作为“扁平网络”。

2、CNI网络模型

CNI是Container Network Interface的是一个标准的,通用的接口。现在容器平台:docker,kubernetes,mesos容器网络解决方案:flannel,calico
只要提供一个标准的接口,就能为同样满足该协议的所有容器平台提供网络功能,而CNI正是这样的一个标准接口协议。

K8s内建了一个kubenet,它可以支持一些基本的网络连接。但更普遍的使用方式是用第三方的网络方案。只要它满足CNI(Container Network Interface) 规范就可以以插件的方式在K8s环境使用。

CNI插件的种类多种多样,但关键的功能不外乎以下两个:

  1. 主要负责将Pod插入到K8s网络或从K8s网络删除
  2. IP地址管理(IPAM, IP Address Management)插件,主要负责为Pod分配IP地址,并在Pod被销毁的时候回收IP

3、K8s引入插件后的工作过程

kubernetes 先创建 pause 容器生成对应的 network namespace
调用网络 driver(因为配置的是 CNI,所以会调用 CNI 相关代码)
CNI driver 根据配置调用具体的 cni 插件
cni 插件给 pause 容器配置正确的网络
pod 中的容器都是用 pause 的网络

4、pause容器

负责同一个pod内的容器通信。

每个Pod中都有一个pause容器,pause容器做为Pod的网络接入点,Pod中其他的容器会使用容器映射模式启动并接入到这个pause容器。
属于同一个Pod的所有容器共享网络的namespace。
一个Pod里的容器与另外主机上的Pod容器能够直接通信;
如果Pod所在的Node宕机,会将这个Node上的所有Pod重新调度到其他节点上;

后续我们专门研究pod时,会特别讲到 Infra 容器。

三、Calico网络组件

Calico是一个纯三层的数据中心网络方案,Calico支持广泛的平台,包括Kubernetes、OpenStack等。
Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器(vRouter)来负责数据转发,而每个 vRouter通过 BGP 协议负责
把自己上运行的 workload 的路由信息向整个 Calico 网络内传播。此外,Calico 项目还实现了 Kubernetes 网络策略,提供ACL功能。
podip nodeip clusterip 互相全部打通。

Calico部署:
wget https://docs.projectcalico.org/manifests/calico.yaml
具体的部署过程在上一篇K8s集群搭建中有详细步骤,这里不再赘述。

1、网络模式 overlay ipip

默认网络模式
Kubernetes那点事儿——K8s网络插件calico_第2张图片

把一个IP数据包又套在一个IP包里,即把IP层封装到IP层的一个tunnel,它的作用其实基本上就相当于一个基于IP层的网桥,一般来说,普通的网桥是基于mac层的,根本不需要IP,而这个ipip则是通过两端的路由做一个tunnel,把两个本来不通的网络通过点对点连接起来;
calico以ipip模式部署完毕后,node上会有一个tunnl0的网卡色号被,这是ipip做隧道封装用的,也是一种overlay模式的网络。当我们把节点下线,calico容器都停止后,这个设备依然还在,执行rmmodipip命令可以将它删除。

数据流向

启动两个pod,用busybox去ping nginx

在这里插入图片描述
  
Kubernetes那点事儿——K8s网络插件calico_第3张图片

  1. 查看pod 路由表,默认路由走169.254.1.1。发送arp请求169.254.1.1的mac。arp请求报文会到达calia41be2965e5。
    在这里插入图片描述

  2. icmp请求到达calia41be2965e5, 查找host路由表得知,下一跳为10.7.7.222(node2的ip),并且需要通过tunl0进行隧道封装。封装完ipip,根据外层ip再次查找host路由表,从网卡发送出去

Kubernetes那点事儿——K8s网络插件calico_第4张图片

  1. 封装数据包到达node2后,因为目的ip为local,所以接收此数据包,并向上层协议传递。
    Kubernetes那点事儿——K8s网络插件calico_第5张图片

Kubernetes那点事儿——K8s网络插件calico_第6张图片

  1. 10.244.169.132 根据路由找到calif26605de395,发送到pod

Kubernetes那点事儿——K8s网络插件calico_第7张图片

2、网络模式 ubderlay BGP

修改calico.yaml 关闭ipip模式
Kubernetes那点事儿——K8s网络插件calico_第8张图片Kubernetes那点事儿——K8s网络插件calico_第9张图片

[root@k8s-master ~]# kubectl apply -f calico.yaml 
poddisruptionbudget.policy/calico-kube-controllers configured
serviceaccount/calico-kube-controllers unchanged
serviceaccount/calico-node unchanged
configmap/calico-config unchanged
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/caliconodestatuses.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/ipreservations.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org configured
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org configured
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers unchanged
clusterrole.rbac.authorization.k8s.io/calico-node unchanged
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers unchanged
clusterrolebinding.rbac.authorization.k8s.io/calico-node unchanged
daemonset.apps/calico-node configured
deployment.apps/calico-kube-controllers unchanged

Kubernetes那点事儿——K8s网络插件calico_第10张图片

重建pod后重新观察node节点route

Kubernetes那点事儿——K8s网络插件calico_第11张图片

node2 route对比

Kubernetes那点事儿——K8s网络插件calico_第12张图片

从route信息我们可以看到,BGP模式直接走宿主机网卡,不需要经过隧道,报文直接通过ens33转发到目标机器上,不会进行二次ip报文的封装,因此从性能上来看,BGP肯定是占优势的。但是由于没有二次封包,BGP模式只能在同一个子网内使用,无法跨网段使用。

你可能感兴趣的:(Kubernetes,kubernetes,网络,docker)