雲原生開發環境初探

在上一篇“雲原生的不同解釋及正確含義”里，我們講到了雲原生的引申含義，就是開發環境也是雲環境，這樣就能保證開發環境和生產環境的一致性，使最終的部署順利進行。本文就通過具體的例子來探討雲原生的開發環境。
開發流程主要包括編寫代碼，程序部署和調試幾個環節。每一個環節都需要相應的工具來幫助你提高效率。下面我們就來看一下如何搭建開發的雲環境以及那些工具能幫你在雲環境里提高開發效率。

開發IDE

以前的IDE只支持應用程序的開發，但雲原生需要同時進行開發環境（容器）的開發，理想的情況是一個IDE能同時支持兩者。我用的是Go語言，選擇的IDE是Goland（也就是IDEA IntelliJ），它本身是支持k8s的，你只要下載一個插件就行。它支持k8s的自動完成（Auto-complete）等功能。如下圖所示，這樣你就擁有了同時支持應用程序和k8s的IDE。

但我不得不說它對k8s的支持很初級，它不能理解k8s對象之間的內在聯系。另外，k8s配置文件對格式要求很嚴，如果空格不對，或格式沒有對齊，在部署時會報錯。Goland有檢查格式的功能，出了問題會報錯，但並不是每個錯誤它都能發現。也就是說當它沒有報錯時也不能肯定格式就是對的。這已經發生好幾次了，IDE沒有報錯，但部署時有問題。

關於IntelliJ對k8s的支持功能，請參見IntelliJ IDEA 2018.1: Kubernetes support

環境搭建

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

程序共享

我的Go應用程序是在Windows上的“C:\code\src\github.com\jfeng45\k8sdemo”目錄下，通過Vagrant可以把宿主機的目錄掛載到虛機上，這樣每次在IDE上修改了k8s的配置文件，在虛機上可以直接取到，不需要另外同步。

在Vagrant中的配置是這樣的：

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

網絡共享

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

Vagrant的配置命令：

“config.vm.network “private_network”, ip: "192.168.50.4”

數據庫共享

在配置k8s時，一般會把數據庫設置成一個服務。如果能在宿主機上訪問k8s數據庫，就能提前測試數據庫，盡早發現數據庫的問題。一旦把虛機和宿主機之間的網絡聯通了，是可以從宿主機直接訪問數據庫。

有關環境配置的詳情，詳情請參閱“通過搭建MySQL掌握k8s（Kubernetes）重要概念（上）：網絡與持久卷”.

開發流程

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

流程示例

我們通過一個例子來講解流程。在本地編寫完代碼之后，就要調試k8s程序。先用Vagrant啟動虛機，然后啟動Minikube：

sudo minikube start

程序結構

上面是程序的目錄結構。“cmd”目錄里是主程序，“config”目錄是負責程序配置的，“dataservice”是數據訪問層，“model”是域模型層，“logs”目錄是存儲日志的。“script”包含了所有與程序部署相關的文件。其中“database”里面是數據庫腳本，“kubernetes”是k8s的所有配置文件，一回兒還會詳細講解。

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

關於k8s的核心概念，請參閱“通過實例快速掌握k8s（Kubernetes）核心概念”.

部署和調試應用程序及k8s

我們的程序有兩個服務“k8sdemo-database-service”和“k8sdemo-backend-service”，先要部署“k8sdemo-database-service”，因為它不依賴於其它服務。不過還有些對象是共享的需要先進行調試。有一點需要注意的是由於k8s對象之間是有依賴關系的，在你創建時是需要按照順序來創建。順序的部署次序是這樣的Secret->ConfigMap->Volume->Deployment->Service。

部署共享對象：

cd /home/vagrant/jfeng45/k8sdemo/script/kubernetes
kubectl apply -f k8sdemo-config.yaml
kubectl apply -f k8sdemo-secret.yaml

檢查創建情況：

kubectl describe configMap
kubectl describe secret

部署數據庫服務：

cd /home/vagrant/jfeng45/k8sdemo/script/kubernetes/database
kubectl apply -f database-volume.yaml
kubectl apply -f database-deployment.yaml
kubectl apply -f database-service.yaml

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

