說了半天跨平臺，今兒咱就來跨跨！（完結篇）——Kubernetes 上手實踐

兩句閒言

去年寫過兩篇這個系列的文章，出於種種原因（當然主要原因是我懶），沒有完成。後來也陸續寫了一些別的內容，但始終沒有再去把這個尾巴給續上，正好最近接觸了一下 kubernetes，就以這個為切入點，來完結這個系列吧。

第一篇:point_right:： http://xie.infoq.cn/article/5fdeb09ec3872f86727a94a22

第二篇:point_right:： http://xie.infoq.cn/article/4f735951a021aa02c5c290f09

幾片碎語

其實我寫這篇 kubernetes 內容的底氣也不是很足，目前的知識結構主要是建立在部分官方文件的基礎上，因為實踐成功，有點大喜過望，記錄一下過程，也算是給還沒有實際接觸過 kubernetes 的老鐵們趟趟道，正式開啟雲原生開發之旅了，哈哈！

再說為什麼要聊 kubernetes 呢？現在的軟體市場，單體應用以後基本沒什麼發展前途了，早在很多年以前，單體應用的前景就已經能看到天花板了，只是在一些小微企業和特殊的場景裡，單體應用還在發光發熱。而放眼整個網際網路，不論國內還是國外，雲原生，分散式，高併發系統都已經相當普及了。所以這就是所謂的“風口”，我覺得程式設計師還是要順勢而為，投入到有未來，有發展前景的行業中去，跟上時代，不然知識面太窄，造成就業面也太窄，以後再遇上個裁員潮，就真的芭比 Q 了啊！

準備工作

故事該從哪裡說起呢？

如果之前沒有接觸過 kubernetes，上手的時候是一個模糊，朦朧的狀態，雖然現在關於 kubernetes 的文章很多，但有的寫的版本比較早，再用新的版本來參照已經不適用，有的寫的內容非常大，脫離了入門基礎。所以要說起入門級別的指引，還是得看官方的文件！其實上手任何工具，框架，或者開發語言，最好的入門資料，絕大多數時候都是官方的文件。雖然有些時候這些文件並沒有中文版本，但翻譯軟體如此發達的當下，這個並不是太大的問題。我這裡依照的入門流程就是幾篇官方文件，分別是

:point_right:：kubernetes的官方文件

:point_right:：docker的官方文件

:point_right:：kind的官方文件

:point_right:：minikube的官方文件（打了個醬油）

為什麼要看這麼多文件？答案也很簡單，因為不熟！所以在上手的時候，會看到文件裡有很多概念，把你指引到相應的地址，其中關聯最多的，就是以上四個地方。

注意，我的分享主要是介紹從零開始搭建本地開發環境並實際部署一個叢集，其中不會太深入相關概念的解釋，建議在上手過程中如果遇到此類困惑，還是去文件中尋求答案。

先試著搭個開發環境吧

這裡，我再想多說一句。在選擇開發環境，尤其是上手人員還是新手的時候，最好選一個自己熟悉的環境進行操作演練。你平時在 windows 環境下開發，就選 windows 的作為開發環境，是 macOS 就選 macOS，不要貿然選一個自己不熟悉的環境去嘗試新的東西。現在的各種軟體工具，基本都是跨平臺支援，即便 Windows 環境不太適合生產環境，但作為開發環境來練習和入門還是綽綽有餘的！

基本情況

先介紹下我本機的相關情況

作業系統 ：Windows 11

子系統 ：Ubuntu 22.04

基本軟體 ：docker desktop（V4.11.1，截止到 2022.8.9 號官方釋出的最新版本）

準備工作

啟用 wsl2

如果還沒安裝，可以參照官方文件進行安裝，系統需要開啟 wsl

開啟 wsl2

# 在powershell或者命令提示符終端中輸入該命令即可wsl.exe –set-default-version 2

驗證 wsl 版本（我這裡因為已經安裝好了 docker 環境，所以會列出更多內容）

