Kubernetes，憑借其完善的生態系統，提供了許多功能，可以顯著增強容器化應用程序的管理、可伸縮性和安全性。以下是13個技巧，每個技巧都有詳細的解釋、使用示例、上下文應用和需要注意的預防措施。

1. 使用 PreStop Hooks 優雅地關閉 Pod

PreStop 鉤子允許在 Pod 即將終止之前在其中執行特定命令或腳本。這種能力對于確保應用程序優雅關閉、在必要時保存狀態，或執行清理任務以避免數據損壞并確保平穩重啟至關重要。

案例：

apiVersion: v1
kind: Pod
metadata:
  name: graceful-shutdown-example
spec:
  containers:
  - name: sample-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 30 && nginx -s quit"]

這個配置確保了 nginx 服務器在關閉之前有 30 秒的時間來完成正在處理的請求。

什么情況使用呢？

在對服務連續性至關重要的環境中實施PreStop鉤子，以確保在部署、擴展或Pod重啟期間零或最小的停機時間。

注意：

Kubernetes允許Pod的終止寬限期。如果PreStop鉤子腳本執行時間超過這個寬限期，Kubernetes將強制終止Pod。

2. 使用Kubelet進行自動Secret輪換

Kubernetes支持對Secret進行自動輪換，而無需重新啟動使用這些Secret的Pod。這一功能特別有助于保持安全標準，定期更改敏感信息，而不影響應用程序的可用性。

案例：

假設您已經在 Kubernetes 中更新了一個Secret。Kubernetes 將自動更新掛載在 Pod 中的Secret，無需任何干預，確保應用程序始終具有最新的憑據，無需手動更新或重新啟動。

什么情況使用呢？

這一功能對于需要高水平安全合規性的應用程序至關重要，需要頻繁進行Secret輪換，比如數據庫、API密鑰或TLS證書。

注意：

應用程序必須設計成能夠動態讀取更新的Secret。一些應用程序在啟動時會緩存Secret，這意味著它們在沒有重新啟動的情況下無法識別更新的Secret。確保您的應用程序定期檢查Secret的更新，或者對變化做出適當的反應。

3. 使用臨時容器調試 Pod

Ephemeral containers 提供了一種臨時將調試容器附加到運行中的 Pod 上的方式，而不會改變其原始規范。這對于在生產環境中調試實時問題非常有幫助，因為您不能擾亂服務。

案例：

kubectl alpha debug -it podname --image=busybox --target=containername

這個命令會向您現有的 Pod 中添加一個 busybox 容器，使您能夠執行命令并檢查 Pod 的環境，而不會改變其運行狀態。

什么情況使用呢？

在實時環境中診斷問題時，特別是當標準日志和指標無法提供足夠信息時，可以利用短暫容器。這是一個強大的工具，用于實時深入分析生產問題。

注意：

由于臨時容器可以訪問Pod的資源和敏感數據，因此在生產環境中要謹慎使用它們。確保只有授權人員可以部署臨時容器，以避免潛在的安全風險。

4. Horizontal Pod Autoscaling 基于自定義指標

HPA可以根據自定義指標而非僅僅是標準的 CPU 和內存使用情況來調整Pod副本。這對于需要根據特定業務指標或性能指標進行調整的應用程序特別有用，比如隊列長度、請求延遲或自定義應用程序指標。

案例：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: custom-metric-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: your-application
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: your_custom_metric
      target:
        type: AverageValue
        averageValue: 10

這個 HPA 配置根據自定義指標 your_custom_metric 的平均值來調整您的應用程序的規模。

什么情況使用呢？

為那些傳統基于資源的度量無法準確反映負載情況或基于業務需求進行精細調整的應用程序，采用自定義度量標度。

注意：

建立自定義指標涉及與支持自定義指標的指標服務器集成，例如Prometheus。確保您的指標是可靠的負載指標，以防止過度或不足擴展。

使用初始化容器來運行腳本

初始化容器在 Pod 中的應用容器之前運行，非常適合需要在應用啟動之前完成的初始化配置腳本。這可能包括數據庫遷移、配置文件創建或等待外部服務可用等任務。初始化容器可以運行一系列初始化任務，確保在主應用容器啟動之前每個步驟都成功完成。

案例：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']

這個示例使用一個初始化容器來等待一個名為"myservice"的服務在啟動主應用容器之前變得可用。

