概述

要玩叢集都是錢坑，在開始燒錢之前，最好先熟悉下列觀念和術語，避免在操駕時手忙腳亂。
以下會列出一些叢集維運需的術語進行基本介紹，對應日常可能需要進行的工作，針對這些工作進行說明。

怕文謅謅，看不完，在此先聲明，底下只有說明幾件事情

1. YAML 格式
2. 常用的四種工作負載 (Workload)

〖K8s / OCP YAML 格式〗

• 在管理叢集的時候，必須先了解如何透過指令的方式調度管理，以 YAML 來標注或是呈現資料。
• 如果你用 kubectl get 某某資源 -n 某某命名空間 某某名稱的資源 -o yaml，你會得到類似下面這串東西。
• 如果你用 kubectl apply -f 某某.yaml 也能把希望進行管理的設定套用到叢集上，則格式如下。

apiVersion: <API 群組/版本>   # 定義資源的 API 版本
kind: <資源類型>              # 定義要建立的資源類型 (Pod, Deployment, Service, Route…)
metadata:                     # 資源的中繼資料
  name: <名稱>                # 必填：資源名稱
  namespace: <命名空間>        # (選填，預設 default / OCP 建議使用 Project)
  labels:                     # (選填) 可用於篩選與分組
    app: myapp
  annotations:                # (選填) 註解/額外資訊
    description: "示範應用"
spec:                         # 資源的規格定義 (各種資源都不同)
  ...                         # 依照資源類型不同而不同
status:                       # (系統自動生成，不需定義)
  ...

格式說明

1. apiVersion → 指定 API 群組與版本
   • Core API（不帶群組）：v1 (Pod, Service, ConfigMap, Secret)
   • 其他群組：
     • apps/v1 (Deployment, StatefulSet, DaemonSet)
     • batch/v1 (Job, CronJob)
     • networking.k8s.io/v1 (NetworkPolicy, Ingress)
     • route.openshift.io/v1 (OpenShift Route)
2. kind → 指定資源類型
   • 例如：Pod、Service、Deployment、ConfigMap、Secret、Route
3. metadata → 必須要有 name，至於 namespace 可有可無
   • labels 與 annotations 用來過濾資源
   • spec → 定義資源的期望狀態 (Desired State)
     • Pod → containers
     • Deployment → replicas, selector, template
     • Service → ports, selector, type
     • Route (OCP限定) → to, port, tls
4. status → 系統自動維護，不需要寫

〖工作負載 / 名詞解釋 / 使用場景〗

來看看 K8s 提供的幾個常見的工作負載（Workload）。
建議先打開參考資料： https://kubernetes.io/docs/concepts/workloads/

1. Pod： 書上、文件上都寫，這是 「K8s 中運作的最小單位」，由一個或是一組容器構成。

   • 作為最基礎的運作單位，Pod 具有運作的狀態 (Phase)，分別可能為 擱置、運作中、成功結束、失敗結束、不明，如下圖所示：
     
   • Pending: Pod 的建立請求已經被叢集接受，但可能等待資源調度、可能還在下載 image 所以還沒建立起來。
   • Running: Pod 已經被起來，其中的程式還在運作中。 但不代表容器一定能正確跑到最後，他也有可能之後發生 Runtime Error。 也有可能已經失敗過，正在嘗試重開的階段。
   • Successed: 成功執行完任務的 Pod 並且安全地結束。
   • Failed: Pod 中的程式結束並回傳非 0 的結束代碼。
   • Unknown: 未知狀態，可能發生在 Control Plane 和 Worker Node 失聯的狀態。

   共享資源觀念：同一組 Pod 中的那票容器，可以共享網路和掛載的儲存。 基於這個特性，去定義容器先後、平行運作等機制，分別可以作為 initContainer (先用容器鋪路、再執行主要容器)、 side car container (邊車配角，可能是用來記錄 log 或是當成資料庫使用)
   文件裡面還有一大票內容，不過之後有用到再說吧。

2. Deployment： 希望部署 Pod 的方式 -> 「部署」這件事，跟 「數量、生命週期、升級策略」 相關。 通常用來管理 Pod 的生命週期、版本調整升降級、橫向擴充或縮小。

   • Replicas: 顧名思義，Pod 的分身數量。
   • Lifecycles

     Deployment 用來管理生命週期：

     建立 (Create) → 當 replicas 增加時，建立新的 Pod
     刪除 (Delete) → 當 replicas 減少時，刪除多餘的 Pod
     自動修復 (Self-healing) → Pod Crash / Node Down 時，自動重新排程 Pod
     更新 (Rolling Update) → 更換 Pod 版本時，逐步替換舊 Pod，避免服務中斷
     回滾 (Rollback) → 若更新失敗，可回到前一版本

   • Strategy: "Recreate" 或 "RollingUpdate"。 預設是後者，用來滾動升級。
     • 然後在 RollingUpdate 的部署策略，可以決定 Max Unavailable 和 Max Surge 來確保同一時間內，可以允許最低的存活 Pod 數量、最多可以允許同時停機升級的 Pod 數量。
   • Scaling: 支援手動或自動調整副本數。

     # 手動調整
     kubectl scale deployment myapp --replicas=5
     
     # 自動調整
     kubectl autoscale deployment myapp --min=2 --max=10 --cpu-percent=80
     

   • 常見用法有下列幾種
     

3. Service： 希望 Pod 如何提供服務給老百姓 -> 提供「服務」，勢必是跟 「網路」 掛勾在一起。

   • Service Type 官方手冊有列出四種。
     1. ClusterIP: 在叢集內派發的內部 IP，讓叢集內其他有具有內部 IP 的 Pod 可以互通。
     2. NodePort: 顧名思義，是 Pod 被分發到 Worker Node 後，使用該奴隸節點的 IP 作 Port Mapping 轉接連結埠。
     3. LoadBalancer: 是由雲端業者提供的 Load Balancer 當服務的入口，通常都是搭配公有雲業者的服務進行叢集建置才會選這個。
     4. ExternalName: 將 Service 指向外部 DNS 名稱。

4. ConfigMap： 希望 Pod 使用的 Config -> 送進去給 容器、送給 Pod 使用的參數。

結論

• 如果以前有做過 docker run -it xxx -v /abc:/mount/xyz -e password:Hahahacker yyy:latest 之類的經驗，應該可以從管理和提升營運規模的角度，去理解 kubectl 的工作負載設計。
• K8s 原生只提供 Service 類型：ClusterIP、NodePort、LoadBalancer、ExternalName； 要用 HTTP/HTTPS Domain 方式對外暴露服務，必須透過額外安裝設定 Ingress Controller (如 NGINX Ingress)
• OCP 透過一個專屬的 Workload 叫做 Route (route.openshift.io/v1)，專門用來將 Service 對外公開，並直接分配 URL； Route 提供 TLS termination（Edge、Passthrough、Re-encrypt），無需額外安裝 Ingress Controller。
• 這個 Route 的功能，後面會單獨拿出來講。