10 张图解 K8S CNI Calico 网络模型原理与功能实战
作者:liugp
原文:https://u.kubeinfo.cn/4tRBTb
一、概述
Calico
是一个联网和网络策略供应商。Calico 支持一套灵活的网络选项,因此你可以根据自己的情况选择最有效的选项,包括非覆盖和覆盖网络,带或不带 BGP。Calico 使用相同的引擎为主机、Pod 和(如果使用 Istio 和 Envoy)应用程序在服务网格层执行网络策略。Calico 以其性能、灵活性而闻名。Calico 的功能更为全面,更为复杂。它不仅提供主机和 pod 之间的网络连接,还涉及网络安全和管理。Calico CNI 插件在 CNI(container network interface
)框架内封装了 Calico 的功能。
GitHub 地址:
官方文档:
想了解 flannel 的小伙伴,可以参考这篇文章:Kubernetes(k8s)CNI(flannel)网络模型原理
https://www.cnblogs.com/liugp/p/16388870.html
其它 CNI 插件,可以查看 k8s 官网:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
二、Calico 架构和核心组件
Calico
不使用重叠网络比如 flannel 和 libnetwork 重叠网络驱动,它是一个纯三层的方法,使用虚拟路由代替虚拟交换,每一台虚拟路由通过BGP
协议传播可达信息(路由)到剩余数据中心;Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发,而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息像整个 Calico 网络内传播——小规模部署可以直接互联,大规模下可通过指定的 BGP route reflector 来完成。
Calico 的核心组件:
Felix
:运行在每一台 Host 的 agent 进程,主要负责网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等。etcd
:分布式键值存储,主要负责网络元数据一致性,确保 Calico 网络状态的准确性,可以与 kubernetes 共用;BGP Client(BIRD)
:Calico 为每一台 Host 部署一个 BGP Client,使用 BIRD 实现,BIRD 是一个单独的持续发展的项目,实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 Host 上由 Felix 注入的路由信息,然后通过 BGP 协议广播告诉剩余 Host 节点,从而实现网络互通。BGP Route Reflector
:在大型网络规模中,如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制,因为所有节点之间俩俩互联,需要 N^2 个连接,为了解决这个规模问题,可以采用 BGP 的 Router Reflector 的方法,使所有 BGP Client 仅与特定 RR 节点互联并做路由同步,从而大大减少连接数。
三、什么是 BGP?
边界网关协议(
BGP
)是运行于 TCP 上的一种自治系统的路由协议,也是互联网上一个核心的去中心化自治路由协议。网络可达信息包括列出的自治系统(AS)的信息。这些信息有效地构造了 AS 互联的拓朴图并由此清除了路由环路,同时在 AS 级别上可实施策略决策。在互联网中,一个自治系统(AS)是一个有权自主地决定在本系统中应采用何种路由协议的小型单位。
- BGP 是路由器之间的通信协议,主要用于 AS(AutonomousSystem,自治系统)之间的互联。
- AS 内部有多个 BGP speaker,分为 ibgp、ebgp,ebgp 与其它 AS 中的 ebgp 建立 BGP 连接。
- AS 内部的 BGP speaker 通过 BGP 协议交换路由信息,最终每一个 BGP speaker 拥有整个 AS 的路由信
可以把 calico 中的 node 节点当成一个 AS,而 node 节点中的容器是 AS 中的 router,calico 通过 BGP 解析,将整个网络中容器地址的路由表绘制出来。
IBGP
(Internal BGP):当 BGP 运行于同一自治系统内部时,被称为IBGP
。EBGP
(External BGP):当 BGP 运行于不同自治系统之间时,称为EBGP
。
BGP 两种模式:
全互联模式(node-to-node mesh)
:全互联模式,每一个 BGP Speaker 都需要和其他 BGP Speaker 建立 BGP 连接,这样 BGP 连接总数就是 N^2,如果数量过大会消耗大量连接。如果集群数量超过 100 台官方不建议使用此种模式。路由反射模式Router Reflection(RR)
:RR 模式中会指定一个或多个 BGP Speaker 为 RouterReflection,它与网络中其他 Speaker 建立连接,每个 Speaker 只要与 Router Reflection 建立 BGP 就可以获得全网的路由信息。在 calico 中可以通过 Global Peer 实现 RR 模式。
三、Calico 两种网络模式
1)IPIP 模式
- 从字面来理解,就是把一个 IP 数据包又套在一个 IP 包里,即把 IP 层封装到 IP 层的一个 tunnel,看起来似乎是浪费,实则不然。
- 它的作用其实基本上就相当于一个基于 IP 层的网桥!
- 一般来说,普通的网桥是基于 mac 层的,根本不需 IP,而这个 ipip 则是通过两端的路由做一个 tunnel,把两个本来不通的网络通过点对点连接起来。
- ipip 的源代码在内核 net/ipv4/ipip.c 中可以找到。
在上面的例子中,IP 包进入 IP 隧道设备之后,就会被 Linux 内核的 IPIP 驱动接管。IPIP 驱动会将这个 IP 包直接封装在一个宿主机网络的 IP 包中,如下所示:
2)BGP 模式
- 边界网关协议(Border Gateway Protocol, BGP)是互联网上一个核心的去中心化自治路由协议。
- 它通过维护 IP 路由表或‘前缀’表来实现自治系统(AS)之间的可达性,属于矢量路由协议。
- BGP 不使用传统的内部网关协议(IGP)的指标,而使用基于路径、网络策略或规则集来决定路由。因此,它更适合被称为矢量性协议,而不是路由协议。
- BGP,通俗的讲就是讲接入到机房的多条线路(如电信、联通、移动等)融合为一体,实现多线单 IP,BGP 机房的优点:服务器只需要设置一个 IP 地址,最佳访问路由是由网络上的骨干路由器根据路由跳数与其它技术指标来确定的,不会占用服务器的任何系统。
- BGP 网络相比较 IPIP 网络,最大的不同之处就是没有了隧道设备 tunl0。前面介绍过 IPIP 网络 pod 之间的流量发送 tunl0,然后 tunl0 发送对端设备。BGP 网络中,pod 之间的流量直接从网卡发送目的地,减少了 tunl0 这个环节。
四、安装 Calico 插件
1)通过 helm 安装 Calico
官方文档:
https://projectcalico.docs.tigera.io/getting-started/kubernetes/helm
# 添加源
helm repo add projectcalico https://projectcalico.docs.tigera.io/charts
# helm repo update
# 下载
helm pull projectcalico/tigera-operator --version v3.24.5
# 解压
tar -xf tigera-operator-v3.24.5.tgz
# 安装,默认命名空间:calico-system
helm install calico ./tigera-operator --namespace tigera-operator --create-namespace
# 检查tigera-operator所有资源
kubectl get all -n tigera-operator
2)通过 yaml 文件安装
wget https://docs.projectcalico.org/manifests/calico.yaml
kubectl apply -f calico.yaml
# 查看
kubectl get all -n kube-system|grep calico
3)k8s flannel 网络切换 calico
1、卸载 flannel 插件
### 1、查看已安装flannel信息
cat /etc/cni/net.d/10-flannel.conflist
### 2、删除flannel布署资源
kubectl delete -f kube-flannel.yml
### 3、清除flannel遗留信息,在集群各节点清理flannel网络的残留文件
ifconfig cni0 down
ip link delete cni0
ifconfig flannel.1 down
ip link delete flannel.1
rm -rf /var/lib/cni
rm -rf /etc/cni/net.d
2、开始安装 Calico 插件
# 下载
wget https://docs.projectcalico.org/manifests/calico.yaml
# 安装
kubectl apply -f calico.yaml
# 查看
kubectl get all -n kube-system|grep calico
# 如果节点NotReady,重启以下容器或者kubelet试试
systemctl restart containerd docker
五、网络策略
关于网络策略,可以参考这篇文章:【云原生】k8s 中的 hostNetwork 和 NetworkPolicy(网络策略)讲解与实战操作
六、简单使用
官方文档:
https://projectcalico.docs.tigera.io/security/kubernetes-policy
1)网络策略示例
1、允许来自同一命名空间中的 Pod 的入口流量
允许来自同一命名空间中的 Pod 的入口流量,在以下示例中,传入带有标签的 Pod 的 label color: red
,仅当它们来自 pod 带有 label color: red
,才被允许转到 80 端口。
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-same-namespace
namespace: default
spec:
podSelector:
matchLabels:
color: blue
ingress:
- from:
- podSelector:
matchLabels:
color: red
ports:
- port: 80
2、允许来自不同命名空间中的 Pod 的入口流量
在以下示例中,仅当传入流量来自带有标签 color: red
的 Pod 时,才允许传入流量,在带有标签的命名空间中带有标签shape: square
,在端口上 80.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-same-namespace
namespace: default
spec:
podSelector:
matchLabels:
color: blue
ingress:
- from:
- podSelector:
matchLabels:
color: red
namespaceSelector:
matchLabels:
shape: square
ports:
- port: 80
2)固定 Pod IP
【示例 1】pod
利用注解 cni.projectcalico.org/ipAddrs
# vi fixed-ip-test-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
annotations:
cni.projectcalico.org/ipAddrs: "[\"10.244.1.200\"]"
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
【示例 2】控制器 单 pod
利用注解 cni.projectcalico.org/ipAddrs
# vi fixed-ip-test-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fixed-ip-test
namespace: default
labels:
k8s-app: cloudnativer-test
spec:
replicas: 1
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
selector:
matchLabels:
k8s-app: cloudnativer-test
template:
metadata:
labels:
k8s-app: cloudnativer-test
annotations:
cni.projectcalico.org/ipAddrs: "[\"10.244.1.220\"]"
spec:
containers:
- name: fixed-ip-test
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
【示例 3】控制器 多 pod 固定 IP 池
需要创建额外 IP 池(除了默认 IP 池),利用注解 cni.projectcalico.org/ipv4pools。
这里先安装一个客户端工具calicoctl
wget https://github.com/projectcalico/calico/releases/download/v3.24.5/calicoctl-linux-amd64
mv calicoctl-linux-amd64 /usr/local/bin/calicoctl
chmod +x /usr/local/bin/calicoctl
编排
# vi fixed-ip-test-deployment2.yaml
# apiVersion: projectcalico.org/v3
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
name: new-pool1
spec:
blockSize: 31
cidr: 10.244.3.220/24
ipipMode: Never
natOutgoing: true
---
# apiVersion: projectcalico.org/v3
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
name: new-pool2
spec:
blockSize: 31
cidr: 10.244.4.221/24
ipipMode: Never
natOutgoing: true
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fixed-ip-test2
namespace: default
labels:
k8s-app: cloudnativer-test
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
selector:
matchLabels:
k8s-app: cloudnativer-test
template:
metadata:
labels:
k8s-app: cloudnativer-test
annotations:
# 【注意】不能使用单引号
"cni.projectcalico.org/ipv4pools": "[\"new-pool1\",\"new-pool2\"]"
spec:
containers:
- name: fixed-ip-test
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
查看
# 查看ip池
calicoctl get ippool
kubectl get pods -owide
【温馨提示】要更改用于 Pod 的默认 IP 范围,请修改
calico.yaml
清单文件中CALICO_IPV4POOL_CIDR
部分。
七、Calico VS Flannel
目前比较常用的是
flannel
和calico
,flannel 的功能比较简单,不具备复杂网络的配置能力,不支持网络策略;calico 是比较出色的网络管理插件,单具备复杂网络配置能力的同时,往往意味着本身的配置比较复杂,所以相对而言,比较小而简单的集群使用 flannel,考虑到日后扩容,未来网络可能需要加入更多设备,配置更多策略,则使用 calico 更好。
1)Flannel
- 优势:部署简单,性能一般。
- 劣势:没办法实现固定 IP 的容器漂移,没法做子网隔离,对上层设计依赖程度高,没有 IPAM , IP 地址浪费,对 Docker 启动方法有绑定。
2)Calico
- Calico 还以其先进的网络功能而闻名。网络策略是其最受追捧的功能之一。
- 支持固定 IP 的配置。
- 此外,Calico 还可以与服务网格 Istio 集成,以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略。这意味着用户可以配置强大的规则,描述 Pod 应如何发送和接受流量,提高安全性并控制网络环境。
两个插件使用的都比较广泛,如果需要设置网络策略,规划更复杂的网络,固定 IP 等,就建议使用 Calico;如果只是简单的使用网络插件的通讯功能就选择 Flannel。
关于 Kubernetes(k8s)CNI(Calico)网络模型原理介绍与部署就先到这里了,有疑问的小伙伴,欢迎给我留言,后续会持续更新【云原生+大数据】相关的文章,请小伙伴耐心等待~