Kubernetes 佈署擴充套件是確保應用程式高用性和可擴充套件性的關鍵。本文探討了在資源受限的單節點 Kubernetes 環境下進行佈署擴充套件的挑戰。透過嘗試將佈署副本數量擴充套件至 90，觀察到節點資源耗盡導致的不穩定性，突顯了資源限制的重要性。使用 kubectl describe node 命令詳細分析了節點的資源狀態，包括 CPU、記憶體、磁碟和 Pod 容量，以及網路連線狀態。此外，還示範了使用 scale-deployment.sh 指令碼逐步擴充套件佈署，並搭配 kubectl get deployments 命令監控擴充套件過程，以及使用 kubectl describe node 命令觀察節點資源使用情況。最後，文章提出了未來改進方向，包括多節點叢集佈署、自動擴充套件機制和更精細的資源監控與管理策略，以提升 Kubernetes 叢集的穩定性和擴充套件性。
Kubernetes 佈署擴充套件的探討
在前面的章節中，我們已經初步瞭解了 Kubernetes（K8S）中的 ReplicaSet 以及其在確保應用程式高用性方面的重要性。現在，我們將更深入地探討 Kubernetes 中的佈署擴充套件（Scaling the Deployment），並且透過實際操作來觀察節點資源耗盡時的行為。
什麼是副本（Replicas）？
副本是指在任何給定的時間內，我們希望執行的容器映像例項的數量，以確保應用的可用性和可擴充套件性。在 Kubernetes 中，透過調整副本數量，可以實作應用的水平擴充套件。
檢視當前節點和 Pod 狀態
首先，我們來檢視當前叢集中的節點狀態。如以下輸出所示，我們的叢集中只有一個節點 wks01，並且它處於 Ready 狀態。
microk8s kubectl get nodes
NAME STATUS ROLES AGE VERSION
wks01 Ready <none> 136m v1.27.4
程式碼解密：
microk8s kubectl get nodes：這個命令用於取得叢集中所有節點的狀態。NAME、STATUS、ROLES、AGE和VERSION分別表示節點名稱、狀態、角色、存在時間和 Kubernetes 版本。
擴充套件佈署
現在，讓我們嘗試將佈署 mydeployment 的副本數量更新為 90，並觀察 Kubernetes 如何處理這個請求。
microk8s kubectl apply -f mydep-atscale.yaml
deployment.apps/mydeployment configured
程式碼解密：
microk8s kubectl apply -f mydep-atscale.yaml：這個命令用於應用mydep-atscale.yaml檔案中的組態，更新佈署mydeployment。deployment.apps/mydeployment configured：表示佈署已經成功更新。
更新後，我們檢查佈署的狀態：
microk8s kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
mydeployment 30/90 30 30 4h15m
程式碼解密：
microk8s kubectl get deployments：這個命令用於取得當前佈署的狀態。NAME、READY、UP-TO-DATE、AVAILABLE和AGE分別表示佈署名稱、準備就緒的副本數、更新完成的副本數、可用的副本數和佈署存在時間。30/90表示當前只有 30 個副本處於準備就緒狀態，而我們請求的是 90 個副本。
資源限制與節點穩定性
在我們的實驗環境中，由於只有一個虛擬機器（VM），並且其資源有限（2GB 記憶體），當我們嘗試擴充套件到 90 個副本時，節點很快就變得不穩定，最終不得不重啟 VM。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title Kubernetes 佈署擴充套件探討
package "Kubernetes Cluster" {
package "Control Plane" {
component [API Server] as api
component [Controller Manager] as cm
component [Scheduler] as sched
database [etcd] as etcd
}
package "Worker Nodes" {
component [Kubelet] as kubelet
component [Kube-proxy] as proxy
package "Pods" {
component [Container 1] as c1
component [Container 2] as c2
}
}
}
api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2
note right of api
核心 API 入口
所有操作經由此處
end note
@enduml圖表翻譯： 此圖示展示了當我們請求擴充套件到 90 個副本時，Kubernetes 的排程過程以及最終導致節點資源耗盡和不穩定的過程。
內容解密：
- 開始擴充套件：我們請求將佈署擴充套件到 90 個副本。
- Kubernetes 排程：Kubernetes 嘗試排程這些副本到可用的節點上。
- 資源耗盡：由於節點資源有限，很快就被耗盡。
- 節點不穩定：資源耗盡導致節點變得不穩定。
自動擴充套件指令碼
為了更系統地觀察叢集在擴充套件過程中的行為，我們編寫了一個簡單的 bash 指令碼 scale-deployment.sh，每隔 30 秒增加一個副本。
#!/bin/bash
num=1
while [ $num -gt 0 ]
do
microk8s kubectl scale deployment --replicas $num mydeployment
echo "deployment scale = $num"
date
echo "sleeping for 30 seconds, on another terminal watch deployment being scaled"
sleep 30
num=`expr $num + 1`
done
程式碼解密：
while [ $num -gt 0 ]：迴圈條件，只要num大於 0 就繼續執行。microk8s kubectl scale deployment --replicas $num mydeployment：動態調整佈署mydeployment的副本數量為num。sleep 30：每隔 30 秒執行一次擴充套件操作。
觀察節點資源使用情況
在執行擴充套件指令碼的同時，我們開啟另一個終端視窗，使用 microk8s kubectl describe node 命令來觀察節點的資源使用情況。
microk8s kubectl describe node
Name: wks01
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
程式碼解密：
microk8s kubectl describe node：用於取得節點的詳細資訊。Name、Roles、Labels等欄位提供了節點的基本資訊和標籤。
未來工作與改進方向
- 多節點叢集佈署：在多節點叢集中進行佈署擴充套件，以提高資源利用率和應用可用性。
- 自動擴充套件機制：利用 Kubernetes 的自動擴充套件功能，根據實際負載動態調整副本數量。
- 資源監控與管理：加強對節點資源的監控和管理，及時發現並解決資源瓶頸問題。
透過這些改進，我們可以進一步提升 Kubernetes 叢集的穩定性和擴充套件性，為應用提供更強大的支援。
參考資料
- Kubernetes 官方檔案：https://kubernetes.io/docs/
- Kubernetes 叢集管理：https://kubernetes.io/docs/tasks/administer-cluster/
本章內容到此結束，感謝您的閱讀。希望透過本章的學習，您能夠對 Kubernetes 中的佈署擴充套件有更深入的瞭解。
Kubernetes 叢集擴充套件實戰：深入剖析 Deployment 擴充套件過程
在現代雲原生應用中，Kubernetes 已成為事實上的容器協調標準。其中，Deployment 資源是管理應用佈署的核心元件。本文將探討 Kubernetes Deployment 的擴充套件機制，並透過實際案例分析其運作細節。
節點健康狀態檢查
在進行 Deployment 擴充套件之前，檢查節點健康狀態是必要的第一步。透過 kubectl describe node 命令，我們可以取得節點的詳細資訊：
shiva@wks01:~$ microk8s kubectl describe node wks01
節點資訊解析
Name: wks01
Labels:
kubernetes.io/hostname=wks01
kubernetes.io/os=linux
microk8s.io/cluster=true
node.kubernetes.io/microk8s-controlplane=microk8s-controlplane
Annotations:
node.alpha.kubernetes.io/ttl: 0
projectcalico.org/IPv4Address: 192.168.0.209/24
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Thu, 31 Aug 2023 16:19:53 +0000
Taints: <none>
Unschedulable: false
內容解密：
此段輸出顯示了節點的基本資訊，包括：
- 節點標籤：標識節點的主機名稱、作業系統和叢集歸屬
- 註解資訊：包含網路組態和儲存管理相關的後設資料
- 建立時間戳：節點加入叢集的時間
Taints狀態：目前無任何汙點，表示節點可正常排程
節點資源狀態分析
進一步檢視節點的資源狀態：
Conditions:
Type Status LastHeartbeatTime Reason Message
---
-
---
---
---
-
---
-
---
-
---
---
---
---
---
-
---
NetworkUnavailable False Thu, 31 Aug 2023 16:54:01 CalicoIsUp Calico is running on this node
MemoryPressure False Thu, 31 Aug 2023 20:59:30 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Thu, 31 Aug 2023 20:59:30 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Thu, 31 Aug 2023 20:59:30 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Thu, 31 Aug 2023 20:59:30 KubeletReady kubelet is posting ready status. AppArmor enabled
內容解密：
節點狀態檢查結果表明：
- 網路狀態正常：Calico 網路元件運作正常
- 資源充足：記憶體、磁碟和 PID 資源均未出現壓力
Ready狀態：節點已準備好接受新的工作負載- Kubelet 狀態：Kubelet 運作正常並啟用 AppArmor
資源容量與可分配資源
檢視節點的資源容量：
Capacity:
cpu: 2
ephemeral-storage: 38905184Ki
memory: 2010852Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 37856608Ki
memory: 1908452Ki
pods: 110
內容解密：
資源組態詳情：
- 總容量：2 核心 CPU、約 1.9GB 可用記憶體
- 可分配資源：扣除系統預留資源後的可用量
- Pod 容量：節點最多可執行 110 個 Pod
Deployment 擴充套件實戰
擴充套件過程監控
透過 scale-deployment.sh 指令碼持續擴充套件 Deployment：
shiva@ubuntu2004-02:~$ microk8s kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
dep-webserver 1/1 1 1 72d
mydeployment 38/39 38 38 6d15h
內容解密：
擴充套件結果顯示：
mydeployment已擴充套件至 38 個副本，接近目標值 39dep-webserver保持單一副本穩定執行- 年齡資訊：顯示 Deployment 的執行時間
詳細佈署資訊分析
進一步檢視 mydeployment 的詳細資訊：
Name: mydeployment
Namespace: default
Replicas: 60 desired | 59 updated | 59 total | 59 available | 0 unavailable
StrategyType: RollingUpdate
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=label-nginx
Containers:
name-nginx:
Image: local/mynginx:01
Port: 80/TCP
內容解密：
佈署策略詳解：
- 期望狀態：60 個副本
- 更新策略：滾動更新，最大不可用/激增比例均為 25%
- 容器組態：使用
local/mynginx:01映像，暴露 80 埠
效能監控與觀察
在擴充套件過程中，叢集表現出一定的延遲：
deployment.apps/mydeployment scaled
deployment scale = 270
Thu Aug 31 09:10:58 PM UTC 2023
sleeping for 30 seconds, on another terminal watch deployment being scaled
deployment.apps/mydeployment scaled
deployment scale = 271
內容解密：
擴充套件過程觀察：
擴充套件速度：逐漸增加副本數量
間隔控制：每 30 秒調整一次規模
叢集反應：觀察到叢集在高負載下的反應
自動擴充套件機制：研究根據 HPA 的動態擴充套件方案
效能最佳化：探索更高效的資源排程策略
高可用性架構：設計多維度的高可用性解決方案
透過持續最佳化和改進，我們可以構建更穩定、高效的 Kubernetes 叢集環境。
