Docker、K8s、CI/CD 與雲端

容器 vs VM 與 Docker 底層原理 高頻 進階

面試最常見的開場題是「容器跟虛擬機差在哪？」。只回答「容器比較輕」是不夠的，面試官要聽到的是隔離發生在哪一層：VM 透過 hypervisor 虛擬化硬體，每台 VM 有自己的 kernel；容器則是同一個 host kernel 上的一群被隔離的 process，隔離靠的是 Linux kernel 的 namespaces，資源限制靠 cgroups，檔案系統靠 union filesystem（overlay2）。

Namespaces：讓 process「看不到」別人

Namespace 決定一個 process 能「看見」哪些系統資源。docker run 時 runtime（runc）會呼叫 clone() / unshare() 建立一組新的 namespace：

PID

容器內有自己的 PID 編號，第一個 process 是 PID 1。從 host 看它只是一般 process，有另一個 PID。

NET

獨立的網路介面、路由表、iptables、port 空間。Docker 預設用 veth pair 接到 host 的 docker0 bridge，再用 NAT 對外。K8s 中同一個 Pod 的容器共用 NET namespace，所以能用 localhost 互通。

MNT

獨立的 mount table，容器看到的 / 是 image 組成的 rootfs（透過 pivot_root）。

UTS

獨立的 hostname / domain name。

IPC

獨立的 System V IPC、POSIX message queue、shared memory。

USER

UID/GID 映射：容器內的 root（UID 0）可以映射到 host 上的非特權 UID（rootless container 的基礎）。

CGROUP

讓容器看到的 cgroup 樹以自己為根。

# 不用 Docker，自己體驗 namespace：開一個有獨立 PID 與 mount namespace 的 shell
sudo unshare --pid --fork --mount-proc bash
ps aux        # 只看得到 bash 與 ps，bash 是 PID 1

# 觀察一個容器 process 的 namespace
docker run -d --name demo nginx:alpine
PID=$(docker inspect -f '{{.State.Pid}}' demo)
sudo ls -l /proc/$PID/ns          # 每個 namespace 是一個 inode
sudo nsenter -t $PID -n ip addr   # 進入該容器的 network namespace 執行 host 上的 ip 指令

cgroups：限制「能用多少」

Control groups 負責資源的限制、計量與優先權。現代發行版多半使用 cgroup v2（單一統一階層）。常見控制器：

• cpu：cpu.max 設定 quota/period（例如 50000 100000 代表每 100ms 最多用 50ms，相當於 0.5 核）；cpu.weight 決定競爭時的相對權重。K8s 的 CPU limit 就是轉成 CFS quota，CPU request 轉成 weight（shares）。
• memory：memory.max 是硬上限，超過時 cgroup 內觸發 OOM killer，容器被殺（exit code 137）。
• pids：限制 process 數，防 fork bomb。
• io：限制區塊裝置讀寫頻寬 / IOPS。

docker run -d --name limited --cpus=0.5 --memory=256m --pids-limit=100 python:3.12-slim sleep 3600
# cgroup v2 下查看（路徑依 cgroup driver 不同而異）
CID=$(docker inspect -f '{{.Id}}' limited)
cat /sys/fs/cgroup/system.slice/docker-$CID.scope/cpu.max      # 50000 100000
cat /sys/fs/cgroup/system.slice/docker-$CID.scope/memory.max   # 268435456
docker stats limited --no-stream

Union FS / overlay2 與 image layer

Docker image 是一疊唯讀的 layer，每個 Dockerfile 中會改變檔案系統的指令（RUN、COPY、ADD）產生一層。overlay2 把這些層疊起來：

• lowerdir：image 的各個唯讀 layer。
• upperdir：容器專屬的可寫層。
• merged：容器實際看到的合併視圖。

讀檔時由上往下找；修改 lower 層的檔案會觸發 copy-up（copy-on-write）：整個檔案先複製到 upperdir 再改。刪除 lower 層的檔案則是在 upperdir 建立 whiteout 標記。這帶來幾個重要推論：

