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