作者 | 倚天碼農(nóng)

責(zé)編 | 屠敏

開發(fā)IDE

以前的IDE只支持應(yīng)用程序的開發(fā)，但云原生需要同時(shí)進(jìn)行開發(fā)環(huán)境（容器）的開發(fā)，理想的情況是一個(gè)IDE能同時(shí)支持兩者。我用的是Go語言，選擇的IDE是Goland（也就是IDEA IntelliJ），它本身是支持k8s的，你只要下載一個(gè)插件就行。它支持k8s的自動(dòng)完成（Auto-complete）等功能。如下圖所示，這樣你就擁有了同時(shí)支持應(yīng)用程序和k8s的IDE。

但我不得不說它對k8s的支持很初級，它不能理解k8s對象之間的內(nèi)在聯(lián)系。另外，k8s配置文件對格式要求很嚴(yán)，如果空格不對，或格式?jīng)]有對齊，在部署時(shí)會(huì)報(bào)錯(cuò)。Goland有檢查格式的功能，出了問題會(huì)報(bào)錯(cuò)，但并不是每個(gè)錯(cuò)誤它都能發(fā)現(xiàn)。也就是說當(dāng)它沒有報(bào)錯(cuò)時(shí)也不能肯定格式就是對的。這已經(jīng)發(fā)生好幾次了，IDE沒有報(bào)錯(cuò)，但部署時(shí)有問題。

關(guān)于IntelliJ對k8s的支持功能，請參見IntelliJ IDEA 2018.1: Kubernetes support（https://blog.jetbrains/idea/2018/03/intellij-idea-2018-1-kubernetes-support/）。

環(huán)境搭建

調(diào)式k8s是在Minikube上進(jìn)行的，而Minikube是安裝在Linux虛機(jī)上的。這就需要開發(fā)環(huán)境的宿主機(jī)和虛機(jī)之間能夠共享文件，這樣才能方便調(diào)試。我的開發(fā)環(huán)境是Windows，然后在Windows上裝了VirtualBox虛擬機(jī)，另外還安裝了Vagrant（它是管理虛擬機(jī)的一個(gè)軟件）作為界面來管理VirtualBox。

程序共享

我的Go應(yīng)用程序是在Windows上的“C:codesrcgithubjfeng45k8sdemo”目錄下，通過Vagrant可以把宿主機(jī)的目錄掛載到虛機(jī)上，這樣每次在IDE上修改了k8s的配置文件，在虛機(jī)上可以直接取到，不需要另外同步。

在Vagrant中的配置是這樣的：

config.vm.synced_folder "C:/code/src/github/jfeng45", "/home/vagrant/jfeng45", id: "jfeng45"

網(wǎng)絡(luò)共享

就是實(shí)現(xiàn)宿主機(jī)（筆記本）和虛機(jī)之間的互相訪問，主要是從宿主機(jī)訪問虛機(jī)。我用的是Vagrant， 因此要在Vagran的配置文件（Vagrantfile）里進(jìn)行配置。網(wǎng)絡(luò)的配置有不同方式，我配置的是私有網(wǎng)絡(luò)，這是一種很靈活的方式。它的配置方法是給宿主機(jī)和虛機(jī)各自設(shè)定一個(gè)固定的IP地址，這樣可以雙向互訪。

Vagrant 的配置命令：

“ config.vmwork“ private_network”, ip: "192 .168.50.4”

數(shù)據(jù)庫共享

在配置k8s時(shí)，一般會(huì)把數(shù)據(jù)庫設(shè)置成一個(gè)服務(wù)。如果能在宿主機(jī)上訪問k8s數(shù)據(jù)庫，就能提前測試數(shù)據(jù)庫，盡早發(fā)現(xiàn)數(shù)據(jù)庫的問題。一旦把虛機(jī)和宿主機(jī)之間的網(wǎng)絡(luò)聯(lián)通了，是可以從宿主機(jī)直接訪問數(shù)據(jù)庫。

開發(fā)流程

