一 Kubernetes概述

Kubernetes是一個全新的基於容器技術的分散式架構領先方案。Kubernetes(k8s)是Google開源的容器叢集管理系統（谷歌內部:Borg）。在Docker技術的基礎上，為容器化的應用提供部署執行、資源排程、服務發現和動態伸縮等一系列完整功能，提高了大規模容器叢集管理的便捷性。 　　Kubernetes是一個完備的分散式系統支撐平臺，具有完備的叢集管理能力，多擴多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智慧負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和線上擴容能力、可擴充套件的資源自動排程機制以及多粒度的資源配額管理能力。 同時Kubernetes提供完善的管理工具，涵蓋了包括開發、部署測試、運維監控在內的各個環節。 Kubernetes中，Service是分散式叢集架構的核心，一個Service物件擁有如下關鍵特徵：

1. 擁有一個唯一指定的名字
2. 擁有一個虛擬IP（Cluster IP、Service IP、或VIP）和埠號
3. 能夠提供某種遠端服務能力
4. 被對映到了提供這種服務能力的一組容器應用上

　　Service的服務程序目前都是基於Socket通訊方式對外提供服務，比如Redis、Memcache、MySQL、Web Server，或者是實現了某個具體業務的一個特定的TCP Server程序，雖然一個Service通常由多個相關的服務程序來提供服務，每個服務程序都有一個獨立的Endpoint（IP+Port）訪問點，但Kubernetes能夠讓我們通過服務連線到指定的Service上。有了Kubernetes內建的透明負載均衡和故障恢復機制，不管後端有多少服務程序，也不管某個服務程序是否會由於發生故障而重新部署到其他機器，都不會影響我們對服務的正常呼叫，更重要的是這個Service本身一旦建立就不會發生變化，意味著在Kubernetes叢集中，我們不用為了服務的IP地址的變化問題而進行修復。 　　容器提供了強大的隔離功能，所以有必要把為Service提供服務的這組程序放入容器中進行隔離。為此，Kubernetes設計了Pod物件，將每個服務程序包裝到相對應的Pod中，使其成為Pod中執行的一個容器。為了建立Service與Pod間的關聯管理，Kubernetes給每個Pod貼上一個標籤Label，比如執行MySQL的Pod貼上name=mysql標籤，給執行PHP的Pod貼上name=php標籤，然後給相應的Service定義標籤選擇器Label Selector，這樣就能巧妙的解決了Service於Pod的關聯問題。 Pod執行在一個稱之為節點（Node）的環境中，節點可以是物理機，也可以是虛擬機器，通過一個節點執行幾百個Pod；其次每個Pod裡執行著一個特殊的稱之為Pause的容器，其他容器則為業務容器，所有業務容器共享Pause容器的網路棧和Volume掛載卷，因此他們之間的通訊和互動更為高效，因此在設計之初可以將一組密切相關聯的服務程序放入同一個Pod中。 　　在叢集管理方面，Kubernetes將叢集中的機器劃分為一個Master節點和一群工作節點Node，其中，在Master節點執行著叢集管理相關的一組程序kube-apiserver、kube-controller-manager和kube-scheduler，這些程序實現了整個叢集的資源管理、Pod排程、彈性伸縮、安全控制、系統監控和糾錯等管理能力，並且都是全自動完成的。Node作為叢集中的工作節點，執行真正的應用程式，在Node上Kubernetes管理的最小執行單元是Pod。Node上執行著Kubernetes的kubelet、kube-proxy服務程序，這些服務程序負責Pod的建立、啟動、監控、重啟、銷燬以及實現軟體模式的負載均衡器。 　　在Kubernetes叢集中，它解決了傳統IT系統中服務擴容和升級的兩大難題。你只需為需要擴容的Service關聯的Pod建立一個Replication Controller簡稱（RC），則該Service的擴容及後續的升級等問題將迎刃而解。在一個RC定義檔案中包括以下3個關鍵資訊。

1. 目標Pod的定義
2. 目標Pod需要執行的副本數量（Replicas）
3. 要監控的目標Pod標籤（Label）

　　在建立好RC後，Kubernetes會通過RC中定義的的Label篩選出對應Pod例項並實時監控其狀態和數量，如果例項數量少於定義的副本數量，則會根據RC中定義的Pod模板來建立一個新的Pod，然後將新Pod排程到合適的Node上啟動執行，直到Pod例項的數量達到預定目標，這個過程完全是自動化。

二 Kubernetes優勢、場景、特點

Kubernetes主要優勢:

