【51CTO.com原創(chuàng)稿件】眾所周知，微服務(wù)和容器本身結(jié)合較為密切，隨著云服務(wù)的普及，它們從企業(yè)機(jī)房內(nèi)部的服務(wù)器上逐漸延伸到了各種云服務(wù)的場景中。

[[240438]]

因此面對常見的混合云服務(wù)，我們該如何用基于容器的模式來進(jìn)行管理呢？

2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開。

在“微服務(wù)架構(gòu)設(shè)計(jì)”分論壇上，來自餓了么計(jì)算力交付部門的資深工程師李健帶來了主題為《餓了么基于容器的混合云實(shí)踐》的精彩演講。

本文將按照如下四個(gè)部分展開分享：

• 計(jì)算力交付
• 技術(shù)選型
• 基于 Kubernetes 的“算力外賣”
• Kubernetes 的擴(kuò)展方案

隨著業(yè)務(wù)的快速增長，對應(yīng)的資源規(guī)模也在迅速增長之中。而這種增長直接導(dǎo)致了服務(wù)器類型的增多、管理任務(wù)的加劇、和交付需求的多樣性。

比如在某些場景下，我們需要在交付的服務(wù)器上，預(yù)安裝某種應(yīng)用；而有些時(shí)候，我們需要交付出一個(gè)“有依賴性”的服務(wù)、或是一組服務(wù)的集合。

計(jì)算力交付

盡管我們所面對的物理資源和虛擬機(jī)資源的數(shù)量是龐大的，但我們運(yùn)維人員卻是有限的，無法做到無限量地?cái)U(kuò)張。因此我們需要將物理資源統(tǒng)一抽象出來，從而輸出給開發(fā)人員。

而這種標(biāo)準(zhǔn)化式的抽象，能夠給企業(yè)帶來兩大好處：極大地減少了成本和增加了服務(wù)器管理上的運(yùn)能。同時(shí)，這種統(tǒng)一抽象催生了我們計(jì)算力交付部門的出現(xiàn)。

具體而言，平時(shí)我們所交付的服務(wù)器，包括以云服務(wù) IaaS 形式的交付，實(shí)際上與應(yīng)用的交付，如 SaaS 形式是一樣的。

在如今虛擬化的云時(shí)代，我們通過簡單的命令輸入，就能為某個(gè)文件系統(tǒng)準(zhǔn)備好 CentOS 或 Ubuntu 操作系統(tǒng)。因此，服務(wù)器實(shí)際上也成為了一種軟件服務(wù)、或是一種 App。

通過以抽象的方式對服務(wù)器和應(yīng)用采取標(biāo)準(zhǔn)化，我們可以把所有的物理資源抽象出來，形成一種具有管控能力的計(jì)算力，從而達(dá)到對于系統(tǒng)的協(xié)調(diào)能力?？梢哉f，一切交付的行為都屬于應(yīng)用。

因此我們計(jì)算力交付的關(guān)鍵也就落腳在了對應(yīng)用的管理之上，這同時(shí)也是我們關(guān)注度的轉(zhuǎn)變。

容器技術(shù)的原型始于七十年代末，但直到 2013 年 Docker 的問世，容器才成為了主流的技術(shù)。

Docker 對于容器技術(shù)的最大貢獻(xiàn)在于：通過真正地面向應(yīng)用的方式，它具有跨平臺(tái)的可移植特性，將所有的服務(wù)，統(tǒng)一以 Image 打包的方式來進(jìn)行應(yīng)用的交付。

另外，它是應(yīng)用的一種封裝標(biāo)準(zhǔn)。在此標(biāo)準(zhǔn)之上，我們可以讓應(yīng)用運(yùn)行在任何一個(gè)平臺(tái)之中。

同時(shí)，這也進(jìn)一步促進(jìn)了自動(dòng)化運(yùn)維、AIOps 和大數(shù)據(jù)等應(yīng)用的發(fā)展。因此，它在降低人力成本的同時(shí)，也提高了資源的利用率。

我們將計(jì)算力交付分為三大類：

• 客戶應(yīng)用的部署。在接到服務(wù)請求后，我們會(huì)著手部署，并讓服務(wù)順利運(yùn)行起來。
• 標(biāo)準(zhǔn)服務(wù)的一鍵交付。例如某部門的大數(shù)據(jù)業(yè)務(wù)需要有一套環(huán)境，該環(huán)境里所包含的許多種服務(wù)，相互之間默認(rèn)是相互隔離的，但同時(shí)也要保證部分服務(wù)能夠相互聯(lián)系。

