今日目標

• 理解常駐服務（Deployment/StatefulSet）與批次任務（Job）的本質差異。
• 搞懂 Kubernetes Job 的重試機制（backoffLimit）與完成條件（completions / parallelism）。
• 掌握 CronJob 的排程語法與併發策略（concurrencyPolicy）。
• 實戰操作：建立一個計算圓周率的批次 Job，並配置一個每分鐘自動執行的定時 CronJob。

痛點場景：為什麼不能用 Deployment 跑一次性腳本？

在傳統開發與維運中，我們常常需要執行一些「跑完就該結束」的工作，例如：

• 系統上線前的 資料庫 Migration（資料結構遷移）。
• 每天凌晨產生的 日結報表計算。
• 每週一次的 資料庫備份與 S3 上傳。

如果你用 Deployment 來跑這些腳本，當腳本順利執行完畢、容器正常退出（Exit Code 0）時，Deployment 的控制器會誤以為「Pod 死掉了！」，進而自動重啟它並再次執行，導致無窮迴圈重複跑腳本！

為了解決這個問題，Kubernetes 提供了兩種專門處理批次運算的控制器：

1. Job：負責「跑完即停（Run-to-completion）」的一次性或多批次任務。
2. CronJob：負責「根據時間表定時觸發」的自動化任務。

核心架構：Job 與 CronJob 的運作機制

實戰演練 A：建立一次性批次任務（Job）

步驟 1：建立 pi-job.yaml

我們建立一個 Job，使用 Perl 容器計算圓周率至小數點後 2000 位：

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-calculator-job
spec:
  template:
    spec:
      containers:
        - name: pi
          image: perl:5.34
          command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never # 失敗或結束後不要隨意重啟容器
  backoffLimit: 3        # 如果失敗最多重試 3 次

解析：在 Job 的 Pod 規格中，restartPolicy 只能設定為 Never 或 OnFailure，絕對不能是預設的 Always。

步驟 2：套用配置並觀察完成狀態

kubectl apply -f pi-job.yaml

# 觀察 Job 狀態
kubectl get jobs -w

幾秒鐘後，你會看到 COMPLETIONS 欄位從 0/1 變成 1/1，代表任務順利完成！

步驟 3：查看計算成果與清理

# 查看任務輸出的日誌
kubectl logs job/pi-calculator-job

終端機將印出完整的 2000 位圓周率數值！

實戰演練 B：建立定時排程任務（CronJob）

步驟 1：建立 backup-cronjob.yaml

建立一個每分鐘執行一次的定時任務：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: minute-backup-cronjob
spec:
  schedule: "*/1 * * * *" # 標準 Linux Cron 格式（每分鐘執行一次）
  concurrencyPolicy: Forbid # 若上一次任務還沒跑完，禁止重疊啟動新任務
  successfulJobsHistoryLimit: 3 # 保留最多 3 筆成功歷史紀錄
  failedJobsHistoryLimit: 1     # 保留最多 1 筆失敗歷史紀錄
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup-worker
              image: busybox
              command: ["sh", "-c", "echo '[Backup Process] Backup database at $(date)'; sleep 5"]
          restartPolicy: OnFailure

步驟 2：套用配置並觀察定期觸發

kubectl apply -f backup-cronjob.yaml

# 監控 CronJob 狀態
kubectl get cronjobs

等待 1 到 2 分鐘後，執行以下指令：

# 查看由 CronJob 自動生成的 Job 列表
kubectl get jobs

# 查看自動生成的 Pod
kubectl get pods

你會發現系統按照時間規律，自動建立了名為 minute-backup-cronjob-xxxxxxx 的 Job 與 Pod，執行完畢後 Pod 狀態會停留在 Completed。

關鍵參數解析：concurrencyPolicy（併發控制策略）

如果某個定時任務執行時間超過了排程間隔（例如：每小時觸發一次備份，但備份花了 90 分鐘），該怎麼辦？
Kubernetes 提供了三種策略：

1. Allow（預設）：允許同時並行執行多個 Job。
2. Forbid（最常用）：若上一個任務仍在執行，跳過本次觸發，嚴禁並行（避免資料庫備份打架造成效能暴跌）。
3. Replace：直接終止目前還在跑的舊任務，用全新的任務取而代之。

本日小結

今天我們解鎖了 Kubernetes 在自動化批次與排程維運的兩大核心工具：

• Job：確保一次性運算精準執行並在完成後優雅退出，支援失敗重試與並行計算。
• CronJob：透過 Cron 表達式自動化管理定期工作，並提供嚴謹的併發控制。

隨著集群裡面的應用程式、資料庫、定時任務越來越多，如何將不同的團隊（開發、測試、運維）或不同的專案隔離開來，避免彼此干擾或資源搶奪？

明天 Day 19，我們將學習多租戶隔離的核心機制：「團隊多租戶隔離：Namespace 劃分與 ResourceQuota 資源限制」！