開發(fā)流程通常是這樣的。你先在本地的IDE上編寫代碼（包括應(yīng)用程序和k8s代碼），代碼是存儲在本地硬盤上的。完成之后，你進(jìn)入虛機(jī)環(huán)境，部署k8s集群和應(yīng)用程序代碼，再在k8s集群上運(yùn)行代碼，測試結(jié)果。如此反復(fù)循環(huán)。

流程示例

我們通過一個(gè)例子來講解流程。在本地編寫完代碼之后，就要調(diào)試k8s程序。先用Vagrant啟動(dòng)虛機(jī)，然后啟動(dòng)Minikube：

sudominikube start

程序結(jié)構(gòu)

上面是程序的目錄結(jié)構(gòu)。“cmd”目錄里是主程序，“config”目錄是負(fù)責(zé)程序配置的，“dataservice”是數(shù)據(jù)訪問層，“model”是域模型層，“l(fā)ogs”目錄是存儲日志的。“”包含了所有與程序部署相關(guān)的文件。其中“database”里面是數(shù)據(jù)庫腳本，“kubernetes”是k8s的所有配置文件，一會(huì) 兒還會(huì)詳細(xì)講解。

上面就是k8s的配置文件目錄結(jié)構(gòu)，最外面有兩個(gè)文件“k8sdemo-config.yaml”和"k8sdemo-secret.yaml"是共享文件，因此放在最外層。里面主要有兩個(gè)子目錄“backend”和“database”分別存后端程序和數(shù)據(jù)庫的配置文件。內(nèi)部的結(jié)構(gòu)是類似的，都有三個(gè)“yaml”文件，“backend-deployment.yaml”是部署配置文件, "backend-service.yaml"是服務(wù)配置文件, "backend-volume.yaml"是持久卷配置文件. ".sh"是k8s命令，用來創(chuàng)建k8s對象。“backend”目錄還多了一個(gè)“docker”子目錄用來存儲backend應(yīng)用的Docker鏡像，database的鏡像文件是直接從Docker的庫中取得，因此不需要另外生成鏡像文件。

部署和調(diào)試應(yīng)用程序及k8s

我們的程序有兩個(gè)服務(wù)“k8sdemo-database-service”和“k8sdemo-backend-service”，先要部署“k8sdemo-database-service”，因?yàn)樗灰蕾囉谄渌?wù)。不過還有些對象是共享的需要先進(jìn)行調(diào)試。有一點(diǎn)需要注意的是由于k8s對象之間是有依賴關(guān)系的，在你創(chuàng)建時(shí)是需要按照順序來創(chuàng)建。順序的部署次序是這樣的Secret->ConfigMap->Volume->Deployment->Service。

部署共享對象：

cd/home/vagrant/jfeng45/k8sdemo//kubernetes

kubectl apply -f k8sdemo-config.yaml

kubectl apply -f k8sdemo-secret.yaml

檢查創(chuàng)建情況：

kubectl describeconfigMap

kubectl describesecret

部署數(shù)據(jù)庫服務(wù)：

cd/home/vagrant/jfeng45/k8sdemo//kubernetes/database

kubectl apply -f database-volume.yaml

kubectl apply -f database-deployment.yaml

kubectl apply -f database-service.yaml

數(shù)據(jù)庫創(chuàng)建好了之后，可以在IDE中用程序直接訪問虛擬機(jī)上的庫，這樣比較方便。但你需要設(shè)置環(huán)境變量。在k8s中是由configMap設(shè)置的，在Windows里需要單獨(dú)設(shè)置，命令在“windowsEnv.bat”里面。內(nèi)容如下：

setxMYSQL_ROOT_PASSWORDroot

setxMYSQL_USER_NAMEdbuser

setxMYSQL_USER_PASSWORDdbuser

setxMYSQL_DATAbaseservice_config

setxMYSQL_HOST192 .168.50.4

setxMYSQL_PORT30306

創(chuàng)建應(yīng)用程序鏡像：

cd/home/vagrant/jfeng45/k8sdemo/

docker build -f .//kubernetes/backend/docker/Dockerfile-k8sdemo-backend -t k8sdemo-backend .

部署后端服務(wù)

cd/home/vagrant/jfeng45/k8sdemo//kubernetes/backend

