Kubernetes佈署有狀態應用程式實務

在 Kubernetes 環境中佈署資料函式庫等有狀態應用程式需要仔細規劃和組態，以確保資料的永續性和服務的穩定性。本文將逐步講解如何使用 YAML 檔案組態 PostgreSQL 資料函式庫，並詳細說明如何利用 PersistentVolumeClaim（PVC）實作資料持久化。同時，文章也將探討不同資料函式庫遷移策略的優缺點，並提供多檔案 YAML 組態管理的實務技巧，以提升佈署效率和管理效率。最後，文章將進一步探討雲原生軟體開發生命週期和多語言雲應用開發的最佳實踐，協助讀者更好地應對現代軟體開發的挑戰。

組態有狀態應用程式於Kubernetes環境

在現代軟體開發和資料函式倉管理領域中，容器化代表了一項重要的進步。本章節將探討傳統資料函式倉管理系統所面臨的挑戰，並介紹容器化資料函式庫作為解決方案，闡述其優勢並討論相關的疑慮。此外，本章還將為讀者提供進一步的資源，以深入探索此主題。

3.1 容器化資料函式庫

傳統資料函式倉管理系統經常面臨諸如可擴充套件性限制、環境不一致、資源利用效率低下以及佈署複雜等問題。容器化資料函式庫提供了一種解決這些問題的方法。

問題

擴充套件限制：傳統資料函式庫的擴充套件可能是一個複雜且耗費資源的過程。
環境不一致：開發、測試和生產環境之間的差異可能導致意外的錯誤。
資源利用效率低下：這些資料函式庫經常無法充分利用底層硬體，導致效率低下。
佈署複雜性：在不同平台上佈署和管理資料函式庫可能既繁瑣又耗時。

解決方案

以下YAML組態在Kubernetes中佈署PostgreSQL。此組態包括一個佈署和一個服務。佈署管理PostgreSQL容器，而服務將PostgreSQL暴露給叢集的其他部分或外部。

apiVersion: v1
kind: Service
metadata:
  name: postgres-service
spec:
  selector:
    app: postgres
  ports:
    - protocol: TCP
      port: 5432
      targetPort: 5432
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:latest
          env:
            - name: POSTGRES_DB
              value: mydatabase
            - name: POSTGRES_USER
              value: myuser
            - name: POSTGRES_PASSWORD
              value: mypassword
          ports:
            - containerPort: 5432
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: postgres-storage
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: postgres-pvc

#### 內容解密：

定義了一個名為postgres-service的服務來暴露PostgreSQL。
建立了一個名為postgres-deployment的佈署來管理PostgreSQL。
設定環境變數（POSTGRES_DB、POSTGRES_USER、POSTGRES_PASSWORD）以進行初始資料函式庫設定。
將預設的PostgreSQL埠5432暴露出來。
連線了一個名為postgres-storage的卷以實作持久化資料儲存。需要事先在叢集中建立一個名為postgres-pvc的PersistentVolumeClaim（PVC）。

3.2 在Kubernetes上實作資料持久化

在Kubernetes上佈署有狀態應用程式（如MySQL資料函式庫）可能具有挑戰性，特別是在確保資料持久化方面。

問題

確保資料持久化是佈署有狀態應用程式的一個關鍵挑戰。

解決方案

解決方案涉及使用PersistentVolumeClaim（PVC）物件。以下是逐步：

建立PVC請求：準備一個YAML清單（data.yaml）來請求儲存空間，例如1 GB。

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi


2.  **應用此清單**：使用Kubernetes命令列工具應用此清單。

    ```bash
$ kubectl apply -f data.yaml

驗證PVC和PV的建立：檢查PVC和相應的持久性儲存區（PV）的狀態。

$ kubectl get pvc $ kubectl get pv


4.  **在Pod中使用此宣告**：在Pod的YAML清單中的volumes部分參考PVC，並將此卷掛載到容器內，例如MySQL的`/var/lib/mysql`。

    ```yml
apiVersion: v1
kind: Pod
metadata:
  name: db
spec:
  containers:
    - image: mysql:8.3.0
      name: db
      volumeMounts:
        - mountPath: /var/lib/mysql
          name: data
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: root
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: data

#### 內容解密：

