12.基于canel的网络策略

Posted 2020-11-25 cmxu

参考文档：https://docs.projectcalico.org/v3.8/getting-started/kubernetes/

一、Calico作为网络插件提供网络功能

Calico：基于BGP网络协议来通过自动学习判定生成路由条目。

隧道方式：IPIP

路由方式：BGP

默认网段192.168.0.0/16。

二、Calico提供网络策略

1、安装部署

不同环境，使用目的不同，安装方式不同，参考官方文档。

也依赖etcd，可通过api-server去写k8s的etcd，或独立部署一个etcd集群。

当使用flannel提供网络功能，calico提供策略控制时，部署如下：

[root@master ~]# curl https://docs.projectcalico.org/v3.8/manifests/canal.yaml -O
[root@master ~]# kubectl apply -f canal.yaml

2、网络策略控制

网络策略都是针对Pod的入和出，Pod级别。

创建两个namespace -- dev，prod

[root@master ~]# kubectl explain networkpolicy.spec
[root@master ~]# kubectl explain networkpolicy.spec.policyTypes  
　　# 如果不指定此值，并且Ingress,Egress都没有定义规则，则二者都使用默认规则，一般情况下，我们会把默认规则都设置为拒绝。只需要哪一个生效，就必须显式指明，否则都会生效，没有定义策略的情况下会走到默认策略。

（1）设置ingress默认策略

默认ingress策略为拒绝所有入站请求，egress不处理。

 

[root@master networkpolicy]# kubectl apply -f ingress-def.yaml -n dev

测试：

[root@master networkpolicy]# kubectl apply -f pod-demo.yaml  -n dev
[root@master networkpolicy]# kubectl apply -f pod-demo.yaml  -n prod 

 

此时dev名称空间访问不到，但prod可以，因为dev定义了ingress策略。

（2）设置策略为允许所有入站

 

测试：

[root@master networkpolicy]# kubectl apply -f ingress-def.yaml -n dev
[root@master networkpolicy]# curl 10.244.2.2 

（3）指定特定入站访问策略

允许特定网段访问标签为app=myapp的Pod的80,443端口。

[root@master networkpolicy]# kubectl label pods pod1 app=myapp -n dev

[root@master networkpolicy]# kubectl apply -f allow-netpol-demo.yaml -n dev

测试：

 

主机不可达是有问题的，需排查。正常被网络策略限制不可达的情况应该是无响应，挂起。

主机不可达，是因为是两个Pod在同一台节点上。具体原因待查。初步排查：部署canal时，路由被calico改变了，具体问题待确定。

 

（4）问题汇总

问题1：如果设置flannel的后端为Directing的VxLAN，则部署canal时应修改一下配置清单，canal.yaml默认有指定flannel后端为默认的VxLAN，之前的路由会被改变为如上图。

部署时canal.yaml会覆盖部署flannel时的clusterrole.rbac.authorization.k8s.io，删除也是。

问题2：删除重装等各种折腾，会因为之前划分的网络有缓存，出现奇奇怪怪的问题，比如路由表不全导致node不能与Pod通信，解决办法，挨个重启。网络不熟还是不要乱折腾。

[root@node2 ~]# systemctl stop kubelet
[root@node2 ~]# systemctl stop docker
[root@node2 ~]# ifconfig cni0 down
[root@node2 ~]# systemctl start kubelet
[root@node2 ~]# systemctl start docker
[root@node2 ~]# ifconfig cni0 up

并且网络重置后，之前运行的Pod都启动不了，更新不到新的网络（error: unable to upgrade connection: container not found ("myapp")），并且新建pod也是一样，具体报错如下：

解决方案：

莫名其妙自己好了。？？？不清楚什么情况

可能是因为刚开始装过canal，所以在/etc/cni/net.d/目录下有cnnal的配置（10-canal.conflist、calico-kubeconfig），然后集群自己去加载了，在修复过程中，找到了删除了，但是问题还是存在，没立即解决，所以不确定是不是这个问题。

问题3：

相同node的pod间不能通信，不同node的通信没有问题，现象如下：

 

原因分析：出现此现象是在[root@master canal]# kubectl apply -f canal.yaml后，之前创建的Pod在同节点仍然可以通信，但新建的pod如果在同节点就不能通信。初步判断为应用canal.yaml时，改变了集群使用的cni组件（查看新建Pod的详细信息及pod所在主机的路由表可以确认），导致新建的pod使用的网络服务是calico，所以通信存在问题。与问题2类似。具体原因需了解apply具体做了哪些操作。

 

[root@node1 net.d]# cd /etc/cni/net.d/
[root@node1 net.d]#  rm -f 10-canal.conflist calico-kubeconfig

删除所有节点上的canal的配置文件，再次创建Pod，不会出现上述问题。故猜测，是多种网络插件共用导致。部署时未能将两种网络插件分别使用的功能区分开（flannel提供网络服务，用calico提供网络策略），还需好好了解。

3、总结：

为了安全，我们可以设置每个名称空间拒绝所有入站、拒绝所有出站，然后单独放行；

但是这样也会有一个问题，就是同一名称空间的pod也不能通信；

所以还要加条策略就是允许本名称空间的pod之间可以互相通信(放行所有出站目标本名称空间内的所有pod)，但是不允许和外部名称空间之间进行通信。