兽性总裁的爱奴,完美世界txt全集下载,有声小说

最近業(yè)界使用范圍最廣的K8S CNI網(wǎng)絡(luò)方案 Calico 宣布支持 eBPF，而作為第一個(gè)通過(guò) eBPF 實(shí)現(xiàn)了 kube-proxy 所有功能的 K8S 網(wǎng)絡(luò)方案——Cilium，它的先見(jiàn)之名是否能轉(zhuǎn)成優(yōu)勢(shì)，繼而成為 CNI 新的頭牌呢？今天我們一起來(lái)入門最 Cool Kubernetes 網(wǎng)絡(luò)方案 Cilium。

Cilium介紹

以下基于 Cilium官網(wǎng)文檔翻譯整理。

當(dāng)前趨勢(shì)

現(xiàn)代數(shù)據(jù)中心的應(yīng)用系統(tǒng)已經(jīng)逐漸轉(zhuǎn)向基于微服務(wù)架構(gòu)的開(kāi)發(fā)體系，一個(gè)微服務(wù)架構(gòu)的應(yīng)用系統(tǒng)是由多個(gè)小的獨(dú)立的服務(wù)組成，它們之間通過(guò)輕量通信協(xié)議如 HTTP、gRPC、Kafka 等進(jìn)行通信。微服務(wù)架構(gòu)下的服務(wù)天然具有動(dòng)態(tài)變化的特點(diǎn)，結(jié)合容器化部署，時(shí)常會(huì)引起大規(guī)模的容器實(shí)例啟動(dòng)或重啟。要確保這種向高度動(dòng)態(tài)化的微服務(wù)應(yīng)用之間的安全可達(dá)，既是挑戰(zhàn)，也是機(jī)遇。

現(xiàn)有問(wèn)題

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

解決方案

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

官方建議所有部署節(jié)點(diǎn)都使用 Linux 最新穩(wěn)定內(nèi)核版本，這樣所有的功能都能啟用，具體部署環(huán)境建議可以參照這里。
作為一個(gè) Kubernetes 網(wǎng)絡(luò)組件，它應(yīng)該在部署 Kubernetes 其他基礎(chǔ)組件之后，才進(jìn)行部署。這里，我自己遇到的問(wèn)題是，因?yàn)檫€沒(méi)有 CNI 插件，coredns 組件的狀態(tài)一直是 pending的，直到部署完 Cilium 后，coredns 完成了重置變成running狀態(tài)。

測(cè)試安裝效果官方提供了一個(gè) connectivity 檢查工具，以檢測(cè)部署好的 Cilium 是否工作正常。如果你的網(wǎng)絡(luò)環(huán)境有些限制，我作了一些簡(jiǎn)單修改，可以參照這里。部署起來(lái)很簡(jiǎn)單，請(qǐng)確保至少有兩個(gè)可用的節(jié)點(diǎn)，否則有幾個(gè) deployment 會(huì)無(wú)法成功運(yùn)行：

>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 都能成功運(yùn)行起來(lái)，說(shuō)明 Cilium 已經(jīng)成功部署并工作正常。網(wǎng)絡(luò)可視化神器 Hubble上文提到了 Cilium 強(qiáng)大之處就是提供了簡(jiǎn)單高效的網(wǎng)絡(luò)可視化功能，它是通過(guò) Hubble組件完成的。Cilium在1.7版本后推出并開(kāi)源了Hubble，它是專門為網(wǎng)絡(luò)可視化設(shè)計(jì)，能夠利用 Cilium 提供的 eBPF 數(shù)據(jù)路徑，獲得對(duì) Kubernetes 應(yīng)用和服務(wù)的網(wǎng)絡(luò)流量的深度可見(jiàn)性。這些網(wǎng)絡(luò)流量信息可以對(duì)接 Hubble CLI、UI 工具，可以通過(guò)交互式的方式快速診斷如與 DNS 相關(guān)的問(wèn)題。除了 Hubble 自身的監(jiān)控工具，還可以對(duì)接主流的云原生監(jiān)控體系—— Prometheus 和 Grafana，實(shí)現(xiàn)可擴(kuò)展的監(jiān)控策略。

部署 Hubble 和 Hubble UI

