其實我挺早就接觸Docker和Kubernetes，時間大概在3、4年前吧，但是由于當(dāng)時所在技術(shù)團隊的業(yè)務(wù)模式所限制，還沒有真正對容器云有技術(shù)需求，所以我更多還是以一種技術(shù)玩具的心態(tài)接觸容器技術(shù)。

直到去年開始才正式接觸基于容器云平臺的技術(shù)架構(gòu)，我從業(yè)務(wù)運維和DevOps的角度來看，容器云平臺與之前的物理機和虛擬機等IaaS層基礎(chǔ)上的運維模式有著非常大的差異。

[[273842]]

根據(jù)這段時間的運維經(jīng)驗，我嘗試總結(jié)一下某些容器云的運維方法的共同特性，并將其稱為“容器運維模式”，簡單百度谷歌了一下，沒有這個名詞，希望是我的首創(chuàng):)

這個名詞靈感來自軟件工程的“設(shè)計模式”，設(shè)計模式(Design Pattern)是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類的、代碼設(shè)計經(jīng)驗的總結(jié)。使用設(shè)計模式的目的：為了代碼可重用性、讓代碼更容易被他人理解、保證代碼可靠性。設(shè)計模式使代碼編寫真正工程化;設(shè)計模式是軟件工程的基石脈絡(luò)，如同大廈的結(jié)構(gòu)一樣。

而“容器運維模式”，指的是由DevOps(題外話：DevOps、SRE、SA、運維等等，其實都差不多是同一個意思，業(yè)界喜歡創(chuàng)一個新的名詞來代替運維，主要是為了區(qū)分自己和一些低端系統(tǒng)維護人員)在日常運維容器化項目的一些經(jīng)驗總結(jié)，為了區(qū)別于傳統(tǒng)的物理機、虛擬機的運維套路，而歸納出來的容器運維方法。

回顧過去

從大概10年前，大家都是以【自建IDC】+【物理服務(wù)器】的形式進行生產(chǎn)環(huán)境基礎(chǔ)架構(gòu)的建設(shè)。

然后持續(xù)到大概5年前，私有云技術(shù)和公有云的興起，讓大批中小型企業(yè)減少對物理設(shè)備資源建設(shè)的人力和資金投入，可以專注于業(yè)務(wù)研發(fā)和運營。

最后到大概3、4年前，容器技術(shù)Docker和以Kubernetes為代表的容器編排技術(shù)的崛起，以及微服務(wù)技術(shù)的同步普及，宣告了容器云平臺的來臨。

而事實上，以Kubernetes為首的相關(guān)周邊項目，已經(jīng)成為了容器云領(lǐng)域的首選標(biāo)準(zhǔn)，所以絕大部分技術(shù)團隊如果現(xiàn)在需要選型容器編排體系，可以無腦選k8s了。

需求的根本——應(yīng)用交付

在傳統(tǒng)裸機(bare metal)或虛擬化的時代，當(dāng)開發(fā)團隊將代碼交付給運維進行生產(chǎn)環(huán)境中部署，但是它卻未能正常工作時，挑戰(zhàn)就出現(xiàn)了。

“運行環(huán)境不一致”、“沒有安裝相關(guān)依賴軟件”、“配置文件不一樣”等等已經(jīng)成了開發(fā)和運維溝通的慣用語。

在傳統(tǒng)的開發(fā)場景中，開發(fā)和測試團隊使用的是與生產(chǎn)環(huán)境不同的基礎(chǔ)設(shè)施，盡管做到了代碼和配置解耦，但是在運行環(huán)境的轉(zhuǎn)換中，依然會得到像前面所述的團隊協(xié)作和環(huán)境依賴問題。

而貫穿軟件生命周期共享相同的容器鏡像是容器化帶來的最大好處，它簡化了開發(fā)與運維團隊之間的協(xié)作關(guān)系。

由于本地開發(fā)/測試服務(wù)器和生產(chǎn)環(huán)境的不一致以及應(yīng)用程序打包部署的過程，一直是讓研發(fā)和運維糾結(jié)的難題，但有了容器之后，由于容器鏡像里打包的不僅是應(yīng)用，而是整個操作系統(tǒng)的文件和目錄，即其運行所需的所有依賴，都能被封裝一起。

