如何為Kubernetes集群設置網絡

Kubernetes簡介

kubernetes，簡稱K8s，是用8代替8個字符"ubernete"而成的縮寫。是一個開源的，用于管理云平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單并且高效(powerful),Kubernetes提供了應用部署，規(guī)劃，更新，維護的一種機制。

10年積累的成都網站建設、成都做網站經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先網站設計后付款的網站建設流程，更有青河免費網站建設讓你可以放心的選擇與我們合作。

傳統(tǒng)的應用部署方式是通過插件或腳本來安裝應用。這樣做的缺點是應用的運行、配置、管理、所有生存周期將與當前操作系統(tǒng)綁定，這樣做并不利于應用的升級更新/回滾等操作，當然也可以通過創(chuàng)建虛機的方式來實現某些功能，但是虛擬機非常重，并不利于可移植性。

新的方式是通過部署容器方式實現，每個容器之間互相隔離，每個容器有自己的文件系統(tǒng) ，容器之間進程不會相互影響，能區(qū)分計算資源。相對于虛擬機，容器能快速部署，由于容器與底層設施、機器文件系統(tǒng)解耦的，所以它能在不同云、不同版本操作系統(tǒng)間進行遷移。

容器占用資源少、部署快，每個應用可以被打包成一個容器鏡像，每個應用與容器間成一對一關系也使容器有更大優(yōu)勢，使用容器可以在build或release 的階段，為應用創(chuàng)建容器鏡像，因為每個應用不需要與其余的應用堆棧組合，也不依賴于生產環(huán)境基礎結構，這使得從研發(fā)到測試、生產能提供一致環(huán)境。類似地，容器比虛機輕量、更"透明"，這更便于監(jiān)控和管理。

如何使用Kubernetes網絡

Kubernetes網絡一直是一個非常復雜的主題。本文將介紹Kubernetes實際如何創(chuàng)建網絡以及如何為Kubernetes集群設置網絡。

 
許多Kubernetes部署指南中包含了在K8S部署中部署Kubernetes網絡CNI的說明。但是如果你的K8S集群已經運行，并且尚未部署任何網絡，那么部署網絡就像在K8S上運行其提供的配置文件一樣簡單（對于大多數網絡和基本用例而言）。例如，要部署flannel：
 

 
這樣，從網絡的角度來看，K8S已經可以使用。為了測試一切是否正常，我們創(chuàng)建了兩個Pod。
 

 
這將創(chuàng)建兩個pod，它們正在使用我們的驅動器。查看其中一個容器，我們發(fā)現網絡的IP地址范圍為10.42.0.0/24。
 

 
在另一個Pod進行的快速ping測試表明，網絡運行正常。
 

 

與Docker網絡相比，Kubernetes網絡如何工作？

Kubernetes通過Docker之上的CNI管理網絡，并將設備附加到Docker。盡管有Docker Swarm的Docker也具有自己的聯網功能（例如overlay、macvlan、bridging等），但CNI也提供了類似類型的功能。
  

還有一點十分重要，K8S并不使用docker0（這是Docker的默認網橋），而是創(chuàng)建自己的網橋，名為cbr0，該網橋需要與docker0區(qū)分開來。

為什么我們需要Overlay網絡？

諸如vxlan或ipsec之類的overlay網絡（如果你設置過安全***，你應該對此比較熟悉）可以將數據包封裝到另一個數據包中。這使得實體在另一臺計算機的范圍之外依舊可以尋址。Overlay網絡的替代方案包括如macvtap(lan)之類的L3解決方案，甚至包括ivtap(lan)之類的L2解決方案，但是這些方案具有一定的局限性。

L2或L3上的任何解決方案都可以讓pod在網絡上尋址。這意味著pod不僅在Docker網絡內部訪問，還能直接從Docker網絡外部訪問。這些是公共IP地址或私有IP地址。

 
然而，在L2上進行通信比較麻煩，并且你的經驗會因為網絡設備而異。某些交換機需要一些時間來注冊你的Mac地址，然后才能將其實際連接到網絡的其余部分。你還可能會遇到一些麻煩，因為系統(tǒng)中其他主機的neighbor(ARP) table仍在過時的緩存上運行，并且始終需要使用dhcp運行而不是host-local，這樣可以避免主機之間的ip沖突。Mac地址和neighbor table問題是諸如ipvlan之類的解決方案存在的原因。這些解決方案不會注冊新的mac地址，而是在現有地址上路由流量（盡管它們也有自己的問題）。
 

