12.基于canel的网络策略

Posted cmxu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了12.基于canel的网络策略相关的知识,希望对你有一定的参考价值。

参考文档: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),但是不允许和外部名称空间之间进行通信。

以上是关于12.基于canel的网络策略的主要内容,如果未能解决你的问题,请参考以下文章

Kubernetes 学习19基于canel的网络策略

精彩论文基于神经网络模型及预测控制DMC的火电机组脱硝控制策略

数据同步神器Canel-day01

手写数字识别——基于全连接层和MNIST数据集

REDIS11_缓存和数据库一致性如何保证解决方案提供Canel解决数据一致性问题

REDIS11_缓存和数据库一致性如何保证解决方案提供Canel解决数据一致性问题