Kubernetes 前世此生（ 附學習思惟導圖 ）

雖然 Docker 已經很強大了，可是在實際使用上仍是有諸多不便，好比集羣管理、資源調度、文件管理等等。那麼在這樣一個百花齊放的容器時代涌現出了不少解決方案，好比 Mesos、Swarm、Kubernetes 等等，其中谷歌開源的 Kubernetes 是做爲老大哥的存在。

Kubernetes發展經歷

歷史老是不盡的相同，好的總會取代壞的。

Kubernetes 是希臘語『舵手』的意思，它最開始由 Google 的幾位軟件工程師創立，深受公司內部 Borg 和 Omega 項目的影響，不少設計都是從 Borg 中借鑑的，同時也對 Borg 的缺陷進行了改進，Kubernetes 目前是 CNCF 的項目而且是不少公司管理分佈式系統的解決方案。其中比較有意思的一點是，Kubernetes 的簡寫稱爲 k8s。即該單詞 k 和 s 中間恰好是 8 個字母組成，因此是一種單詞的簡寫形式。相似於，咱們在項目中使用的國際化(internationalization)叫作 i18n 是同樣效果。

建於 Docker 之上的 Kubernetes 能夠構建一個容器的調度服務，其目的是讓用戶透過 Kubernetes 集羣來進行雲端容器集羣的管理，而無需用戶進行復雜的設置工做，系統會自動選取合適的工做節點來執行具體的容器集羣調度處理工做。

其核心概念是 Container Pod。一個 Pod 由一組工做於同一物理工做節點的容器構成。這些組容器擁有相同的網絡命名空間、IP以及存儲配額，也能夠根據實際狀況對每個 Pod 進行端口映射。此外，Kubernetes 工做節點會由主系統進行管理，節點包含了可以運行 Docker 容器所用到的服務。

咱們能夠看到多種服務方式

• 阿里雲 => Infrastructure as a service

• 新浪雲 => Platform as a service

• Office365 => Software as a service

做爲編排工具，從社區的年齡來說，Kubernetes 不佔優點。畢竟 Kubernetes 才三歲而已，而 Apache 推出的 Mesos 已經有 7 年之久。Docker Swarm 雖然是比 Kubernetes 更年輕，可是它的背後是來自於 Docker 官方容器中心的全方位支持。可是，由於是谷歌開源出來的，而且擁有十多年的容器化的經驗，因此仍是有不少人在使用，而且會變成之後整個行業的主要支柱。

Kubernetes 解決的核心問題

• 服務發現和負載均衡

• Kubernetes 可使用 DNS 名稱或本身的 IP 地址公開容器，若是到容器的流量很大，Kubernetes 能夠負載均衡並分配網絡流量，從而使部署穩定。

• 存儲編排

• Kubernetes 容許您自動掛載您選擇的存儲系統，例如本地存儲、公共雲提供商等。

• 自動部署和回滾

• 您可使用 Kubernetes 描述已部署容器的所需狀態，它能夠以受控的速率將實際狀態更改成所需狀態。例如，您能夠自動化 Kubernetes 來爲您的部署建立新容器，刪除現有容器並將它們的全部資源用於新容器。

• 自動二進制打包

• Kubernetes 容許您指定每一個容器所需 CPU 和內存（RAM）。當容器指定了資源請求時，Kubernetes 能夠作出更好的決策來管理容器的資源。

• 自我修復

• Kubernetes 從新啓動失敗的容器、替換容器、殺死不響應用戶定義的運行情況檢查的容器，而且在準備好服務以前不將其通告給客戶端。

• 密鑰與配置管理

• Kubernetes 容許您存儲和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。您能夠在不重建容器鏡像的狀況下部署和更新密鑰和應用程序配置，也無需在堆棧配置中暴露密鑰。

Kubernetes 的出現不只主宰了容器編排的市場，更改變了過去的運維方式，不只將開發與運維之間邊界變得更加模糊，並且讓 DevOps 這一角色變得更加清晰，每個軟件工程師均可以經過 Kubernetes 來定義服務之間的拓撲關係、線上的節點個數、資源使用量而且可以快速實現水平擴容、藍綠部署等在過去複雜的運維操做。