因此，我的建議是，對于大多數用戶而言，將overlay網絡作為默認解決方案應該足夠了。但是，一旦工作負載變得更加高級并提出了更具體的要求，你將需要考慮其他的解決方案，如BGP和直接路由。

Kubernetes網絡如何工作？

在Kubernetes中首先要了解的是，pod實際上并不等同于容器，而是容器的集合。在同一集合的容器中共享一個網絡堆棧。Kubernetes通過在暫停容器上設置網絡來進行管理，你可以在你所創(chuàng)建的每個pod中找到這些暫停容器。所有其他pod都連接到暫停容器的網絡，該容器本身除了提供網絡外不執(zhí)行任何操作。因此，也可以使一個容器通過localhost與不同容器中的服務進行通信，此時該容器具有相同pod的相同定義。

除了本地通信之外，pod之間的通信看起來與Docker網絡中的container-to-container通信幾乎相同。

Kubernetes流量路由

我將以兩種場景為例，詳細地說明如何在Pod之間路由流量。

1、 在同一主機上路由流量：

 
在兩種情況下，流量不會離開主機。一是當調用的服務在同一節(jié)點上運行，一是單個pod中的同一個容器集合。

如果從第一個pod中的容器1調用localhost:80并在容器2中運行服務，則流量將通過網絡設備并將數據包轉發(fā)到其他目的地。在這種情況下，路由流量的路線很短。

如果我們想要與其他pod進行通信，時間會更長一些。首先，流量將傳遞到cbr0，接下來cbr0將會注意到我們在同一個子網通信，因此它會將流量轉發(fā)到目標Pod，過程如下圖所示：
 

 

2、 跨主機路由流量：

當我們離開節(jié)點時，這將變得更加復雜?，F在，cbr0會將流量傳遞到下一個節(jié)點，該節(jié)點的配置由CNI管理。這些基本上只是以目標主機為網關的子網路由。然后，目標主機可以繼續(xù)使用自己的cbr0并將流量轉發(fā)到目標容器，如下所示：
 

 

究竟什么是CNI？

 
CNI是Container Networking Interface（容器網絡接口）的縮寫，基本上是一個具有定義明確的外部接口，Kubernetes可以調用它來提供網絡功能。

 
你可以在以下鏈接中找到維護的參考插件，其中包括容器網絡官方repo中的大多數重要插件：
 
https://github.com/containernetworking/plugins

CNI 3.1版不是很復雜。它包含三個必需的功能，ADD、DEL和VERSION，這些功能可以盡其所能管理網絡。有關每個函數應返回和傳遞的內容的更詳細說明，您可以在此處閱讀規(guī)范：
 
https://github.com/containernetworking/cni/blob/master/SPEC.md

CNI之間的區(qū)別

以下我們將介紹一些最受歡迎的CNI：

Flannel

Flannel是一個簡單的網絡，并且是overlay網絡最簡單的設置選項。它的功能包括原生網絡，但在多個網絡中使用時會受到限制。對于大多數用戶來說，Flannel是Canal下面的默認網絡，部署起來非常簡單，甚至還有本地網絡功能，如主機網關。但是Flannel有一些限制，包括缺乏對網絡安全策略的支持以及沒有多網絡的功能。
 

Calico

Calico與Flannel采用不同的方法，從技術的角度來說，它不是overlay網絡，而是在所有相關系統(tǒng)之間配置路由的系統(tǒng)。為此，Calico利用邊界網關協議（BGP），它在名為peering的過程中用于Internet。其中每方peering交換流量并參與BGP網絡。BGP協議本身會在其ASN下傳播路由，不同之處在于它們是私有的，不需要再RIPE中注冊它們。

但是，在某些情況下，Calico可與overlay網絡配合使用，如IPINIP。當節(jié)點位于不同網絡上時使用，以便啟動兩個主機之間的流量交換。

Canal

