如何分析Kubernetes網(wǎng)絡(luò)概念，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

民和網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)自2013年起到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運(yùn)維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

Kubernetes網(wǎng)絡(luò)是Kubernetes中一個核心概念。簡而言之，Kubernetes網(wǎng)絡(luò)模型可以確保集群上所有Kubernetes pod都能進(jìn)行通信。此外，在Kubernetes網(wǎng)絡(luò)模型的基礎(chǔ)上，Kubernetes還有其他核心概念，即Kubernetes Services和Kubernetes Ingress。

將使用系統(tǒng)模型的方法探索Kubernetes網(wǎng)絡(luò)。我們將開發(fā)一個簡單的模型來了解容器與容器間的通信以及Pod之間的通信。

如何看待網(wǎng)絡(luò)

毫無疑問，網(wǎng)絡(luò)是一個極為廣泛且復(fù)雜的領(lǐng)域，它需要多年的理論積累以及實踐才能精通。在本文中，我們將在概念層面對網(wǎng)絡(luò)進(jìn)行梳理，暫時不涉及實現(xiàn)層面的細(xì)節(jié)。

理想的網(wǎng)絡(luò)模型

上圖將網(wǎng)絡(luò)描述為Network Graph，該網(wǎng)絡(luò)由一組節(jié)點以及節(jié)點之間的鏈接組成。如果當(dāng)且僅當(dāng)節(jié)點之間存在聯(lián)系時，一個節(jié)點才可以與另一個節(jié)點交換信息。 消息交換框架

一個節(jié)點，即源節(jié)點，通過將消息放入目標(biāo)的輸入隊列，與另一個節(jié)點，即目標(biāo)交換消息。消息交換由源節(jié)點觀察到的Send Event，Send·M和在目標(biāo)節(jié)點觀察到的相應(yīng)的Receive Event，Recv·M表示。

消息交換行為

網(wǎng)絡(luò)中的節(jié)點要么是Process，要么是Switch。Process會產(chǎn)生和消耗消息，Switch根據(jù)其轉(zhuǎn)發(fā)信息庫（FIB）處理消息。

S1和S2的轉(zhuǎn)發(fā)信息庫（FIB）

上圖描述了Switch的轉(zhuǎn)發(fā)信息庫（FIB）S1和S2。在收到消息時，每臺Switch都會查詢其轉(zhuǎn)發(fā)信息庫，以決定是發(fā)送（deliver）、轉(zhuǎn)發(fā)（forward）還是丟棄（discard）該消息。

Switch：

將信息的請求頭，即源地址、源端口、目標(biāo)地址和目標(biāo)端口與其轉(zhuǎn)發(fā)信息庫相匹配、 執(zhí)行相關(guān)操作，默認(rèn)為棄置（discard）

Kubernetes網(wǎng)絡(luò)模型

Kubernetes網(wǎng)絡(luò)模型是一個描述性的網(wǎng)絡(luò)模型，也就是說，任何滿足Kubernetes網(wǎng)絡(luò)模型規(guī)范的網(wǎng)絡(luò)都是Kubernetes網(wǎng)絡(luò)。

然而，Kubernetes并沒有規(guī)定如何實現(xiàn)網(wǎng)絡(luò)模型。事實上，現(xiàn)在市面上有許多替代的實現(xiàn)，稱為網(wǎng)絡(luò)插件。

本節(jié)將用一組關(guān)于消息交換的約束條件來描述Kubernetes網(wǎng)絡(luò)模型。

限制條件：網(wǎng)絡(luò)可尋址實體

Kubernetes網(wǎng)絡(luò)模型定義了3個可尋址實體：K8S pod、K8S 節(jié)點以及K8S Service，每個實體都會分配到一個不同的IP地址。

∧ (K8s-Pod(E?) ∨ K8s-Node(E?) ∨ K8s-Service(E?))
∧ (K8s-Pod(E?) ∨ K8s-Node(E?) ∨ K8s-Service(E?)):
  addr(E?, a) ∧ addr(E?, a)?
   ? E? = E?

然而，網(wǎng)絡(luò)模型不對這些IP地址做任何進(jìn)一步的聲明。例如，Kubernetes網(wǎng)絡(luò)模型不對從這些IP地址中提取的IP地址空間做任何進(jìn)一步的聲明。

限制條件：容器間通信

Kubernetes網(wǎng)絡(luò)模型要求在Pod P上下文中執(zhí)行的容器C1可以通過localhost與在P上下文中執(zhí)行的其他容器C2進(jìn)行通信。

K8s-Pod(P) ∧ K8s-Container(C?, P) ∧ K8s-Container(C?, P):
 open(C?, p) 
  ?
   Send(e, C?, 127.0.0.1, _, 127.0.0.1, p)
    ?
     Recv(e, C?, 127.0.0.1, _, 127.0.0.1, p)

限制條件：Pod到Pod

Kubernetes網(wǎng)絡(luò)模型要求在Pod P1上下文中執(zhí)行的容器C1可以通過P2的地址與在P2上下文中執(zhí)行的其他容器C2進(jìn)行通信。

∧ K8s-Pod(P?) ∧ K8s-Container(C?, P?)
∧ K8s-Pod(P?) ∧ K8s-Container(C2, P?):
 addr(P?, sa) ∧ addr(P?, ta) ∧ open(C?, tp)
  ?
   Send(e, C?, sa, sp, ta, tp)
    ?
     Recv(e, C?, sa, sp, ta, tp)

限制條件：Process到Pod

