"Kubernetes"
- 4.0.3 以監控鏈盤點 Kubernetes 上的電商 checkout：叢集內的監控、託管資料庫與第三方金流各自的失效域，以及佇列消費端與外部依賴的缺口
把一個跑在託管 Kubernetes 上、有訊息佇列消費端、託管資料庫與第三方金流的電商 checkout 現有的監控放進監控鏈的各層，逐層判讀缺口與補法；另寫付款服務的 readiness 納入金流業者時對付款回呼的影響、失效域從主機換成叢集與雲端帳號之後觀察者要放在哪裡，以及業務結果、對帳、到期事件、消費端、備份、安全、第三方依賴與成本的逐類盤點
- GCP 上 MIG 與 GKE 管理存取的實測紀錄：instance template 與 canary 滾動更新、重建與主機金鑰、kubectl debug 的 namespace、node pool 設定與控制平面端點的切換
要把 IAP 的 tag、OS Login 與移除外部 IP 套到 MIG 或 GKE 上，想照一次實跑過的順序做、看每一步換一種做法的結果時讀；也用在 MIG 重建之後 SSH 出現 REMOTE HOST IDENTIFICATION HAS CHANGED、kubectl debug 停在等待，或關掉 GKE 控制平面的 IP 端點之前要確認每個人都改連的時候
- GCP 上由 MIG 與 GKE 管理的 VM 的管理存取：instance template、node pool、kubectl debug 與控制平面存取
VM 由 managed instance group 或 GKE node pool 管理時，管理通道的設定為什麼要寫在 instance template 與 node pool 而不是逐台修改、MIG 救援用重建、退回 template 與 Serial Console 各自適用的情形、GKE 的控制平面與節點兩個存取面、kubectl debug 取代節點 SSH 的權限邊界（RBAC 與 Pod Security Admission），以及 GKE 控制平面三種端點（authorized networks、DNS-based endpoint 與 private endpoint）的差別
- Kubernetes 的元件與請求路徑：控制平面、節點、Pod、Deployment、Service 與 Ingress
從 Docker Compose 的使用經驗出發，說明 Kubernetes 用期望狀態與控制迴圈管理容器的方式、控制平面與節點上各元件的責任、Deployment、ReplicaSet 與 Pod 三層工作負載、一個外部 HTTP 請求經過 Ingress 與 Service 抵達 Pod 的路徑和每一段出問題時的訊號，以及節點故障後的重建時間與這套模型在什麼規模下划算
- Liveness 與 Readiness
分不清該用哪種探針、或探針失敗後平台重啟了不該重啟的服務時，回來釐清 liveness、readiness、startup 三種探針各自宣告什麼、失敗後平台做什麼
- 5.2 Kubernetes 部署策略
整理 deployment、probe 與 rolling update
- 單機練習用的 Kubernetes：kind、k3d 與 minikube 的節點模擬方式、預設元件、主機連線與單機上量得到和量不到的行為
比較 kind、k3d、minikube 三種在一台電腦上起 Kubernetes 叢集的工具：節點怎麼用容器模擬、預設附了哪些元件以及缺少時在哪裡現形、主機的 image 與網路怎麼接進叢集，以及節點共用同一台電腦這件事讓哪些 Kubernetes 行為量得到、哪些量不到，最後是三者的閒置開銷與適合練習的對象
- Process supervisor 選型
在 systemd、supervisord、Docker restart policy、Kubernetes 之間選服務監管方式時，用平台能不能分開表達 startup、readiness、liveness、drain 當判斷標準
- Kubernetes Graceful Shutdown：termination 序列跟你以為的不一樣
K8s pod termination 五步序列、preStop / SIGTERM / terminationGracePeriodSeconds 的真實時序、5 個 production 踩雷（500 期間 502、connection drain race、init container 重啟、StatefulSet 串行終止、Job 不 graceful）、跟 service mesh / readiness probe 整合
- Docker Swarm → Kubernetes：5 個 Swarm production cluster 撞牆數據
Docker Swarm → Kubernetes 是 Type E paradigm shift — Swarm「simpler container orchestration」設計上限在 100-200 service 規模、跨 application 服務治理時 paradigm 不足；本文用 5 個 production cluster 量化數據開頭、5 個 production 踩雷
- 在 Kubernetes 上接上監控：kube-prometheus-stack 的元件、ServiceMonitor 與 PrometheusRule 的選取、節點標籤、儀表板 sidecar、Alertmanager 的預設路由、控制平面的讀取與單節點叢集的資源用量
在 Kubernetes 上以 kube-prometheus-stack 接上監控：chart 裝了哪些元件與 CRD，讀取對象與告警規則改以 ServiceMonitor、PrometheusRule 宣告之後由誰轉成 Prometheus 的設定，release 標籤決定哪些宣告會被選中，主機標籤改成節點標籤，儀表板經由 ConfigMap 與 sidecar 載入，Alertmanager 預設不送任何通知，以及控制平面元件只綁本機時讀不到的原因、單節點叢集上的資源用量與記憶體不足時的表現
- Pod
在 Kubernetes 的輸出或設定裡看到 Pod，要知道它和容器的關係、為什麼它的 IP 與名稱會變、以及誰負責替補它時
- Kubernetes Service
在 Kubernetes 裡要讓其他服務連到一組會換 IP 的 Pod、或排查請求為什麼沒有送到 Pod 時：Service 如何用標籤選 Pod、ClusterIP 與 DNS 名稱、EndpointSlice 與 ready 狀態
- Ingress
要讓叢集外的 HTTP 請求依網域與路徑進到 Kubernetes 裡不同的服務、Ingress 建立了卻連不進去、或 ingress-nginx 結束維護後要換 controller 時：Ingress 物件與 Ingress controller 的分工、IngressClass，以及 Gateway API 的關係
- Control Loop（控制迴圈）
讀到「期望狀態」「reconcile」，或 Kubernetes 的 apply 成功了服務卻沒起來時：控制迴圈如何持續比對期望狀態與實際狀態並修正落差，以及它和只在下指令時比對一次的宣告式工具差在哪
- Namespace（命名空間）
看到 kubectl 的 -n、kube-system、default，或跨 namespace 的 Service 名稱連不到時：namespace 劃分物件名稱的範圍、預設用哪一個、對 DNS 名稱與權限的影響
- Taint 與 Toleration
節點故障後 Pod 等了幾分鐘才搬走、Pod 排不上某些節點、或看到 node.kubernetes.io/not-ready 這類鍵名時：taint 如何把 Pod 擋在節點外或趕出節點、toleration 如何讓 Pod 容忍它
- Kubernetes RBAC（角色型存取控制）
要決定誰能對叢集裡的哪些物件做什麼、或查某個帳號為什麼被拒絕或為什麼權限過大時，查 Kubernetes RBAC 的 Role、ClusterRole、binding 與動詞資源的組成
- Pod Security Admission（Pod 安全准入）
Pod 因為安全設定被拒絕建立、要限制某個 namespace 不能跑 privileged 或掛載主機目錄的 Pod，或評估 kubectl debug 這類需要高權限的工具在叢集裡能不能用時，查 Pod Security Admission 的三個等級與 namespace label
- Privileged Container（特權容器）
在 Pod 設定裡看到 securityContext.privileged=true、要判斷某個除錯或系統元件為什麼需要它，或評估誰能建這種 Pod 等於持有節點 root 權限時，查特權容器能做什麼與它的權限邊界