Kubernetes 應用佈署的核心在於妥善管理 Deployment、Service 和 PersistentVolumeClaim 等資源。Deployment 定義應用規格，例如容器映像、副本數量和資源限制，並透過 ReplicaSet 維護期望狀態。Service 則負責網路組態，提供穩定的 IP 和 DNS 名稱，實作負載平衡和高用性。PersistentVolumeClaim 則讓應用程式能掛載持久化儲存，確保資料的長期儲存。kubectl 工具提供命令列介面，讓開發者能操作 Kubernetes 資源，包含建立、描述、編輯和刪除等功能。YAML 檔案則以宣告式方式定義資源規格，讓組態更具彈性且易於版本控制。然而，Kubernetes 資源種類別繁多，需要深入理解才能正確組態。命令式和宣告式組態各有優劣，而直接修改線上資源容易造成本地與線上狀態不一致，增加管理複雜度。
Kubernetes 佈署應用
佈署應用程式到 Kubernetes 是一個多步驟的過程，其中最基礎的資源是 Deployment。Deployment 是 Kubernetes 中用來定義和管理應用程式佈署的資源。以下是對 Deployment 的詳細介紹及其相關概念。
Deployment 資源
Deployment 是 Kubernetes 中最基本的資源之一，它定義了應用程式的佈署細節，包括要使用的容器映像、副本數量、資源限制、健康檢查和卷掛載等。當建立一個 Deployment 時，Kubernetes 會自動生成一個中間資源，稱為 ReplicaSet，它負責確保應用程式的副本數量符合所設定的期望狀態。
容器映像
容器映像可以在本地工作站上使用 Docker 或 Jib 等工具構建，也可以直接在 Kubernetes 上使用 Kaniko 構建。由於 Kubernetes 沒有提供原生的 API 端點來構建容器映像，因此不會詳細討論容器映像的構建過程。
副本數量
Deployment 中的 replicas 欄位定義了應用程式的副本數量。Kubernetes 會根據這個欄位建立相應數量的 Pod，並確保這些 Pod 都處於執行狀態。
Pod
Pod 是 Kubernetes 中最小的佈署單位，它封裝了一個或多個容器。Pod 中的容器分享相同的網路和儲存資源，因此可以緊密協作。
資源限制和健康檢查
Deployment 還可以定義應用程式的資源限制（如 CPU 和記憶體）和健康檢查（如 liveness probe 和 readiness probe），以確保應用程式在預期範圍內執行並能夠正常回應請求。
Service 資源
而 Deployment 處理的是應用程式的佈署細節，Service 則負責組態網路元件，以便讓應用程式能夠被外界存取。Service 提供了一個穩定的 IP 地址和 DNS 名稱，並將流量分配到多個 Pod 上，從而實作負載平衡和高用性。
Service 的工作原理
Service 透過分配一個穩定的 IP 地址來實作負載平衡。當外部流量進來時，Service 會將其路由到相應的 Pod 上，從而實作高用性和負載平衡。以下是一個使用 Service 的架構示意圖：
graph TD
A[Client] --> B[Service]
B --> C[Pod1]
B --> D[Pod2]
B --> E[Pod3]
此圖示顯示了 Service 在客戶端和 Pod 之間提供負載平衡的功能。
PersistentVolumeClaim 資源
在微服務架構中，應用程式通常需要維持狀態以便於長期儲存資料。為了滿足這一需求，Kubernetes 提供了 PersistentVolume 和 PersistentVolumeClaim 資源來抽象化儲存細節。
PersistentVolumeClaim 的作用
PersistentVolumeClaim 是用來申請持久化儲存資源的一種方式。Kubernetes 操作員可以透過組態 StorageClass 來動態分配持久化儲存資源。PersistentVolume 則包含了所有必要的儲存細節，包括儲存型別（如 NFS、iSCSI 或雲端提供者）和儲存大小。
以下是一個使用 PersistentVolumeClaim 的架構示意圖：
graph TD
A[Pod] --> B[PersistentVolume]
B --> C[StorageClass]
此圖示展示了 Pod 如何透過 PersistentVolumeClaim 來掛載持久化儲存資源。
kubectl 工具
為了與 Kubernetes API 進行互動並建立這些資源，我們使用 kubectl 命令列工具。kubectl 提供了一系列子命令來操作 Kubernetes 資源，這些子命令包括 create、describe、edit 和 delete。
命令格式
kubectl 的命令格式如下：
kubectl <verb> <noun> <arguments>
其中 verb 是子命令名稱，noun 是要操作的 Kubernetes 資源型別。
建立 Deployment
以下是使用 kubectl 建立 Deployment 的範例：
kubectl create deployment my-deployment --image=busybox
這條命令會指示 kubectl 與 Deployment API 息息以建立一個名為 my-deployment 的 Deployment，並使用 Docker Hub 上的 busybox 畫素。
描述 Deployment
要取得有關已建立 Deployment 的更多資訊，可以使用 describe 子命令：
kubectl describe deployment my-deployment
這條命令會檢索有關 my-deployment 的資訊並以可讀格式顯示。
編輯 Deployment
如果需要修改已存在的 Deployment，可以使用 edit 子命令：
kubectl edit deployment my-deployment
這條命令會開啟一個文字編輯器，允許你在原地修改 Deployment。
刪除 Deployment
要刪除一個 Deployment，可以使用 delete 子命令：
kubectl delete deployment my-deployment
這條命令會指示 API刪除名為 my-deployment 的 Deployment。
YAML 資原始檔
Kubernetes 資源一旦建立便存在於叢集中作為 JSON 資原始檔，可將其匯出為 YAML 檔案以增加可讀性。以下是一個 Deployment 資原始檔範例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
spec:
replicas: 1
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
spec:
containers:
- name: main
image: busybox
args:
- sleep
- infinity
名稱空間考量與技術選擇
在選擇技術方案時需考慮專案規模、團隊專業知識及未來擴充套件性等因素。若面對大型專案則考慮選擇更成熟且穩定性更高且靈活度更強之工具或框架。反之若專案規模較小則可選擇較簡單易上手之工具或框架以快速達成目標且降低學習成本。
健康檢查與盯查技術方案改進點分析
若發現某些健康檢查機制未能正確執行則需回頭重新評估設計思維及健康檢查策略。適時調整健康檢查機制並引入更先進之監控與警示系統能夠提升系統穩定性與即時性。 此外能夠增加自我修復機制能夠減少人力干預增加系統自動化程度及維運效率。 以上所述內容為玄貓針對 Kubernetes 應用佈署之技術深度分析與具體技術例項結合台灣本土科技社群語境之內容創作重構。 玄貓希望此份內容能夠對各位工作者帶來啟發與幫助且持續改進技術知識與技能。
Kubernetes 與 Helm 的理解
在之前的 YAML 格式中，我們展示了一個非常基本的使用案例。它佈署了來自 Docker Hub 的 busybox 映像，並無限期地執行 sleep 命令以保持 Pod 的執行狀態。雖然使用 kubectl 子命令來命令式地建立資源可能更為簡單，但 Kubernetes 允許我們以宣告式的方式直接管理 YAML 資源，以獲得更多對資源建立的控制權。kubectl 子命令並不總是讓我們組態所有可能的資源選項，但直接建立 YAML 檔案允許我們更靈活地建立資源並填補 kubectl 子命令可能包含的空缺。
宣告式組態
在宣告式組態中，使用者首先以 YAML 格式撰寫他們想要建立的資源。然後，他們使用 kubectl 工具將該資源應用到 Kubernetes API。雖然在命令式組態中開發者使用 kubectl 子命令來管理資源，但宣告式組態主要依賴於一個子命令—apply。
宣告式組態通常採取以下形式：
kubectl apply -f my-deployment.yaml
此命令向 Kubernetes 提供了一個包含資源規範的 YAML 資源，儘管也可以使用 JSON 格式。Kubernetes 根據資源是否存在來推斷要對資源執行的操作（建立或修改）。
宣告式組態的步驟
應用程式可以透過以下步驟進行宣告式組態：
- 首先，使用者可以建立一個名為
deployment.yaml的檔案，並為佈署提供一個 YAML 格式的規範。我們將使用之前相同的示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
spec:
replicas: 1
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
spec:
containers:
- name: main
image: busybox
args:
- sleep
- infinity
- 接著，可以使用以下命令建立佈署：
kubectl apply -f deployment.yaml
執行此命令後，Kubernetes 會嘗試根據你指定的方式建立佈署。
- 若要對佈署進行更改，例如將副本數量更改為 2，則首先需要修改
deployment.yaml檔案：
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
spec:
replicas: 2
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
spec:
containers:
- name: main
image: busybox
args:
- sleep
- infinity
- 則再應用該更改：
kubectl apply -f deployment.yaml
執行該命令後，Kubernetes 將應用所提供的佈署宣告覆寫之前應用的佈署。此時，應用程式將從副本值 1 擴充套件到 2。
- 在刪除應用程式時，Kubernetes 說明檔案實際上建議以命令式方式進行；即使用
delete子命令而不是apply：
kubectl delete -f deployment.yaml
delete子命令可以透過傳入-f標誌和檔名來使其更具宣告性。這使得kubectl得知在特設定檔案中宣告的要刪除的資源名稱，並允許開發者繼續使用宣告式 YAML 檔案來管理資源。
資源組態挑戰
在前面的部分中，我們介紹了 Kubernetes 有兩種不同的組態方法：命令式和宣告式。然而，當我們使用這些方法來建立 Kubernetes 資源時會遇到哪些挑戰呢？讓我們討論一些最常見的挑戰。
Kubernetes 資源型別繁多
首先，Kubernetes 中有許多不同型別的資源。以下是開發者應該瞭解的一些資源：
- Deployment（佈署）
- StatefulSet（有狀態集）
- Service（服務）
- Ingress（入口）
- ConfigMap（組態對映）
- Secret（秘密）
- StorageClass（儲存類別）
- PersistentVolumeClaim（持久性儲存區申請）
- ServiceAccount（服務帳戶）
- Role（角色）
- RoleBinding（角色繫結）
- Namespace（名稱空間）
從本質上講，在 Kubernetes 上佈署應用程式並不簡單如按下一個大紅按鈕標記為「佈署」。開發者需要能夠確定哪些資源是必需的才能佈署他們的應用程式，並且他們需要深入瞭解這些資源以便能夠正確地組態它們。這需要對平台有大量的知識和培訓。
認知與現有狀態的一致性
玄貓建議一種組態 Kubernetes 資源的方法是將它們的組態儲存在來源控制中供團隊編輯和分享，這也允許來源控制儲存函式庫成為事實來源。在來源控制中定義的組態（稱為「本地狀態」）透過將它們應用到 Kubernetes環境中來建立它們並使其「實時」或進入所謂「實時狀態」。這聽起來簡單了吧？但當開發者需要對他們的資源進行更改時會發生什麼呢？正確答案是修改本地檔案並應用變更以將本地狀態同步到實時狀態從而更新事實來源。然而，這通常不是最終發生的事情。在短期內修改實時資源原地更為簡單；即使用 kubectl patch 或 kubectl edit 全部跳過修改本地檔案。這導致本地和實時狀態之間出現狀態不一致問題且使得在 Kubernetes 上擴充套件變得困難。
graph TD;
A[本地狀態] -->|同步| B[實時狀態];
B -->|修改| C[狀態不一致];
內容解密：
此圖示展示了本地狀態與實時狀態之間的一致性問題。本地狀態代表在來源控制中的組態檔案；當這些組態檔案被應用到 Kubernetes環境中時就轉化為實時狀態。然而，當開發者直接修改實時資源而不更新本地檔案時就會導致狀態不一致問題。
透過解決這些挑戰並理解 Kubernetes 的資源管理方法，開發者可以更高效且可靠地管理他們在 Kubernetes 上執行的應用程式。