官方提供了基于 Helm Chart 部署方式，這樣可以靈活控制部署變量，實(shí)現(xiàn)不同監(jiān)控策略。出于想要試用 hubble UI 和對(duì)接 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 #包含兩個(gè)組件 #-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

運(yùn)行效果

由于默認(rèn)的 Hubble UI 只提供了 ClusterIP 類似的 service，無(wú)法通過(guò)外部訪問(wèn)。因此需要?jiǎng)?chuàng)建一個(gè) 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執(zhí)行kubectl apply -f hubble-ui-nodeport-svc.yaml，就可以通過(guò)任意集群節(jié)點(diǎn) IP 地址加上 32321 端口訪問(wèn) Hubble UI 的 web 服務(wù)了。打開(kāi)效果如下所示：

頁(yè)面上半部分是之前部署的一整套 conectivity-check 組件的數(shù)據(jù)流向圖，官方叫做Service Map，默認(rèn)情況下可以自動(dòng)發(fā)現(xiàn)基于網(wǎng)絡(luò) 3 層和 4 層的訪問(wèn)依賴路徑，看上去非常 cool，也有點(diǎn)分布式鏈路追蹤圖的感覺(jué)。點(diǎn)擊某個(gè)服務(wù)，還能看到更為詳細(xì)的關(guān)系圖：

下圖是 kube-system 命名空間下的數(shù)據(jù)流圖，能看到 Hubble-UI 組件和 Hubble 組件是通過(guò)gRPC 進(jìn)行通信的，非常有趣。但令人感到的好奇的是，為何沒(méi)有顯示 Kubernetes 核心組件之間的調(diào)用關(guān)系圖:

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

對(duì)接 Grafana + Prometheus

如果你跟一樣是 Grafana+ Prometheus 的忠實(shí)粉絲，那么使 Hubble 對(duì)接它們就是必然操作了。仔細(xì)的同學(xué)已經(jīng)發(fā)現(xiàn)之前 helm template 的玄機(jī)了：

--setmetrics.enabled="{dns:query;ignoreAAAA;destinationContext=pod-short,drop:sourceContext=pod;destinationContext=pod,tcp,flow,port-distribution,icmp,http}" #上面的設(shè)置，表示開(kāi)啟了 hubble 的 metrics 輸出模式，并輸出以上這些信息。 #默認(rèn)情況下，Hubble daemonset 會(huì)自動(dòng)暴露 metrics API 給 Prometheus。你可以對(duì)接現(xiàn)有的 Grafana+Prometheus 服務(wù)，也可以部署一個(gè)簡(jiǎn)單的：

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

#檢查Cilium對(duì)于取代kube-proxy的狀態(tài) >kubectlexec-it-nkube-system[Cilium-agent-pod]--ciliumstatus|grepKubeProxyReplacement #默認(rèn)是Probe狀態(tài) #當(dāng)Ciliumagent啟動(dòng)并運(yùn)行，它將探測(cè)節(jié)點(diǎn)內(nèi)核版本，判斷BPF內(nèi)核特性的可用性， #如果不滿足，則通過(guò)依賴kube-proxy來(lái)補(bǔ)充剩余的Kubernetess， #并禁用BPF中的一部分功能 KubeProxyReplacement:Probe[NodePort(SNAT,30000-32767),ExternalIPs,HostReachableServices(TCP,UDP)] #查看Cilium保存的應(yīng)用服務(wù)訪問(wèn)列表 #有了這些信息，就不需要kube-proxy進(jìn)行中轉(zhuǎn)了 >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維護(hù)的規(guī)則 >iptables-save|grepKUBE-SVC #說(shuō)明 kube-proxy 沒(méi)有維護(hù)任何應(yīng)用服務(wù)跳轉(zhuǎn)，即可以停止它了。小結(jié)Cilium 作為當(dāng)下最 Cool 的 Kubernetes CNI 網(wǎng)絡(luò)插件，還有很多特性，如高階 network policy、7 層流量控制等，這款基于 BPF/eBPF 打造出的簡(jiǎn)單、高效、易用的網(wǎng)絡(luò)管理體驗(yàn)，有機(jī)會(huì)大家都來(lái)試用吧。

責(zé)任編輯：haq

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題，請(qǐng)聯(lián)系本站處理。舉報(bào)投訴