Kubernetes網(wǎng)絡(luò)模型要求托管在節(jié)點N上的一個Process，稱為Daemon D，可以通過P的地址與托管在N上的Pod P上下文中執(zhí)行的任何容器C進(jìn)行通信。 K8s-Node(N) ∧ K8s-Daemon(D) ∧ K8s-Pod(P) ∧ K8s-

Container(C, P):
 host(N, D) ∧ host(N, P) ∧ addr(P, a) ∧ open(C, p)
  ?
   Send(e, D, _, _, a, p)
    ?
     Recv(e, C, _, _, a, p)

Kubernetes網(wǎng)絡(luò)作為Network Graph

本節(jié)用Kubernetes Network Graph這個理想的模型來描述Kubernetes網(wǎng)絡(luò)模型。

下圖描述了本節(jié)內(nèi)容中的用例：Kubernetes集群K1由2個節(jié)點組成。每個節(jié)點托管2個Pod。每個Pod執(zhí)行2個容器，一個容器監(jiān)聽8080端口，一個容器監(jiān)聽9090端口。此外，每個節(jié)點托管1個Daemon。

我們可以將Kubernetes集群網(wǎng)絡(luò)建模為一個具有一組節(jié)點和一組鏈接的Graph。

節(jié)點

每個K8S容器C映射到網(wǎng)絡(luò)Process C

K8s-Pod(P) ∧ K8s-Container(C, P):
  Process(C)

每個Daemon D映射到網(wǎng)絡(luò)Process C

K8s-Daemon(D):
  Process(D)

每個K8s Pod P映射到網(wǎng)絡(luò)Switch P, Pod的Switch

K8s-Pod(P):
  Switch(P)

每個K8S節(jié)點N 映射到網(wǎng)絡(luò) Switch N，節(jié)點的Switch：

K8s-Pod(N):
  Switch(N)

鏈接

每個容器C會被鏈接到其Pod Switch P

K8s-Pod(P) ∧ K8s-Container(C, P):
 link(C, P)

每個Daemon D會被鏈接到其節(jié)點Switch N

K8s-Node(N) ∧ K8s-Daemon(D):
 host(N, D)
  ?
   link(D, N)

每個Pod Switch P會被鏈接到其節(jié)點Switch N

K8s-Node(N) ∧ K8s-Pod(P):
 host(N, P)
  ?
   link(P, N)

每個節(jié)點Switch N1會被鏈接到其他各節(jié)點Switch N2

K8s-Node(N?) ∧ K8s-Node(N?):
 N? ≠ N?
  ?
   link(N?, N?)

在Pod Switch的轉(zhuǎn)發(fā)信息庫

P2的轉(zhuǎn)發(fā)信息庫

1. Delivery on localhost
K8s-Pod(P) ∧ K8s-Container(C, P):
 open(C, p) 
  ?
   [* * 127.0.0.1 p Deliver(C)] in FIB[P]
2. Delivery on Pod Address
K8s-Pod(P) ∧ K8s-Container(C, P):
 addr(P, a) ∧ open(C, p) 
  ?
   [* * a p Deliver(C)] in FIB[P]
3. Local Forwarding Rule
K8s-Node(N) ∧ K8s-Pod(P):
 host(N, P) 
  ?
   [* * * * Forward(N)] in FIB[P]

在節(jié)點Switch的轉(zhuǎn)發(fā)信息庫

轉(zhuǎn)發(fā)信息庫 N2

1. Node to Pod Forwarding Rule K8s-Node(N) ∧ K8s-Pod(P): host(N, P) ∧ addr(P, a) ? [* * a * Forward(P)] in FIB[N]

2. Node to Node Forwalding Rule K8s-Node(N?) ∧ K8s-Node(N?) ∧ K8s-Pod(P): N? ≠ N? ∧ host(N?, P) ∧ addr(P, a) ? [* * a * Forward(N?)] in FIB[N?]

示例

本節(jié)將通過一些例子，按照Kubernetes集群網(wǎng)絡(luò)K1中的消息生命（Life of a Message）來進(jìn)行講解。

容器到容器

容器C1.1需要與容器C1.2進(jìn)行通信：

• C1.1在P1的上下文中執(zhí)行

• C1.2在P1的上下文中執(zhí)行

C?.?通過127.0.0.1:9090到C?.?

節(jié)點內(nèi)Pod到Pod通信

容器C 1.1需要與C 3.1進(jìn)行通信：

• C 1.1在N1節(jié)點上的P1上下文中執(zhí)行

• C 3.1在N1節(jié)點上的P3上下文中執(zhí)行

C 1.1通過10.1.1.2:8080到C 3.1

節(jié)點間Pod到Pod通信

容器C 1.1需要與容器C 2.1進(jìn)行通信：

• C1.1是在N1節(jié)點上托管的P1的上下文中執(zhí)行的

• C2.1在節(jié)點N2上的P2上下文中執(zhí)行

C1.1通過10.1.2.1:8080到C2.1

Daemon到Pod通信

Daemon D1需要與容器 C 1.1通信：

• D1托管在節(jié)點N1上

• C 1.1在Pod P1的上下文中執(zhí)行，該P(yáng)od托管在節(jié)點N1上

D1通過10.1.1.1:8080到C 1.1

Kubernetes網(wǎng)絡(luò)模型是一個允許性的網(wǎng)絡(luò)模型，也就是說，任何滿足Kubernetes網(wǎng)絡(luò)模型約束的網(wǎng)絡(luò)都是一個有效的Kubernetes網(wǎng)絡(luò)。

將Kubernetes網(wǎng)絡(luò)模型映射到Network Graph，使我們能夠在概念層面上對網(wǎng)絡(luò)進(jìn)行推理，并且跳過了在實現(xiàn)層面上推理所需的一系列細(xì)節(jié)。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。