參考文檔：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的网络策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。