最近業(yè)界使用范圍最廣的K8S CNI網(wǎng)絡(luò)方案 Calico 宣布支持 eBPF,而作為第一個通過 eBPF 實(shí)現(xiàn)了 kube-proxy 所有功能的 K8S 網(wǎng)絡(luò)方案——Cilium,它的先見之名是否能轉(zhuǎn)成優(yōu)勢,繼而成為 CNI 新的頭牌呢?今天我們一起來入門最 Cool Kubernetes 網(wǎng)絡(luò)方案 Cilium。Cilium介紹
以下基于 Cilium官網(wǎng)文檔翻譯整理。
當(dāng)前趨勢
現(xiàn)代數(shù)據(jù)中心的應(yīng)用系統(tǒng)已經(jīng)逐漸轉(zhuǎn)向基于微服務(wù)架構(gòu)的開發(fā)體系,一個微服務(wù)架構(gòu)的應(yīng)用系統(tǒng)是由多個小的獨(dú)立的服務(wù)組成,它們之間通過輕量通信協(xié)議如 HTTP、gRPC、Kafka 等進(jìn)行通信。微服務(wù)架構(gòu)下的服務(wù)天然具有動態(tài)變化的特點(diǎn),結(jié)合容器化部署,時常會引起大規(guī)模的容器實(shí)例啟動或重啟。要確保這種向高度動態(tài)化的微服務(wù)應(yīng)用之間的安全可達(dá),既是挑戰(zhàn),也是機(jī)遇。現(xiàn)有問題
傳統(tǒng)的 Linux 網(wǎng)絡(luò)訪問安全控制機(jī)制(如 iptables)是基于靜態(tài)環(huán)境的IP地址和端口配置網(wǎng)絡(luò)轉(zhuǎn)發(fā)、過濾等規(guī)則,但是 IP 地址在微服務(wù)架構(gòu)下是不斷變化的,非固定的;出于安全目的,協(xié)議端口(例如 HTTP 傳輸?shù)?TCP 端口 80)也不再固定用來區(qū)分應(yīng)用系統(tǒng)。為了匹配大規(guī)模容器實(shí)例快速變化的生命周期,傳統(tǒng)網(wǎng)絡(luò)技術(shù)需要維護(hù)成千上萬的負(fù)載均衡規(guī)則和訪問控制規(guī)則,并且需要以不斷增長的頻率更新這些規(guī)則,而如果沒有準(zhǔn)確的可視化功能,要維護(hù)這些規(guī)則也是十分困難,這些對傳統(tǒng)網(wǎng)絡(luò)技術(shù)的可用性和性能都是極大的挑戰(zhàn)。比如經(jīng)常會有人對 kube-proxy 基于 iptables 的服務(wù)負(fù)載均衡功能在大規(guī)模容器場景下具有嚴(yán)重的性能瓶頸,同時由于容器的創(chuàng)建和銷毀非常頻繁,基于 IP 做身份關(guān)聯(lián)的故障排除和安全審計(jì)等也很難實(shí)現(xiàn)。解決方案
Cilium 作為一款 Kubernetes CNI 插件,從一開始就是為大規(guī)模和高度動態(tài)的容器環(huán)境而設(shè)計(jì),并且?guī)砹?API 級別感知的網(wǎng)絡(luò)安全管理功能,通過使用基于 Linux 內(nèi)核特性的新技術(shù)——BPF,提供了基于 service/pod/container 作為標(biāo)識,而非傳統(tǒng)的 IP 地址,來定義和加強(qiáng)容器和 Pod 之間網(wǎng)絡(luò)層、應(yīng)用層的安全策略。因此,Cilium 不僅將安全控制與尋址解耦來簡化在高度動態(tài)環(huán)境中應(yīng)用安全性策略,而且提供傳統(tǒng)網(wǎng)絡(luò)第 3 層、4 層隔離功能,以及基于 http 層上隔離控制,來提供更強(qiáng)的安全性隔離。另外,由于 BPF 可以動態(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 非常簡單,可以通過單獨(dú)的 yaml 文件部署全部組件(目前我使用了這個方式部署了1.7.1 版本),也可以通過 helm chart 一鍵完成。重要的是部署環(huán)境和時機(jī):- 官方建議所有部署節(jié)點(diǎn)都使用 Linux 最新穩(wěn)定內(nèi)核版本,這樣所有的功能都能啟用,具體部署環(huán)境建議可以參照這里。
- 作為一個 Kubernetes 網(wǎng)絡(luò)組件,它應(yīng)該在部署 Kubernetes 其他基礎(chǔ)組件之后,才進(jìn)行部署。這里,我自己遇到的問題是,因?yàn)檫€沒有 CNI 插件,coredns 組件的狀態(tài)一直是 pending的,直到部署完 Cilium 后,coredns 完成了重置變成running狀態(tài)。
>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)行起來,說明 Cilium 已經(jīng)成功部署并工作正常。網(wǎng)絡(luò)可視化神器 Hubble上文提到了 Cilium 強(qiáng)大之處就是提供了簡單高效的網(wǎng)絡(luò)可視化功能,它是通過 Hubble組件完成的。Cilium在1.7版本后推出并開源了Hubble,它是專門為網(wǎng)絡(luò)可視化設(shè)計(jì),能夠利用 Cilium 提供的 eBPF 數(shù)據(jù)路徑,獲得對 Kubernetes 應(yīng)用和服務(wù)的網(wǎng)絡(luò)流量的深度可見性。這些網(wǎng)絡(luò)流量信息可以對接 Hubble CLI、UI 工具,可以通過交互式的方式快速診斷如與 DNS 相關(guān)的問題。除了 Hubble 自身的監(jiān)控工具,還可以對接主流的云原生監(jiān)控體系—— Prometheus 和 Grafana,實(shí)現(xiàn)可擴(kuò)展的監(jiān)控策略。
部署 Hubble 和 Hubble UI
官方提供了基于 Helm Chart 部署方式,這樣可以靈活控制部署變量,實(shí)現(xiàn)不同監(jiān)控策略。出于想要試用 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
運(yùn)行效果
由于默認(rèn)的 Hubble UI 只提供了 ClusterIP 類似的 service,無法通過外部訪問。因此需要創(chuàng)建一個 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
,就可以通過任意集群節(jié)點(diǎn) IP 地址加上 32321 端口訪問 Hubble UI 的 web 服務(wù)了。打開效果如下所示:
-
頁面上半部分是之前部署的一整套 conectivity-check 組件的數(shù)據(jù)流向圖,官方叫做
Service Map
,默認(rèn)情況下可以自動發(fā)現(xiàn)基于網(wǎng)絡(luò) 3 層和 4 層的訪問依賴路徑,看上去非常 cool,也有點(diǎn)分布式鏈路追蹤圖的感覺。點(diǎn)擊某個服務(wù),還能看到更為詳細(xì)的關(guān)系圖:
- 下圖是 kube-system 命名空間下的數(shù)據(jù)流圖,能看到 Hubble-UI 組件和 Hubble 組件是通過gRPC 進(jìn)行通信的,非常有趣。但令人感到的好奇的是,為何沒有顯示 Kubernetes 核心組件之間的調(diào)用關(guān)系圖:
對接 Grafana + Prometheus
如果你跟一樣是 Grafana+ Prometheus 的忠實(shí)粉絲,那么使 Hubble 對接它們就是必然操作了。仔細(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è)置,表示開啟了 hubble 的 metrics 輸出模式,并輸出以上這些信息。 #默認(rèn)情況下,Hubble daemonset 會自動暴露 metrics API 給 Prometheus。 你可以對接現(xiàn)有的 Grafana+Prometheus 服務(wù),也可以部署一個簡單的:
#下面的命令會在命名空間cilium-monitoring下部署一個Grafana服務(wù)和Prometheus服務(wù) $kubectlapply-fhttps://raw.githubusercontent.com/cilium/cilium/v1.6/examples/kubernetes/addons/prometheus/monitoring-example.yaml #創(chuàng)建對應(yīng)NodePortService,方便外部訪問web服務(wù) $kubectlexposedeployment/grafana--type=NodePort--port=3000--name=gnp-ncilium-monitoring $kubectlexposedeployment/prometheus--type=NodePort--port=9090--name=pnp-ncilium-monitoring 完成部署后,打開 Grafana 網(wǎng)頁,導(dǎo)入官方制作的 dashboard,可以快速創(chuàng)建基于 Hubble 的 metrics 監(jiān)控。等待一段時間,就能在 Grafana 上看到數(shù)據(jù)了: Cilium 配合 Hubble,的確非常好用!取代 kube-proxy 組件Cilium 另外一個很大的宣傳點(diǎn)是宣稱已經(jīng)全面實(shí)現(xiàn)kube-proxy的功能,包括
ClusterIP
,NodePort
,ExternalIPs
和LoadBalancer
,可以完全取代它的位置,同時提供更好的性能、可靠性以及可調(diào)試性。當(dāng)然,這些都要?dú)w功于 eBPF 的能力。官方文檔中提到,如果你是在先有 kube-proxy 后部署的 Cilium,那么他們是一個 “共存” 狀態(tài),Cilium 會根據(jù)節(jié)點(diǎn)操作系統(tǒng)的內(nèi)核版本來決定是否還需要依賴 kube-proxy 實(shí)現(xiàn)某些功能,可以通過以下手段驗(yàn)證是否能停止 kube-proxy 組件:#檢查Cilium對于取代kube-proxy的狀態(tài) >kubectlexec-it-nkube-system[Cilium-agent-pod]--ciliumstatus|grepKubeProxyReplacement #默認(rèn)是Probe狀態(tài) #當(dāng)Ciliumagent啟動并運(yùn)行,它將探測節(jié)點(diǎn)內(nèi)核版本,判斷BPF內(nèi)核特性的可用性, #如果不滿足,則通過依賴kube-proxy來補(bǔ)充剩余的Kubernetess, #并禁用BPF中的一部分功能 KubeProxyReplacement:Probe[NodePort(SNAT,30000-32767),ExternalIPs,HostReachableServices(TCP,UDP)] #查看Cilium保存的應(yīng)用服務(wù)訪問列表 #有了這些信息,就不需要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
責(zé)任編輯:haq
聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。
舉報(bào)投訴
-
網(wǎng)絡(luò)
+關(guān)注
關(guān)注
14文章
7815瀏覽量
90968 -
容器
+關(guān)注
關(guān)注
0文章
511瀏覽量
22457
原文標(biāo)題:Kubernetes 網(wǎng)絡(luò)方案——炫酷的 Cilium
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
熱點(diǎn)推薦
生產(chǎn)環(huán)境中Kubernetes容器安全的最佳實(shí)踐
隨著容器化技術(shù)的快速發(fā)展,Kubernetes已成為企業(yè)級容器編排的首選平臺。然而,在享受Kubernetes帶來的便利性和可擴(kuò)展性的同時,安全問題也日益凸顯。本文將從運(yùn)維工程師的角度,深入探討生產(chǎn)環(huán)境中Kubernetes容器
k8s網(wǎng)絡(luò)的基本介紹
Kubernetes網(wǎng)絡(luò)是指在Kubernetes集群中不同組件之間進(jìn)行通信和交互的網(wǎng)絡(luò)架構(gòu)。
Kubernetes Helm入門指南
Helm 是 Kubernetes 的包管理工具,它允許開發(fā)者和系統(tǒng)管理員通過定義、打包和部署應(yīng)用程序來簡化 Kubernetes 應(yīng)用的管理工作。Helm 的出現(xiàn)是為了解決在 Kubernetes