setx MYSQL_ROOT_PASSWORD root
setx MYSQL_USER_NAME dbuser
setx MYSQL_USER_PASSWORD dbuser
setx MYSQL_DATABASE service_config
setx MYSQL_HOST 192.168.50.4
setx MYSQL_PORT 30306

創建應用程序鏡像：

cd /home/vagrant/jfeng45/k8sdemo/
docker build -f ./script/kubernetes/backend/docker/Dockerfile-k8sdemo-backend -t k8sdemo-backend .

部署后端服務

cd /home/vagrant/jfeng45/k8sdemo/script/kubernetes/backend
kubectl apply -f backend-volume.yaml
kubectl apply -f backend-deployment.yaml
kubectl apply -f backend-service.yaml

登錄容器，並運行程序，查看結果：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/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部分並不是每次修改應用程序之后都要運行，通常只需要運行有改動的部分。一般來講只是部署（Deployment）會有改動，因為程序的Docker鏡像變了。即使這樣要完成一次調試也有不少步驟。

有關k8s的核心概念，詳情請參閱“通過實例快速掌握k8s（Kubernetes）核心概念”.

綜述：

從上面的流程可以看出，在本地雲環境上進行開發和調試還是比較繁瑣的，你需要在宿主機和虛擬機之間進行切換，還要同時對應用程序和k8s進行調試，中間有很多手工操作，要敲入很多命令，怎樣才能簡化它呢？

Helm

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

Helm文件結構

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

以上就是Helm自動生成的chart目錄結構，在Helm里每個項目叫一個chart，它由下面幾個組成部分：

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

Chart設計

現在我們就用一個例子來展示Helm的chart設計。這個例子是一個微服務應用程序，它共有三層: 前端，后端和數據庫。

在k8s中，每一層就是一個單獨的服務，它里面有各種配置文件。Helm的優勢是把這些不同的服務組成一個Chart來共同管理和調式，方便了許多。
鍵入如下命令創建chart，其中“k8sdemo”是chart的名字，這個名字很重要，服務的名字和label都是由它產生的。

helm create k8sdemo

這之后，系統會自動創建前面講到的chart目錄結構。然后就是對已經生成的文件進行修改。

上面就是最終的chart目錄結構圖。“chart”是總目錄，里面有三個子目錄“k8sdemo”，“k8sdemo-backend”，“k8sdemo-database”, 每一個對應一個服務，每個服務都是一個獨立的chart，能單獨調式部署，chart之間也可以有依賴關系。其中“k8sdemo”是父chart，同時也是前端服務，它的“charts”目錄里有它依賴的另外兩個服務。“k8sdemo-backend”是后端服務，“k8sdemo-database”是數據庫服務。

安裝k8sdemo：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/chart$ helm upgrade k8sdemo ./k8sdemo
Release "k8sdemo" has been upgraded. Happy Helming!
NAME: k8sdemo
LAST DEPLOYED: Fri Nov 29 01:28:55 2019
NAMESPACE: default
STATUS: deployed
REVISION: 2
NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services k8sdemo)
  export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

獲取Pod名稱：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/chart$ kubectl get pod
NAME                                          READY   STATUS    RESTARTS   AGE
k8sdemo-74cb7b997c-pgcj4                      1/1     Running   0          33s
k8sdemo-backend-5cd9d79856-dqlmz              1/1     Running   0          33s
k8sdemo-database-85855485c6-jtksb             1/1     Running   0          33s
k8sdemo-jenkins-deployment-675dd574cb-r57sb   1/1     Running   3          23d

運行程序進行測試：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/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的部署和調試過程。只需一步就能完成所有k8s對象的部署。

詳情請參見用Helm3構建多層微服務

自動調試工具

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

它會自動檢測程序修改，一旦發現就自動生成Docker鏡像，然后調用k8s部署文件把新的鏡像文件部署到k8s集群上，再調用測試程序進行測試，並在控制台顯示結果。整個過程不需要你敲入一行命令，全部自動執行。這樣完全消除了手工操作，使整個流程自動執行。你可能會說你並不想每修改一行程序就進行一下測試，而是當你需要的時候再去測試。這個功能在某些工具里也是可以配置的，你可以配置一個觸發器，只有當它觸發之后才自動完成上述操作。

Skaffold配置文件：

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

