Kubernetes 佈署策略詳解與 vCluster 虛擬叢集應用

Kubernetes 提供多種佈署策略，滿足不同應用場景的需求。重建佈署適用於允許停機的應用，滾動更新則在不停機的情況下逐步更新 Pod。藍綠佈署透過兩個相同的環境實作零停機切換，金絲雀佈署逐步將新版本暴露給部分使用者，而 A/B 測試則比較不同版本的表現。選擇合適的策略需要考量應用特性、停機時間容忍度和更新風險。此外，隨著容器化應用規模擴大，多租戶管理成為 Kubernetes 的一大挑戰。vCluster 提供虛擬叢集解決方案，在單一實體叢集中實作資源隔離、彈性擴充套件和簡化管理，有效應對資源爭用、隔離性不足和管理開銷等問題。

更新您的應用程式：佈署策略型別

在動態的雲原生環境中，定期更新應用程式對於佈署新功能、安全補丁和錯誤修復至關重要。Kubernetes提供了多種佈署策略來管理應用程式更新，每種策略都針對特定的場景和需求量身定製。

挑戰

• 最小化應用程式更新期間的停機時間，以確保不間斷的可用性。
• 正確組態佈署策略，以滿足特定的應用程式和營運需求。
• 有效管理與佈署新版本相關的風險，包括潛在的錯誤和不相容性。

解決方案

重建佈署（Recreate Deployment）

適用於可以接受停機時間且不需要無縫更新的應用程式。重建佈署涉及在建立新Pod之前關閉現有的Pod。這種策略確保舊版本和新版本之間沒有重疊。

recreate_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.26.1
        ports:
        - containerPort: 80

內容解密：

此YAML檔案定義了一個Kubernetes佈署，名為nginx-app，使用了Recreate佈署策略。這意味著在建立新的Pod之前，所有現有的Pod都會被刪除。這種方法確保了在任何時候，只有一個版本的應用程式正在執行，這對於某些需要嚴格版本控制的應用程式來說是有用的。

1. apiVersion 和 kind：指定了Kubernetes API的版本和資源型別（在此例中為Deployment）。
2. metadata：提供了佈署的後設資料，如名稱。
3. spec：定義了佈署的期望狀態，包括副本數量、佈署策略、選擇器和Pod範本。
4. strategy.type：指定了佈署策略為Recreate。
5. selector.matchLabels 和 template.metadata.labels：確保佈署管理的Pod與指定的標籤相匹配。
6. containers：定義了Pod中執行的容器，包括名稱、映像檔和埠組態。

透過使用Recreate策略，可以確保應用程式的新舊版本不會同時執行，這對於需要嚴格控制版本或有特定相容性要求的場景非常有用。然而，這種方法可能會導致應用程式暫時的不可用，因此需要根據具體需求進行選擇。

滾動更新佈署策略詳解

在 Kubernetes 中，佈署策略對於確保應用程式的持續可用性和最小化停機時間至關重要。本章節將探討幾種常見的佈署策略，包括滾動更新、藍綠佈署、金絲雀佈署、影子佈署和 A/B 測試，並介紹其最佳實踐。

滾動更新（Rolling Update）佈署

滾動更新是一種逐步替換舊版本 Pod 的方法，以最小化停機時間並保持應用程式的可用性。下面是一個 rollingupdatedeployment.yaml 的範例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ru-app
  labels:
    app: nginx-ru-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: nginx-ru-app
  template:
    metadata:
      labels:
        app: nginx-ru-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.26.1
        ports:
        - containerPort: 80

內容解密：

• maxUnavailable: 1 表示在更新過程中最多允許一個 Pod 不可用。
• maxSurge: 1 表示在更新過程中最多可以建立一個額外的 Pod（超出期望的副本數）。

使用 kubectl get pods -l 'app=nginx-ru-app' -w 可以觀察到 Kubernetes 逐漸替換舊 Pod 的過程。

藍綠佈署（Blue-Green Deployment）

藍綠佈署透過執行兩個相同的生產環境（藍色和綠色）來減少停機時間和風險。任何時候，只有一個環境是活躍的，服務所有生產流量。下面是一個 blue_deployment.yaml 的範例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
      version: blue
  template:
    metadata:
      labels:
        app: nginx
        version: blue
    spec:
      containers:
      - name: nginx
        image: nginx:1.26.1
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
    version: blue
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

內容解密：

• 藍綠佈署需要兩個相同的環境，透過切換 Service 的選擇器來實作流量的切換。
• 這種方法可以實作零停機時間的佈署，並且方便回復。

金絲雀佈署（Canary Deployment）

金絲雀佈署是一種將新版本應用程式逐步暴露給一部分使用者的技術，以測試新版本的穩定性和效能。下面是一個金絲雀佈署的範例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary
spec:
  replicas: 1
  ...

內容解密：

• 金絲雀佈署透過控制新舊版本的流量比例來實作逐步上線。
• 這種方法可以用於測試新版本的表現，並根據需要調整流量比例。

A/B 測試（A/B Testing）

A/B 測試是一種比較不同版本應用程式表現的方法，透過將不同比例的使用者流量導向不同的版本來實作。下面是一個 A/B 測試的範例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ab
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /a
        backend:
          service:
            name: my-app-v1
            port:
              number: 80
      - path: /b
        backend:
          service:
            name: my-app-v2
            port:
              number: 80

內容解密：

• A/B 測試透過將不同路徑的流量導向不同的服務來實作版本的比較。
• 這種方法可以用於評估不同版本的表現，並根據結果進行最佳化。

最佳實踐

