Kubernetes：Webhook 伺服器憑證

在 Kubernetes 的 Webhook 設定中，伺服器憑證是確保安全通訊的關鍵元素。當 Kubernetes API 伺服器與 Webhook 伺服器通訊時，需要透過 TLS 加密連線來保護資料傳輸安全。這部分將探討 Webhook 伺服器憑證的設定與管理。

憑證的重要性與作用

Webhook 伺服器憑證在 Kubernetes 安全架構中扮演著關鍵角色：

身份驗證：憑證確保 API 伺服器只與受信任的 Webhook 伺服器通訊
加密通訊：防止敏感資料在傳輸過程中被竊聽或篡改
完整性保障：確保資料在傳輸過程中不被修改

憑證設定方式

在 Webhook 設定中，有兩種主要方式來設定伺服器憑證：

1. 使用 `caBundle` 欄位

最常見的方法是在 Webhook 設定中提供 CA 憑證捆綁包：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: example-webhook
webhooks:
- name: webhook.example.com
  clientConfig:
    url: https://webhook.example.com:8443/validate
    caBundle: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQVRBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1EZ3lNREF6TURVeE1Gb1hEVEl5TURneU1EQXpNRFV4TUZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTXR5CnVDOHRQODlqNGRoRmZ1K0x5Yk5KcmNYOGJyVzFhbUJEQjdtNzl0WkdIaWZKcVNxK1hGcWVhV3YwZWtRZlFLUlYKUkxuNWlWMUQyU0xTR0JFRnhFbkN0YjRwUERHZ0FuM3JQbDk5QzRYdkpJdHlZL3JpNVdOeUFwYmZvU3RnRXBvdgpVTkM1bXFpTmY1OHJYdmFUUk5BcUhJbDZCMVhzQXBpOFNwYWlWMDNXWWQ3U0QvWXk1Sm1VQlhLWW5LWnFzS2RlCjZEL1ZNM0h6L0hZVFJnK2FLdkV5TjJTNlJKUmFJa2pTUUJ5c3ZUK0NNZnlzL3RrRGlGVkc4WEZ3YkZFNHRsRHMKYjRCbDZZcGtDOUdIaFZPNTlHVXRQWXhHYXJIVk5qQkNsQlhJUFJDVDZlODNWaUZFaXVEQXZSWGRhcjFWTlZZNQpLbWxoWnJVWGJNVUNBd0VBQWFOQ01FQXdEZ1lEVlIwUEFRSC9CQVFEQWdLa01BOEdBMVVkRXdFQi93UUZNQU1CCkFmOHdIUVlEVlIwT0JCWUVGSm1wQjFkbkRJeVgrZUZMVVRQbHBuaE5GODdHTUEwR0NTcUdTSWIzRFFFQkN3VUEKQTRJQkFRQXdHQTZnY3dHUUZnY0F1dkMrY0dYV0FyUUhPOXJpWld1Q1ZVeXRkYmRnK1J2Qk0vZkZOcEFOQWZBVwpJTWxQcVMzRWxQYkJUNHNVMmFMUjVFb2RhNUVRcHBxWHJZaXdkS2pWVHU4WFZGK2tFOGJQZ0QyVEpVd2FBT0VlCnRGMUhHL0pFZzlVQ2QrSk9mMUlrTUFSNGFMaGl5YXlYNWNkTGVQZVpnL0JuVkdtUjJmZWZYcXI1ZFEzWWZYdVgKNWJsNm1tN2hqT3N1MjJhQVJXcFgxK2tDa1BQTWRqK1JzQXRxZDZPVXdla0xzMUNXTlRsTEV4UEtjS2dIZ0xWZApVRHBZS0JxdlBDTUxQOWVsUUZCb1FVOGVISVRqYTJvVnJ5eHZVQkJ1V1lUanE5VkxsRnlJOUF0aFNLQzlDSWdlCnRSYkVaZ2xJTWZPUGRCZUJiNVdsCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