apiVersion: skaffold/v1
kind: Config
metadata:
  name: k-sdemo
build:
  artifacts:
  - image: k8sdemo-backend
    context: .
    docker:
      dockerfile: script/kubernetes/backend/docker/Dockerfile-k8sdemo-backend
deploy:
  kubectl:
    manifests:
    - script/kubernetes/backend/backend-deployment.yaml
    - script/kubernetes/backend/backend-service.yaml

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

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

運行Skaffold：

生成“skaffold.yaml”文件之后，鍵入如下命令“skaffold dev”，系統會運行“skaffold.yaml”，部署k8s，並開始監控程序的修改。輸出如下：

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo$ skaffold dev
WARN[0000] Could not get minikube docker env, falling back to local docker daemon: getting minikube env: Running [minikube docker-env --shell none]: stdout , stderr: *
Listing files to watch...
- k8sdemo-backend
Generating tags...
- k8sdemo-backend -> k8sdemo-backend:05894ca-dirty
Checking cache...
- k8sdemo-backend: Not found. Building
Found [minikube] context, using local docker daemon.
Building [k8sdemo-backend]...
Sending build context to Docker daemon  534.5kB
Step 1/13 : FROM golang:latest as builder
---> dc7582e06f8e
Step 2/13 : WORKDIR /app
---> Using cache
---> d5d126eaa528
Step 3/13 : COPY go.mod go.sum ./
---> Using cache
---> 6ed430911953
Step 4/13 : RUN go mod download
---> Using cache
---> bfb89c8b352b
Step 5/13 : COPY . .
---> 6c1f89974762
Step 6/13 : WORKDIR /app/cmd
---> Running in d36e8a412aae
---> 9f7f92349811
Step 7/13 : RUN go build -o main.exe
---> Running in 31ff6408dfda
---> 31d84d0c860a
Step 8/13 : FROM alpine:latest
---> 965ea09ff2eb
Step 9/13 : RUN apk --no-cache add ca-certificates
---> Using cache
---> a27265887a1e
Step 10/13 : WORKDIR /root/
---> Using cache
---> b9c048c97f07
Step 11/13 : RUN mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2
---> Using cache
---> 95a2b77e3e0a
Step 12/13 : COPY --from=builder /app/cmd/main.exe .
---> Using cache
---> 5ef8db6e073a
Step 13/13 : CMD exec /bin/sh -c "trap : TERM INT; (while true; do sleep 1000; done) & wait"
---> Using cache
---> 6f3e1f751ac6
Successfully built 6f3e1f751ac6
Successfully tagged k8sdemo-backend:05894ca-dirty
Tags used in deployment:
- 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 for changes...

你如果有測試程序，就可以在控制台輸出結果。我沒有測試程序，就要登錄到Pod上運行程序，查看結果。

獲得Pod名

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/backend$ kubectl get pod
NAME                                          READY   STATUS    RESTARTS   AGE
k8sdemo-74cb7b997c-8hpdq                      1/1     Running   1          11d
k8sdemo-backend-5cd9d79856-nwlcl              1/1     Running   1          11d
k8sdemo-backend-deployment-57bcd56f7d-26p5k   1/1     Running   0          14s
k8sdemo-database-85855485c6-vnsp4             1/1     Running   1          11d
k8sdemo-jenkins-deployment-675dd574cb-r57sb   1/1     Running   5          36d

登錄Pod，並運行程序

vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/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}]"

有關Skaffold的詳情，請參見Working With Skaffold

自動調試工具比較：

有四個比較流行的 自動調試工具，它們是“Draft”，“Skaffold”，“Garden”，“Tilt”。

Garden：
我最先測試的是“Garden”，因為它功能強大。但測試之后發現它很不靈活，對項目的目錄結構有特殊要求。例如，你的項目有三個微服務，那么它會建一個總項目，三個微服務每個是一個子項目，每個子項目里需要一個“Garden”的微服務配置文件，總項目也要一個配置文件，而且文件的名字和位置是固定的。這導致它配置起來很繁瑣，而且與一般的程序結構有沖突。“Garden”的設計思想是好的，它想使用一個工具來統一開發和部署。但由於開發和部署差別還是很大的，統一的結果就是不倫不類。它給出的例子也都是很簡單的實例，我覺得一旦應用到比較復雜的項目就會很不方便。