在Kubernetes中，預設的儲存類別會在請求PVC時自動建立一個匹配的PV。這種動態供應對於有狀態應用程式中的資料持久化至關重要。
Minikube中的儲存類別通常使用hostPath供應器，這意味著資料儲存在Minikube虛擬機器本身上。這種設定允許資料持久化，確保即使Pod重新啟動或被刪除，資料仍然保持完整。

3.3 將資料函式庫遷移到Kubernetes環境

將現有的資料函式庫遷移到Kubernetes是另一個挑戰。許多團隊將傳統的遷移工具容器化並整合到Kubernetes環境中。隨著應用程式的發展，它們的資料函式庫架構也會演變。

問題

將現有的資料函式庫遷移到Kubernetes可能會遇到各種挑戰，包括如何無縫整合現有的遷移工具和流程。

#### 未來趨勢與實務應用評估

隨著雲原生技術的發展，將有狀態應用程式佈署到Kubernetes環境中已成為現代軟體開發的一個重要方面。未來，我們可以預期看到更多針對有狀態應用程式的最佳實踐和工具的發展。同時，企業也需要評估其現有的IT基礎設施和流程，以確定如何最好地利用Kubernetes等雲原生技術來提高其業務效率和競爭力。

3.4 在 Kubernetes 上一次性套用多個 YAML 檔案

問題描述

在管理 Kubernetes 資源（如 Pod、Service 和 Deployment）時，管理員和開發者經常面臨如何有效處理多個 YAML 檔案的挑戰。逐一套用這些檔案不僅耗時，而且容易出錯，尤其是在大規模佈署或複雜應用程式中。

解決方案

為了高效地管理和套用多個 YAML 檔案，我們可以使用 kubectl apply 指令，並指定一個目錄或多個檔案作為引數。這種方法允許我們在單一指令中套用目錄內或多個檔案中指定的所有 YAML 設定，從而簡化佈署流程。

步驟說明

整理 YAML 檔案：將所有 YAML 檔案放置在特定目錄中。確保每個檔案都正確格式化，並包含必要的 Kubernetes 資源組態。
使用 kubectl apply 指令處理目錄：要套用目錄中的所有 YAML 檔案，請使用以下指令：
```
kubectl apply -f <directory_path>/
```
此指令將套用指定目錄中的所有 YAML 檔案。

資料函式庫遷移的最佳實踐

應用程式內執行遷移

在 Kubernetes 環境中，最簡單的遷移方法是於應用程式啟動時觸發遷移。然而，這種方法並未充分利用 Kubernetes 的功能，並且存在安全性風險，因為遷移工具和敏感的資料函式庫憑證在執行環境中暴露。此外，當佈署多個應用程式副本時，應用程式內遷移方法會強制順序載入，可能導致同時修改資料函式庫的風險，並顯著減慢佈署流程。

優點：實作簡單
缺點：未充分利用 Kubernetes 功能；存在安全性風險；佈署多副本時強制順序載入，可能導致同時修改資料函式庫並減慢佈署

使用 Init Containers 執行遷移

較佳的方法是使用 Kubernetes 的 Init Containers 在主要應用程式啟動前執行遷移。雖然這種方法將遷移工具從執行環境中移除，但仍然面臨同步挑戰，並且未能充分解決失敗場景，可能導致大量 Pod 卡在 Crash Loop 中，造成停機。

優點：將遷移工具從執行環境中移除
缺點：面臨同步挑戰；未能充分解決失敗場景

使用 Kubernetes Jobs 執行遷移

另一種方法是使用 Kubernetes Jobs，該方法在應用程式滾動更新前將遷移作為獨立步驟執行。這種方法通常使用 Helm pre-upgrade hooks 或 Argo CD pre-sync hooks 等工具實作，能夠確保遷移在獨立於執行環境的情況下執行一次。然而，這種方法仍然需要完全遵循 GitOps 原則。

優點：在應用程式滾動更新前將遷移作為獨立步驟執行
缺點：需要額外的工具；尚未完全遵循 GitOps 原則

使用 Operator Pattern

