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

一、Calico作為網(wǎng)絡(luò)插件提供網(wǎng)絡(luò)功能

Calico：基于BGP網(wǎng)絡(luò)協(xié)議來通過自動學(xué)習(xí)判定生成路由條目。

隧道方式：IPIP

路由方式：BGP

默認(rèn)網(wǎng)段192.168.0.0/16。

二、Calico提供網(wǎng)絡(luò)策略

1、安裝部署

不同環(huán)境，使用目的不同，安裝方式不同，參考官方文檔。

也依賴etcd，可通過api-server去寫k8s的etcd，或獨立部署一個etcd集群。

當(dāng)使用flannel提供網(wǎng)絡(luò)功能，calico提供策略控制時，部署如下：

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

2、網(wǎng)絡(luò)策略控制

網(wǎng)絡(luò)策略都是針對Pod的入和出，Pod級別。

創(chuàng)建兩個namespace -- dev，prod

[root@master ~]# kubectl explain networkpolicy.spec
[root@master ~]# kubectl explain networkpolicy.spec.policyTypes  
　　# 如果不指定此值，并且Ingress,Egress都沒有定義規(guī)則，則二者都使用默認(rèn)規(guī)則，一般情況下，我們會把默認(rèn)規(guī)則都設(shè)置為拒絕。只需要哪一個生效，就必須顯式指明，否則都會生效，沒有定義策略的情況下會走到默認(rèn)策略。

（1）設(shè)置ingress默認(rèn)策略

默認(rèn)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）設(shè)置策略為允許所有入站

測試：

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

（3）指定特定入站訪問策略

允許特定網(wǎng)段訪問標(biāo)簽為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

測試：

主機(jī)不可達(dá)是有問題的，需排查。正常被網(wǎng)絡(luò)策略限制不可達(dá)的情況應(yīng)該是無響應(yīng)，掛起。

主機(jī)不可達(dá)，是因為是兩個Pod在同一臺節(jié)點上。具體原因待查。初步排查：部署canal時，路由被calico改變了，具體問題待確定。

（4）問題匯總

問題1：如果設(shè)置flannel的后端為Directing的VxLAN，則部署canal時應(yīng)修改一下配置清單，canal.yaml默認(rèn)有指定flannel后端為默認(rèn)的VxLAN，之前的路由會被改變?yōu)槿缟蠄D。

部署時canal.yaml會覆蓋部署flannel時的clusterrole.rbac.authorization.k8s.io，刪除也是。

問題2：刪除重裝等各種折騰，會因為之前劃分的網(wǎng)絡(luò)有緩存，出現(xiàn)奇奇怪怪的問題，比如路由表不全導(dǎo)致node不能與Pod通信，解決辦法，挨個重啟。網(wǎng)絡(luò)不熟還是不要亂折騰。

[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

并且網(wǎng)絡(luò)重置后，之前運行的Pod都啟動不了，更新不到新的網(wǎng)絡(luò)（error: unable to upgrade connection: container not found ("myapp")），并且新建pod也是一樣，具體報錯如下：

解決方案：

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

可能是因為剛開始裝過canal，所以在/etc/cni/net.d/目錄下有cnnal的配置（10-canal.conflist、calico-kubeconfig），然后集群自己去加載了，在修復(fù)過程中，找到了刪除了，但是問題還是存在，沒立即解決，所以不確定是不是這個問題。

問題3：

相同node的pod間不能通信，不同node的通信沒有問題，現(xiàn)象如下：

原因分析：出現(xiàn)此現(xiàn)象是在[root@master canal]# kubectl apply -f canal.yaml后，之前創(chuàng)建的Pod在同節(jié)點仍然可以通信，但新建的pod如果在同節(jié)點就不能通信。初步判斷為應(yīng)用canal.yaml時，改變了集群使用的cni組件（查看新建Pod的詳細(xì)信息及pod所在主機(jī)的路由表可以確認(rèn)），導(dǎo)致新建的pod使用的網(wǎng)絡(luò)服務(wù)是calico，所以通信存在問題。與問題2類似。具體原因需了解apply具體做了哪些操作。

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

刪除所有節(jié)點上的canal的配置文件，再次創(chuàng)建Pod，不會出現(xiàn)上述問題。故猜測，是多種網(wǎng)絡(luò)插件共用導(dǎo)致。部署時未能將兩種網(wǎng)絡(luò)插件分別使用的功能區(qū)分開（flannel提供網(wǎng)絡(luò)服務(wù)，用calico提供網(wǎng)絡(luò)策略），還需好好了解。

3、總結(jié)：

為了安全，我們可以設(shè)置每個名稱空間拒絕所有入站、拒絕所有出站，然后單獨放行；

但是這樣也會有一個問題，就是同一名稱空間的pod也不能通信；

所以還要加條策略就是允許本名稱空間的pod之間可以互相通信(放行所有出站目標(biāo)本名稱空間內(nèi)的所有pod)，但是不允許和外部名稱空間之間進(jìn)行通信。

總結(jié)

以上是生活随笔為你收集整理的12.基于canel的网络策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。