• 容器編排
• 輕量級
• 開源
• 彈性伸縮
• 負載均衡

Kubernetes常見場景：

• 快速部署應用
• 快速擴充套件應用
• 無縫對接新的應用功能
• 節省資源，優化硬體資源的使用

Kubernetes相關特點：

• 可移植: 支援公有云，私有云，混合雲，多重雲（multi-cloud）
• 可擴充套件: 模組化, 外掛化, 可掛載, 可組合
• 自動化: 自動部署，自動重啟，自動複製，自動伸縮/擴充套件

三 Kubetcl的核心概念

3.1 Master

　　k8s叢集的管理節點，負責管理叢集，提供叢集的資源資料訪問入口。擁有Etcd儲存服務（可選），執行Api Server程序，Controller Manager服務程序及Scheduler服務程序，關聯工作節點Node。

• Kubernetes API server提供HTTP Rest介面的關鍵服務程序，是Kubernetes裡所有資源的增、刪、改、查等操作的唯一入口。也是叢集控制的入口程序；
• Kubernetes Controller Manager是Kubernetes所有資源物件的自動化控制中心；
• Kubernetes Schedule是負責資源排程（Pod排程）的程序。

3.2 Node

　　Node是Kubernetes叢集架構中執行Pod的服務節點（亦叫agent或minion）。Node是Kubernetes叢集操作的單元，用來承載被分配Pod的執行，是Pod執行的宿主機。關聯Master管理節點，擁有名稱和IP、系統資源資訊。執行docker eninge服務，守護程序kunelet及負載均衡器kube-proxy. 每個Node節點都執行著以下一組關鍵程序

1. kubelet：負責對Pod對於的容器的建立、啟停等任務，同時與Master節點協作，實現叢集管理的基本功能；
2. kube-proxy：實現Kubernetes Service的通訊與負載均衡機制的重要元件；
3. Docker Engine（Docker）：Docker引擎，負責本機容器的建立和管理工作。

　　Node節點可以在執行期間動態增加到Kubernetes叢集中，預設情況下，kubelet會想master註冊自己，這也是Kubernetes推薦的Node管理方式，kubelet程序會定時向Master彙報自身情報，如作業系統、Docker版本、CPU和記憶體，以及有哪些Pod在執行等等，這樣Master可以獲知每個Node節點的資源使用情況，並實現高效均衡的資源排程策略。

3.3 Pod

　　運行於Node節點上，若干相關容器的組合。Pod內包含的容器執行在同一宿主機上，使用相同的網路名稱空間、IP地址和埠，能夠通過localhost進行通訊。Pod是Kurbernetes進行建立、排程和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關容器。 　　Pod有兩種型別：普通Pod和靜態Pod。後者比較特殊，它並不存在Kubernetes的etcd儲存中，而是存放在某個具體的Node上的一個具體檔案中，並且只在此Node上啟動。普通Pod一旦被建立，就會被放入etcd儲存中，隨後會被Kubernetes Master排程到摸個具體的Node上進行繫結，隨後該Pod被對應的Node上的kubelet程序例項化成一組相關的Docker容器並啟動起來，在預設情況下，當Pod裡的某個容器停止時，Kubernetes會自動檢測到這個問題並且重啟這個Pod（重啟Pod裡的所有容器），如果Pod所在的Node宕機，則會將這個Node上的所有Pod重新排程到其他節點上。 Pod的IP與ContainerPort（容器埠）共同構成了Endpoint，表示此Pod中的一個服務程序對外的通訊地址。 每個Pod也可以對其能使用的資源設定相應配額，CPU和記憶體的數值都為絕對值，CPU通常定義為千分之一單位，如100-300m，表示佔用0.1——0.3個CPU，記憶體通常以位元組數表示，如64Mi。

3.4 Label（標籤）

Kubernetes中的任意API物件都是通過Label進行標識，Label的實質是一系列的Key/Value鍵值對，其中key與value可自定義。Label可以附加到各種資源物件上，如Node、Pod、Service、RC等，一個資源物件可以定義任意數量的Label，同一個Label也可以被新增到任意數量的資源物件上去。Label是Replication Controller和Service執行的基礎，二者通過Label來進行關聯Node上執行的Pod,可以通過Label Selector（標籤選擇器）查詢和篩選資源物件。 一些常用的Label如下：

• 版本標籤："release":"stable","release":"canary"......
• 環境標籤："environment":"dev","environment":"qa","environment":"production"
• 架構標籤："tier":"frontend","tier":"backend","tier":"middleware"
• 分割槽標籤："partition":"customerA","partition":"customerB"
• 質量管控標籤："track":"daily","track":"weekly"