kubectl apply -f backend-volume.yaml

kubectl apply -f backend-deployment.yaml

kubectl apply -f backend-service.yaml

登錄容器，并運(yùn)行程序，查看結(jié)果：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo//kubernetes/backend$ kubectl exec -ti k8sdemo-backend-deployment-57bcd56f7d-26p5k -- /bin/sh

~ # ./main.exe

time= "2019-12-10T06:23:45Z"level=debug msg= "connect to database "

time= "2019-12-10T06:23:45Z"level=debug msg= "dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8"

time= "2019-12-10T06:23:45Z"level=debug msg= "FindAll"

time= "2019-12-10T06:23:45Z"level=debug msg= "created=2019-10-21"

time= "2019-12-10T06:23:45Z"level=debug msg= "find user:{1 Tony IT 2019-10-21}"

time= "2019-12-10T06:23:45Z"level=debug msg= "find user list:[{1 Tony IT 2019-10-21}]"

time= "2019-12-10T06:23:45Z"level=debug msg= "user lst:[{1 Tony IT 2019-10-21}]"

上面步驟中的k8s部分并不是每次修改應(yīng)用程序之后都要運(yùn)行，通常只需要運(yùn)行有改動(dòng)的部分。一般來講只是部署（Deployment）會(huì)有改動(dòng)，因?yàn)槌绦虻腄ocker鏡像變了。即使這樣要完成一次調(diào)試也有不少步驟。

綜述：

從上面的流程可以看出，在本地云環(huán)境上進(jìn)行開發(fā)和調(diào)試還是比較繁瑣的，你需要在宿主機(jī)和虛擬機(jī)之間進(jìn)行切換，還要同時(shí)對應(yīng)用程序和k8s進(jìn)行調(diào)試，中間有很多手工操作，要敲入很多命令，怎樣才能簡化它呢？

Helm

k8s的一個(gè)痛點(diǎn)就是它有很多組成部分（部署，服務(wù)，存儲卷等），每個(gè)部分都要分別敲入命令進(jìn)行調(diào)試，特別是當(dāng)出現(xiàn)問題時(shí)，你需要反復(fù)刪除原來的并創(chuàng)建新的。Helm解決了它的這個(gè)痛點(diǎn)。Helm是最流行的k8s包管理工具，就像Java中的Maven和Go里面的“Go Module”。它的一個(gè)核心概念是“Chart”。有了它之后，你可以把k8s的各個(gè)部分作為一個(gè)整體來管理，這樣就大大減少了工作量。在調(diào)試初期，你還是可以對各部分進(jìn)行單獨(dú)調(diào)試，這樣減少復(fù)雜度。但一旦成功之后，你就可以把它當(dāng)成一個(gè)整體來操作，這樣大大簡化了操作。Helm的另一個(gè)作用就是對K8s配置的版本進(jìn)行管理。

Helm文件結(jié)構(gòu)

chart里一個(gè)很重要的概念就是模板（template）,也就是Go語言模板。模板就是里面加入了編程邏輯的k8s文件。這些模板文件在使用時(shí)都要先進(jìn)行模板解析，把其中的程序邏輯轉(zhuǎn)化成對應(yīng)的編碼，最終生成k8s配置文件。

以上就是Helm自動(dòng)生成的chart目錄結(jié)構(gòu)，在Helm里每個(gè)項(xiàng)目叫一個(gè)chart，它由下面幾個(gè)組成部分：

• "Chart.yaml"： 存有這個(gè)chart的基本信息，
• "values.yaml"： 定義模板中要用到的常量。
• “template”目錄： 里面存有全部的模板文件，其中最重要的是“deployment.yaml”和“service.yaml”，分別是部署和服務(wù)文件. "helpers.tpl"用來定義變量，"ingress.yaml"和"serviceaccount.yaml"分別是對外接口和服務(wù)賬戶，這里暫時(shí)沒用， “NOTES.txt”是注釋文件。
• “charts”目錄: 存有這個(gè)chart依賴的所有子chart。

Chart設(shè)計(jì)