什么情況使用呢？

初始化容器在您的應用容器在啟動之前依賴于外部服務或配置可用時非常重要。它們確保您的應用在環境準備就緒的情況下啟動。

注意：

整個 Pod 的啟動將被阻塞，直到所有 init 容器成功完成。確保 init 容器高效且能夠優雅地處理失敗，以防止它們成為瓶頸或導致 Pod 啟動失敗。

6. 適用于特定工作負載調度的節點親和性

節點親和性允許您指定規則，根據節點上的標簽限制您的 Pod 可以調度到哪些節點上。這對于將工作負載定向到具有特定硬件（如 GPU）的節點，確保數據局部性，或遵守合規性和數據主權要求非常有用。

案例：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  containers:
  - name: with-node-affinity
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

這個 Pod 只會被調度到具有標簽 disktype=ssd 的節點上。

什么情況使用呢？

當您的應用程序需要特定節點功能時，請使用節點親和性。

注意：

過度使用節點親和性可能導致集群利用率低和調度復雜性增加。確保您的集群具有標簽和親和性的平衡分布，以保持資源利用的高效性。

7. Pod的污點和容忍配置

Taints和tolerations共同作用，確保Pods不會被調度到不適當的節點上。節點上的Taint會排斥不容忍該Taint的Pods。Tolerations應用于Pods，使它們能夠在帶有Taint的節點上調度。這種機制對于將節點專門用于特定工作負載（例如GPU密集型應用程序）或確保只有特定的Pods在帶有敏感數據的節點上運行至關重要。

案例：

# Applying a taint to a node
kubectl taint nodes node1 key=value:NoSchedule

# Pod specification with toleration
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: nginx
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

這個配置確保了 mypod 可以被調度到具有特定污點的 node1 上，其他 pod 無法容忍這個污點。

什么情況使用呢？

Taints和tolerations在多租戶集群中特別有用，對于安全性或性能原因而隔離工作負載至關重要。它們還有助于運行需要專用資源的專業工作負載。

注意：

配置污點和容忍度不當可能導致調度問題，導致Pod未按預期調度或某些節點被低效利用。定期審查您的污點和容忍度設置，確保其符合您的調度要求。

8. 工作負載的 Pod 優先級和搶占

Kubernetes允許您為Pod分配優先級，如果必要，較高優先級的Pod可以搶占（驅逐）較低優先級的Pod。這確保了關鍵工作負載在高度擁擠的集群中也能獲得所需的資源。

案例：

# PriorityClass definition
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

# Pod specification with priorityClassName
apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  containers:
  - name: high-priority
    image: nginx
  priorityClassName: high-priority

這個配置定義了一個高優先級類，并將其分配給一個 pod，確保它可以搶占其他低優先級的 pods。

什么情況使用呢？

使用Pod優先級和搶占功能來管理那些對您的業務運營至關重要的應用程序，特別是在資源爭用頻繁的集群環境中運行時。

注意：

不當使用可能導致次要應用程序資源匱乏。平衡不同工作負載的需求，并考慮對集群健康和應用程序性能的整體影響是至關重要的。

9. 動態配置的ConfigMaps和Secrets

ConfigMaps和Secrets提供了將配置數據注入到Pod中的機制。這使得配置外部化，使得應用程序更容易配置，而無需硬編碼配置數據。ConfigMaps適用于非敏感數據，而Secrets則用于敏感數據。

案例：

# ConfigMap Example
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  config.json: |
    {
      "key": "value",
      "databaseURL": "http://mydatabase.example.com"
    }

# Pod Spec using ConfigMap
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
    - name: myapp-container
      image: myapp
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

這個配置將 app-config 的內容注入到 pod 中，使應用程序能夠從 /etc/config/config.json 中讀取其配置。

什么情況使用呢？每當您需要將應用程序的配置或機密數據外部化，使其更易于管理、更新和維護，而無需重新構建容器映像時。

注意：雖然 ConfigMaps 非常適合存儲非敏感數據，但應避免將需要保密的任何數據存儲在其中。始終使用 Secrets 來存儲、令牌、密鑰和其他敏感數據，并且要了解保護 Secrets 的最佳實踐，例如在靜態狀態下對其進行加密。

10. Kubectl Debug 用于直接容器調試