這段設定中的 caBundle 欄位包含了 Base64 編碼的 CA 憑證。API 伺服器會使用這個 CA 憑證來驗證 Webhook 伺服器的身份。這個憑證必須是簽發 Webhook 伺服器 TLS 憑證的 CA 憑證，確保 API 伺服器能夠信任 Webhook 伺服器提供的憑證。

2. 使用服務參考與自動注入

另一種方法是使用 Kubernetes 服務參考，並讓系統自動注入 CA 憑證：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: example-webhook
  annotations:
    cert-manager.io/inject-ca-from: "namespace/certificate-name"
webhooks:
- name: webhook.example.com
  clientConfig:
    service:
      namespace: webhook-namespace
      name: webhook-service
      path: "/validate"
      port: 443

這種設定方式使用了 service 欄位指向 Kubernetes 叢集內的服務，而非直接使用 URL。注意這裡使用了 cert-manager.io/inject-ca-from 註解，這是與 cert-manager 整合的方式，允許 cert-manager 自動注入正確的 CA 憑證到 Webhook 設定中。這種方法大簡化了憑證管理流程。

使用 cert-manager 管理 Webhook 憑證

cert-manager 是 Kubernetes 生態系統中流行的憑證管理工具，它可以大幅簡化 Webhook 憑證的建立和管理：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: webhook-cert
  namespace: webhook-namespace
spec:
  secretName: webhook-tls
  duration: 8760h # 1 年
  renewBefore: 720h # 30 天
  subject:
    organizations:
      - "Example Organization"
  isCA: false
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
  usages:
    - server auth
  dnsNames:
    - webhook-service.webhook-namespace.svc
    - webhook-service.webhook-namespace.svc.cluster.local
  issuerRef:
    name: webhook-issuer
    kind: Issuer
    group: cert-manager.io

這個 Certificate 資源定義了 Webhook 伺服器需要的 TLS 憑證。關鍵點包括：

secretName：指定儲存憑證的 Secret 名稱
duration 和 renewBefore：設定憑證有效期和提前更新時間
dnsNames：包含 Webhook 服務的所有可能 DNS 名稱，確保憑證對服務有效
usages：指定憑證用途為伺服器認證
issuerRef：指向將簽發此憑證的 cert-manager Issuer 或 ClusterIssuer

自簽憑證的建立與使用

在開發或測試環境中，可能需要快速建立自簽憑證。以下是使用 OpenSSL 建立自簽憑證的步驟：

# 建立 CA 私鑰和憑證
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -subj "/CN=Webhook CA"

# 建立伺服器私鑰
openssl genrsa -out server.key 2048

# 建立伺服器憑證簽名請求 (CSR)
openssl req -new -key server.key -out server.csr -subj "/CN=webhook-service.webhook-namespace.svc"

# 使用 CA 簽署伺服器憑證
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

這個 Shell 指令碼展示了建立自簽憑證的完整流程：

首先建立一個自簽 CA（憑證授權機構）
然後為 Webhook 伺服器建立私鑰
使用私鑰生成憑證簽名請求 (CSR)
最後使用 CA 簽署伺服器憑證

生成的 ca.crt 檔案需要 Base64 編碼後填入 Webhook 設定的 caBundle 欄位：

cat ca.crt | base64 | tr -d '\n'

憑證輪換與更新策略

憑證管理不僅是初始設定，還需要考慮憑證的輪換與更新：

自動輪換：使用 cert-manager 可以自動處理憑證更新
監控過期時間：設定監控以提前發現即將過期的憑證
無縫更新：確保憑證更新不會導致服務中斷

在生產環境中，建議實施以下最佳實踐：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: webhook-cert
  namespace: webhook-namespace
spec:
  secretName: webhook-tls
  duration: 2160h # 90 天
  renewBefore: 360h # 15 天
  privateKey:
    rotationPolicy: Always # 每次更新都輪換私鑰
  # 其他設定...

這個設定範例展示了生產環境中的憑證輪換策略：

使用較短的憑證有效期（90天），符合現代安全最佳實踐
提前15天開始嘗試更新，確保有足夠時間處理可能的問題
rotationPolicy: Always 確保每次更新都生成新的私鑰，增強安全性

故障排除與常見問題

