十四、K8s calico网络的通信及网络策略
K8s网络概述：
前两种情况是在一个主机（Node）中通信，也就是docker里面涉及到的原理，这里不详细探讨。
情况1：一个pod的两个容器之间通信：
情况2：一个Node中的两个pod之间通信：
情况3：不同node之间的pod进行通信：
这种方式实现的方式有：
- 有的基于overlay网络实现；
- 有的基于vxlan实现；
- 有的基于openvswitch实现；
- 有的基于BGP实现。
说到容器就不能不提 CNI，CNI 作为容器网络的统一标准，让各个容器管理平台（k8s,mesos等)都可以通过相同的接口调用各式各样的网络插件（flannel,calico,weave 等）来为容器配置网络。容器管理系统与网络插件之间的关系图如下所示。
网络插件的解决方案：
- flannel—基于overlay 不支持网络策略；
- calico—基于BGP 支持网络策略；
- canal 支持网络策略。
各种网络解决方案的对比：
不管哪种解决方案，每个pod都有独立IP，可以直接通信，只是性能及配置的难易及是否支持网络策略有区别。
一、Calico网络通信原理：
实验环境：
其中，calico是以容器的方式存在。
步骤1： 搭建etcd集群
Calico的信息存储于etcd，首先需要搭建etcd集群。具体步骤请参考：
https://blog.csdn.net/tushanpeipei/article/details/118409836?spm=1001.2014.3001.5501
[root@vms204 ~]# etcdctl member list
193cd579a601f16a: name=etcd-204 peerURLs=http://192.168.0.204:2380 clientURLs=http://192.168.0.204:2379,http://localhost:2379 isLeader=false
591f7e324267e48a: name=etcd-205 peerURLs=http://192.168.0.205:2380 clientURLs=http://192.168.0.205:2379,http://localhost:2379 isLeader=true
步骤2： 安装docker，使用etcd来存储数据
分别设置etcd的地址，存储自己的数据，修改文件/usr/lib/systemd/system/docker.service
，在ExecStart=后加入etcd的内容即可。
[root@vms204 etcd]# vim /usr/lib/systemd/system/docker.service
--cluster-store=etcd://192.168.0.204:2379
[root@vms205 etcd]# vim /usr/lib/systemd/system/docker.service
--cluster-store=etcd://192.168.0.205:2379
在两个设备上restart docker：
systemctl restart etcd
systemctl daemon-reload ; systemctl restart docker
步骤3： 在两台设备上生成Calico的配置文件：
mkdir /etc/calico
进入目录下，创建并编辑calicoctl.cfg文件
[root@vms204 calico]# cat calicoctl.cfg
apiVersion: v1
kind: calicoApiConfig
metadata:
spec:
datastoreType: "etcdv2"
etcdEndpoints: "http://192.168.0.204:2379"
[root@vms205 calico]# cat calicoctl.cfg
apiVersion: v1
kind: calicoApiConfig
metadata:
spec:
datastoreType: "etcdv2"
etcdEndpoints: "http://192.168.0.205:2379"
这里加载calico使用到的相关镜像，地址为：
https://download.csdn.net/download/tushanpeipei/20156748?spm=1001.2014.3001.5501
https://download.csdn.net/download/tushanpeipei/20156723
下载后导入到2台设备中。然后在两台设备上给calicoctl添加权限：
chmod +x calicoctl
mv calicoctl /bin/
在两台设备上加载镜像
[root@vms204 ~]# docker load -i calico-node-v2.tar
df64d3292fd6: Loading layer [==================================================>] 4.672MB/4.672MB
d6f0e85be2d0: Loading layer [==================================================>] 8.676MB/8.676MB
c9818c503193: Loading layer [==================================================>] 250.9kB/250.9kB
1f748fca5871: Loading layer [==================================================>] 4.666MB/4.666MB
714c5990d9e8: Loading layer [==================================================>] 263.9MB/263.9MB
Loaded image: quay.io/calico/node:v2.6.12
[root@vms205 ~]# docker load -i calico-node-v2.tar
df64d3292fd6: Loading layer [==================================================>] 4.672MB/4.672MB
d6f0e85be2d0: Loading layer [==================================================>] 8.676MB/8.676MB
c9818c503193: Loading layer [==================================================>] 250.9kB/250.9kB
1f748fca5871: Loading layer [==================================================>] 4.666MB/4.666MB
714c5990d9e8: Loading layer [==================================================>] 263.9MB/263.9MB
Loaded image: quay.io/calico/node:v2.6.12
步骤4： 建立Calico pod：
calicoctl node run --node-image=quay.io/calico/node:v2.6.12 -c /etc/calico/calicoctl.cfg
查看容器建立情况：
[root@vms204 calico]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9c73a77f26eb quay.io/calico/node:v2.6.12 "start_runit" 49 seconds ago Up 48 seconds calico-node
[root@vms205 calico]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ea8f82ab22bb quay.io/calico/node:v2.6.12 "start_runit" About a minute ago Up About a minute calico-node
查看对方主机的信息：
[root@vms204 calico]# calicoctl node status
Calico process is running.
IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+---------------+-------------------+-------+----------+-------------+
| 192.168.0.205 | node-to-node mesh | up | 08:03:17 | Established |
+---------------+-------------------+-------+----------+-------------+
IPv6 BGP status
No IPv6 peers found.
步骤5： 在任意主机上创建网络（可以同步给远端）
docker network create --driver calico --ipam-driver calico-ipam calnet1
–driver calico 指定使用 calico 的 libnetwork CNM driver。
–ipam-driver calico-ipam 指定使用 calico 的 IPAM driver 管理 IP。
calico 为 global 网络，etcd 会将 calnet1 同步到所有主机。
查看网络建立情况：可以看到创建了一个名为calnet1的网络。
[root@vms204 calico]# docker network list
NETWORK ID NAME DRIVER SCOPE
c21c6b680d2e bridge bridge local
a820a4b2f07d calnet1 calico global
bffc445a376b host host local
4f378dcf68c2 none null local
步骤6： 在两个设备上创建容器，使用calnet1网络，检查是否能够通信
[root@204 calico]# docker run --name c204 --net calnet1 -itd busybox
[root@205 calico]# docker run --name c205 --net calnet1 -itd busybox
进入容器，查看其网卡信息：
[root@vms204 calico]# docker exec -it c204 sh
/ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
4: cali0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.173.0/32 scope global cali0
valid_lft forever preferred_lft forever
[root@vms205 calico]# docker exec -it c205 sh
/ # ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
4: cali0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.242.64/32 scope global cali0
valid_lft forever preferred_lft forever
可以看到两个容器上有一个ali0@if5的网卡。然后查看宿主机的网卡信息：
[root@vms204 calico]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:64:4b:0e brd ff:ff:ff:ff:ff:ff
inet 192.168.0.204/24 brd 192.168.0.255 scope global ens32
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe64:4b0e/64 scope link
valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 02:42:a5:fb:5f:db brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: calibe0de8fc176@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 92:e4:82:9a:33:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::90e4:82ff:fe9a:33b6/64 scope link
valid_lft forever preferred_lft forever
[root@vms205 calico]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:1b:ea:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.0.205/24 brd 192.168.0.255 scope global ens32
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe1b:eaca/64 scope link
valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 02:42:40:b1:a7:b1 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: cali39e20803688@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether ae:5e:a1:f5:f9:c8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::ac5e:a1ff:fef5:f9c8/64 scope link
valid_lft forever preferred_lft forever
可以看到，宿主机上也有一个calico生成的网卡，对比容器内和宿主机的calico网卡，我们可以发现，他们是配对的（if4配对if5，veth pair，可以理解为直连）。
检查两个pod是否能够通信：
[root@vms204 calico]# docker exec -it c204 sh
/ # ping 192.168.242.64
PING 192.168.242.64 (192.168.242.64): 56 data bytes
64 bytes from 192.168.242.64: seq=0 ttl=62 time=0.328 ms
64 bytes from 192.168.242.64: seq=1 ttl=62 time=0.241 ms
64 bytes from 192.168.242.64: seq=2 ttl=62 time=0.216 ms
步骤7： 分析流量转发流程
在vms204的容器中，pingvms205时，首先查看路由表：
/ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0 0 cali0
169.254.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 cali0
可以看到，默认有一条默认路由，出接口为calico创建的接口。因此流量从接口出来，到达此宿主机与之配对的接口，然后再宿主机上查看路由表：
[root@vms204 calico]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ens32
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens32
192.168.173.0 0.0.0.0 255.255.255.255 UH 0 0 0 calibe0de8fc176
192.168.173.0 0.0.0.0 255.255.255.192 U 0 0 0 *
192.168.242.64 192.168.0.205 255.255.255.192 UG 0 0 0 ens32
可以看到其上有一条去玩对端pod 192.168.242.64地址的路由，出接口为ens32，下一跳为192.168.0.205（VMS205的ens32的地址）；由于两个节点是2层通信，不需要在外部再封装IP报头。将目的MAC设置为了VMS205的ens32的MAC地址，然后发送给VMS205。VMS205收到报文后可以看到目地址是192.168.242.64，查看路由表：
[root@vms205 calico]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ens32
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens32
192.168.173.0 192.168.0.204 255.255.255.192 UG 0 0 0 ens32
192.168.242.64 0.0.0.0 255.255.255.255 UH 0 0 0 cali39e20803688
192.168.242.64 0.0.0.0 255.255.255.192 U 0 0 0 *
可以看到，有一条192.168.242.64的路由，出接口为calico接口，流量因此通过宿主机的calico接口发送到了其容器c205中，完成了单向的通信，echo reply报文回程类似。
返回到K8s中：
按照图示部署好了K8s集群，一个Master，两个worker nodes。在master设备上，可以看到如下的pods：
[root@vms201 ~]# kubectl get pods -n kube-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
calico-kube-controllers-78d6f96c7b-h6p86 1/1 Running 16 4d5h 10.244.58.229 vms202.rhce.cc <none> <none>
calico-node-hstwf 1/1 Running 18 8d 192.168.0.201 vms201.rhce.cc <none> <none>
calico-node-ldfhc 1/1 Running 24 8d 192.168.0.203 vms203.rhce.cc <none> <none>
calico-node-sdvzv 1/1 Running 24 8d 192.168.0.202 vms202.rhce.cc <none> <none>
coredns-545d6fc579-596hb 1/1 Running 18 8d 10.244.20.230 vms201.rhce.cc <none> <none>
coredns-545d6fc579-7mb9v 1/1 Running 18 8d 10.244.20.229 vms201.rhce.cc <none> <none>
etcd-vms201.rhce.cc 1/1 Running 21 8d 192.168.0.201 vms201.rhce.cc <none> <none>
kube-apiserver-vms201.rhce.cc 1/1 Running 14 4d2h 192.168.0.201 vms201.rhce.cc <none> <none>
kube-controller-manager-vms201.rhce.cc 1/1 Running 20 8d 192.168.0.201 vms201.rhce.cc <none> <none>
kube-proxy-28x9h 1/1 Running 18 8d 192.168.0.201 vms201.rhce.cc <none> <none>
kube-proxy-7qzdd 1/1 Running 22 8d 192.168.0.202 vms202.rhce.cc <none> <none>
kube-proxy-m9c2c 1/1 Running 25 8d 192.168.0.203 vms203.rhce.cc <none> <none>
kube-scheduler-vms201.rhce.cc 1/1 Running 20 8d 192.168.0.201 vms201.rhce.cc <none> <none>
metrics-server-bcfb98c76-nqc2t 1/1 Running 14 4d5h 10.244.58.237 vms202.rhce.cc <none> <none>
可以看到在每个设备上，都存在一个calico pod，和前面实验中的一样。不过在K8S环境中直接使用calico.yaml来配置calico，保证了K8s中每个Node之间都能够回显通信。
网络策略：
Network Policy是kubernetes中的一种资源类型，它从属于某个namespace。其内容从逻辑上看包含两个关键部分，一是pod选择器，基于标签选择相同namespace下的pod，将其中定义的规则作用于选中的pod。另一个就是规则了，就是网络流量进出pod的规则，其采用的是白名单模式，符合规则的通过，不符合规则的拒绝。
实验概述：
在集群中创建两个pod，分别关联两个SVC，正常情况下，集群外的主机是能够直接访问两个服务的，
步骤1： 使用docker拉取测试使用的镜像
docker pull yauritux/busybox-curl
步骤2： 创建两个pod和SVC
[root@vms201 calico]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
test: pod1
name: pod1
spec:
terminationGracePeriodSeconds: 0
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod1
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@vms201 calico]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 calico]# sed 's/pod1/pod2/' pod1.yaml | kubectl apply -f -
pod/pod2 created
[root@vms201 calico]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod1 1/1 Running 0 30s
pod2 1/1 Running 0 8s
修改nginx的主页，pod1为111，pod2为222：
[root@vms201 calico]# kubectl exec pod1 -- sh -c "echo 111 > /usr/share/nginx/html/index.html"
[root@vms201 calico]# kubectl exec pod2 -- sh -c "echo 222 > /usr/share/nginx/html/index.html"
创建SVC，绑定到pods上：
[root@vms201 ~]# kubectl expose --name=svc1 pod pod1 --port=80 --type=LoadBalancer
service/svc1 exposed
[root@vms201 ~]# kubectl expose --name=svc2 pod pod2 --port=80 --type=LoadBalancer
service/svc2 exposed
[root@vms201 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc1 LoadBalancer 10.107.162.113 192.168.0.240 80:31536/TCP 43s
svc2 LoadBalancer 10.98.23.70 192.168.0.241 80:30992/TCP 29s
创建测试使用的pod：可以看到，目前测试使用的pod能够正常访问两个nginx的pods。
kubectl run testpod --image=docker.io/yauritux/busybox-curl:latest -it --rm --image-pull-policy=IfNotPresent -- sh
/home # curl svc1
111
/home # curl svc2
222
在K8s官网找到网络策略的yaml文件模板进行应用：
https://kubernetes.io/docs/concepts/services-networking/network-policies/
[root@vms201 calico]# cat networkPolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
其中的podSelector表示作用于namespace中的哪个pod，使用标签的方式进行匹配。如果不写的话，表示作用于namespace中的所有pods。
podSelector:
matchLabels:
role: db
policyType有两种，分别表示匹配入方向或者出方向的流量，只有在这里激活了对应的type，后续设置的策略才会生效。
policyTypes:
- Ingress
- Egress
策略：
如下是ingress策略：
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
有三种方式，分别是：
- ipBlock：匹配到的IP地址可以访问，except匹配到的无法访问 ；
- podSelector：指定匹配到label的pod能够访问；
- namespaceSelector：指定命名空间内任何pod能够访问。
其中podSelector默认作用于当前命名空间，如果想要作用于其他命名空间，可以这书写策略：取消掉列表。
- namespaceSelector:
matchLabels:
project: myproject
podSelector:
matchLabels:
role: frontend
egress策略同理。
测试1： 通过ingress策略的podSelector限制testpod无法访问pod1
修改策略文件：
[root@vms201 calico]# cat policy1.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy1
namespace: network
spec:
podSelector:
matchLabels:
test: pod1
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: xxx
ports:
- protocol: TCP
port: 80
作用于network命名空间中的node1，仅运行标签为role: xxx访问，作用的协议是TCP的80号端口。
[root@vms201 calico]# kubectl apply -f policy1.yaml
networkpolicy.networking.k8s.io/test-network-policy1 created
[root@vms201 calico]# kubectl get networkpolicies
NAME POD-SELECTOR AGE
test-network-policy1 test=pod1 37s
应用策略后使用testpod进行验证：
[root@vms201 calico]# kubectl exec -it testpod -- sh
/home # curl svc1
/home # curl svc2
222
可以看到，目前testpod无法访问testpod。
测试完成后删除掉当前策略即可。
测试2： 通过egress策略的ipBlock限制testpod仅能访问通pod1，不能够访问pod2。
策略的yaml文件如下：
[root@vms201 calico]# cat policy2.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy2
spec:
podSelector:
matchLabels:
run: testpod
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: kube-system
ports:
- protocol: UDP
port: 53
- to:
- ipBlock:
cidr: 192.168.0.240/32
ports:
- protocol: TCP
port: 80
作用于testpod上，192.168.0.240为pod1的IP地址。在其中加上namespaceSelector和允许protocol: UDP的原因是让其可以去访问kube-system空间内的DNS服务器，解析SVC的名称。
应用策略并查看结果：
[root@vms201 calico]# kubectl apply -f policy2.yaml
networkpolicy.networking.k8s.io/test-network-policy2 created
[root@vms201 calico]# kubectl get networkpolicies
NAME POD-SELECTOR AGE
test-network-policy2 run=testpod 14s
进入testpod进行查看：
[root@vms201 calico]# kubectl exec -it testpod -- sh
/home # curl svc1
111
/home # curl svc2
默认策略：
默认拒绝所有入站流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
默认允许所有入站流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-ingress
spec:
podSelector: {}
ingress:
- {}
policyTypes:
- Ingress
默认拒绝所有出站流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-egress
spec:
podSelector: {}
policyTypes:
- Egress
默认允许所有出站流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-egress
spec:
podSelector: {}
egress:
- {}
policyTypes:
- Egress
默认拒绝所有入口和所有出站流量：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
参考资料：
《老段CKA课程》