那么我們就需要準(zhǔn)備好一些可復(fù)制的標(biāo)準(zhǔn)化服務(wù)模板，以保證就算在復(fù)雜的 SOA 體系中，也能實(shí)現(xiàn)應(yīng)用服務(wù)的順暢發(fā)現(xiàn)。

• 服務(wù)器的交付。如前所述，服務(wù)器交付的標(biāo)準(zhǔn)化，正是我們計(jì)算力交付部門能力的一種體現(xiàn)。

技術(shù)選型

如今，可選的容器技術(shù)有很多，包括 Kubernetes、Swarm、和 AWSECS 等，其中 Kubernetes 比較熱門。

因此我們在選型時(shí)，需要考慮如下因素：

• Kubernetes 項(xiàng)目已成為了容器編排的事實(shí)標(biāo)準(zhǔn)。由于大家都在普遍使用，如果碰到了問題，可以到社區(qū)里去搜尋答案。這無形中帶來了成本下降的優(yōu)勢。
• 實(shí)際需求情況和技術(shù)的契合度。
• 擴(kuò)展性與生態(tài)發(fā)展。一些由大公司的采用作為背書的技術(shù)，一般都有著強(qiáng)大的后臺(tái)支持和一定的前瞻性，同時(shí)也方便建立起一定的生態(tài)體系。

基于 Kubernetes 的“算力外賣”

我們開發(fā)人員平時(shí)對于應(yīng)用服務(wù)類型的需求和本公司所做的點(diǎn)餐服務(wù)是極其類似的。上圖中的綠色 Box，實(shí)際上就像我們抽象出的一個(gè)外賣盒。

其中每一種服務(wù)相互之間的調(diào)用，都是通過 DomainName 去實(shí)現(xiàn)的。而且這些 Box 具有復(fù)制性，我們可以依據(jù)模板來創(chuàng)建出多個(gè) Box。

而每個(gè) Box 內(nèi)部在調(diào)用不同的服務(wù)時(shí)，它的域名在系統(tǒng)中是唯一的。因此，它們可以橫跨不同的環(huán)境進(jìn)行調(diào)用，從而減少了開發(fā)人員的工作量。

過去，在服務(wù)啟動(dòng)的時(shí)候，系統(tǒng)會(huì)自動(dòng)生成一個(gè)網(wǎng)絡(luò)標(biāo)識(shí)，而當(dāng) IP 地址或域名發(fā)生變化時(shí)，他們不得不進(jìn)行相應(yīng)的配置修改。

如今，只要容器環(huán)境和相應(yīng)的應(yīng)用運(yùn)行起來了，不同服務(wù)之間就能夠根據(jù)唯一的網(wǎng)絡(luò)標(biāo)識(shí)實(shí)現(xiàn)相互調(diào)用。

在具體實(shí)現(xiàn)中，我們利用 Kubernetes 做出了一個(gè)底層的容器引擎。在其中的每個(gè) Unit 里，都會(huì)包括有 Domain 和 Pod。而且每個(gè) Unit 都有自己的副本，以實(shí)現(xiàn)負(fù)載均衡。

我們通過使用 Systemd，這種啟動(dòng)方式去了解各個(gè)服務(wù)之間的相互依賴關(guān)系。

它通過啟動(dòng)樹，在 Box 中實(shí)現(xiàn)了同樣的功能，以保證 Box 在啟動(dòng)的時(shí)候，能夠根據(jù)我們既定的依賴描述，按照先后次序?qū)?yīng)用啟動(dòng)運(yùn)行起來。

雖然從技術(shù)發(fā)展的角度來說，服務(wù)之間不應(yīng)該存在過多的依賴關(guān)系，但是由于我們部門是面向業(yè)務(wù)部門提供服務(wù)的，所以我們需要做的只是去推動(dòng)標(biāo)準(zhǔn)化，從而去兼容開發(fā)的習(xí)慣和他們當(dāng)前的項(xiàng)目。

如上圖所示，每個(gè) Unit 中還有一個(gè) Hook，它可以協(xié)助服務(wù)的啟/停與初始化。例如，在某些服務(wù)完成了之后，它會(huì)去調(diào)用另外一個(gè) Pod 進(jìn)行初始化。

