Kubernetes最佳實踐應用藍圖

– 12 分鐘閱讀

Kubernetes 已成為容器協調領域的事實標準，本文旨在提供 Kubernetes 的最佳實踐，涵蓋從基礎設定到進階應用的各個導向。本文並非 Kubernetes 入門教材，讀者需具備 Kubernetes 基礎知識。本文內容涵蓋開發流程、持續整合與測試、建構高階平台、狀態管理、服務操作、叢集管理、機器學習整合以及外部服務整合等主題。新版更加入 GitOps、安全性、混沌測試和 Operator 等新興技術與方法。本文適合已有一定 Kubernetes 基礎，並希望深入學習如何在實際環境中佈署和管理應用程式的工程師。

透過逐步建構一個簡單的多層應用程式，包含網頁應用程式和資料函式庫，示範如何在 Kubernetes 中設定和管理應用程式。這個日誌服務應用程式包含 NGINX 靜態檔案伺服器、RESTful API，並使用 Let’s Encrypt 服務管理 SSL。本文將會使用 YAML 設定檔和 Helm Charts 逐步建構這個應用程式，並提供程式碼範例和詳細說明。

Kubernetes 最佳實踐：開發成功應用的藍圖

在當今的雲端運算時代，Kubernetes 已經成為容器協調事實上的標準。無論是初創公司還是大型企業，都在利用 Kubernetes 來佈署和管理他們的應用程式。《Kubernetes 最佳實踐》第二版，由 Brendan Burns、Eddie Villalba、Dave Strebel 和 Lachlan Evenson 四位 Kubernetes 專業人士撰寫，為讀者提供了深入的指導，幫助他們在 Kubernetes 上構建成功的應用程式。

為什麼需要 Kubernetes 最佳實踐？

隨著 Kubernetes 生態系統的不斷擴充套件，管理和維護 Kubernetes 叢集變得越來越複雜。許多企業在採用 Kubernetes 的過程中遇到了各種挑戰，從設定和開發到安全和監控，每一步都需要謹慎的規劃和執行。因此，學習和遵循 Kubernetes 最佳實踐變得至關重要。

本文的特色

  • 深入淺出：本文假設讀者已經具備基本的 Kubernetes 知識，但希望進一步瞭解如何在生產環境中成功佈署和管理應用程式。
  • 豐富的實務經驗：四位作者結合了他們在分散式系統、開源軟體和企業應用開發方面的豐富經驗，為讀者提供了寶貴的見解和建議。
  • 最新的 Kubernetes 功能：本文涵蓋了最新的 Kubernetes 功能、新工具和棄用功能，確保讀者能夠跟上技術的最新發展。
  • 具體的程式碼範例：書中包含了許多具體的程式碼範例，幫助讀者更好地理解和實踐所學的知識。

本文涵蓋的主題

1. 設定和開發應用程式

本文首先介紹瞭如何在 Kubernetes 上設定和開發應用程式，包括如何建立和管理 Pod、Service 和 Deployment 等基本資源。

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
        ports:
        - containerPort: 80

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的版本和型別。
  • metadata 包含了資源的中繼資料，如名稱和標籤。
  • spec 定義了資源的期望狀態，包括副本數量、選擇器和範本。
  • template 定義了 Pod 的範本，包括容器和埠。

2. 監控和安全

本文還詳細介紹瞭如何監控和保護 Kubernetes 叢集，包括如何使用 Prometheus 和 Grafana 進行監控，以及如何使用 Network Policy 和 Secret 來保護應用程式。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的版本和型別。
  • metadata 包含了資源的中繼資料，如名稱。
  • spec 定義了資源的期望狀態，包括 Pod 選擇器和入口規則。
  • podSelector 定義了允許存取的 Pod 範圍。

3. 升級和回復

本文還介紹瞭如何管理 Kubernetes 中的升級和回復，包括如何使用 Rolling Update 和 Rollback 來確保應用程式的平滑升級。

kubectl rollout update deployment nginx-deployment --image=nginx:latest

內容解密：

  • kubectl rollout update 命令用於更新 Deployment 的映像檔。
  • --image 引數指定了新的映像檔名稱。

圖表翻譯：

此圖示展示了 Kubernetes 中 Deployment 和 Pod 之間的關係。

圖表翻譯：

  • 此圖表展示了 Kubernetes 中 Deployment、ReplicaSet 和 Pod 之間的關係。
  • Deployment 控制 ReplicaSet，ReplicaSet 管理 Pod，Pod 執行容器。