性能對比

當今三大主流調度系統的比較與分析

• 對比總結

• Apache Mesos

Apache Mesos 是一個分佈式系統內核的開源集羣管理器，Apache Mesos 的出現要遠早於 Docker Swarm 和 Kubernetes。再加上 Marathon 這個基於容器的應用程序的編排框架，它爲 Docker Swarm 和 Kubernetes 提供了一個有效的替代方案。Mesos 同時可使用其餘框架來同時支持容器化和非容器化的工做負載。

Mesos 可以在一樣的集羣機器上運行多種分佈式系統類型，能夠更加動態高效的共享資源。並且 Messos 也提供服務失敗檢查，服務發佈，服務跟蹤，服務監控，資源管理和資源共享。Messos 能夠擴展伸縮到數千個節點。若是你擁有不少的服務器並且想構建一個大的集羣的時候，Mesos 就派上用場了。不少的現代化可擴展性的數據處理應用均可以在 Mesos 上運行，包括大數據框架 Hadoop、Kafka、Spark。

可是大而全，每每就是對應的複雜和困難，這一點體如今 Messos 上是徹底正確，與Docker 和 Docker Swarm 使用同一種 API 不一樣的，Mesos 和 Marathon 都有本身的 API，這使得它們比其餘編排系統更加的複雜。Apache Mesos 是混合環境的完美編配工具，因爲它包含容器和非容器的應用，雖然 Messos 很穩定，可是它的使用戶快速學習應用變得更加困難，這也是在應用和部署場景下難於推廣的緣由之一。

• Docker Swarm

Docker Swarm 是 Docker 公司的容器編排系統，使用的是標準 Docker API 接口，容器使用命令和 docker 命令是一套，簡單方便。Docker Swarm 基本架構是也是簡單直接，每一個主機運行一個 Docker Swarm 代理，一個主機運行一個 Docker Swarm 管理者，這個管理者負責指揮和調度這些主機上的容器，Docker Swarm 以高可用性模式運行，Docker Swarm 中的一個節點充當其餘節點的管理器，包括調度程序和服務發現組件的容器。

Docker Swarm 的優勢和缺點都是使用標準的 Docker 接口，由於使用簡單，容易集成到現有系統，因此在支持複雜的調度系統時候就會比較困難了，特別是在定製的接口中實現的調度。這也許就是成也在 Docker，敗也在 Docker 的緣由所在。

• Kubernetes

Kubernetes 做爲一個容器集羣管理系統，用於管理雲平臺中多個主機上的容器應用，Kubernetes 的目標是讓部署容器化的應用變得簡單且高效，因此 Kubernetes 提供了應用部署，規劃，更新，維護的一整套完整的機制。

Kubernetes 沒有固定要求容器的格式，可是 Kubernetes 使用它本身的 API 和命令行接口來進行容器編排。除了 Docker 容器以外，Kubernetes 還支持其餘多種容器，如 rkt、CoreOS 等。Kubernetes 是自成體系的管理工具，能夠實現容器調度，資源管理，服務發現，健康檢查，自動伸縮，更新升級等，也能夠在應用模版配置中指定副本數量，服務要求（IO 優先；性能優先等），資源使用區間，標籤（Labels等）來匹配特定要求達到預期狀態等，這些特徵便足以征服開發者，再加上 Kubernetes 有一個很是活躍的社區。它爲用戶提供了更多的選擇以方便用戶擴展編排容器來知足他們的需求。可是因爲 Kubernetes 使用了本身的 API 接口，因此命令系統是另一套系統，這也是 kubernetes 門檻比較高的緣由所在。

大部分的應用程序咱們在部署的時候都會適當的添加監控，對於運行載體容器則更應該如此。kubernetes 提供了 liveness probes 來檢查咱們的應用程序，它是由節點上的 kubelet 按期執行的。

知識圖譜

主要介紹學習一些什麼知識

軟件架構

傳統的客戶端服務端架構

• 架構說明

