K8s 原理架構介紹(一)

一、Kubernetes 是什么

Kubernetes是當今最流行的開源容器管理平臺，它就是大名鼎鼎的Google Borg的開源版本。Google在2014年推出了Kubernetes，本文發布時最新的版本是1.11。

Kubernetes源于希臘語，意為舵手，K8S是一個簡稱，因為首尾字母中間正好有8個字母。基于容器技術，Kubernetes可以方便的進行集群應用的部署、擴容、縮容、自愈機制、服務發現、負載均衡、日志、監控等功能，大大減少日常運維的工作量。

Kubernetes所有的操作都可以通過Kubernetes API來進行，通過API來操作Kubernetes中的對象，包括Pod、Service、Volume、Namespace等等。

二、Kubernetes 設計架構

Kubernetes借鑒了Borg的設計理念，比如Pod、Service、Labels和單Pod單IP等。Kubernetes的整體架構跟Borg非常像，如下圖所示：

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

• etcd保存了整個集群的狀態；
• apiserver提供了資源操作的唯一入口，并提供認證、授權、訪問控制、API注冊和發現等機制；
• controller manager負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；
• scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；
• kubelet負責維護容器的生命周期，同時也負責Volume（CVI）和網絡（CNI）的管理；
• Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；
• kube-proxy負責為Service提供cluster內部的服務發現和負載均衡；

除了核心組件，還有一些推薦的Add-ons：

• kube-dns負責為整個集群提供DNS服務
• Ingress Controller為服務提供外網入口
• Heapster提供資源監控
• Dashboard提供GUI
• Federation提供跨可用區的集群
• Fluentd-elasticsearch提供集群日志采集、存儲與查詢

三、Kubernetes的核心技術概念和API對象

API對象是K8s集群中的管理操作單元。K8s集群系統每支持一項新功能，引入一項新技術，一定會新引入對應的API對象，支持對該功能的管理操作。例如副本集Replica Set對應的API對象是RS。

每個API對象都有3大類屬性：元數據metadata、規范spec和狀態status。元數據是用來標識API對象的，每個對象都至少有3個元數據：namespace，name和uid；除此以外還有各種各樣的標簽labels用來標識和匹配不同的對象，例如用戶可以用標簽env來標識區分不同的服務部署環境，分別用env=dev、env=testing、env=production來標識開發、測試、生產的不同服務。規范描述了用戶期望K8s集群中的分布式系統達到的理想狀態（Desired State），例如用戶可以通過復制控制器Replication Controller設置期望的Pod副本數為3；status描述了系統實際當前達到的狀態（Status），例如系統當前實際的Pod副本數為2；那么復制控制器當前的程序邏輯就是自動啟動新的Pod，爭取達到副本數為3。

K8s中所有的配置都是通過API對象的spec去設置的，也就是用戶通過配置系統的理想狀態來改變系統，這是k8s重要設計理念之一，即所有的操作都是聲明式（Declarative）的而不是命令式（Imperative）的。聲明式操作在分布式系統中的好處是穩定，不怕丟操作或運行多次，例如設置副本數為3的操作運行多次也還是一個結果，而給副本數加1的操作就不是聲明式的，運行多次結果就錯了。

Cluster

Cluster 是計算、存儲和網絡資源的集合，Kubernetes 利用這些資源運行各種基于容器的應用。

Master

Master 是 Cluster 的大腦，它的主要職責是調度，即決定將應用放在哪里運行。Master 運行 Linux 操作系統，可以是物理機或者虛擬機。為了實現高可用，可以運行多個 Master。

Node

Node 的職責是運行容器應用。Node 由 Master 管理，Node 負責監控并匯報容器的狀態，并根據 Master 的要求管理容器的生命周期。Node 運行在 Linux 操作系統，可以是物理機或者是虛擬機。

Pod

Pod 是 Kubernetes 的最小工作單元。每個 Pod 包含一個或多個容器。Pod 中的容器會作為一個整體被 Master 調度到一個 Node 上運行。

Kubernetes 引入 Pod 主要基于下面兩個目的：

