網管人雜誌
本文刊載於 網管人雜誌第 151 期 - 2018 年 8 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
前言K8S（Kubernetes）是什麼？
Kubernetes 叢集運作架構
Kubernetes 叢集實戰
啟用 AKS 預覽功能
建立資源群組
建立 Kubernetes 叢集
連線至 Kubernetes 叢集
新增 Kubernetes 部署和服務
擴充和縮小運作規模
Kubernetes 儀表板
刪除 Kubernetes 叢集環境
結語
前言
「容器」（Container）技術，在這幾年時間已經被大多數開發人員及 IT 管理人員所熟知，然而跟所有技術相同，一旦管理人員面對數量越來越多的容器及互相依存的應用程式時，便需要尋找一套方便好管理並且具備高可用性機制的「調度」（Orchestration）平台。同時，容器調度平台已經從先前百家爭嗚的戰國時代至目前大致底定，從 Google 搜尋熱度的趨勢變化結果可以看到，在近五年的關鍵字搜尋熱度中 K8S（Kubernetes）容器管理調度平台，已經躍升為第一名並遠遠超過其它容器管理調度平台（如圖 1 所示）。
圖 1、Google 搜尋熱度的趨勢變化-容器管理調度平台
此外，根據知名市調機構 RightScale，在最新一期的 2018 - State of the Cloud Report 調查報告結果也顯示，不管是公有雲供應商或企業及組織內使用的容器技術，雖然仍以 Docker 做為主要的容器底層技術，然而在容器管理調度平台方面則開始以 K8S（Kubernetes）為主，同時 K8S 也是成長最快速的容器調度平台（如圖 2 所示）。
圖 2、RightScale 市調統計結果，企業用於管理容器技術的優先順序
K8S（Kubernetes）是什麼？
首先，管理人員一開始接觸 K8S（Kubernetes）容器管理調度平台時，一定對於這個技術名稱縮寫有點好奇。事實上，Kubernetes 名字起源為希臘語意思是指掌舵手或飛行員，而 K8S 的由來只是將完整的 Kubernetes 名稱中，保留「開頭 K」及「結尾 S」的英文字母，至於中間的英文字母數量剛好是「8 個英文字」，這就是簡單來說，當企業及組織的 IT 管理人員開始使用 Docker 容器技術（如圖 3 所示），並且隨著享受到 Docker 容器技術的好處後，在資料中心內的容器數量不斷成長的情況下，便需要有個方面管理及調度眾多容器的平台，而 K8S（Kubernetes）為 Google 在 2014 年進行開源的容器管理調度平台，融合 Google 多年的容器管理調度經驗，漸漸成為大家喜愛的容器管理調度平台。
圖 3、傳統部署於主機上的應用程式vs新興部署於容器中的應用程式
K8S 容器調度管理平台改版速度非常快速，那麼管理人員該如何判斷新增服務是否適合企業及組織使用？ 一般來說各種新增功能的步調會是先推出「Alpha」版本，待後續推出新版 K8S 版本時視功能成熟度轉換為「Beta」版本，最後則是變成「GA」穩定版本並成為 K8S 的正式功能。
早期的 K8S 版本與其它大部分的容器調度管理平台相同，「僅」能管理 Linux 容器運作環境。然而，從 K8S 1.05 版本開始，便能夠「同時」支援 Windows 及 Linux 容器運作環境。下列項目，為 2018 年最新發佈的 K8S 1.10 版本容器調度管理平台特色功能簡介：
- 儲存： 在前一版 K8S 1.09 版本時，推出的「容器儲存介面」（Container Storage Interface，CSI）及「本機持續性磁碟區」（Local Persistent Volumes）這 2 項儲存功能為「Alpha」版本，在最新 K8S 1.10 版本中皆更新為較成熟的「Beta」版本。其中，CSI 容器儲存介面可以讓安裝 Volume Plugins 的動作就像部署 Pod 一樣簡單，並且在預設的情況下便會啟用此功能，而無須像 K8S 1.09 版本必須管理人員手動啟用此功能，至於持續性本機磁碟區機制，則是幫助管理人員輕鬆讓主機的本機磁碟區成為持續性的儲存資源供容器使用。CSI 容器儲存介面功能，預計在後續的 K8S 1.12 版本時將會成為 GA 正式版本。
- 安全： 從 K8S 1.09 版本開始，提供 CCM（Cloud Controller Manager）特色功能（如圖 4 所示），在新版 K8S 1.10 版本中則提供「外部 kubectl 憑證提供者」的「Alpha」版本功能，以便使用雲端供應商提供的 IAM 身分驗證服務。
- 網路： 提供在安裝程序中，將 DNS 服務切換為「CoreDNS」的「Alpha」版本功能。
- 其它： 從 K8S 1.10 版本開始，將「持續性磁碟區宣告」（Persistent Volume Claim，PVC）更新為 Beta 版本，以便避免儲存資源因為被綁定在 Pod 中而被誤刪的情況發生。同時，在 K8S 1.10 版本中也推出新增功能 Local raw block volumes 的 Alpha 版本。
圖 4、Kubernetes - CCM（Cloud Controller Manager）運作架構示意圖
此外，在 2016 年時 Docker 將 Runtime 主要運作元件 Containerd 以開源的方式釋出。在 2018 年 5 月時，K8S 也正式支援最新釋出的 Containerd 1.1 版本，讓 Kubelet 能夠直接與 Containerd 溝通與協同運作（如圖 5 所示），有效改善 Pod 運作效能及降低啟動延遲。
圖 5、Kubernetes 正式支援 Containerd 1.1 版本運作示意圖
Kubernetes 叢集運作架構
首先，在 K8S（Kubernetes）叢集運作架構中，有 ２ 種運作角色分別是「Kubernetes Master」及「Kubernetes Nodes」（如圖 6 所示），其中擔任 Master 角色的 Kubernetes 主機，將會負責協調 Kubernetes 叢集中所有管理工作任務，例如，調度應用程式、維護應用程式的期望狀態、擴充應用程式運作規模、執行滾動式更新作業……等。至於擔任 Nodes 角色的 Kubernetes 主機，除了可以採用實體伺服器或 VM 虛擬主機之外，最主要的工作任務就是負責「運作容器」，並且都會有 Kubelet 管理程序及運作容器軟體（例如，Docker 或 rkt），同時透過代理程式及 Kubernetes API 與擔任 Master 角色的 Kubernetes 主機溝通。
在 Kubernetes 叢集運作架構中，擔任 Nodes 角色的 Kubernetes 節點主機數量，建議至少應配置「3 台」為佳。
圖 6、Kubernetes 叢集運作架構示意圖
那麼，我們來看看在 Kubernetes 叢集運作架構中，主要負責溝通協調及調度管理重任的 Kubernetes Master 主機（如圖 7 所示），以及專責運作「容器和應用程式」的 Kubernetes Node 節點主機中，分別運作哪些重要的運作元件：
Kubernetes Master
- kube-apiserver： 在 Kubernetes 叢集中負責驗證及 API 的控制平台前端，主要用途為提供 Kubernetes API 與 Kubernetes Nodes 節點主機溝通運作，以及進行運作規模「水平擴充」（Scale-Out）等工作任務。
- etcd： 在 Kubernetes 叢集中，負責處理及存放所有資料的儲存資源。
- kube-scheduler： 負責監控和調度及管理 Kubernetes Node 節點主機中的 Pod 等工作任務。
- kube-controller-manager： 負責管理在 Kubernetes 叢集中各項控制器的協同運作，例如，Node Controller、Replication Controller、Endpoints Controller、Service Account & Token Controller 等。
- cloud-controller-manager： 這是從 K8S 1.06 版本開始新增的 Alpha 運作元件，以便 Kubernetes 叢集能夠與各家雲端供應商提供的控制器協同運作，例如，Node Controller、Route Controller、Service Controller、Volume Controller 等。
Kubernetes Node
- kubelet： 每台 Kubernetes Node 節點主機皆會運作此代理程式，並且在 Kubernetes 叢集中的最小單位 Pod 中運作容器及應用程式。
- kube-proxy： 當 Kubernetes Node 節點主機順利建立 Pod 並運作容器和應用程式後，接著便是透過 kube-proxy 處理網路環境進而對外提供「服務」（Service）。
- container runtime： 在 Kubernetes Node 節點主機中負責運作容器的軟體，目前 Kubernetes 支援 Docker、rkt、runc 及符合 OCI runtime-spec 規範的容器技術。
圖 7、Kubernetes 叢集運作元件架構示意圖
Kubernetes 叢集實戰
事實上，在目前的 Windows Server 2016 運作環境中，倘若要建置 Kubernetes 叢集仍然相對複雜，舉例來說，必須要採用 Windows Server 2016（1709 版本），才能夠支援運作 Kubernetes 1.09 版本。此外，雖然 Kubernetes 叢集可以同時運作及管理 Windows 和 Linux 容器，但是擔任 Kubernetes Master 角色的主機，目前仍然「僅支援 Linux 作業系統」進行建構及運作相關元件的工作任務。
請注意，Windows Server 2016 RTM 為 1607 版本，並未支援建構 Kubernetes 1.09 叢集環境。此外，微軟預計在 2018 下半年度推出 Windows Server 2019 雲端作業系統，將會對於 Kubernetes 叢集環境有更高的支援度及整合度。因此，本文為避免 Kubernetes 初學者，在建構 Kubernetes 叢集環境時便遭遇太大的困難，所以本文實作環境將在 Microsoft Azure 公有雲環境，透過 AKS（Azure Kubernetes Service）機制快速建構 Kubernetes 叢集環境，並且建立 Pod 並運作容器和應用程式。
事實上，微軟 Azure 公有雲一開始推出的容器服務為 ACS（Azure Container Service），並同時支援 Docker Swarm、Mesosphere DC/OS、Kubernetes 等多種容器管理調度平台。然而，容器管理調度平台已經大勢底定以 Kubernetes 為首選，所以在 2017 年 10 月微軟將 ACS 容器服務，改名為 AKS 並專注於 Kubernetes 管理平台。
啟用 AKS 預覽功能
在本文撰寫階段微軟 Azure 公有雲中，專注於 Kubernetes 叢集的 AKS（Azure Kubernetes Service）服務仍處於「預覽」（Preview）階段。因此，管理人員在建立 Kubernetes 叢集之前，請先透過 Azure Cloud Shell 或 Azure CLI 執行啟用「Azure 服務提供者」（Azure Service Providers）的動作，以便啟用 AKS 預覽機制。Microsoft AKS 於 2018 年 6 月 13 日正式 GA，詳細資訊請參考 Azure Kubernetes Service (AKS) GA – New regions, more features, increased productivity | Blog | Microsoft Azure。
如圖 8 所示，請透過「az provider register」指令啟用相關 Azure 服務提供者，以便順利啟用 AKS 預覽機制，後續才能夠快速且順利的建構 Kubernetes 叢集架構。
圖 8、執行 az provider register 指令啟用相關 Azure 服務提供者
建立資源群組
請執行「az group create」指令，在 Microsoft Azure 公有雲環境中建立「資源群組」（Resource Group）。值得注意的是，由於目前的 AKS 服務仍處於預覽階段，所以全球只有部分的資料中心支援此服務，目前僅加拿大中部（canadacentral）、加拿大東部（canadaeast）、美國中部（centralus）、美國東部（eastus）、西歐（westeurope）等五座資料中心支援 AKS 預覽服務。如圖 9 所示，執行「az group create --name RG-USEast --location eastus」指令後，將會指定在「美國東部」（eastus）的資料中心內，建立名稱為「RG-USEast」的資源群組。
圖 9、指定在美國東部資料中心內建立名稱為 RG-USEast 的資源群組
建立 Kubernetes 叢集
請執行「az aks create」指令以便建立 Kubernetes 叢集，在下列所執行的「az aks create --resource-group RG-USEast --name K8SCluster --node-count 3 --generate-ssh-keys」指令中，將會在剛才於美國東部資料中心內所建立的 RG-USEast 資源群組中，建立名稱為「K8SCluster」的 Kubernetes 叢集。此外，在這個 Kubernetes 叢集當中，將會建立「1 台」擔任管理和調度角色的 Kubernetes Master 主機，以及建立「3 台」擔任運作容器和應用程式角色的 Kubernetes Node 節點主機（如圖 10 所示）。
在本次實作環境中，執行建立指令約 15 分鐘後 Kubernetes 叢集便建立完成。
圖 10、建立具備 1 台 Master 主機及 3 台 Node 節點主機的 Kubernetes 叢集
連線至 Kubernetes 叢集
現在，管理人員可以開始透過 kubectl 這個 Kubernetes 用戶端指令來管理 Kubenetes 叢集。首先，請執行「az aks get-credentials」指令以便下載憑證並組態設定 Kubernetes CLI 以便使用，在下列所執行的「az aks get-credentials --resource-group RG-USEast --name K8SCluster」指令中，將會於美國東部資料中心內 RG-USEast 資源群組中，所建立的 K8SCluster 的 Kubernetes 叢集下載憑證。倘若，未正確下載驗證 Kubernetes 叢集憑證的話，屆時嘗試查詢 Kubernetes 叢集節點主機資訊時，將會出現 Unable to connect to the server 及 no such host 的錯誤資訊。
順利通過 Kubernetes 叢集驗證程序後，便可以執行「kubectl get nodes」指令，列出 Kubernetes 叢集中 Node 節點主機資訊。如圖 11 所示，可以看到在 Kubernetes 叢集共有 3 台 Node 節點主機，並且採用 K8S v1.9.6 版本。
倘若，採用的 Azure CLI 指令工具無法順利執行 kubectl 指令，請執行「az aks install-cli」指令進行安裝即可。
圖 11、下載 Kubernetes 叢集驗證用途的憑證後，接著查詢 Node 節點主機資訊
新增 Kubernetes 部署和服務
在 Kubernetes 叢集運作架構中，建立容器與執行應用程式的方式與管理 Docker 容器大同小異。在本文實作環境中，我們將會先建立 1 個名稱為「azure-vote.yaml」的資訊清單檔案，在這個 YAML 檔案中將會定義使用的容器及相關物件，在「Kubernetes 部署」（K8S Deployments）的部份將會部署 2 個，首先是用於投票用途的 Python 應用程式，另 1 個則是快取用途的 Redis 執行個體。Kubernetes 部署的部分宣告完畢後，接著在「Kubernetes 服務」（K8S Services）的部份也是 2 個，首先是負責外部服務投票用途的 Python 應用程式為前端（服務名稱為 azure-vote-front），至於快取用途的 Redis 執行個體則會後端（服務名稱為 azure-vote-back）。
下列為 azure-vote.yaml 檔案內容，詳細資訊請參考 Quickstart - Azure Kubernetes cluster for Linux | Microsoft Docs 官方文件內容。
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: azure-vote-back
spec:
replicas: 1
template:
metadata:
labels:
app: azure-vote-back
spec:
containers:
- name: azure-vote-back
image: redis
ports:
- containerPort: 6379
name: redis
---
apiVersion: v1
kind: Service
metadata:
name: azure-vote-back
spec:
ports:
- port: 6379
selector:
app: azure-vote-back
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: azure-vote-front
spec:
replicas: 1
template:
metadata:
labels:
app: azure-vote-front
spec:
containers:
- name: azure-vote-front
image: microsoft/azure-vote-front:v1
ports:
- containerPort: 80
env:
- name: REDIS
value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
name: azure-vote-front
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-vote-front完成 azure-vote.yaml 資訊清單檔案的編寫作業後，便可以執行「kubectl apply -f azure-vote.yaml」指令採用剛才定義的 azure-vote.yaml 檔案，進行 Kubernetes 部署及新增服務的工作任務。如圖 12 所示，可以看到 Kubernetes 叢集順利新增 2 項 Kubernetes 部署及 Kubernetes 服務，名稱分別是 azure-vote.yaml 資訊清單檔案內，所定義的 azure-vote-front 及 azure-vote-back。
圖 12、Kubernetes 叢集順利新增 2 項 Kubernetes 部署及 Kubernetes 服務
負責外部服務的前端 Python 應用程式建立後，我們可以執行「kubectl get service azure-vote-front --watch」指令，來即時觀察前端 Python 應用程式的運作狀態。一開始執行時，可以看到負責外部服務的 IP 位址欄位「EXTERNAL-IP」狀態為「pending」（如圖 13 所示），表示此時 Kubernetes 叢集仍在初始化 azure-vote-front 服務中，稍待片刻便可以看到欄位狀態轉變為「外部 IP 位址」（本文實作環境為 40.121.14.165）。
當 azure-vote-front 前端服務順利初始化完成取得外部 IP 位址之後，便可以使用「Ctrl + C」組合鍵中斷即時監看狀態。
圖 13、確認前端 Python 應用程式的運作狀態，是否已經能夠對外提供服務
此時，便可以開啟瀏覽器鍵入剛才前端 Python 應用程式的外部 IP 位址，來驗證範例用途的投票應用程式是否已經能夠對外提供服務。如圖 14 所示，皆可以順利執行投票作業並且重置投票結果。
圖 14、透過瀏覽器驗證範例用途的投票應用程式是否已經能夠對外提供服務
擴充和縮小運作規模
隨著時間的推移，企業及組織在 Kubernetes 叢集中所建立及運作的容器和應用程式，有可能需要因為專案需求或其它因素而擴充或縮小運作規模，Kubernetes 叢集提供非常簡便且線上不中斷的方式，讓管理人員可以隨時擴充或縮小 Node 節點主機數量，或者是運作容器及應用程式的 Pods 數量。舉例來說，在本文的實作環境中 Kubernetes 叢集內有「3 台」Node 節點主機，管理人員可以透過「az aks scale --resource-group RG-USEast --name K8SCluster --node-count 8」指令，將 Kubernetes 叢集內原有的 Node 節點主機，擴充為「8台」節點主機的運作規模，完成後再次執行「kubectl get nodes」指令查詢 Kubernetes 叢集中 Node 節點主機資訊（如圖 15 所示）。
倘若，需要縮小 Node 節點主機運作規模，只需要調整「--node-count」參數的數值即可。
圖 15、擴充 Kubernetes 叢集 Node 節點主機的運作規模
除了擴充及縮小 Kubernetes 叢集中 Node 節點主機運作規模之外，也支援擴充和縮小運作容器和應用程式的 Pod 。舉例來說，剛才所部署的 azure-vote-front 前端及 azure-vote-back 後端，都只有「1 個 Pod」而已，同樣的管理人員可以透過「kubectl scale --replicas=5 deployment/azure-vote-front」指令，將 Pod 數量由原本的 1 個擴充為「5 個Pod」，完成後再次執行「kubectl get pods」指令查詢 Kubernetes 叢集中 Pod 資訊（如圖 16 所示）。
倘若，需要縮小 Pod 運作規模，只需要調整「--replicas」參數的數值即可。
圖 16、擴充 Kubernetes 叢集 Pod 的運作規模
除了管理人員手動調整 Pod 的運作規模之外，Kubernetes 叢集還支援根據資源使用量，例如，CPU 使用率達到指定的門檻值後「自動」擴充 Pod 的運作規模。舉例來說，管理人員可以透過「kubectl autoscale deployment azure-vote-front --cpu-percent=50 --min=3 --max=10」指令，指定當 CPU 使用率「超過 50%」時，Kubernetes 叢集便自動擴充 Pod 的運作規模最多新增至「10 個 Pod」，倘若沒什麼工作負載時 Kubernetes 叢集便縮小 Pod 的運作規模最小至「3 個 Pod」。
如圖 17 所示，可以看到剛才手動擴充 Pod 的運作規模至「5 個 Pod」，然而組態設定自動調整 Pod 運作規模機制後，透過「kubectl get hpa」指令可以看到，因為 CPU 工作負載低於 50% 的門檻值，所以 Kubernetes 叢集便自動縮小 Pod 運作規模至最小的「3 個 Pod」。
圖 17、組態設定 Kubernetes 叢集自動調整 Pod 的運作規模
Kubernetes 儀表板
至此，我們已經成功建構 Kubernetes 叢集運作環境，並且部署容器及範例用途的投票應用程式。最後，管理人員可以透過 Kubernetes 叢集內建提供的儀表板功能，輕鬆監控 Kubernetes 叢集各項運作元件及容器的健康情況。請執行「az aks browse --resource-group RG-USEast --name K8SCluster」指令，那麼系統便會在 CLI 主機與 Kubernetes API 之間建立 Proxy（如圖 18 所示）。
圖 18、執行 CLI 主機與 Kubernetes API 之間建立 Proxy 的動作
如圖 19 所示，系統將會自動開啟 CLI 主機的瀏覽器後，透過與 Kubernetes API 之間建立的 Proxy 連結至 Kubernetes 儀表板。除了透過 Kubernetes 儀表板監看 Kubernetes 叢集工作負載，例如，Kubernetes 部署、Kubernetes 服務、Pods、Replica Sets……等，也可以透過 Kubernetes 儀表板部署容器及應用程式。
圖 19、透過 Kubernetes 儀表板監看 Kubernetes 叢集工作負載