　　Label相當於我們熟悉的標籤，給某個資源物件定義一個Label就相當於給它大了一個標籤，隨後可以通過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源物件，Kubernetes通過這種方式實現了類似SQL的簡單又通用的物件查詢機制。 Label和Label Selector共同構成了Kubernetes系統中最核心的應用模型，是的被管理物件能夠被精細的分組管理，同時實現了整個叢集的高可用性。 Label場景：

• kube-Controller程序通過資源物件RC上定義Label Selector來篩選要監控的Pod副本的數量，從而實現副本數量始終符合預期設定的全自動控制流程
• kube-proxy程序通過Service的Label Selector來選擇對應的Pod，自動建立起每個Service島對應Pod的請求轉發路由表，從而實現Service的智慧負載均衡
• 通過對某些Node定義特定的Label，並且在Pod定義檔案中使用Nodeselector這種標籤排程策略，kuber-scheduler程序可以實現Pod”定向排程“的特性。

3.5 Replication Controller

　　Replication Controller用來管理Pod的副本，保證叢集中存在指定數量的Pod副本。叢集中副本的數量大於指定數量，則會停止指定數量之外的多餘容器數量，反之，則會啟動少於指定數量個數的容器，保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。 定義RC包括如下幾個部分：

• Pod期待的副本數（replicas）；
• 用於篩選目標Pod的Label Selector；
• 當Pod的副本數小於預期數量時，用於建立Pod的Pod模板（template）。

RC機制： 當定義了RC並提交至Kubernetes叢集中之後，Master節點上的Controller Manager元件獲悉，並同時巡檢系統中當前存活的目標Pod，並確保目標Pod例項的數量剛好等於此RC的期望值，若存在過多的Pod副本在執行，系統會停止一些Pod，反之則自動建立一些Pod。 注意：刪除RC並不會影響通過該RC已經建立的Pod。 提示：下一代RC，即Replica Sets與RC唯一的區別是RS支援基於集合的Label selector。 RC特性及場景：

• 通過定義RC實現Pod的建立過程及副本數量自動控制；
• RC裡包括完整的Pod定義模板；
• RC通過Label Selector機制實現副本的自動控制；
• 通過改變RC裡的Pod副本數量，可以實現Pod的擴容或縮容功能；
• 通過改變RC的Pod模板的映象版本，可以實現Pod的滾動升級功能。

3.6 Deployment

Deployment在內部使用了RS來實現目的，Deployment相當於RC的一次升級，其最大的特色為可以隨時獲知當前Pod的部署進度。 Deployment場景：

• 建立一個Deployment物件來生成對應的RS並完成Pod副本的建立過程；
• 檢查Deployment的狀態來看部署動作是否完成（即副本數量是否達到預期值）；
• 更新Deployment以建立新的Pod（比如映象升級）；
• 如果當前Deployment不穩定，則回滾到一個早先Deployment版本；
• 掛起或恢復一個Deployment。

3.7 HPA（Horizontal Pod Autoscaler）

Pod的橫向自動擴容，也是Kubernetes的一種資源，通過追蹤分析RC控制的所有Pod目標的負載變化情況，來確定是否需要針對性的調整Pod副本數量。 HPA針對Pod負載的兩種度量方式：

• CPUUtilizationPercentage；
• 應用程式自定義的度量指標。

3.8 Service

　　Service定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，使用者不需要了解後臺Pod是如何執行。 外部系統訪問Service的機制： Kubernetes的三種IP：

• Node IP：Node節點的IP地址
• Pod IP： Pod的IP地址
• Cluster IP：Service的IP地址

　　首先,Node IP是Kubernetes叢集中節點的物理網絡卡IP地址，所有屬於這個網路的伺服器之間都能通過這個網路直接通訊。這也表明Kubernetes叢集之外的節點訪問Kubernetes叢集之內的某個節點或者TCP/IP服務的時候，必須通過Node IP進行通訊； 　　其次，Pod IP是每個Pod的IP地址，他是Docker Engine根據docker0網橋的IP地址段進行分配的，通常是一個虛擬的二層網路； 　　最後Cluster IP是一個虛擬的IP，但更像是一個偽造的IP網路，Cluster IP特點：

