Kubernetes 多容器 Pod 設計模式深度解析

– 8 分鐘閱讀

Kubernetes 作為容器協調的標準，其 Pod 的多容器設計模式是構建高效應用程式的關鍵。本文將探討 Ambassador、Sidecar 和 Adapter 三種模式，並輔以實際案例說明。Ambassador 模式如同外部服務的橋樑，Sidecar 模式提供輔助功能，而 Adapter 模式則專注於資料轉換。透過 Nginx 代理 Redis、Redis 作為 Sidecar 提供快取，以及日誌格式轉換等案例，可以清楚理解這些模式的應用場景和優缺點。此外，文章也將探討 Kubernetes Deployment 資源的管理和佈署策略，包括滾動更新、藍綠佈署和 Canary 發布，提供全面的 Kubernetes 應用佈署。

雲端原生時代的 DevOps 最佳實務：Kubernetes 多容器 Pod 設計模式深度解析

Kubernetes 多容器 Pod 設計模式深度解析

在現代雲端原生架構中，Kubernetes 已成為容器協調的標準。理解 Pod 的運作機制對於構建高效、可靠的應用至關重要。本文將探討 Kubernetes Pod 的核心概念，著重分析 Ambassador、Sidecar 和 Adapter 三種多容器設計模式，並透過實際案例和程式碼範例，幫助讀者掌握 Pod 的最佳實踐和應用技巧。

Pod 基礎架構與多容器設計原則

Kubernetes 中的 Pod 是最小的佈署單元，它封裝了一個或多個容器，並提供分享的網路和儲存資源。多容器 Pod 設計允許開發者將緊密耦合的容器組合成一個邏輯單元，實作更複雜的應用場景。

Ambassador 模式：外部服務的橋樑

Ambassador 模式如同應用程式的大使，負責處理與外部服務的互動，簡化應用程式開發並提升安全性。

實踐案例：Nginx 作為 Redis 的 Ambassador

以下 YAML 檔案定義了一個 Pod，其中包含 Flask 應用程式和 Nginx Ambassador：

apiVersion: v1
kind: Pod
metadata:
  name: flask-ambassador
spec:
  containers:
  - name: flask-app
    image: <your_dockerhub_user>/flask-redis
  - name: nginx-ambassador
    image: nginx
    volumeMounts:
    - mountPath: /etc/nginx
      name: nginx-volume
  initContainers:
  - name: init-nginx
    image: busybox:1.28
    command: ['sh', '-c', 'cp -L /config/nginx.conf /etc/nginx/nginx.conf && sed -i "s/REDIS_HOST/${REDIS_HOST}/g" /etc/nginx/nginx.conf']
    env:
    - name: REDIS_HOST
      valueFrom:
        configMapKeyRef:
          name: redis-config
          key: host
    - name: REDIS_PORT
      valueFrom:
        configMapKeyRef:
          name: redis-config
          key: port
    volumeMounts:
    - mountPath: /etc/nginx
      name: nginx-volume
    - mountPath: /config
      name: config
  volumes:
  - name: nginx-volume
    emptyDir: {}
  - name: config
    configMap:
      name: nginx-config
      items:
      - key: "nginx.conf"
        path: "nginx.conf"

內容解密：

這個 Pod 包含兩個容器：flask-app 和 nginx-ambassador。flask-app 容器執行 Flask 應用程式，nginx-ambassador 容器則作為 Redis 的代理。initContainers 部分定義了一個 init-nginx 容器，負責在 Nginx 啟動前生成必要的組態。此組態從 redis-config 和 nginx-config ConfigMap 中取得 Redis 的主機和連線埠資訊，並將其注入到 Nginx 組態檔案中。

流程圖解

流程解密：

Flask 應用程式的所有請求都先傳送到 Nginx Ambassador，然後由 Nginx 代理到 Redis 服務。

優缺點分析

優點：

  • 簡化應用程式開發：應用程式無需直接處理外部服務的連線細節。
  • 提升安全性：Ambassador 可以作為安全屏障，保護應用程式免受外部攻擊。
  • 靈活組態：可以根據需求調整 Ambassador 的組態，例如增加身份驗證或流量控制。

缺點：

  • 增加額外開銷：Ambassador 會增加額外的資源消耗。

