準備 Certified Kubernetes Administrator (CKA)

CMD vs ENTRYPOINT 差異比較 CMD 是什麼？ CMD 用來指定 預設要執行的命令或參數 。 如果你在執行容器時提供了命令或參數，那麼 CMD 的內容會被 覆蓋掉 。 通常搭配 ENTRYPOINT 使用，用來提供預設參數。 範例： ``` CMD ["echo", "Hello from CMD"] ``` 執行： ``` docker run myimage # 輸出：Hello from CMD docker run myimage echo "我自訂的訊息" # 輸出：我自訂的訊息（CMD 被覆蓋） ``` ENTRYPOINT 是什麼？ ENTRYPOINT 用來定義容器啟動時 一定會執行的主命令 。 不會被 docker run 的參數覆蓋 （除非你用 --entrypoint 明確指定）。 適合讓容器專注執行某個固定的程式或腳本。 範例： ``` ENTRYPOINT ["echo"] ``` 執行： ``` docker run myimage "來自 ENTRYPOINT" # 輸出：來自 ENTRYPOINT ``` CMD + ENTRYPOINT 一起使用 當你同時使用這兩個指令時： ENTRYPOINT 是 主命令 （command） CMD 是 預設參數 （arguments） 範例： ``` ENTRYPOINT ["echo"] CMD ["Hello from CMD"] ``` 執行： ``` docker run myimage # 輸出：Hello from CMD docker run myimage "嗨！" # 輸出：嗨！（CMD 被自訂參數取代） ``` 總結比較表

Q: Inspect the deployment and identify the number of PODs deployed by it Ans: 4 $ kubectl get deploy                                               $ kubectl describe deployment | grep -i Desired         Replicas:  4 desired | 4 updated | 4 total | 4 available | 0 unavailable Q: Inspect the deployment and identify the current strategy $ kubectl describe deployment frontend | grep -i StrategyType              Ans: StrategyType: RollingUpdate Q: If you were to upgrade the application now what would happen? Ans: PODs are upgraded few at a time Q: Let us try that. Upgrade the application by setting the image on the deployment to `kodekloud/webapp-color:v2`.  Do not delete and re-create the deployment. Only set the new image name for the existing deployment. Deployment Name: frontend D...

Q: A user - USER5 - has expressed concerns accessing the application. Identify the cause of the issue. Inspect the logs of the POD $ kubectl logs webapp-1              Q: A user is reporting issues while trying to purchase an item. Identify the user and the cause of the issue. Inspect the logs of the webapp in the POD $ kubectl logs webapp-2 -c simple-webapp              說明： webapp-2：目標 Pod 的名稱。 -c simple-webapp： 指定要查看的容器名稱 （如果 Pod 中有多個容器時必須指定）。 預設會印出該容器目前的 stdout/stderr log。

🏆 最常見的監控解法總覽 如：Metrics Server、Prometheus、Elastic Stack、Datadog、Dynatrace Metrics Server 📈 metrics-server 是什麼？ metrics-server 是 K8s 中用來提供資源用量資訊（非歷史紀錄），例如： $ kubectl top node           $ kubectl top pod            HPA（Horizontal Pod Autoscaler）的依據 Cluster Autoscaler 的依據（間接） 📌 注意：它不是用來做長期監控或歷史查詢（那是 Prometheus 的角色）。 🚀 安裝 metrics-server 建議方式（官方部署，預設會在 kube-system namespace 中建立 Deployment） $ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml             