使用 Git 作為程式碼和基礎設施管理的中心樞紐，強調自動化、可稽核的佈署，是資料函式庫遷移的最佳實踐。Atlas Kubernetes Operator 是這種方法的典型範例。它允許透過 Kubernetes 定義和套用所需的資料函式庫結構，支援宣告式工作流程和版本控制。Operator 不斷協調所需和實際的資料函式庫狀態，提供比傳統 Jobs 更強壯和語意豐富的解決方案。

優點：遵循 GitOps 原則；支援宣告式工作流程和版本控制；提供強壯和語意豐富的解決方案
缺點：需要熟悉 Kubernetes Operator；可能需要更複雜的設定

範例：新增資料函式庫欄位

假設我們要在 users 資料表中新增 bio 欄位，需要建立以下 schema.yaml 清單：

apiVersion: db.atlasgo.io/v1alpha1
kind: AtlasSchema
metadata:
  name: atlasschema-mysql
spec:
  urlFrom:
    secretKeyRef:
      key: url
      name: mysql-credentials
  schema:
    sql: |
      create table users (
        id int not null auto_increment,
        name varchar(255) not null,
        email varchar(255) unique not null,
        bio varchar(255) not null,
        primary key (id)
      );

使用 Atlas Operator 套用此結構：

kubectl apply -f schema.yaml

Atlas Operator 將在背景套用結構變更，如圖 3-1 所示。

圖表翻譯：

圖 3-1 描述了宣告式結構遷移的流程，展示瞭如何透過 Kubernetes 和 Atlas Operator 管理資料函式庫結構變更。

圖表翻譯： 此圖表展示了宣告式結構遷移的流程。首先檢查 schema.yaml 是否存在，若存在則套用，Atlas Operator 將處理變更並更新資料函式庫結構，最終結束流程。

管理多檔案 Kubernetes 組態與佈署

在管理 Kubernetes 組態時，我們經常需要處理多個 YAML 檔案。為了簡化佈署流程並確保組態的一致性，我們可以採用多種方法來有效地管理和應用這些組態檔案。

使用 `kubectl apply` 命令處理多個檔案

當我們有多個 YAML 檔案需要佈署時，可以使用 kubectl apply 命令同時指定多個檔案。以下是一個示例命令：

kubectl apply -f deployment.yaml -f service.yaml -f configmap.yaml

內容解密：

kubectl apply 是用於應用組態變更的命令。
-f 選項用於指定組態檔案。
在此範例中，我們一次性應用了 deployment.yaml、service.yaml 和 configmap.yaml 三個檔案。
這種方法確保了相關資源的組態能夠被正確且一致地佈署。

驗證佈署結果

在應用組態檔案後，我們需要驗證資源是否正確佈署並執行。可以使用 kubectl get 命令來檢查資源的狀態：

kubectl get deployments
kubectl get services
kubectl get configmaps

內容解密：

kubectl get deployments 用於檢查佈署的狀態。
kubectl get services 用於檢查服務的狀態。
kubectl get configmaps 用於檢查組態對映的狀態。
這些命令幫助我們確認資源是否已正確建立並執行。

討論

將組態分散到多個檔案中有助於更好地組織和管理複雜的 Kubernetes 組態。例如，我們可以為每個佈署、服務和組態對映建立單獨的 YAML 檔案。這種方法提高了組態的可讀性和可維護性。

然而，需要注意的是，如果某些資源之間存在依賴關係（例如，服務依賴於佈署），我們必須確保依賴的資源先被定義或按照正確的順序應用組態檔案。

此外，kubectl apply 命令能夠智慧地管理變更。如果某個資源已經存在，它會更新該資源而不是建立一個新的例項。這種冪等性行為對於持續佈署（CD）管道和自動化工作流程至關重要。

雲原生軟體開發生命週期（SDLC）

傳統的軟體開發生命週期（SDLC）模型往往難以跟上雲原生環境的動態和分散特性。雲原生開發需要一種能夠適應快速迭代、持續交付和可擴充套件架構（如微服務和無伺服器計算）的方法。

採用雲原生 SDLC 的步驟

