国产亚州精品女人久久久久久_欧美日韩国产精品中文_亚洲av日韩av永久在线观看_欧美激性欧美激情在线户外_国产黄片久久三级_一级特黄性色生活片免费_非洲人粗长硬配种视频_香蕉国产精品偷在线观_日韩少妇无码一区二区三区

最近業(yè)界使用范圍最廣的K8S CNI網(wǎng)絡(luò)方案 Calico 宣布支持 eBPF，而作為第一個通過 eBPF 實現(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)是由多個小的獨立的服務(wù)組成，它們之間通過輕量通信協(xié)議如 HTTP、gRPC、Kafka 等進(jìn)行通信。微服務(wù)架構(gòu)下的服務(wù)天然具有動態(tài)變化的特點，結(jié)合容器化部署，時常會引起大規(guī)模的容器實例啟動或重啟。要確保這種向高度動態(tài)化的微服務(wù)應(yīng)用之間的安全可達(dá)，既是挑戰(zhàn)，也是機遇。

現(xiàn)有問題

傳統(tǒng)的 Linux 網(wǎng)絡(luò)訪問安全控制機制（如 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ī)模容器實例快速變化的生命周期，傳統(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)的故障排除和安全審計等也很難實現(xiàn)。

解決方案

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

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

測試安裝效果官方提供了一個 connectivity 檢查工具，以檢測部署好的 Cilium 是否工作正常。如果你的網(wǎng)絡(luò)環(huán)境有些限制，我作了一些簡單修改，可以參照這里。部署起來很簡單，請確保至少有兩個可用的節(jié)點，否則有幾個 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 已經(jīng)成功部署并工作正常。網(wǎng)絡(luò)可視化神器 Hubble上文提到了 Cilium 強大之處就是提供了簡單高效的網(wǎng)絡(luò)可視化功能，它是通過 Hubble組件完成的。Cilium在1.7版本后推出并開源了Hubble，它是專門為網(wǎng)絡(luò)可視化設(shè)計，能夠利用 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，實現(xiàn)可擴展的監(jiān)控策略。

部署 Hubble 和 Hubble UI

官方提供了基于 Helm Chart 部署方式，這樣可以靈活控制部署變量，實現(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

運行效果

由于默認(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é)點 IP 地址加上 32321 端口訪問 Hubble UI 的 web 服務(wù)了。打開效果如下所示：

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

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

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

對接 Grafana + Prometheus

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

--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 另外一個很大的宣傳點是宣稱已經(jīng)全面實現(xiàn)kube-proxy的功能，包括ClusterIP,NodePort,ExternalIPs和LoadBalancer，可以完全取代它的位置，同時提供更好的性能、可靠性以及可調(diào)試性。當(dāng)然，這些都要歸功于 eBPF 的能力。官方文檔中提到，如果你是在先有 kube-proxy 后部署的 Cilium，那么他們是一個 “共存” 狀態(tài)，Cilium 會根據(jù)節(jié)點操作系統(tǒng)的內(nèi)核版本來決定是否還需要依賴 kube-proxy 實現(xià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啟動并運行，它將探測節(jié)點內(nèi)核版本，判斷BPF內(nèi)核特性的可用性， #如果不滿足，則通過依賴kube-proxy來補充剩余的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 #說明 kube-proxy 沒有維護(hù)任何應(yīng)用服務(wù)跳轉(zhuǎn)，即可以停止它了。小結(jié)Cilium 作為當(dāng)下最 Cool 的 Kubernetes CNI 網(wǎng)絡(luò)插件，還有很多特性，如高階 network policy、7 層流量控制等，這款基于 BPF/eBPF 打造出的簡單、高效、易用的網(wǎng)絡(luò)管理體驗，有機會大家都來試用吧。

責(zé)任編輯：haq

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

網(wǎng)絡(luò)

網(wǎng)絡(luò)

+關(guān)注

關(guān)注
14

文章
7517

瀏覽量
88628
容器

容器

+關(guān)注

關(guān)注
0

文章
494

瀏覽量
22044

原文標(biāo)題：Kubernetes 網(wǎng)絡(luò)方案——炫酷的 Cilium

文章出處：【微信號：magedu-Linux，微信公眾號：馬哥Linux運維】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

Kubernetes集群搭建容器云需要幾臺服務(wù)器？

Kubernetes集群搭建容器云需要幾臺服務(wù)器？至少需要4臺服務(wù)器。搭建容器云所需的服務(wù)器數(shù)量以及具體的搭建步驟，會根據(jù)所選用的技術(shù)棧、業(yè)務(wù)規(guī)模、架構(gòu)設(shè)計以及安全需求等因素而有所不同。以下是一個基于Kubernetes集群的容器云搭建的概述：

發(fā)表于 10-21 10:06 ?129次閱讀

基于DPU與SmartNIC的K8s Service解決方案

1.? 方案背景 1.1. Kubernetes Service介紹 Kubernetes Service是Kubernetes中的一個核心概念，它定義了一種抽象，用于表示一組提供相同

發(fā)表于 09-02 17:01 ?869次閱讀

基于DPU與SmartNIC的K8s Service解決<b class='flag-5'>方案</b>

TSN時間敏感網(wǎng)絡(luò)技術(shù)入門級解決方案TSN?BasicSolution

隨著TSN技術(shù)獲得越來越多的關(guān)注和廣泛應(yīng)用，TSN Systems公司推出了一款入門級的解決方案TSN?BasicSolution，通過簡化的方式為用戶提供關(guān)鍵功能，基于硬件與軟件的無縫集成，幫助您提升生產(chǎn)力，更快實現(xiàn)目標(biāo)并且有效應(yīng)對復(fù)雜的任務(wù)和分析需求。

發(fā)表于 08-16 08:58 ?1624次閱讀