共計 3890 個字符，預計需要花費 10 分鐘才能閱讀完成。

本篇文章為大家展示了如何進行 Kubernetes 架構及組件介紹，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

1. Kubernetes 簡介

Kubernetes 是谷歌開源的容器集群管理系統，是 Google 多年大規模容器管理技術 Borg 的開源版本，主要功能包括:

基于容器的應用部署、維護和滾動升級

負載均衡和服務發現

跨機器和跨地區的集群調度

自動伸縮

無狀態服務和有狀態服務

廣泛的 Volume 支持

插件機制保證擴展性

Kubernetes 發展非常迅速，已經成為容器編排領域的領導者。

2. Kubernetes 架構及組件介紹 2.1 kubernetes 架構

Kubernetes 主要由以下幾個核心組件構成：

etcd 保存整個集群的狀態；

apiserver 提供了資源操作的唯一入口，并提供認證、授權、訪問控制、API 注冊和發現等機制；

controller manager 負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；

scheduler 負責資源的調度，按照預定的調度策略將實例（Pod）調度到相應的主機上；

kubelet 負責維護容器的生命周期，同時也負責存儲卷和網絡的管理；

container runtime 負責鏡像管理以及容器的真正執行，在我們系統中指的是 Docker

kube-proxy 負責為應用提供集群內部的服務發現和負載均衡

推薦的插件

helm – kubernetes 包管理工具

kube-dns/coreDNS 負責為整個集群提供 DNS 服務

Ingress Controller 為服務提供外網入口

Heapster 提供資源監控

Dashboard 提供 GUI

Federation 提供跨可用區的集群

Fluentd-elasticsearch 提供集群日志采集、存儲與查詢

2.2 Kubernetes 組件介紹

2.2.1 etcd

etcd 是基于 Raft 一致性算法開發的分布式 key-value 存儲，可用于服務發現、共享配置以及一致性保障（如數據庫選主、分布式鎖等）

etcd 主要功能：

基本的 key-value 存儲

監聽機制

key 的過期及續約機制，用于監控和服務發現

原子 CAS 和 CAD，用于分布式鎖和 leader 選舉

Etcd 基于 RAFT 的一致性

leader 節點選舉方法

初始啟動時，節點處于 follower 狀態并被設定一個 election timeout，如果在這一時間周期內沒有收到來自 leader 的心跳檢測，節點將發起選舉，將自己切換為 candidate（候選人）節點之后，向集群中的其他 follow 節點發送請求，詢問其是否選舉自己為 leader

當收到來自集群中過半數節點的接受投票后，節點即成為 leader，開始接收保存 client 的數據并向其他的 follower 節點同步日志。如果沒有達成一致，則 candidate 節點隨機選擇一個等待時間（150ms ～ 300ms）再次發起投票，得到集群中半數以上的 follower 接受的 candidate 將成為 leader

leader 節點依靠定時向 follower 節點發送心跳檢測來保持其地位

任何時候如果其他 follower 在 election timeout 期間沒有收到來自 leader 的心跳檢測，同樣會將自己的狀態切換為 candidate 并發起選舉。每成功選舉一次，新 leader 的步進數（Term）都會比之前 leader 的步進數加 1

失效處理

leader 失效：其他沒有收到心跳檢測的節點將發起新的選舉，當 leader 恢復后由于步進數小自動成為 follower（日志會被新 leader 的日志覆蓋）

follower 節點不可用：follower 節點不可用的情況相對比較容易解決。因為集群中的日志內容始終是從 leader 節點同步，只要這一節點再次加入集群時重新從 leader 節點處復制日志即可

多個候選人（candidate）：沖突后 candidate 將隨機選擇一個等待時間（150ms ～ 300ms）再次發起投票，得到集群中半數以上的 follower 接受的 candidate 將成為 leader

講到這里可能有同學發現 Etcd 和 Zookeeper、Consul 等一致性協議實現框架有些類似，的確這些中間件是比較類似的，關于其中的異同點，大家可以自行查閱資料。

2.2.2 kube-apiserver

kube-apiserver 是 Kubernetes 最重要的核心組件之一，主要提供了如下功能：

提供集群管理的 REST API 接口，包括認證授權、數據校驗以及集群狀態變更等

提供同其他模塊之間的數據交互 (其他模塊通過 API Server 查詢或修改數據，只有 API Server 才直接操作 etcd)