有了容器鏡像的打包能力之后，這些應(yīng)用程序所需的基礎(chǔ)依賴環(huán)境，也成為了這個應(yīng)用沙盒的一部分，這可以給這個應(yīng)用包賦予這樣的能力：無論在開發(fā)、測試還是生產(chǎn)環(huán)境運行，我們只需要解壓這個容器鏡像，那么這個應(yīng)用所需的所有運行依賴都是存在的、一致的。

如果熟悉Docker容器技術(shù)原理的話，我們知道它主要由Linux內(nèi)核的Namespace和CGroups以及rootfs技術(shù)隔離出來一種特殊進程。

把Docker形容為一個房子的話，Namespace構(gòu)成了四面墻，為PID\NET\MNT\UTS\IPC等資源進行隔離;CGroups形成了它的天花板，限制了對系統(tǒng)資源的占用;而rootfs是其地基，是通過copy-on-write機制構(gòu)成的分層鏡像，也是開發(fā)者最為關(guān)心的應(yīng)用信息的傳遞載體。

作為開發(fā)者，他們可能不關(guān)心由前兩者構(gòu)成的容器運行時的環(huán)境差異，因為真正承載容器化應(yīng)用的傳遞載體，是這個不變的容器鏡像。

在Docker技術(shù)的普及后不久，為了整個完整的DevOps鏈條的打通，包括CI/CD、監(jiān)控、網(wǎng)絡(luò)、存儲、日志收集等生產(chǎn)環(huán)境的剛需，以及整個容器生命周期的管理和調(diào)度，以Kubernetes為首的容器編排體系也作為上層建筑也迎來了一波快速的增長。從容器到容器云的蛻變，標(biāo)志著容器運維時代的來臨。

容器運維模式的主要場景分析

1、聲明式 vs 命令行

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: nginx-deployment 
  labels: 
    app: nginx 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: nginx 
  template: 
    metadata: 
      labels: 
        app: nginx 
    spec: 
      containers: 
      - name: nginx 
        image: nginx:1.12.2 
        ports: 
        - containerPort: 80 

我們知道Kubernetes是通過yaml文件(樣例如上所示)來對其API對象，如Deployment、Pod、Service、DaemonSet等進行期望狀態(tài)的描述，然后k8s的控制器有一套狀態(tài)調(diào)諧的機制讓各種API對象按要求所述的狀態(tài)運行。由于這樣一套運行機制的存在，所以使得k8s和過往運維常見的命令行，也包括腳本式的運行方式有著很大的差異。

深度使用過puppet的運維工程師可能會比較清楚兩者的區(qū)別，puppet也是一套基于聲明式機制的配置管理和狀態(tài)管理的工具。在沒有puppet之前，運維工程師喜歡用簡單的shell、python腳本對眾多服務(wù)器進行統(tǒng)一的軟件安裝、配置管理，但隨著服務(wù)器數(shù)量增多和配置項的遞增，命令行式的配置管理往往出現(xiàn)各種缺陷。如狀態(tài)不一致、歷史版本無法回滾、配置沒有冪等性、需要很多狀態(tài)判斷才能執(zhí)行最終的操作等等。

而聲明式的配置管理方法，可以規(guī)避以上弊端，原因如下：

當(dāng)我們確認(rèn)了一個版本yaml配置文件后，表示向k8s的Kube-Controller-Manager提交了我們所期望的對象狀態(tài)信息，然后k8s使用patch的方式對API對象進行修改。而聲明式API是k8s項目編排能力的核心所在，它可以在無需干預(yù)的情況下對api對象進行增刪改查，完成對“期望狀態(tài)”和“實際狀態(tài)”的reconcile過程。

以我們常用的deployment對象為例。

1)方式一

$ kubectl apply -f deploy-ooxx.yaml 

2)方式二

首次創(chuàng)建使用 create ，修改yaml使用edit，然后用replace使之生效。

k8s對這兩種機制的處理方法是完全不同的，前者是聲明式，后者是命令式。

兩者的結(jié)果雖然都是觸發(fā)滾動更新，但是前者是對原有API對象打patch，后者是對象的銷毀和替換。前者能一次處理多個yaml配置變更的寫操作并具備相同配置項的merge能力，后者只能逐個處理，否則有沖突的可能。