現(xiàn)在我們就用一個(gè)例子來展示Helm的chart設(shè)計(jì)。這個(gè)例子是一個(gè)微服務(wù)應(yīng)用程序，它共有三層: 前端，后端和數(shù)據(jù)庫。

在k8s中，每一層就是一個(gè)單獨(dú)的服務(wù)，它里面有各種配置文件。Helm的優(yōu)勢是把這些不同的服務(wù)組成一個(gè)Chart來共同管理和調(diào)試，方便了許多。鍵入如下命令創(chuàng)建chart，其中“k8sdemo”是chart的名字，這個(gè)名字很重要，服務(wù)的名字和label都是由它產(chǎn)生的。

helmcreate k8sdemo

這之后，系統(tǒng)會(huì)自動(dòng)創(chuàng)建前面講到的chart目錄結(jié)構(gòu)。然后就是對已經(jīng)生成的文件進(jìn)行修改。

上面就是最終的chart目錄結(jié)構(gòu)圖。“chart”是總目錄，里面有三個(gè)子目錄“k8sdemo”，“k8sdemo-backend”，“k8sdemo-database”, 每一個(gè)對應(yīng)一個(gè)服務(wù)，每個(gè)服務(wù)都是一個(gè)獨(dú)立的chart，能單獨(dú)調(diào)試部署，chart之間也可以有依賴關(guān)系。其中“k8sdemo”是父chart，同時(shí)也是前端服務(wù)，它的“charts”目錄里有它依賴的另外兩個(gè)服務(wù)。“k8sdemo-backend”是后端服務(wù)，“k8sdemo-database”是數(shù)據(jù)庫服務(wù)。

安裝k8sdemo：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo//kubernetes/chart$ helm upgrade k8sdemo ./k8sdemo

Release"k8sdemo"has been upgraded. Happy Helming!

NAME: k8sdemo

LASTDEPLOYED: Fri Nov 2901: 28: 552019

NAMESPACE: default

STATUS: deployed

REVISION: 2

NOTES:

1.Getthe application URLbyrunning these commands:

exportNODE_PORT=$(kubectl get--namespace default -o jsonpath="{.spec.ports[0].nodePort}" services k8sdemo)