Canal基于Flannel，但有一些Calico自己的組件，例如felix（主機代理），它可以利用網絡安全策略。這些通常在Flannel中不存在。因此，它基本上通過添加安全策略來擴展Flannel。

Multus

Multus是一個CNI，但實際上它本身并不是網絡接口。只是它編排了多個接口，并且沒有配置實際的網絡，因而Pod無法單獨與Multus通信。實際上，Multus是多設備和多子網網絡的推動者。下圖顯示了它是如何工作的，Multus本身基本上調用了真正的CNI而不是kubelet，并將結果傳遞回kubelet。

 

 
Kube-Router
 

同樣值得一提的是kube-router，與Calico一樣，它可以與BGP和路由而不是overlay網絡一起使用。就像Calico一樣，它在必要的時候可以使用IPINIP。它還能利用ipvs進行負載均衡。
 

設置多網絡K8S集群

如果您需要使用多個網絡，則可能需要Multus。

設置Multus

我們需要做的第一件事是設置Multus。我們使用的幾乎是Multus倉庫示例中的配置，但進行了一些重要的調整。請參閱下面的示例。
 

首先是調整configmap。因為我們計劃使用Flannel創(chuàng)建默認網絡，所以我們在Multus配置的delegates數組中定義配置。這里用紅色標記的一些重要設置是“ masterplugin”：true，用于定義Flannel網絡本身的網橋。你將在接下來的步驟中了解為什么我們需要這樣做。除此之外，還需要添加配置映射的安裝定義，其他則不需要調整，因為由于某些原因，此示例未完成。

關于此configmap的另一件重要事情是，這一configmap中定義的所有內容都是默認網絡，這些默認網絡會自動安裝到容器，而無需進一步說明。另外，如果要編輯此文件，請注意，你要么需要終止并重新運行守護進程的容器，要么重新啟動節(jié)點才能使更改生效。
 

示例yaml文件：

 

設置主要的Flannel Overlay網絡

對于主要的Flannel網絡，設置非常簡單。我們可以從Multus倉庫中獲取示例，然后進行部署。此處所做的調整是CNI安裝、容差的調整以及對Flannel的CNI設置所做的一些調整。例如，添加“ forceAddress”：true并刪除“ hairpinMode”：true。

這已在使用RKE設置的集群上進行了測試，但是只要您從主機正確安裝CNI（在本例中為/ opt / cni / bin），它就可以在其他集群上工作。
 

Multus本身并沒有太大的改變。他們只注釋了initcontainer配置，你可以刪除它。之所以如此，是因為Multus將建立其delegates，并充當主要的“ CNI”。

這是修改后的Flannel daemonset：
 


 
部署了這些樣本之后，我們已經完成了很多工作，現在應該為pod分配一個IP地址。讓我們測試一下：
 



 
如你所見，我們已經成功部署了Pod，并在eth0接口（默認接口）上為其分配了IP 10.42.2.43。所有其他接口都將顯示為netX，即net1。

設置輔助網絡

 
輔助網絡還需要進行一些調整，這些調整的前提是假設你要部署vxlan。為了實際服務于輔助overlay，我們需要更改VXLAN標識符“ VIN”，默認情況下將其設置為1，并且我們的第一個overlay網絡現在已經使用了它。因此，我們可以通過在etcd服務器上配置網絡來更改此設置。我們使用自己的集群etcd，此處標記為綠色（并且假設job在運行etcd客戶端的主機上運行），然后從本地主機（在我們的情況下，將其存儲在本地主機）中裝入密鑰（此處標記為紅色），存儲在/ etc / kubernetes / ssl文件夾中。

完整的YAML文件示例：
 

 
接下來，我們可以實際部署輔助網絡。此設置幾乎與主要網絡設置相同，但有一些關鍵區(qū)別。最明顯的是，我們更改了子網，但是我們還需要更改其他一些內容。

首先，我們需要設置一個不同的dataDir，即/ var / lib / cni / flannel2，以及一個不同的subnetFile，即/run/flannel/flannel2.env。這十分必要，因為它們已經被我們的主要網絡占用。接下來，我們需要調整網橋，因為主要的Flannel overlay網絡已經使用了kbr0。
  