所以，我們只需要確認(rèn)yaml文件的版本，一律通過 kubectl apply 命令進行執(zhí)行，無需再考慮第一步創(chuàng)建、第二步修改、第三步替換之類的命令行。那么我們統(tǒng)一用apply命令，可以通過history命令進行回溯版本，也可以保證apply的結(jié)果的冪等性等等。

使用聲明式只需要描述最終所需的狀態(tài)，無需用戶關(guān)心過多的實現(xiàn)流程和細節(jié)，沒有像命令行式的那么多上下文關(guān)系或者運行環(huán)境依賴，甚至可以由開發(fā)人員直接編寫，運維進行code review即可。特別在使用Kubernetes這樣的容器編排工具，更加要深刻理解和靈活運用聲明式的運維模式。

2、API對象

Kubernetes大量的API對象的存在是導(dǎo)致其運維方法和傳統(tǒng)系統(tǒng)層運維有區(qū)別較大的重要原因之一。

如果我們要深入了解k8s，則需要理解一些它核心的API對象，才能更好地理解這個容器的運行系統(tǒng)。如果把容器理解成一種特殊帶有資源隔離、資源限制的進程，那么Pod對象是一組進程組，最后，k8s是運行眾多有關(guān)聯(lián)的進程組(Pod)的操作系統(tǒng)。

這一層操作系統(tǒng)運行在PaaS層，比我們傳統(tǒng)運維的Linux系統(tǒng)所在的IaaS層要高一層。

而我們在理解這個在PaaS層的k8s對象的概念時，需要一些面向?qū)ο蟮木幊趟枷?，會讓整個思路梳理地更加清晰。

所謂的面向?qū)ο螅丛诰幋a過程中設(shè)定一切事物皆對象，通過面向?qū)ο蟮姆绞剑瑢F(xiàn)實世界的事物抽象成對象，現(xiàn)實世界中的關(guān)系抽象成類、繼承，幫助人們實現(xiàn)對現(xiàn)實世界的抽象與數(shù)字建模。

通過面向?qū)ο蟮姆椒ǎ谟萌死斫獾姆绞綄?fù)雜系統(tǒng)進行分析、設(shè)計與編程。同時，面向?qū)ο竽苡行岣呔幊痰男剩ㄟ^封裝技術(shù)，消息機制可以像搭積木的一樣快速開發(fā)出一個全新的系統(tǒng)。

面向?qū)ο笫侵敢环N程序設(shè)計范型，同時也是一種程序開發(fā)的方法。對象指的是類的集合。它將對象作為程序的基本單元，將程序和數(shù)據(jù)封裝其中，以提高軟件的重用性、靈活性和擴展性。

在系統(tǒng)層運維時候，我們關(guān)注的有CPU、內(nèi)存、IO等硬件對象，以及軟件安裝卸載、系統(tǒng)服務(wù)啟停、環(huán)境變量、內(nèi)核版本等軟件對象等等，就足以理解和把控整個操作系統(tǒng)運行環(huán)境。

理解這些對象可以當(dāng)成是一種面向過程的思維，因為最初操作系統(tǒng)的設(shè)計就是當(dāng)時的計算機大牛們通過面向過程的思維所寫出來的，所以系統(tǒng)很多組成概念無需要面向?qū)ο笏季S就可以理解。

眾所周知，Kubernetes是根據(jù)谷歌內(nèi)部運行多年的Borg項目的架構(gòu)體系所創(chuàng)造出來，所以它具備天生的項目架構(gòu)前瞻性。一般的開源項目是理論基礎(chǔ)走在工程應(yīng)用的后面，比如docker + swarm為代表，都是現(xiàn)實應(yīng)用中遇到什么需求，就新增一個功能，慢慢從一個單獨容器docker再到了具備基本編排能力的swarm。反觀Kubernetes，是一套自頂向下的架構(gòu)設(shè)計，幾乎能適配當(dāng)前所有的應(yīng)用架構(gòu)模式，應(yīng)對什么web-db、lb-web-redis-db、db-master-slave之類的常見架構(gòu)根本不在話下。

再回到Kubernetes的API對象，k8s使用這些API對象來描述一個集群所期望的運行狀態(tài)。