wsl -l -v

安裝合適的 Ubuntu 發行版

在 windows store 中找一個合適的發行版即可，我這裡用的是 22.04

安裝好後，根據指引，進入 ubuntu 子系統，進行更新

# 更新可用軟體包的儲存庫和列表 sudo apt update
# 根據安裝的軟體包更新系統 > “-y” 將自動批准更改 sudo apt upgrade -y

安裝 Docker Desktop

Windows 環境下的 Docker Desktop 安裝非常簡單，參照文件安裝即可需要說明的是，在安裝之前，請確保系統開啟了 hyper-v

啟動 wsl 整合

開啟，docker desktop，進入設定頁面，執行相關配置

配置完成後，進入 ubuntu，驗證配置是否生效

sudo apt upgrade -y

看到終端打印出相關資訊，則證明配置生效！

*一點額外操作

到上面那一步，其實基本的配置就完成了，但由於國內的網路環境限制，為了更好的體驗，還要配置一些映象加速類的操作這裡我用的是阿里雲的映象加速，基本操作流程可以參照一下官方文件:point_right:： http://help.aliyun.com/document_detail/60750.html

根據文件進行一系列配置後，會得到一個加速器地址，結構是這樣的：

[系統分配字首].mirror.aliyuncs.com 。

然後把這個新增到 docker 的配置檔案裡就好

 "registry-mirrors": [    "http://{系統分配的字首}.mirror.aliyuncs.com"  ]

好了，終於可以正式去建立叢集了!

建立叢集

kind 還是 minikube？

兩種方式其實都可以，在 kubernetes1.24 之前，minikube 的方式應該是更容易，現在網上的很多資料也都是基於 minikube 的。但環境來到 wsl 中後，情況可能會發生變化。這裡我把我踩過的坑簡單介紹一下，怕折騰的同學可以簡單參考一下

• 安裝，這個沒什麼可說的，在 wsl 中安裝 minikube 還是很流暢的，執行著幾段命令就可以

# 下載curl -Lo minikube http://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64# 使二進位制可執行檔案chmod +x ./minikube# 將二進位制檔案移動到可執行路徑sudo mv ./minikube /usr/local/bin/

• 啟動

minikube start

到這裡，會出現一個大概這樣“System has not been booted with systemd…”的錯誤然後到這裡，我折騰了一番，為了讓 wsl 中啟用 systemd，找了很多方法，結果，成功的讓我的虛擬機器起不來了。。然後為了繼續“探索”，我也不得不把子系統刪掉，再重新安裝了一次。這也是上邊這一段為啥沒截圖的原因，因為不想再折騰一次了~~

但後來翻看文件內容，我的嘗試應該是方向錯了，因為 minikube 本身提供了基於 windows 系統的啟動方式，並不需要在 wsl 中使用，所以，如果大家想在 Windows 上嘗試 minikube，建議先看一下文件的介紹吧~~

對了，我還確實找到了一個可以在 wsl 中使用 systemd 的指令碼。看評論應該是好使，但我沒再繼續嘗試了，因為它這個指令碼也已經實在 2019 年寫的了，而且畢竟也不是官方出的方案，有興趣的同學可以研究一下，傳送門:point_right:： http://forum.snapcraft.io/t/running-snaps-on-wsl2-insiders-only-for-now/13033

用 kind 來建立一個叢集

安裝 kind

開啟 windows 終端，進入到 wsl 子系統，按順序輸入如下命令，安裝 kind

# 下載curl -Lo ./kind http://kind.sigs.k8s.io/dl/v0.14.0/kind-linux-amd64# 使二進位制可執行檔案chmod +x ./kind# 將二進位制檔案移動到可執行路徑sudo mv ./kind /usr/local/bin/kind

可以看到，安裝流程和 minikube 的安裝流程基本一致

建立一個單節點叢集

安裝好 kind 後，可以簡單做一些驗證性的操作，然後就可以建立叢集了