kubectl debug 提供了一種方法，可以創建一個臨時的 pod 副本，并用調試版本的容器替換其原有的容器，或者在不影響原始 pod 的情況下添加新的故障排查工具。這對于在不影響應用程序運行狀態的情況下調試實時環境中的問題非常有用。

案例：

kubectl debug pod/myapp-pod -it --copy-to=myapp-debug --container=myapp-container --image=busybox

這個命令創建了一個myapp-pod的副本，為了調試目的，用busybox鏡像替換了myapp-container。

什么情況使用呢？

當你需要對崩潰的或在生產中表現不如預期的pod進行故障排查時進行實時調試，對服務的影響最小。

注意：

調試Pod仍然可能影響整個集群的資源分配，并可能訪問敏感數據。請確保嚴格控制對調試命令的訪問，并在使用后清理調試Pod。

11. 通過請求和限制進行高效的資源管理

Kubernetes允許您為pod中的每個容器指定CPU和內存（RAM）的請求和限制。請求保證容器獲得指定數量的資源，而限制確保容器永遠不會使用超過分配的數量。這有助于有效管理資源分配，并防止任何單一應用程序壟斷集群資源。

案例：

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

這個pod規格要求為demo-container分配特定數量的CPU和內存，以確保它具有實現最佳性能所需的資源，同時防止其超過指定的限制。

什么情況使用呢？

請對所有容器應用請求和限制，以確保應用程序的性能可預測，并避免在集群中運行的應用程序之間的資源爭搶。

注意：將限制設置得過低可能會導致如果集群無法提供請求的資源，Pods可能會被終止或無法調度。相反，將它們設置得過高可能會導致集群資源的利用效率低下。請監控應用程序的性能，并根據需要調整請求和限制

12. 用于擴展Kubernetes的自定義資源定義（CRD）

CRD 允許你通過自己的 API 對象擴展 Kubernetes，從而實現創建像原生 Kubernetes 對象一樣運作的自定義資源。這對于向你的集群添加特定領域的功能、促進自定義操作以及與外部系統集成具有強大的作用。

案例：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

這個CRD在集群中定義了一種新的資源類型CronTab，它可以像傳統的cron作業一樣用于調度任務，但是采用了Kubernetes原生的管理方式。

什么情況使用呢？CRD 是擴展 Kubernetes 功能以滿足您的應用程序或服務特定需求的理想選擇，例如引入特定領域的資源類型或與外部服務和 API 進行集成。

注意：

設計和管理CRD需要對Kubernetes內部結構和API機制有深入的理解。設計不良的CRDs可能會導致性能問題，并使集群管理變得復雜。始終確保對CRDs進行徹底的測試，并考慮其對集群穩定性和性能的影響。

13. 用于動態交互和自動化的Kubernetes API

Kubernetes API使您能夠動態地與您的集群進行交互，從而可以以編程方式自動化擴展、部署和管理任務。通過利用API，您可以創建與您的集群實時交互的腳本或應用程序，實現復雜的自動化和集成場景，這超出了靜態配置文件和手動命令所能實現的范圍。

案例：

以下是一個基本示例，使用curl與Kubernetes API交互，以獲取默認命名空間中的pod列表。這假設您有一個訪問令牌，并且可以在https://處訪問Kubernetes API。

curl -X GET https://<kubernetes-api-server>/api/v1/namespaces/default/pods \
-H "Authorization: Bearer <your-access-token>" \
-H 'Accept: application/json'

對于更復雜的交互，可以考慮使用各種編程語言（如Go、Python、Java）中可用的客戶端庫，這些庫抽象化了HTTP請求，并提供了更便捷的接口來操作Kubernetes API。

什么情況使用呢？

Kubernetes API對于開發自定義自動化、動態擴展策略、CI/CD集成，甚至擴展Kubernetes功能的自定義控制器具有難以置信的強大功能。當你需要將Kubernetes操作與外部系統集成或創建自定義部署工作流時，它尤其有用。

注意：

與Kubernetes API進行交互時，需要謹慎處理身份驗證和授權。確保你的腳本和應用程序堅持最小權限原則，只請求它們運行所需的權限。此外，當進行頻繁或復雜的查詢時，要注意可能對API服務器的負載產生的影響，因為這可能會影響集群性能。始終驗證并清理你的API客戶端的輸入，以避免安全漏洞，特別是如果它們與外部系統或用戶生成的內容進行交互。