2.2.3 kube-scheduler

kube-scheduler 負責分配調度 Pod 到集群內的節點上，它監聽 kube-apiserver，查詢還未分配 Node 的 Pod，然后根據調度策略為這些 Pod 分配節點

通過以下三種方式可以指定 Pod 只運行在特定的 Node 節點上

nodeSelector: 只調度到匹配指定 label 的 Node 上

nodeAffinity: 功能更豐富的 Node 選擇器，比如支持集合操作

podAffinity: 調度到滿足條件的 Pod 所在的 Node 上

2.2.4 kube-controller-manager

kube-controller-manager 是 Kubernetes 的大腦，通過 kube-apiserver 監控整個集群的狀態，并確保集群處于預期的工作狀態，它由一系列的控制器組成，這些控制器主要包括三組：

1. 必須啟動的控制器

eploymentController

DaemonSetController

NamesapceController

ReplicationController

RelicaSet

JobController

…

2. 默認啟動的控制器

NodeController

ServiceController

PVBinderController

…

3. 默認禁止的可選控制器

BootstrapSignerController

TokenCleanerController

…

2.2.5 Kubelet

每個 Node 節點上都運行一個 kubelet 守護進程，默認監聽 10250 端口，接收并執行 master 發來的指令，管理 Pod 及 Pod 中的容器。每個 kubelet 進程會在 API Server 上注冊節點自身信息，定期向 master 節點匯報節點的資源使用情況

節點管理

主要是節點自注冊和節點狀態更新:

Kubelet 可以通過設置啟動參數 –register-node 來確定是否向 API Server 注冊自己;

如果 Kubelet 沒有選擇自注冊模式，則需要用戶自己配置 Node 資源信息，同時需要在 Kubelet 上配置集群中 API Server 的信息;

Kubelet 在啟動時通過 API Server 注冊節點信息，并定時向 API Server 發送節點狀態消息，API Server 在接收到新消息后，將信息寫入 etcd

容器健康檢查

Pod 通過兩類探針檢查容器的健康狀態

LivenessProbe 存活探針：通過該探針判斷容器是否健康，告訴 Kubelet 一個容器什么時候處于不健康的狀態。如果 LivenessProbe 探針探測到容器不健康，則 kubelet 將刪除該容器，并根據容器的重啟策略做相應的處理。如果一個容器不包含 LivenessProbe 探針，那么 kubelet 認為該容器的 LivenessProbe 探針返回的值永遠是“Success”。

ReadinessProbe 就緒探針：用于判斷容器是否啟動完成且準備接收請求。如果 ReadinessProbe 探針探測到失敗，則 Pod 的狀態將被修改。Endpoint Controller 將從 Service 的 Endpoint 中刪除包含該容器所在 Pod 的 IP 地址的 Endpoint 條目。

2.2.6 kube-proxy

每臺機器上都運行一個 kube-proxy 服務，它監聽 API Server 中 service 和 Pod 的變化情況，并通過 userspace、iptables、ipvs 等 proxier 來為服務配置負載均衡

代理模式（proxy-mode）提供如下三種類型：

1) userspace

最早的負載均衡方案，它在用戶空間監聽一個端口，所有請求通過 iptables 轉發到這個端口，然后在其內部負載均衡到實際的 Pod。service 的請求會先從用戶空間進入內核 iptables，然后再回到用戶空間（kube-proxy），由 kube-proxy 完成后端 Endpoints 的選擇和代理工作，這樣流量從用戶空間進出內核帶來的性能損耗是不可接受的，所以產生了 iptables 的代理模式

2) iptables:

iptables mode 完全使用 iptables 來完成請求過濾和轉發。但是如果集群中存在大量的 Service/Endpoint，那么 Node 上的 iptables rules 將會非常龐大，添加或者刪除 iptables 規則會引起較大的延遲。

3) ipvs:

為了解決存在大量 iptables 規則時的網絡延遲的問題，Kubernetes 引入了 ipvs 的模式，（ipvs 是 LVS – Linux Virtual Server 的重要組成部分，最早是由中國的章文嵩博士推出的一個開源項目，提供軟件負載均衡的解決方案），下面是 ipvs 模式的原理圖：

上述內容就是如何進行 Kubernetes 架構及組件介紹，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。