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

[[273834]]

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

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

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

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

回顧過去

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

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

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

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

需求的根本——應用交付

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

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

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

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

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

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

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

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

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

在Docker技術的普及后不久，為了整個完整的DevOps鏈條的打通，包括CI/CD、監(jiān)控、網絡、存儲、日志收集等生產環(huán)境的剛需，以及整個容器生命周期的管理和調度，以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等進行期望狀態(tài)的描述，然后k8s的控制器有一套狀態(tài)調諧的機制讓各種API對象按要求所述的狀態(tài)運行。由于這樣一套運行機制的存在，所以使得k8s和過往運維常見的命令行，也包括腳本式的運行方式有著很大的差異。

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

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

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

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

1)方式一

$ kubectl apply -f deploy-ooxx.yaml 

2)方式二

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

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

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

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

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

2、API對象

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

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

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

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

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

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

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

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

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

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

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

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

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

3、控制器模式

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

1)模型(Model)

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

2)視圖(View)

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

3)控制器(Controller)

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

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

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

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

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

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

控制器(Controller)，它充當View和Model的媒介，將模型和視圖綁定在一起，包括處理用戶的配置輸入，以此修改Model。反過來，View需要知道Model中數(shù)據的變化，也是通過Controller來完成。除此之外，Controller還可以為應用程序協(xié)調任務，管理其它對象的生命周期。在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配置文件樣例，可以劃分為兩大部分進行分析，配置文件的上半部分是屬于控制器，下半部分是數(shù)據模型：

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

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

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

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

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

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

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

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

接口(interface)無法被實例化，但是可以被實現(xiàn)。一個實現(xiàn)(implements)接口的類(class)，必須實現(xiàn)接口內所描述的所有方法，否則就必須聲明為抽象類(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ā)各種軟件中也會用到廣義的接口。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}

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

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í)行任務的工作節(jié)點，可以擬人化地理解為：Master是用人經理，Node是工作人員。

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

1)Master

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

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

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

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

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

2)Node

Node是Kubernetes中的工作節(jié)點，最開始被稱為minion。一個Node可以是VM或物理機。每個Node(節(jié)點)具有運行pod的一些必要服務，并由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通過在主機上維護網絡規(guī)則并執(zhí)行連接轉發(fā)來實現(xiàn)Kubernetes服務抽象。

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

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

3)Api-server

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

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

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

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

總結

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

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

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

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