Kubernetes 短途旅行（下）

Kubernetes 短途旅行（上）

本文會經過一箇中文情緒分析的應用（如下簡稱 SA）把 K8s 的一些基礎概念穿插講一講，接着咱們會進行一次 UI 的更新以便體驗一下 K8s 的滾動更新，最後咱們還會進行一次回滾，把 UI 的更新給撤銷掉並回滾到上一個版本。

那麼接下來就按照這個劇本開始吧。

中文情緒分析的應用 SA

倉庫地址：github.com/jwma/sentim…

SA 分爲三個部分：

• sa-frontend，使用 Vue.js 開發的前端應用並部署在 Nginx，提供讓用戶交互的界面；
• sa-webapp，使用 Go 語言開發的 API 服務，直接面向前端應用；
• sa-logic，使用 Python 開發的情緒分析服務，面向 API 服務，對前端應用不可見。

部署到 K8s

若是咱們要將 SA 部署到 K8s 集羣，咱們須要先準備一些必需品：

1. K8s 集羣;
2. 容器鏡像；
3. Deployment 和 Service 配置文件；
4. 建立 Deployment 和 Service 資源。

1. K8s 集羣

參考上一篇文章，你會找到適合你本身的途徑。這裏我會使用 Minikube 爲我啓動一個本地的單節點集羣。

2. 容器鏡像

容器化的細節本文就不展開了，能夠參考項目源碼內各部分的 Dockerfile，下面講講構建鏡像的相關內容。

通常來講，咱們會把咱們的容器鏡像推送到一個鏡像倉庫如 DockerHub，但因爲咱們的集羣就是在本地，因此咱們能夠重用 Minikube 內置的 Docker，這樣咱們就不須要浪費時間去推送鏡像和拉取鏡像了，便於咱們在本地體驗。

這樣使用時須要注意，在爲鏡像打 tag 時，須要使用 :latest 之外的名字，由於當你使用了 :latest 意味着鏡像拉取策略也會被修改成 Always，在鏡像不存在於默認的 Docker 鏡像倉庫（通常爲 DockerHub）時，會引起 ErrImagePull 錯誤。

咱們能夠這樣使用 Minikube 內置的 Docker：

eval $(minikube docker-env)
複製代碼

此時命令行的 Docker 就是 Minikube 的 Docker 了，接着咱們就能夠構建鏡像了：

# 切換到源碼目錄
cd /path/to/sentiment-analyzer
 # 構建 sa-logic 鏡像
docker build -t sa-logic:v1.0.0 sa-logic
 # 成功的話會看到以下輸出
# Successfully tagged sa-logic:v1.0.0
 # 構建 sa-webapp 鏡像
docker build -t sa-webapp:v1.0.0 sa-webapp
 # 成功的話會看到以下輸出
# Successfully tagged sa-webapp:v1.0.0
 # 暫時沒法構建 sa-frontend
# 由於其依賴了 sa-webapp 暴露的通訊地址
# 須要等咱們建立了 sa-webapp service 以後再構建
複製代碼

3. Deployment 和 Service 配置文件

這一部份內容比較無聊，着急的能夠先跳過。

查看源碼的 infrastructure 目錄，其中包含了 Deployment 和 Service 配置文件。

以 sa-webapp 的 Deployment 舉例：