在設定 Webhook 憑證時，常見的問題包括：

憑證驗證失敗：API 伺服器無法驗證 Webhook 伺服器的憑證
- 檢查 caBundle 是否正確
- 確認 Webhook 伺服器使用的憑證是由提供的 CA 簽發的
名稱不比對：憑證中的 DNS 名稱與實際服務名稱不比對
- 確保憑證包含所有可能的服務 DNS 名稱
憑證過期：憑證已過期導致連線失敗
- 實施自動輪換機制
- 設定監控和警示

以下是一個診斷指令碼範例：

#!/bin/bash
# 檢查 Webhook 憑證設定

# 取得 Webhook 設定
kubectl get validatingwebhookconfigurations -o yaml > webhooks.yaml

# 提取 caBundle 並解碼
grep -A1 caBundle webhooks.yaml | grep -v caBundle | sed 's/^[ \t]*//' > cabundle.b64
base64 -d cabundle.b64 > ca.crt

# 檢查憑證資訊
openssl x509 -in ca.crt -text -noout

# 檢查 Webhook 服務連線
WEBHOOK_SVC=$(grep -A3 service webhooks.yaml | grep name | head -1 | awk '{print $2}')
WEBHOOK_NS=$(grep -A3 service webhooks.yaml | grep namespace | head -1 | awk '{print $2}')
WEBHOOK_PORT=$(grep -A3 service webhooks.yaml | grep port | head -1 | awk '{print $2}')

echo "Testing connection to $WEBHOOK_SVC.$WEBHOOK_NS:$WEBHOOK_PORT"
kubectl run -it --rm test --image=curlimages/curl --restart=Never -- \
  curl -v --cacert /tmp/ca.crt https://$WEBHOOK_SVC.$WEBHOOK_NS:$WEBHOOK_PORT

這個診斷指令碼幫助排查 Webhook 憑證問題：

提取當前的 Webhook 設定
解碼 caBundle 以檢查 CA 憑證
顯示憑證詳細資訊，包括有效期和主體
嘗試連線 Webhook 服務以驗證 TLS 設定是否正確

安全最佳實踐

為確保 Webhook 憑證的安全性，建議遵循以下最佳實踐：

最小許可權原則：確保憑證只包含必要的許可權和用途
短期憑證：使用較短的憑證有效期（如90天）
私鑰保護：妥善保護私鑰，使用 Kubernetes Secrets 儲存
自動化管理：使用工具如 cert-manager 自動化憑證生命週期
監控與警示：設定監控以檢測憑證問題和即將到期的憑證

與服務網格的整合

在使用服務網格（如 Istio 或 Linkerd）的環境中，可以利用服務網格的 mTLS 功能來簡化 Webhook 憑證管理：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: webhook-mtls
  namespace: webhook-namespace
spec:
  host: webhook-service.webhook-namespace.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

這個 Istio DestinationRule 設定啟用了 Webhook 服務的 mTLS（相互 TLS）。使用 ISTIO_MUTUAL 模式時，Istio 會自動處理憑證的建立、分發和輪換，大簡化了憑證管理流程。這種方法特別適合在已經使用服務網格的環境中。

Webhook 伺服器憑證是 Kubernetes 安全架構中的重要組成部分。正確設定和管理這些憑證不僅能確保 API 伺服器與 Webhook 之間的安全通訊，還能防止潛在的安全漏洞。透過使用現代工具如 cert-manager 和遵循最佳實踐，可以大簡化憑證管理流程，同時保持高水準的安全性。

規則（Rules）

在 Kubernetes 的 Webhook 設定中，rules 欄位定義了 Webhook 將處理哪些資源的哪些操作。這是 Webhook 功能的核心部分，決定了 Webhook 的觸發條件和範圍。

規則的基本結構

規則定義了 Webhook 應該攔截的請求型別。以下是一個基本的規則結構：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: example-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["deployments", "statefulsets"]
    scope: "Namespaced"

這個規則設定指定了 Webhook 將處理以下請求：

