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

[[273834]]

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

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

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

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

回顧過去

從大概10年前，大家都是以【自建IDC】+【物理服務器】的形式進行生產環境基礎架構的建設。

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

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

而事實上，以Kubernetes為首的相關周邊項目，已經成為了容器云領域的首選標準，所以絕大部分技術團隊如果現在需要選型容器編排體系，可以無腦選k8s了。

需求的根本——應用交付

在傳統裸機(bare metal)或虛擬化的時代，當開發團隊將代碼交付給運維進行生產環境中部署，但是它卻未能正常工作時，挑戰就出現了。

“運行環境不一致”、“沒有安裝相關依賴軟件”、“配置文件不一樣”等等已經成了開發和運維溝通的慣用語。

在傳統的開發場景中，開發和測試團隊使用的是與生產環境不同的基礎設施，盡管做到了代碼和配置解耦，但是在運行環境的轉換中，依然會得到像前面所述的團隊協作和環境依賴問題。

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

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

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

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

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

作為開發者，他們可能不關心由前兩者構成的容器運行時的環境差異，因為真正承載容器化應用的傳遞載體，是這個不變的容器鏡像。

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

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

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等進行期望狀態的描述，然后k8s的控制器有一套狀態調諧的機制讓各種API對象按要求所述的狀態運行。由于這樣一套運行機制的存在，所以使得k8s和過往運維常見的命令行，也包括腳本式的運行方式有著很大的差異。

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

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

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

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

1)方式一

$ kubectl apply -f deploy-ooxx.yaml 

2)方式二

首次創建使用 create ，修改yaml使用edit，然后用replace使之生效。

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

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

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

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

2、API對象

Kubernetes大量的API對象的存在是導致其運維方法和傳統系統層運維有區別較大的重要原因之一。

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

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

而我們在理解這個在PaaS層的k8s對象的概念時，需要一些面向對象的編程思想，會讓整個思路梳理地更加清晰。

所謂的面向對象，即在編碼過程中設定一切事物皆對象，通過面向對象的方式，將現實世界的事物抽象成對象，現實世界中的關系抽象成類、繼承，幫助人們實現對現實世界的抽象與數字建模。

通過面向對象的方法，更利于用人理解的方式對復雜系統進行分析、設計與編程。同時，面向對象能有效提高編程的效率，通過封裝技術，消息機制可以像搭積木的一樣快速開發出一個全新的系統。

面向對象是指一種程序設計范型，同時也是一種程序開發的方法。對象指的是類的集合。它將對象作為程序的基本單元，將程序和數據封裝其中，以提高軟件的重用性、靈活性和擴展性。

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

理解這些對象可以當成是一種面向過程的思維，因為最初操作系統的設計就是當時的計算機大牛們通過面向過程的思維所寫出來的，所以系統很多組成概念無需要面向對象思維就可以理解。

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

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

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

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

3、控制器模式

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

1)模型(Model)

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

2)視圖(View)

能夠實現數據有目的的顯示(理論上，這不是必需的)。在 View 中一般沒有程序上的邏輯。為了實現 View 上的刷新功能，View 需要訪問它監視的數據模型(Model)，因此應該事先在被它監視的數據那里注冊。

3)控制器(Controller)

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

MVC 模式強調職責分離，即視圖和數據模型的分離，并利用控制器來作為這兩者的邏輯控制的中介，使之具有邏輯復用、松散耦合等優點。

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

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

因為Model本身就代表著業務的特定數據對象，而在k8s里面，最典型的Model就是Pod。

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

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

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

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

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

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

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

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

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

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

4、接口和實現

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

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

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

Java 接口實現：

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的接口類型，但除了狹義的接口，我們在開發各種軟件中也會用到廣義的接口。

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

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

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

Kubernetes作為云原生應用的最佳部署平臺，已經開放了容器運行時接口(CRI)、容器網絡接口(CNI)和容器存儲接口(CSI)，這些接口讓Kubernetes的開放性變得最大化，而Kubernetes本身則專注于容器調度。

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

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

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

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

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

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

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

CSI 代表容器存儲接口，CSI 試圖建立一個行業標準接口的規范，借助 CSI 容器編排系統(CO)可以將任意存儲系統暴露給自己的容器工作負載。

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

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

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

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

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

}

有四個方法：添加網絡、刪除網絡、添加網絡列表、刪除網絡列表。

5、Master-Node模式與Api-server

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

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

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

1)Master

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

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

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

kube-scheduler監視新創建沒有分配到Node的Pod，為Pod選擇一個Node。

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

2)Node

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

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

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

kube-proxy通過在主機上維護網絡規則并執行連接轉發來實現Kubernetes服務抽象。

Docker等容器運行時，作用當然就是用于運行容器。

對于以上的Kubernetes的Master和Node的節點模式，在很多支持分布式架構的軟件中都是類似的，如Hadoop等。他們的Master節點往往需要有3個以上，以實現高可用架構。很多軟件架構也采取了這樣的設計方式，都是為了生產環境所需的高可用性服務。

3)Api-server

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

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

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

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

總結

從過去的【單體式應用+物理機】，到現在【微服務應用+容器云】的運行環境的變革，需要運維工程師同步改變以往的運維技術思維。新技術的應用，會引發更深層次的思考，深入了解容器之后，我們會自然而然地去學習業務最主流的編排工具——Kubernetes。

Kubernetes前身是谷歌的Borg容器編排管理平臺，它充分體現了谷歌公司多年對編排技術的最佳實踐。而容器云字面意思就是容器的云，實際指的是以容器為單位，封裝環境、提供構建、發布、運行分布式應用平臺。

而運維工程師在面對業界更新迭代極快的技術潮流下，需要選定一個方向進行深耕，無疑，Kubernetes是值得我們去深入學習的，畢竟它戰勝了幾乎所有的編排調度工具，成為業內編排標準。

我們通過搭建容器云環境下的應用運行平臺，并實現運維自動化，快速部署應用、彈性伸縮和動態調整應用環境資源，提高研發運營效率，最終實現自身的運維價值。