Kubernetes 原理架構介紹(一)
目錄
一、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，除此以外，管理員可以可以建立新的名字空間滿足需要。
參考文件：http://docs.kubernetes.org.cn/251.html
參考檔案：https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/