樹莓派GUI應(yīng)用開發(fā):從零到炫酷的魔法之旅!
的GUI應(yīng)用開發(fā)有多好玩、多實(shí)用!樹莓派+GUI:不只是“好看”那么簡單!你可能已經(jīng)知道,樹莓派是一款性價比超高的開發(fā)板,但你有沒有想過,給它加上一個炫酷的圖形界

Kubernetes負(fù)載均衡器MetalLB介紹
Kubernetes中一個應(yīng)用服務(wù)會有一個或多個實(shí)例,每個實(shí)例(Pod)的IP地址由網(wǎng)絡(luò)插件動態(tài)隨機(jī)分配(Pod重啟后IP地址會改變)。為屏蔽這些后端實(shí)例的動態(tài)變化和對多實(shí)例的負(fù)載均衡,引入了 Service這個資源對象。

Kubernetes中部署MySQL集群
一般情況下 Kubernetes 可以通過 ReplicaSet 以一個 Pod 模板創(chuàng)建多個 pod 副本,但是它們都是無狀態(tài)的,任何時候它們都可以被一個全新的 pod 替換。

Kubernetes包管理工具Helm的安裝和使用
Helm 可以幫助我們管理 Kubernetes 應(yīng)用程序 - Helm Charts 可以定義、安裝和升級復(fù)雜的 Kubernetes 應(yīng)用程序,Charts 包很容易創(chuàng)建、版本管理、分享和分布。
徹底移除Calico網(wǎng)絡(luò)插件
的CNI接口來允許插件的接入,所以它又稱之為CNI網(wǎng)絡(luò)插件。 為了解決跨主機(jī)容器間通信問題,市面上存在很多解決方案,為了兼容和規(guī)范這些解決方案,Kubernetes僅設(shè)計(jì)了