規劃與設計：首先了解雲原生架構，專注於可擴充套件性、彈性和獨立性。設計微服務並選擇合適的雲原生技術。
開發：以小而易於管理的程式碼塊進行開發。實施 CI/CD 管道來自動化建置、測試和佈署過程。使用容器化技術（如 Docker）和協調工具（如 Kubernetes）來管理和佈署服務。
測試：採用嚴格的測試策略，包括單元測試、整合測試和端對端測試。利用雲原生功能，如服務網格，進行流量控制和故障注入測試。
佈署：使用 Kubernetes 自動化佈署。採用藍綠佈署或金絲雀佈署策略，以最小化停機時間並降低佈署新版本的風險。
監控與維護：利用雲原生監控工具來跟蹤應用的效能和健康狀況。在應用的每一層實施日誌記錄和監控，以便快速識別和解決問題。
反饋與迭代：透過監控工具和使用者反饋管道不斷收集反饋。根據這些反饋快速迭代，確保不斷改進和適應。
安全：在整個 SDLC 中實施強大的安全措施，包括安全的編碼實踐、依賴項漏洞掃描和定期的安全稽核。

討論

在雲原生 SDLC 中，重點是小而頻繁的更新和彈性。微服務允許團隊獨立更新系統的部分，從而降低系統範圍故障的風險。對 DevOps 文化的重視促進了開發和營運團隊之間的協作，確保在開發過程早期考慮營運環境的現實。

此外，雲原生方法通常涉及利用受管理的服務和無伺服器計算，減少基礎設施管理的負擔，讓團隊能夠更專注於核心業務邏輯。

多語言雲應用開發

隨著企業的不斷擴充套件和多元化，越來越需要在各個雲平台和地區建立複雜且可擴充套件的應用。這些應用通常需要混合使用多種程式語言，以利用不同生態系統和函式庫的優勢。然而，管理多語言雲應用開發環境可能具有挑戰性。開發人員需要指導如何高效地設計、開發和維護這類別應用。

多語言程式設計的最佳實踐

選擇合適的語言組合：選擇適合專案的程式語言會對其成功產生重大影響。考慮不同語言和函式庫在專案背景下的優勢和劣勢。在生產力、效能和開發人員專業知識之間取得平衡。本文將探討選擇語言時需要考慮的因素，並提供各種使用案例中成功的語言組合範例。
有效設計微服務：在多語言環境中開發微服務可能會導致整合和相容性問題。採用清晰的設計策略，包括 API 合約、版本控制和標準化的通訊協定（如 REST 或 gRPC）。我們將探討用於建立多語言微服務的設計模式和工具，以確保它們能夠無縫協作。
管理依賴項和函式庫：協調不同語言和版本之間的依賴項可能很複雜。使用套件管理器、依賴項管理工具和容器化技術（如 Docker）來隔離每個語言的依賴項。我們將提供有效管理依賴項和避免版本衝突的實際範例。

雲原生 SDLC 流程圖

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes佈署有狀態應用程式實務

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

圖表翻譯： 此圖示展示了雲原生軟體開發生命週期（SDLC）的流程。首先進行規劃與設計，接著是開發階段，然後進入測試階段。測試完成後進行佈署，之後是監控與維護階段。在監控過程中，不斷收集反饋並進行迭代，同時在整個流程中實施安全措施。這種迴圈過程確保了軟體的不斷改進和適應性。

玄貓 BlackCat

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

Kubernetes佈署有狀態應用程式實務

組態有狀態應用程式於Kubernetes環境

3.1 容器化資料函式庫

問題

解決方案

#### 內容解密：

3.2 在Kubernetes上實作資料持久化

問題

解決方案

#### 內容解密：

3.3 將資料函式庫遷移到Kubernetes環境

問題

#### 未來趨勢與實務應用評估

3.4 在 Kubernetes 上一次性套用多個 YAML 檔案

問題描述

解決方案

步驟說明

資料函式庫遷移的最佳實踐

應用程式內執行遷移

使用 Init Containers 執行遷移

使用 Kubernetes Jobs 執行遷移

使用 Operator Pattern

範例：新增資料函式庫欄位

圖表翻譯：

管理多檔案 Kubernetes 組態與佈署

使用 kubectl apply 命令處理多個檔案

內容解密：

驗證佈署結果

內容解密：

討論

雲原生軟體開發生命週期（SDLC）

採用雲原生 SDLC 的步驟

討論

多語言雲應用開發

多語言程式設計的最佳實踐

雲原生 SDLC 流程圖

玄貓 BlackCat

使用 `kubectl apply` 命令處理多個檔案