當(dāng)然，我們也涉及到對公共服務(wù)的使用。例如，Box1 和 Box2 都要通過一個(gè)公共服務(wù)來傳遞數(shù)據(jù)。而公共服務(wù)的唯一性網(wǎng)絡(luò) ID，則可能因?yàn)橹貑⒌韧獠恳蛩囟l(fā)生變化。

因此為了保持一致性，我們嘗試著將上述提到的內(nèi)部標(biāo)識(shí)轉(zhuǎn)換為外部標(biāo)識(shí)。實(shí)際上，我們的內(nèi)部標(biāo)識(shí)是永遠(yuǎn)不變的，而外面關(guān)系則需要通過服務(wù)發(fā)現(xiàn)的機(jī)制，與內(nèi)部服務(wù)動(dòng)態(tài)建立關(guān)聯(lián)。

這樣一來，內(nèi)部的服務(wù)就不必考慮配置變更、以及服務(wù)發(fā)現(xiàn)等問題了。上圖就是我們對于外賣服務(wù)方式的一種最簡單的抽象。

眾所周知，Kubernetes 的服務(wù)主要依賴于 Etcd 的啟動(dòng)，但是 Etcd 本身在 Kubernetes 的應(yīng)用場景下并不能支持大量的業(yè)務(wù)。

因此，考慮到了業(yè)務(wù)量的逐漸增大和對于服務(wù)的穩(wěn)定性要求，我們需要對 Kubernetes 盡量進(jìn)行拆分。

在拆分的過程中，我們將原來單個(gè)機(jī)房網(wǎng)絡(luò)中的資源池拆分成三到四個(gè) Kubernetes 集群。

在拆分完成之后，我們曾碰到了一個(gè)問題：由于拆分得太細(xì)，集群資源出現(xiàn)了利用率不均的情況：有的集群負(fù)載不夠、而有的集群則負(fù)載過多。

因此，我們運(yùn)用不同的 Etcd 對應(yīng)不同的 Kubernetes 集群，通過調(diào)度的方式，讓服務(wù)能夠在集群之間飄移，從而既解決了資源效率的問題，又解決了可靠性的問題。

在上述簡單的結(jié)構(gòu)中，除了黃色的部分，其他都是 Kubernetes 原生的組件，包括藍(lán)色部分里具有調(diào)度 Pod 功能的調(diào)度器（Scheduler）。

我們根據(jù)上述不同 Node 層的屬性和服務(wù)信息進(jìn)行判斷，以確定要調(diào)用哪個(gè)集群。

由于我們采取的是兩層調(diào)度的方式，因此在調(diào)到第一層的時(shí)候，我們并沒有該集群的實(shí)時(shí)信息，也無法知道此集群把服務(wù)調(diào)到了何處。

對此，我們自行開發(fā)了一個(gè) Scheduler（如黃色部分所示）。另外，我們還開發(fā)了一個(gè)類似于 Kubernetes 的 APIServer 服務(wù)。

可見，我們的目的就在于：以外圍的方式去擴(kuò)展 Kubernetes 集群，而不是去改動(dòng) Kubernetes 本身。

即：在 Kubernetes 的外圍，增加了一層 APIServer 和 Scheduler。此舉的直接好處體現(xiàn)在：我們節(jié)約了在框架上的開發(fā)與維護(hù)成本。

下面我們來具體看看真實(shí)的容器環(huán)境：

• 如前所述，我們是基于 Kubernetes 的。
• 在網(wǎng)絡(luò)上我們使用的是阿里云的虛擬機(jī)。如果規(guī)模小的話，我們會(huì)用 Vroute 的方式；如果是自建機(jī)房的話，我們就使用 LinuxBridge 的方式。同時(shí)，我們的 Storage Driver 用的是 Overlay2。
• 在操作系統(tǒng)方面，我們都使用的是 Centos7-3.10.0-693。
• 在 Docker 的版本上，我們用的是 17.06。值得補(bǔ)充的是：如今社區(qū)里傳聞該版本即將被停止維護(hù)了，因此我們近期會(huì)著手升級。

Registry

說到 Registry，在以前規(guī)模小的時(shí)候并不存在問題。但是如今我們的規(guī)模已大到橫跨幾個(gè)機(jī)房。