Kubernetes:構(gòu)建高效的容器化應(yīng)用平臺
Kubernetes 作為容器編排的事實(shí)標(biāo)準(zhǔn),在容器化應(yīng)用部署中發(fā)揮著關(guān)鍵作用。 搭建 Kubernetes 集群是應(yīng)用的基礎(chǔ)。可以使用kubeadm工具快速搭建。在主節(jié)點(diǎn)執(zhí)行kubeadm
使用 Flexus 云服務(wù)器 X 實(shí)例部署 Kubernetes 圖形化管理平臺
Kubernetes 作為當(dāng)今最流行的容器編排平臺,隨著云計(jì)算、微服務(wù)架構(gòu)和 DevOps 文化的普及,Kubernetes 在自動化部署、擴(kuò)展和管理容器化應(yīng)用程序方面扮演著越來越重要的角色。未來

Kubernetes的CNI網(wǎng)絡(luò)插件之flannel
Kubernetes設(shè)計(jì)了網(wǎng)絡(luò)模型,但卻將它的實(shí)現(xiàn)講給了網(wǎng)絡(luò)插件,CNI網(wǎng)絡(luò)插件最重要的功能就是實(shí)現(xiàn)Pod資源能夠跨主機(jī)通信。
艾體寶與Kubernetes原生數(shù)據(jù)平臺AppsCode達(dá)成合作
虹科姐妹公司艾體寶宣布與Kubernetes 原生數(shù)據(jù)平臺 AppsCode達(dá)成正式合作,致力于將其核心產(chǎn)品KubeDB引入中國市場,為企業(yè)提供專業(yè)、高效的云原生數(shù)據(jù)庫管理解決方案。
Kubernetes集群搭建容器云需要幾臺服務(wù)器?
Kubernetes集群搭建容器云需要幾臺服務(wù)器?至少需要4臺服務(wù)器。搭建容器云所需的服務(wù)器數(shù)量以及具體的搭建步驟,會根據(jù)所選用的技術(shù)棧、業(yè)務(wù)規(guī)模、架構(gòu)設(shè)計(jì)以及安全需求等因素而有所不同。以下是一個基于Kubernetes集群的容器云搭建的概述:
評論