今天分享如題：

Kubernetes

? ?

本篇內容源于工作項目需要自學

但K8s確實現在十分的主流so推薦給大家

最近更新緩慢由于工作太忙惹，忙里偷閑整理愿分享能與君共勉💪

大家新年快樂🎉

🔈言歸正題，相信很多朋友在學習K8S的時候，能夠借助yaml文檔把自己的應用部署到K8S集群上，但是對于K8S內部的技術細節和實現原理并不了解，而這恰恰正是我們作為開發者提升技術所欠缺的東西。

那么今天我們就來簡單總結一下K8S的基本架構和其中的各個組件的概念和原理?

在開始正式介紹K8S之前，我們首先要搞明白一個問題：K8S是用來干什么的？?

一、 Kubernetes概況

首先，熟悉網購的朋友可能都知道，每年的雙十一期間，會有無數的訂單傳往淘寶，這對阿里的服務器系統的運算能力和承受能力是一個巨大的挑戰。毫無疑問，哪怕是一臺超級計算機，面對PB級別的訪問業務也會應接不暇。

云計算技術的日益成熟彌補了企業計算能力的不足。所謂云計算，就是把許多臺單獨的計算機的計算能力集中起來，承擔起單臺計算機無法承受的業務。實現云計算，我們不得不提到“虛擬化”技術，也就是使不同系統不同配置的機器能夠提供相同環境的技術?

而容器技術則是輕量化的虛擬技術。它不需要虛擬出整個操作系統，只需要虛擬一個小規模的環境。2013年3月，dotCloud公司的創始人之一，28歲的Solomon?Hykes正式決定，將Docker項目開源，這使得Docker容器引擎受到了廣大企業和開發者青睞。

平常使用過Docker等容器技術的朋友可能會有這樣的感受：當我們把應用部署在一個或幾個容器之中的時候，我們需要完成拉取鏡像、啟動容器、解決不同容器的通信問題、終止容器進程等等一系列操作，實在是非常不方便。也就是說，怎么實現多臺計算機之間的業務調度和資源管理，是我們必須要解決的問題。

那么，有沒有一款容器集群管理工具，能夠幫我解決這些底層的東西，讓我專注于業務本身呢？

答案當然是有的，那就是我們今天的主角

——Kubernetes，又被稱作K8S。

Kubernetes源于希臘語，有“舵”或“飛行員”的意思。而K8S，則是由Kubernetes中間的八個字母縮寫為數字8得來的。Google采用這個名字的深意就是：docker把自己定位成馱著集裝箱在大海上遨游的鯨魚，那么Kubernetes就是鯨魚的掌舵者，鯨魚必須按照其設定的路線巡游。從上邊圖片中的土撥鼠也能看得出來，Kubernetes是使用GO語言開發的。

Kubernetes是一個完備的分布式系統支撐平臺，具有完備的集群管理能力，多擴多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。同時Kubernetes提供完善的管理工具，涵蓋了包括開發、部署測試、運維監控在內的各個環節。

從K8S的定義中我們可以知道，所謂Kubernetes的核心特點，就是能夠自主地管理容器來保證云平臺中的容器按照用戶的期望狀態運行（比如用戶想讓apache一直運行，用戶不需要關心怎么去做，Kubernetes會自動去監控，然后去重啟，新建，總之，讓apache一直提供服務），同時，Kubernetes也提升了工具以及人性化方面，讓用戶能夠方便的部署自己的應用。

總而言之，Kubernetes的出現使得用戶能夠輕松地把自己的應用或業務部署在一個K8S集群上，而避免了處理集群中可能存在的調度、監控、運維、網絡等等諸多問題。那么K8S究竟是怎么做到這些的呢？接下來我們就來正式學習一下K8S集群的基本架構。

二、 Kubernetes基本架構

在正式介紹K8S的架構之前，請各位讀者先思考一個問題：如果讓你來設計一個由50臺計算機組成的集群，這個集群可以提供一臺超級計算機的計算能力和負載能力，那么你會怎么設計？

首先，我們總得有幾臺機器是專門負責對整個集群進行管理和調度的吧？如果這幾臺計算機能夠提供對外界的接口，那就太好不過了。在實際的K8S集群中，我們往往會分出幾臺計算機專門處理這樣的管理事務，它們被稱作“Master”節點。

其次，我們必須要有大量的機器負責處理實際的業務。因此，我們就可以把剩下的機器都用于提供計算能力，它們應當具有正常的運算能力和通信能力。實際中這些節點被稱作“Node”節點，而在每一個Node節點中，都運行著若干Pod進程，處理實際的業務。

1. Master

K8S集群的管理節點，負責管理集群，提供集群的資源數據訪問入口。它擁有etcd進行存儲，運行Api Server進程，Controller Manager服務進程及Scheduler服務進程，關聯工作節點Node。

