Docker 與 Kubernetes 容器協調技術深度解析

– 9 分鐘閱讀

Docker 提供 Macvlan 等網路驅動方案，能讓容器直接與外部網路溝通，提升網路效率。相較於橋接網路，Macvlan 避免了 NAT 和埠對映的效能損耗，適用於對網路效能要求較高的場景。在容器數量眾多的生產環境中，Kubernetes 等容器協調系統扮演著關鍵角色。Kubernetes 使用 etcd 作為鍵值儲存，儲存叢集狀態和組態資訊。其核心元件包含 Master 節點（API Server、Scheduler、Controller Manager）和 Worker 節點（Kubelet、Kube Proxy）。API Server 作為叢集控制入口，Scheduler 負責 Pod 的排程，Controller Manager 確保 Pod 副本數量符合預期。Kubelet 負責在 Worker 節點上管理 Pod 的生命週期，Kube Proxy 則負責 Pod 的網路代理。Kubernetes 使用 Pod 作為最小佈署單元，並透過 Service 提供穩定的網路連線入口，即使 Pod 位置變動，服務也能持續運作。例如，佈署多個 MySQL Pod 時，可透過 Service 對外提供穩定的資料函式庫連線，簡化應用程式連線設定，並提升系統容錯能力。

自訂網路（Custom Networks）

在 Docker 中，管理容器叢集的方法不僅限於 Docker Swarm。還有多種開源技術，如 Kubernetes 和 Mesos，可以用來管理叢集。這些技術通常需要一個有效的鍵值儲存服務來儲存必要的資訊，如發現、端點、IP 地址等。常見的鍵值儲存服務包括 Consul、Zookeeper 和 etcd 等。

基礎網路驅動或 Macvlan

Macvlan（媒體存取控制虛擬區域網）是另一種內建的網路驅動，相對輕量且簡單。它不使用內建的 Linux 橋接和埠對映，而是將容器的介面直接連線到主機介面（如 eth0 或子介面）。

這些基本上都是在主機的一個物理介面背後的虛擬介面。透過這種方式，每個虛擬介面都有唯一的 MAC 和 IP 地址。這使得容器能夠直接與外部資源通訊，而無需進行 NAT（網路地址轉換）和埠對映，從而使這個驅動程式比其他替代方案更高效。

與覆寫網路類別似，Macvlan 網路與其他網路分段隔離。同一主機上的容器如果不在同一個 Macvlan 網路中，則無法彼此通訊。以下圖示展示了這種基礎網路的結構。

  graph TD;
    subgraph "Host 1"
        c11[Container 1]
        c21[Container 2]
        c31[Container 3]
        c41[Container 4]
        eth270[eth2.70]
        eth280[eth2.80]
    end
    subgraph "Host 2"
        c12[Container 1]
        c22[Container 2]
        c32[Container 3]
        c42[Container 4]
        eth270_2[eth2.70]
        eth280_2[eth2.80]
    end

    c11 --> eth270;
    c21 --> eth270;
    c31 --> eth280;
    c41 --> eth280;

    c12 --> eth270_2;
    c22 --> eth270_2;
    c32 --> eth280_2;
    c42 --> eth280_2;

    subgraph "Macvlan Network 1"
        direction TB
        eth270
    end

    subgraph "Macvlan Network 2"
        direction TB
        eth280
    end

此圖示解說：

  • Host 1 和 Host 2 分別包含四個容器。
  • 每個容器都有其自己的虛擬介面（ethx.yy），並且連線到主機的物理介面。
  • Macvlan 網路將容器直接連線到主機的物理介面，使得容器能夠直接與外部資源通訊。

Docker 的靈活性

Docker 在網路方面非常靈活。如果您的需求更加複雜，無法透過之前討論的選項解決，您可以編寫自己的網路驅動外掛或使用現成的外掛，如 Weave Net 或 Flannel。

叢集協調（Container Orchestration）

管理少量容器與管理數百甚至數千個生產級容器截然不同。為了支援大規模容器管理，我們需要一種簡單易用的方式來佈署和處理這些容器。這就是所謂的叢集協調。本文將探討業界的一些選項並涵蓋每個選項的基本工作原理。由於叢集協調是一個快速變化的領域，請參考提供的連結瞭解最新發展。

主要工具

在叢集協調領域有許多選項可供選擇：

  • Kubernetes
  • Mesos + Marathon
  • Docker Swarm

以下是對這些工具的一些基本介紹。

Kubernetes

Kubernetes 是由 Google 引領的一個開源專案。Google 在大規模管理和佈署容器方面有豐富經驗。Kubernetes 是幫助您在需要時執行容器化應用程式的協調引擎之一。

主要元件