針對 apps API 群組中的資源
僅處理 API 版本 v1 的資源
只攔截 CREATE 和 UPDATE 操作
只處理 deployments 和 statefulsets 資源型別
只處理名稱空間範圍的資源（排除叢集範圍資源）

規則欄位詳解

1. `apiGroups`

定義 Webhook 處理的 API 群組列表：

apiGroups: ["", "apps", "batch"]

空字串 "" 代表核心 API 群組（如 Pod、Service）
apps 群組包含 Deployment、有狀態集合等
batch 群組包含工作、定時工作等
可以使用 ["*"] 比對所有 API 群組

2. `apiVersions`

指定 Webhook 處理的 API 版本：

apiVersions: ["v1", "v1beta1"]

可以指定多個 API 版本
常見版本包括 v1、v1beta1、v1alpha1 等
可以使用 ["*"] 比對所有版本

3. `operations`

定義 Webhook 攔截的操作型別：

operations: ["CREATE", "UPDATE", "DELETE", "CONNECT"]

CREATE：建立新資源時觸發
UPDATE：更新現有資源時觸發
DELETE：刪除資源時觸發
CONNECT：用於 Pod exec、port-forward 等連線操作
*：比對所有操作型別

4. `resources`

指定 Webhook 處理的資源型別：

resources: ["pods", "deployments"]
resources: ["deployments/status"]
resources: ["pods/*"]