Kubernetes 遵循很是傳統的客戶端/服務端的架構模式，客戶端能夠經過 RESTful 接口或者直接使用 kubectl 與 Kubernetes 集羣進行通訊，這二者在實際上並無太多的區別，後者也只是對 Kubernetes 提供的 RESTful API 進行封裝並提供出來。每個 Kubernetes 集羣都是由一組 Master 節點和一系列的 Worker 節點組成，其中 Master 節點主要負責存儲集羣的狀態併爲 Kubernetes 對象分配和調度資源。

• 主節點服務 - Master 架構

做爲管理集羣狀態的 Master 節點，它主要負責接收客戶端的請求，安排容器的執行而且運行控制循環，將集羣的狀態向目標狀態進行遷移。Master 節點內部由下面三個組件構成：

API Server: 負責處理來自用戶的請求，其主要做用就是對外提供 RESTful 的接口，包括用於查看集羣狀態的讀請求以及改變集羣狀態的寫請求，也是惟一一個與 etcd 集羣通訊的組件。

etcd: 是兼具一致性和高可用性的鍵值數據庫，能夠做爲保存 Kubernetes 全部集羣數據的後臺數據庫。

Scheduler: 主節點上的組件，該組件監視那些新建立的未指定運行節點的 Pod，並選擇節點讓 Pod 在上面運行。調度決策考慮的因素包括單個 Pod 和 Pod 集合的資源需求、硬件/軟件/策略約束、親和性和反親和性規範、數據位置、工做負載間的干擾和最後時限。

controller-manager: 在主節點上運行控制器的組件，從邏輯上講，每一個控制器都是一個單獨的進程，可是爲了下降複雜性，它們都被編譯到同一個可執行文件，並在一個進程中運行。這些控制器包括：節點控制器(負責在節點出現故障時進行通知和響應)、副本控制器(負責爲系統中的每一個副本控制器對象維護正確數量的 Pod)、端點控制器(填充端點 Endpoints 對象，即加入 Service 與 Pod))、服務賬戶和令牌控制器(爲新的命名空間建立默認賬戶和 API 訪問令牌)。

• 工做節點 - Node 架構

其餘的 Worker 節點實現就相對比較簡單了，它主要由 kubelet 和 kube-proxy 兩部分組成。

kubelet: 是工做節點執行操做的 agent，負責具體的容器生命週期管理，根據從數據庫中獲取的信息來管理容器，並上報 pod 運行狀態等。

kube-proxy: 是一個簡單的網絡訪問代理，同時也是一個 Load Balancer。它負責將訪問到某個服務的請求具體分配給工做節點上同一類標籤的 Pod。kube-proxy 實質就是經過操做防火牆規則(iptables或者ipvs)來實現 Pod 的映射。

Container Runtime: 容器運行環境是負責運行容器的軟件，Kubernetes 支持多個容器運行環境: Docker、 containerd、cri-o、 rktlet 以及任何實現 Kubernetes CRI(容器運行環境接口)。

組件說明

主要介紹關於 K8s 的一些基本概念

主要由如下幾個核心組件組成：

• apiserver

• 全部服務訪問的惟一入口，提供認證、受權、訪問控制、API 註冊和發現等機制

• controller manager

• 負責維護集羣的狀態，好比副本指望數量、故障檢測、自動擴展、滾動更新等

• scheduler

• 負責資源的調度，按照預約的調度策略將 Pod 調度到相應的機器上

• etcd

• 鍵值對數據庫，保存了整個集羣的狀態

• kubelet

• 負責維護容器的生命週期，同時也負責 Volume 和網絡的管理

• kube-proxy

• 負責爲 Service 提供 cluster 內部的服務發現和負載均衡

• Container runtime

• 負責鏡像管理以及 Pod 和容器的真正運行

除了核心組件，還有一些推薦的插件：

• CoreDNS

• 能夠爲集羣中的 SVC 建立一個域名 IP 的對應關係解析的 DNS 服務

• Dashboard

• 給 K8s 集羣提供了一個 B/S 架構的訪問入口

• Ingress Controller
• 官方只可以實現四層的網絡代理，而 Ingress 能夠實現七層的代理
• Prometheus
• 給 K8s 集羣提供資源監控的能力
• Federation

• 提供一個能夠跨集羣中心多 K8s 的統一管理功能，提供跨可用區的集羣

做者: Escape
連接: https://www.escapelife.site/p...