• #1 apiVersion 指定了該資源對象所對應的 API 版本，K8s 支持多個 API 版本，K8s 團隊選擇在 API 級別進行版本化，而不是在資源或字段級別進行版本化，以確保 API 提供清晰，一致的系統資源和行爲視圖，並控制對已廢止的 API 和/或實驗性 API 的訪問；
• #2 kind 指定了該資源的類型爲 Deployment；
• #3 metadata K8s 的資源對象都擁有通用的元數據，這裏指定了名稱和添加了一個鍵爲 app 值爲 sa-webapp 的標籤，後續須要用來匹配對應的 Service；
• #7 spec 描述你指望的 Deployment 的狀態；
• #8 spec.replicas 指按期望的 Pod 數量，默認值是 1；
• #9 spec.selector 指定了 Deployment 管理 Pod 的範圍，經過標籤進行匹配；
• #12 spec.template 指定 PodTemplate，描述了 Pod 的細節，這裏爲 Pod 添加了一個鍵爲 app 值爲 sa-webapp 的標籤，也指明瞭 Pod 的名字及其實用的鏡像，爲了讓容器能正常運行，還設置了容器所需 的環境變量，最後還暴露了容器的端口。

以 sa-webapp 的 Service 舉例：

• #2 kind 指定了該資源的類型爲 Service；
• #8 spec.selector 經過標籤選擇器匹配 sa-webapp Deployment；
• #10 spec.type 指定 Service 類型爲 LoadBalancer，也就說來自外部的流量會經過這個 Service 的負載均衡器而後打到匹配的 Pod 上；
• #11 spec.ports 指定端口的映射關係，把負載均衡器的 80 端口映射到 Pod 的 8080 端口。

什麼是 Deployment 和 Service?

在本文的例子中，除了認識 Deployment 和 Service 外，你還須要認識 Pod 和 RS（Replica Set），由於他們的互相結合才使得咱們可以把 SA 給運做起來。

實質上，它們都是 K8s 的 API 對象，只是他們負責的工做內容不同而已。

Pod

Pod 是 K8s 應用的基礎執行單元，它是你建立或部署的最小最簡單的 K8s 單元。一個 Pod 一般包含的是一個應用容器（有時候會是多個容器）。結合上文，咱們在 Deployment 聲明瞭 PodTemplate，也就是說咱們的 Pod 會按照咱們的聲明運行咱們想要運行的容器。

RS

RS 保證 Pod 的高可用。結合上文，咱們在 Deployment 聲明瞭 replicas，咱們指望運行兩個 Pod，而實際運行中的 Pod 的數量就是經過 RS 進行保障的。

Deployment

Deployment 能夠建立/更新一個服務，也能夠滾動更新服務。咱們經過配置文件，能夠告訴 K8s 集羣咱們指望應用的運行狀態，結合 Pod 咱們能把應用運行起來，結合 RS 咱們能保障 Pod 的可用性。一次對 Deployment 的操做，就是經過操做相關的 API 對象來更新應用的運行狀態以達到咱們的指望。

Service

經過上面的幾個 API 對象，咱們已經保證應用可以正常運做，但沒有解決如何訪問這些服務的問題，Service 就是用來解決這個問題的。

4. 建立 Deployment 和 Service 資源

在 K8s 上建立 API 對象的資源很簡單，咱們可使用統一的方式進行建立：

# 切換到源碼目錄
cd /path/to/sentiment-analyzer
 # 建立 sa-logic 的 Deployment、Service
kubectl apply -f infrastructure/deployment/sa-logic.yaml
 # 查看 sa-logic 對應的 Pod 是否正常運做
kubectl get pods -l app=sa-logic
 # 建立 sa-logic 的 Service
kubectl apply -f infrastructure/service/sa-logic.yaml
 # 查看 sa-logic 對應的 Service
kubectl get service -l app=sa-logic
 # 建立 sa-webapp 的 Deployment、Service
kubectl apply -f infrastructure/deployment/sa-webapp.yaml
kubectl apply -f infrastructure/service/sa-webapp.yaml
複製代碼

到這裏，咱們就把 sa-logic 和 sa-webapp 部署到 K8s 集羣了，sa-webapp 是一個對外可見的服務，因此咱們在部署 sa-frontend 以前，可使用 postman 或者 curl 來訪問如下 sa-webapp 看看。

因爲咱們使用的是 Minikube，因此爲了獲取 sa-webapp 服務的通訊地址，咱們須要：

