目錄
1.K8S相關概念
-
Cluster
Cluster由多臺虛擬機或者物理設備組成，是計算、存儲和網絡等資源的集合，K8S利用這些資源運行各種基於容器的應用。
-
Master
Master是Cluster集羣的大腦，它的主要職責是調度、即決定將應用放在哪個節點運行。Master 運行 Linux 操作系統，可以是物理機或者虛擬機。爲了實現高可用，可以運行多個 Master。
-
Node
Node是用於運行容器應用的節點。Node由Master管理，Node主要負責監控並彙報容器的狀態，並根據Master的要求管理容器的生命週期。Node運行在Linux操作系統上，可以是物理機或者虛擬機。
-
Pod
Pod是K8S的最小工作單元。每個Pod可以包含一個或者多個有緊密聯繫的容器應用。Pod中的容器回作爲一個整體被Master調度到一個Node上運行。（Pod如何創建？通過Master上的Controller Manager）
K8S引入Pod主要基於下面兩個目的：
-
可管理性。
有些容器天生就是需要緊密聯繫，一起工作。Pod 提供了比容器更高層次的抽象，將它們封裝到一個部署單元中。Kubernetes 以 Pod 爲最小單位進行調度、擴展、共享資源、管理生命週期。 -
通信和資源共享。
Pod 中的所有容器使用同一個網絡 namespace，即相同的 IP 地址和 Port 空間。它們可以直接用 localhost 通信。同樣的，這些容器可以共享存儲，當 Kubernetes 掛載 volume 到 Pod，本質上是將 volume 掛載到 Pod 中的每一個容器。
Pods的使用方式：
-
運行單一容器。
one-container-per-Pod是 Kubernetes 最常見的模型，這種情況下，只是將單個容器簡單封裝成 Pod。即便是隻有一個容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。 -
運行多個容器。
但問題在於：哪些容器應該放到一個 Pod 中？
答案是：這些容器聯繫必須 非常緊密，而且需要 直接共享資源。
Example：
下圖的Pod包含兩個容器：一個File Puller，一個是Web Server。
File Puller 會定期從外部的 Content Manager 中拉取最新的文件，將其存放在共享的 volume 中。Web Server 從 volume 讀取文件，響應 Consumer 的請求。這兩個容器是緊密協作的，它們一起爲 Consumer 提供最新的數據；同時它們也通過 volume 共享數據。所以放到一個 Pod 是合適的。
再來看一個反例：是否需要將 Tomcat 和 MySQL 放到一個 Pod 中？
Tomcat 從 MySQL 讀取數據，它們之間需要協作，但還不至於需要放到一個 Pod 中一起部署，一起啓動，一起停止。同時它們是之間通過 JDBC 交換數據，並不是直接共享存儲，所以放到各自的 Pod 中更合適。
-
Controller Manager
Controller Manager作爲集羣內部的管理控制中心，負責集羣內的Node，Pod副本，服務端點（endpoint），命名空間（namespace）等的管理，當某個Node意外宕機，CM會及時發現此故障並執行自動化修復流程，確保集羣始終處於預期的工作狀態。
K8S通常不會直接創建Pod。而是通過CM來管理Pods的，Controller Manager中定義了Pod的部署特性，比如有幾個副本，在哪個Node上運行等，CM有許多不同的Controller，用來提供各種功能。如下圖：
每個Controller通過API Server提供的接口實時監控整個集羣的每個資源對象的當前狀態，當發生各種故障導致系統狀態發生變化時，會嘗試將系統狀態修復到“期望狀態”。
-
Service
Deployment Controller爲Pod和Replication Set通過聲明示更新，通過它夠可以創建出多個Pod，每個Pod都有自己的IP，那麼外界如何去訪問這些Pod呢？通過Pod的IP嗎？這肯定是不行對的，Pod可能會被頻繁地創建，銷燬，或者重啓，它們的IP會頻繁地變化，用Pod的IP去訪問不太現實。
答案是使用Service。
Service在K8S中主要提供的功能是負載均衡和服務自動發現，它提供了我們訪問單個或者多個容器應用的能力。每個Service在其生命週期內，都擁有一個固定的IP地址和端口（所以Pod的IP變化，不會影響到這個Pod的上層Service的IP地址變化）。這樣也方便後端進行Pod的彈性伸縮等操作。
所有說K8S運行Pod和訪問Pod這兩項任務分別由Controller和Service執行。
-
NameSpace
我們可以認爲NameSpace是K8S Cluster中的虛擬化集羣。在一個K8S集羣中可以有多個命名空間，這些命名空間在邏輯上彼此隔離。常見的pods, services, replication controllers和deployments等都是屬於某一個NameSpace的（默認是default）。
類似於default這樣的默認NameSpace，K8S集羣共有三個：
- default：創建資源時如果不指定NameSpace的話，默認將被放到default中
- kube-system：kubernetes系統組件使用。
- kube-public：公共資源使用。但實際上現在並不常用。
2.K8S架構和集羣規劃
-
K8S架構
-
K8S架構拆解圖
K8S Master節點
從上圖可以看到K8S Cluster的大腦，運行着的Daemon服務包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod網絡（例如flannel）。
1. API Server （kube-apiserver)
API Server提供HTTP/HTTPS RESTful API，即Kubernetes API。API Server是Kubernetes Cluster的前端接口，各種客戶端工具（CLI或UI）以及Kubernetes其他組件可以通過它管理Cluster的各種資源。
2. Scheduler（kube-scheduler）
Scheduler負責決定將Pod放在哪個Node上運行。Scheduler在調度時會充分考慮Cluster的拓撲結構，當前各個節點的負載，以及應用對高可用、性能、數據親和性的需求。
3. Controller Manager（kube-controller-manager）
Controller Manager負責管理Cluster各種資源，保證資源處於預期的狀態。Controller Manager 由多種Controller組成，包括replication controller、endpoint controller、namespace controller、serviceaccounts controller等。
不同的controller管理不同的資源。例如，replication controller管理Deployment、StatefulSet、DaemonSet的生命週期，namespace controller管理Namespace資源。
4. etcd
etcd負責保存Kubernetes Cluster的配置信息和各種資源的狀態信息。當數據發生變化時，etcd會快速通知Kubernetes相關組件。
5. Pod網絡
Pod要能夠相同通信，Kubernetes Cluster必須部署Pod網絡，flannel是其中一個可選方案。
K8S Node節點
Node是Kubernetes集羣架構中運行Pod的服務節點（亦叫agent或minion）。Node是Kubernetes集羣操作的單元，用來承載被分配Pod的運行，是Pod運行的宿主機。關聯Master管理節點，擁有名稱和IP、系統資源信息。運行docker eninge服務，守護進程kunelet及負載均衡器kube-proxy.
- 每個Node節點都運行着以下一組關鍵進程
- kubelet：負責對Pod對於的容器的創建、啓停等任務
- kube-proxy：實現Kubernetes Service的通信與負載均衡機制的重要組件
- Docker Engine（Docker）：Docker引擎，負責本機容器的創建和管理工作
Node節點可以在運行期間動態增加到Kubernetes集羣中，默認情況下，kubelet會向master註冊自己，這也是Kubernetes推薦的Node管理方式，kubelet進程會定時向Master彙報自身情報，如操作系統、Docker版本、CPU和內存，以及有哪些Pod在運行等等，這樣Master可以獲知每個Node節點的資源使用情況，冰實現高效均衡的資源調度策略。
1. Kubelet：kubelet是node的agent，當Scheduler確定在某個Node上運行Pod後，會將Pod的具體配置信息（image、volume等）發送給該節點的kubelet，kubelet會根據這些信息創建和運行容器，並向master報告運行狀態。
2. Kube-proxy: service在邏輯上代表了後端的多個Pod，外借通過service訪問Pod。service接收到請求就需要kube-proxy完成轉發到Pod的。每個Node都會運行kube-proxy服務，負責將訪問的service的TCP/UDP數據流轉發到後端的容器，如果有多個副本，kube-proxy會實現負載均衡，有2種方式：LVS或者Iptables。
3. 容器運行時環境，如Docker, rkt, runc等：負責節點的容器的管理工作。
K8S中Pod的創建流程
創建Pod 的流程
1. 用戶通過REST API創建一個Pod
2. apiserver將其寫入etcd
3. scheduluer檢測到未綁定Node的Pod，開始調度並更新Pod的Node綁定
4. kubelet檢測到有新的Pod調度過來，通過container runtime運行該Pod
5. kubelet通過container run
參考：《每天5分鐘玩轉Kubernetes》、https://www.cnblogs.com/linuxk/