2023年6月29日发(作者:)
⼀图看懂Calico架构原理⼀、Calico简介1. 什么是CalicoCalico是⼀个⽤于容器、虚拟机和基于本地主机的⼯作负载的开源⽹络和⽹络安全解决⽅案。Calico⽀持⼴泛的平台,包括Kubernetes、OpenShift、Docker EE、OpenStack和bare metal服务。Calico将灵活的⽹络功能与随处运⾏的安全实施相结合,提供了⼀个具有本地Linux内核性能和真正的云本地可伸缩性的解决⽅案。2. 为什么使⽤Calico1. 针对⽹络安全的最佳实践Calico丰富的⽹络策略模型使得锁定通信变得很容易,所以唯⼀的流量就是你想要的流量。您可以将Calico的安全增强看作是⽤它⾃⼰的个⼈防⽕墙来包装您的每个⼯作负载,当您部署新服务或将应⽤程序向上或向下扩展时,防⽕墙会实时动态地重新配置。Calico的策略引擎可以在主机⽹络层(如果使⽤Istio & Envoy)和服务⽹格层(如果使⽤Istio & Envoy)执⾏相同的策略模型,保护您的基础设施不受⼯作负载影响。2. 性能Calico使⽤Linux内核内置的⾼度优化的转发和访问控制功能来提供本地Linux⽹络数据平⾯性能,通常不需要任何与第⼀代SDN⽹络相关的encap/decap开销。3. 扩容Calico的核⼼设计原则利⽤了最佳实践的云原⽣设计模式,并结合了全球最⼤的互联⽹运营商所信任的基于标准的⽹络协议。其结果是⼀个具有⾮凡可伸缩性的解决⽅案,多年来⼀直在⽣产中⼤规模运⾏。Calico的开发测试周期包括定期测试数千个节点集群。⽆论您运⾏的是10个节点集群、100个节点集群还是更多,您都可以获得最⼤Kubernetes集群所要求的性能和可伸缩性特性的改进。4. 互操作Calico⽀持Kubernetes⼯作负载和⾮Kubernetes或遗留⼯作负载⽆缝且安全地通信。Kubernetes pods是您⽹络上的⼀等公民,能够与⽹络上的任何其他⼯作负载进⾏通信。此外,Calico可以⽆缝地扩展,以保护与Kubernetes⼀起的现有基于主机的⼯作负载(⽆论是在公共云中,还是在VMs上的on-prem或裸机服务器上)。所有⼯作负载都受制于相同的⽹络策略模型,因此允许流的惟⼀流量就是您希望流的流量。5. 和linux有很多相似之处Calico使⽤现有系统管理员已经熟悉的Linux术语。输⼊您喜欢的Linux⽹络命令,您将得到您期望的结果。在绝⼤多数部署中,离开应⽤程序的包是通过⽹络传输的包,没有封装、隧道或覆盖。系统和⽹络管理员⽤来获得可见性和分析⽹络问题的所有现有⼯具都像现在⼀样⼯作。6. 针对Kubernetes⽹络策略的⽀持Calico的⽹络策略引擎在API的开发过程中形成了Kubernetes⽹络策略的原始参考实现。Calico的独特之处在于它实现了API定义的全部特性,为⽤户提供了API定义时所设想的所有功能和灵活性。对于需要更强⼤功能的⽤户,Calico⽀持⼀组扩展的⽹络策略功能,这些功能与Kubernetes API⼀起⽆缝地⼯作,为⽤户定义⽹络策略提供了更⼤的灵活性。Calico在kubernetes集群中创建和管理⼀个三层的⽹络,该⽹络提供了Pod间的通信。 它为Pods提供了可路由的IP地址,从⽽使互操作性更加容易。Calico允许实施⽹络安全策略,提供对pod之间通信的细粒度控制。⼆、Calico架构1. Calico主要由下列组件组成:calico/node: 该agent作为Calico守护进程的⼀部分运⾏。它管理接⼝,路由和接点的状态报告及强制性策略。BIRD: ⼀个BGP的客户端,由Felix程序⼴播路由。Etcd: ⼀个可选的分布式数据库存储。Calico Controller: Calico策略控制器。1.1 CALICO/NODE:calico/node是⼀个由两个容器组成的Pod1. ⼀个calico/node容器运⾏两个守护进程。a. Felixb. the Bird BGP daemon (optional)2. A calico-CNI插件, 响应来⾃节点上的kubelet的CNI请求。这个Felix组件是Calico⽹络的核⼼。它运⾏在集群中的每个节点上,它主要负责接⼝、路由的管理、状态报告及强制性策略。1.1.1 接⼝和路由的管理Felix守护进程负责编程接⼝并在内核路由表中创建路由,以便在创建pod时为它们提供可路由的IP地址。Felix创建虚拟的⽹络接⼝,并且针对每个pod从Calico IPAM中分配⼀个IP地址。 接⼝⼀般以cali前辍开头,除⾮明确指定1.1.2 状态报告Felix通过监视⼯具(如Prometheus)公开⽤于实例状态报告的度量。1.1.3 强制性策略Felix负责⽹络策略的实施。Felix监视Pod上的标签,并与定义的⽹络策略对象进⾏⽐较,以决定是否允许或拒绝Pod的流量。Felix将有关接⼝及其IP地址和主机⽹络状态的信息写⼊etcd。1.2 BIRDBIRD是⼀个BGP守护进程,它将Felix编写的路由信息分发给集群节点上的其他BIRD代理。BIRD agent是和Calico守护进程的Pod⼀起安装的。这确保了流量是跨节点可路由的。默认情况下,Calico创建⼀个完整的⽹格拓扑。这意味着每个BIRD代理都需要连接到集群中的其他所有BIRD代理。对于较⼤的部署,BIRD可以配置为路由反射器。路由反射器拓扑允许将BIRD设置为其他BIRD代理通信的集中点。它还减少了每个BGP代理打开连接的数量。1.3 ETCDCalico使⽤⼀个称为etcd的分布式数据存储,存储Calico资源配置和⽹络策略规则。Felix守护进程与etcd数据存储进⾏通信,⽤于发布每个节点的路由、节点和接⼝信息。为了获得更⾼的可⽤性,应该为⼤型部署设置多节点etcd集群。在这个设置中,etcd确保在etcd集群中复制Calico配置,使它们始终处于最后已知的良好状态。⼀个可选的部署模型是使⽤Kubernetes API服务器作为分布式数据存储,从⽽消除了构建和维护etcd数据存储的需要。2. calico组件协同⼯作案例演⽰在Kubernetes集群上部署三个nginx pod的⽰例演⽰了这些组件如何协同⼯作以提供⽹络。1. 当⼀个nginx pods调度到kubernetes节点上时,Felix创建⼀个以cali前辍的⽹络虚拟接⼝。并且分配给它⼀个/32的IP地址。$ kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESmy-nginx-5d998f947f-dgmrv 1/1 Running 0 102s 10.244.215.169
10.244.13.64/26 via 192.168.20.116 dev tunl0 proto bird onlink
10.244.106.64/26 via 192.168.20.113 dev tunl0 proto bird onlink
10.244.117.64/26 via 192.168.20.111 dev tunl0 proto bird onlink
10.244.123.128/26 via 192.168.20.112 dev tunl0 proto bird onlink
10.244.213.128/26 via 192.168.20.115 dev tunl0 proto bird onlink
blackhole 10.244.220.64/26 proto bird
10.244.220.76 dev cali791e7a948a6 scope link
10.244.220.77 dev cali1577b57a2a2 scope link
10.244.220.78 dev calib7e5b49a5fc scope link
10.244.220.79 dev cali15c7619fccc scope link
`10.244.220.81 dev cali9ee09c33a93 scope link `3. 查看关于cali9ee09c33a93接⼝的详细信息.[root@c720114 ~]# ip a show dev cali9ee09c33a9313: cali9ee09c33a93@if4:
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 4 inet6 fe80::ecee:eeff:feee:eeee/64 scope link
valid_lft forever preferred_lft forever4. 进⼊它的容器,应该能看到它的Mac地址和第3步显⽰的⼀样。[root@c720111 ~]# kubectl exec -it my-nginx-5d998f947f-vb2jb -- /bin/sh[info]以上证明了calico创建了⽹络接⼝,并分配给Pod⼀个ip地址。5. BIRD BGP守护进程意识到出现了⼀个新的⽹络接⼝,并通知其他节点。我们在其它节点上进⾏查看如下所⽰:ip route showdefault via 192.168.20.1 dev eth0 proto static metric 100
10.244.13.64/26 via 192.168.20.116 dev tunl0 proto bird onlink
10.244.106.64/26 via 192.168.20.113 dev tunl0 proto bird onlink
10.244.117.64/26 via 192.168.20.111 dev tunl0 proto bird onlink
10.244.123.128/26 via 192.168.20.112 dev tunl0 proto bird onlink
blackhole 10.244.213.128/26 proto bird
10.244.213.156 dev cali8739340ad20 scope link
10.244.213.157 dev cali1abad8afd57 scope link
10.244.213.158 dev cali11239f98883 scope link
10.244.213.159 dev cali19a12db9068 scope link
10.244.213.160 dev cali0ff1fd6ec86 scope link
10.244.213.161 dev calibf2f53a4925 scope link
10.244.213.162 dev cali06d2d365420 scope link
10.244.213.163 dev cali2bb02659332 scope link
10.244.213.164 dev calidab80719a39 scope link
`10.244.220.64/26 via 192.168.20.114 dev tunl0 proto bird onlink `172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.115 metric 100
三、Calico⽹络和策略的安装0. 如果安装了flannel,执⾏如下# 删除flannel$ kubectl delete -f /coreos/flannel/master/Documentation/# 在node节点清理flannel⽹络留下的⽂件ifconfig cni0 downip link delete cni0ifconfig flannel.1 downip link delete flannel.1rm -rf /var/lib/cni/rm -f /etc/cni/net.d/*注:执⾏上⾯的操作,重启kubelet# 第三步,应⽤calico相关的yaml⽂件1. 安装的先决条件kube-proxy: 配置为不运⾏ --masquerade-all选项,因为这与Calico冲突。kubelet: 针对⽹络必须配置使⽤CNI插件。--network-plugin=cnikube-proxy: 必须运⾏iptables的代理模式,这是默认选项。2. 执⾏安装Calico是作为kubernetes集群的daemonset进⾏部署的。因此它确保了集群中的每个节点都会安装。1. 针对50个节点或⼩于50个节点的安装⽅法如下:下载⽂件curl /v3.11/manifests/ -O假如使⽤192.168.0.0/16段的⽹络,直接跳过本步骤。假如使⽤别的⽹络,请取代下⾯的192.168.0.0/16POD_CIDR="
发布者:admin,转转请注明出处:http://www.yc00.com/news/1688051203a71135.html
评论列表(0条)