Sidecar 模式：輔助容器的應用

Sidecar 模式如同摩托車的邊車，提供輔助功能，增強主容器的功能，但主容器本身可以獨立執行。

Redis Sidecar 案例解析

以下案例展示如何使用 Sidecar 模式將 Redis 作為輔助容器，提供資料儲存功能。

首先，構建 Redis 映象並推播至 Docker Hub：

docker push <your_dockerhub_user>/redis-secret

接著，構建應用程式映象。app.py 程式碼如下：

import time
import redis
from flask import Flask
from datetime import datetime

app = Flask(__name__)
cache = redis.Redis(host='localhost', port=6379)

def get_secret():
    try:
        secret = cache.get('secret')
        return secret
    except redis.exceptions.ConnectionError as e:
        raise e

@app.route('/')
def index():
    secret = str(get_secret().decode('utf-8'))
    return 'Hi there! The secret is {}.\n'.format(secret)

程式碼解析：

這段程式碼建立一個簡單的 Flask 應用，從 Redis 快取中取得名為 secret 的值，並在網頁上顯示。

Pod 組態與實作

建立 Pod manifest flask-sidecar.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: flask-sidecar
spec:
  containers:
  - name: flask-app
    image: <your_dockerhub_user>/flask-redis-secret
  - name: redis-sidecar
    image: <your_dockerhub_user>/redis-secret
    volumeMounts:
    - mountPath: /redis-master
      name: secret
  volumes:
  - name: secret
    secret:
      secretName: redis-secret
      items:
      - key: redis-secret
        path: init.redis

組態解析：

這個 Pod 定義了兩個容器：flask-app 執行程式碼，redis-sidecar 則作為 Sidecar 提供 Redis 功能。

Sidecar 與主容器的互動機制

圖解說明：

Flask 主應用和 Redis Sidecar 在同一個 Pod 中，可以直接互相通訊。

Adapter 模式：資料轉換的最佳實踐

Adapter 模式主要用於資料轉換，將不同格式的日誌或其他資料統一成標準格式，以便後續處理和分析。

日誌轉換案例詳解

以下案例展示如何使用 Adapter 將應用的日誌輸出轉換成 JSON 格式。

首先，建立 app-adapter.yaml 組態檔案：

apiVersion: v1
kind: Pod
metadata:
  name: app-adapter
spec:
  containers:
  - name: app-container
    image: <your_dockerhub_user>/app-logger:latest
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/app/
  - name: adapter-container
    image: <your_dockerhub_user>/log-adapter:latest  
    volumeMounts:
    - name: logs-volume  
      mountPath: /var/log/app/
      readOnly: true  
volumes:
- name: logs-volume  
  emptyDir: {}

組態解析：

這個組態定義了兩個容器分享同一個 emptyDir 卷，用於日誌檔案交換。主應用將日誌寫入共用卷後，由 Adapter 從同一位置讀取並進行格式轉換。

多容器設計模式的比較與選擇

| 特性 | Ambassador | Sidecar | Adapter | |

|

-|

–|

–| | 主要功能 | 處理外部服務互動 | 提供輔助功能 | 資料格式轉換 | | 與主容器的關係 | 中介角色 | 輔助角色 | 資料處理角色 | | 代表案例 | Nginx代理Redis | Redis提供快取 | 日誌格式轉換 |

在選擇適當的多容器設計模式時，需考慮具體的業務需求和技術場景。例如，當需要簡化外部服務互動時，Ambassador 是理想選擇；而當需要為主應用提供輔助功能時，Sidecar 更為合適；若涉及大量資料格式轉換，則應採用 Adapter 模式。

深入 Kubernetes 佈署：策略與實踐

在 Kubernetes 環境中，有效管理應用程式佈署至關重要。Deployment 資源提供了一個強大的機制，讓我們能夠控制應用程式的版本、升級和回復。本文將探討 Deployment 資源的運作方式，並解析不同的佈署策略。

Deployment 資源鏈

Deployment 資源並非直接管理 Pod，而是透過 ReplicaSet 作為後端控制器。這形成了一個資源鏈：Deployment -> ReplicaSet -> Pod。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes 多容器 Pod 設計模式深度解析

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

圖表解密：