以下是 Kubernetes 的主要元件：

  graph TD;
    subgraph "Master Node"
        API_Server[(API Server)]
        Scheduler[(Scheduler)]
        Replication_Controller[(Replication Controller)]
    end

    subgraph "Worker Node 1"
        Pod1[(Pod)]
        Kubelet_1[(Kubelet)]
        Kube_Proxy_1[(Kube Proxy)]
    end

    subgraph "Worker Node 2"
        Pod_2[(Pod)]
        Kubelet_2[(Kubelet)]
        Kube_Proxy_2[(Kube Proxy)]
    end

    Kubectl[(kubectl)] -- interacts with --> API_Server;

    API_Server -- communicates with --> Kubelet_1;
    API_Server -- communicates with --> Kubelet_2;

    API_Server -- communicates with --> etcd[(etcd)];

kubectl

Kubernetes 提供了一個命令列介面 kubectl 用於執行命令和與 Kubernetes 叢集互動。

Master Node

Master 是 Kubernetes 的大腦，協調叢集活動並藉助一些支援服務執行。它包括 API Server、排程式和複製控制器等元件。

API Server

API Server 負責暴露 REST API 與 Kubernetes 叢集互動。所有客戶端（kubectl）與 Kubernetes 叢集之間發生的外部通訊以及工作節點與主節點之間發生的叢集通訊都由 API Server 操作。

Scheduler

Kubernetes 排程式負責將容器放置（排程執行）到叢集節點上。它透過建立 Pods 來完成這一點，Pods 是 Kubernetes 排程的基本單位。可以把 Pods 想像成具有獨立名稱空間的邏輯主機，其中一個或多個容器生活其中。

當向 Kubernetes API Server 提交請求時，API Server 與排程式合作將 Pods 放置在叢集節點上。在將 Pod 放置在工作節點之前，排程式會檢查各種標準：

  • 哪些節點有足夠的資源（如 CPU 和記憶體）來執行 Pod 中的容器
  • 節點是否有足夠開啟的埠供 Pod 請求
  • 將 Pod 放置在哪裡以避免延遲問題（節點親和性）
  • 是否將 Pod 分佈在叢集中以支援高用性

排程式必須根據這些標準做出智慧、知情決策來放置 Pods 在叢集中。這正是 Kubernetes 排程式的一個關鍵功能。

副本控制器

副本控制器確保在任何給定時間內執行指定數量的 Pod 副本。如果某些 Pod 被刪除或終止，副本控制器會啟動新的 Pod 副本以滿足所需狀態。

etcd

etcd 是一個分散式鍵值儲存系統，用於儲存 Kubernetes 叢集中的所有組態資料和狀態資訊。

  graph TD;
    A[Client] --> B[API Server];
    B --> C[etcd];

此圖示解說：

  • Client 應用程式透過 API Server 與 etcd進行互動。
  • etcd 用於儲存 Kubernetes 叢集中的組態資料和狀態資訊。

建立和管理 Pods 的範例

假設我們要建立並執行三個 Tomcat 應使用案例項：

kubectl run myTomcat --image=tomcat --replicas=3

裡面運作流程：

  • kubectl 提交我們要執行三個 Tomcat 應使用案例項的意圖或請求給 API Server。
  • API Server 與排程式和副本控制器協作來執行此請求並使叢集達到所需狀態。
  • 副本控制器確保三個 Tomcat 應使用案例項始終執行。
  • 排程式決定將這些 Pods 放置在哪些工作節點上以滿足資源需求和高用性要求。

透過上述流程可以清楚瞭解 Kubernetes 中如何高效地管理和排程容器化應用程式。

容器協調的核心元素

在現代雲端運算環境中，容器協調是實作高效資源管理與應用程式佈署的關鍵技術。本文將探討 Kubernetes 協調器、副本控制器、工作節點及 Pods 的運作原理，並透過具體案例來解說這些元素如何協同工作，確保應用程式的高用性與資源效率。

容器協調與 Kubernetes 協調器

Kubernetes 協調器負責決定將 Pods 安排到哪個節點上執行。它會讀取 Pods 的需求，例如所需的 CPU、記憶體資源、高用性需求、節點親和性等，並根據這些需求從 etcd 資料函式庫中取得可用節點的資訊。以下是 Kubernetes 協調器的典型決策流程：

  1. 需求分析與節點篩選： 協調器會先檢查 Pods 的資源需求和其他政策，然後從可用節點中篩選出符合這些需求的節點。例如，如果一個節點只有 4G 記憶體剩餘，而 Pod 需要至少 8G 記憶體，那麼這個節點會被排除在外。

  2. 政策考量與最佳節點選擇： 在第一步透過的節點中，協調器會進一步分析這些節點的各項政策，如高用性、負載平衡等。例如，為了避免單一故障點，協調器會嘗試將相同服務的多個 Pods 分散到不同的節點上執行。

  3. Pods 安排與執行： 一旦選定了最佳節點，協調器會將 Pods 安排到該節點上執行。如果需要更複雜的排程邏輯，可以自行插入定製化的協調器來滿足特定需求。

副本控制器（Controller Manager）

副本控制器的主要職責是確保在叢集中始終執行指定數量的 Pod 副本。假設我們要求 Kubernetes 在叢集中執行三個 Tomcat 容器例項，副本控制器會建立並排程這三個 Pods。如果其中一個節點失效，導致某個 Tomcat Pod 無法執行，副本控制器會立即啟動另一個 Tomcat Pod 以維持預期狀態。