exportNODE_IP=$(kubectl getnodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")

echo $NODE_IP:$NODE_PORT

獲取Pod名稱：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo//kubernetes/chart$ kubectl get pod

NAME READY STATUS RESTARTS AGE

k8sdemo -74cb7b997c-pgcj4 1/ 1Running 033s

k8sdemo-backend -5cd9d79856-dqlmz 1/ 1Running 033s

k8sdemo-database -85855485c6-jtksb 1/ 1Running 033s

k8sdemo-jenkins-deployment -675dd574cb-r57sb 1/ 1Running 323d

運(yùn)行程序進(jìn)行測試：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo//kubernetes/chart$ kubectl exec -ti k8sdemo-backend-5cd9d79856-dqlmz -- /bin/sh

~ # ./main.exe

time= "2019-11-27T07:03:03Z"level=debug msg= "connect to database "

time= "2019-11-27T07:03:03Z"level=debug msg= "dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8"

time= "2019-11-27T07:03:03Z"level=debug msg= "FindAll"

time= "2019-11-27T07:03:03Z"level=debug msg= "created=2019-10-21"

time= "2019-11-27T07:03:03Z"level=debug msg= "find user:{1 Tony IT 2019-10-21}"

time= "2019-11-27T07:03:03Z"level=debug msg= "find user list:[{1 Tony IT 2019-10-21}]"

time= "2019-11-27T07:03:03Z"level=debug msg= "user lst:[{1 Tony IT 2019-10-21}]"

~ #

由上面可以看出，使用了Helm之后，大大簡化了k8s的部署和調(diào)試過程。只需一步就能完成所有k8s對象的部署。

自動(dòng)調(diào)試工具

Helm解決了k8s的部署問題，但你修改程序之后，還是要更新Docker鏡像，才能部署，部署之后還要測試，比對結(jié)果，這里面還是有很多手工操作，有沒有工具能自動(dòng)完成這些工作？確實(shí)有這樣的工具，而且還有不少，它們的功能也不盡相同。這里面有一類工具是相對來說比較有用的，那就是自動(dòng)化整個(gè)部署、調(diào)試流程的。它們的功能和流程一般是這樣的。

它會(huì)自動(dòng)檢測程序修改，一旦發(fā)現(xiàn)就自動(dòng)生成Docker鏡像，然后調(diào)用k8s部署文件把新的鏡像文件部署到k8s集群上，再調(diào)用測試程序進(jìn)行測試，并在控制臺顯示結(jié)果。整個(gè)過程不需要你敲入一行命令，全部自動(dòng)執(zhí)行。這樣完全消除了手工操作，使整個(gè)流程自動(dòng)執(zhí)行。你可能會(huì)說你并不想每修改一行程序就進(jìn)行一下測試，而是當(dāng)你需要的時(shí)候再去測試。這個(gè)功能在某些工具里也是可以配置的，你可以配置一個(gè)觸發(fā)器，只有當(dāng)它觸發(fā)之后才自動(dòng)完成上述操作。

Skaffold配置文件：

我們現(xiàn)在就用一個(gè)例子來具體說明，使用的工具是Skaffold。Skaffold的主要部分是一個(gè)配置文件，叫“skaffold.yaml”, 存放在項(xiàng)目的根目錄。里面有Skaffold需要的信息，如Docker鏡像的文件名，k8s的部署文件等。

apiVersion: skaffold/v1

kind: Config

metadata:

name: k-sdemo

build:

artifacts:

- image: k8sdemo-backend

context: .

docker:

dockerfile: /kubernetes/backend/docker/Dockerfile-k8sdemo-backend

deploy:

kubectl:

manifests:

- /kubernetes/backend/backend-deployment.yaml

- /kubernetes/backend/backend-service.yaml

上面就是這個(gè)文件，它看起來很像k8s的配置文件，它的類型是“Config”。里面有兩個(gè)主要部分，一個(gè)是：“build”，負(fù)責(zé)生成項(xiàng)目的Docker鏡像的，另一個(gè)是“deploy”，負(fù)責(zé)把生成的鏡像部署到k8s上。

Skaffold可以幫你自動(dòng)生成基礎(chǔ)配置文件。你可以敲入“skaffold init”，它會(huì)問你一些問題，并根據(jù)你的回答，自動(dòng)生成“skaffold.yaml”文件。生成之后，你可以根據(jù)需要進(jìn)行修改。這里面比較重要的就是引用了鏡像文件和k8s部署文件。如果你以前已經(jīng)創(chuàng)建了這些文件，那么你可以復(fù)用它們。

運(yùn)行Skaffold：

生成“skaffold.yaml”文件之后，鍵入如下命令“skaffold dev”，系統(tǒng)會(huì)運(yùn)行“skaffold.yaml”，部署k8s，并開始監(jiān)控程序的修改。輸出如下：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo$ skaffold dev

WARN[ 0000] Could notgetminikube docker env, falling back tolocal docker daemon: getting minikube env: Running [minikube docker-env --shell none]: stdout , stderr: *

Listing files towatch...

- k8sdemo-backend

Generating tags...

- k8sdemo-backend -> k8sdemo-backend: 05894ca-dirty

Checking cache...

- k8sdemo-backend: Notfound. Building

Found [minikube] context, usinglocal docker daemon.

Building [k8sdemo-backend]...

Sending build context toDocker daemon 534.5kB

Step1/ 13: FROMgolang:latest asbuilder

---> dc7582e06f8e

Step2/ 13: WORKDIR /app

---> Usingcache

---> d5d126eaa528

Step3/ 13: COPY go. modgo.sum ./

---> Usingcache

---> 6ed430911953

Step4/ 13: RUN go moddownload

---> Usingcache

---> bfb89c8b352b

Step5/ 13: COPY . .

---> 6c1f89974762

Step6/ 13: WORKDIR /app/cmd

---> Running ind36e8a412aae

---> 9f7f92349811

Step7/ 13: RUN go build -o main.exe

---> Running in31ff6408dfda

---> 31d84d0c860a

Step8/ 13: FROMalpine:latest

---> 965ea09ff2eb

Step9/ 13: RUN apk --no-cache add ca-certificates

---> Usingcache

---> a27265887a1e

Step10/ 13: WORKDIR /root/

---> Usingcache

---> b9c048c97f07

Step11/ 13: RUN mkdir /lib64 && ln -s / lib/libc.musl-x86_64.so .1/lib64/ld-linux-x86 -64.so .2

---> Usingcache

---> 95a2b77e3e0a

Step12/ 13: COPY -- from=builder /app/cmd/main.exe .

---> Usingcache

---> 5ef8db6e073a

Step13/ 13: CMD exec /bin/sh -c "trap : TERM INT; (while true; do sleep 1000; done) & wait"

---> Usingcache

---> 6f3e1f751ac6

Successfully built 6f3e1f751ac6

Successfully tagged k8sdemo-backend: 05894ca-dirty

Tags used indeployment:

- k8sdemo-backend -> k8sdemo-backend: 6f3e1f751ac6ad3c39092a9308f9a6e1d5e087da275349aa3719344785b26f1a

local images can 't be referenced by digest. They are tagged and referenced by a unique ID instead

Starting deploy...

- deployment.apps/k8sdemo-backend-deployment created

- service/k8sdemo-backend-service created

Watching forchanges...

你如果有測試程序，就可以在控制臺輸出結(jié)果。我沒有測試程序，就要登錄到Pod上運(yùn)行程序，查看結(jié)果。

獲得Pod名

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo//kubernetes/backend$ kubectl get pod

NAME READY STATUS RESTARTS AGE

k8sdemo -74cb7b997c -8hpdq 1/ 1Running 111d

k8sdemo-backend -5cd9d79856-nwlcl 1/ 1Running 111d

k8sdemo-backend-deployment -57bcd56f7d -26p5k 1/ 1Running 014s

k8sdemo-database -85855485c6-vnsp4 1/ 1Running 111d

k8sdemo-jenkins-deployment -675dd574cb-r57sb 1/ 1Running 536d

登錄Pod，并運(yùn)行程序

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo//kubernetes/backend$ kubectl exec -ti k8sdemo-backend-deployment-57bcd56f7d-26p5k -- /bin/sh

~ # ./main.exe

time= "2019-12-10T06:23:45Z"level=debug msg= "connect to database "

time= "2019-12-10T06:23:45Z"level=debug msg= "dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8"

time= "2019-12-10T06:23:45Z"level=debug msg= "FindAll"

time= "2019-12-10T06:23:45Z"level=debug msg= "created=2019-10-21"

time= "2019-12-10T06:23:45Z"level=debug msg= "find user:{1 Tony IT 2019-10-21}"

time= "2019-12-10T06:23:45Z"level=debug msg= "find user list:[{1 Tony IT 2019-10-21}]"

time= "2019-12-10T06:23:45Z"level=debug msg= "user lst skaffold:[{1 Tony IT 2019-10-21}]"

有關(guān)Skaffold的詳情，請參見Working With Skaffold（https://skaffold.dev/docs/workflows/）

自動(dòng)調(diào)試工具比較：

有四個(gè)比較流行的 自動(dòng)調(diào)試工具，它們是“Draft”，“Skaffold”，“Garden”，“Tilt”。

Garden：我最先測試的是“Garden”，因?yàn)樗δ軓?qiáng)大。但測試之后發(fā)現(xiàn)它很不靈活，對項(xiàng)目的目錄結(jié)構(gòu)有特殊要求。例如，你的項(xiàng)目有三個(gè)微服務(wù)，那么它會(huì)建一個(gè)總項(xiàng)目，三個(gè)微服務(wù)每個(gè)是一個(gè)子項(xiàng)目，每個(gè)子項(xiàng)目里需要一個(gè)“Garden”的微服務(wù)配置文件，總項(xiàng)目也要一個(gè)配置文件，而且文件的名字和位置是固定的。這導(dǎo)致它配置起來很繁瑣，而且與一般的程序結(jié)構(gòu)有沖突。“Garden”的設(shè)計(jì)思想是好的，它想使用一個(gè)工具來統(tǒng)一開發(fā)和部署。但由于開發(fā)和部署差別還是很大的，統(tǒng)一的結(jié)果就是不倫不類。它給出的例子也都是很簡單的實(shí)例，我覺得一旦應(yīng)用到比較復(fù)雜的項(xiàng)目就會(huì)很不方便。