因此我們就需要對 Registry 傳過來的數(shù)據(jù)進(jìn)行同步，并“雙寫”到 OSS(Object Storage Service)和 Ceph(一個(gè)開源的分布式存儲(chǔ)系統(tǒng)，提供對象存儲(chǔ)、塊存儲(chǔ)和文件系統(tǒng)的存儲(chǔ)機(jī)制)之中了。

由于我們在自己的物理機(jī)房中都有 Ceph，因此在下載時(shí)可以遵循就近下載的原則，而不必跨出本機(jī)房。

此舉的好處就在于：降低了在機(jī)房之間傳輸所帶來的帶寬瓶頸問題。

那么我們?yōu)槭裁匆鐾侥兀坑捎谖覀兊姆?wù)一旦被發(fā)布出去，它們就會(huì)自動(dòng)去進(jìn)行異步部署。

但是，有些機(jī)房里可能根本沒有所需的鏡像，那么它們在進(jìn)行“拉取”操作時(shí)就會(huì)報(bào)錯(cuò)。

因此基于此方面的考慮，我們采用了“同步雙寫”模式，并增加了認(rèn)證的環(huán)節(jié)。

想必大家都知道：Registry 在長時(shí)間運(yùn)行后，鏡像里會(huì)有越來越多的 Blob。

我們既可以自行清理，也可以根據(jù)官方提供的方式來清理，但是清理的時(shí)間一般都會(huì)非常長。

因此清理工作會(huì)帶來服務(wù)的運(yùn)維性中斷，這對于一般公司來說是無法接受的。

對此，我們想到一種“Bucket 輪轉(zhuǎn)”的方法。由于在 CI（持續(xù)集成）的過程中，我們會(huì)產(chǎn)生大量的鏡像，因此我們將鏡像以兩個(gè)季度為一個(gè)保存周期進(jìn)行劃分，即：

• 為第一個(gè)季度新建一個(gè) Bucket，用來存儲(chǔ)鏡像。
• 在第二個(gè)季度時(shí)，將新的鏡像產(chǎn)生到第二個(gè) Bucket 之中。
• 等到了第三個(gè)季度，我們就將第一個(gè) Bucket 里的鏡像清理掉，以存入新的鏡像。

以此類推，通過該方法，我們就能夠限制鏡像，不至于無限地增長下去。

我們當(dāng)前的 8 臺(tái) Registry 所服務(wù)的 Docker 對象具有成千上萬的體量規(guī)模。

如果 Registry 一旦出現(xiàn)問題，我們就需要迅速地能夠定位到問題，因此，對于 Registry 采取相關(guān)的監(jiān)控是非常必要的。

同時(shí)，我們也需要通過監(jiān)控來實(shí)時(shí)了解系統(tǒng)的使用程度，以便做出必要的擴(kuò)容。

在實(shí)現(xiàn)方式上，我們實(shí)際上只是稍微加入了一些自己寫的程序，而整體上仍保留著與其他程序的解耦關(guān)系。

如圖所示，我們通過上傳、下載的速度，包括 Blob 的數(shù)量等監(jiān)控指標(biāo)，能夠?qū)崟r(shí)地跟蹤 Registry 的運(yùn)行狀態(tài)。 

Docker

我們使用 Docker syslog driver 將采集到的用戶進(jìn)程輸出到 ELK 之中進(jìn)行呈現(xiàn)。不過在日志量過于頻繁的時(shí)候，ELK 會(huì)出現(xiàn)毫秒級別的亂序。

這樣的亂序會(huì)給業(yè)務(wù)部門帶來無法進(jìn)行問題排查的困難。因此，我們改動(dòng)了 Docker 的相關(guān)代碼，給每一條日志都人為增加一個(gè)遞增的序列號。

針對一些可靠性要求較高的 Log，我們選擇了 TCP 模式。但是在 TCP 模式下，如果某個(gè)日志被輸出到一個(gè)服務(wù)時(shí)，其接收服務(wù)的 Socket 由于滿載而“夯住”了。

那么該容器就無法繼續(xù)，其 Docker ps 命令也就只能停在那兒了。另外就算 TCP 模式開啟了，但是其接收日志 TCPServer 尚未啟動(dòng)也是無濟(jì)于事的。

