Kubernetes 超詳細總結

一個目標：容器操作；兩地三中心；四層服務發現；五種 Pod 共享資源；六個 CNI 常用插件；七層負載均衡；八種隔離維度；九個網絡模型原則；十類 IP 地址；百級產品線；千級物理機；萬級容器；相如無億，Kubernetes 有億：億級日服務人次。

一個目標：容器操作

Kubernetes 是自動化容器操作的開源平臺。這些容器操作包括：部署，調度和節點集羣間擴展。

具體功能：

• 自動化容器部署和複製。

• 實時彈性收縮容器規模。

• 容器編排成組，並提供容器間的負載均衡。

調度：容器在哪個機器上運行。

組成：

• kubectl：客戶端命令行工具，作爲整個系統的操作入口。

• kube-apiserver：以 REST API 服務形式提供接口，作爲整個系統的控制入口。

• kube-controller-manager：執行整個系統的後臺任務，包括節點狀態狀況、Pod 個數、Pods 和 Service 的關聯等。

• kube-scheduler：負責節點資源管理，接收來自 kube-apiserver 創建 Pods 任務，並分配到某個節點。

• etcd：負責節點間的服務發現和配置共享。

• kube-proxy：運行在每個計算節點上，負責 Pod 網絡代理。定時從 etcd 獲取到 service 信息來做相應的策略。

• kubelet：運行在每個計算節點上，作爲 agent，接收分配該節點的 Pods 任務及管理容器，週期性獲取容器狀態，反饋給 kube-apiserver。

• DNS：一個可選的 DNS 服務，用於爲每個 Service 對象創建 DNS 記錄，這樣所有的 Pod 就可以通過 DNS 訪問服務了。

下面是 Kubernetes 的架構拓撲圖：

兩地三中心

兩地三中心包括本地生產中心、本地災備中心、異地災備中心。

兩地三中心要解決的一個重要問題就是數據一致性問題。Kubernetes 使用 etcd 組件作爲一個高可用、強一致性的服務發現存儲倉庫。用於配置共享和服務發現。

它作爲一個受到 ZooKeeper 和 Doozer 啓發而催生的項目。除了擁有他們的所有功能之外，還擁有以下 4 個特點：

• 簡單：基於 http+json 的 API 讓你用 curl 命令就可以輕鬆使用。

• 安全：可選 SSL 客戶認證機制。

• 快速：每個實例每秒支持一千次寫操作。

• 可信：使用 Raft 算法充分實現了分佈式。

四層服務發現‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

先上一張圖解釋一下網絡七層協議：

Kubernetes 提供了兩種方式進行服務發現：

環境變量：當創建一個 Pod 的時候，kubelet 會在該 Pod 中注入集羣內所有 Service 的相關環境變量。需要注意的是，要想一個 Pod 中注入某個 Service 的環境變量，則必須 Service 要先比該 Pod 創建。這一點，幾乎使得這種方式進行服務發現不可用。

比如，一個 ServiceName 爲 redis-master 的 Service，對應的 ClusterIP:Port 爲 10.0.0.11:6379，則對應的環境變量爲：

DNS：可以通過 cluster add-on 的方式輕鬆的創建 KubeDNS 來對集羣內的 Service 進行服務發現。

以上兩種方式，一個是基於 TCP，衆所周知，DNS 是基於 UDP 的，它們都是建立在四層協議之上。

五種 Pod 共享資源

Pod 是 Kubernetes 最基本的操作單元，包含一個或多個緊密相關的容器，一個 Pod 可以被一個容器化的環境看作應用層的 “邏輯宿主機”；一個 Pod 中的多個容器應用通常是緊密耦合的，Pod 在 Node 上被創建、啓動或者銷燬；每個 Pod 裏運行着一個特殊的被稱之爲 Volume 掛載卷，因此他們之間通信和數據交換更爲高效，在設計時我們可以充分利用這一特性將一組密切相關的服務進程放入同一個 Pod 中。

同一個 Pod 裏的容器之間僅需通過 localhost 就能互相通信。一個 Pod 中的應用容器共享五種資源：

• PID 命名空間：Pod 中的不同應用程序可以看到其他應用程序的進程 ID。

• 網絡命名空間：Pod 中的多個容器能夠訪問同一個 IP 和端口範圍。

• IPC 命名空間：Pod 中的多個容器能夠使用 SystemV IPC 或 POSIX 消息隊列進行通信。

• UTS 命名空間：Pod 中的多個容器共享一個主機名。

• Volumes（共享存儲卷）：Pod 中的各個容器可以訪問在 Pod 級別定義的 Volumes。

Pod 的生命週期通過 Replication Controller 來管理；通過模板進行定義，然後分配到一個 Node 上運行，在 Pod 所包含容器運行結束後，Pod 結束。

Kubernetes 爲 Pod 設計了一套獨特的網絡配置，包括：爲每個 Pod 分配一個 IP 地址，使用 Pod 名作爲容器間通信的主機名等。

六個 CNI 常用插件

CNI（Container Network Interface）容器網絡接口，是 Linux 容器網絡配置的一組標準和庫，用戶需要根據這些標準和庫來開發自己的容器網絡插件。CNI 只專注解決容器網絡連接和容器銷燬時的資源釋放，提供一套框架，所以 CNI 可以支持大量不同的網絡模式，並且容易實現。

下面用一張圖表示六個 CNI 常用插件：

七層負載均衡