此外，副本控制器還可以根據實際需求動態調整 Pod 副本數量。例如，如果我們發現只需要兩個 Tomcat Pod 副本即可處理當前流量，可以透過以下命令來調整：

kubectl run myTomcat --image=tomcat --replicas=2

副本控制器會移除多餘的 Pod 副本以維持預期狀態。

工作節點與 Kubelet

工作節點是實際執行 Pods 的地方。每個工作節點內都執行著一個名為 Kubelet 的代理程式。Kubelet 是每個工作節點與主節點之間的唯一接觸點，負責從主節點接收工作並執行這些工作（即 Pods）。Kubelet 會確保這些 Pods 成功啟動並在工作節點上正常執行。

此外，Kubelet 還負責向主節點報告每個工作節點和其上的每個 Pod 的狀態。這些資訊儲存在 etcd 資料函式庫中，並由主節點使用這些資訊來進行下一次排程決策。例如，協調器和副本控制器都依賴這些資訊來判斷哪些資源可用及需要維護何種狀態。

Pods 的動態特性

Pods 是 Kubernetes 中最小的佈署單元，具有高度動態性。它們可以根據需要建立、移動或擴充套件。以下是一個具體案例來說明這一特性：

案例：Kubernetes 叢集中的 MySQL Pods

假設我們在 Kubernetes 叢集中執行三個 MySQL Pods：

  • Pod 1：標籤 app=MySQL，埠 3306
  • Pod 2：標籤 app=MySQL，埠 3306
  • Pod 3：標籤 app=MySQL，埠 3306
MySQL Service

MySQL Consumer 1 Consumer 2

Node 1                    Node 2                    Node 3
+---------------------+   +---------------------+   +---------------------+
|                     |   |                     |   |                     |
|   POD 1             |   |   POD 2             |   |   POD 3             |
|   Label: app=MySQL  |   |   Label: app=MySQL  |   |   Label: app=MySQL |
|   Port: 3306        |   |   Port: 3306        |   |   Port: 3306        |
+---------------------+   +---------------------+   +---------------------+
                        |
                MySQL Service

此圖示展示了三個 MySQL Pods 分佈在不同的工作節點上。

Kubernetes Services 的重要性

在微服務架構中，消費者需要知道如何連線到 MySQL 資料函式庫。由於 MySQL Pods 的位置可能隨時變動（例如因故障而移動），消費者無法直接連線到特定的 IP 地址和埠。因此，Kubernetes 提供了 Services 作為抽象層來解決這個問題。

Services 提供了一個虛擬 IP 地址和埠，消費者只需連線到這個地址即可達到後端相關的所有 Pods。無論後端 Pods 的位置如何變動，Services 始終提供穩定的連線入口。

MySQL Services

Consumer                      Service                       PODs
       +---------------------------+                            +---------------------+
       |                          V                           Node1       Node2      Node3
       |       MySQL Service         +-------------------+    +---------------------+
       +--------------------------->| Virtual IP: xx.xx.xx.xx, Port:xxxx            |
                                  +---------------------------+
                                |
               Consumer          |
               Connect to        |
               Database          V

此圖示展示了消費者透過 MySQL Service 與後端 MySQL Pods 的互動方式。

##與挑戰

隨著容器協調技術的不斷發展，Kubernetes 未來將繼續面臨以下幾個挑戰與機遇：**

  • 高階自動化與智慧化：隨著人工智慧技術的不斷進步，未來容器協調可能會更加智慧化，能夠根據複雜資料和策略進行更為精準和高效的資源分配。
  • 安全性：隨著容器化應用程式數量的增加，安全問題將變得越來越重要。容器協調平台需要提供更為強大和靈活的安全功能以應對各種潛在威脅。
  • 效能最佳化：雖然現有技術已經相當成熟，但仍有很大空間進行效能最佳化。特別是對於大規模叢集來說，網路延遲、資料傳輸效率等方面都需要進一步最佳化以提升整體系統表現。
  • 全球化支援：隨著雲端計算普及，全球範圍內佈署應用程式也變得越來越普遍。未來，Kubernetes 需要提供更好的全球化支援，以滿足不同地理位置下應用程式的佈署和管理需求。

內容解密：

在探討 Kubernetes 協調系統時，玄貓強調以下幾項核心概念：

  1. 順序架構：Kubernetes 協調系統包含多層次結構：協調策略決定、副本控制、POD 與 Service 領域。
  2. 自動化與智慧化：為應對未來挑戰，玄貓認為未來系統應該融入人工智慧能力進一步提升決策精準度與資源利用率。
  3. 安全性優先：隨著應用數量增長，安全問題也日益嚴峻，亟待更強大且靈活之安全防護功能。
  4. 全球支援： 隨著全球佈署普及，玄貓認為未來系統應具備良好的全球支援機制以滿足不同地理位置之佈署與管理需求。
  5. 深層技術選型分析： 若要面對上述挑戰，玄貓建議深刻思考技術選型並且提供具體改進方案以達到最佳效果。
玄貓

玄貓

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