Garden的詳情，請參見Introduction：https://docs.garden.io/

Tilt：“Tilt”是我第二個(gè)測試的，它看起來非常靈活，功能也很強(qiáng)大。但運(yùn)行之后，它在連接Minikube時(shí)出了問題，連接不上。官方安裝文檔給出的默認(rèn)的k8s集群是Microk8s。它的文檔里也說了支持Minikube，但并沒有解釋需要做哪些設(shè)置，看起來像是不需要設(shè)置就可以直接連通，不知道為什么我的Minikube會(huì)有問題。當(dāng)然，也有可能是因?yàn)槲覇?dòng)時(shí)用的是“minikube start --vm-driver=none”，導(dǎo)致了連接的問題。我想如果花些時(shí)間仔細(xì)研究，問題應(yīng)該可以解決，但連接Minikube是整個(gè)過程的第一步，一上來就出問題實(shí)在讓我有些信心不足，就決定先放一放。

Tilt的詳情，請參見Tutorial: The First 15 Minutes：https://docs.tilt.dev/tutorial.html

Skaffold：這是我測試的第三個(gè)工具。它功能很強(qiáng)大，也很靈活，雖然也碰到一些問題，但很快就解決了。因此我對Skaffold是很滿意的。Skaffold給出的官方安裝文檔的下載地址是“https://storage.googleapis/skaffold/releases/latest/skaffold-linux-amd64”。這個(gè)沒法訪問。你可以在GitHub的release里面下載可執(zhí)行文件，然后拷貝到“/usr/local/bin/skaffold”目錄就可以了。