提負載均衡就不得不先提服務器之間的通信。

IDC（Internet Data Center），也可稱數據中心、機房，用來放置服務器。IDC 網絡是服務器間通信的橋樑。

上圖裏畫了很多網絡設備，它們都是幹啥用的呢？

路由器、交換機、MGW/NAT 都是網絡設備，按照性能、內外網劃分不同的角色。

• 內網接入交換機：也稱爲 TOR（top of rack），是服務器接入網絡的設備。每臺內網接入交換機下聯 40-48 臺服務器，使用一個掩碼爲 / 24 的網段作爲服務器內網網段。

• 內網核心交換機：負責 IDC 內各內網接入交換機的流量轉發及跨 IDC 流量轉發。

• MGW/NAT：MGW 即 LVS 用來做負載均衡，NAT 用於內網設備訪問外網時做地址轉換。

• 外網核心路由器：通過靜態互聯運營商或 BGP 互聯美團統一外網平臺。

先說說各層負載均衡：

• 二層負載均衡：基於 MAC 地址的二層負載均衡。

• 三層負載均衡：基於 IP 地址的負載均衡。

• 四層負載均衡：基於 IP + 端口的負載均衡。

• 七層負載均衡：基於 URL 等應用層信息的負載均衡。

這裏用一張圖來說說四層和七層負載均衡的區別：

上面四層服務發現講的主要是 Kubernetes 原生的 kube-proxy 方式。Kubernetes 關於服務的暴露主要是通過 NodePort 方式，通過綁定 minion 主機的某個端口，然後進行 Pod 的請求轉發和負載均衡，但這種方式有下面的缺陷：

• Service 可能有很多個，如果每個都綁定一個 Node 主機端口的話，主機需要開放外圍的端口進行服務調用，管理混亂。

• 無法應用很多公司要求的防火牆規則。

理想的方式是通過一個外部的負載均衡器，綁定固定的端口，比如 80，然後根據域名或者服務名向後面的 Service IP 轉發，Nginx 很好的解決了這個需求，但問題是如果有的新的服務加入，如何去修改 Nginx 的配置，並且加載這些配置？Kubernetes 給出的方案就是 Ingress。這是一個基於 7 層的方案。

八種隔離維度

Kubernetes 集羣調度這邊需要對上面從上到下從粗粒度到細粒度的隔離做相應的調度策略。

九個網絡模型原則

Kubernetes 網絡模型要符合 4 個基礎原則，3 個網絡要求原則，1 個架構原則，1 個 IP 原則。

每個 Pod 都擁有一個獨立的 IP 地址，而且假定所有 Pod 都在一個可以直接連通的、扁平的網絡空間中，不管是否運行在同一 Node 上都可以通過 Pod 的 IP 來訪問。

Kubernetes 中的 Pod 的 IP 是最小粒度 IP。同一個 Pod 內所有的容器共享一個網絡堆棧，該模型稱爲 IP-per-Pod 模型。

Pod 由 docker0 實際分配的 IP，Pod 內部看到的 IP 地址和端口與外部保持一致。同一個 Pod 內的不同容器共享網絡，可以通過 localhost 來訪問對方的端口，類似同一個 VM 內不同的進程。

IP-per-Pod 模型從端口分配、域名解析、服務發現、負載均衡、應用配置等角度看，Pod 可以看做是一臺獨立的 VM 或物理機。

• 所有容器都可以不用 NAT 的方式同別的容器通信。

• 所有節點都可以在不同 NAT 方式下同所有容器心痛，反之亦然。

• 容器的地址和別人看到的地址是同一個地址。

要符合下面的架構：

由上圖架構引申出來 IP 概念從集羣外部到集羣內部。

十類 IP 地址

大家都知道 IP 地址分爲 ABCDE 類，另外還有 5 類特殊用途的 IP。

A 類

1.0.0.0-126.255.255.255，默認子網掩碼/8，即255.0.0.0

B 類

128.0.0.0-191.255.255.255，默認子網掩碼/16，即255.255.0.0

C 類

192.0.0.0-223.255.255.255，默認子網掩碼/24，即255.255.255.0

D 類

224.0.0.0-239.255.255.255，一般用於組播

E 類

240.0.0.0-255.255.255.255（其中255.255.255.255爲全網廣播地址），E類地址一般用於研究用途

0.0.0.0

嚴格來說，0.0.0.0 已經不是一個真正意義上的 IP 地址了。它表示的是這樣一個集合：所有不清楚的主機和目的網絡。這裏的不清楚是指在本機的路由表裏沒有特定條目指明如何到達。作爲缺省路由。

127.0.0.1

本機地址。

224.0.0.1

組播地址。如果你的主機開啓了 IRDP（Internet 路由發現，使用組播功能），那麼你的主機路由表中應該有這樣一條路由。

169.254.x.x

使用了 DHCP 功能自動獲取了 IP 的主機，DHCP 服務器發生故障，或響應時間太長而超出了一個系統規定的時間，系統會爲你分配這樣一個 IP，代表網絡不能正常運行。

10.xxx、172.16.x.x~172.31.x.x、192.168.x.x

私有地址，大量用於企業內部。保留這樣的地址是爲了避免亦或是哪個接入公網時引起地址混亂。

原文鏈接：https://blog.csdn.net/huakai_sun/article/details/82378856

文章轉載：分佈式實驗室
（版權歸原作者所有，侵刪）

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/D-I1iz7hJKp7CKMPfC_E8Q