由此可見，在面對一些具體使用中的問題時(shí)，我們的需求與開源項(xiàng)目本身所能提供的服務(wù)還是有一定距離的。任何一個(gè)開源項(xiàng)目在企業(yè)落地時(shí)，都不可能是完美的。

開源項(xiàng)目往往提供的是標(biāo)準(zhǔn)化的服務(wù)，而我們的需求卻經(jīng)常是根據(jù)自己的具體場景而定制化的。

我們企業(yè)的軟件環(huán)境，都是根據(jù)自身環(huán)境一點(diǎn)、一點(diǎn)地長出來的，因此存在差異性是必然的。

我們不可能讓開源軟件為我們而改變，只能通過修改程序，讓開源軟件來適應(yīng)我們當(dāng)前的軟件狀態(tài)與環(huán)境，進(jìn)而解決各種具體的問題。

上圖是 Docker 的一些監(jiān)控，它能夠幫助我們發(fā)現(xiàn)各種問題、Bug、以及“夯住”的地方。

Init 進(jìn)程

在將傳統(tǒng)的業(yè)務(wù)進(jìn)行容器化轉(zhuǎn)變的過程中，我們針對容器定制并改進(jìn)了 Init 進(jìn)程。

該 Init 進(jìn)程能夠切換 Image 基礎(chǔ)層管理的一些目錄和環(huán)境變量，通過也可以替換基礎(chǔ)配置文件的宏代換。

對于一些遷移過來的服務(wù)，其本身就曾帶有配置項(xiàng)，它們通常使用環(huán)境變量來讀取配置信息。那么這對于我們將其修改成容器的工作，就無形中增加了成本。

因此我們所提供的方法是：雖然變量被寫在了配置里，但是我們能夠根據(jù)容器的環(huán)境變量設(shè)置，自動(dòng)去替換服務(wù)寫“死”的配置。

Init 進(jìn)程的這種方法對于在容器尚未啟動(dòng)，且不知道服務(wù)的 IP 地址時(shí)尤為有用。

對于容器的管理，我們也啟動(dòng)了 Command，來持續(xù)監(jiān)聽進(jìn)程的狀態(tài)，以避免僵尸進(jìn)程的出現(xiàn)。

另外，由于我們公司有著內(nèi)部的 SOA 體系，在 Docker 產(chǎn)生停止信號之后，需要將流量從公司的整個(gè)集群里摘除掉。

因此，我們通過截獲信息，做到了在相關(guān)的流量入口予以服務(wù)的摘除動(dòng)作。

同時(shí)，我們還通過傳遞停止信號給應(yīng)用進(jìn)程，以完成針對軟件的各種掃尾清理操作，進(jìn)而實(shí)現(xiàn)了對傳統(tǒng)業(yè)務(wù)予以容器化的平滑過渡。

Kubernetes 資源管理擴(kuò)展

下面通過案例來看看，我們是如何通過擴(kuò)展來滿足業(yè)務(wù)需求的。

我們都知道，Kubernetes 的 APIServer 是較為核心的組件，它使得所有的資源都可以被描述和配置。這與 Linux“一切皆文件”的哲學(xué)具有異曲同工之妙。

Kubernetes 集群將所有的操作，包括監(jiān)控和其他資源，都通過讀文件的方式來掌握服務(wù)的狀態(tài)，并通過寫文件的方式來修改服務(wù)的狀態(tài)。

借用這種方式，我們相繼開發(fā)了不同的組件和 APIServer 的接口，并以 Restful 的接口形式對服務(wù)實(shí)現(xiàn)了微服務(wù)化。

在實(shí)際部署中，雖然我們并沒有用到 Kubernetes Proxy，但是這樣反而降低了 APIServer 的負(fù)載。

當(dāng)然如果需要的話，我們完全可以按需加載與部署，從而保證并增強(qiáng)系統(tǒng)整體的擴(kuò)展性。

Kubernetes APIServer

上圖直觀地展示了 APIServer 的簡單內(nèi)部結(jié)構(gòu)。所有的資源實(shí)際上都要被放入 Etcd 之中。

同時(shí)，每一種資源都有一個(gè) InternalObject，它對應(yīng)著 Etcd 里的一些存儲(chǔ)類 Key/Value，這樣保證了每個(gè)對象的唯一性。