Kubernetes 最佳實踐：資源管理與排程最佳化

Kubernetes 作為現代雲原生應用的基礎設施，其資源管理與排程能力直接影回應用的效能和可靠性。本章將探討 Kubernetes 中的資源管理機制，重點分析排程器的工作原理、資源分配策略以及相關的最佳實踐。

Kubernetes 排程器的工作原理

Kubernetes 排程器（Scheduler）是叢集的核心元件，負責將新建立的 Pod 分配到合適的節點上執行。其主要流程包括以下步驟：

  1. 過濾（Predicates）：排程器根據預定義的規則過濾掉不符合要求的節點，例如：

    • 資源不足（CPU、記憶體等）
    • 節點標籤或汙點（Taints）不匹配
    • 硬體或軟體需求不滿足

  2. 優先排序（Priorities）：在透過過濾的節點中，排程器根據優先順序規則進行排序，選擇最優節點。例如：

    • 資源利用率均衡
    • 資料區域性最佳化
    • 應用親和性（Affinity）組態

程式碼範例：排程器組態最佳化

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: kubernetes.io/hostname
              whenUnsatisfiable: DoNotSchedule

內容解密：

此組態定義了一個預設排程器，使用 PodTopologySpread 外掛來最佳化 Pod 在不同節點上的分佈。其中：

  • maxSkew 設定了 Pod 分佈的最大偏差。
  • topologyKey 指定了拓撲結構的鍵值，這裡使用主機名進行區分。
  • whenUnsatisfiable 設定為 DoNotSchedule 表示當條件不滿足時不進行排程。

資源管理最佳實踐

有效的資源管理需要綜合考慮應用的需求和叢集的整體資源狀況。以下是一些最佳實踐：

  1. 資源請求與限制：為每個容器設定合理的資源請求（Request）和限制（Limit），確保應用在獲得足夠資源的同時不會過度佔用叢集資源。

  2. Pod 親和性與反親和性：透過組態親和性規則，將相關聯的 Pod 排程到相近的節點，或將競爭資源的 Pod 分散到不同節點。

  3. 節點汙點與容忍度：使用汙點（Taints）標記特殊節點，並透過容忍度（Tolerations）控制 Pod 是否可以排程到這些節點。

程式碼範例：Pod 資源組態

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

內容解密：

此範例展示了一個 Pod 的資源組態：

  • requests 定義了容器啟動所需的最低資源量。
  • limits 設定了容器可使用的最大資源量，防止其無限制佔用資源。

Kubernetes 資源排程流程

圖表翻譯： 此圖展示了 Kubernetes 中 Pod 的排程流程：

  1. 當建立一個新的 Pod 時，排程器首先進行節點過濾。
  2. 過濾透過的節點進入優先順序排序階段。
  3. 最終選擇最優節點並將 Pod 繫結到該節點上。
  4. 若無符合條件的節點，Pod 將進入等待狀態。

Kubernetes 多叢集管理與應用整合的最佳實踐

隨著雲原生技術的發展，Kubernetes 已經成為容器協調的標準。然而，隨著企業數位轉型的深入，單一叢集的架構逐漸無法滿足日益複雜的業務需求。因此，多叢集管理成為企業提升彈性、擴充套件性和安全性的重要手段。本文將探討 Kubernetes 多叢集管理的最佳實踐，以及如何將外部服務與 Kubernetes 進行整合。

為什麼需要多叢集？

多叢集架構能夠為企業帶來多方面的好處，包括：

  1. 隔離不同環境：開發、測試和生產環境可以佈署在不同的叢集中，以確保環境之間的隔離。
  2. 提升可用性：在多個地理位置佈署叢集，可以提高應用的可用性和容災能力。
  3. 滿足法規遵從：不同地區的資料儲存和處理需求可以透過多叢集架構來滿足。
  4. 資源最佳化：根據不同業務需求，將工作負載分配到不同的叢集，以最佳化資源利用率。

多叢集設計的考量因素

在設計多叢集架構時，需要考慮以下關鍵因素：

  1. 叢集間的通訊：確保叢集之間的網路連通性，同時考慮安全性和延遲問題。
  2. 統一管理：使用統一的管理工具來簡化多叢集的管理和維護工作。
  3. 資源分配：合理分配資源，避免資源浪費或不足。
  4. 安全性：確保每個叢集的安全組態一致，並實施統一的安全策略。