Draft：我沒有測試Draft。Draft現(xiàn)在已經(jīng)不再維護(hù)了，它的開發(fā)者有別的任務(wù)，停止了繼續(xù)開發(fā)。Draft應(yīng)該比較容易使用，但功能不夠強(qiáng)大。

總體評論：總的來說我對Skaffold很滿意，它確實(shí)大大簡化了調(diào)試流程。但我覺得這類工具并不像我想像的那么完美。因?yàn)槊看涡薷某绦蛑蠖家匦律社R像，這個(gè)過程很慢。當(dāng)然你可以有很多手段來優(yōu)化他，例如建一個(gè)本地鏡像庫。另外這類工具本身也有優(yōu)化措施，例如對下載庫的優(yōu)化。但總的來說跟本地環(huán)境還是沒法比。

關(guān)于這些工具的比較詳情，請參見The ultimate guide for local development on Kubernetes: Draft vs Skaffold vs Garden.io（https://codefresh.io/howtos/local-k8s-draft-skaffold-garden/）和Local Kubernetes development with Tilt.dev（https://codefresh.io/kubernetes-tutorial/local-kubernetes-development-tilt-dev/）。

開發(fā)模式

在云原生開發(fā)模式下，你可以把項(xiàng)目的運(yùn)行環(huán)境分成兩部分。一部分是項(xiàng)目需要調(diào)用的服務(wù)和資源，這些都是部署在云環(huán)境上的（也就是k8s集群）。你可以用Helm創(chuàng)建一個(gè)chart，里面包含所有本項(xiàng)目需要調(diào)用的k8s服務(wù)（包括數(shù)據(jù)庫服務(wù)），然后把這個(gè)chart部署到k8s集群上，這部分的程序變化頻率較低。一旦這些服務(wù)中的某些代碼變了，你只要重新部署chart就行了。另一部分是項(xiàng)目本身的代碼和運(yùn)行環(huán)境，這部分程序變化頻率較高。這一部分既可以在k8s上運(yùn)行，也可以在本地環(huán)境運(yùn)行。它的不同決定了開發(fā)模式的不同。

純云原生開發(fā)模式：