通常一個Kubernetes對象包含以下信息：需要運行的應(yīng)用以及運行在哪些Node上、應(yīng)用可以使用哪些資源、應(yīng)用運行時的一些配置，例如副本數(shù)、重啟策略、升級以及容錯性等等。

通過上圖可見API對象種類非常多，其實我們應(yīng)該先重點掌握最核心的Node、Pod、Deployment、RS、Service、Namespace，以及它們之間的關(guān)系，這里就不詳述了，請參考相關(guān)文檔。

3、控制器模式

在說Kubernetes的控制器模式之前，我們先看看軟件架構(gòu)中十分常見的MVC模式，即Model(模型)、View(視圖)、Controller(控制器)。

1)模型(Model)

用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對數(shù)據(jù)的處理方法。“ Model ”有對數(shù)據(jù)直接訪問的權(quán)力，例如對數(shù)據(jù)庫的訪問。“Model”不依賴“View”和“Controller”，也就是說， Model 不關(guān)心它會被如何顯示或是如何被操作。但是 Model 中數(shù)據(jù)的變化一般會通過一種刷新機制被公布。為了實現(xiàn)這種機制，那些用于監(jiān)視此 Model 的 View 必須事先在此 Model 上注冊，從而，View 可以了解在數(shù)據(jù) Model 上發(fā)生的改變。比如：觀察者模式(軟件設(shè)計模式)。

2)視圖(View)

能夠?qū)崿F(xiàn)數(shù)據(jù)有目的的顯示(理論上，這不是必需的)。在 View 中一般沒有程序上的邏輯。為了實現(xiàn) View 上的刷新功能，View 需要訪問它監(jiān)視的數(shù)據(jù)模型(Model)，因此應(yīng)該事先在被它監(jiān)視的數(shù)據(jù)那里注冊。

3)控制器(Controller)

起到不同層面間的組織作用，用于控制應(yīng)用程序的流程。它處理事件并作出響應(yīng)。“事件”包括用戶的行為和數(shù)據(jù) Model 上的改變。

MVC 模式強調(diào)職責(zé)分離，即視圖和數(shù)據(jù)模型的分離，并利用控制器來作為這兩者的邏輯控制的中介，使之具有邏輯復(fù)用、松散耦合等優(yōu)點。

數(shù)據(jù)模型(Model)，它描述了“應(yīng)用程序是什么”，用于封裝和保存應(yīng)用程序的數(shù)據(jù)，同時定義操控和處理該數(shù)據(jù)的邏輯和運算。而且，Model通常是可以復(fù)用的。

一個良好的MVC應(yīng)用程序應(yīng)該將所有重要的數(shù)據(jù)都封裝到Model中，而應(yīng)用程序在將持久化的數(shù)據(jù)(文件、數(shù)據(jù)庫)加載到內(nèi)存中時，也應(yīng)該保存在Model中。

因為Model本身就代表著業(yè)務(wù)的特定數(shù)據(jù)對象，而在k8s里面，典型的Model就是Pod。

視圖(View)，它是展現(xiàn)給用戶的界面，這個不用多說。這個在k8s的應(yīng)用不多，例如kubectl的信息輸出或者Dashbord等，都可以算是一種View的應(yīng)用。

控制器(Controller)，它充當(dāng)View和Model的媒介，將模型和視圖綁定在一起，包括處理用戶的配置輸入，以此修改Model。反過來，View需要知道Model中數(shù)據(jù)的變化，也是通過Controller來完成。除此之外，Controller還可以為應(yīng)用程序協(xié)調(diào)任務(wù)，管理其它對象的生命周期。在k8s里面，最典型的Controller就是Deployment。

