亚州人成网在线播放,四虎影视永久在线精品免费,亚洲精品老司机福利在线播放

最近業界使用范圍最廣的K8S CNI網絡方案 Calico 宣布支持 eBPF，而作為第一個通過 eBPF 實現了 kube-proxy 所有功能的 K8S 網絡方案——Cilium，它的先見之名是否能轉成優勢，繼而成為 CNI 新的頭牌呢？今天我們一起來入門最 Cool Kubernetes 網絡方案 Cilium。

Cilium介紹

以下基于 Cilium官網文檔翻譯整理。

當前趨勢

現代數據中心的應用系統已經逐漸轉向基于微服務架構的開發體系，一個微服務架構的應用系統是由多個小的獨立的服務組成，它們之間通過輕量通信協議如 HTTP、gRPC、Kafka 等進行通信。微服務架構下的服務天然具有動態變化的特點，結合容器化部署，時常會引起大規模的容器實例啟動或重啟。要確保這種向高度動態化的微服務應用之間的安全可達，既是挑戰，也是機遇。

現有問題

傳統的 Linux 網絡訪問安全控制機制（如 iptables）是基于靜態環境的IP地址和端口配置網絡轉發、過濾等規則，但是 IP 地址在微服務架構下是不斷變化的，非固定的；出于安全目的，協議端口(例如 HTTP 傳輸的 TCP 端口 80)也不再固定用來區分應用系統。為了匹配大規模容器實例快速變化的生命周期，傳統網絡技術需要維護成千上萬的負載均衡規則和訪問控制規則，并且需要以不斷增長的頻率更新這些規則，而如果沒有準確的可視化功能，要維護這些規則也是十分困難，這些對傳統網絡技術的可用性和性能都是極大的挑戰。比如經常會有人對 kube-proxy 基于 iptables 的服務負載均衡功能在大規模容器場景下具有嚴重的性能瓶頸，同時由于容器的創建和銷毀非常頻繁，基于 IP 做身份關聯的故障排除和安全審計等也很難實現。

解決方案

Cilium 作為一款 Kubernetes CNI 插件，從一開始就是為大規模和高度動態的容器環境而設計，并且帶來了 API 級別感知的網絡安全管理功能，通過使用基于 Linux 內核特性的新技術——BPF，提供了基于 service/pod/container 作為標識，而非傳統的 IP 地址，來定義和加強容器和 Pod 之間網絡層、應用層的安全策略。因此，Cilium 不僅將安全控制與尋址解耦來簡化在高度動態環境中應用安全性策略，而且提供傳統網絡第 3 層、4 層隔離功能，以及基于 http 層上隔離控制，來提供更強的安全性隔離。另外，由于 BPF 可以動態地插入控制 Linux 系統的程序，實現了強大的安全可視化功能，而且這些變化是不需要更新應用代碼或重啟應用服務本身就可以生效，因為 BPF 是運行在系統內核中的。以上這些特性，使 Cilium 能夠在大規模容器環境中也具有高度可伸縮性、可視化以及安全性。部署 Cilium部署 Cilium 非常簡單，可以通過單獨的 yaml 文件部署全部組件（目前我使用了這個方式部署了1.7.1 版本），也可以通過 helm chart 一鍵完成。重要的是部署環境和時機：

官方建議所有部署節點都使用 Linux 最新穩定內核版本，這樣所有的功能都能啟用，具體部署環境建議可以參照這里。
作為一個 Kubernetes 網絡組件，它應該在部署 Kubernetes 其他基礎組件之后，才進行部署。這里，我自己遇到的問題是，因為還沒有 CNI 插件，coredns 組件的狀態一直是 pending的，直到部署完 Cilium 后，coredns 完成了重置變成running狀態。

測試安裝效果官方提供了一個 connectivity 檢查工具，以檢測部署好的 Cilium 是否工作正常。如果你的網絡環境有些限制，我作了一些簡單修改，可以參照這里。部署起來很簡單，請確保至少有兩個可用的節點，否則有幾個 deployment 會無法成功運行：