在這種模式下，除了IDE和代碼是在本地，其他的所有東西都是在云環(huán)境。當(dāng)項(xiàng)目代碼修改之后，需要?jiǎng)?chuàng)建新的Docker鏡像文件，然后把鏡像部署到k8s集群上，在k8s集群上進(jìn)行調(diào)試。你可以用前面講到的自動(dòng)調(diào)試工具來完成這一任務(wù)。它的好處是開發(fā)環(huán)境和生產(chǎn)環(huán)境完全兼容，這樣保證了在生產(chǎn)環(huán)境部署時(shí)沒有意外。缺點(diǎn)是調(diào)試效率稍低。你如果想把IDE和代碼都放在云上，也是可以的，本地只要有一個(gè)客戶端來訪問它們就行了。這時(shí)就是純正的云開發(fā)環(huán)境，但它的象征意義更大，對實(shí)際工作沒有太大影響。

混合開發(fā)模式：

在這種模式下，項(xiàng)目是在本地調(diào)試的，而它依賴的其它微服務(wù)是部署在云環(huán)境上（虛擬機(jī)上的k8s上）的。由于本地環(huán)境和虛機(jī)的網(wǎng)絡(luò)是聯(lián)通的，本地環(huán)境上運(yùn)行的代碼可以訪問虛機(jī)上的微服務(wù)。數(shù)據(jù)庫也是一樣，也是部署在k8s集群上，你可以把它看成一個(gè)服務(wù)，并通過本地客戶端訪問數(shù)據(jù)庫上的數(shù)據(jù)，這時(shí)數(shù)據(jù)庫的物理位置對你是透明的，不管是在云上還是在本地都沒有區(qū)別。當(dāng)項(xiàng)目的代碼修改之后，你在本地運(yùn)行項(xiàng)目并調(diào)試。如果你需要web服務(wù)器，對有些語言不成問題，例如Go，它的web服務(wù)器就是用本地代碼生成的，是程序的一部分。如果你用的是Java，需要單獨(dú)的服務(wù)器，那么你還需要一個(gè)本地服務(wù)器來部署修改之后的代碼。

這種方式的最大好處就是調(diào)試效率很高。因?yàn)楸卷?xiàng)目的代碼修改頻率是最高的，用這種方式能最大限度地提高它的調(diào)試速度。雖然犧牲了一點(diǎn)開發(fā)環(huán)境和生產(chǎn)環(huán)境的兼容性，但這也是可以彌補(bǔ)的。例如，你可以每隔一段時(shí)間把本地項(xiàng)目部署到k8s集群上（使用上面提到的調(diào)試工具）和其他依賴的服務(wù)一起進(jìn)行整個(gè)聯(lián)調(diào)，這時(shí)的運(yùn)行環(huán)境就和生產(chǎn)環(huán)境一致了。具體的部署頻率根據(jù)個(gè)人和項(xiàng)目來定，可以是每天，也可以是3天或更多。這樣既能保證平時(shí)調(diào)試的速度和效率，又能保證本地開發(fā)環(huán)境和生產(chǎn)環(huán)境的一致性。這種模式在我看來更有優(yōu)勢。

工具總結(jié)

本文詳細(xì)講解了云原生開發(fā)環(huán)境以及需要的工具，它包括下面四類：

• IDE： 必不可少，需支持k8s.
• k8s： 是云原生的基石，沒有它就沒有云原生.
• Helm： 不論什么開發(fā)模式，它都是一個(gè)不可或缺的工具.
• 自動(dòng)調(diào)試工具： 在純云原生開發(fā)模式下是必不可少的，在混合開發(fā)模式下也是需要的，但沒有純云原生開發(fā)模式下那么重要。

源碼庫

完整源碼的GitHub鏈接：k8sdemo（https://github/jfeng45/k8sdemo）

不堆砌術(shù)語，不羅列架構(gòu)，不迷信權(quán)威，不盲從流行，堅(jiān)持獨(dú)立思考。

聲明：本文為CSDN博主「倚天碼農(nóng)」的投稿。

想為博主點(diǎn)贊？

想要請教博主？

快速 獲取與博主直面溝通的方式吧！