然而相比起Kubernetes的熱度和知名度，這個(gè)被人們寄予厚望的工具在企業(yè)中成功落地的著名案例卻少的多了。尤其是在傳統(tǒng)的企業(yè)之中，不管是開發(fā)和運(yùn)維都在反映Kubernetes有點(diǎn)難，不容易使用。為什么會(huì)這樣？
原因很簡(jiǎn)單，Kubernetes不是設(shè)計(jì)來直接使用的。我們先來看看Google自己是怎么說的吧：
Kelsey Hightower 是谷歌云非常資深的布道師，可以說他的聲音也就代表了谷歌官方的思路，而這個(gè)思路對(duì)于Kubernetes的定位很明確：Kubernetes本身并不是一個(gè)直接可用的平臺(tái)，而是一個(gè)用來構(gòu)建平臺(tái)的基礎(chǔ)。
也可以打個(gè)比方，如果我們把現(xiàn)代的云平臺(tái)看成是一個(gè)操作系統(tǒng)的話，那么Kubernetes只是這個(gè)操作系統(tǒng)的內(nèi)核。從一個(gè)操作系統(tǒng)的內(nèi)核到一個(gè)企業(yè)級(jí)操作系統(tǒng)還差多少東西？相信讀者們都應(yīng)該很清楚。
所以，不管是開發(fā)還是運(yùn)維，若想把“傳說中”Kubernetes的各種威力發(fā)揮出來，只是靠Kubectl而沒有其他合適的工具，那是非常困難的。例如，我們來看看以下幾個(gè)場(chǎng)景：
- 某公司A有幾個(gè)應(yīng)用軟件開發(fā)商與其長(zhǎng)期合作，目前都是通過容器鏡像的方式為該公司提供最新的軟件版本。但是由于歷史原因，各開發(fā)商提供的鏡像中的操作系統(tǒng)，中間件或者軟件工具各不相同，經(jīng)常出現(xiàn)因?yàn)榘踩蛘吆弦?guī)問題無法部署到生產(chǎn)環(huán)境而引起項(xiàng)目交付延遲的情況；
- 某公司B基于某個(gè)版本的操作系統(tǒng)已經(jīng)在生產(chǎn)環(huán)境中部署了幾百個(gè)容器，并且運(yùn)行良好。最近該公司的IT部門得知該公司當(dāng)前版本的操作系統(tǒng)發(fā)現(xiàn)了嚴(yán)重的安全漏洞，需要立即打上安全補(bǔ)丁，但是這些應(yīng)用絕大多數(shù)是要求不間斷運(yùn)行的，怎么辦？
- 某公司C為了提高生產(chǎn)效率，已經(jīng)在內(nèi)部建立起了CI/CD管道來自動(dòng)化軟件的開發(fā)測(cè)試部署過程，并且一直在根據(jù)使用效果做持續(xù)改進(jìn)。最近該公司發(fā)現(xiàn)一年前部署的一個(gè)軟件版本出現(xiàn)了bug需要修復(fù)，但是現(xiàn)在的CI/CD管道已經(jīng)做了幾次修改，其中依賴的軟件版本都已經(jīng)有了變化，已經(jīng)無法重新構(gòu)建出原來的軟件環(huán)境，只有重新手工操作或者重新配置CI/CD管道…
這些例子在日常工作中可能都非常常見，他們集中體現(xiàn)了在企業(yè)環(huán)境中使用Kubernetes的一個(gè)典型的難點(diǎn)：如何同時(shí)滿足開發(fā)團(tuán)隊(duì)對(duì)于“高效率”和運(yùn)維團(tuán)隊(duì)對(duì)于“安全可控”的需求？
而這正是kpack所要解決的問題。
Kpack，其全名是Kubernetes Native Container Build Service，如其英文名所示，是一個(gè)Kubernetes原生的容器構(gòu)建工具。Kpack具體能做什么事情？它又能為我們?nèi)粘５拈_發(fā)和運(yùn)維工作帶來哪些助益？下面容我為大家細(xì)細(xì)道來。
什么是Kpack？
Kpack是由原來的Pivotal，也就是現(xiàn)在的VMWare開源的軟件工具。簡(jiǎn)單來講，kpack其實(shí)就是Kubernetes的一組擴(kuò)展的資源定義（CRD），它通過聲明式的方式來配置一個(gè)符合OCI標(biāo)準(zhǔn)的容器鏡像，然后可以直接通過源代碼來自動(dòng)化地構(gòu)建這個(gè)鏡像并上傳到指定的鏡像倉庫。
廢話不多說，我們先通過一個(gè)動(dòng)畫來看看Kpack是怎么使用的：
在動(dòng)畫中，演示人員首先創(chuàng)建了一個(gè)容器鏡像的描述文件image.yaml，然后直接執(zhí)行kubectl apply -f image.yaml，我們可以看到容器鏡像就已經(jīng)構(gòu)建成功并且上傳到了鏡像倉庫中！
為了了解清楚整個(gè)過程都發(fā)生了什么事情，我們不妨把整個(gè)動(dòng)畫一幀一幀地再重放一遍。
首先我們看一下演示人員使用的image.yaml都包含哪些內(nèi)容：
在這個(gè)描述文件中，最關(guān)鍵的就是兩個(gè)配置項(xiàng)：tag和source。其中，“tag”指的就是生成的容器鏡像，而“source”則是軟件版本管理系統(tǒng)中源代碼的位置（url）和版本（revision）。這里假設(shè)版本管理用的是git。
當(dāng)然，在執(zhí)行命令kubectl apply -f image.yaml之前，這個(gè)Kubernetes集群已經(jīng)已經(jīng)配置好了鏡像倉庫例如Harbor等，并且這里配置的serviceAccount可以訪問該鏡像倉庫。
然后我們?cè)倏纯唇酉聛淼膸讉�(gè)命令在做什么。
- Kubectl get images: kpack會(huì)對(duì)每個(gè)構(gòu)建出來的鏡像進(jìn)行記錄，調(diào)用這個(gè)命令會(huì)列出當(dāng)前所有kpack構(gòu)建的鏡像。當(dāng)然，如果想查看某個(gè)鏡像的詳細(xì)信息，可以調(diào)用命令kubectl describe image
。
- Kubectl get builds: 除了構(gòu)建的容器鏡像以外，kpack也同樣會(huì)對(duì)每一次鏡像構(gòu)建的build過程做記錄，用kubectl get builds就可以獲得過去所有構(gòu)建鏡像的build操作。為了很明顯地看出每一次build具體對(duì)應(yīng)于哪一個(gè)鏡像，build的名稱都是用鏡像的名字做開頭，后面加上隨機(jī)數(shù)字，就如上圖所顯示的那樣。同樣，用kubectl describe build也可以看到具體build的詳細(xì)信息。
- Logs -image=demo-image: 查看鏡像構(gòu)建的日志。“logs”是kpack提供的一個(gè)日志工具，可以專門用來查看kpack打印出來的日志，可以用于鏡像構(gòu)建的調(diào)試。
那么日志究竟打印出來了什么內(nèi)容？如下可以看到日志開頭的一小部分：
沒錯(cuò)，對(duì)PaaS產(chǎn)品有一定了解的讀者可能已經(jīng)猜到了，kpack的核心，真正執(zhí)行容器構(gòu)建操作的其實(shí)就是著名的Buildpacks，現(xiàn)在也是CNCF中最受關(guān)注的開源項(xiàng)目之一：Cloud Native Buildpacks。
為了讓大家對(duì)Buildpack和其工作機(jī)制有一些了解，這里有必要先來簡(jiǎn)單介紹一下Buildpack和Cloud Native Buildpacks的關(guān)系。
BuildPacks和Cloud Native Buildpacks
Cloud Native Buildpacks是從早年P(guān)ivotal和Heroku提出的buildpack的概念演化而來。Buildpack的主要思路就是：在多數(shù)情況下，把軟件從源碼打包到容器鏡像的過程是一個(gè)重復(fù)性操作，因此應(yīng)該完全是自動(dòng)化的。
為了完全實(shí)現(xiàn)這個(gè)自動(dòng)化過程，Buildpack里面包含了構(gòu)建一個(gè)容器鏡像所需要的主要組件，如操作系統(tǒng)，容器化的中間件，開源組件，主流編程語言的運(yùn)行環(huán)境和通用服務(wù)等。例如，早期的Buildpacks支持的語言包括Java，Windows（托管Web Core）上的。NET，。NET Core，Node.js，Go，PHP，Python和Ruby等。
使用Buildpack方法，在部署應(yīng)用程序時(shí)，Buildback程序?qū)⒆詣?dòng)生成，容器化和運(yùn)行應(yīng)用程序所需的所有框架和運(yùn)行時(shí)支持匯總在一起。它通過“讀取”代碼并下載運(yùn)行它所需的依賴項(xiàng)來實(shí)現(xiàn)。比如說，如果發(fā)現(xiàn)push上來的文件當(dāng)中包含了。jar文件，那么就選擇用Java Buildpacks來構(gòu)建容器鏡像；如果包含了。php文件，那么則會(huì)用PHP Buildpack來構(gòu)建容器鏡像，等等。除此之外， Buildpack還會(huì)配置該應(yīng)用程序所需的網(wǎng)絡(luò)服務(wù)。
作為Buildpack的聯(lián)合發(fā)起者，自然Heroku和Pivotal都把Buildpack集成到了自己的PaaS平臺(tái)當(dāng)中，例如Pivotal主導(dǎo)開發(fā)的開源PaaS平臺(tái)Cloud Foundry以及自己的商業(yè)產(chǎn)品Pivotal Application Service（Pivotal Cloud Foundry的2.0版本），就是依賴于Buildpacks打造了廣受企業(yè)開發(fā)者喜愛的應(yīng)用一鍵部署的體驗(yàn)“cf push”，如下所示：
cf push是Cloud Foundry的一個(gè)命令，開發(fā)人員通過這個(gè)命令，可以把自己編譯好的應(yīng)用“扔到”PAS平臺(tái)上，然后PAS平臺(tái)就會(huì)為應(yīng)用自動(dòng)選擇合適的Buildpack，將應(yīng)用封裝到容器里面，并自動(dòng)完成以上列出的所有上線步驟（部署容器，加載環(huán)境變量，配置負(fù)載均衡，配置防火墻和安全策略，配置APM，配置日志等等）。
更重要的是，很多已經(jīng)大規(guī)模用于生產(chǎn)環(huán)境的Buildpack是由一些公司定期維護(hù)和更新的。因此，開發(fā)和運(yùn)維人員都不用擔(dān)心他們所使用的軟件和庫是否是最新和最安全的，因?yàn)樗鼈円呀?jīng)內(nèi)嵌到Buildpacks中了。這正像大型Buildpack支持者Pivotal也就是現(xiàn)在的VMware所說的那樣，“您不必考慮依賴庫，中間件或運(yùn)行時(shí)組件，平臺(tái)可以為您完成。”
而在近年來隨著Kubernetes逐漸發(fā)展成為標(biāo)準(zhǔn)基礎(chǔ)設(shè)施的一部分，業(yè)界對(duì)于將Buildpacks用于Kubernetes平臺(tái)的呼聲越來越高。因此，Pivotal（VMWare）和Heroku又將Buildpacks在Kubernetes平臺(tái)之上做了適配和優(yōu)化，并且啟動(dòng)了一個(gè)新的CNCF項(xiàng)目Cloud Native Buildpack（以下簡(jiǎn)稱CNB）。相比之前的Buildpacks，CNB的能力又得到了進(jìn)一步的提升：開發(fā)人員甚至都不用自己去編譯代碼了，CNB已經(jīng)支持了源代碼在線編譯的能力，所以開發(fā)人員可以直接把應(yīng)用的源代碼“扔”給CNB，CNB就可以自動(dòng)對(duì)源碼進(jìn)行編譯并打包成容器鏡像！
那么下面我們就對(duì)Kpack的引擎CNB做一下深入的分解，看看它究竟是如何工作的。
Cloud Native Buildpacks的工作原理
我們可以用多種方式來集成CNB，不過對(duì)于CNB來說，不管如何被集成，它的工作總是從接收到應(yīng)用的源碼開始的。
我們還是看一下Kpack的場(chǎng)景。Kpack會(huì)從指定的url下載應(yīng)用的源碼，然后將這些源碼交給CNB。在CNB接收到了源代碼之后，會(huì)通過如下四個(gè)步驟完成它自己的全部任務(wù)：
- Detection（檢測(cè)）: 查找系統(tǒng)中可以用于應(yīng)用構(gòu)建的Buildpack，例如Java Buildpack， .Net Buildpack, Go Buildpacks等等，然后按照默認(rèn)的順序逐個(gè)判斷哪個(gè)Buildpack可以用于當(dāng)前代碼的構(gòu)建；
- Analysis（分析）: 確定具體的Buildpack之后，將Buildpack解包，找到那些可以用于優(yōu)化構(gòu)建和導(dǎo)出階段的文件，以備稍后使用；
- Build（構(gòu)建）: 將應(yīng)用程序源代碼轉(zhuǎn)換為可打包到容器中的可運(yùn)行工件；
- Export（打包）: 創(chuàng)建最終的符合OCI標(biāo)準(zhǔn)的容器鏡像。
注意，雖然Docker鏡像在日常工作中使用最多，但是CNB旨在支持所有符合OCI標(biāo)準(zhǔn)的鏡像格式。
那么我們還是看看剛才kpack打印出來的日志，就大概了解這四部分是怎么工作的了。
首先，從日志的第一行，我們看到Kpack將示例應(yīng)用源代碼clone下來，然后交給了CNB。訪問一下這個(gè)應(yīng)用所在的url，我們會(huì)發(fā)現(xiàn)這個(gè)應(yīng)用是一個(gè)Node.js應(yīng)用。
然后，CNB開始啟動(dòng)第一步，檢測(cè)自己現(xiàn)有的Buildpack哪一個(gè)能夠支持這個(gè)代碼的構(gòu)建。
1、檢測(cè)
為了便于Buildpack的管理，我們看CNB將Buildpack按照編程語言分成了不同的組，如果開發(fā)人員不指定具體的Buildpack，那么CNB就會(huì)把每個(gè)組都拿出來逐個(gè)與源碼進(jìn)行匹配，下面的日志顯示了第一組所包含的Buildpack。
很明顯第一組里面包含的都是支持Java的buildpack，因?yàn)镴ava在企業(yè)應(yīng)用中最為常見，所以在這里檢測(cè)時(shí)把這一組放在最前面。但是由于這個(gè)應(yīng)用是node.js的，所以第一組不合適。（如果開發(fā)人員用Spring Boot去開發(fā)應(yīng)用，從最新的2.3版本開始，其實(shí)還有更簡(jiǎn)單的方法使用Java Buildpacks，后面我們會(huì)提到。）
第二組和第三組都有Node Engine Buildpack，不同的第二組的包管理用的是Yarn，而第三組用的是NPM。由于CNB在源碼當(dāng)中發(fā)現(xiàn)了package.json而沒有yarn的關(guān)鍵文件yarn.lock,所以CNB判斷這個(gè)需要用NPM Buildpack來支持。所以，第三組的兩個(gè)buildpack全部檢測(cè)通過 ，第一個(gè)步驟完成，開始進(jìn)行第二步的操作。
2、分析
在確定了Buildpack之后，可以看到日志里面有這樣一句：“Cache ‘/cache’： metadata not found, nothing to restore”。這是在分析Buildpack之前，kpack首先要先看看對(duì)于這個(gè)應(yīng)用源代碼，系統(tǒng)內(nèi)部有沒有緩存的直接可用的鏡像層的緩存。這個(gè)緩存機(jī)制非常重要，因?yàn)殡S著應(yīng)用的不斷迭代，每天都需要不斷地修改源碼并且進(jìn)行測(cè)試，如果有這樣一個(gè)cache將之前已經(jīng)構(gòu)建好的鏡像層在內(nèi)部進(jìn)行緩存，那么在應(yīng)用的首次構(gòu)建之后，以后的構(gòu)建就無需再一遍遍重新“拼接”出這個(gè)鏡像層，在完成第一步檢測(cè)之后直接使用cache中的鏡像層就可以了。
在本例中，因?yàn)槭堑谝淮螛?gòu)建，所以Kpack沒有發(fā)現(xiàn)cache中有已經(jīng)構(gòu)建過的鏡像層，所以就需要對(duì)鏡像的配置（主要基于image.yaml）進(jìn)行分析，并依次調(diào)用兩個(gè)Buildpack進(jìn)行鏡像的構(gòu)建工作。
看到這里我們一定要說清楚一個(gè)很重要的問題：對(duì)每一個(gè)編程語言就用一個(gè)Buildpack不就行了嗎？這樣多方便，干嘛要分解成多個(gè)Buildpack來完成？
靈活性肯定是這個(gè)問題的答案之一，但是其實(shí)這里面還有另外一個(gè)更重要的因素，那就是這個(gè)平臺(tái)的可維護(hù)性。
我們可以回想一下文章開頭提到的B公司的例子。如果一家公司基于某個(gè)版本的操作系統(tǒng)已經(jīng)部署了很多容器，而后來這個(gè)版本的操作系統(tǒng)出現(xiàn)嚴(yán)重的安全漏洞需要打安全補(bǔ)丁，那該怎么辦？把所有的這些應(yīng)用的鏡像全部重新構(gòu)建，測(cè)試，升級(jí)部署嗎？如果這樣的容器有幾百個(gè)甚至幾千個(gè)，這得需要多少工作量？！多長(zhǎng)時(shí)間才能完成？只怕是還沒等完成，黑客就已經(jīng)入侵系統(tǒng)了…
而在CNB里面，每一個(gè)Buildpack都被設(shè)計(jì)成可以構(gòu)建為鏡像的一個(gè)layer，這樣當(dāng)每一個(gè)buildpack中包含的軟件出現(xiàn)了新版本，需要打安全補(bǔ)丁，或者需要進(jìn)行定制，我們只需要修改這個(gè)buildpack就好，正如下圖所示：
即便是對(duì)于已經(jīng)用原來的Buildpack已經(jīng)構(gòu)建并已經(jīng)運(yùn)行的容器鏡像，也無需重新對(duì)原來的鏡像全部重新構(gòu)建，因?yàn)镃NB提供了rebase的功能，通過這個(gè)功能，CNB會(huì)檢查應(yīng)用當(dāng)前的基礎(chǔ)鏡像是不是有最新版本可用，如果有的話，可以將已經(jīng)構(gòu)建好的容器中的基礎(chǔ)鏡像直接替換掉。對(duì)于那些未來要開發(fā)運(yùn)維幾百，幾千甚至幾萬容器的企業(yè)來說，這個(gè)功能不管是對(duì)于開發(fā)人員還是運(yùn)維人員來說，無疑都是一個(gè)福音。
說清楚了這一點(diǎn)，我們也就很容易看懂例子中這兩個(gè)Buildpack在做什么了：
- Node Engine Buildpack會(huì)下載Node.js的運(yùn)行時(shí)環(huán)境，并進(jìn)行配置；
- NPM Buildpack會(huì)根據(jù)package.json中的內(nèi)容，下載編譯運(yùn)行本應(yīng)用所需要的所有的依賴庫；
這兩部分分別構(gòu)成了容器鏡像中的兩層。這樣構(gòu)建容器鏡像的材料都已經(jīng)齊備，可以開始build image了。
3、構(gòu)建
對(duì)于Node.js來說，因?yàn)榇a不需要編譯就可以運(yùn)行，所以這一步很簡(jiǎn)單，只是需要把源代碼copy過來就可以了。
如果是其他需要編譯的語言比如說Java，這里可能就需要Maven或者Gradle的Buildpack（根據(jù)應(yīng)用源代碼的配置）來對(duì)源碼進(jìn)行編譯了。
4、打包
從日志當(dāng)中我們可以看出，這個(gè)image構(gòu)建成功，共由5個(gè)layer組成，分別是app，config，launcher，以及分別由兩個(gè)Buildpack所構(gòu)建的node engine和node modules。
這里特別需要注意的是日志打印出的最后一行：“Caching layer …”。正如之前提到的，在這次構(gòu)建完成之后，node engine這一層的layer將會(huì)被緩存在系統(tǒng)中，這樣以后再重新構(gòu)建該應(yīng)用的鏡像的時(shí)候，就無須再重新下載node.js的運(yùn)行時(shí)并構(gòu)建這層layer了。
至此，鏡像已經(jīng)構(gòu)建完成。我們也已經(jīng)了解了CNB是如何通過一系列自動(dòng)化的操作將應(yīng)用的源代碼直接構(gòu)建成容器鏡像的。事實(shí)上，Buildpack的技術(shù)體系經(jīng)過近10年的不斷發(fā)展和優(yōu)化到今天，已經(jīng)兼?zhèn)淞顺墒煨院挽`活性，除了今天我們所介紹的KPack以外，通過把它和其他的技術(shù)相結(jié)合，可以開發(fā)出各種高效的新平臺(tái)，或者是推動(dòng)現(xiàn)有工具的創(chuàng)新發(fā)展。
例如，就如前文所提到的，在企業(yè)最常用的微服務(wù)開發(fā)框架Spring Boot的2.3版本中，已經(jīng)預(yù)集成了Cloud Native Buildpacks，而且使用起來非常簡(jiǎn)單。具體來說，通過在Maven中使用新的spring-boot:build-image goal，或者是在Gradle中使用bootBuildImage task，都可以通過我們剛剛介紹的CNB的能力直接將源碼構(gòu)建成為容器鏡像。有興趣的讀者不妨一試，體驗(yàn)一下無需安裝任何工具便可以實(shí)現(xiàn)的全自動(dòng)化的鏡像構(gòu)建過程。
Kpack的使用
所有的開源項(xiàng)目，包括像Kpack這樣的項(xiàng)目，如果真的想要在實(shí)際工作中使用，都會(huì)有一些特別的問題需要注意，下面我們就了解一下幾個(gè)比較重要的問題。
從哪里可以找到Buildpacks？
其實(shí)對(duì)于我們一般的用戶來說，不用關(guān)心哪里去找Buildpacks，因?yàn)槲覀兛赡艹Ｓ玫腂uildpacks已經(jīng)內(nèi)置在Kpack當(dāng)中以套件的方式存在，可以直接使用了，正像上面的例子當(dāng)中所描述的那樣。但是，我們最好還是應(yīng)該了解Buildpacks具體是怎樣被組織和管理的，這樣我們才能用它完成日常工作中更加復(fù)雜的需求比如說它的定制和升級(jí)。
在Kpack中，還有一個(gè)很重要的組件我們沒有提及，那就是Builder，而這個(gè)Builder就是Buildpacks的組合套裝。根據(jù)在K8s當(dāng)中的使用習(xí)慣，我們可以將Builder設(shè)定為供某一個(gè)namespace使用，或者供整個(gè)K8s全局使用的ClusterBuilder，這些都是通過yaml文件的配置實(shí)現(xiàn)，非常簡(jiǎn)單，不再贅述。
關(guān)鍵是Builder里面的結(jié)構(gòu)是怎么樣的？
Kpack的Builder其實(shí)是Cloud Native Buildpacks中Builder組件的CRD封裝，下面就是CNB中Builder組成的示意圖：
我們可以看到，Builder主要由三部分組成：Buildpacks，lifecycle以及build image。其中的lifecycle其實(shí)上面我們已經(jīng)詳細(xì)分析過，就是檢測(cè)，分析，構(gòu)建和打包這四個(gè)步驟，而build image則是build源代碼所需要的基礎(chǔ)鏡像環(huán)境。
我們?cè)趫D中的左邊也可以看到一個(gè)run image，從名字當(dāng)中可以得知，其實(shí)這個(gè)run image就是應(yīng)用打包好之后可以去部署的運(yùn)行環(huán)境。我們上面所提到的rebase的操作其實(shí)替換的就是這個(gè)run image：
由于CNB是公開的標(biāo)準(zhǔn)，所以Kpack可以使用任何滿足這樣規(guī)范的Builder。目前市場(chǎng)上面最為成熟和廣泛使用的builder是Packto Builders。而下面就是Packto Builder當(dāng)中包含的Java的Buildpacks：
Packto目前主要是由VMWare（Pivotal）來維護(hù)和發(fā)展。
當(dāng)然除了Packto的Builder，還有另外兩個(gè)Builder也是CNB官方推薦的，一個(gè)是來自于Google的用于GCP的Builder（gcr.io/buildpacks/builder）,另外一個(gè)則是來自于Salesforce的Heroku（heroku/buildpacks:18）。
Buildpack需要升級(jí)怎么辦？
Buildpack需要升級(jí)這是一個(gè)非常明顯的需求，并且因?yàn)楝F(xiàn)在技術(shù)迭代的速度越來越快，軟件版本更新的頻率也越來越快，這樣在一年里面升級(jí)幾次Buildpack是很正常的事情。
目前CNB官方推薦的builder，比如說像Packto Builder，會(huì)實(shí)時(shí)跟蹤所包含的Buildpacks里面是否有任何新的升級(jí)或者安全補(bǔ)丁，并及時(shí)對(duì)這些Buildpack進(jìn)行更新。所以，如果在Kpack里面選擇使用像Packto這樣比較成熟的Builder，用戶自己并不需要對(duì)Buildpack的升級(jí)做操作，只是需要考慮自己本地的升級(jí)策略和配置就可以了。
比如說下面是Kpack里面一個(gè)Builder的定義，也是一個(gè)CRD：
- apiVersion: build.pivotal.io/v1alpha1
- kind: ClusterBuilder
- metadata:
- name: cluster-sample-builder
- spec:
- image: gcr.io/paketo-buildpacks/builder:base
- updatePolicy：polling
在builder的配置里面，有一個(gè)updatePolicy的配置項(xiàng)，這個(gè)配置項(xiàng)可以有兩個(gè)選擇，一個(gè)是“polling”，如果選擇這個(gè)選項(xiàng)，Kpack會(huì)每隔5分鐘去查看一下正在使用的builder有沒有變化；也可以選擇“external”，在這種情況下是由用戶自己負(fù)責(zé)去升級(jí)替換Buildpack。
定制自己的Builder
下面我們把難度再提高一點(diǎn)：如何定制自己的Builder？
Kpack提供了另外一個(gè)CRD – CustomBuilder來支持用戶自定義CNB builder的需求。但是在定義自己的Builder之前，首先需要在Kpack里面定義兩個(gè)關(guān)鍵的資源：Store和Stack。
- Store的定義
首先是一個(gè)Store定義的例子：
apiVersion: experimental.kpack.pivotal.io/v1alpha1
kind: Store
metadata:
name: sample-store
spec:
sources:
- image: gcr.io/cf-build-service-public/node-engine-buildpackage@sha256:95ff756f0ef0e026440a8523f4bab02fd8b45dc1a8a3a7ba063cefdba5cb9493
- image: gcr.io/cf-build-service-public/npm-buildpackage@sha256:5058ceb9a562ec647ea5a41008b0d11e32a56e13e8c9ec20c4db63d220373e33
- image: gcr.io/paketo-buildpacks/builder:base
Store其實(shí)就是一個(gè)Buildpack的庫，在這個(gè)庫里面包含了可以用于定義CustomBuilder的所有的Buildpacks。例如，如果我們想從幾個(gè)Builder里面選出一些滿足自己需求的Buildpacks拼接成一個(gè)CustomBuilder，那么我們首先就需要把這些Buildpacks都列在這個(gè)Store對(duì)象里面，正如上面yaml文件所展示的那樣。
- Stack的定義
在上文已經(jīng)提過，其實(shí)Stack就是定義基礎(chǔ)鏡像的地方。Stack會(huì)包含兩個(gè)基礎(chǔ)鏡像，一個(gè)是用于Build的，另外一個(gè)是用于應(yīng)用的運(yùn)行時(shí)環(huán)境的。下面就是一個(gè)示例的Stack的定義：
- apiVersion: experimental.kpack.pivotal.io/v1alpha1
- kind: Stack
- metadata:
- name: bionic-stack
- spec:
- id: "io.buildpacks.stacks.bionic"
- buildImage:
- image: "gcr.io/paketo-buildpacks/build@sha256:84f3eb6655aa126d827c07a3badbad3192288a50986be1b28ad2526bd38c93c7"
- runImage:
- image: "gcr.io/paketo-buildpacks/run@sha256:e30db2d9b15e0da9f4171e48430ce9249319c126ce6b670b68443e6c13e91aa5"
其中，id是這個(gè)stack的定義，當(dāng)然企業(yè)可以根據(jù)自己的需求定義多個(gè)stack。BuildImage和runImage分別對(duì)應(yīng)于構(gòu)建和運(yùn)行所使用的基礎(chǔ)鏡像模版。
由于很多企業(yè)對(duì)自己的基礎(chǔ)鏡像都有自己的要求，因此使用Stack來定義這些基礎(chǔ)鏡像是一個(gè)很好的辦法，因?yàn)檫@實(shí)際上是在企業(yè)內(nèi)部建立起了一個(gè)標(biāo)準(zhǔn)鏡像，來自不同團(tuán)隊(duì)的開發(fā)人員或者應(yīng)用軟件供應(yīng)商，通過使用Kpack生成容器鏡像的過程中，默認(rèn)就已經(jīng)遵循了企業(yè)安全和合規(guī)性等的要求，從而很好的解決了開發(fā)/測(cè)試/生產(chǎn)環(huán)境差異性的問題。
有了Buildpack和基礎(chǔ)鏡像，下面就可以定義自己的Builder了。比如說，如果一個(gè)企業(yè)的某個(gè)開發(fā)團(tuán)隊(duì)主要基于Node.js和Java來開發(fā)應(yīng)用，那么可以為他們定制如下的一個(gè)CustomBuilder：
- apiVersion: experimental.kpack.pivotal.io/v1alpha1
- kind: CustomBuilder
- metadata:
- name: my-custom-builder
- spec:
- tag: gcr.io/sample/custom-builder
- serviceAccount: default
- stack: bionic-stack
- store: sample-store
- order:
- group:
- id: paketo-buildpacks/node-engine
- id: paketo-buildpacks/yarn
- group:
- id: paketo-buildpacks/adopt-openjdk
- id: paketo-buildpacks/gradle
optional: true
- id: paketo-buildpacks/maven
optional: true
- id: paketo-buildpacks/executable-jar
optional: true
- id: paketo-buildpacks/apache-tomcat
optional: true
- id: paketo-buildpacks/spring-boot
optional: true
- id: paketo-buildpacks/dist-zip
optional: true
我們看，這個(gè)CustomBuilder使用了上面的store和stack，然后定義了兩個(gè)group，分別對(duì)應(yīng)于編譯Node.js應(yīng)用所需要的Buildpack和Spring Boot應(yīng)用所需要的Buildpack。
我們?cè)倩氐奖疚囊婚_始提到的那個(gè)例子，在例子中鏡像的定義image.yaml文件中是這樣指定所用的builder的：builderRef: demo-builder。我們也可以把這個(gè)配置改成如下這樣：
- builder:
- name: my-custom-builder
- kind: CustomBuilder
這樣，Kpack就會(huì)用我們剛才定義的builder來構(gòu)建這個(gè)鏡像了。
定制自己的Buildpack
Builder可以定制，Buildpack也同樣可以。比如說，對(duì)于文章開頭提到的公司C的例子，即便都是在用Java開發(fā)應(yīng)用，但是不同的應(yīng)用依賴的JDK版本有可能個(gè)不相同，這種情況下我們可能就需要對(duì)每一個(gè)JDK版本定制一個(gè)Buildpack，并且保存在系統(tǒng)中以用于后面軟件的更新和升級(jí)。這種情形可能相對(duì)比較簡(jiǎn)單，我們可以拷貝一個(gè)現(xiàn)有的Java Buildpack，然后對(duì)配置做相應(yīng)的修改，重新打包就可以了。
但是有的時(shí)候，Buildpack的定制可能會(huì)很復(fù)雜。比如說如果需要在Buildpack中加入公司要求的APM或者日志管理的agent，或者應(yīng)用要滿足一些合規(guī)性要求，這樣就需要對(duì)Buildpack的結(jié)構(gòu)作比較多的修改，甚至有可能需要完全重新做一個(gè)自己的Buildpack才能完全滿足要求。這一部分涉及到的的內(nèi)容可能也會(huì)比較復(fù)雜，在本文中就不詳述，以后有機(jī)會(huì)可以用一個(gè)單獨(dú)的主題來分享。
Kpack的展望
一直以來，開發(fā)人員對(duì)效率的追求和運(yùn)維人員對(duì)環(huán)境的控制始終是以尖銳的矛盾形式存在，而Buildpack技術(shù)體系在過去十年在世界各大領(lǐng)軍企業(yè)的大規(guī)模生產(chǎn)實(shí)踐中，成功證明了它可以作為開發(fā)和運(yùn)維需求的橋梁，把這對(duì)矛盾巧妙地轉(zhuǎn)化為了雙方一致的目標(biāo)：在安全可控環(huán)境之內(nèi)的應(yīng)用快速開發(fā)和部署。
而伴隨著Kubernetes逐漸成為基礎(chǔ)設(shè)施的新標(biāo)準(zhǔn)，Kubernetes社區(qū)也急需要類似Buildpack這樣的技術(shù)來大大降低Kubernetes在企業(yè)落地的難度。這正是VMware（Pivotal）開源Kpack的主要原因：我們希望將世界范圍內(nèi)廣受認(rèn)可的Buildpack的技術(shù)體系和Kubernetes的聲明式資源管理方式結(jié)合在一起，把過去成功的經(jīng)驗(yàn)移植到K8s平臺(tái)上面來，為社區(qū)提供一個(gè)基礎(chǔ)和參考去做更多的創(chuàng)新。
當(dāng)然，我們首先自己就有基于Kpack的企業(yè)級(jí)版本，那就是VMWare Tanzu產(chǎn)品家族中的Tanzu Build Service和Tanzu Application Service for K8s。下面我們可以分別來簡(jiǎn)單了解一下這兩個(gè)企業(yè)級(jí)版本。
Tanzu Build Service：企業(yè)級(jí)容器鏡像構(gòu)建流水線
與很多開源軟件的企業(yè)級(jí)版本一樣，Tanzu Build Service（以下簡(jiǎn)稱TBS）致力于將kpack與其相關(guān)的工具集成在一起，例如默認(rèn)的Buildpacks和Kubernetes權(quán)限模型，這樣大大減少手工的配置工作，使平臺(tái)更加容易使用。
另外，我們深知很多研發(fā)和運(yùn)維工程師都不喜歡寫yaml文件，所以TBS還將提供一個(gè)稱為kp的可選專用CLI，以幫助工程師更快地工作，并更輕松地管理團(tuán)隊(duì)的多租戶。
當(dāng)然，最重要是我們提供Buildpacks的支持和維護(hù)工作，這將會(huì)使TBS的用戶放心使用安全和穩(wěn)定的軟件棧來部署自己的應(yīng)用。
TBS比較適合于已經(jīng)建立了自己的CI/CD管道的企業(yè)，因?yàn)門BS解決了最繁瑣的從代碼到容器鏡像的自動(dòng)化過程，可以直接與企業(yè)后面的應(yīng)用自動(dòng)部署整合在一起，形成端到端的應(yīng)用部署管道。
您可以通過https://tanzu.vmware.com/build-service來進(jìn)一步了解TBS。
然而，很多企業(yè)的要求可能更高，他們希望自己有一個(gè)全自動(dòng)化的平臺(tái)，不但整個(gè)應(yīng)用的構(gòu)建環(huán)境和運(yùn)行環(huán)境完全可控，同時(shí)希望平臺(tái)可以提供從代碼到部署完成的全自動(dòng)化服務(wù)，就像是上文提到的Pivotal Application Service的“一鍵部署”那樣的體驗(yàn)。
這就要用到我們另外一個(gè)基于Kpack的商業(yè)產(chǎn)品：Tanzu Application Service for K8s了。
TAS for K8s：實(shí)現(xiàn)Kubernetes平臺(tái)上面的應(yīng)用一鍵部署
TAS for K8s，全名是Tanzu Application Services for K8s，是VMWare Tanzu產(chǎn)品家族里面的PaaS平臺(tái)，正是來源于原來的Pivotal Application Service在K8s平臺(tái)上面的實(shí)現(xiàn)（原來的Pivotal Aplication Service現(xiàn)在名稱為TAS for VM）。
雖然從原來的基于虛擬機(jī)運(yùn)行的構(gòu)架重構(gòu)為現(xiàn)在面向K8s的構(gòu)架，TAS for K8s上面提供的一鍵部署的產(chǎn)品體驗(yàn)仍然會(huì)和原來的Pivotal Application Service類似，甚至連CLI工具都保持不變（仍然是cf push）。
在實(shí)際工作場(chǎng)景中TAS for K8s是怎么用的？
如果從一個(gè)開發(fā)工程師的角度來看，他只需在自己的源代碼目錄里面直接執(zhí)行一個(gè)cf push命令，一兩分鐘之后，他的應(yīng)用已經(jīng)部署在K8s集群里面可以直接訪問了！在整個(gè)流程中，Kpack會(huì)負(fù)責(zé)從代碼構(gòu)建為鏡像的部分，然后鏡像構(gòu)建好之后會(huì)觸發(fā)鏡像的自動(dòng)化部署過程，這個(gè)過程主要是由另外一個(gè)開源項(xiàng)目Eirini來實(shí)現(xiàn)，它會(huì)自動(dòng)生成yaml文件，并將鏡像部署為K8s服務(wù)供外部訪問。
而從運(yùn)維團(tuán)隊(duì)的角度來看，他們也不用再擔(dān)心每次應(yīng)用上線的時(shí)候晝夜鏖戰(zhàn)的痛苦經(jīng)歷了，因?yàn)橥ㄟ^在開發(fā)/測(cè)試/生產(chǎn)環(huán)境中維護(hù)同一套滿足安全，合規(guī)以及開發(fā)團(tuán)隊(duì)需求的Buildpacks，環(huán)境差異已經(jīng)不再存在，因此在生產(chǎn)環(huán)境上線已經(jīng)沒有多少需要手工準(zhǔn)備的工作，上線過程已經(jīng)簡(jiǎn)化成了幾條命令；同時(shí)也不用再擔(dān)心開源軟件可能帶來的安全漏洞，因?yàn)樗械穆┒炊紩?huì)在第一時(shí)間在Buildpacks里面被補(bǔ)上！
當(dāng)然，為了對(duì)這個(gè)平臺(tái)有全面的管理，我們也集成了很多K8s的工具來支撐微服務(wù)治理，日志，監(jiān)控，APM，高可用等方面的能力，也是通過自動(dòng)化配置的方式來減輕運(yùn)維人員的負(fù)擔(dān)。
您可以通過https://tanzu.vmware.com/application-service來了解更多關(guān)于TAS的詳細(xì)信息。
總結(jié)
未來的企業(yè)應(yīng)該需要什么樣的工具來使用Kubernetes？從我個(gè)人看來，其實(shí)答案很簡(jiǎn)單：這個(gè)工具應(yīng)該使工程師們，不管是開發(fā)還是運(yùn)維，忘記Kubernetes的存在，而不是成為Kubernetes的專家。因?yàn)槠髽I(yè)的主要目標(biāo)是自己核心業(yè)務(wù)的創(chuàng)新，而不是要開發(fā)IT基礎(chǔ)設(shè)施的產(chǎn)品。
過去的Pivotal一直是圍繞著這個(gè)目標(biāo)為企業(yè)提供產(chǎn)品，今天的VMWare也正在繼續(xù)為此而努力。不論是開源的Kpack，Cloud Native Buildpacks，還是商業(yè)產(chǎn)品TBS和TAS，都已經(jīng)開始展示出實(shí)現(xiàn)這樣目標(biāo)的能力，提供了一條從開源的Kubernetes到現(xiàn)代化的企業(yè)云平臺(tái)的最短實(shí)現(xiàn)路徑。但是與云原生技術(shù)的快速發(fā)展同步，這些產(chǎn)品也仍然還是處于快速發(fā)展之中，在未來還會(huì)有各種各樣令人興奮的新功能加入其中。所以歡迎各位讀者對(duì)這些產(chǎn)品保持關(guān)注，如果愿意試用并提出寶貴意見，我們將不勝感激，并且很愿意與您做深入探討。
楊海濤
Email: ypaul@vmware.com
WeChat: yanghaitao1979
作者介紹：楊海濤現(xiàn)任VMWare資深云平臺(tái)架構(gòu)師，對(duì)于應(yīng)用現(xiàn)代化，云原生平臺(tái)以及DevOps等領(lǐng)域有深入的理解和豐富的實(shí)踐經(jīng)驗(yàn)，目前主要負(fù)責(zé)VMWare Tanzu產(chǎn)品的解決方案設(shè)計(jì)，咨詢和推廣等工作，是Spring認(rèn)證工程師，Kubernetes認(rèn)證管理員以及AWS認(rèn)證架構(gòu)師。在超過15年的職業(yè)經(jīng)歷中，一直專注于軟件行業(yè)。從事過與軟件相關(guān)的多種工作，包括：技術(shù)研發(fā)、項(xiàng)目管理、技術(shù)支持、團(tuán)隊(duì)管理和系統(tǒng)架構(gòu)等，據(jù)有多個(gè)不同行業(yè)的大型項(xiàng)目經(jīng)驗(yàn)。來源：VMware中國(guó)