此圖表展示了 Deployment 管理 ReplicaSet，而 ReplicaSet 負責維持指定數量的 Pod。這種層級結構使得應用程式的管理更加靈活和可靠。

以下是一個 NGINX Deployment 的 YAML 範例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

內容解密：

這個 Deployment 資源定義了一個名為 nginx-deployment 的佈署，包含三個副本，使用 nginx:latest 映象。Deployment 資源透過管理 ReplicaSet 來確保指定的副本數量。

佈署策略

Kubernetes 支援多種佈署策略，以滿足不同的需求。常見的策略包括滾動更新（Rolling Update）和藍綠佈署（Blue-Green Deployment）。

滾動更新

滾動更新是一種逐步替換舊版本 Pod 的方法，確保應用程式在更新過程中保持可用。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

內容解密：

此範例展示了一個使用滾動更新策略的 Deployment 組態。maxUnavailable 和 maxSurge 引數控制著更新過程中的 Pod 狀態，確保平滑過渡。

圖表解密：

此圖表對比了滾動更新和藍綠佈署兩種策略的特點。滾動更新逐步替換舊版本，保持應用程式的持續可用；藍綠佈署則透過平行環境實作快速切換。根據實際需求選擇適當的策略，可以提高佈署的效率和可靠性。

Kubernetes 佈署策略進階解析與最佳實踐

在前述內容中，我們探討了 Kubernetes Deployment 資源的管理和基本佈署策略，包括 Recreate 和 RollingUpdate。接下來，我們將進一步分析滾動更新策略的細節，並探討更多進階的佈署技術，以滿足不同應用場景的需求。

滾動更新策略的進階組態

滾動更新（RollingUpdate）是 Kubernetes 中最常用的佈署策略。它透過逐步替換舊版本的 Pod，確保應用程式在更新過程中保持可用性。滾動更新的兩個關鍵引數是 maxSurge 和 maxUnavailable，它們控制著更新過程中的 Pod 數量。

maxSurge 和 maxUnavailable 的作用

  • maxSurge：指定在更新過程中可以超出預期副本數量的最大 Pod 數量。可以是數字或百分比（如 25%）。
  • maxUnavailable：指定在更新過程中可以不可用的最大 Pod 數量。同樣可以是數字或百分比。

透過調整這兩個引數，我們可以實作不同的滾動更新策略，以適應各種應用場景。例如，將 maxSurge 設定為較高值，可以加快更新速度，但可能會增加資源使用量；將 maxUnavailable 設定為較低值，可以確保更高的可用性，但可能會延長更新時間。

漸進式滾動更新與最大努力控制滾動更新

漸進式滾動更新

漸進式滾動更新適合於需要逐步觀察應用程式狀態的場景，避免一次性更新所有 Pod 導致潛在問題。以下是一個示例組態：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx

內容解密： 此組態定義了一個名為 nginx 的 Deployment，包含 10 個副本。maxSurge: 1 表示在更新過程中最多額外建立一個 Pod，而 maxUnavailable: 0 保證在更新過程中沒有 Pod 處於不可用狀態。

最大努力控制滾動更新

最大努力控制滾動更新適用於需要在不影回應用程式可用性的前提下，盡快完成更新的場景。以下是一個示例組態：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx

內容解密： 在此組態中，maxSurge: 0 表示不會建立額外的 Pod，而 maxUnavailable: 25% 表示最多允許 25% 的 Pod 同時不可用。這種組態可以在保證一定可用性的同時，加快更新速度。

Blue/Green 佈署與 Canary 發布

除了滾動更新，Kubernetes 生態系統還支援其他進階佈署策略，如 Blue/Green 佈署和 Canary 發布。

Blue/Green 佈署

Blue/Green 佈署涉及兩個獨立的環境：一個執行當前版本（Blue），另一個執行新版本（Green）。流量可以透過切換 Service 的標籤選擇器，從 Blue 環境切換到 Green 環境，從而實作無縫升級。

Canary 發布

Canary 發布涉及將新版本佈署到一小部分使用者或流量中，以測試其穩定性和效能。如果新版本表現良好，可以逐漸增加其接收的流量比例，最終完全替換舊版本。

這些進階佈署策略需要額外的工具和組態，例如使用 Istio 或其他服務網格技術來管理流量分配。

玄貓 BlackCat

玄貓 BlackCat

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