其余還需更改的配置包括將其更改為實際針對我們之前配置的etcd服務器。在主網絡中，這是通過–kube-subnet-mgr flag直接連接到K8S API來完成的。但是我們不能這樣做，因為我們還需要修改要讀取的前綴。你可以在下面看到橙色標記的內容，而集群etcd連接的設置則顯示為紅色。最后一個設置是再次指定子網文件，在示例中以綠色標記。最后一點是，我們添加了一個網絡定義。其余部分與我們的主要網絡配置相同。
 

有關上述步驟，請參見示例配置文件：
 


 
完成此操作后，我們便準備好了輔助網絡。

分配額外的網絡

既然我們已經準備好輔助網絡，那么我們現在需要分配他。為此，我們需要先定義一個NetworkAttachmentDefinition，之后我們可以使用它將網絡分配給容器?；旧希@是在初始化Multus之前，我們設置的configmap的動態(tài)替代方案。這樣，我們可以按需安裝所需的網絡。在此定義中，我們需要指定網絡類型（本例中是Flannel）以及必要的配置。這包括前面提到的subnetFile、dataDir和網橋名稱。

我們需要確定的最后一件事是網絡的名稱，我們將其命名為flannel2。
 

 
現在，我們終于可以使用輔助網絡生成第一個pod。
 

  
現在應該使用輔助網絡創(chuàng)建新的Pod，并且我們將那些附加網絡視為額外添加的網絡接口。
 

 
成功啦，輔助網絡分配10.5.22.4作為其IP地址。
 

Troubleshooting

如果該示例沒有正常工作，你需要查看kubelet的日志。

一個常見的問題的是缺少CNI。我第一次測試的時候，遺漏了CNI網橋，因為RKE沒有部署它。但是這個問題十分容易解決。
 

外部連接和負載均衡

現在我們已經建立并運行網絡，接下來我們要做的是使我們的應用程序可以訪問并將其配置為高可用和可擴展。高可用性和可伸縮性不僅可以通過負載均衡來實現，它還我們需要具備的關鍵組件。

Kubernetes有四個概念，可以使應用程序在外部可用。
 

使用負載均衡器

Ingress

 
Ingress基本上就是具有Layer7功能的負載均衡器，特別是HTTP(s)。最常用的ingress controller是NGINX ingress。但這主要取決于你的需求以及你的使用場景。例如，你還可以選擇traefik或HA Proxy。

配置一個ingress十分簡單。在以下例子中，你將了解一個鏈接服務的例子。藍色標注的是指向服務的基本配置。綠色標注的是鏈接SSL證書所需的配置（需要在此之前安裝這一證書）。最后，你會看到調整了NGINX ingress的一些詳細設置。

 
Layer 4 負載均衡器
 

在Kubernetes中，使用type: LoadBalancer定義Layer 4 負載均衡器，這是一個依賴于負載均衡解決方案的服務提供程序。對于本地計算機，大概率會使用HA代理或一個路由解決方案。云提供商會使用自己的解決方案以及專用硬件，也可以使用HA代理或路由解決方案。

最大的區(qū)別是第4層負載平衡器不了解高級應用程序協議（layer 7），并且僅能夠轉發(fā)流量。此級別上的大多數負載均衡器還支持SSL終止。這通常需要通過注釋進行配置，并且尚未標準化。

使用 {host,node} 端口

{host，node} Port基本上等同于docker -p port:port，尤其是hostPort。與hostPort不同，nodePort在所有節(jié)點上可用，而不是僅在運行pod的節(jié)點上可用。對于nodePort，Kubernetes首先創(chuàng)建一個clusterIP，然后通過該端口負載均衡流量。nodePort本身只是將端口上的流量轉發(fā)到clusterIP的iptable規(guī)則。

除了快速測試外，很少使用nodePort，只有在你希望每個節(jié)點公開端口（即用于監(jiān)視）時才會在生產中使用nodePort。大多數時候，你需要使用Layer 4負載均衡器。hostPort僅用于測試，或者少數時候，將pod粘貼到特定節(jié)點并在指向該節(jié)點的特定IP地址下發(fā)布。

例如，在容器規(guī)范中定義了hostPort，如下所示：
 

什么是ClusterIP ？