# 建立一個單節點叢集，名字叫wslkindkind create cluster --name wslkind

到這裡，就已經建立了一個基本的叢集節點了。

因為 kind 本身就是一個適合學習和測試的工具，啟動快，資源佔用低，但目前不適合生產環境，所以這裡更多的內容，就不過多囉嗦了，大家感興趣可以到官方文件去了解一下。

利用 Docker Desktop 建立叢集（推薦）

事實上，在 Windows 環境下建立基於 docker 的 k8s 叢集，已經變得非常簡單，通過 docker desktop 提供的 kubernetes 能力就可以完成，關於這一點，docker 的官網有更為詳細的介紹，大家可以去看一下。

在 Windows 環境下，用 Docker Desktop 來部署 k8s 叢集有一個非常大的優勢，就是 docker 提供了視覺化的介面，多數情況下，不需要輸入命令就可以完成操作，這對新手來說還是非常友好的。

開啟 kubernetes

開啟 Docker Desktop 的設定介面，到 kubernetes 欄目，勾選“Enable Kubernetes”選項，然後應用並重啟。

執行上述操作後，會自動下載一些映象到本地，這裡我們可以先不用去管。

打包應用映象

開啟 kubernetes 環境後，既可以去打包我們自己的應用映象了，這裡我之前已經打包好並上傳到dockerhub了，具體流程，在文章開頭的兩個連結裡有具體介紹，也單獨寫過一篇相關的文章，可以簡單參考一下。打包後，登入 dockerhub，可以看到自己上傳的映象

編寫 k8s 啟動檔案

為什麼要編寫一個配置檔案？關於這一點，其實內容有 億 點抽象，我貼一段 docker 官網上的話（翻譯過的，原文地址）

“使用 Kubernetes YAML 描述應用程式 Kubernetes 中的所有容器都被排程為 pod，它們是共享一些資源的同地容器組。此外，在實際應用中，我們幾乎從不建立單獨的 pod；相反，我們的大部分工作負載都被安排為部署，它們是由 Kubernetes 自動維護的可擴充套件的 Pod 組。最後，所有 Kubernetes 物件都可以並且應該在稱為 Kubernetes YAML 檔案的清單中進行描述。這些 YAML 檔案描述了 Kubernetes 應用程式的所有元件和配置，可用於在任何 Kubernetes 環境中輕鬆建立和銷燬您的應用程式。”

總之，現階段，我們要知道，需要編寫一個 yaml 格式的檔案，來描述應用程式的一些基本內容，通過這個檔案，才能讓 kubernetes 來啟動叢集

apiVersion: apps/v1kind: Deploymentmetadata:     name: k8s-cipapi    namespace: default    labels:        name: k8s-cipapispec:     replicas: 1    selector:        matchLabels:             name: k8s-cipapi    template:        metadata:          labels:            name: k8s-cipapi        spec:          containers:          - name: k8s-cipapi            image: tonydf/cipapi:v220804 # 映象標識，如果本地不存在就會到dockerhub拉取，當然這個拉去規則是可以設定的。            ports:               - containerPort: 8002
---
apiVersion: v1kind: Servicemetadata:  name: k8s-cipapi  namespace: defaultspec:  type: NodePort  selector:    name: k8s-cipapi  ports:  - port: 8002    targetPort: 80

注意，這裡涉及到很多屬性，我就簡單挑幾個說明一下

• apiVersion，建立該物件所使用的 Kubernetes API 的版本

• kind，想要建立的物件的類別

• metadata，幫助唯一標識物件的一些資料，包括一個 name 字串、UID 和可選的 namespace

• spec，你所期望的該物件的狀態

• ---，這三個線表示同級別內容的分割

以上只是外層屬性的含義，其中每個屬性內部還有各自專屬的子屬性，的確有些複雜，但好在層次分明，條例清晰，yaml 的格式也比 json 更加簡潔，實際理解起來並不是很困難。更具體的大家可以去看kubernetes的官方文件