Garden的詳情，請參見Introduction

Tilt：
“Tilt”是我第二個測試的，它看起來非常靈活，功能也很強大。但運行之后，它在連接Minikube時出了問題，連接不上。官方安裝文檔給出的默認的k8s集群是Microk8s。它的文檔里也說了支持Minikube，但並沒有解釋需要做哪些設置，看起來像是不需要設置就可以直接連通，不知道為什么我的Minikube會有問題。當然，也有可能是因為我啟動時用的是“minikube start --vm-driver=none”，導致了連接的問題。我想如果花些時間仔細研究，問題應該可以解決，但連接Minikube是整個過程的第一步，一上來就出問題實在讓我有些信心不足，就決定先放一放。

Tilt的詳情，請參見Tutorial: The First 15 Minutes

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

Draft：
我沒有測試Draft。Draft現在已經不再維護了，它的開發者有別的任務，停止了繼續開發。Draft應該比較容易使用，但功能不夠強大。

總體評論：
總的來說我對Skaffold很滿意，它確實大大簡化了調試流程。但我覺得這類工具並不像我想像的那么完美。因為每次修改程序之后都要重新生成鏡像，這個過程很慢。當然你可以有很多手段來優化他，例如建一個本地鏡像庫。另外這類工具本身也有優化措施，例如對下載庫的優化。但總的來說跟本地環境還是沒法比。

關於這些工具的比較詳情，請參見The ultimate guide for local development on Kubernetes: Draft vs Skaffold vs Garden.io和Local Kubernetes development with Tilt.dev

開發模式：

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

純雲原生開發模式：

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

混合開發模式：

在這種模式下，項目是在本地調試的，而它依賴的其它微服務是部署在雲環境上（虛擬機上的k8s上）的。由於本地環境和虛機的網絡是聯通的，本地環境上運行的代碼可以訪問虛機上的微服務。數據庫也是一樣，也是部署在k8s集群上，你可以把它看成一個服務，並通過本地客戶端訪問數據庫上的數據，這時數據庫的物理位置對你是透明的，不管是在雲上還是在本地都沒有區別。當項目的代碼修改之后，你在本地運行項目並調試。如果你需要web服務器，對有些語言不成問題，例如Go，它的web服務器就是用本地代碼生成的，是程序的一部分。如果你用的是Java，需要單獨的服務器，那么你還需要一個本地服務器來部署修改之后的代碼。

這種方式的最大好處就是調試效率很高。因為本項目的代碼修改頻率是最高的，用這種方式能最大限度地提高它的調試速度。雖然犧牲了一點開發環境和生產環境的兼容性，但這也是可以彌補的。例如，你可以每隔一段時間把本地項目部署到k8s集群上（使用上面提到的調試工具）和其他依賴的服務一起進行整個聯調，這時的運行環境就和生產環境一致了。具體的部署頻率根據個人和項目來定，可以是每天，也可以是3天或更多。這樣既能保證平時調試的速度和效率，又能保證本地開發環境和生產環境的一致性。這種模式在我看來更有優勢。

工具總結：

本文詳細講解了雲原生開發環境以及需要的工具，它包括下面四類：

• IDE：必不可少，需支持k8s.
• k8s：是雲原生的基石，沒有它就沒有雲原生.
• Helm：不論什么開發模式，它都是一個不可或缺的工具.
• 自動調試工具：在純雲原生開發模式下是必不可少的，在混合開發模式下也是需要的，但沒有純雲原生開發模式下那么重要。

源碼庫

完整源碼的github鏈接：
k8sdemo

索引

1. 雲原生的不同解釋及正確含義
2. IntelliJ IDEA 2018.1: Kubernetes support
3. 通過搭建MySQL掌握k8s（Kubernetes）重要概念（上）：網絡與持久卷
4. 通過實例快速掌握k8s（Kubernetes）核心概念
5. 用Helm3構建多層微服務
6. Working With Skaffold
7. Introduction
8. Tutorial: The First 15 Minutes
9. The ultimate guide for local development on Kubernetes: Draft vs Skaffold vs Garden.io
10. Local Kubernetes development with Tilt.dev