>kubectlapply-fconnectivity-check.yaml NAMEREADYUP-TO-DATEAVAILABLEAGE echo-a1/11116d echo-b1/11116d host-to-b-multi-node-clusterip1/11116d host-to-b-multi-node-headless1/11116d pod-to-a1/11116d pod-to-a-allowed-cnp1/11116d pod-to-a-external-11111/11116d pod-to-a-l3-denied-cnp1/11116d pod-to-b-intra-node1/11116d pod-to-b-multi-node-clusterip1/11116d pod-to-b-multi-node-headless1/11116d pod-to-external-fqdn-allow-google-cnp1/11116d 如果所有的 deployment 都能成功運行起來，說明 Cilium 已經成功部署并工作正常。網絡可視化神器 Hubble上文提到了 Cilium 強大之處就是提供了簡單高效的網絡可視化功能，它是通過 Hubble組件完成的。Cilium在1.7版本后推出并開源了Hubble，它是專門為網絡可視化設計，能夠利用 Cilium 提供的 eBPF 數據路徑，獲得對 Kubernetes 應用和服務的網絡流量的深度可見性。這些網絡流量信息可以對接 Hubble CLI、UI 工具，可以通過交互式的方式快速診斷如與 DNS 相關的問題。除了 Hubble 自身的監控工具，還可以對接主流的云原生監控體系—— Prometheus 和 Grafana，實現可擴展的監控策略。

部署 Hubble 和 Hubble UI

官方提供了基于 Helm Chart 部署方式，這樣可以靈活控制部署變量，實現不同監控策略。出于想要試用 hubble UI 和對接 Grafana，我是這樣的部署的：

>helmtemplatehubble --namespacekube-system --setmetrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}" --setui.enabled=true >hubble.yaml >kubectlapply-fhubble.yaml #包含兩個組件 #-daemonsethubble #-deploymenthubbleUI >kubectlgetpod-nkube-system|grephubble hubble-67ldp1/1Running021h hubble-f287p1/1Running021h hubble-fxzms1/1Running021h hubble-tlq641/1Running121h hubble-ui-5f9fc85849-hkzkr1/1Running015h hubble-vpxcb1/1Running021h

運行效果

由于默認的 Hubble UI 只提供了 ClusterIP 類似的 service，無法通過外部訪問。因此需要創建一個 NodePort 類型的 service，如下所示：

#hubble-ui-nodeport-svc.yaml kind:Service apiVersion:v1 metadata: namespace:kube-system name:hubble-ui-np spec: selector: k8s-app:hubble-ui ports: -name:http port:12000 nodePort:32321 type:NodePort執行kubectl apply -f hubble-ui-nodeport-svc.yaml，就可以通過任意集群節點 IP 地址加上 32321 端口訪問 Hubble UI 的 web 服務了。打開效果如下所示：

頁面上半部分是之前部署的一整套 conectivity-check 組件的數據流向圖，官方叫做Service Map，默認情況下可以自動發現基于網絡 3 層和 4 層的訪問依賴路徑，看上去非常 cool，也有點分布式鏈路追蹤圖的感覺。點擊某個服務，還能看到更為詳細的關系圖：

下圖是 kube-system 命名空間下的數據流圖，能看到 Hubble-UI 組件和 Hubble 組件是通過gRPC 進行通信的，非常有趣。但令人感到的好奇的是，為何沒有顯示 Kubernetes 核心組件之間的調用關系圖:

頁面的下半部分默認顯示的是對于每條數據流路徑的詳細描述，包括發起請求的 pod 名稱、發起請求的 service 名稱、請求目標的 pod 名稱、請求目標的 service 名稱、目標 IP、目標端口、目標 7 層信息、請求狀態、最后一次查看時間等，如下圖所示：點擊任意一條 flow，可以查看到更多詳細信息：頁面的下半部分可以通過點擊切換成顯示 network policy 模式，列出了當前命名空間下所有的網絡策略：如果想開啟網絡 7 層的可視化觀察，就需要對目標 pod 進行 annotations ，感興趣可以看這里，就不在入門篇詳述了。這樣的網絡可視化是不是你夢寐以求的，絕對能在排查請求調用問題的時候幫上大忙。

對接 Grafana + Prometheus

如果你跟一樣是 Grafana+ Prometheus 的忠實粉絲，那么使 Hubble 對接它們就是必然操作了。仔細的同學已經發現之前 helm template 的玄機了：

--setmetrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}" #上面的設置，表示開啟了 hubble 的 metrics 輸出模式，并輸出以上這些信息。 #默認情況下，Hubble daemonset 會自動暴露 metrics API 給 Prometheus。你可以對接現有的 Grafana+Prometheus 服務，也可以部署一個簡單的：

#下面的命令會在命名空間cilium-monitoring下部署一個Grafana服務和Prometheus服務 $kubectlapply-fhttps://raw.githubusercontent.com/cilium/cilium/v1.6/examples/kubernetes/addons/prometheus/monitoring-example.yaml #創建對應NodePortService，方便外部訪問web服務 $kubectlexposedeployment/grafana--type=NodePort--port=3000--name=gnp-ncilium-monitoring $kubectlexposedeployment/prometheus--type=NodePort--port=9090--name=pnp-ncilium-monitoring 完成部署后，打開 Grafana 網頁，導入官方制作的 dashboard，可以快速創建基于 Hubble 的 metrics 監控。等待一段時間，就能在 Grafana 上看到數據了： Cilium 配合 Hubble，的確非常好用！取代 kube-proxy 組件Cilium 另外一個很大的宣傳點是宣稱已經全面實現kube-proxy的功能，包括ClusterIP,NodePort,ExternalIPs和LoadBalancer，可以完全取代它的位置，同時提供更好的性能、可靠性以及可調試性。當然，這些都要歸功于 eBPF 的能力。官方文檔中提到，如果你是在先有 kube-proxy 后部署的 Cilium，那么他們是一個 “共存” 狀態，Cilium 會根據節點操作系統的內核版本來決定是否還需要依賴 kube-proxy 實現某些功能，可以通過以下手段驗證是否能停止 kube-proxy 組件：

#檢查Cilium對于取代kube-proxy的狀態 >kubectlexec-it-nkube-system[Cilium-agent-pod]--ciliumstatus|grepKubeProxyReplacement #默認是Probe狀態 #當Ciliumagent啟動并運行，它將探測節點內核版本，判斷BPF內核特性的可用性， #如果不滿足，則通過依賴kube-proxy來補充剩余的Kubernetess， #并禁用BPF中的一部分功能 KubeProxyReplacement:Probe[NodePort(SNAT,30000-32767),ExternalIPs,HostReachableServices(TCP,UDP)] #查看Cilium保存的應用服務訪問列表 #有了這些信息，就不需要kube-proxy進行中轉了 >kubectlexec-it-nkube-system[Cilium-agent-pod]--ciliumservicelist IDFrontendServiceTypeBackend 110.96.0.10:53ClusterIP1=>100.64.0.98:53 2=>100.64.3.65:53 210.96.0.10:9153ClusterIP1=>100.64.0.98:9153 2=>100.64.3.65:9153 310.96.143.131:9090ClusterIP1=>100.64.4.100:9090 410.96.90.39:9090ClusterIP1=>100.64.4.100:9090 50.0.0.0:32447NodePort1=>100.64.4.100:9090 610.1.1.179:32447NodePort1=>100.64.4.100:9090 7100.64.0.74:32447NodePort1=>100.64.4.100:9090 810.96.190.1:80ClusterIP 910.96.201.51:80ClusterIP 1010.96.0.1:443ClusterIP1=>10.1.1.171:6443 2=>10.1.1.179:6443 3=>10.1.1.188:6443 1110.96.129.193:12000ClusterIP1=>100.64.4.221:12000 120.0.0.0:32321NodePort1=>100.64.4.221:12000 1310.1.1.179:32321NodePort1=>100.64.4.221:12000 14100.64.0.74:32321NodePort1=>100.64.4.221:12000 1510.96.0.30:3000ClusterIP 1610.96.156.253:3000ClusterIP 17100.64.0.74:31332NodePort 180.0.0.0:31332NodePort 1910.1.1.179:31332NodePort 2010.96.131.215:12000ClusterIP1=>100.64.4.221:12000 #查看iptables是否有kube-proxy維護的規則 >iptables-save|grepKUBE-SVC #說明 kube-proxy 沒有維護任何應用服務跳轉，即可以停止它了。小結Cilium 作為當下最 Cool 的 Kubernetes CNI 網絡插件，還有很多特性，如高階 network policy、7 層流量控制等，這款基于 BPF/eBPF 打造出的簡單、高效、易用的網絡管理體驗，有機會大家都來試用吧。

責任編輯：haq

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。舉報投訴