啟動叢集

在 windows 終端中，通過命令，啟動我們自己的 k8s

kubectl apply -f .\cipapi.yaml

啟動之後可以命令，檢視啟動狀態

kubectl get deployments

可以看到，啟動叢集之後，叢集狀態並沒有馬上變成“ready”狀態，這是因為我再啟動這個叢集的時候，並沒有在本地打包容器映象，因此 k8s 會自動根據我設定的映象標籤去 dockerhub 拉取映象。幾分鐘後，再來看叢集狀態

就已經是啟動狀態了。還可以通過如下命令，來檢視服務狀態

 kubectl get services

k8s-cipapi 就是我們自己的服務專案了。同樣的，可以執行 docker ps 命令，來對照一下容器的狀態

可以看到，k8s 自動幫我們建立了一個容器，並根據我們在 yaml 中配置的相關內容設定了容器的 name。

資料驗證

確定叢集正常啟動後，就可以來驗證一下服務是否正常啟動了通過命令

kubectl get svc

可以看到 k8s 給我們部署好的服務的外部埠

可以看到，容器內部，使用的是 8002 埠，暴露給外網訪問的埠變成了 31494 在瀏覽器訪問一下

這裡呢，是因為 swagger 的預設配置不支援跨域，而 k8s 通過類似 nginx 反向代理的形式把對外的埠改成了 31494，所以訪問 swagger 預設文件的時候會提示這個錯誤，所以這個是系統配置的問題，並不是叢集造成的問題。接下來在通過 postman 來實際訪問一下介面，看看效果

可以看到，介面成功返回了資料！

另外，這裡的 31494 其實是 k8s 幫我們暴露給外部訪問的一個 node 埠，因為我這裡主要定位是“跑通”，所以更多關於概念性的東西大家還是務必要到官方文件去看一下。

通過 kubernetes-dashboard 來檢測叢集狀態

通過上面的實踐，可以看到，部署好叢集之後，還要監控叢集的狀態，而在實際的開發應用中，如果每次都通過命令列的形式來檢視，效率就太低了，因此我們可以部署一個 dashboard 應用，來視覺化的管理我們的叢集。

先上 github 地址:point_right:： http://github.com/kubernetes/dashboard

其實具體安裝和配置流程，這個文件裡也介紹的很清楚了，我這裡就簡單過一下流程

安裝

kubectl apply -f http://raw.githubusercontent.com/kubernetes/dashboard/v2.6.0/aio/deploy/recommended.yaml

訪問

# 要從本地工作站訪問 Dashboard，必須為 Kubernetes 叢集建立一個代理訪問通道kubectl proxy

代理啟動後，在瀏覽器訪問這個地址 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/，就可以看到登陸介面了

建立 rbac 配置檔案

要想快速訪問這個管理面板，需要建立一個基於 rbac 的 token，為了快速完成這個操作，首先需要建立一個 yaml 檔案

apiVersion: v1kind: ServiceAccountmetadata:  name: admin-user  namespace: kubernetes-dashboard  ---
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: admin-userroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-adminsubjects:- kind: ServiceAccount  name: admin-user  namespace: kubernetes-dashboard

然後通過建立叢集的指令，完成服務的部署

kubectl apply -f dashboard-adminuser.yaml

之後，就可以獲取 token 了

kubectl -n kubernetes-dashboard create token admin-user

複製這個 token 值，到登陸介面，就可以看到管理面板了

到此，在開發環境部署 k8s 叢集的旅程就基本結束了，接下來就是更加深入的瞭解，和調整優化了！

結束語

基本就是這些啦，關於 k8s 和微服務的探索，這僅僅是冰山一角，還有更多的內容等待去挖掘，我也會繼續狂奔，順勢而為，希望參與評選的大家，都有好成績啊，哈哈。

*注：本文也同步釋出於阿里雲開發者社群:point_right:： http://developer.aliyun.com/article/994445