當(dāng)有外面請求來訪問服務(wù)時(shí)，則需要通過 ExternalObject 和 InternalObject 進(jìn)行轉(zhuǎn)換才能實(shí)現(xiàn)。

例如：我們可能使用不同版本的 API 進(jìn)行程序開發(fā)，而此時(shí)出現(xiàn)了需求變更，需要我們增加一個(gè)字段。

而實(shí)際上該字段可能已經(jīng)存在于 InternalObject 之中了，那么我們只需經(jīng)過一些處理便可直接生成該字段。

可見，我們真正要去實(shí)現(xiàn)的只是 ExternalObject，而沒必要去改動(dòng) InternalObject。

如此，我們在不修改存儲(chǔ)的基礎(chǔ)上，盡量做到了服務(wù)與存儲(chǔ)之間的解耦，以更好地應(yīng)對外界的各種變化。

當(dāng)然，這同時(shí)也是 Kubernetes APIServer 里對象服務(wù)的一個(gè)過程。

與此同時(shí)，我們也將部分 API 劃歸到了一個(gè) APIGroup 之中。在同一個(gè) APIGroup 里，不同的資源相互之間是解耦、并行的，我們能夠以添加接口的方式進(jìn)行資源的擴(kuò)展。

而上述提到的兩個(gè)對象之間的轉(zhuǎn)換，以及類型的注冊，都是在圖中的 Scheme 里面完成的。

如果大家想自己做 APIServer 的話，谷歌官方就擁有該項(xiàng)目的對應(yīng)方案，并提供了專門的技術(shù)支持。如果您感興趣的話，可以參考圖中下方對應(yīng)的 Github 項(xiàng)目的網(wǎng)址。

另外，谷歌還提供了自動(dòng)生成代碼的工具。相應(yīng)地，我們在開發(fā)的過程中也做了一個(gè)直接通過對象來生成數(shù)據(jù)庫所有相關(guān)操作的小工具，它節(jié)約了我們大量的時(shí)間。

Kubernetes 落地

最后和大家分享一下，我們在 Kubernetes 落地過程中所遇到的一些問題：

• Pod 重啟方式。由于 Pod 所謂的重啟實(shí)際上是新建一個(gè) Pod，并且放棄以前那個(gè)舊的，因此這對于我們的企業(yè)環(huán)境來說是無法接受的。
• Kubernetes 無法限制容器文件系統(tǒng)大小。有時(shí)候程序員在寫業(yè)務(wù)代碼時(shí)，由于不慎，會(huì)導(dǎo)致日志文件在一天之內(nèi)激增 100 多 GB，從而占滿了磁盤并導(dǎo)致報(bào)警。

然而我們發(fā)現(xiàn)，在 Kubernetes 里好像并沒有相關(guān)的屬性去限制文件系統(tǒng)的大小，因此我們不得不對它進(jìn)行了略微的修改。

• DNS 改造。您可以采用自己的 DNS，也可以使用 Kubernetes 的 DNS。不過我們在使用 Kubernetes DNS 之前，專門花時(shí)間對它進(jìn)行了定制與改造。
• Memory.kmem.slabinfo。當(dāng)我們創(chuàng)建容器到了一定程度時(shí)，會(huì)發(fā)現(xiàn)容器再怎么也無法被創(chuàng)建了。我們雖然嘗試過釋放容器，但是發(fā)現(xiàn)還是受到了內(nèi)存已滿的限制。

經(jīng)過分析，我們發(fā)現(xiàn)：由于我們使用的 Kernel 版本為 3，而 Kubelet 激活開啟了 cgroupkernel-memory 這一測試屬性特性，同時(shí) Centos7-3.10.0-693 的 Kernel 3 對于該特性支持并不好，因此耗光了所有的內(nèi)存。

[[240444]]

李健，餓了么 計(jì)算力交付部負(fù)責(zé)人，擁有多年豐富的容器系統(tǒng)建設(shè)經(jīng)驗(yàn)，并推進(jìn)了餓了么平臺(tái)容器化；擅長將容器的敏捷性和標(biāo)準(zhǔn)化進(jìn)行企業(yè)級落地，是企業(yè)內(nèi)部多個(gè)基于容器的云計(jì)算項(xiàng)目的開發(fā)負(fù)責(zé)人。熱愛開源，熱衷于用開源項(xiàng)目解決企業(yè)問題。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】