本系列的第一篇[文章](https://xie.infoq.cn/article/27f5f6250a3033ea09c337989)，我們學習了每一個 Kubernetes 從業者的實際工作中幾乎都會使用的步驟：建立 Deployment 和 Service，同時透過實際例子講解了 Pod 和 Service 繫結的實現方式，介紹了使用 Kubernetes Job 計算圓周率這種費時的操作。

本文作為 Kubernetes 學習系列的第二篇文章，我們繼續學習 XX.

# 練習1 - 使用指令碼在 Linux 伺服器上自動安裝 Kubernetes 的包管理器 Helm

Helm 之於 Kubernetes 好比 yum 之於 Red Hat Enterprise Linux，或者 apt-get 之於 Ubuntu.

Helm 是由 helm CLI 和 Tiller 組成，是典型的 Client/Server 應用。helm 執行於客戶端，提供命令列介面；Tiller 應用執行於 Kubernetes 內部。

![](https://img-blog.csdnimg.cn/img_convert/2d24e2a7ad76738014ca617266b14c40.png)

本練習使用一種全自動的做法，使用安裝指令碼自動安裝。

(1) 自動下載安裝指令碼
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get > get_helm.sh

![](https://img-blog.csdnimg.cn/img_convert/1fb1b9f1d4c079d12d1d29e394aa5a1e.png)

開啟指令碼，可以看到 helm 安裝的環境變數 `HELM_INSTALL_DIR` 為 `/usr/local/bin`:

![](https://img-blog.csdnimg.cn/img_convert/f74bb03064cc352c4961f09b5a3c7e61.png)

(2) chmod 700 get_helm.sh

![](https://img-blog.csdnimg.cn/img_convert/e0aece2ddb4c85f87d83f30f201e075c.png)

./get_helm.sh:

![](https://img-blog.csdnimg.cn/img_convert/0950d0c515911e015cd060cbadc03cc4.png)

(3) 執行 helm init, 看到 Happy Helming 訊息，說明安裝成功。

![](https://img-blog.csdnimg.cn/img_convert/c1da9ff8106364000eff84416c52b5b8.png)

# 練習2 - 一個簡單的例子理解 Kubernetes 的三種 IP 地址型別

很多 Kubernetes 的初學者對 Kubernetes 裡面三種不同的 IP 地址和工作機制理解得不是很清楚。

本練習我們透過一個最簡單的例子來學習。

用如下命令列建立一個基於 nginx 的 deployment：

> kubectl run nginx --image=nginx:maxline

用 kubectl get deploy 檢視成功生成的名為 nginx 的 deployment：

![](https://img-blog.csdnimg.cn/img_convert/2816fea718eeae3230e7d2493ad35f4b.png)

此時這個 deployment 裡的 nginx pod 還無法對外界提供服務。

我們建立一個 service 讓外界能夠消費。使用命令列建立這樣的一個 service：

> kubectl expose deployment nginx --type=LoadBalancer --port=80 --target-port=80

type 的型別選擇為 LoadBalancer， --port 指定的是 80 埠，意思是這個 service 對外界暴露出來的服務埠是 80，--target-port=80，這個埠是 pod 內部的 nginx docker 容器提供服務的工作埠，預設為 80。這裡實際上建立了向外界開發的 80 埠同 nginx 容器內部埠的一個對映關係。

![](https://img-blog.csdnimg.cn/img_convert/6a31bf75a99b77acd8680399d17e0f14.png)

執行完畢後，我們呼叫下面的命令列，看到了建立的 service 的 Cluster IP 和 External IP.

![](https://img-blog.csdnimg.cn/img_convert/e49c0ac8ba5abd0bfba407c808d5d569.png)

其中 external IP 很好理解，這個 service 透過 external IP 加上我們前面介紹的被對映到 80 埠向外界提供服務：

瀏覽器裡輸入External IP http://35.241.173.27:80, 能成功訪問 nginx 伺服器的 index.html:

![](https://img-blog.csdnimg.cn/img_convert/a27d5a5e55731aa45d27cbccd1891a6c.png)

而我們透過 Service 的 Cluster IP 是無法訪問這個 Service 提供的功能的。

我們知道 Kubernetes 裡的所有 pod 都可以彼此通訊，而不需要透過網路地址轉換（Network Address Translation-NAT），所有的節點也可以與所有的 pod 通訊。而 Service 的 Cluster  IP，是一個內部的 IP 地址，專門用於同 Cluste r內部的節點或者 pod 通訊。同外界通訊，還是透過 External IP 進行。

接下來再試試 NodePort.

> kubectl expose deployment nginx --type=NodePort --port=80 --target-port=80

注意看下圖的 PORT 欄下面顯示的型別為 NodePort 的埠：31375

這個埠號是 Kubernetes expose 命令自動生成的，範圍在 30000 到 32767 之間。如果需要修改，可以編輯 api server 的配置檔案：/etc/kubernetes/apiserver:

![](https://img-blog.csdnimg.cn/img_convert/5d8c8c572366262592f2b41718f6c9e4.png)
![](https://img-blog.csdnimg.cn/img_convert/b6d8d4b7690fc0f008463e4f9e14e7eb.png)

有了這個埠號，我們隨便使用一個 node 的 IP 地址，後面拼接上 `:31375` 即是外部可以消費的完整地址。

使用命令列 `kubectl get nodes -o wide`, 在結果裡選擇任意節點的 External-IP，後面加上:31375:

![](https://img-blog.csdnimg.cn/img_convert/d8e06e80142ebc4887f20ed7758e7d53.png)

測試：
http://146.148.23.183:31375/
測試透過。

![](https://img-blog.csdnimg.cn/img_convert/99593a2acd174a079cb34902309e9693.png)

接下來繼續學習 Pod 的埠轉發功能。

值得一提的是，有時我們出於測試的目的，需要一種簡單的辦法檢視一個 pod 是否能正常提供服務。如果每次透過 kubectl 的方式建立 service 就太麻煩了。

本練習介紹一種簡單的辦法：pod的埠轉發功能（port forward）。
比如我們想測試下圖get pods返回的第一個pod的功能，名稱為nginx-6f754dd4b9-74jdn：

![](https://img-blog.csdnimg.cn/img_convert/eb9bdec45ee1373dafd926fcf0a41598.png)

執行命令列 kubectl port-forward pod/nginx-6f754dd4b9-74jdn 8080:80
看到提示資訊 Forwarding from 127.0.0.1:8080 -> 80, 意思是把當前主機的 8080 埠對映到nginx pod 的 80 工作埠：

![](https://img-blog.csdnimg.cn/img_convert/6842ddad9c2cfb100b7c63cd3f1ba3a5.png)

最後，就能夠透過 localhost:8080 直接訪問 nginx pod 提供的服務了：

![](https://img-blog.csdnimg.cn/img_convert/0913bd5bb86dec1a1aebeda6582b6a9c.png)

# 練習3 - 使用 describe 命令進行 Kubernetes pod 錯誤排查

我有一個 pod 名叫 another，用 `kubectl create` 建立後發現過了 29 分鐘，狀態還是處於 ContainerCreating 階段。

![](https://img-blog.csdnimg.cn/img_convert/7b9fd8eabd20af4392c3f75c5a9e13ca.png)

使用 kubectl describe 命令檢查：

![](https://img-blog.csdnimg.cn/img_convert/f0900765b893c7d8d3c9cc6bb5de6cad.png)

從錯誤訊息發現是因為這個 pod `attach volume` 失敗：

> FailedAttachVolume 2m1s (x22 over 31m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-c4d41f5c-e7ed-11e8-8726-fe6d42bf075f" : googleapi: Error 400: RESOURCE_IN_USE_BY_ANOTHER_RESOURCE - The disk resource 'projects/sap-pi-coo-acdc-dev/zones/europe-west1-b/disks/shoot--k8s-train--shac-pvc-c4d41f5c-e7ed-11e8-8726-fe6d42bf075f' is already being used by 'projects/sap-pi-coo-acdc-dev/zones/europe-west1-b/instances/shoot--k8s-train--shacw46-worker-prvfv-z1-7844dc6744-ghd5m'
Warning FailedMount 31s (x14 over 29m) kubelet, shoot--k8s-train--shacw46-worker-prvfv-z1-7844dc6744-hhrmd Unable to mount volumes for pod "another_part-0110(13f15fa4-e819-11e8-8726-fe6d42bf075f)": timeout expired waiting for volumes to attach or mount for pod "part-0110"/"another". list of unmounted volumes=[content-storage]. list of unattached volumes=[content-storage default-token-6z5sk]

根據上面的錯誤訊息順藤摸瓜，檢視這個 pod 的 yaml 檔案，果然發現有一個 persistent volume 的 claim：

![](https://img-blog.csdnimg.cn/img_convert/1eabd5962d4937c3f021a6edfaccaf98.png)

用命令 `kubectl get pv`, 發現當前所有的 persistent volume 都被佔用了（BOUND狀態）：

![](https://img-blog.csdnimg.cn/img_convert/a8336be90bb71214010c2398d18f154a.png)

解決方案有很多種，出於測試目的，我只是簡單地將另一個同樣宣告瞭 `nginx-pvc` 作為PersistentVolumeClaim 的 pod 刪除，然後這個名為 another 的 pod 狀態就很快變成 `Running` 了：

![](https://img-blog.csdnimg.cn/img_convert/84677187e859de46323c36155f505601.png)

從 `describe` 命令生成的日誌裡也能清楚的觀察到這個成功 mount volume 的事件：

![](https://img-blog.csdnimg.cn/img_convert/de5e876e1d42429abe9d8fe729069f3d.png)

> Normal SuccessfulAttachVolume 84s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-c4d41f5c-e7ed-11e8-8726-fe6d42bf075f"

# 總結

繼本系列第一[部分](https://xie.infoq.cn/article/27f5f6250a3033ea09c337989) 介紹了 Kubernetes 建立 Pod 和 Service 的基礎操作，以及 Pod 和 Service 繫結的實現原理後，本文作為該系列的第二部分，分享了 Kubernetes 包管理器 Helm 的安裝方式，以及 Kubernetes 三種 IP 型別，最後介紹瞭如何使用 describe 命令分析一個 Pod 不能啟動的實際問題。

適合 Kubernetes 初學者的一些實戰練習(二)

相關文章