kube-apiserver：是整個k8s集群對外提供服務的唯一接口，它提供請求過濾、訪問控制等機制，是各組件的協調者，此API是聲明式的（簡單說就是用戶想要什么規格的容器直接跟kube-apiserver說就行了，過程不用你管）。用戶的合法請求會被API放行，然后存入etcd中。

是否合法指的是：etcd就好像公司領導，kuber-apiserver就是門口保安，領導規定，必須什么樣的人你能放進來。k8s將etcd所能接受的數據規格范式加以封裝定義在了kube-apiserver中，符合規格才能放行。

kube-scheduler：資源調度器。kube-apiserver收到新建Pod的請求，識別其合法并存入etcd，然后kube-scheduler去watch kube-apiserver知道此需求，根據預定的調度策略評估出一個最合適Node節點來運行Pod，如果沒有最合適，那就隨機，最后會把調度的結果記錄在etcd中。關于scheduler的更多原理，請移步我的博客。

kube-controller：控制器。就好比人類的大腦一樣，負責維護集群的狀態、故障檢測與恢復、自動擴展、節點狀態等等。kube-controller有一個control loop的機制，它會循環檢測集群中Pod的狀態，假如Nginx啟的不是預期的80端口，那就由kube-controller來控制容器重啟、重建，直到達到預期效果為止。

etcd：是一個鍵值對（key:value）格式的存儲系統，保存應用程序配置信息。

總而言之，如果把ApiServer比作“接待大廳”的話，那么Controller就是負責掌控Api對象運行周期的“控制室”，Scheduler就是負責提供調度策略的“調度室”，而etcd則是存儲著所有資源對象信息的“存儲室”。

比方說，用戶發送新建Nginx容器的請求給kube-apiserver，kube-apiserver識別其合法后以鍵值對的方式存入etcd，kube-scheduler和kube-controller通過watch kube-apiserver知道此需求，然后kube-scheduler負責資源分配并決定容器運行在哪個Node上，至于運行時所需的鏡像及運行的健康狀態的維護都由kube-controller來負責，kube-controller會循環將當前容器的狀態與watch到的用戶預期的需求做對比，看是否匹配。

2. 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引擎，負責本機容器的創建和管理工作。
container runtime：負責pod和容器的運行，即cri。

Node節點可以在運行期間動態增加到Kubernetes集群中，默認情況下，kubelet會想master注冊自己，這也是Kubernetes推薦的Node管理方式，kubelet進程會定時向Master匯報自身情報，如操作系統、Docker版本、CPU和內存，以及有哪些Pod在運行等等，這樣Master可以獲知每個Node節點的資源使用情況，冰實現高效均衡的資源調度策略。

3. K8S部署流程

我們簡單分析一下K8S集群部署業務的流程，并簡單看一看各個組件的作用。

準備包含應用程序的Deployment的yaml文件，然后通過kubectl客戶端工具發送給ApiServer。
ApiServer接收到客戶端的請求并將資源內容存儲到數據庫(etcd)中。
Controller組件(包括scheduler、replication、endpoint)監控資源變化并作出反應。
ReplicaSet檢查數據庫變化，創建期望數量的pod實例。
Scheduler再次檢查數據庫變化，發現尚未被分配到具體執行節點(node)的Pod，然后根據一組相關規則將pod分配到可以運行它們的節點上，并更新數據庫，記錄pod分配情況。
Kubelete監控數據庫變化，管理后續pod的生命周期，發現被分配到它所在的節點上運行的那些pod。如果找到新pod，則會在該節點上運行這個新pod。

三、 Kubernetes中的資源(API)對象

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

每個API對象都有3大類屬性：元數據metadata、規范spec和狀態status。

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

?

所有Kubernetes中的資源，比如Pod,都通過一個叫URI的東西來區分，這個URI有一個UID,URI的重要組成部分是：對象的類型（比如pod），對象的名字，對象的命名空間，對于特殊的對象類型，在同一個命名空間內，所有的名字都是不同的，在對象只提供名稱，不提供命名空間的情況下，這種情況是假定是默認的命名空間。UID是時間和空間上的唯一。

那么總體介紹完了API對象的定義和特性之后，我們就來簡單了解一下幾種重要的K8S集群中常見的API對象。

1. Pod

K8s有很多技術概念，同時對應很多API對象，最重要的也是最基礎的是微服務Pod。從之前的架構圖像中我們也能看出，每一個Node上都運行著若干個Pod。Pod是在K8s集群中運行部署應用或服務的最小單元。Pod的設計理念是支持多個容器在一個Pod中共享網絡地址和文件系統，可以通過進程間通信和文件共享這種簡單高效的方式組合完成服務。

Pod對多容器的支持是K8s最基礎的設計理念。比如你運行一個操作系統發行版的軟件倉庫，一個Nginx容器用來發布軟件，另一個容器專門用來從源倉庫做同步，這兩個容器的鏡像不太可能是一個團隊開發的，但是他們一塊兒工作才能提供一個微服務；這種情況下，不同的團隊各自開發構建自己的容器鏡像，在部署的時候組合成一個微服務對外提供服務。