可以指定具體資源型別如 pods、deployments
可以使用 資源/子資源 格式指定子資源，如 deployments/status
可以使用 資源/* 比對資源的所有子資源
可以使用 * 比對所有資源型別

5. `scope`

定義 Webhook 處理的資源範圍：

scope: "Namespaced"  # 或 "Cluster"

Namespaced：只處理名稱空間範圍的資源（如 Pod、Deployment）
Cluster：只處理叢集範圍的資源（如 Node、PersistentVolume）
如果不指定，則處理所有範圍的資源

複雜規則範例

以下是一個更複雜的規則設定，展示了多種比對條件的組合：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: advanced-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["pods"]
    scope: "Namespaced"
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE", "DELETE"]
    resources: ["deployments", "statefulsets"]
    scope: "Namespaced"
  - apiGroups: ["batch"]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["jobs", "cronjobs"]
    scope: "Namespaced"

這個設定定義了三組不同的規則，每組針對不同的資源型別和操作：

第一組規則處理核心 API 群組中的 Pod 資源的建立和更新操作
第二組規則處理 apps 群組中的 Deployment 和有狀態集合資源的建立、更新和刪除操作
第三組規則只處理 batch 群組中的工作和定時工作資源的建立操作

這種分層規則允許精確控制 Webhook 的觸發條件，避免不必要的呼叫。

使用萬用字元

萬用字元可以簡化規則設定，但需要謹慎使用：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: wildcard-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["*"]
    apiVersions: ["*"]
    operations: ["*"]
    resources: ["*"]

這個設定使用萬用字元比對所有可能的請求，這意味著 Webhook 將處理叢集中的每個 API 請求。雖然這提供了最大的覆寫範圍，但可能導致效能問題，並增加 Webhook 故障影響整個叢集的風險。在生產環境中，應該避免使用如此廣泛的規則，除非絕對必要。

子資源處理

子資源是資源的特殊檢視或操作端點。處理子資源需要特殊的規則設定：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: subresource-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["UPDATE"]
    resources: ["deployments/status"]
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CONNECT"]
    resources: ["pods/exec", "pods/portforward"]

這個設定展示瞭如何處理特定子資源：

第一條規則只處理 Deployment 資源的 status 子資源的更新操作
第二條規則處理 Pod 的 exec 和 portforward 子資源的連線操作

子資源規則允許更精細地控制 Webhook 的行為，只攔截特定型別的操作。

規則最佳化與效能考量

Webhook 規則設定不僅影響功能，還會影響效能。以下是一些最佳化建議：

最小化規則範圍：只攔截真正需要驗證或修改的資源和操作
避免萬用字元：除非必要，避免使用 * 萬用字元
合併相似規則：將相似的規則合併，減少規則數量
考慮資源使用頻率：頻繁使用的資源（如 Pod）的 Webhook 應特別高效

# 不推薦：過於寬泛的規則
rules:
- apiGroups: ["*"]
  apiVersions: ["*"]
  operations: ["*"]
  resources: ["*"]

# 推薦：精確定義的規則
rules:
- apiGroups: ["apps"]
  apiVersions: ["v1"]
  operations: ["CREATE", "UPDATE"]
  resources: ["deployments"]

這個對比展示了規則最佳化的重要性：

第一個例子使用萬用字元比對所有請求，可能導致不必要的 Webhook 呼叫和效能問題
第二個例子精確指定了只需要處理的資源和操作，大減少了 Webhook 的呼叫次數

規則測試與驗證

在佈署到生產環境前，應該測試 Webhook 規則是否按預期工作：

# 建立測試資源並觀察 Webhook 是否觸發
kubectl apply -f test-deployment.yaml

# 檢查 Webhook 日誌
kubectl logs -n webhook-namespace -l app=webhook-server

# 使用 dry-run 測試 Webhook 行為
kubectl apply -f test-deployment.yaml --dry-run=server

這些命令可以幫助測試 Webhook 規則：

建立測試資源以觸發 Webhook
檢查 Webhook 伺服器日誌以確認是否正確處理了請求
使用 --dry-run=server 選項測試 Webhook 行為而不實際建立資源

排除特定名稱空間

在某些情況下，可能需要排除特定名稱空間的資源，這可以透過 namespaceSelector 實作：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: namespace-selective-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["deployments"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values: ["kube-system", "kube-public"]

這個設定使用 namespaceSelector 排除了 kube-system 和 kube-public 名稱空間。這是一個重要的安全實踐，可以防止 Webhook 幹擾關鍵系統元件。注意這個設定與 rules 是分開的，但兩者共同決定了 Webhook 的觸發條件。

故障安全機制

為了防止 Webhook 故障影響整個叢集，可以設定故障安全機制：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: failsafe-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["deployments"]
  failurePolicy: Ignore
  timeoutSeconds: 5

這個設定包含兩個重要的故障安全機制：

failurePolicy: Ignore 表示如果 Webhook 無法存取或超時，API 請求將被允許繼續處理
timeoutSeconds: 5 設定了 5 秒的超時間，防止 Webhook 回應過慢導致 API 伺服器等待過長時間

這些設定對於生產環境至關重要，可以防止 Webhook 故障導致整個叢集不可用。

規則與標籤選擇器的結合

可以將規則與物件選擇器結合，只處理帶有特定標籤的資源：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: label-selective-webhook
webhooks:
- name: webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["deployments"]
  objectSelector:
    matchLabels:
      webhook-validation: "enabled"

這個設定使用 objectSelector 只處理帶有 webhook-validation: enabled 標籤的資源。這提供了一種選擇性啟用 Webhook 驗證的方法，可以逐步推出 Webhook 功能或只對特定資源應用驗證。

多 Webhook 協調

在複雜環境中，可能有多個 Webhook 處理相同的資源。這時需要考慮 Webhook 的執行順序：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: ordered-webhook
webhooks:
- name: first.webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["deployments"]
  matchPolicy: Exact
  reinvocationPolicy: Never
- name: second.webhook.example.com
  # 其他設定...
  rules:
  - apiGroups: ["apps"]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["deployments"]
  matchPolicy: Equivalent
  reinvocationPolicy: IfNeeded

這個設定展示了多 Webhook 協調的關鍵設定：

matchPolicy: Exact 表示只有完全比對規則的請求才會觸發 Webhook
matchPolicy: Equivalent 允許比對等效的資源版本
reinvocationPolicy: Never 表示 Webhook 只會被呼叫一次
reinvocationPolicy: IfNeeded 表示如果資源被其他 Webhook 修改，可能會重新呼叫此 Webhook

這些設定對於管理複雜的 Webhook 鏈非常重要，可以控制 Webhook 的執行順序和重複呼叫行為。

Webhook 規則是定義 Webhook 行為的核心元素。透過精確設定規則，可以確保 Webhook 只處理需要的資源和操作，同時保持系統的效能和穩定性。在設計 Webhook 規則時，應該遵循最小許可權原則，只攔截真正需要處理的請求，並實施適當的故障安全機制，防止 Webhook 故障影響整個叢集。

側邊車（Sidecar）模式與 Webhook 整合

在 Kubernetes 生態系統中，側邊車模式是一種強大的設計模式，可以與 Webhook 結合使用，建立更強大、更靈活的解決方案。這種整合特別適合需要深度整合到 Kubernetes 控制平面的複雜應用場景。

側邊車模式基本概念

側邊車模式是一種將輔助功能佈署為獨立容器但與主應用分享資源的架構模式：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-sidecar
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    volumeMounts:
    - name: shared-data
      mountPath: /data
  - name: sidecar
    image: example/webhook-sidecar:v1
    volumeMounts:
    - name: shared-data
      mountPath: /data
  volumes:
  - name: shared-data
    emptyDir: {}

這個 Pod 定義展示了基本的側邊車模式：

webhook-server 容器執行主要的 Webhook 邏輯
sidecar 容器提供輔助功能
兩個容器透過分享卷 shared-data 進行通訊
兩個容器分享相同的網路名稱空間，可以透過 localhost 互相存取

側邊車與 Webhook 的整合場景

側邊車模式可以在多種 Webhook 場景中提供價值：

1. 憑證管理側邊車

自動處理 Webhook TLS 憑證的建立、更新和輪換：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-cert-manager
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    volumeMounts:
    - name: certs
      mountPath: /etc/webhook/certs
      readOnly: true
  - name: cert-manager-sidecar
    image: example/cert-manager-sidecar:v1
    volumeMounts:
    - name: certs
      mountPath: /etc/webhook/certs
  volumes:
  - name: certs
    emptyDir: {}

這個設定中的 cert-manager-sidecar 容器專門負責：

生成和更新 TLS 憑證
將憑證儲存在分享卷中
監控憑證過期並自動更新
在更新後通知主 Webhook 容器重新載入憑證

這種分離關注點的方法使主 Webhook 服務可以專注於其核心邏輯，而將複雜的憑證管理委託給專門的側邊車。

2. 日誌增強側邊車

捕捉、處理和轉發 Webhook 日誌：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-logging
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    volumeMounts:
    - name: logs
      mountPath: /var/log/webhook
  - name: logging-sidecar
    image: fluent/fluent-bit:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log/webhook
    - name: fluent-bit-config
      mountPath: /fluent-bit/etc/
  volumes:
  - name: logs
    emptyDir: {}
  - name: fluent-bit-config
    configMap:
      name: fluent-bit-config

這個設定使用 Fluent Bit 作為日誌處理側邊車：

主 Webhook 容器將日誌寫入分享卷
日誌側邊車讀取、處理並轉發這些日誌
可以實作日誌增強、過濾、格式轉換和集中儲存
主容器不需要了解複雜的日誌處理邏輯

3. 設定多載側邊車

監控和動態更新 Webhook 設定：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-config-reloader
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    volumeMounts:
    - name: config
      mountPath: /etc/webhook/config
    env:
    - name: CONFIG_HASH
      value: ""
  - name: config-reloader
    image: example/config-reloader:v1
    volumeMounts:
    - name: config
      mountPath: /etc/webhook/config
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
  volumes:
  - name: config
    configMap:
      name: webhook-config

這個設計中的 config-reloader 側邊車：

監控 ConfigMap 變化
當設定更改時，更新分享卷中的設定檔案
透過更新環境變數 CONFIG_HASH 或傳送訊號通知主容器重新載入設定
允許在不重啟 Pod 的情況下動態更新 Webhook 設定

高階側邊車模式實作

多功能側邊車設計

複雜 Webhook 可能需要多個側邊車協同工作：

apiVersion: v1
kind: Pod
metadata:
  name: advanced-webhook
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    volumeMounts:
    - name: certs
      mountPath: /etc/webhook/certs
    - name: config
      mountPath: /etc/webhook/config
    - name: cache
      mountPath: /var/cache/webhook
  - name: cert-manager
    image: example/cert-manager:v1
    volumeMounts:
    - name: certs
      mountPath: /etc/webhook/certs
  - name: config-reloader
    image: example/config-reloader:v1
    volumeMounts:
    - name: config
      mountPath: /etc/webhook/config
  - name: cache-warmer
    image: example/cache-warmer:v1
    volumeMounts:
    - name: cache
      mountPath: /var/cache/webhook
  volumes:
  - name: certs
    emptyDir: {}
  - name: config
    configMap:
      name: webhook-config
  - name: cache
    emptyDir: {}

這個高階設計包含多個專用側邊車：

cert-manager 處理 TLS 憑證
config-reloader 管理動態設定更新
cache-warmer 預熱和維護 Webhook 使用的快取資料
每個側邊車專注於特定功能，透過分享卷與主容器通訊

這種模組化設計使系統更易於維護和擴充套件，每個元件可以獨立更新和擴充套件。

側邊車通訊模式

側邊車與主容器之間的通訊可以透過多種方式實作：

分享檔案系統：最常見的方法，透過分享卷交換資料
本地網路通訊：透過 localhost 網路介面進行 HTTP/gRPC 通訊
訊號通知：使用程式訊號通知事件（如設定更改）
分享環境變數：透過更新環境變數傳遞簡單資訊

以下是使用本地網路通訊的範例：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-api-sidecar
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    env:
    - name: SIDECAR_API_URL
      value: "http://localhost:8080"
  - name: api-sidecar
    image: example/api-sidecar:v1
    ports:
    - containerPort: 8080

在這個設計中：

主 Webhook 容器透過環境變數 SIDECAR_API_URL 獲知側邊車的 API 地址
側邊車在 localhost:8080 提供 API 服務
兩個容器可以透過 HTTP 請求進行通訊
這種方法適合需要複雜互動的場景，比分享檔案更靈活

側邊車資源管理

側邊車設計需要考慮資源分配和限制：

apiVersion: v1
kind: Pod
metadata:
  name: resource-optimized-webhook
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    resources:
      requests:
        memory: "256Mi"
        cpu: "200m"
      limits:
        memory: "512Mi"
        cpu: "500m"
  - name: sidecar
    image: example/sidecar:v1
    resources:
      requests:
        memory: "64Mi"
        cpu: "50m"
      limits:
        memory: "128Mi"
        cpu: "100m"

這個設定展示了資源分配策略：

主 Webhook 容器獲得大部分資源
側邊車容器資源請求和限制較低
明確定義資源需求可以防止資源爭用問題
適當的資源限制可以防止單個容器消耗過多資源

側邊車生命週期管理

側邊車的生命週期管理對於系統穩定性至關重要：

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-managed-webhook
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    ports:
    - containerPort: 8443
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "until [ -f /etc/webhook/ready ]; do sleep 1; done"]
  - name: init-sidecar
    image: example/init-sidecar:v1
    volumeMounts:
    - name: shared
      mountPath: /etc/webhook
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "rm /etc/webhook/ready && sleep 5"]
  volumes:
  - name: shared
    emptyDir: {}

這個設定使用生命週期鉤子管理容器啟動和關閉順序：

postStart 鉤子使主容器等待側邊車準備就緒
preStop 鉤子確保側邊車在主容器關閉前執行清理操作
分享檔案 /etc/webhook/ready 用作就緒訊號
這種協調確保了系統的穩定啟動和優雅關閉

側邊車安全考量

在設計側邊車時，安全性是重要考量：

apiVersion: v1
kind: Pod
metadata:
  name: secure-webhook-sidecar
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
  - name: sidecar
    image: example/sidecar:v1
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

這個設定實施了多層安全措施：

Pod 級別的 securityContext 確保容器以非 root 使用者執行
容器級別的安全上下文禁止許可權提升
移除所有 Linux 能力
使用只讀根檔案系統
為需要寫入的目錄提供專用卷

這些安全實踐減少了 Webhook 和側邊車容器的攻擊面。

側邊車模式的最佳實踐

1. 關注點分離

每個側邊車應該專注於單一責任：

# 推薦：每個側邊車專注於單一功能
- name: cert-manager-sidecar
  image: example/cert-manager:v1
- name: metrics-sidecar
  image: example/metrics-exporter:v1

# 不推薦：單個側邊車承擔多種功能
- name: multi-purpose-sidecar
  image: example/do-everything:v1

關注點分離原則使系統更易於維護和理解：

每個側邊車專注於特定功能（憑證管理、指標收集等）
避免建立承擔多種不相關責任的"萬能"側邊車
這種模組化設計使元件可以獨立更新和測試

2. 輕量級設計

側邊車應該盡可能輕量級：

# 推薦：輕量級專用側邊車
- name: config-reloader
  image: example/config-reloader:v1
  resources:
    requests:
      memory: "32Mi"
      cpu: "10m"

# 不推薦：重量級通用側邊車
- name: heavy-sidecar
  image: example/heavy-sidecar:v1
  resources:
    requests:
      memory: "512Mi"
      cpu: "200m"

輕量級設計的好處包括：

減少資源消耗
加快啟動時間
減少映像大小
降低安全風險

3. 健康檢查整合

為所有容器實施適當的健康檢查：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-health-checks
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 2
  - name: sidecar
    image: example/sidecar:v1
    livenessProbe:
      httpGet:
        path: /health
        port: 8081
      initialDelaySeconds: 5
      periodSeconds: 5

這個設定為主容器和側邊車都實施了健康檢查：

livenessProbe 檢測容器是否執行正常
readinessProbe 檢測容器是否準備好接收流量
適當的延遲和週期設定避免了過早或過頻繁的檢查
這確保了整個系統的健康狀態可以被正確監控

4. 版本相容性管理

確保側邊車與主容器版本相容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webhook-deployment
spec:
  template:
    spec:
      containers:
      - name: webhook-server
        image: example/webhook-server:v1.2.3
      - name: sidecar
        image: example/sidecar:v1.2.x

版本相容性管理的關鍵點：

使用明確的版本標籤而非 latest
確保側邊車版本與主容器相容
考慮使用語義化版本控制
在更新一個元件前測試相容性

實際應用案例

服務網格注入器

Istio 等服務網格使用側邊車注入 Webhook 自動注入代理側邊車：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: istio-sidecar-injector
webhooks:
- name: sidecar-injector.istio.io
  clientConfig:
    service:
      name: istiod
      namespace: istio-system
      path: "/inject"
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["pods"]
  namespaceSelector:
    matchLabels:
      istio-injection: enabled

這個 Istio 側邊車注入器 Webhook：

監控 Pod 建立操作
在標記為 istio-injection: enabled 的名稱空間中自動注入 Envoy 代理側邊車
修改 Pod 規格以包含額外的容器和卷
這是側邊車模式與 Webhook 結合的典型例子

安全掃描器

使用側邊車進行容器安全掃描：

apiVersion: v1
kind: Pod
metadata:
  name: webhook-with-security-scanner
spec:
  containers:
  - name: webhook-server
    image: example/webhook-server:v1
    volumeMounts:
    - name: docker-socket
      mountPath: /var/run/docker.sock
      readOnly: true
  - name: security-scanner
    image: example/security-scanner:v1
    volumeMounts:
    - name: docker-socket
      mountPath: /var/run/docker.sock
      readOnly: true
  volumes:
  - name: docker-socket
    hostPath:
      path: /var/run/docker.sock
      type: Socket

這個設計使用安全掃描側邊車：

側邊車與主容器分享對 Docker 通訊端的存取
安全掃描器可以檢查容器映像中的漏洞
可以在佈署前阻止存在安全問題的容器
這種方法將安全掃描與主 Webhook 邏輯分離

側邊車模式與 Webhook 的結合提供了強大的擴充套件性和模組化架構。透過將不同功能分離到專用容器中，可以建立更易於維護、更安全、更靈活的系統。這種模式特別適合需要多種輔助功能（如憑證管理、日誌處理、設定多載）的複雜 Webhook 實作。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。