1. 在後面的 layer 刪檔不會讓 image 變小。RUN apt-get install ... 之後再 RUN rm -rf /var/lib/apt/lists/*，檔案仍存在前一層裡。清理必須在同一個 RUN 內完成，或用 multi-stage build。
2. 多個容器共用同一個 image 時，lower layers 只存一份，啟動快且省磁碟。
3. 容器內寫大量資料到 rootfs 很慢且容器刪除就消失，資料要寫到 volume（bind mount / named volume / K8s PV）。
4. 寫入密集的 DB 不要放在 overlay 的可寫層上。

Build cache 的運作規則

BuildKit 依序檢查每個指令：指令字串相同、且（對 COPY/ADD 而言）來源檔案的內容 checksum 相同，就重用快取。某一層快取失效，其後所有層都要重建。所以 Dockerfile 的順序原則是：越少變動的放越前面——先裝系統套件、再複製依賴描述檔（pyproject.toml、uv.lock、go.mod）並安裝依賴、最後才複製原始碼。這樣改一行程式碼只需重建最後一兩層。

Dockerfile 最佳實踐與 Production 級 Python 範例 高頻

寫 Dockerfile 的目標有五個：小（拉取快、攻擊面小）、快（build cache 有效）、安全（non-root、無 secret、無多餘工具）、可重現（鎖版本）、行為正確（信號處理、log 輸出到 stdout）。

PID 1、信號處理與 tini

這是很多人踩過、面試也很愛問的細節。docker stop 或 K8s 刪除 Pod 時，runtime 會送 SIGTERM 給容器的 PID 1，等待寬限期（Docker 預設 10 秒，K8s 預設 terminationGracePeriodSeconds: 30）後送 SIGKILL。問題有三：

1. Shell form 吃掉信號：CMD python app.py 實際執行的是 /bin/sh -c "python app.py"，PID 1 是 sh，而 sh 不會把 SIGTERM 轉發給子 process，應用永遠收不到，只能等 SIGKILL 被硬殺——進行中的請求全斷、連線沒關、buffer 沒 flush。
2. PID 1 的特殊信號語意：Linux kernel 對 namespace 內的 PID 1 不套用預設的信號處理動作。一般 process 收到 SIGTERM 沒裝 handler 時預設會終止，但 PID 1 若沒有明確註冊 handler，SIGTERM 會被忽略。Python 預設沒有 SIGTERM handler（只有 SIGINT 變成 KeyboardInterrupt）。
3. Zombie 回收：PID 1 負責 wait() 被收養的孤兒 process。若應用會 fork 子 process（例如呼叫 subprocess 但沒 wait），zombie 會累積。

解法：使用 exec form；在應用中註冊 SIGTERM handler 做 graceful shutdown；並用輕量 init（tini、dumb-init）當 PID 1，它會轉發信號並回收 zombie。Docker 可直接 docker run --init；K8s 沒有對應選項，所以在 image 裡裝 tini 最保險。若一定要用 shell script 當 entrypoint，最後一行要用 exec "$@" 讓應用取代 shell。

# app/main.py —— 在應用層處理 SIGTERM（以 asyncio 服務為例）
import asyncio
import signal

async def serve(stop: asyncio.Event) -> None:
    # 假裝是 HTTP server / consumer 主迴圈
    while not stop.is_set():
        await asyncio.sleep(0.5)
    print("draining in-flight work, closing DB pool ...", flush=True)
    await asyncio.sleep(1)  # 等進行中的請求完成、flush buffer、commit offset
    print("bye", flush=True)

async def main() -> None:
    stop = asyncio.Event()
    loop = asyncio.get_running_loop()
    for sig in (signal.SIGTERM, signal.SIGINT):
        loop.add_signal_handler(sig, stop.set)
    await serve(stop)

if __name__ == "__main__":
    asyncio.run(main())

實務上用 Uvicorn / Gunicorn 時，它們本身已處理 SIGTERM（停止接新連線、等待進行中請求完成），你只需確保它們真的是收到信號的那個 process。

Production 級 Python（uv）Dockerfile

以下以 FastAPI + Uvicorn、依賴由 uv 管理（pyproject.toml + uv.lock）為例。重點：builder 與 runtime 用同一個 Python base，讓 venv 可直接複製；依賴層與程式碼層分離；cache mount 加速；non-root；tini；healthcheck。

# syntax=docker/dockerfile:1.7
ARG PYTHON_VERSION=3.12

########## Stage 1: builder ##########
FROM python:${PYTHON_VERSION}-slim AS builder

# 從官方 image 取得固定版本的 uv 執行檔
COPY --from=ghcr.io/astral-sh/uv:0.5.11 /uv /uvx /bin/

ENV UV_COMPILE_BYTECODE=1 \
    UV_LINK_MODE=copy \
    UV_PYTHON_DOWNLOADS=0 \
    UV_PROJECT_ENVIRONMENT=/app/.venv

WORKDIR /app

# 1) 只用 lock 檔安裝「依賴」——程式碼變動不會讓這層失效
RUN --mount=type=cache,target=/root/.cache/uv \
    --mount=type=bind,source=uv.lock,target=uv.lock \
    --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
    uv sync --frozen --no-install-project --no-dev

# 2) 再複製原始碼並安裝專案本身
COPY . .
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --frozen --no-dev

########## Stage 2: runtime ##########
FROM python:${PYTHON_VERSION}-slim AS runtime

# tini 當 PID 1：轉發信號 + 回收 zombie；同一個 RUN 內清掉 apt list
RUN apt-get update \
 && apt-get install -y --no-install-recommends tini \
 && rm -rf /var/lib/apt/lists/* \
 && groupadd --system --gid 10001 app \
 && useradd --system --uid 10001 --gid app --no-create-home app

ENV PATH="/app/.venv/bin:$PATH" \
    PYTHONUNBUFFERED=1 \
    PYTHONDONTWRITEBYTECODE=1

WORKDIR /app
COPY --from=builder --chown=app:app /app /app

USER 10001
EXPOSE 8000

# Docker 本機用；K8s 會忽略 HEALTHCHECK，改用 probes
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD ["python", "-c", "import urllib.request,sys; sys.exit(0 if urllib.request.urlopen('http://127.0.0.1:8000/healthz', timeout=2).status == 200 else 1)"]

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "2", "--timeout-graceful-shutdown", "20"]

# .dockerignore
.git
.github
.venv
__pycache__/
*.pyc
.pytest_cache/
.mypy_cache/
.env
*.env
tests/
docs/
Dockerfile*
docker-compose*.yml

# 建置與檢查
docker build -t events-api:$(git rev-parse --short HEAD) .
docker image ls events-api                 # 看大小
docker history events-api:<tag>          # 看每層大小，找出肥大的層
docker run --rm -p 8000:8000 events-api:<tag>

# build 期需要私有套件庫 token：用 secret mount，不留在任何 layer
docker build --secret id=pip_token,env=PIP_TOKEN -t events-api .
#   Dockerfile 內：RUN --mount=type=secret,id=pip_token \
#       PIP_TOKEN=$(cat /run/secrets/pip_token) uv sync --frozen

補充：Go 服務的極小 image

FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod go mod download
COPY . .
RUN --mount=type=cache,target=/go/pkg/mod --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags="-s -w" -o /out/bidder ./cmd/bidder

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /out/bidder /bidder
USER nonroot:nonroot
ENTRYPOINT ["/bidder"]

靜態編譯的 Go binary 搭配 distroless，image 通常只有十幾 MB，沒有 shell 也沒有套件管理器，攻擊面極小（代價是不能 kubectl exec 進去 debug，可用 kubectl debug 的 ephemeral container 補救）。

Docker Compose：本機開發與整合測試環境 基礎

Compose 用一份 YAML 描述多個服務、網路與 volume，適合本機開發、整合測試與 CI。它不是 production orchestrator（沒有跨主機排程、自動 reschedule、rolling update），production 交給 K8s / ECS。以下是 app + PostgreSQL + Redis 的範例，重點在健康檢查與啟動順序。

# compose.yaml
services:
  api:
    build:
      context: .
      target: runtime
    image: events-api:dev
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://app:app@postgres:5432/events
      REDIS_URL: redis://redis:6379/0
      LOG_LEVEL: debug
    depends_on:
      postgres:
        condition: service_healthy   # 等 DB 真的可連線才啟動，而非只是容器啟動
      redis:
        condition: service_healthy
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M

  migrate:
    image: events-api:dev
    command: ["alembic", "upgrade", "head"]
    environment:
      DATABASE_URL: postgresql://app:app@postgres:5432/events
    depends_on:
      postgres:
        condition: service_healthy
    restart: "no"

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app        # 只限本機開發
      POSTGRES_DB: events
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./db/init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d events"]
      interval: 5s
      timeout: 3s
      retries: 10

  redis:
    image: redis:7-alpine
    command: ["redis-server", "--appendonly", "yes", "--maxmemory", "256mb", "--maxmemory-policy", "allkeys-lru"]
    volumes:
      - redisdata:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  pgdata:
  redisdata:

docker compose up -d --build        # 建置並背景啟動
docker compose ps                   # 看狀態與 health
docker compose logs -f api          # 追 log
docker compose exec postgres psql -U app -d events
docker compose run --rm api pytest -q   # 在相同網路中跑整合測試
docker compose down -v              # 停止並刪除 volume（資料會清掉）

• Compose 會為專案建立預設 network，服務之間用服務名稱當 hostname（postgres、redis），由 Docker 內建 DNS 解析。
• depends_on 只控制啟動順序；沒有 condition: service_healthy 時不保證依賴「可用」。即使有，應用本身仍要有連線重試，因為 production 中依賴隨時可能短暫不可用。
• 容器內連 localhost 指的是容器自己，不是 host——這是新手最常見的連線錯誤。

Kubernetes 架構與 Reconcile Loop 高頻 進階

Kubernetes 是一個宣告式（declarative）的容器編排系統：你告訴它「我要 5 個這個版本的 Pod」（desired state），一群 controller 不斷比對實際狀態（actual state）並採取行動讓兩者一致。理解這個「控制迴圈」比背元件名稱重要得多。

Control plane 元件

kube-apiserver

整個叢集的唯一入口，提供 REST API；負責認證（authn）、授權（RBAC）、admission control（mutating/validating webhook，例如自動注入 sidecar、強制 policy），並且是唯一直接讀寫 etcd 的元件。無狀態，可水平擴展。所有元件都透過 watch API server 取得變更通知，而不是彼此直接溝通。

etcd

分散式強一致 key-value store，使用 Raft 共識演算法，儲存所有叢集狀態。通常部署 3 或 5 個成員（奇數，容忍 (n-1)/2 個故障）。etcd 掛了叢集就無法變更（既有 Pod 仍會繼續跑）。必須定期備份（etcdctl snapshot save）。

kube-scheduler

watch 尚未指派 node 的 Pod，經過 filtering（資源 requests 是否放得下、nodeSelector/affinity、taints/tolerations、PVC 所在 zone）與 scoring（資源平衡、spread、image locality 等）選出 node，然後寫回 spec.nodeName（binding）。注意排程只看 requests，不看實際使用量。

kube-controller-manager

打包了許多 controller：Deployment、ReplicaSet、StatefulSet、Job、Node（偵測 node 失聯並驅逐 Pod）、EndpointSlice、ServiceAccount、Namespace 等。每個 controller 都是一個 reconcile loop。

cloud-controller-manager

與雲端 API 整合：建立 type: LoadBalancer 的雲端 LB、設定路由、管理 node 生命週期。

Node 元件

kubelet

每個 node 上的 agent。watch 指派到本 node 的 Pod，透過 CRI 呼叫 container runtime 建立容器、掛載 volume、執行 probes、回報 Pod 與 node 狀態、在資源壓力時驅逐（evict）Pod。

kube-proxy

watch Service 與 EndpointSlice，在 node 上寫 iptables 或 IPVS 規則，把送往 Service ClusterIP 的封包 DNAT 到後端 Pod IP。它不是真的 proxy 流量（早期 userspace 模式才是）。Cilium 等 eBPF CNI 可完全取代 kube-proxy。

Container runtime

實作 CRI 的 containerd 或 CRI-O，底層呼叫 runc。

CNI plugin

（不是核心元件但必備）負責 Pod 網路：每個 Pod 一個 IP，所有 Pod 不經 NAT 可互通。常見：Calico、Cilium、AWS VPC CNI（Pod 直接拿 VPC IP）、GKE 的 Dataplane V2。

從 kubectl apply 到容器跑起來

Reconcile loop 的本質

# 概念性虛擬碼：所有 controller 都長這樣（level-triggered，而非 edge-triggered）
def reconcile(key):
    desired = api.get(key)                 # 例如 ReplicaSet.spec.replicas = 5
    actual = api.list_pods(selector=desired.selector, owner=key)
    diff = desired.replicas - len([p for p in actual if not p.terminating])
    if diff > 0:
        for _ in range(diff):
            api.create_pod(desired.template)
    elif diff < 0:
        for pod in pick_pods_to_delete(actual, -diff):   # 優先刪 未就緒/新的/同 node 擁擠的
            api.delete_pod(pod)
    api.update_status(key, ready=count_ready(actual))

while True:
    key = workqueue.get()          # 由 informer 的 watch 事件 + 定期 resync 放入
    try:
        reconcile(key)
    except Exception:
        workqueue.add_rate_limited(key)   # 失敗就指數退避重試
    finally:
        workqueue.done(key)

重點特性：

• Level-triggered：controller 看的是「現在狀態與期望狀態的差」，而不是「發生了什麼事件」。所以漏掉事件、controller 重啟都沒關係，下次 reconcile 會自動修正——這是 K8s 自癒（self-healing）的根源。
• 冪等：reconcile 執行多次結果相同。
• 樂觀並行控制：每個物件有 resourceVersion，更新時版本不符會得到 409 Conflict，controller 重新讀取再試。
• Operator 模式就是自己寫 CRD + controller，把維運知識（例如資料庫的備份、failover）編碼成 reconcile loop。

核心物件與 YAML 範例 高頻

先看一張總表，再逐一看 YAML。記住物件之間的擁有關係：Deployment 管 ReplicaSet，ReplicaSet 管 Pod；Service 透過 label selector 找到 Pod（不是擁有）。

Deployment（含 probes、resources、安全設定）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: events-api
  namespace: tracking
  labels: { app: events-api }
spec:
  replicas: 4
  revisionHistoryLimit: 5
  selector:
    matchLabels: { app: events-api }       # 建立後不可變更
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%          # 更新時最多多出幾個 Pod
      maxUnavailable: 0      # 更新時不允許可用數低於 replicas
  template:
    metadata:
      labels: { app: events-api, version: "1.8.2" }
    spec:
      serviceAccountName: events-api
      terminationGracePeriodSeconds: 40
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile: { type: RuntimeDefault }
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector: { matchLabels: { app: events-api } }
      containers:
        - name: api
          image: registry.example.com/tracking/events-api:1.8.2-3f9c2ab
          ports:
            - { name: http, containerPort: 8000 }
          env:
            - name: REDIS_URL
              valueFrom: { configMapKeyRef: { name: events-api-config, key: redis_url } }
            - name: DATABASE_PASSWORD
              valueFrom: { secretKeyRef: { name: events-api-secret, key: db_password } }
          resources:
            requests: { cpu: "500m", memory: "512Mi" }
            limits:   { memory: "512Mi" }          # 常見做法：設 memory limit，CPU 不設 limit
          startupProbe:
            httpGet: { path: /healthz, port: http }
            periodSeconds: 2
            failureThreshold: 30                   # 最多給 60 秒啟動
          readinessProbe:
            httpGet: { path: /readyz, port: http }
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet: { path: /healthz, port: http }
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          lifecycle:
            preStop:
              exec: { command: ["sleep", "10"] }   # 等 endpoint 移除傳播完（見優雅關閉段落）
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          volumeMounts:
            - { name: tmp, mountPath: /tmp }
      volumes:
        - name: tmp
          emptyDir: {}

Service、Ingress 與 Gateway API

apiVersion: v1
kind: Service
metadata: { name: events-api, namespace: tracking }
spec:
  type: ClusterIP
  selector: { app: events-api }
  ports:
    - { name: http, port: 80, targetPort: http }
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: events-api
  namespace: tracking
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "1m"
spec:
  ingressClassName: nginx
  tls:
    - hosts: [track.example.com]
      secretName: track-tls
  rules:
    - host: track.example.com
      http:
        paths:
          - path: /v1/events
            pathType: Prefix
            backend: { service: { name: events-api, port: { name: http } } }
---
# Gateway API：Ingress 的後繼者，角色分離（平台團隊管 Gateway，應用團隊管 Route），原生支援權重分流
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: events-api, namespace: tracking }
spec:
  parentRefs: [{ name: public-gateway, namespace: infra }]
  hostnames: [track.example.com]
  rules:
    - matches: [{ path: { type: PathPrefix, value: /v1/events } }]
      backendRefs:
        - { name: events-api, port: 80, weight: 90 }
        - { name: events-api-canary, port: 80, weight: 10 }

Ingress 只是規則，需要 Ingress Controller（ingress-nginx、Traefik、AWS Load Balancer Controller 會建立 ALB、GKE 會建立 Google Cloud HTTP(S) LB）才會生效。Ingress 的進階功能（rewrite、canary、timeout）都要靠各家 annotation，不可攜；Gateway API 把這些標準化成欄位，是新專案較推薦的方向。

ConfigMap 與 Secret

apiVersion: v1
kind: ConfigMap
metadata: { name: events-api-config, namespace: tracking }
data:
  redis_url: redis://redis-master.tracking:6379/0
  app.yaml: |
    batch_size: 500
    flush_interval_ms: 200
---
apiVersion: v1
kind: Secret
metadata: { name: events-api-secret, namespace: tracking }
type: Opaque
stringData:                 # 寫入時是明文，API server 會存成 base64 的 data
  db_password: change-me

PV、PVC、StorageClass 與 StatefulSet

• PersistentVolume（PV）：叢集中的一塊實際儲存（EBS volume、GCE PD、NFS）。
• PersistentVolumeClaim（PVC）：應用對儲存的「請求」（要 50Gi、ReadWriteOnce）。
• StorageClass：描述如何動態佈建 PV（provisioner、磁碟類型 gp3/pd-ssd、reclaimPolicy Delete/Retain、volumeBindingMode: WaitForFirstConsumer 讓磁碟建在 Pod 被排程到的 zone）。
• Access modes：ReadWriteOnce（單一 node 讀寫，EBS 屬此類）、ReadOnlyMany、ReadWriteMany（需 NFS/EFS/Filestore 類）、ReadWriteOncePod。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: gp3 }
provisioner: ebs.csi.aws.com
parameters: { type: gp3 }
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: apps/v1
kind: StatefulSet
metadata: { name: redis, namespace: tracking }
spec:
  serviceName: redis-headless          # 需搭配 headless Service
  replicas: 3
  selector: { matchLabels: { app: redis } }
  template:
    metadata: { labels: { app: redis } }
    spec:
      containers:
        - name: redis
          image: redis:7.2
          ports: [{ containerPort: 6379 }]
          volumeMounts: [{ name: data, mountPath: /data }]
  volumeClaimTemplates:                # 每個 Pod 一個 PVC：data-redis-0, data-redis-1 ...
    - metadata: { name: data }
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: gp3
        resources: { requests: { storage: 20Gi } }

DaemonSet、Job、CronJob

apiVersion: batch/v1
kind: CronJob
metadata: { name: hourly-report, namespace: analytics }
spec:
  schedule: "5 * * * *"               # 每小時第 5 分
  timeZone: "Asia/Taipei"
  concurrencyPolicy: Forbid           # 上一次還沒跑完就跳過，避免重疊
  startingDeadlineSeconds: 600
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 3                 # 失敗重試次數
      activeDeadlineSeconds: 3000     # 超時就整個 Job 失敗
      ttlSecondsAfterFinished: 86400
      template:
        spec:
          restartPolicy: Never        # Job 只能是 Never 或 OnFailure
          containers:
            - name: report
              image: registry.example.com/analytics/report:2.3.0
              args: ["--window", "1h"]
              resources:
                requests: { cpu: "1", memory: "2Gi" }
                limits:   { memory: "2Gi" }

CronJob 不保證「恰好一次」：controller 故障可能錯過或重複觸發，所以任務本身要冪等（例如以時間窗為 key upsert 結果）。DaemonSet 則常配合 tolerations 讓它也能跑在有 taint 的 node 上（例如 GPU node、spot node）。

HPA、PDB、Namespace 與 ResourceQuota

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: events-api, namespace: tracking }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: events-api }
  minReplicas: 4
  maxReplicas: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 60 }   # 以 requests 為分母
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies: [{ type: Percent, value: 100, periodSeconds: 30 }]  # 每 30 秒最多翻倍
    scaleDown:
      stabilizationWindowSeconds: 300                              # 縮容觀察 5 分鐘，避免抖動
      policies: [{ type: Percent, value: 10, periodSeconds: 60 }]
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: events-api, namespace: tracking }
spec:
  minAvailable: 75%          # 或 maxUnavailable: 1
  selector: { matchLabels: { app: events-api } }
---
apiVersion: v1
kind: ResourceQuota
metadata: { name: team-quota, namespace: tracking }
spec:
  hard:
    requests.cpu: "100"
    requests.memory: 200Gi
    limits.memory: 300Gi
    pods: "500"

• HPA 的核心公式：desiredReplicas = ceil(currentReplicas × currentMetric / targetMetric)，預設有 10% 容忍區間避免小幅波動觸發。CPU 使用率是「實際使用 / requests」，所以沒設 requests 的 Pod，CPU-based HPA 無法運作。資源指標來自 metrics-server；自訂指標（QPS、queue lag）需要 Prometheus Adapter 或 KEDA。
• HPA 管 Pod 數；Pod 放不下時要靠 Cluster Autoscaler 或 Karpenter（AWS）加 node。VPA 則調整單一 Pod 的 requests，不要和同指標的 HPA 同時作用在 CPU/memory 上。
• PDB 只保護自願中斷（kubectl drain、node 升級、Cluster Autoscaler 縮容），對 node 當機這類非自願中斷無效。設定 minAvailable 等於 replicas 會讓 drain 永遠卡住，是常見事故。
• Namespace 是 RBAC、ResourceQuota、LimitRange、NetworkPolicy 的作用範圍，但不是安全隔離邊界：預設不同 namespace 的 Pod 網路是通的，需要 NetworkPolicy 才能限制。

Probes、Resources、QoS 與 OOMKilled 高頻 深入

三種 probe 的正確用法

Probe 預設值：periodSeconds: 10、timeoutSeconds: 1、failureThreshold: 3、successThreshold: 1。支援 httpGet（2xx/3xx 視為成功）、tcpSocket、exec、grpc。

# 健康檢查端點的合理分工（FastAPI 示意）
import asyncio, time
from fastapi import FastAPI, Response

app = FastAPI()
state = {"ready": False, "draining": False, "last_tick": time.monotonic()}

@app.on_event("startup")
async def startup() -> None:
    # 載入模型、建立連線池、暖快取……完成後才 ready
    await asyncio.sleep(2)
    state["ready"] = True
    asyncio.create_task(heartbeat())

async def heartbeat() -> None:
    while True:                         # event loop 若被阻塞，tick 就不會更新
        state["last_tick"] = time.monotonic()
        await asyncio.sleep(1)

@app.get("/healthz")                    # liveness：只檢查自己是否卡死
async def healthz(resp: Response):
    if time.monotonic() - state["last_tick"] > 10:
        resp.status_code = 500
    return {"ok": resp.status_code != 500}

@app.get("/readyz")                     # readiness：能不能接流量
async def readyz(resp: Response):
    if not state["ready"] or state["draining"]:
        resp.status_code = 503
    return {"ready": resp.status_code != 503}

Requests vs Limits

requests

排程依據與保證量。scheduler 只把 Pod 放到「剩餘可分配 requests」足夠的 node。CPU request 轉成 cgroup 的 CPU weight，在競爭時保證按比例分到 CPU。

limits

硬上限。CPU limit 轉成 CFS quota（每 100ms period 能用多少 CPU 時間），超過就被 throttle（暫停到下個 period）；memory limit 超過就被 OOMKilled（exit code 137）。

CPU 是可壓縮資源（超用只會變慢），memory 是不可壓縮資源（超用只能殺掉）。這導出一個業界常見（但有爭議）的建議：memory 設 limit 且通常等於 request；CPU 設 request、不設 limit 或設寬鬆的 limit，避免不必要的 throttling。

CPU throttling：延遲殺手

假設 limit 為 1 核（每 100ms 可用 100ms CPU 時間），而服務有 4 個執行緒同時處理一個突發請求，每個需要 30ms CPU：前 25ms 內 4 執行緒就用光 100ms 配額，剩下 75ms 全部被暫停。結果平均 CPU 使用率看起來只有 40%，但 p99 延遲多了 75ms——對 RTB 這種 100ms 預算的服務是致命的。觀察指標：cgroup 的 cpu.stat 中的 nr_throttled、throttled_usec，或 Prometheus 的 container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total。

QoS class 與驅逐順序

注意兩種不同的「被殺」：容器超過自己的 memory limit → cgroup OOM killer 殺掉容器，Pod 狀態顯示 OOMKilled，容器原地重啟；node 整體記憶體不足 → kubelet 依 QoS 與使用量驅逐（evict）Pod，Pod 狀態為 Evicted，由 controller 在別處重建。

# 診斷 OOMKilled
kubectl get pod events-api-7d9c-abcde -o jsonpath='{.status.containerStatuses[0].lastState}'
#  {"terminated":{"exitCode":137,"reason":"OOMKilled",...}}
kubectl describe pod events-api-7d9c-abcde | grep -A5 "Last State"
kubectl top pod -n tracking --containers            # 需 metrics-server
# 判斷是 limit 太低還是 memory leak：看記憶體曲線是「穩定在高位」還是「持續爬升」

部署策略與 K8s 優雅關閉 高頻 深入

Rolling update、Blue-Green、Canary

kubectl set image deploy/events-api api=registry.example.com/tracking/events-api:1.8.3-a1b2c3d -n tracking
kubectl rollout status deploy/events-api -n tracking --timeout=5m   # CI 中用來判斷成敗
kubectl rollout history deploy/events-api -n tracking
kubectl rollout undo deploy/events-api -n tracking                 # 回到上一個 ReplicaSet
kubectl rollout undo deploy/events-api -n tracking --to-revision=7
kubectl rollout pause / resume deploy/events-api -n tracking       # 手動做簡易分批

原生 Deployment 只能做 rolling update；要自動化 canary / blue-green 並根據指標分析決定前進或回滾，常用 Argo Rollouts 或 Flagger（搭配 Prometheus 查詢錯誤率、延遲）。

K8s 中的優雅關閉時序

這是深入題的常客：「為什麼我 rolling update 時會出現少量 502/503？」答案在於 Pod 終止與 endpoint 移除是平行發生的，沒有先後保證。

如果沒有 preStop，容器可能在 kube-proxy / Ingress controller / 雲端 LB 還沒更新前就收到 SIGTERM 並關閉 listener，那幾百毫秒到幾秒內仍被送來的請求就會失敗。正確做法：

1. preStop 加短暫 sleep（5–15 秒，視 LB 傳播時間而定），讓流量先停。distroless image 沒有 sleep 指令時，可用較新版本 K8s 原生的 preStop: { sleep: { seconds: 10 } }，或在應用內實作「收到 SIGTERM 後先繼續服務 N 秒」。
2. 應用處理 SIGTERM：停止接受新連線、讓 readiness 回 503、等進行中的請求完成、flush buffer、commit Kafka offset、關閉 DB 連線池，然後退出。
3. terminationGracePeriodSeconds > preStop 時間 + 最長請求處理時間。注意 preStop 的時間是算在寬限期內的。
4. 長連線（WebSocket、gRPC streaming、HTTP keep-alive）：主動通知 client 重連（HTTP/2 GOAWAY、回 Connection: close），否則 client 會一直黏在要關掉的 Pod 上。
5. Queue consumer：停止拉新訊息、處理完手上的、commit offset，未完成的交還 broker（visibility timeout / rebalance）。

spec:
  terminationGracePeriodSeconds: 45
  containers:
    - name: api
      lifecycle:
        preStop:
          exec: { command: ["sh", "-c", "sleep 10"] }
      # 應用收到 SIGTERM 後最多花 30 秒 drain：10 (preStop) + 30 < 45

K8s 常見排錯 高頻 進階

排錯的通用順序：看狀態 → 看事件 → 看 log → 進去看 → 看資源。

kubectl get pods -n tracking -o wide                 # STATUS、RESTARTS、所在 node、IP
kubectl describe pod <pod> -n tracking               # 最重要：Events 區塊、Last State、Conditions
kubectl get events -n tracking --sort-by=.lastTimestamp | tail -30
kubectl logs <pod> -n tracking -c api --tail=200     # 多容器要指定 -c
kubectl logs <pod> -n tracking --previous           # 上一次 crash 的容器 log（CrashLoop 必用）
kubectl logs -l app=events-api -n tracking --since=10m --max-log-requests=20
kubectl exec -it <pod> -n tracking -- sh            # 進容器（需要 image 有 shell）
kubectl debug -it <pod> -n tracking --image=nicolaka/netshoot --target=api   # ephemeral debug 容器
kubectl top pod -n tracking --containers; kubectl top node
kubectl port-forward svc/events-api 8000:80 -n tracking                # 本機直連除錯
kubectl get endpointslices -n tracking -l kubernetes.io/service-name=events-api   # Service 有沒有後端
kubectl auth can-i get secrets -n tracking --as=system:serviceaccount:tracking:events-api

Helm、Kustomize 與 GitOps（ArgoCD） 進階

直接維護多套 YAML（dev/staging/prod、多個區域）很快會失控，需要「範本化」或「疊加」工具，再透過 GitOps 讓叢集狀態與 Git 自動同步。

# Helm：templates/deployment.yaml 片段
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "events-api.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
    spec:
      containers:
        - name: api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
---
# values-prod.yaml
replicaCount: 8
image:
  repository: registry.example.com/tracking/events-api
  tag: 1.8.3-a1b2c3d
resources:
  requests: { cpu: "1", memory: 1Gi }
  limits: { memory: 1Gi }

helm upgrade --install events-api ./charts/events-api -n tracking -f values-prod.yaml --atomic --timeout 5m
helm template events-api ./charts/events-api -f values-prod.yaml | less   # 先渲染出來看
helm history events-api -n tracking; helm rollback events-api 12 -n tracking

# Kustomize：overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: tracking
resources:
  - ../../base
images:
  - name: registry.example.com/tracking/events-api
    newTag: 1.8.3-a1b2c3d            # CI 只需要改這一行
replicas:
  - name: events-api
    count: 8
patches:
  - path: resources-patch.yaml
configMapGenerator:
  - name: events-api-config
    behavior: merge
    literals: [LOG_LEVEL=info]       # 產生帶 hash 後綴的名稱，內容變更會自動觸發 rolling update

GitOps 與 ArgoCD 原理

GitOps 的四個原則（OpenGitOps）：宣告式、版本化且不可變（Git 是唯一事實來源）、自動拉取、持續 reconcile。關鍵在「pull 模型」：不是 CI 拿著叢集憑證 kubectl apply（push），而是叢集內的 agent（ArgoCD、Flux）去 Git 拉取並套用。

• Application CRD：定義「哪個 Git repo 的哪個路徑/revision」要部署到「哪個叢集的哪個 namespace」。
• Repo server 把 Helm/Kustomize 渲染成 manifest（desired state）；application controller 與叢集 live state 比對，顯示 Synced/OutOfSync 與健康狀態 Healthy/Progressing/Degraded。
• Auto-sync + selfHeal：有人手動 kubectl edit 造成漂移（drift），ArgoCD 會自動改回 Git 的狀態；prune：Git 刪掉的資源叢集也刪掉。
• Sync waves / hooks：控制順序，例如先跑 DB migration Job（PreSync hook）再更新 Deployment。
• App of Apps / ApplicationSet：用一個 Application 管理多個 Application，或依叢集/環境清單自動產生。
• 回滾 = git revert，所有變更都有審核紀錄（PR）與作者。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: events-api-prod
  namespace: argocd
spec:
  project: tracking
  source:
    repoURL: https://git.example.com/platform/k8s-config.git
    targetRevision: main
    path: apps/events-api/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: tracking
  syncPolicy:
    automated: { prune: true, selfHeal: true }
    syncOptions: [CreateNamespace=true]
    retry: { limit: 5, backoff: { duration: 10s, factor: 2, maxDuration: 3m } }

CI/CD Pipeline 設計：GitHub Actions、Jenkins、Drone、Ansible、Terraform 高頻

CI（Continuous Integration）確保每次合併都經過自動驗證；CD 分成 Continuous Delivery（隨時可部署，正式環境需人工按下）與 Continuous Deployment（通過就自動上線）。一條成熟的 pipeline：

設計原則

• Fail fast：便宜快速的檢查放前面（lint 幾秒、unit test 一兩分鐘），貴的（整合測試、E2E）放後面；能平行的就平行。
• Build once, deploy many：同一個 image（同一個 digest）從 dev 一路升級（promote）到 prod，環境差異只放在設定（ConfigMap/values），不要每個環境重新 build，否則測過的不是上線的。
• Artifact 版本化：image tag 用 <semver>-<git short SHA> 或直接 SHA，不可變（registry 開啟 tag immutability）；部署以 digest 鎖定更嚴謹。可追溯：從線上 Pod 的 image 反查 commit、PR、build log。
• 可重現：lock file、固定 base image、CI runner 用容器。
• 快取：依賴快取（uv cache、Go mod cache）、Docker layer 快取（BuildKit cache-from/cache-to）。
• 安全：secret 存在 CI 的 secret store；雲端認證用 OIDC 換短期憑證（GitHub Actions → AWS IAM Role），不放長期 access key；image 簽章（cosign）與 SBOM。
• Promotion：dev → staging → prod 的升級可以是 GitOps repo 中對應 overlay 的 PR（自動或人工核准），每一步都有紀錄。
• DB migration 獨立成步驟（或 ArgoCD PreSync Job），而且要向後相容。

GitHub Actions 完整範例

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]

concurrency:                       # 同一分支新 push 取消舊的 run
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read

env:
  IMAGE: ghcr.io/${{ github.repository_owner }}/events-api

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v5
        with: { enable-cache: true }
      - run: uv sync --frozen
      - run: uv run ruff check .
      - run: uv run ruff format --check .
      - run: uv run mypy app

  test:
    runs-on: ubuntu-latest
    needs: lint
    services:
      postgres:
        image: postgres:16-alpine
        env: { POSTGRES_USER: app, POSTGRES_PASSWORD: app, POSTGRES_DB: events_test }
        ports: ["5432:5432"]
        options: >-
          --health-cmd "pg_isready -U app" --health-interval 5s --health-timeout 3s --health-retries 10
      redis:
        image: redis:7-alpine
        ports: ["6379:6379"]
    env:
      DATABASE_URL: postgresql://app:app@localhost:5432/events_test
      REDIS_URL: redis://localhost:6379/0
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v5
        with: { enable-cache: true }
      - run: uv sync --frozen
      - run: uv run pytest -q --cov=app --cov-report=xml --junitxml=report.xml
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: test-report
          path: |
            report.xml
            coverage.xml

  build-scan-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    permissions:
      contents: read
      packages: write
    outputs:
      tag: ${{ steps.meta.outputs.tag }}
    steps:
      - uses: actions/checkout@v4
      - id: meta
        run: echo "tag=$(date +%Y%m%d)-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: .
          load: true                      # 先載入本機給 scanner 掃
          tags: ${{ env.IMAGE }}:${{ steps.meta.outputs.tag }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
      - uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: ${{ env.IMAGE }}:${{ steps.meta.outputs.tag }}
          severity: CRITICAL,HIGH
          exit-code: "1"                  # 有高風險漏洞就讓 pipeline 失敗
          ignore-unfixed: true
      - run: docker push ${{ env.IMAGE }}:${{ steps.meta.outputs.tag }}

  deploy-dev:
    runs-on: ubuntu-latest
    needs: build-scan-push
    environment: dev                       # 可在 GitHub 設定 environment 的保護規則與核准者
    steps:
      - uses: actions/checkout@v4
        with:
          repository: example-org/k8s-config
          token: ${{ secrets.CONFIG_REPO_TOKEN }}
      - name: Bump image tag (GitOps)
        run: |
          cd apps/events-api/overlays/dev
          kustomize edit set image ${{ env.IMAGE }}=${{ env.IMAGE }}:${{ needs.build-scan-push.outputs.tag }}
          git config user.name ci-bot
          git config user.email ci-bot@example.com
          git commit -am "events-api(dev): ${{ needs.build-scan-push.outputs.tag }}"
          git push
      # 之後 ArgoCD 偵測到 config repo 變更並 sync；prod 則開 PR 由人核准

Jenkins 與 Drone

// Jenkinsfile（Declarative Pipeline）
pipeline {
  agent { kubernetes { yamlFile 'ci/agent-pod.yaml' } }
  options { timeout(time: 30, unit: 'MINUTES'); disableConcurrentBuilds() }
  environment { IMAGE = "registry.example.com/tracking/events-api:${env.GIT_COMMIT.take(7)}" }
  stages {
    stage('Lint & Test') {
      parallel {
        stage('Lint') { steps { sh 'uv run ruff check .' } }
        stage('Test') { steps { sh 'uv run pytest -q --junitxml=report.xml' } }
      }
    }
    stage('Build & Push') {
      when { branch 'main' }
      steps {
        withCredentials([usernamePassword(credentialsId: 'registry', usernameVariable: 'U', passwordVariable: 'P')]) {
          sh 'echo $P | docker login registry.example.com -u $U --password-stdin'
          sh 'docker build -t $IMAGE . && docker push $IMAGE'
        }
      }
    }
    stage('Deploy prod') {
      when { branch 'main' }
      input { message 'Deploy to prod?' }
      steps { sh './ci/bump-gitops.sh prod $IMAGE' }
    }
  }
  post { always { junit 'report.xml' } failure { slackSend channel: '#deploy', message: "FAILED ${env.BUILD_URL}" } }
}

# .drone.yml
kind: pipeline
type: docker
name: default
steps:
  - name: test
    image: ghcr.io/astral-sh/uv:python3.12-bookworm-slim
    commands:
      - uv sync --frozen
      - uv run pytest -q
  - name: publish
    image: plugins/docker
    settings:
      repo: registry.example.com/tracking/events-api
      tags: ["${DRONE_COMMIT_SHA:0:7}"]
      username: { from_secret: registry_user }
      password: { from_secret: registry_password }
    when: { branch: [main], event: [push] }

Ansible：無 agent 的設定管理

Ansible 透過 SSH 連到目標機器執行 module，不需在目標安裝 agent（push 模式）。用在 VM / 實體機的設定（安裝套件、部署 Nginx 設定、調整 sysctl、滾動重啟服務），K8s 時代仍常用於 node 層、資料庫主機、跳板機等。

Inventory

目標主機清單與分組，可靜態檔或動態（從 AWS/GCP API 撈）。

Playbook

YAML 描述「對哪些主機、依序執行哪些 task」。

Module

冪等的操作單元：apt、copy、template、systemd、sysctl、user…

Handler

只在被 notify 且有變更時執行，例如設定檔改了才 reload Nginx。

Role

可重用的 task/template/handler 組合。

冪等（idempotent）

跑一次和跑十次結果相同；第二次執行應顯示 changed=0。避免用 shell/command 做模組能做的事，非用不可時加 creates/changed_when。

# inventory/prod.ini
[api]
api-1.internal ansible_host=10.0.1.11
api-2.internal ansible_host=10.0.1.12

[api:vars]
ansible_user=deploy
app_port=8000

# playbooks/api.yml
- name: Configure API hosts
  hosts: api
  become: true
  serial: 1                        # 一次一台，等於滾動更新
  vars:
    nofile_limit: 65535
  tasks:
    - name: Install packages
      ansible.builtin.apt:
        name: [nginx, chrony]
        state: present
        update_cache: true
        cache_valid_time: 3600

    - name: Tune kernel for many connections
      ansible.posix.sysctl:
        name: "{{ item.key }}"
        value: "{{ item.value }}"
        state: present
        reload: true
      loop:
        - { key: net.core.somaxconn, value: "4096" }
        - { key: net.ipv4.ip_local_port_range, value: "10240 65000" }

    - name: Render nginx site
      ansible.builtin.template:
        src: templates/api.conf.j2
        dest: /etc/nginx/sites-enabled/api.conf
        mode: "0644"
      notify: Reload nginx

    - name: Ensure nginx running
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Reload nginx
      ansible.builtin.systemd:
        name: nginx
        state: reloaded

ansible -i inventory/prod.ini api -m ping
ansible-playbook -i inventory/prod.ini playbooks/api.yml --check --diff   # dry run，看會改什麼
ansible-playbook -i inventory/prod.ini playbooks/api.yml --limit api-1.internal

IaC 與 Terraform 概念

Infrastructure as Code 讓 VPC、子網路、叢集、資料庫、IAM 等雲端資源由程式碼描述、review、版本控制。Terraform（與其開源分支 OpenTofu）是最普遍的工具：

• 宣告式：寫 desired state，terraform plan 計算差異，terraform apply 執行。
• Provider：對接 AWS/GCP/K8s 等 API。Module：可重用的元件。
• State：記錄「程式碼中的資源 ↔ 雲端實際 ID」的對應。團隊必須用 remote state + locking（S3 + 鎖、GCS backend），否則兩人同時 apply 會互相覆蓋；state 可能含敏感資料，要加密與控管存取。
• Drift：有人在 console 手動改資源，下次 plan 會顯示差異。原則是「一律透過程式碼改」。
• 與 Ansible 的分工：Terraform 負責建立基礎設施（provisioning），Ansible 負責機器內部的設定（configuration management）。

# main.tf（HCL）
terraform {
  backend "s3" {
    bucket       = "example-tfstate"
    key          = "tracking/prod.tfstate"
    region       = "ap-northeast-1"
    use_lockfile = true          # 新版 Terraform 支援 S3 原生鎖；舊做法是搭配 DynamoDB table
    encrypt      = true
  }
}

resource "aws_s3_bucket" "raw_events" {
  bucket = "example-raw-events-prod"
}

resource "aws_s3_bucket_lifecycle_configuration" "raw_events" {
  bucket = aws_s3_bucket.raw_events.id
  rule {
    id     = "tiering"
    status = "Enabled"
    filter {}
    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 180
      storage_class = "GLACIER"
    }
    expiration {
      days = 730
    }
  }
}

雲端服務對照：AWS vs GCP 與選型 高頻

職缺列出 EC2、S3、Lambda、ECS、API Gateway、Load Balancer。面試不會要你背所有服務，而是要你知道每一類問題用哪種服務、各自的取捨。

運算服務怎麼選

VPC 網路、IAM、S3、Serverless 與成本優化 進階

VPC 網路基礎

• VPC：一個區域（region）內的私有網路，以 CIDR 定義位址空間（例如 10.0.0.0/16，約 65,536 個位址）。要事先規劃，避免與公司其他 VPC 或機房重疊（之後要 peering / VPN 會衝突）。
• Subnet：在 AWS 上一個 subnet 屬於單一 AZ（GCP 的 subnet 則是 regional）。「public」與「private」的差別在於路由表：public subnet 的 0.0.0.0/0 指向 Internet Gateway；private subnet 指向 NAT Gateway 或沒有對外路由。
• NAT Gateway：讓 private subnet 的機器能主動連出（拉 image、呼叫外部 API），但外部無法主動連入。放在 public subnet，每個 AZ 一個以免單點故障與跨 AZ 流量費。NAT 按小時 + 處理的 GB 計費，流量大時很貴——存取 S3/DynamoDB 應改用 VPC Gateway Endpoint（不經 NAT 且不收資料處理費），其他服務可用 Interface Endpoint（PrivateLink）。
• 高可用：服務至少跨 2–3 個 AZ；但跨 AZ 傳輸要收費，chatty 的服務間呼叫要注意（K8s 可用 topology-aware routing）。

IAM 與最小權限

• 最小權限（least privilege）：只給完成工作所需的動作與資源，例如只能 s3:PutObject 到特定 bucket 的特定 prefix，而不是 s3:* on *。
• 用 Role 不用長期 key：EC2 用 instance profile；EKS 用 IRSA（IAM Roles for Service Accounts）或 EKS Pod Identity；GKE 用 Workload Identity；CI 用 OIDC federation。全部都是自動輪替的短期憑證。
• Policy 評估邏輯：預設拒絕 → 任何明確 Deny 優先 → 有 Allow 才放行。另有 SCP（組織層）、permission boundary、resource policy（如 bucket policy）共同決定。
• 人員使用 SSO + MFA，root 帳號鎖起來；以 CloudTrail / Cloud Audit Logs 稽核；定期用 IAM Access Analyzer 找出未使用的權限。
• 多帳號 / 多專案隔離環境（prod 與 dev 分開），爆炸半徑更小。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteRawEventsOnly",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::example-raw-events-prod/ingest/*"
    },
    {
      "Sid": "ReadModelArtifacts",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-models/bidder/*"
    }
  ]
}

S3：一致性、presigned URL 與常見設計

• 一致性：自 2020 年 12 月起，S3 對所有 GET/PUT/LIST/DELETE 提供強的 read-after-write 一致性（寫入成功後立即讀得到新版本、LIST 立即可見），不再是過去的最終一致。但同一 key 的並行寫入仍是 last-writer-wins，沒有鎖；需要條件寫入時可用 If-None-Match / If-Match conditional write。
• 不是檔案系統：沒有真正的目錄（prefix 只是 key 的一部分）、不能 append 或部分修改物件、rename = copy + delete。
• 效能：每個 prefix 每秒可支援數千次請求（官方數字為 PUT 類 3,500、GET 類 5,500 RPS per prefix），用多個 prefix 平行即可擴展；大檔用 multipart upload。
• 小檔問題：每個事件一個物件會造成大量請求費用與下游 Spark 讀取緩慢，應在上游 batch 成較大的檔案（例如每分鐘一個 Parquet/壓縮 JSON 檔，以 dt=2025-01-01/hour=13/ 分區）。
• Presigned URL：後端用自己的憑證對「某個操作 + 某個 key + 到期時間」簽章，產生一個暫時的 URL 交給 client，client 直接上傳/下載 S3，流量不經過你的伺服器。適合使用者上傳大檔、私有報表下載。有效期由 ExpiresIn 決定，SigV4 最長 7 天，且若以臨時憑證（role）簽發，憑證過期時 URL 也失效。

import boto3
from botocore.config import Config

s3 = boto3.client("s3", region_name="ap-northeast-1", config=Config(signature_version="s3v4"))

def presign_report_download(report_id: str, user_id: str) -> str:
    # 先做授權檢查：這個 user 能否看這份報表（presigned URL 本身任何人拿到都能用）
    key = f"reports/{user_id}/{report_id}.csv.gz"
    return s3.generate_presigned_url(
        "get_object",
        Params={"Bucket": "example-reports", "Key": key,
                "ResponseContentDisposition": f'attachment; filename="{report_id}.csv.gz"'},
        ExpiresIn=600,   # 10 分鐘
    )

def presign_sdk_upload(app_id: str, batch_id: str) -> dict:
    # presigned POST 可限制大小與 content-type
    return s3.generate_presigned_post(
        Bucket="example-raw-events-prod",
        Key=f"ingest/app={app_id}/{batch_id}.json.gz",
        Conditions=[["content-length-range", 1, 10 * 1024 * 1024],
                    {"Content-Type": "application/gzip"}],
        Fields={"Content-Type": "application/gzip"},
        ExpiresIn=300,
    )

Serverless 的優缺點

成本優化

Git 進階：rebase、cherry-pick、bisect、reflog 與分支策略 高頻 基礎

職缺明列 Git。實習生面試常問「merge 和 rebase 差在哪？」「不小心 reset 掉 commit 怎麼救？」「你們團隊用什麼 branching strategy？」。先建立正確的心智模型：commit 是不可變的快照，以 parent 指標串成 DAG；branch 只是一個指向 commit 的可移動指標；HEAD 指向目前的 branch。

Merge vs Rebase

黃金守則：不要 rebase 別人也在用的公開分支。自己的 PR 分支 rebase 後要推送時用 git push --force-with-lease（若遠端被別人更新過會拒絕），而不是 --force。

# 讓自己的 feature branch 跟上 main
git fetch origin
git rebase origin/main            # 遇衝突：修改檔案 → git add → git rebase --continue（或 --abort 放棄）
git push --force-with-lease

# 互動式 rebase：在發 PR 前整理 commit（squash 修正、改訊息、調順序、刪除）
git rebase -i origin/main
#   pick   3f9c2ab feat(events): add batch ingestion endpoint
#   fixup  a1b2c3d fix typo           ← 併入上一個 commit 並丟棄訊息
#   reword 7d8e9f0 add tests          ← 修改 commit message
#   drop   1122aab debug print        ← 刪除
# 小技巧：git commit --fixup=<sha> 之後 git rebase -i --autosquash 自動排好

cherry-pick、bisect、reflog

# cherry-pick：把某個 commit 的變更套到目前分支（例如把 hotfix 帶到 release 分支）
git switch release/1.8
git cherry-pick 3f9c2ab               # 產生新 commit；-x 會在訊息附上來源 hash
git cherry-pick A^..B                 # 一段範圍

# bisect：二分搜尋找出「哪個 commit 引入 bug」——O(log n) 次測試
git bisect start
git bisect bad                        # 目前版本有 bug
git bisect good v1.7.0                # 這個版本沒問題
#   Git checkout 中間的 commit，測完告訴它 good / bad，重複直到找到
git bisect run uv run pytest tests/test_dedup.py -q   # 全自動：exit 0 = good，非 0 = bad（125 = skip）
git bisect reset

# reflog：HEAD 與 branch 移動的本機紀錄（預設保留約 90 天），救援神器
git reset --hard HEAD~3               # 糟了，三個 commit 不見了
git reflog                            # 找到 reset 前的位置，例如 HEAD@{1}
git reset --hard HEAD@{1}             # 或 git branch rescue <sha>
# 刪掉的 branch、rebase 弄壞的歷史，都能從 reflog 找回（只要還沒被 gc）

# 其他常用
git stash push -m "wip" ; git stash pop
git restore --staged file.py          # 取消 add
git revert <sha>                      # 對已推送的 commit 產生「反向 commit」，不改寫歷史
git log --oneline --graph --decorate --all
git blame -L 120,160 app/ingest.py ; git log -S "dedup_key" -p   # 找某段程式碼何時被加入

Branching strategy

Commit message 規範

feat(ingest): batch events into 1-minute gzip files on S3

Writing one object per event caused ~40k PUT/s and slow Spark scans.
Buffer events per (app_id, minute) and flush when 5 MB or 60 s.

- add EventBuffer with size/time based flush
- graceful shutdown flushes pending buffers on SIGTERM

Refs: TRACK-123

Conventional Commits：type(scope): subject，type 常見有 feat、fix、refactor、perf、test、docs、chore、ci；subject 用祈使句、50 字元左右；body 說明為什麼而不只是做了什麼。好處：可自動產生 changelog 與 semver。

解 merge conflict 的流程

1. git status 看哪些檔案衝突；衝突區塊以 <<<<<<< HEAD、=======、>>>>>>> branch 標示。
2. 理解兩邊的意圖，而不是單純選一邊——看 git log -p --merge 或 PR 說明，必要時找作者確認。設 git config merge.conflictstyle zdiff3 可同時看到共同祖先版本，更容易判斷。
3. 編輯成正確結果，刪除標記，跑測試（語意衝突不會被 Git 偵測到，例如對方改了函式簽名、你新增了呼叫）。
4. git add 後 git commit（merge）或 git rebase --continue。
5. 預防勝於治療：小 PR、頻繁同步 main、避免大範圍格式化與功能修改混在一起。

Appier 情境：Bidder 依 QPS 擴展、Spot 節點跑批次 深入

Bidder：為什麼用 QPS 而不只用 CPU 擴展？

• CPU 是落後指標：流量暴增時，CPU 拉高 → metrics-server 抓到（約 15 秒以上）→ HPA 計算 → Pod 啟動 → 通過 readiness，可能已過一兩分鐘；期間延遲飆升、bid timeout 就是直接損失營收。
• bidder 的瓶頸可能不是 CPU（例如等 Redis / 特徵服務、連線數），CPU 使用率不能反映飽和。
• QPS per Pod 與容量的對應關係可以壓測得出（例如單 Pod 在 p99 < 50ms 下能撐 800 QPS），直接把目標設在安全水位（例如 600）。

# 方案一：HPA + Prometheus Adapter 暴露的自訂指標（Pods 類型）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: bidder, namespace: rtb }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: bidder }
  minReplicas: 30                    # 依歷史低峰 + 安全餘裕，避免縮太小來不及長回來
  maxReplicas: 400
  metrics:
    - type: Pods
      pods:
        metric: { name: bid_requests_per_second }     # adapter 由 rate(bid_requests_total[1m]) 轉出
        target: { type: AverageValue, averageValue: "600" }
    - type: Resource                  # 多指標時取「建議副本數最大」的那個，CPU 當保險
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 65 } }
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      selectPolicy: Max
      policies:
        - { type: Percent, value: 100, periodSeconds: 15 }
        - { type: Pods, value: 20, periodSeconds: 15 }
    scaleDown:
      stabilizationWindowSeconds: 600   # 慢慢縮，避免流量回彈時來不及
      policies: [{ type: Percent, value: 5, periodSeconds: 60 }]
---
# 方案二：KEDA（內部會建立並管理 HPA），直接寫 PromQL
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: bidder, namespace: rtb }
spec:
  scaleTargetRef: { name: bidder }
  minReplicaCount: 30
  maxReplicaCount: 400
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: sum(rate(bid_requests_total{service="bidder"}[1m]))
        threshold: "600"              # 每個副本的目標值

完整的擴展設計還需要：

1. Node 層擴展要跟得上：Pod 擴了但 node 不夠會 Pending。用 Karpenter / Cluster Autoscaler，並保留少量overprovisioning（低優先級的 placeholder Pod 佔位，高優先級 bidder 要排程時把它們擠掉，立刻有空間）。
2. 啟動要快：image 小、模型與設定預載、startupProbe 合理、readiness 只在暖機完成後才通過（避免冷 Pod 一進來就 timeout）。
3. 可預期的尖峰用排程擴容：大型購物節前預先拉高 minReplicas（CronJob 修改 HPA 或 KEDA cron trigger）。
4. 過載保護：擴容來不及時，bidder 應快速回 no-bid（load shedding）而不是排隊等到超時；readiness 在 in-flight 過高時暫時回 503。
5. 縮容平穩：PDB、preStop + graceful shutdown，確保縮容時沒有 bid request 被中斷。
6. 跨 AZ 分散：topologySpreadConstraints，避免單一 AZ 故障影響太大。

Spot 節點跑批次

# Spot node pool 打上 taint，只有明確容忍的批次工作會被排上去
# (EKS 受管節點群組的標籤為 eks.amazonaws.com/capacityType=SPOT；
#  Karpenter 為 karpenter.sh/capacity-type=spot；GKE 為 cloud.google.com/gke-spot=true)
apiVersion: batch/v1
kind: Job
metadata: { name: feature-backfill-20250101, namespace: analytics }
spec:
  parallelism: 50
  completions: 500                 # 500 個分片，每個 Pod 處理一片
  completionMode: Indexed          # Pod 取得 JOB_COMPLETION_INDEX，分片可重跑且冪等
  backoffLimitPerIndex: 3
  podFailurePolicy:
    rules:
      - action: Ignore             # 被 spot 回收造成的中斷不計入失敗次數
        onPodConditions: [{ type: DisruptionTarget }]
  template:
    spec:
      restartPolicy: Never
      priorityClassName: batch-low
      tolerations:
        - { key: "spot", operator: "Equal", value: "true", effect: "NoSchedule" }
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - { key: karpenter.sh/capacity-type, operator: In, values: ["spot"] }
      terminationGracePeriodSeconds: 90   # 小於 AWS 2 分鐘通知，來得及存 checkpoint
      containers:
        - name: worker
          image: registry.example.com/analytics/backfill:3.1.0
          args: ["--date", "2025-01-01", "--checkpoint", "s3://example-ckpt/backfill/"]
          resources:
            requests: { cpu: "2", memory: 4Gi }
            limits: { memory: 4Gi }

• 可中斷設計：工作切成小分片、每片冪等（寫入以分片 ID 覆蓋，而非 append）、定期 checkpoint 到 S3，被回收後從 checkpoint 續跑。
• 中斷處理：AWS Node Termination Handler 或 Karpenter 的 interruption handling 收到 2 分鐘通知後 cordon + drain node，Pod 收到 SIGTERM 存檔退出。
• 多樣化：允許多種機型與多個 AZ，降低同時被回收的機率；Karpenter 會挑選價格與可得性較佳的組合。
• Spark on K8s：driver 放 on-demand（driver 掛掉整個 job 重來），executor 放 spot（掉了只重算該 task 的分區）。
• 線上服務不放 spot，或只把一部分可替換的副本放 spot，且保證 on-demand 基線足以承載。

面試自測題