• 可管理性
  有些容器天生就是需要緊密聯系，一起工作。Pod 提供了比容器更高層次的抽象，將它們封裝到一個部署單元中。Kubernetes 以 Pod 為最小單位進行調度、擴展、共享資源、管理生命周期。

• 通信和資源共享
  Pod 中的所有容器使用同一個網絡 namespace，即相同的 IP 地址和 Port 空間。它們可以直接用 localhost 通信。同樣的，這些容器可以共享存儲，當 Kubernetes 掛載 volume 到 Pod，本質上是將 volume 掛載到 Pod 中的每一個容器。

File Puller 會定期從外部的 Content Manager 中拉取最新的文件，將其存放在共享的 volume 中。Web Server 從 volume 讀取文件，響應 Consumer 的請求。這兩個容器是緊密協作的，它們一起為 Consumer 提供最新的數據；同時它們也通過 volume 共享數據。所以放到一個 Pod 是合適的。

Controller

Kubernetes 通常不會直接創建 Pod，而是通過 Controller 來管理 Pod 的。Controller 中定義了 Pod 的部署特性，比如有幾個副本，在什么樣的 Node 上運行等。為了滿足不同的業務場景，Kubernetes 提供了多種 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我們逐一討論。

Deployment

Deployment 是最常用的 Controller，比如前面在線教程中就是通過創建 Deployment 來部署應用的。Deployment 可以管理 Pod 的多個副本，并確保 Pod 按照期望的狀態運行。

ReplicaSet

ReplicaSet 實現了 Pod 的多副本管理。使用 Deployment 時會自動創建 ReplicaSet，也就是說 Deployment 是通過 ReplicaSet 來管理 Pod 的多個副本，我們通常不需要直接使用 ReplicaSet。

DaemonSet

DaemonSet 用于每個 Node 最多只運行一個 Pod 副本的場景。正如其名稱所揭示的，DaemonSet 通常用于運行 daemon。

StatefuleSet

StatefuleSet 能夠保證 Pod 的每個副本在整個生命周期中名稱是不變的。而其他 Controller 不提供這個功能，當某個 Pod 發生故障需要刪除并重新啟動時，Pod 的名稱會發生變化。同時 StatefuleSet 會保證副本按照固定的順序啟動、更新或者刪除。

Job

Job 用于運行結束就刪除的應用。而其他 Controller 中的 Pod 通常是長期持續運行。

Service

RC、RS和Deployment只是保證了支撐服務的微服務Pod的數量，但是沒有解決如何訪問這些服務的問題。一個Pod只是一個運行服務的實例，隨時可能在一個節點上停止，在另一個節點以一個新的IP啟動一個新的Pod，因此不能以確定的IP和端口號提供服務。要穩定地提供服務需要服務發現和負載均衡能力。服務發現完成的工作，是針對客戶端訪問的服務，找到對應的的后端服務實例。在K8s集群中，客戶端需要訪問的服務就是Service對象。每個Service會對應一個集群內部有效的虛擬IP，集群內部通過虛擬IP訪問一個服務。在K8s集群中微服務的負載均衡是由Kube-proxy實現的。Kube-proxy是K8s集群內部的負載均衡器。它是一個分布式代理服務器，在K8s的每個節點上都有一個；這一設計體現了它的伸縮性優勢，需要訪問服務的節點越多，提供負載均衡能力的Kube-proxy就越多，高可用節點也隨之增多。與之相比，我們平時在服務器端做個反向代理做負載均衡，還要進一步解決反向代理的負載均衡和高可用問題。

Kubernetes 運行容器（Pod）與訪問容器（Pod）這兩項任務分別由 Controller 和 Service 執行。

Namespace

名字空間為K8s集群提供虛擬的隔離作用，K8s集群初始有兩個名字空間，分別是默認名字空間default和系統名字空間kube-system，除此以外，管理員可以可以創建新的名字空間滿足需要。

三、創建 Pod 流程

參考文檔：http://docs.kubernetes.org.cn/251.html
參考文件：https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/