Pod是K8s集群中所有業務類型的基礎，可以看作運行在K8s集群中的小機器人，不同類型的業務就需要不同類型的小機器人去執行。目前K8s中的業務主要可以分為長期伺服型（long-running）、批處理型（batch）、節點后臺支撐型（node-daemon）和有狀態應用型（stateful application），分別對應的小機器人控制器為Deployment、Job、DaemonSet和PetSet，本文后面會挑重點進行介紹。

2. 復制控制器（Replication Controller，RC）

RC是K8s集群中最早的保證Pod高可用的API對象。通過監控運行中的Pod來保證集群中運行指定數目的Pod副本。指定的數目可以是多個也可以是1個；少于指定數目，RC就會啟動運行新的Pod副本；多于指定數目，RC就會殺死多余的Pod副本。即使在指定數目為1的情況下，通過RC運行Pod也比直接運行Pod更明智，因為RC也可以發揮它高可用的能力，保證永遠有1個Pod在運行。RC是K8s較早期的技術概念，只適用于長期伺服型的業務類型，比如控制小機器人提供高可用的Web服務。

3. 副本集（Replica Set，RS）

RS是新一代RC，提供同樣的高可用能力，區別主要在于RS后來居上，能支持更多種類的匹配模式。副本集對象一般不單獨使用，而是作為Deployment的理想狀態參數使用。

4. 部署(Deployment)

部署表示用戶對K8s集群的一次更新操作。部署是一個比RS應用模式更廣的API對象，可以是創建一個新的服務，更新一個新的服務，也可以是滾動升級一個服務。滾動升級一個服務，實際是創建一個新的RS，然后逐漸將新RS中副本數增加到理想狀態，將舊RS中的副本數減小到0的復合操作；這樣一個復合操作用一個RS是不太好描述的，所以用一個更通用的Deployment來描述。以K8s的發展方向，未來對所有長期伺服型的的業務的管理，都會通過Deployment來管理。

5. 服務（Service）

RC、RS和Deployment只是保證了支撐服務的微服務Pod的數量，但是沒有解決如何訪問這些服務的問題。一個Pod只是一個運行服務的實例，隨時可能在一個節點上停止，在另一個節點以一個新的IP啟動一個新的Pod，因此不能以確定的IP和端口號提供服務。要穩定地提供服務需要服務發現和負載均衡能力。服務發現完成的工作，是針對客戶端訪問的服務，找到對應的的后端服務實例。在K8s集群中，客戶端需要訪問的服務就是Service對象。每個Service會對應一個集群內部有效的虛擬IP，集群內部通過虛擬IP訪問一個服務。

6. 任務（Job）

Job是K8s用來控制批處理型任務的API對象。批處理業務與長期伺服業務的主要區別是批處理業務的運行有頭有尾，而長期伺服業務在用戶不停止的情況下永遠運行。Job管理的Pod根據用戶的設置把任務成功完成就自動退出了。成功完成的標志根據不同的spec.completions策略而不同：單Pod型任務有一個Pod成功就標志完成；定數成功型任務保證有N個任務全部成功；工作隊列型任務根據應用確認的全局成功而標志成功。

還有很多的API對象，這里就不一一介紹了。如果沒個實例，說得太多，相信大家也是懵逼的。

六、總結

Kubernetes作為容器集群管理工具，于2015年7月22日迭代到 v 1.0并正式對外公布，這意味著這個開源容器編排系統可以正式在生產環境使用。Kubernetes項目凝結了Google過去十年間在生產環境的經驗和教訓，從Borg的多任務Alloc資源塊到Kubernetes的多副本Pod，在Docker等高級引擎帶動容器技術興起和大眾化的同時，為容器集群管理提供獨了到見解和新思路。

作為開發/測試人員，我們除了要能夠熟練掌握Kubernetes中的各種命令行、具備部署擴容排錯等運維能力，還應該時刻注意對K8S各構件和底層原理的學習。只有打好K8S項目的原理基礎，我們才能提升個人在就業或者工作方面的競爭力，而不至于對發生的問題束手無策。

本次分享內容源于CSDN，感覺對于我這樣的新人來說入門了解很是友好，后期整理一下我學習和工作中常用的操作命令行。

以上就是我對走向自律的全部理解，

希望我們都能對生活保持熱愛?

以下為之前分享的寶藏內容

我認為資料的價值在于能用、好用，不是滿足人的占有欲和獲得感。所以，也請各位擦亮雙眼，提高標準。得到的同時記得他的價值所在，收獲的同時，也請做好擇優標準。BTW,學長做的不好的地方，歡迎你們提出來，又或者如果屏幕前的你將更好的資源拿出分享，那真的十分優秀，也希望各位能無私互助。獲取資料不強制轉發。

希望學長分享的內容對你我都有幫助💪