多叢集管理的最佳實踐

  1. 使用 GitOps 管理多叢集：透過 GitOps，可以實作多叢集組態的版本控制和自動化佈署，提高管理的效率和一致性。
  2. 選擇合適的多叢集管理工具：例如 Kubernetes Federation、Rancher 等工具，可以簡化多叢集的管理工作。
  3. 實施統一的監控和日誌收集：透過統一的監控和日誌收集系統，可以及時發現和解決多叢集環境中的問題。

將外部服務與 Kubernetes 整合

在多叢集架構中，將外部服務與 Kubernetes 進行整合是一個常見的需求。以下是一些常見的整合方式：

  1. 匯入外部服務到 Kubernetes：透過建立 Service 物件，將外部服務匯入到 Kubernetes 叢集中。
  2. 使用 LoadBalancer 型別的 Service：將 Kubernetes 中的服務暴露給外部，透過 LoadBalancer 實作負載平衡。
  3. 使用 Ingress Controller：透過 Ingress Controller，可以實作對外部流量的統一管理和路由。
內容解密：

本文主要討論了 Kubernetes 多叢集管理的最佳實踐，以及如何將外部服務與 Kubernetes 進行整合。首先，介紹了多叢集架構的好處和設計考量因素。接著，提出了多叢集管理的最佳實踐，包括使用 GitOps 和選擇合適的管理工具。最後，探討了將外部服務與 Kubernetes 整合的方法，包括匯入外部服務和使用 LoadBalancer 和 Ingress Controller。整篇文章從理論到實踐，為讀者提供了全面的指導。

圖表翻譯：

此圖示展示了多叢集架構的整體設計，包括不同叢集之間的關係以及與外部服務的整合方式。圖中清晰地標示了各個元件的功能和相互之間的連線，幫助讀者更好地理解多叢集管理的核心概念。

@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

圖表翻譯： 此圖示呈現了一個典型的 Kubernetes 多叢集架構下的流量路由流程。客戶端的請求首先到達 Ingress Controller，然後根據路由規則被分發到不同的 Service。每個 Service 再透過負載平衡將請求分發到後端的 Pod 上。這種設計有效地提升了應用的可用性和可擴充套件性。

前言

Kubernetes 已成為雲端原生開發的實際標準。它是一個強大的工具，可以讓您的下一個應用程式更容易開發、更快佈署、更可靠地執行。然而，要充分發揮 Kubernetes 的強大功能，需要正確地使用它。本文旨在幫助任何將真實世界應用程式佈署到 Kubernetes 的人，學習可以應用到他們在 Kubernetes 上構建的應用程式的模式和實踐。

本文適合誰閱讀

本文並不是 Kubernetes 的入門書。我們假設您對 Kubernetes API 和工具有基本的熟悉，並且知道如何建立和與 Kubernetes 叢集互動。如果您正在尋找學習 Kubernetes，有很多優秀的資源，例如《Kubernetes：Up and Running》，可以為您提供入門介紹。

相反，本文是為那些想要深入瞭解如何在 Kubernetes 上佈署特定應用程式和工作負載的人準備的資源。無論您即將在 Kubernetes 上佈署第一個應用程式，還是已經使用 Kubernetes 多年，本文都將對您有所幫助。

為什麼我們寫這本文

我們四個人在幫助各式各樣的使用者將他們的應用程式佈署到 Kubernetes 方面擁有豐富的經驗。透過這些經驗，我們看到了人們在哪些地方遇到困難，並幫助他們找到成功的道路。在撰寫這本文時，我們試圖捕捉這些經驗，以便更多的人可以透過閱讀我們從這些真實世界經驗中學到的教訓來學習。我們希望透過將我們的經驗寫下來，可以擴充套件我們的知識，讓您能夠成功地在 Kubernetes 上佈署和管理您的應用程式。

如何瀏覽本文

雖然您可以將本文從頭到尾一次性讀完，但這並不是我們預期的使用方式。相反，我們設計本文為一系列獨立的章節。每個章節都對您可能需要使用 Kubernetes 完成的特定任務提供了完整的概述。我們預計人們會深入閱讀本文，以瞭解特定的主題或興趣，然後放下本文，直到新的主題出現時再回來閱讀。