Validating and Mutating Admission Controllers 🔧 Mutating Admission Controller（變更型） ✅ 功能： 修改用戶提交的資源物件 常用於補上預設值、標籤、或注入 Sidecar 📌 實際用途： 自動加入監控 sidecar（如 Istio、Datadog） 補上預設 labels 或 annotations 加入預設的資源限制（CPU/記憶體） 加上 Tolerations、Node Affinity 等 🧩 常見元件： MutatingAdmissionWebhook MutatingAdmissionPolicy（Kubernetes 1.28+ GA） 🔍 Validating Admission Controller（驗證型） ✅ 功能： 驗證資源是否合法，若不符合條件則拒絕執行 無法修改資源，只能判斷通過或拒絕 📌 實際用途： 拒絕使用 latest image tag 禁止容器使用 root 權限 限制只能使用特定的 StorageClass 確保所有物件都有必要的 label 🧩 常見元件： ValidatingAdmissionWebhook ValidatingAdmissionPolicy（Kubernetes 1.28+ GA） 執行順序（流程圖） 1️⃣ 使用者發送 API 請求      ↓ 2️⃣ 驗證身份與權限（Authentication / Authorization）      ↓ 3️⃣ Mutating Admission Controller（如需修改）      ↓ 4️⃣ Validating Admission Controller（檢查是否合法）      ↓ 5️⃣ 通過後寫入 etcd，開始執行 Q: Which of the below combination is correct for Mutating and validating admission controllers ? Ans: NamespaceAutoProvision - Mutating, NamespaceExists - Va...

Admission Controllers 🌐 Admission Controllers 是什麼？ Admission Controllers 是 Kubernetes API Server 中的一個 請求攔截點（intercept point），當使用者送出請求（例如 `kubectl apply -f xxx.yaml`）時，在這個請求被持久化到 etcd 前，Admission Controller 會進行額外的驗證、修改或拒絕。 Admission Controllers 位於 API Server 處理流程中的 驗證（Authentication）與授權（Authorization）之後，物件寫入 etcd 之前。 Note: the `Namespace Auto Provision` and `Namespace Exists` at admission controllers are deprecated and is now replaced by the `Namespace Lifecycle` Admission Controller. The `namespace lifecycle` admission controller will make sure that requests to a non-existent namespace is rejected and that the default namespace, such as default kube-system and kube-public cannot be deleted . ✨ 分類：Mutating vs Validating 🔧 常見內建 Admission Controllers NamespaceLifecycle 禁止在 Terminating 的 Namespace 中創建新資源 LimitRanger 根據 Namespace 設定限制 Pod 的資源使用 ServiceAccount 自動注入預設的 ServiceAccount 到 Pod ResourceQuota 強制資源配額 NodeRestriction 限制 kubelet 操作非自身的 Node 資源 🌐 Webhook 型 Admission C...

Kubernetes Multiple Schedulers 📌 為什麼需要多個 Scheduler？ Kubernetes 預設使用 kube-scheduler 處理所有 Pod 的排程任務。 但某些場景下，我們可能需要： 使用不同策略排程不同類型的工作負載（ex: ML Job、批次任務） 為特定隊列、優先級、資源需求定制排程邏輯 測試自定義排程演算法（研究用） ⚙️ 如何實作 Multiple Schedulers？ 在 cluster 中「同時部署多個 scheduler」，然後讓特定 Pod 使用你指定的 scheduler 名稱進行排程。 1️⃣ 設計你的排程架構 假設你要： 使用原生 default-scheduler 處理一般 workload 使用 custom-scheduler 處理 ML/批次任務 未來可能擴充更多 scheduler 你可以這樣規劃： 2️⃣ 撰寫或部署自定義 Scheduler 可以是： Fork 官方 kube-scheduler 修改排程邏輯（進階） 用 Go/Python 等語言實作一個簡單的排程邏輯 或使用現成的開源方案（如 Volcano、YuniKorn） 建立自定義 Scheduler 後，打包為 Docker Image。 3️⃣ 部署到 Kubernetes 以一個最簡單的 custom scheduler 為例（custom-scheduler-deploy.yaml）： ``` apiVersion: apps/v1 kind: Deployment metadata:   name: custom-scheduler spec:   replicas: 1   selector:     matchLabels:       component: custom-scheduler   template:     metadata:       labels:         component: custom-scheduler     spec:      ...