minikube service sa-webapp-service --url
複製代碼

咱們會獲得一個 URL，如：http://192.168.99.105:31861，接下來咱們用 cURL 工具測試下 sa-webapp 的接口：

# 發送請求
curl --request POST \
  --url http://192.168.99.105:31861/analyse \
  --header 'Content-Type: application/json' \
  --data '{"sentence": "很是棒"}'
 # 響應結果
{"sentence":"很是棒","level":9}
複製代碼

咱們成功的獲得告終果。如今咱們已經獲得了正確的 sa-webapp 的通訊地址了，因此咱們能夠開始構建 sa-frontend 鏡像而後部署了：

# 切換到源碼目錄
cd /path/to/sentiment-analyzer

docker build -t sa-frontend:v1.0.0 --build-arg VUE_APP_API_HOST=http://192.168.99.105:31861 sa-frontend

kubectl apply -f infrastructure/deployment/sa-frontend.yaml
kubectl apply -f infrastructure/service/sa-frontend.yaml
複製代碼

而後咱們就能夠獲取 sa-frontend 的訪問 URL 了：

# 此次不加 --url，會自動在瀏覽器打開
minikube service sa-frontend-service
複製代碼

你也能夠像我這樣玩一下：

滾動更新

在 K8s 上要實現滾動更新是一件很是簡單的事情。 咱們接下來會更新 sa-frontend，由於我以爲每次提交完一個句子後，Emoji 出現的太突兀，缺少了一些動感，因此我接下來會使用 animate.css 爲 Emoji 加一個動畫，讓畫面看起來更有動感一些。

來看看整個流程吧：

1. 修改代碼；
2. 構建一個新的 sa-frontend 鏡像；
3. 更新 sa-frontend Deployment 配置文件；
4. 向 K8s 提交 Deployment；
5. 查看結果。

1. 修改代碼

這裏不是重點，就跳過了。

2. 構建一個新的 sa-frontend 鏡像

咱們更新了代碼，因此咱們也會跟着構建一個新的鏡像，鏡像版本號取 v1.1.0。

# 切換到源碼目錄
cd /path/to/sentiment-analyzer

docker build -t sa-frontend:v1.1.0 --build-arg VUE_APP_API_HOST=http://192.168.99.105:31861 sa-frontend/
複製代碼

3. 更新 sa-frontend Deployment

# ...省略
# 鏡像修改成剛剛構建好的 v1.1.0
image: sa-frontend:v1.1.0
# ...省略
複製代碼

4. 向 K8s 提交 Deployment

跟第一次部署 sa-frontend 同樣，咱們向 K8s 集羣提交了咱們的 Deployment 配置文件。

kubectl apply -f infrastructure/deployment/sa-frontend.yaml
複製代碼

5. 查看結果

我感受這樣就好多了呢。

在這裏，你能夠不去思考 K8s 的滾動更新是怎麼作的，但我認爲日後你應該要去了解這件事情，這對你理解 K8s 的各個 API 對象頗有幫助。

回滾

若是你是一個比較安靜的孩紙，不喜歡這麼動感，你能夠回滾到上一個版本：

kubectl rollout undo deployment sa-frontend-deployment
複製代碼

除了回滾到上一個版本，你還能回滾到指定的版本，這裏就不展開了，我相信若是要用到的時候你確定會去翻文檔的。

短途旅行的終點

咱們到達了此次短途旅行的終點，就像真正的旅行同樣，這個終點每每會是原點，咱們不斷的旅行，咱們見識到了不一樣的風景，認識到了不一樣的朋友，體驗了不一樣的風情，雖然咱們又回到了原點，但咱們不斷積累閱歷，讓咱們面對下一個挑戰更具勇氣，讓咱們走得更遠看得更廣。

但願這兩篇文章，能帶你蜻蜓點水看看 K8s，若是能在你的腦中留下 K8s 好像真的不錯哦，我想我就知足了。