儘管採用了這種獨立的方法，但仍有一些主題貫穿全書。有幾章討論了在 Kubernetes 上開發應用程式。第 2 章涵蓋了開發人員工作流程。第 5 章討論了持續整合和測試。第 15 章涵蓋了在 Kubernetes 上構建更高層級的平台，第 16 章討論了管理狀態和有狀態應用程式。除了開發應用程式之外，還有幾章討論了在 Kubernetes 中操作服務。第 1 章涵蓋了基本服務的設定，第 3 章涵蓋了監控和指標。第 4 章涵蓋了組態管理，而第 6 章涵蓋了版本控制和發布。第 7 章涵蓋了在全球範圍內佈署您的應用程式。

還有幾章討論了叢集管理，包括第 8 章關於資源管理，第 9 章關於網路，第 10 章關於 Pod 安全，第 11 章關於政策和治理，第 12 章關於管理多個叢集，以及第 17 章關於准入控制和授權。最後，有些章節是真正獨立的；這些章節涵蓋了機器學習（第 14 章）和與外部服務整合（第 13 章）。

雖然在實際嘗試這些主題之前閱讀所有章節可能會有所幫助，但我們的主要希望是您將本文視為一本參考。它旨在作為您在真實世界中實踐這些主題時的。

本版新增內容

我們希望透過四個新的章節來補充第一版，涵蓋了隨著 Kubernetes 不斷成熟而出現的新工具和模式，並提供了最佳實踐。這些新的章節是第 18 章關於 GitOps，第 19 章關於安全，第 20 章關於混沌測試，以及第 21 章關於實作 Operator。

本文使用的排版慣例

本文使用以下排版慣例：

  • 斜體：表示新術語、URL、電子郵件地址、檔案名稱和檔案副檔名。

內容解密：

本文的內容安排合理，每個章節都獨立成篇，方便讀者根據自己的需求進行閱讀。同時，本文也涵蓋了許多重要的主題，包括開發應用程式、操作服務和叢集管理等。對於想要深入瞭解如何在 Kubernetes 上佈署和管理應用程式的人來說，本文是一本非常有價值的參考。

設定基本服務

本章節描述在 Kubernetes 中設定簡單多層應用程式的程式。我們將要講解的範例包含兩個層級：一個簡單的網頁應用程式和一個資料函式庫。雖然這不是最複雜的應用程式，但對於學習如何在 Kubernetes 中管理應用程式來說，這是一個良好的起點。

應用程式概述

我們用於範例的應用程式相當直接。它是一個簡單的日誌服務，具有以下特點：

  • 它有一個獨立的靜態檔案伺服器，使用 NGINX。
  • 它在 /api 路徑上擁有一個 RESTful 應用程式介面（API） https://some-host-name.io/api。
  • 它在主網址 https://some-host-name.io 上有一個檔案伺服器。
  • 它使用 Let’s Encrypt 服務來管理安全套接層（SSL）。

圖 1-1 呈現了這個應用程式的圖表

此圖示呈現了應用程式的架構，包括靜態檔案伺服器、RESTful API 和資料函式庫等元件。

圖表翻譯： 此圖示說明瞭日誌服務的整體架構，包括 NGINX 靜態檔案伺服器、RESTful API 和 Let’s Encrypt SSL 管理服務。各元件之間的關係和資料流向也在圖中清晰呈現。

使用 YAML 組態檔案和 Helm Charts 建置應用程式

我們將逐步講解如何建置這個應用程式，首先使用 YAML 組態檔案，然後使用 Helm Charts。

程式碼範例與說明

apiVersion: apps/v1
kind: Deployment
metadata:
  name: journal-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: journal-service
  template:
    metadata:
      labels:
        app: journal-service
    spec:
      containers:
      - name: journal-service
        image: journal-service:latest
        ports:
        - containerPort: 80

內容解密：

上述 YAML 組態檔案定義了一個名為 journal-service 的 Deployment 物件。其中：

  • apiVersion 和 kind 指定了該物件的 API 版本和型別。
  • metadata 部分定義了 Deployment 的名稱。
  • spec 部分定義了 Deployment 的規格，包括副本數量、選擇器和範本。
  • template 部分定義了 Pod 的範本，包括容器名稱、映像檔和埠號。 該組態檔案確保了 journal-service 應用程式能夠以 Deployment 的形式佈署在 Kubernetes 叢集中，並且具有三個副本。
玄貓 BlackCat

玄貓 BlackCat

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