Kubernetes 佈署檔案以 YAML 格式定義叢集狀態，確保應用程式與網路設定維持一致性。本文以一個簡易服務範例 mysvc01.yaml 說明如何定義服務名稱、連線埠、型別和選擇器等關鍵設定，並透過 kubectl apply 指令佈署至叢集。佈署後，可使用 kubectl get service 檢視服務狀態，並透過 kubectl describe service 檢視詳細組態，例如服務的 Endpoints 和 Selector。此外，本文也示範如何使用 curl 測試服務連通性，並驗證 Kubernetes 的自動化管理機制，例如在刪除 Pod 後 Kubernetes 會自動重建以維持期望狀態。最後，文章提供進階的 Kubernetes 設定檔解析與操作實務，包含 TLS 連線資訊解析、設定檔結構說明以及 Context 操作應用，例如檢視、重新命名和列出所有可用的 Contexts。
Kubernetes 佈署檔案與自動化管理詳解
在 Kubernetes（K8S）叢集中，佈署檔案（Deployment Files）扮演著至關重要的角色，它們負責定義叢集的期望狀態，並確保系統自動維持這一狀態。本章節將探討如何撰寫 K8S 佈署檔案，以及如何利用這些檔案實作自動化管理。
佈署檔案（Deployment File）基礎
佈署檔案是用於定義 Kubernetes 資源的 YAML 或 JSON 檔案。這些檔案描述了我們希望叢集達到的狀態，包括應執行的應用程式、網路組態等關鍵資訊。
佈署檔案範例：mysvc01.yaml
apiVersion: v1
kind: Service
metadata:
name: "myservice"
spec:
ports:
- port: 80
targetPort: 80
type: LoadBalancer
selector:
app: "label-nginx"
內容解密：
apiVersion和kind：所有 Kubernetes 資源定義檔案都需要這兩個欄位，分別指定了 Kubernetes API 版本和資源型別。metadata：提供資源的後設資料，如名稱、標籤等。在此範例中，我們將服務命名為myservice。spec：描述資源的期望狀態。對於服務（Service）資源，這裡定義了服務的連線埠、服務型別和選擇器。ports：定義服務暴露的連線埠以及對應的目標連線埠。type: LoadBalancer：指定服務型別為負載平衡器，用於將外部流量匯入叢集內部。selector：根據標籤選擇要關聯的 Pod。在此範例中，服務將流量導向標有app: label-nginx的 Pod。
建立與驗證 Kubernetes 服務
透過以下命令建立服務並驗證其狀態：
kubectl apply -f mysvc01.yaml
kubectl get service
輸出結果顯示 myservice 服務已成功建立並執行，服務型別為 LoadBalancer。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myservice LoadBalancer 10.152.183.214 <pending> 80:30331/TCP 21s
詳細檢視服務組態
使用 kubectl describe service myservice 命令可以檢視服務的詳細組態資訊。
Name: myservice
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=label-nginx
Type: LoadBalancer
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.152.183.214
IPs: 10.152.183.214
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 30331/TCP
Endpoints: 10.1.166.11:80
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
重點解析：
Selector: app=label-nginx：服務透過此選擇器與對應的 Pod 進行關聯。Endpoints: 10.1.166.11:80：顯示服務實際對應的終端點 IP 與連線埠。
測試服務連通性
使用 curl 命令測試服務是否可正常存取：
curl localhost:30331
輸出結果顯示服務執行正常，並傳回預期的網頁內容。
自動化管理的優勢
Kubernetes 的強大之處在於其自動化管理能力。透過定義佈署檔案，我們可以確保叢集狀態與期望狀態一致。例如，當刪除某個 Pod 時，Kubernetes 會自動重新建立新的 Pod 以維持預定的執行狀態。
驗證自動化管理
- 檢視當前執行的 Pod
kubectl get pods
NAME READY STATUS RESTARTS AGE
mydeployment-756d77bc56-trgjx 1/1 Running 0 9m29s
- 刪除指定的 Pod
kubectl delete pod mydeployment-756d77bc56-trgjx
- 再次檢視 Pod 狀態
kubectl get pods
NAME READY STATUS RESTARTS AGE
mydeployment-756d77bc56-j6gpq 1/1 Running 0 43s
結果顯示 Kubernetes 自動建立了新的 Pod 以維持期望狀態。
練習與進階挑戰
- 撰寫 Apache2/HTTPD 容器的佈署檔案：嘗試為 Apache2 或 HTTPD 容器撰寫對應的 Kubernetes 佈署檔案，並佈署至叢集中。
- 驗證服務執行狀態：使用
kubectl相關命令驗證服務是否正常執行，並測試其可存取性。
透過這些練習，可以進一步掌握 Kubernetes 佈署檔案的撰寫技巧，以及自動化管理的實務操作。
Kubernetes 深入解析
Kubernetes 叢集與驗證機制
Kubernetes 叢集是由多個元件組成的系統，主要包含管理平面（management plane）和資料平面（data plane）。管理平面提供了各種 API 介面，用於組態和控制叢集本身；資料平面則由節點和其他類別似結構組成，工作負載在這些節點上執行。
在與 Kubernetes 叢集互動之前，首先需要進行身份驗證。驗證機制確保只有授權使用者才能執行特定操作。在前面的章節中，我們直接與 microk8s 叢集互動，無需顯式驗證。接下來，我們將探討 Kubernetes 的驗證機制。
當前使用者與群組
首先，我們需要了解當前 Linux 使用者的身份。透過 whoami 和 id 命令，可以查詢當前使用者名稱和所屬群組，如下所示：
whoami
id
輸出結果：
shiva
uid=1000(shiva) gid=1000(shiva) groups=1000(shiva),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lxd),117(docker),998(microk8s)
連線至 Kubernetes 叢集
接下來，我們需要了解目前連線的 Kubernetes 叢集資訊。使用 microk8s kubectl config get-clusters 命令，可以列出當前組態的叢集：
microk8s kubectl config get-clusters
輸出結果：
NAME
microk8s-cluster
這表明我們目前連線的叢集名稱為 microk8s-cluster。使用 microk8s kubectl config current-context 命令，可以查詢目前使用的 context：
microk8s kubectl config current-context
輸出結果：
microk8s
Kubernetes 驗證機制
Kubernetes 採用微服務架構，各個服務之間透過 API 介面進行通訊。kubectl 命令列工具將使用者指令轉換為 API 請求，並傳送至 Kubernetes API 伺服器。
那麼，Kubernetes 如何驗證使用者身份？通常，API 服務會透過使用者名稱和 token 進行驗證。使用 microk8s config 命令，可以查詢叢集的組態資訊：
microk8s config
輸出結果（部分）：
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCg==
server: https://192.168.0.26:16443
name: microk8s-cluster
contexts:
- context:
cluster: microk8s-cluster
user: admin
name: microk8s
current-context: microk8s
kind: Config
preferences: {}
users:
- name: admin
user:
token: YktrYUZEMUYwT0h4NTlweVVjY21EQ3c0WXpialEzTFltMmVEZ1FPTGhKST0K
輸出結果顯示，Kubernetes API 伺服器執行在 https://192.168.0.26:16443，並使用 token 進行驗證。API endpoint 使用加密連線保護敏感資料。
驗證加密連線
使用 OpenSSL 命令，可以檢查 API endpoint 的加密引數：
openssl s_client -connect localhost:16443
輸出結果（部分）：
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = GB, ST = Canonical, L = Canonical, O = Canonical, OU = Canonical, CN = 127.0.0.1
verify error:num=20:unable to get local issuer certificate
verify return:1
內容解密：
以上命令和輸出結果表明，Kubernetes 叢集使用加密連線保護 API endpoint，並且使用 token 進行使用者驗證。microk8s config 命令輸出的組態資訊中，包含叢集名稱、使用者名稱和 token 等重要資訊。這些資訊對於理解 Kubernetes 叢集的驗證機制至關重要。
Kubernetes 叢集架構與驗證流程圖示
graph LR
A[Kubernetes 叢集] --> B[管理平面]
A --> C[資料平面]
B --> D[API 伺服器]
D --> E[使用者驗證]
E --> F[Token 驗證]
C --> G[節點]
G --> H[工作負載]
圖表翻譯： 此圖示展示了 Kubernetes 叢集的整體架構。叢集包含管理平面和資料平面兩個主要部分。管理平面中的 API 伺服器負責處理使用者請求，並進行使用者驗證。驗證透過後，使用者可以對叢集進行操作。資料平面則包含多個節點，用於執行工作負載。
Kubernetes 驗證機製程式碼示例
以下是一個簡單的 Kubernetes 驗證機製程式碼範例，使用 Python 和 kubernetes 函式庫：
from kubernetes import client, config
# 載入 Kubernetes 組態
config.load_kube_config()
# 建立 API 客戶端
v1 = client.CoreV1Api()
# 查詢節點資訊
nodes = v1.list_node()
# 列印節點名稱
for node in nodes.items:
print(node.metadata.name)
內容解密：
以上程式碼範例展示瞭如何使用 kubernetes 函式庫與 Kubernetes 叢集互動。首先，需要載入 Kubernetes 組態資訊。然後，建立 CoreV1Api 客戶端物件，用於查詢節點資訊。最後，列印節點名稱。
這個範例程式碼僅供參考，實際應用中需要根據具體需求進行修改和擴充套件。
Kubernetes 叢集的驗證機制將繼續發展和完善，包括加強安全性、提高可擴充套件性和簡化操作流程等方面。未來，Kubernetes 將更好地支援多叢集管理、自動化佈署和擴充套件等功能，為使用者提供更強大和靈活的容器協調能力。
Kubernetes 設定檔解析與操作實務
在前面的章節中，我們使用 OpenSSL 工具驗證了與 Kubernetes 叢集的連線，並觀察到相關的 SSL/TLS 連線資訊。在本章節中，我們將探討 kubectl config 的輸出內容，並學習如何操作和管理 Kubernetes 的設定。
TLS 連線資訊解析
首先，讓我們回顧使用 OpenSSL 連線到 Kubernetes 叢集的輸出結果：
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
這段輸出顯示了連線使用的協定版本為 TLSv1.3，並採用根據 AES256 的加密套件。雖然 OpenSSL 顯示了一些憑證驗證錯誤，但由於我們使用的是自簽憑證，因此可以忽略這些錯誤。在正式的生產環境中，我們將在後續章節中學習如何正確管理憑證。
Kubernetes 設定檔結構解析
現在，讓我們仔細分析 microk8s kubectl config view 的輸出結果：
contexts:
- context:
cluster: microk8s-cluster
user: admin
name: microk8s
current-context: microk8s
kind: Config
preferences: {}
users:
- name: admin
user:
token: YktrYUZEMUYwT0h4NTlweVVjY21EQ3c0WXpialEzTFltMmVEZ1FPTGhKST0K
設定檔結構說明
-
Contexts（上下文）設定
- 定義了可用的上下文列表
- 目前只有一個名為
microk8s的上下文 - 指定了使用的叢集（cluster）和使用者（user）
-
目前使用的上下文
current-context: microk8s表示目前正在使用的上下文
-
使用者驗證資訊
- 使用 Token 進行驗證
- Token 儲存在設定檔中用於身份驗證
操作 Context 的實務應用
1. 檢視目前的 Context
microk8s kubectl config current-context
執行結果：
microk8s
2. 列出所有可用的 Contexts
microk8s kubectl config get-contexts
執行結果：
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* microk8s microk8s-cluster admin
3. 重新命名 Context
# 將 microk8s 重新命名為 myfirstk8scluster
microk8s kubectl config rename-context microk8s myfirstk8scluster
執行結果：
Context "microk8s" renamed to "myfirstk8scluster".
驗證結果：
microk8s kubectl config get-contexts
執行結果：
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* myfirstk8scluster microk8s-cluster admin
4. 檢視叢集資訊
microk8s kubectl cluster-info
執行結果：
Kubernetes control plane is running at https://127.0.0.1:16443
CoreDNS is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
重點整理
-
Context 的重要性
- 管理多個叢集時，Context 的切換至關重要
- 可以自定義 Context 名稱以便管理
-
驗證方式
- 使用 Token 進行身份驗證
- Token 儲存在
kubectl的設定檔中
-
實務操作建議
- 使用
config get-contexts檢視所有 Context - 使用
config current-context檢視目前 Context - 使用
config rename-context重新命名 Context 以便管理
- 使用
在後續章節中，我們將進一步探討：
- 如何管理多個 Kubernetes 叢集
- 如何安全地處理驗證 Token
- 如何使用不同的驗證方式
- 如何在不同環境中切換 Context
透過這些知識，我們能夠更有效地管理和操作 Kubernetes 叢集。接下來，我們將探討 Kubernetes 的資源管理與佈署策略。