clusterIP是Kubernetes集群及其中所有服務的內部可訪問IP。該IP本身將負載均衡流量到與其selector規(guī)則匹配的所有Pod。在很多情況下，例如在指定類型：LoadBalancer服務或設置nodePort時，也會自動生成clusterIP。其背后的原因是所有負載均衡都是通過clusterIP進行的。
 

clusterIP作為一個概念是為了解決多個可尋址主機以及這些主機的有效更新的問題。具有不變的單個IP比始終通過服務發(fā)現針對服務的所有性質重新獲取數據要容易得多。盡管有時在某些情況下更適合使用服務發(fā)現，但如果你想要explicit control，那么還是建議使用clusterIP，如在某些微服務環(huán)境中。

常見的故障

如果您使用公有云環(huán)境并手動設置主機，則您的集群可能缺少防火墻規(guī)則。例如，在AWS中，您將需要調整安全組，以允許集群間通信以及ingress和egress。如果不這樣做，將導致集群無法運行。確保始終打開主節(jié)點和worker節(jié)點之間的必要端口。直接在主機上打開的端口（即hostPort或nodePort）也是如此。

網絡安全

既然我們已經設置了所有Kubernetes網絡，我們還需要確保它們具備一定的安全性。保證安全性的最低原則是為應用程序提供其運行所需的最少訪問量。這可以在一定程度上確保即使在發(fā)生安全漏洞的情況下，***者也將難以深入挖掘你的網絡。雖然它不能完全確保你的安全，但無疑會使***者進行***時變得更加困難和耗時。這很重要，因為它會使你有更多的時間做出反應并防止進一步的破壞。這里有一個典型的例子，不同應用程序的不同exploits/漏洞的組合，這使得***者只有從多個維度（例如，網絡、容器、主機）到達任何***面的情況下，才能進行***。
 

這里的選擇要么是利用網絡策略，要么是尋求第三方安全解決方案以實現容器網絡安全。有了網絡策略，我們有堅實的基礎來確保流量僅在流量應流的地方進行，但這僅適用于少數幾個CNI。例如，它們可與Calico和Kube-router一起使用。Flannel不支持它，但是幸運的是，你可以移至Canal，這使得Flannel可以使用Calico的網絡策略功能。對于大多數其他CNI，則沒有支持，目前尚未有支持的計劃。

 
但這不是唯一的問題。問題在于，網絡策略規(guī)則只是針對特定端口的防火墻規(guī)則，它十分簡單。這意味著你無法應用任何高級設置。例如，如果你發(fā)現某個容器可疑，就不能按需阻止它。進一步來說，網絡規(guī)則無法理解流量，因此你不知道流量的流向，并且僅限于在第3層和第4層上創(chuàng)建規(guī)則。最后，它還無法檢測到基于網絡的威脅或***，例如DDoS，DNS，SQL注入以及即使在受信任的IP地址和端口上也可能發(fā)生的其他破壞性網絡***。
 

因此，我們需要專用的容器網絡安全解決方案，它可為關鍵應用程序（例如財務或合規(guī)性驅動的應用程序）提供所需的安全性。我個人喜歡NeuVector。它具有我曾在Arvato / Bertelsmann進行部署的容器防火墻解決方案，并提供了我們所需的Layer7可見性和保護。

應該注意的是，任何網絡安全解決方案都必須是云原生的，并且可以自動擴展和調整。部署新應用程序或擴展Pod時，你無需檢查iptable規(guī)則或更新任何內容。也許對于幾個節(jié)點上的簡單應用程序堆棧，你可以手動進行管理，但是對于任何企業(yè)而言，部署安全不能減慢CI / CD流水線的速度。

除了安全性和可見性之外，我還發(fā)現擁有連接和數據包級容器網絡工具有助于在測試和staging期間調試應用程序。借助Kubernetes網絡，除非您能看到流量，否則您將永遠無法真正確定所有數據包的去向以及將哪些Pod路由到其中。

名稱欄目：如何為Kubernetes集群設置網絡
標題來源：http://muchs.cn/article4/jpdgoe.html

成都網站建設公司_創(chuàng)新互聯，為您提供網站排名、面包屑導航、定制開發(fā)、做網站、云服務器、網站設計公司

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