在上文中我們提到了k8s擁有很多API對象，而其中一部分是屬于控制器類型的特殊對象，我們可以進入k8s的代碼目錄：kubernetes/pkg/controller/*，查看所有控制機類型的API對象，包含：deployment\job\namespace\replicaset\cronjob\serviceaccount\volume 等等。

由于k8s的架構(gòu)體系中，View不算是其核心的功能模塊，我們這里重點關(guān)注Controller和Model的關(guān)系，代入k8s對象的話，我們以最典型的Deployment和Pod的關(guān)系，作為主要的研究對象。

我們回頭看看文章連載前面的 Deployment 的yaml配置文件樣例，可以劃分為兩大部分進行分析，配置文件的上半部分是屬于控制器，下半部分是數(shù)據(jù)模型：

其實要深究起來，Deployment不是直接控制Pod，而是通過一個叫ReplicaSet的對象對Pod進行編排控制，所在在Pod的matadata里面會顯示其 owerReference是ReplicaSet。

也就是說在控制器對象的范圍內(nèi)，也會進行功能的分層，因為不同的控制機之間，存在著可以復(fù)用的功能邏輯，比如對Pod的副本數(shù)控制。

那么這時候可以抽象出一層例如像ReplicaSet的對象，進行對Pod的副本控制，除了Deployment以外，也存在其他的控制器對象可以利用ReplicaSet進行對Model的控制。

基于這樣的分層思想，我們在生產(chǎn)環(huán)境場景的所遇到的需求，可以將其控制邏輯都在控制器這一層進行實現(xiàn)。

比如無狀態(tài)的Deployment和有狀態(tài)的StatefuleSet，或者每個Node只有一個DeamonSet，盡管各自實現(xiàn)的功能各不相同，但是它們都是可以共用同一套Pod對象的邏輯，而差異的部分都封裝在控制器層。

4、接口和實現(xiàn)

接口這個詞廣泛存在于各種技術(shù)文檔中，到底接口是什么?

其實，狹義的接口是指代碼編寫的一個技巧，比如在Java語言里面，一個接口(interface)的特性是只定義了方法返回值、名稱、參數(shù)等，但沒有定義其具體的實現(xiàn)。

接口(interface)無法被實例化，但是可以被實現(xiàn)。一個實現(xiàn)(implements)接口的類(class)，必須實現(xiàn)接口內(nèi)所描述的所有方法，否則就必須聲明為抽象類(Abstract Class)。

Java 接口實現(xiàn)：

interface Animal {  
    public void eat();  
    public void travel();  
} 
 
public class MammalInt implements Animal{ 
   public void eat(){ 
      System.out.println("Mammal eats"); 
   } 
   public void travel(){ 
      System.out.println("Mammal travels"); 
   } 
   public int noOfLegs(){ 
      return 0; 
   } 
   public static void main(String args[]){ 
      MammalInt m = new MammalInt(); 
      m.eat(); 
      m.travel(); 
   } 
} 

以上是Java的接口類型，但除了狹義的接口，我們在開發(fā)各種軟件中也會用到廣義的接口。

接口對于調(diào)用方來說就是一種事先約定好的協(xié)議，它也許是一些預(yù)先定義的函數(shù)，目的是提供應(yīng)用程序與開發(fā)人員基于某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內(nèi)部工作機制的細節(jié)。

而在Kubernetes里面，其很多組件或者實現(xiàn)都采用了接口的形式，留給使用者非常靈活的擴展空間。

比如CRI \ CSI \ CNI 等等，都是Kubernetes留給其底層實現(xiàn)的接口方式。

Kubernetes作為云原生應(yīng)用的優(yōu)秀部署平臺，已經(jīng)開放了容器運行時接口(CRI)、容器網(wǎng)絡(luò)接口(CNI)和容器存儲接口(CSI)，這些接口讓Kubernetes的開放性變得最大化，而Kubernetes本身則專注于容器調(diào)度。

我們逐個了解一下以上3個接口，就可以對Kubernetes的實現(xiàn)思想有一定的感受，從而更深地理解其它類似的接口實現(xiàn)。

1)CRI (Container Runtime Interface，容器運行時接口)

Kubernetes其實不會直接和容器打交道，Kubernetes的使用者能接觸到的概念只有pod，而pod里包含了多個容器。

CRI中定義了容器和鏡像的服務(wù)的接口，因為容器運行時與鏡像的生命周期是彼此隔離的。

當(dāng)我們在Kubernetes里用kubectl執(zhí)行各種命令時，這一切是通過Kubernetes工作節(jié)點里所謂“容器運行時”的軟件在起作用。大家最熟悉的容器運行時軟件當(dāng)然是Docker，然而Docker只是Kubernetes支持的容器運行時技術(shù)的一種。

為了讓Kubernetes不和某種特定的容器運行時(Docker)技術(shù)綁死，而是能無需重新編譯源代碼就能夠支持多種容器運行時技術(shù)的替換，和我們面向?qū)ο笤O(shè)計中引入接口作為抽象層一樣，在Kubernetes和容器運行時之間我們引入了一個抽象層，即容器運行時接口。以后就算Docker不再流行了，甚至有了Eocker、Focker等等，就可以通過CRI接口無縫地融入Kubernetes體系。

2)CSI (Container Storage Interface，容器存儲接口)

CSI 代表容器存儲接口，CSI 試圖建立一個行業(yè)標(biāo)準(zhǔn)接口的規(guī)范，借助 CSI 容器編排系統(tǒng)(CO)可以將任意存儲系統(tǒng)暴露給自己的容器工作負載。

類似于 CRI，CSI 也是基于 gRPC 實現(xiàn)。CSI 卷類型是一種 in-tree(即跟其它存儲插件在同一個代碼路徑下，隨 Kubernetes 的代碼同時編譯的) 的 CSI 卷插件，用于 Pod 與在同一節(jié)點上運行的外部 CSI 卷驅(qū)動程序交互。部署 CSI 兼容卷驅(qū)動后，用戶可以使用 csi 作為卷類型來掛載驅(qū)動提供的存儲。

3)CNI (Container Network Interface，容器存儲接口)

CNI(Container Network Interface)是CNCF旗下的一個項目，由一組用于配置Linux容器的網(wǎng)絡(luò)接口的規(guī)范和庫組成，同時還包含了一些插件。CNI僅關(guān)心容器創(chuàng)建時的網(wǎng)絡(luò)分配，和當(dāng)容器被刪除時釋放網(wǎng)絡(luò)資源。

Kubernetes 網(wǎng)絡(luò)的發(fā)展方向是希望通過插件的方式來集成不同的網(wǎng)絡(luò)方案， CNI 就是這一努力的結(jié)果。CNI只專注解決容器網(wǎng)絡(luò)連接和容器銷毀時的資源釋放，提供一套框架，所以CNI可以支持大量不同的網(wǎng)絡(luò)模式，并且容易實現(xiàn)。

CNI的接口中包括以下幾個方法：

type CNI interface { 
    AddNetworkList(net *NetworkConfigList, rt *RuntimeConf) (types.Result, error) 
    DelNetworkList(net *NetworkConfigList, rt *RuntimeConf) error 
    AddNetwork(net *NetworkConfig, rt *RuntimeConf) (types.Result, error) 
    DelNetwork(net *NetworkConfig, rt *RuntimeConf) error 
} 

有四個方法：添加網(wǎng)絡(luò)、刪除網(wǎng)絡(luò)、添加網(wǎng)絡(luò)列表、刪除網(wǎng)絡(luò)列表。

5、Master-Node模式與Api-server

Kubernetes有幾個核心組件：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、CRI(一般是docker)等等。

它們分別是運行在Master或者Node節(jié)點上面，我把Master和Node稱為物理組件，因為它們是運行于物理環(huán)境的，如物理機或者虛擬機。其中Master提供集群的管理控制中心，而Node是真正接受執(zhí)行任務(wù)的工作節(jié)點，可以擬人化地理解為：Master是用人經(jīng)理，Node是工作人員。

而Etcd是用于存儲配置信息或者其他需要持久化的數(shù)據(jù)，獨立于Master和Node節(jié)點，一般也是三副本的方式運行。

1)Master

區(qū)別于物理組件，邏輯組件是指在程序內(nèi)的虛擬概念，例如運行在Master的邏輯組件有kube-apiserver、kube-controller-manager、kube-scheduler。

kube-apiserver用于暴露Kubernetes API。任何的資源請求/調(diào)用操作都是通過kube-apiserver提供的接口進行。

kube-controller-manager運行管理控制器，它們是集群中處理常規(guī)任務(wù)的后臺線程。邏輯上，每個控制器是一個單獨的進程，但為了降低復(fù)雜性，它們都被編譯成單個二進制文件，并在單個進程中運行。

kube-scheduler監(jiān)視新創(chuàng)建沒有分配到Node的Pod，為Pod選擇一個Node。

這幾個組件的用途不作特別展開，我們后面將詳細聊聊Apiserver。

2)Node

Node是Kubernetes中的工作節(jié)點，最開始被稱為minion。一個Node可以是VM或物理機。每個Node(節(jié)點)具有運行pod的一些必要服務(wù)，并由Master組件進行管理。

然后介紹運行于Node節(jié)點的組件：kubelet、kube-proxy、CRI(一般是docker)。

kubelet是主要的節(jié)點代理，它會監(jiān)視已分配給節(jié)點的pod，具體功能如：安裝Pod所需的volume;下載Pod的Secrets;Pod中運行的docker(或experimentally，rkt)容器;定期執(zhí)行容器健康檢查等等。

kube-proxy通過在主機上維護網(wǎng)絡(luò)規(guī)則并執(zhí)行連接轉(zhuǎn)發(fā)來實現(xiàn)Kubernetes服務(wù)抽象。

Docker等容器運行時，作用當(dāng)然就是用于運行容器。

對于以上的Kubernetes的Master和Node的節(jié)點模式，在很多支持分布式架構(gòu)的軟件中都是類似的，如Hadoop等。他們的Master節(jié)點往往需要有3個以上，以實現(xiàn)高可用架構(gòu)。很多軟件架構(gòu)也采取了這樣的設(shè)計方式，都是為了生產(chǎn)環(huán)境所需的高可用性服務(wù)。

3)Api-server

前面介紹過Master和Node，它們之間從Master (apiserver)到集群有兩個主要的通信路徑。第一個是從Apiserver到在集群中的每個節(jié)點上運行的kubelet進程。第二個是通過Apiserver的代理功能從Apiserver到任何Node、pod或service。

所以說Apiserver對于Master-Node模式來說是非常重要的溝通橋梁。

從Apiserver到kubelet的連接用于獲取pod的日志，通過kubectl來運行pod，并使用kubelet的端口轉(zhuǎn)發(fā)功能。這些連接在kubelet的HTTPS終端處終止。

從Apiserver到Node、Pod或Service的連接默認(rèn)為HTTP連接，因此不需進行認(rèn)證加密。也可以通過HTTPS的安全連接，但是它們不會驗證HTTPS端口提供的證書，也不提供客戶端憑據(jù)，因此連接將被加密但不會提供任何誠信的保證。這些連接不可以在不受信任/或公共網(wǎng)絡(luò)上運行。

總結(jié)

從過去的【單體式應(yīng)用+物理機】，到現(xiàn)在【微服務(wù)應(yīng)用+容器云】的運行環(huán)境的變革，需要運維工程師同步改變以往的運維技術(shù)思維。新技術(shù)的應(yīng)用，會引發(fā)更深層次的思考，深入了解容器之后，我們會自然而然地去學(xué)習(xí)業(yè)務(wù)最主流的編排工具——Kubernetes。

Kubernetes前身是谷歌的Borg容器編排管理平臺，它充分體現(xiàn)了谷歌公司多年對編排技術(shù)的最佳實踐。而容器云字面意思就是容器的云，實際指的是以容器為單位，封裝環(huán)境、提供構(gòu)建、發(fā)布、運行分布式應(yīng)用平臺。

而運維工程師在面對業(yè)界更新迭代極快的技術(shù)潮流下，需要選定一個方向進行深耕，無疑，Kubernetes是值得我們?nèi)ド钊雽W(xué)習(xí)的，畢竟它戰(zhàn)勝了幾乎所有的編排調(diào)度工具，成為業(yè)內(nèi)編排標(biāo)準(zhǔn)。

我們通過搭建容器云環(huán)境下的應(yīng)用運行平臺，并實現(xiàn)運維自動化，快速部署應(yīng)用、彈性伸縮和動態(tài)調(diào)整應(yīng)用環(huán)境資源，提高研發(fā)運營效率，最終實現(xiàn)自身的運維價值。

作者介紹

溫崢峰，小鵬汽車互聯(lián)網(wǎng)中心運維高級經(jīng)理，專注于運維自動化、DevOps實踐、運維服務(wù)體系建設(shè)與容器運維時代下的價值挖掘。知乎專欄：HiPhone運維之道。