1. Cluster IP僅僅作用於Kubernetes Service這個物件，並由Kubernetes管理和分配P地址；
2. Cluster IP無法被ping，他沒有一個“實體網路物件”來響應；
3. Cluster IP只能結合Service Port組成一個具體的通訊埠，單獨的Cluster IP不具備通訊的基礎，並且他們屬於Kubernetes叢集這樣一個封閉的空間。
4. Kubernetes叢集之內，Node IP網、Pod IP網與Cluster IP網之間的通訊，採用的是Kubernetes自己設計的一種區別於常規的IP路由的程式設計方式的特殊路由規則。

3.9 Volume（儲存卷）

Volume是Pod中能夠被多個容器訪問的共享目錄，Kubernetes中的Volume是定義在Pod上，可以被一個或多個Pod中的容器掛載到某個目錄下。Kubernetes中的Volume與Pod的生命週期相同，與容器的生命週期並無直接關係。Kubernetes的Volume支援多種型別的後端驅動，如glusterfs、ceph。 Volume常見型別：

• emptyDir：為Pod分配到Node的時候建立。無需指定宿主機的目錄檔案，為Kubernetes自動分配的目錄。

場景： 臨時空間，用於某些應用程式執行時所需的臨時目錄，且無須永久儲存； 長時間任務的中間過程CheckPoint的臨時儲存目錄； 一個容器需要從另一個容器中獲取資料的目錄（多容器共享目錄）。

• hostPath：為在Pod上掛載宿主機上的檔案或目錄。

場景： 容器應用程式生產的日誌檔案需要永久儲存，可以使用宿主機的高速檔案系統進行儲存； 需要訪問宿主機的Docker內部資料結構的容器。可指定hostPath為/var/lib/docker，使容器內部應用直接訪問Docker的檔案系統；

提示：若不同Node上具有相同配置的Pod可能因為宿主機的目錄結構不一致從而導致訪問結構不一致。

• NFS：NFS網路檔案系統；
• iSCSI：iSCSI儲存裝置；
• flocker；
• rbd：
• glusterfs。

3.10 Namespace（名稱空間）

Namespace用於實現多租戶的資源隔離，可將叢集內部的資源物件分配到不同的Namespace中，形成邏輯上的不同專案、小組或使用者組，便於不同的Namespace在共享使用整個叢集的資源的同時還能被分別管理。 提示：Kubernetes叢集在啟動後，會建立一個名為“default”的Namespace，且預設情況下Kubernetes的相關資源，如Pod、RC、Service都將被系統建立到此預設名為default的Namespace中。

3.11 Annotation（註釋）

Annotation類似Label，也使用key/value形式進行定義。Annotation是使用者任意定義的“附加資訊”，如電話號碼、負責人、網站等等。  

四 Kubernetes 元件簡述

Kubernetes Master控制組件，排程管理整個系統（叢集），包含如下元件: Kubernetes API Server 作為Kubernetes系統的入口，其封裝了核心物件的增刪改查操作，以RESTful API介面方式提供給外部客戶和內部元件呼叫。維護的REST物件持久化到Etcd中儲存。 Kubernetes Scheduler 為新建立的Pod進行節點(node)選擇(即分配機器)，負責叢集的資源排程。元件抽離，可以方便替換成其他排程器。 Kubernetes Controller 負責執行各種控制器，目前已經提供了很多控制器來保證Kubernetes的正常執行。 Replication Controller 管理維護Replication Controller，關聯Replication Controller和Pod，保證Replication Controller定義的副本數量與實際執行Pod數量一致。 Node Controller 管理維護Node，定期檢查Node的健康狀態，標識出(失效|未失效)的Node節點。 Namespace Controller 管理維護Namespace，定期清理無效的Namespace，包括Namesapce下的API物件，比如Pod、Service等。 Service Controller 管理維護Service，提供負載以及服務代理。 EndPoints Controller 管理維護Endpoints，關聯Service和Pod，建立Endpoints為Service的後端，當Pod發生變化時，實時更新Endpoints。 Service Account Controller 管理維護Service Account，為每個Namespace建立預設的Service Account，同時為Service Account建立Service Account Secret。 Persistent Volume Controller 管理維護Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進行繫結，為釋放的Persistent Volume執行清理回收。 Daemon Set Controller 管理維護Daemon Set，負責建立Daemon Pod，保證指定的Node上正常的執行Daemon Pod。 Deployment Controller 管理維護Deployment，關聯Deployment和Replication Controller，保證執行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和　Pod的更新。 Job Controller 管理維護Job，為Jod建立一次性任務Pod，保證完成Job指定完成的任務數目 Pod Autoscaler Controller 實現Pod的自動伸縮，定時獲取監控資料，進行策略匹配，當滿足條件時執行Pod的伸縮動作。   參考：https://blog.csdn.net/qq_35254726/article/details/54233781