Kubernetes学习目录
1、基础知识
1.1、简介
Calico是一个开源的虚拟化网络方案,用于为云原生应用实现互联及策略控制.相较于 Flannel 来
说,Calico 的优势是对网络策略(network policy),它允许用户动态定义 ACL 规则控制进出容器的数据
报文,实现为 Pod 间的通信按需施加安全策略.不仅如此,Calico 还可以整合进大多数具备编排能力的环
境,可以为 虚机和容器提供多主机间通信的功能。
Calico 本身是一个三层的虚拟网络方案,它将每个节点都当作路由器,将每个节点的容器都当作是节点
路由器的一个终端并为其分配一个 IP 地址,各节点路由器通过 BGP(Border Gateway Protocol)学习
生成路由规则,从而将不同节点上的容器连接起来.因此,Calico 方案其实是一个纯三层的解决方案,通过每
个节点协议栈的三层（网络层）确保容器之间的连通性,这摆脱了 flannel host-gw 类型的所有节点必须
位于同一二层网络的限制,从而极大地扩展了网络规模和网络边界。
1.2、官网文档地址
官方地址：https://www.tigera.io/project-calico/
项目地址：https://github.com/projectcalico/calico
当前版本：3.26.0
1.3、网络模型
Calico为了实现更广层次的虚拟网络的应用场景，它支持多种网络模型来满足需求。
underlay network - BGP
overlay network - IPIP、VXLAN
1.4、设计思想
Calico不使用隧道或者NAT来实现转发，而是巧妙的把所有二三层流量转换成三层流量，并通过host上路由配置完成跨host转发。
2、模型简介
2.1、BGP
2.1.1、BGP-简介
BGP(Border Gateway Protocol - 边界网关协议) ，这是一种三层虚拟网络解决方案，也是Calico广为人知的一种网络模型。
它是互联网上一个核心的去中心化自治路由协议。
- 每个工作节点都是一个网络主机边缘节点。
由一个虚拟路由(vrouter)和一系列其他节点组成的一个自治系统(AS)。
- 各个节点上的vrouter基于BGP协议，通过互相学习的方式，动态生成路由规则，实现各节点之间的网络互通性。
BGP不使用传统的内部网关协议(IGP)的指标，而使用基于路径、网络策略或规则集来决定路由规则
它属于矢量路由协议。
这也是很多人从flannel切换到Calico之上的一个重要的考虑因素，VGP是一种纯粹的三层路由解决方案，并没有叠加，而是一种承载网络。
它有点类似于flannel的host-gw模型，但是与host-gw的区别在于，host-gw是由flanneld通过
kube-apiserver来操作etct内部的各种网络配置，进而实时更新到当前节点上的路由表中。
BGP方案中，各节点上的vRouter通过BGP协议学习生成路由表，基于路径、网络策略或规则集来动态生成路由规则
2.1.2、BGP模型划分
BGP模型根据主机容量来划分，可以分层两种网络模型：
小规模网络：BGP peer，以一对多(N-1)的方式，彼此更新网络信息，主机量多的时候，性能不好。因为每个节点都要进行(N-1)的网络信息更新，形成了mesh(网格)的效果
大规模网络：BGP Reflector，他以中央反射器的方式收集所有节点主机的信息，然后将收集后的信息，发布给所有节点，从而减轻集群中的路由同步的报文效率。但是我们需要对中央BGP反射器进行冗余处理。
简单来说，BGP就是通过动态生成的路由表的方式，以类似flannel的host-gw方式，来完成pod之间报文的直接路由，通信效率较高。
它要求所有的节点处于一个二层网络中，同时所有的主机也需要支持BGP协议。
2.1.3、BGP流程图
注意：如果节点是跨网段的话，会因为目标地址找不到，而无法发送数据包
2.2、IPIP
通过把一个IP数据包又套在一个IP包里，即把IP层封装到IP层的一个 tunnel，实现跨网段效果
2.3、VXLAN
2.3.1、vxlan简介
把数据包封装在UDP中，并使用物理网络的IP/MAC作为outer-header进行封装标识，然后在物理IP网上传输，"根据标识"到达目的地后由隧道终结点解封并将数据发送给目标虚拟机。
BGP要求所有的节点处于一个二层网络中，同时所有的主机也需要支持BGP协议。但是一旦我们要构建大
规模的网络集群，比如是一个B类网站，放了很多的节点主机，这个时候，由于网络报文无法被隔离，所以一
旦安全措施做的不到位的话，就会导致广播风暴，对我们产生很大的影响。所以，正常情况下，我们一般不推
荐在一个子网内创建大量的节点主机。所以一旦跨子网，BGP就不支持了。
所以VXLAN就实现了这样一种类似于 flannel的 VXLAN with directrouting的机制，演变出了一种 Vxlan With BGP的效果。
- 如果是同一网段，就使用BGP
- 如果不是同一网段，就用VXLAN机制
2.3.2、vxlan流程图
注意：calico默认的配置清单中，使用的是 IPIP方式，因为它默认节点中不支持BGP协议。
3、工作模型
3.1、前提
如果我们要使用calico的时候，必须要提前将 flannel 功能禁用，然后再安装calico。因为对于k8s来说，cni配置的是谁，他就用谁。
如删除flannel
kubectl delete -f flannel/kube-flannel.yml
3.1、软件架构
3.1.1、安装方式
calico支持的模式很多，但是默认情况下，calico不知道我们的节点是否支持 BGP，所以，默认情况下，
我们在安装calico的时候，它采用的模式是 IPIP模式。如果我们非要使用BGP模型的话，需要自己修改配置
清单文件或者选择适合我们自己的BGP配置。
参考资料： https://docs.projectcalico.org/getting-started/kubernetes/quickstart
3.1.2、Calico-架构图
3.1.3、架构说明
注意：以下三点不是calico的组成部分。
1、每个黑色的背景就是一个边缘自治节点，里面有很多工作中的pod对象
2、每个pod对象不像flannel通过一对虚拟网卡连接到cni0，而是直接连接到内核中。
3、借助于内核中的iptables 和 routers(路由表)来完成转发的功能
3.1.4、关键组件
组件 解析
Felix 每个节点都有，负责配置路由、ACL、向etcd宣告状态等
BIRD 每个节点都有，负责把 Felix 写入Kernel的路由信息 分发到整个Calico网络，确保workload 连通
etcd 存储calico自己的状态数据，可以结合kube-apiserver来工作
RouteReflector 路由反射器，用于集中式的动态生成所有主机的路由表，非必须选项
Calico 编排系统插件 实现更广范围的虚拟网络解决方案。
参考资料：https://docs.projectcalico.org/reference/architecture/overview
3.2、组件解析
由于Calico是一种纯三层的实现，因此可以避免与二层方案相关的数据包封装的操作，中间没有任何的NAT，
没有任何的overlay，所以它的转发效率可能是所有方案中最高的，因为它的包直接走原生TCP/IP的协议
栈，它的隔离也因为这个栈而变得好做。因为TCP/IP的协议栈提供了一整套的防火墙的规则，所以它可以通过IPTABLES的规则达到比较复杂的隔离逻辑。
3.2.1、Calico网络模型主要工作组件 - Felix
运行在每一台host的agent进程，主要负责网络接口管理和监听、路由规划、ARP管理、ACL管理和同步、状
态报告等。Felix会监听Etcd中心的存储，从它获取事件，比如说用户在这台机器上加了一个IP，或者是创
建了一个容器等，用户创建Pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一
条，注明这个IP应该到这张网卡。同样，用户如果制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
注意：这里的策略规则是通过内核的iptables方式实现的
3.2.2、Calico网络模型主要工作组件 - Etcd
分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性，可以与Kubernetes共用。
简单来说：ETCD是所有calico节点的通信总线，也是calico对接到到其他编排系统的通信总线。
官方推荐；
< 50节点,可以结合 kube-apiserver 来实现数据的存储
> 50节点,推荐使用独立的ETCD集群来进行处理。
参考资料：https://docs.projectcalico.org/getting-started/kubernetes/self-managedonprem/onpremises
3.2.3、Calico网络模型主要工作组件 - BIRD
Calico为每一台host部署一个BGP Client，使用BIRD实现，BIRD是一个单独的持续发展的项目，实现了
众多动态路由协议比如：BGP、OSPF、RIP等。在Calico的角色是监听Host上由Felix注入的路由信息，然
后通过BGP协议广播告诉剩余Host节点，从而实现网络互通。BIRD是一个标准的路由程序，它会从内核里面
获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这
个IP在这里，你们路由的时候得到这里来。
3.2.4、Calico网络模型主要工作组件 - Route Reflector
在大型网络规模中，如果仅仅使用BGP Client形成mesh全网互联的方案就会导致规模限制，因为所有节点之
间两两互连，需要N^2个连接，为了解决这个规模问题，可以采用BGP的Route Reflector的方法，使所有
BGP Client仅与特定RR节点互连并做路由同步，从而大大减少连接数。
4、软件部署
4.1、准备工作
4.1.1、部署解析
对于calico在k8s集群上的部署来说，为了完成上面四个组件的部署，这里会涉及到两个部署组件
组件名 组件作用
calico-node 需要部署到所有集群节点上的代理守护进程，提供封装好的Felix和BIRD
calico-kube-controller 专用于k8s上对calico所有节点管理的中央控制器。负责calico与k8s集群的协同及calico核心功能实现。
4.1.2、部署步骤
1、获取资源配置文件
从calico官网获取相关的配置信息
2、定制CIDR配置
定制calico自身对于pod网段的配置信息，并且清理无关的网络其他插件
3、定制pod的manifest文件分配网络配置
默认的k8s集群在启动的时候，会有一个cidr的配置，有可能与calico进行冲突，那么我们需要修改一下
4、应用资源配置文件
4.1.3、注意事项
对于calico来说，它自己会生成自己的路由表，如果路由表中存在响应的记录，默认情况下会直接使
用，而不是覆盖掉当前主机的路由表
所以如果我们在部署calico之前，曾经使用过flannel，尤其是flannel的host-gw模式的话，一定
要注意，在使用calico之前，将之前所有的路由表信息清空，否则无法看到calico的tunl的封装效果。
4.2、环境部署
4.2.1、删除之前布署的flannel
kubectl delete -f flannel/kube-flannel.yml
# 为了确保不受flannel之前多余的路由影响，建议重启一下节点，确保cni0、flannel、flannel.1接口是不存在。
4.2.2、获取资源配置清单
# 建议单独下载
https://github.com/projectcalico/calico/blob/master/manifests/calico.yaml
4.2.3、准备本地镜像
# 查看需要的镜像
]# grep docker.io calico/calico.yaml | uniq
image: docker.io/calico/cni:master
image: docker.io/calico/node:master
image: docker.io/calico/kube-controllers:master
# 准备离线镜像
# 1)、下载node:master
docker pull calico/node:master
docker tag calico/node:master 192.168.10.33:80/k8s/calico/node:master
docker push 192.168.10.33:80/k8s/calico/node:master
# 2)、下载kube-controllers:master
docker pull kube-controllers:master
docker tag calico/kube-controllers:master 192.168.10.33:80/k8s/calico/kube-controllers:master
docker push 192.168.10.33:80/k8s/calico/kube-controllers:master
# 3)、下载cni:master
docker pull cni:master
docker tag calico/cni:master 192.168.10.33:80/k8s/calico/cni:master
docker push 192.168.10.33:80/k8s/calico/cni:master
# 修改下载镜像地址
sed -i 's#docker.io/calico#192.168.10.33:80/k8s/calico#g' calico.yaml
# 修改成功
master1 calico]# grep 'k8s/calico' calico.yaml
image: 192.168.10.33:80/k8s/calico/cni:master
image: 192.168.10.33:80/k8s/calico/cni:master
image: 192.168.10.33:80/k8s/calico/node:master
image: 192.168.10.33:80/k8s/calico/node:master
image: 192.168.10.33:80/k8s/calico/kube-controllers:master
4.2.4、配置CIDR
# 开放默认注释的 CALICO_IPV4POOL_CIDR 变量，然后定制我们当前的pod的网段范围即可
master1 calico]# vi calico.yaml
4800 - name: CALICO_IPV4POOL_CIDR
4801 value: "10.244.0.0/16"
4.2.5、定制pod的manifest文件分配网络配置
# 这里我们直接让calico使用kube-controller-manager为节点分配的网段信
master1 calico]# vi calico.yaml
71 "ipam": {
72 "type": "host-local",
73 "subnet": "usePodCidr"
74 },
4.2.6、应用资源配置清单
kubectl apply -f calico/calico.yaml
4.2.7、检查pod状态
master1 ~]# kubectl -n kube-system get pod -o wide| grep calico
calico-kube-controllers-74846594dd-tt6t8 1/1 Running 0 2m21s 10.244.3.3 node1 <none> <none>
calico-node-2gxlc 1/1 Running 0 2m21s 192.168.10.28 master3 <none> <none>
calico-node-8bjxx 1/1 Running 0 2m21s 192.168.10.27 master2 <none> <none>
calico-node-8gfbc 1/1 Running 0 2m21s 192.168.10.29 node1 <none> <none>
calico-node-dx8zx 1/1 Running 0 2m21s 192.168.10.30 node2 <none> <none>
calico-node-jhshc 1/1 Running 0 2m21s 192.168.10.26 master1 <none> <none>
4.2.8、查看节点主机的进程
node2 ~]# ps -ef | grep calico
root 79038 79036 0 17:27 ? 00:00:00 calico-node -confd
root 79039 79037 0 17:27 ? 00:00:00 calico-node -monitor-token
root 79040 79032 0 17:27 ? 00:00:00 calico-node -allocate-tunnel-addrs
root 79041 79033 0 17:27 ? 00:00:00 calico-node -status-reporter
root 79044 79031 0 17:27 ? 00:00:00 calico-node -monitor-addresses
root 79045 79030 0 17:27 ? 00:00:02 calico-node -felix
root 79477 79035 0 17:27 ? 00:00:00 bird6 -R -s /var/run/calico/bird6.ctl -d -c /etc/calico/confd/config/bird6.cfg
root 79478 79034 0 17:27 ? 00:00:00 bird -R -s /var/run/calico/bird.ctl -d -c /etc/calico/confd/config/bird.cfg
4.2.9、创建pod，验证calico是否生效
]# kubectl create deployment pod-dept --replicas=3 --image=192.168.10.33:80/k8s/pod_test:v0.1
]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-dept-75cb4f74c8-888kd 1/1 Running 0 10s 10.244.4.5 node2 <none> <none>
pod-dept-75cb4f74c8-bklxw 1/1 Running 0 10s 10.244.3.5 node1 <none> <none>
pod-dept-75cb4f74c8-xpd6t 1/1 Running 0 10s 10.244.4.4 node2 <none> <none>
# 暴露一个service
]# kubectl expose deployment pod-dept --port=80 --target-port=80
# 访问测试
]# curl 10.111.204.254
kubernetes pod-test v0.1!! ClientIP: 10.244.137.64, ServerName: pod-dept-75cb4f74c8-888kd, ServerIP: 10.244.4.5!
]# curl 10.111.204.254
kubernetes pod-test v0.1!! ClientIP: 10.244.137.64, ServerName: pod-dept-75cb4f74c8-xpd6t, ServerIP: 10.244.4.4!
]# curl 10.111.204.254
kubernetes pod-test v0.1!! ClientIP: 10.244.137.64, ServerName: pod-dept-75cb4f74c8-bklxw, ServerIP: 10.244.3.5!
5、calico-网络解析
5.1、自动生成一个api版本信息
]# kubectl api-versions | grep crd
crd.projectcalico.org/v1
5.2、自动生成很多api资源
5.2.1、查询生成的资源
]# kubectl api-resources | grep crd.pro
bgpconfigurations crd.projectcalico.org/v1 false BGPConfiguration
bgpfilters crd.projectcalico.org/v1 false BGPFilter
bgppeers crd.projectcalico.org/v1 false BGPPeer
blockaffinities crd.projectcalico.org/v1 false BlockAffinity
caliconodestatuses crd.projectcalico.org/v1 false CalicoNodeStatus
clusterinformations crd.projectcalico.org/v1 false ClusterInformation
felixconfigurations crd.projectcalico.org/v1 false FelixConfiguration
globalnetworkpolicies crd.projectcalico.org/v1 false GlobalNetworkPolicy
globalnetworksets crd.projectcalico.org/v1 false GlobalNetworkSet
hostendpoints crd.projectcalico.org/v1 false HostEndpoint
ipamblocks crd.projectcalico.org/v1 false IPAMBlock
ipamconfigs crd.projectcalico.org/v1 false IPAMConfig
ipamhandles crd.projectcalico.org/v1 false IPAMHandle
ippools crd.projectcalico.org/v1 false IPPool
ipreservations crd.projectcalico.org/v1 false IPReservation
kubecontrollersconfigurations crd.projectcalico.org/v1 false KubeControllersConfiguration
networkpolicies crd.projectcalico.org/v1 true NetworkPolicy
networksets crd.projectcalico.org/v1 true NetworkSet
5.2.2、测试查询ippools资源
]# kubectl get ippools
NAME AGE
default-ipv4-ippool 178m
5.3、查询网络的模型
5.3.1、默认是ipip模型
]# kubectl describe ippools default-ipv4-ippool
Name: default-ipv4-ippool
Namespace:
Labels: <none>
Annotations: projectcalico.org/metadata: {"uid":"1d92a905-4c11-4d84-a53d-4999a4d64666","creationTimestamp":"2023-04-02T09:27:06Z"}
API Version: crd.projectcalico.org/v1
Kind: IPPool
Metadata:
Creation Timestamp: 2023-04-02T09:27:06Z
Generation: 1
Managed Fields:
API Version: crd.projectcalico.org/v1
Fields Type: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.:
f:projectcalico.org/metadata:
f:spec:
.:
f:allowedUses:
f:blockSize:
f:cidr:
f:ipipMode:
f:natOutgoing:
f:nodeSelector:
f:vxlanMode:
Manager: Go-http-client
Operation: Update
Time: 2023-04-02T09:27:06Z
Resource Version: 1194008
UID: ef561fbc-59df-4aae-8d39-21f83dac43da
Spec:
Allowed Uses:
Workload
Tunnel
Block Size: 26
Cidr: 10.244.0.0/16
Ipip Mode: Always
Nat Outgoing: true
Node Selector: all()
Vxlan Mode: Never
Events: <none>
5.3.2、说明
这里的calico采用的模型就是ipip模型，分配的网段是使我们定制的cidr网段，而且子网段也是我们定制的16位掩码。
5.4、查看calico启动后，节点网口的情况
]# ifconfig
tunl0: flags=193<UP,RUNNING,NOARP> mtu 1480
inet 10.244.136.0 netmask 255.255.255.255
master3 ]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.2 0.0.0.0 UG 100 0 0 ens33
10.244.3.2 192.168.10.29 255.255.255.255 UGH 0 0 0 tunl0
10.244.3.3 192.168.10.29 255.255.255.255 UGH 0 0 0 tunl0
10.244.3.4 192.168.10.29 255.255.255.255 UGH 0 0 0 tunl0
10.244.3.5 192.168.10.29 255.255.255.255 UGH 0 0 0 tunl0
10.244.4.2 192.168.10.30 255.255.255.255 UGH 0 0 0 tunl0
10.244.4.3 192.168.10.30 255.255.255.255 UGH 0 0 0 tunl0
10.244.4.4 192.168.10.30 255.255.255.255 UGH 0 0 0 tunl0
10.244.4.5 192.168.10.30 255.255.255.255 UGH 0 0 0 tunl0
10.244.104.0 192.168.10.30 255.255.255.192 UG 0 0 0 tunl0
10.244.136.0 0.0.0.0 255.255.255.192 U 0 0 0 *
10.244.137.64 192.168.10.26 255.255.255.192 UG 0 0 0 tunl0
10.244.166.128 192.168.10.29 255.255.255.192 UG 0 0 0 tunl0
10.244.180.0 192.168.10.27 255.255.255.192 UG 0 0 0 tunl0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.10.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33
环境创建完毕后，会生成一个tunl0的网卡，所有的流量会走这个tunl0网卡
5.5、捉包分析ipip网络模式
5.5.1、node2节点的pod发出一个icmp包
# node2节点的pod发出一个icmp包
master1 ~]# kubectl exec -it pod-dept-75cb4f74c8-888kd -- /bin/sh
[root@pod-dept-75cb4f74c8-888kd /]# ping -c 1 10.244.3.5
5.5.2、分析总结-捉到的包
# 192.168.10.29、192.168.10.30 是node1和node2的物理IP地址
node1 ~]# tcpdump -i ens33 -nn ip host 192.168.10.29 and host 192.168.10.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
20:43:44.424164 IP 192.168.10.30 > 192.168.10.29: IP 10.244.4.5 > 10.244.3.5: ICMP echo request, id 8704, seq 0, length 64 (ipip-proto-4)
20:43:44.424271 IP 192.168.10.29 > 192.168.10.30: IP 10.244.3.5 > 10.244.4.5: ICMP echo reply, id 8704, seq 0, length 64 (ipip-proto-4)
每个数据包都是基于双层ip嵌套的方式来进行传输，而且协议是 ipip-proto-4
结合路由的分发详情，可以看到具体的操作效果。
具体效果：10.244.4.5 -> 192.168.10.30 -> 192.168.10.29 -> 10.244.4.5
6、Calico-BGP网络
6.1、简单介绍
calico本身是一个复杂的系统，复杂到它自己提供一个非常重要的Restful接口，结合calicoctl命
令来管理自身的相关属性信息，calicoctl可以直接与etcd进行操作，也可以通过kube-apiserver的方式
与etcd来进行操作。默认情况下，它与kube-apiserver通信的认证方式与kubectl的命令使用同一个
context。但是我们还是推荐，使用手工定制的一个配置文件。
calicoctl 是运行在集群之外的，用于管理集群功能的一个重要的组件。calicoctl 的安装方式很
多，常见的方式有：单主机方式、kubectl命令插件方式、pod方式、主机容器方式。我们需要自己选择一种适合自己的方式
参考资料：https://docs.projectcalico.org/gettingstarted/clis/calicoctl/install
6.2、calicoctl
6.2.1、安装calicoctl
curl -o /usr/local/bin/calicoctl -O -L https://github.com/projectcalico/calico/releases/download/v3.25.1/calicoctl-linux-amd64
chmod +x /usr/local/bin/calicoctl
# 测试
]# calicoctl ipam show --allow-version-mismatch
+----------+---------------+-----------+------------+--------------+
| GROUPING | CIDR | IPS TOTAL | IPS IN USE | IPS FREE |
+----------+---------------+-----------+------------+--------------+
| IP Pool | 10.244.0.0/16 | 65536 | 5 (0%) | 65531 (100%) |
+----------+---------------+-----------+------------+--------------+
6.2.2、关联kube-apiserver
mkdir /etc/calico
cat >/etc/calico/calicoctl.cfg<<'EOF'
apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
datastoreType: "kubernetes"
kubeconfig: "/etc/kubernetes/admin.conf"
EOF
master1 ~]# calicoctl get nodes --allow-version-mismatch
NAME
master1
master2
master3
node1
node2
我们可以通过 calicoctl 来操作kubectl操作的资源了，只不过显式的格式稍微有一点点的区别.
6.2.3、命令操作
]# calicoctl ipam show --allow-version-mismatch
+----------+---------------+-----------+------------+--------------+
| GROUPING | CIDR | IPS TOTAL | IPS IN USE | IPS FREE |
+----------+---------------+-----------+------------+--------------+
| IP Pool | 10.244.0.0/16 | 65536 | 5 (0%) | 65531 (100%) |
+----------+---------------+-----------+------------+--------------+
]# calicoctl ipam show --show-configuration --allow-version-mismatch
+--------------------+-------+
| PROPERTY | VALUE |
+--------------------+-------+
| StrictAffinity | false |
| AutoAllocateBlocks | true |
| MaxBlocksPerHost | 0 |
+--------------------+-------+
6.2.4、定制kubectl 插件子命令
cp -p /usr/local/bin/calicoctl /usr/local/bin/kubectl-calico
]# kubectl calico node status --allow-version-mismatch
Calico process is running.
IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+---------------+-------------------+-------+----------+-------------+
| 192.168.10.27 | node-to-node mesh | up | 01:31:06 | Established |
| 192.168.10.29 | node-to-node mesh | up | 01:31:06 | Established |
| 192.168.10.30 | node-to-node mesh | up | 01:31:06 | Established |
| 192.168.10.28 | node-to-node mesh | up | 01:31:13 | Established |
+---------------+-------------------+-------+----------+-------------+
IPv6 BGP status
No IPv6 peers found.
6.3、配置BGP网络
6.3.1、修改配置
# 查看ipv4 ippool资源
]# kubectl calico --allow-version-mismatch get ipPools
NAME CIDR SELECTOR
default-ipv4-ippool 10.244.0.0/16 all()
# 导出资源配置文件
]# kubectl calico --allow-version-mismatch get ipPools default-ipv4-ippool -o yaml >calico/default-ipv4-ippool.yml
# 修改资源配置清单
]# cat default-ipv4-ippool.yml
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
name: default-ipv4-ippool
spec:
allowedUses:
- Workload
- Tunnel
blockSize: 26
cidr: 10.244.0.0/16
ipipMode: CrossSubnet
natOutgoing: true
nodeSelector: all()
vxlanMode: Never
主要修改如下：
1、pipMode: Always 修改为 ipipMode: CrossSubnet
这样子就可以实现所谓的 BGP with vxlan的效果
6.3.2、应用资源配置清单
]# kubectl calico --allow-version-mismatch apply -f default-ipv4-ippool.yml
Successfully applied 1 'IPPool' resource(s)
6.3.3、分析节点路由变化
]# ip route list
default via 192.168.10.2 dev ens33 proto static metric 100
blackhole 10.244.0.0/26 proto bird
10.244.1.2 via 192.168.10.27 dev ens33 proto bird
10.244.1.3 via 192.168.10.27 dev ens33 proto bird
10.244.1.4 via 192.168.10.27 dev ens33 proto bird
10.244.2.0/26 via 192.168.10.28 dev ens33 proto bird
10.244.3.0/26 via 192.168.10.29 dev ens33 proto bird
10.244.4.0/26 via 192.168.10.30 dev ens33 proto bird
10.244.180.0/26 via 192.168.10.27 dev ens33 proto bird
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.10.0/24 dev ens33 proto kernel scope link src 192.168.10.26 metric 100
# 更新完毕配置后，动态路由的信息就发生改变了，不再完全是 tunl0 网卡了，而是变成了通过具体的，物理网卡ens33 转发出去了。
6.4、捉包验证
6.4.1、开启deployment控制器 3个pod
master1 ~]# kubectl create deployment dp-test --replicas=3 --image=192.168.10.33:/k8s/pod_test:v0.1
6.4.2、node开启捉包并且发出icmp包验证
master1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
dp-test-55b67b496-c79hd 1/1 Running 0 110m 10.244.3.4 node1 <none> <none>
dp-test-55b67b496-kst8x 1/1 Running 0 110m 10.244.3.5 node1 <none> <none>
dp-test-55b67b496-stffx 1/1 Running 0 110m 10.244.4.3 node2 <none> <none>
master1 ~]# kubectl exec -it dp-test-55b67b496-stffx -- /bin/sh
[root@dp-test-55b67b496-stffx /]# ping -c 1 10.244.3.4
64 bytes from 10.244.3.4: seq=0 ttl=62 time=0.385 ms
# Node1开启捉包
node1 ~]# tcpdump -i ens33 -nn ip host 10.244.3.4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
14:11:14.063730 IP 10.244.4.3 > 10.244.3.4: ICMP echo request, id 5888, seq 0, length 64
14:11:14.063837 IP 10.244.3.4 > 10.244.4.3: ICMP echo reply, id 5888, seq 0, length 64
# 可以实现正常的通信效果，没有再次使用ipip的方式了。
7、BGP reflecter-进阶
7.1、基础知识
7.1.1、查询当前节点的网络情况
master1 ~]# kubectl calico node status
Calico process is running.
IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+---------------+-------------------+-------+----------+-------------+
| 192.168.10.27 | node-to-node mesh | up | 01:31:06 | Established |
| 192.168.10.29 | node-to-node mesh | up | 01:31:06 | Established |
| 192.168.10.30 | node-to-node mesh | up | 01:31:06 | Established |
| 192.168.10.28 | node-to-node mesh | up | 01:31:13 | Established |
+---------------+-------------------+-------+----------+-------------+
IPv6 BGP status
No IPv6 peers found.
当前的calico节点的网络状态是 BGP peer 的模型效果，也就是说 每个节点上都要维护 n-1 个路
由配置信息，整个集群中需要维护 n*(n-1) 个路由效果，这在节点量非常多的场景中，不是我们想要的。
所以我们需要实现一种 BGP reflecter 的效果。
7.1.2、反射器方案
一个集群中，至少需要一个反射器角色。
如果我们要做 BGP reflecter 效果的话，需要对反射器角色做冗余，如果我们的集群是一个多主集群
的话，可以将集群的master节点作为bgp的reflecter角色，从而实现反射器的冗余。
7.1.3、操作步骤
1、定制反射器角色
2、后端节点使用反射器
3、关闭默认的网格效果
7.2、设置为BGP reflecter模型
7.2.1、创建反射器角色
# 定义calico资源配置清单
kubectl calico --allow-version-mismatch apply -f - <<EOF
apiVersion: projectcalico.org/v3
kind: Node
metadata:
labels:
route-reflector: "true"
name: master1
spec:
bgp:
ipv4Address: 192.168.10.26/24
ipv4IPIPTunnelAddr: 10.244.0.1
routeReflectorClusterID: 1.1.1.1
EOF
# Successfully applied 1 'Node' resource(s)
属性解析；
metadata.labels 是非常重要的，因为它需要被后面的节点来进行获取
metadata.name 是通过 calicoctl get nodes 获取到的节点名称。
spec.bgp.ipv4Address 是指定节点的IP地址
spec.bgp.ipv4IPIPTunnelAddr 是指定节点上tunl0的IP地址
spec.bgp.routeReflectorClusterID 是BGP网络中的唯一标识，所以这里的集群标识只要唯一就可以了
7.2.2、将节点的网络模型更换为 reflecter模型
kubectl calico --allow-version-mismatch apply -f - <<EOF
kind: BGPPeer
apiVersion: projectcalico.org/v3
metadata:
name: bgppeer-demo
spec:
nodeSelector: all()
peerSelector: route-reflector=="true"
EOF
属性解析；
spec.nodeSelector 指定的所有后端节点
spec.peerSelector 指定的是反射器的标签，标识所有的后端节点与这个反射器进行数据交流
master1 ~]# kubectl calico get BGPPeer --allow-version-mismatch
NAME PEERIP NODE ASN
bgppeer-demo all() 0
master1 ~]# kubectl calico node status
IPv4 BGP status
+---------------+---------------+-------+----------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+---------------+---------------+-------+----------+-------------+
| 192.168.10.27 | node specific | up | 07:00:30 | Established |
| 192.168.10.28 | node specific | up | 07:00:30 | Established |
| 192.168.10.29 | node specific | up | 07:00:30 | Established |
| 192.168.10.30 | node specific | up | 07:00:30 | Established |
+---------------+---------------+-------+----------+-------------+
这个时候，节点的状态发生了改变,原来是PEER TYPE：node-to-node mesh 现在变成 PEER TYPE: node specific
7.2.3、关闭默认的网格效果
注意:
我使用的版本是Calico Cluster Version: 3.26.0,默认自动会做如下操作
如果node-to-node mesh与node specific并存的时候，请做如下操作：
kubectl calico --allow-version-mismatch apply -f - <<EOF
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
name: default
spec:
logSeverityScreen: Info
nodeToNodeMeshEnabled: false
asNumber: 63400
EOF
# Successfully applied 1 'BGPConfiguration' resource(s)
属性解析；
metadata.name 在这里最好是default，因为我们要对BGP默认的网络效果进行关闭
spec.nodeToNodeMeshEnabled 关闭后端节点的BGP peer默认状态 -- 即点对点通信关闭
spec.asNumber 指定的是后端节点间使用反射器的时候，我们要在一个标志号内，这里随意写一个
# 查看资源运行
master1 ~]# kubectl calico get BGPConfiguration --allow-version-mismatch
NAME LOGSEVERITY MESHENABLED ASNUMBER
default Info false 63400
# 效果如下:
master1 ~]# kubectl calico node status
Calico process is running.
IPv4 BGP status
+---------------+---------------+-------+----------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+---------------+---------------+-------+----------+-------------+
| 192.168.10.27 | node specific | up | 07:08:47 | Established |
| 192.168.10.29 | node specific | up | 07:08:47 | Established |
| 192.168.10.30 | node specific | up | 07:08:47 | Established |
| 192.168.10.28 | node specific | up | 07:08:47 | Established |
+---------------+---------------+-------+----------+-------------+
此时点对点已经没有，剩下反射器模式