二、网络 – Cedar-记录日常的小破站

本文最后更新于106 天前，其中的信息可能已经过时，如有错误请发送邮件到big_fw@foxmail.com

Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平的网络空间中，这在 GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes 假定这个网络已经存在。而在私有云里搭建 Kubernetes 集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的 Docker 容器之间的互相访问先打通，然后运行 Kubernetes

Table of Contents

1.flannel 弗兰多

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。而且它还能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内

Flannel简介
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是：

为新加入的Pod分配一个唯一的虚拟IP地址。
为新加入Pod添加路由配置。
实现覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标Pod。
Flannel和ETCD都是CoreOS开发的，因此Flannel使用ETCD存储数据，服务兼容良好。

Flanneld 可以在启动的时候通过配置文件来指定不同的Backend来进行网络通信，目前比较成熟的 Backend 有 vxlan 、 host-gw 以及 UDP 三种方式，通过CNI网络、路由策略、二次封包等基础实现Overlay Network（扁平化网络），数据传输过程对容器应用来说是透明的。

第一步：会在不同的机器上运行一个flanneld的进程
第二步：flanneld会向etcd申请地址，etcd里面会记录被申请的kv结构，就是记录当前的flanneld申请的内网网段和这个flanneld的物理网卡信息
- 就是记录66.11这个地址分配的网段是10.244.0.0的网段，66.12=10.244.1.0
  因为etcd和flanneld都是CoreOS公司开发的
第三步：flanneld会绑定一个网桥，这个网桥就是flannel0，flannel0是cni0的master，就是说flannel0可以捕获cni0获取的数据报文。放在docker里面，cni0就是docker0网桥，可以被flannel0捕获
第四步：eth0就是Pod内部pause容器的veth，其他容器和pause共享网络，可以通过eth0发送接收报文
第五步：数据报文在二次封装的时候，目标地址还是flanneld的地址，端口也是flanneld的端口

flannel的优缺点

flannel实际上是通过udp报文的二次封装，不用tcp是因为tcp有慢启动，而在内网网络中，数据包基本不可能会丢

优点：
    网络逻辑比较清晰
缺点：
    浪费资源比较大
    需要udp二次封装
    需要在内核和用户中反复拷贝，数据包从内核空间到用户空间是通过拷贝实现的（字符界面——网卡，网桥等等），这样使为了内核的安全，拷贝的时候就是间接的验证。

对比：

flannel是简单的，一看就懂，同时排错也是非常简单的，有完整的网络，无加密，抓包就能分析
IPIP模式不容易分析，没有复用到docker0网桥，在内部捕获需要专门找到他外面套的VETH0是哪个才能抓，后期是十分不好排错的

2.calico

calico 是一个纯三层（不再接收到广播信息，直接是包与包的转换）的虚拟网络，它没有复用 docker 的 docker0 网桥，而是自己实现的，calico 网络不对数据包进行额外封装，不需要 NAT 和端口映射

2.1 calico框架

feix： 从etcd中获取信息，然后落实到具体的机器上

BIRD： 上一层级的信息同步是通过Etcd获取的，并且确定是同步的，在feix落实以后，不同的机器之间就通过BIRD来互相同步

2.2 IPIP模式

BGP的优点是可以跨多个数据中心，通过路由器和边界路由网关协议组建成一个超大的虚拟路由器实现路由分发，但是BGP在云环境中是不可用的，因为在云环境中BGP不是想开就开的.比如联通云不支持BGP模式,如果想修改可以更改IPpools资源.

[root@kube-master01 ~]# kubectl get ippools.crd.projectcalico.org
NAME                  AGE
default-ipv4-ippool   508d
[root@kube-master01 ~]# kubectl get ippools.crd.projectcalico.org default-ipv4-ippool -o yaml
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  annotations:
    projectcalico.org/metadata: '{"uid":"3cdeb8f4-5a10-4542-b6ed-4605fe4098bb","creationTimestamp":"2023-02-09T10:37:15Z"}'
  creationTimestamp: "2023-02-09T10:37:44Z"
  generation: 1
  name: default-ipv4-ippool
  resourceVersion: "8122"
  uid: 9fd90a3d-8320-4b11-b359-4e5a8803be25
spec:
  allowedUses:
  - Workload
  - Tunnel
  blockSize: 26
  cidr: 10.43.0.0/16
  ipipMode: Never
  natOutgoing: true
  nodeSelector: all()
  vxlanMode: Never
[root@kube-master01 ~]#

#如果想关闭BGP模式.启用IPIP模式,那么将ipipMode: Never   改为   ipipMode: Always

但是IPIP模式不影响：就是把一个IP报文通过IP报文分发到另一端，是工作在三层的，通过隧道技术（理解为虫洞，不需要知道对方的ip和端口了）进行连接的，缺点就是需要建立大量的虫洞。

TUN隧道是内核支持的，不需要开启，消耗的资源远少于UDP，实际上也是从网卡，交换机，路由器进行传输的，内核功能！！！在建立隧道的时候是需要对方的网卡地址的，一旦写完了网卡地址，当前的linux内核就会出现一个tunl0的接口，只要把数据报文放进去，就能在别的洞口钻出来，就是一个IP套另一个IP，没有别的包头标记了

2.3 通讯模式

同物理机之间不同Pod的通讯

U:Up 表示此路由当前为启动状态
H:Host 表示此网关为一主机
G:Gateway，表示此网关为一路由器

在机器内部会有自己的路由表
记录着想去1.13的话交给网卡calib7ff5c这个网卡，就是交给cali.c2

不同机器之间Pod的通讯

没有在用户空间和内核空间之间反复拷贝！
而且可以做ACL地址控制，限制谁能访问，谁不能访问

3.k8s网络模型

节点网络：物理网卡网络
Pod网络：每个Pod都有自己的独立私有IP地址
Service 网络：负载均衡网络，通过IPVS连接Pod（真实服务器）

4.网络小结

网络
k8s 扁平化的网络

flannel
    UDP 数据报文二次封装
        优点
            实现逻辑清晰，排除简单明了

        缺点
            数据报文需要二次封装并且需要反复在 内核空间与用户空间间发生拷贝

calico
    没有复用 Docker0 网桥

    IPIP
        采用 Linux 内核 IPIP 的隧道实现的

    BGP

网络      扁平化网络
连通性
    pod 内部的不同容器
        lo

    pod 间访问
        同物理机
            flannel 
                基于网桥 Docker0
            calico
                通过 路由 实现的数据报文访问
        跨物理机
            flannel 数据报文二次封装
            calico  采用 Linux 内核 IPIP 的隧道实现的

隔离性
    NS - Network