1. 監控和指標：使用 Prometheus 和 Grafana 等工具監控佈署的健康狀態、效能和成功率。
2. 測試和驗證：使用 CI/CD 管道自動化測試和驗證，以確保新版本按預期工作。
3. 回復機制：始終準備回復計劃，並定期測試，以確保能夠快速還原到穩定的狀態。
4. 流量管理：使用 Ingress Controller、Service Mesh 或負載平衡器管理金絲雀、藍綠和 A/B 測試佈署期間的流量。
5. 檔案和培訓：記錄佈署策略和流程，以確保團隊的一致性和理解，並提供培訓以幫助團隊掌握不同的佈署策略和處理回復場景。

透過遵循這些最佳實踐，組織可以實施和最佳化各種 Kubernetes 佈署策略，確保應用程式更新的平滑進行，最小化停機時間和中斷，從而提高應用程式的可靠性、效能和使用者經驗。

vCluster：實作 Kubernetes 環境的高效擴充套件與彈性管理

在 Kubernetes 的應用中，多租戶管理是一項常見的挑戰，尤其是在大規模的環境中。多租戶意味著多個使用者或團隊分享同一個 Kubernetes 叢集，但需要資源隔離、效能保證和應用擴充套件的靈活性。傳統的 Kubernetes 環境難以滿足這些需求，因為資源隔離、名稱空間衝突管理和安全維護都相當複雜。

問題描述

隨著組織對 Kubernetes 的依賴加深，如何在單一叢集中管理多個團隊和應用變得越來越困難。主要挑戰包括：

• 資源爭用：多個團隊分享叢集資源可能導致效能下降或「吵雜鄰居」問題。
• 隔離性：Kubernetes 的名稱空間無法提供完全的隔離，錯誤組態或惡意應用可能會影響同一叢集中的其他應用。
• 叢集管理開銷：為每個團隊或環境（開發、測試、生產）執行多個實體叢集會增加營運成本、維護和監控的複雜性。
• 自定義組態：不同團隊可能需要特定的 Kubernetes 組態、政策或版本，這在不使用獨立叢集的情況下難以實作。
• 擴充套件性：隨著工作負載的增長，如何在不影響其他團隊運作的前提下進行水平擴充套件成為了一大瓶頸。

解決方案：vCluster

vCluster（虛擬叢集）是一種創新的解決方案，能夠在單一實體 Kubernetes 叢集中建立輕量級的虛擬 Kubernetes 叢集，從而有效解決上述問題，增強擴充套件性和彈性。

vCluster 的關鍵優勢

• 完全隔離：每個虛擬叢集執行在實體叢集的獨立名稱空間中，具備完整的資源隔離、安全政策和組態。
• 最佳化資源利用：相比佈署多個實體叢集，使用 vCluster 可以在同一基礎設施上執行多個隔離的虛擬叢集，最佳化資源利用並降低營運成本。
• 簡化多租戶管理：vCluster 為多租戶環境提供了簡便的管理方式，每個租戶擁有獨立的虛擬叢集，避免了名稱空間、RBAC 政策或資源配額的衝突。
• 版本與組態靈活性：團隊可以在自己的虛擬叢集中執行不同版本的 Kubernetes 或組態，而不會影響其他團隊。
• 彈性與故障隔離：虛擬叢集之間的獨立性確保了一個叢集中的資源耗盡、應用當機或錯誤組態不會影響其他叢集，提高了大規模環境下的容錯能力。
• 擴充套件性：vCluster 使得擴充套件更加精細和高效，每個虛擬叢集可以根據工作負載需求獨立擴充套件，而不會影響實體叢集的效能。

實際應用場景

假設一家大型組織有多個開發團隊，分別開發不同的微服務。每個團隊需要獨立的 Kubernetes 環境進行開發、測試和生產，並可能需要不同版本的 Kubernetes 或組態。使用 vCluster，該組織可以在單一實體 Kubernetes 叢集中為每個團隊提供獨立的虛擬叢集。團隊可以在不影響其他團隊的前提下獨立運作、擴充套件和組態其虛擬叢集，同時避免了管理多個實體叢集的營運開銷。

vCluster 的工作原理

安裝 vCluster

首先，我們需要在本地環境中安裝 vCluster。根據主機系統或 Kubernetes 發行版的不同，可以參考 vCluster 官方檔案進行安裝。在本例中，我們使用 Linux 版本，並在 wsl2 上執行以下命令進行安裝：

curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64" && sudo install -c -m 0755 vcluster /usr/local/bin && rm -f vcluster

建立第一個 vCluster

接下來，我們在名稱空間 team-x 中建立第一個 vCluster：

vcluster create my-vcluster --namespace team-x

建立第二個 vCluster

我們可以在不同的名稱空間 team-z 中建立第二個 vCluster，以展示環境之間的隔離性：

vcluster create my-vcluster-2 --namespace team-z

驗證隔離性

為了驗證 vCluster 之間的隔離性，我們在第一個 vCluster 中建立了一個 CRD（自定義資源定義），然後檢查第二個 vCluster 是否能夠看到該 CRD。

首先，定義 CRD：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.example.com
spec:
  group: example.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              name:
                type: string
              size:
                type: integer
  scope: Namespaced
  names:
    plural: myresources
    singular: myresource
    kind: MyResource
    shortNames:
    - mr

將 CRD 套用到第一個 vCluster：

sudo kubectl apply -f crd.yaml

檢查第二個 vCluster 是否存在該 CRD：

kubectl get crd myresources.example.com

結果顯示，第二個 vCluster 無法看到第一個 vCluster 中建立的 CRD，證明瞭 vCluster 之間的隔離性。