本文轉載自微信公眾號「架構精進之路」，作者架構精進之路。轉載本文請聯系架構精進之路公眾號。

1. 容器編排技術

容器編排是指對多個容器的部署，管理和監控。

之所以有容器編排技術，其實是和業務量與系統復雜度與日俱增推動服務部署的演進方式息息相關的，下圖是服務部署方式的演進過程。

更高效的利用系統資源、一致的運行環境、更輕松的遷移和拓展等諸多優點，使容器部署方式越來越成為主流。

Docker 是開源的被廣泛應用的容器引擎，在實際生產環境中，在多臺物理主機中協調容器資源成為首要要解決的問題，這一問題被統稱為容器編排。

容器領域現階段爭論的重點也正在于為容器主機群管理提供怎樣容器編排功能。

目前比較流行的容器編排工具包括 Docker Swarm，Kubernetes 和 Mesos+Marathon。容器使用的最核心問題也恰是容器編排及如何部署和管理容器。Docker Swarm，Kubernetes，Mesos+Marathon 都可用于容器的部署、管理以及實現容器的擴縮容，但這三種編排工具著重處理的問題和使用場景也是不同的。

2. 初識 Kubernetes

2.1 Kubernetes 概述

Kubernetes 也簡稱為 k8s，它可以提供?戶所需的容器部署，管理和擴縮容等編排功能。

借助 Kubernetes 的編排功能，?戶可以構建多個容器的應?服務，跨集群調度、擴展這些容器，并長期持續管理這些容器和檢測健康狀況 。

2.2 Kubernetes 能做什么?

Kubernetes 為?戶主要提供了以下功能：

• 服務發現和負載均衡：Kubernetes 可以使?DNS 名稱或集群的 IP 公開容器，如果進?容器的流量很?， Kubernetes 可以用負載均衡并均衡分配流量使服務穩定。
• 存儲編排：Kubernetes 允許你?動掛載選擇的存儲系統，例如本地存儲、公共云提供商等。
• 動部署和回滾：你可以使?Kubernetes 描述已部署容器的所需狀態，它可以以受控的速率將實際狀態更改為期望狀態。例如，你可以?動化的方式來部署創建新容器， 刪除現有容器并將它們的所有資源?于新容器。
• 動完成裝箱計算：Kubernetes 允許你指定每個容器所需 CPU 和內存(RAM)。當容 器指定了資源請求時，Kubernetes 可以做出更好的決策來管理容器的資源。
• 我修復：Kubernetes 能重啟容器、替換容器、殺死不符合定義運?狀況檢查的容器，并且這些功能對客戶端都是無感知的。
• 密鑰與配置管理：Kubernetes 允許你存儲和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。你可以在不重建容器鏡像的情況下部署和更新密鑰和應?程序配置，也?需 在堆棧配置中暴露密鑰。

2.3 為什么是 Kubernetes?

回歸根本問題：why Kubernetes?

可擴展性

Kubernetes 具有很好的可擴展性。K8s 內置一組資源，例如 Pod，Deployment、StatefulSets、Secrets、ConfigMaps 等，用戶和開發人員也可以以“Custom Resource Definition”的形式添加更多自定義資源。Kubernetes 可擴展性的另一種形式是開發人員具有編寫自己的 Operators 的能力，operator 允許用戶通過與 Kubernetes API 進行對話來自動管理 Custom Resource Definition。

強大的社區

Kubernetes 受歡迎的另一個重要方面是其強大的社區。Kubernetes 于 2015 年在 1.0 版本時就捐贈給了與供應商無關的基金會，Kubernetes 是活躍在 Github 中前幾名的項目之一：占有在所有項目前 0.01%的排名。隨著項目的推進，還有各種各樣的社區 SIG(特殊興趣小組)針對 Kubernetes 中的不同領域。他們不斷添加新功能，并使其對用戶更加友好。

技術與革新

Kubernetes 基于谷歌的 Borg 的開源技術，它累積了 Borg15 年的深耕細作的發展和生產實踐。在過去的幾年中，Kubernetes 每年都有三到四個大小版本發布。引入的新功能的速度到目前也并未減慢，這些新功能使集群運營商在運行各種不同的工作負載時具有更大的靈活性。軟件工程師也能擁有更多控件，以將其應用程序直接部署到生產環境中。

3. Kubernetes 構成與基本原理

3.1 Kubernetes 集群

上圖可以看到一個集群主要包括兩個部分：

• 一個 Master 節點，也稱為控制平?，是 Kubernetes 集群的?腦。

其中包括如下組件：

• Api server：是整個系統的對外接口，供客戶端和其它組件調用，相當于“營業廳”；
• Etcd：Api server 的后臺數據存儲，相當于 Kubernetes 集群的數據中?;
• Scheduler：負責對集群內部的資源進行調度，相當于“調度室”;
• Controller-manager：控制管理器，保證 Kubernetes 集群中的資源按照要求運?。

2、一群 Node 節點，也稱為 Worker 節點 ，主要負責 Pod 的運。

主要包括以下組件：

• Kubelet：負責與 Master 節點交互，進?執?具體的任務;
• Kubelet：負責與 Master 節點交互，進?執?具體的任務;
• Kube-proxy：負責 Kubernetes 集群中的負載均衡;
• Container-runtime：提供容器運行環境，有 docker，rkt 或者其他容器實現標準，負責容器的操作，啟動或者關閉等;
• Pod：k8s 的最小調度單元，1 個 pod 可以包含 1 個或多個容器，pod 可以理解為容器的集合。

3.2 Master 節點及運行機制

我們知道了 Master 節點包括 Api Server、Scheduler、Controller manager、Etcd。

下面對這幾種組件一一做介紹。

Api server

Kubernetes API Server 是集群的統一入口，各組件協調者，以 HTTP API 提供接口服務，所有對象資源的增刪改查和監聽操作首先交給 API Server 處理，下一步再給 Etcd 存儲。

Controller-manager

Controller-manager 是 Kubernetes 中的資源管理器。Kubernetes 集群中有很多

的資源，如 Node、Pod 副本、服務端點 Endpoint、命名空間 namespace、服務賬號

ServiceAccount 等。Controller-manager 負責這些資源的管理，以保證這些資源實際運?的狀態達到被期望的狀態。

Etcd

Etcd 是一個高可用的鍵值存儲系統，主要用于共享配置和服務發現。它使用 Go 語言編寫，并通過 Raft 一致性算法處理日志復制以保證強一致性。

Etcd 可以理解為 Kubernetes 集群的數據中?，用于保存集群狀態信息，比如 Pod、Service 等對象信息。Etcd 主要和 Api server 交互比較多，Api server 接受操作命令后，會將信息存儲到 Etcd 中。從下文的 pod 的狀態流程可看到，Api server 構建出完整的 Pod 信息，并將該信息存儲到 etcd 中。

Scheduler

Scheduler 是 Kubernetes 集群中的調度器。Scheduler 的作?是將待調度的 Pod 按照特定的調度算法和調度策略綁定到集群中某個合適的 Node 上，并將綁定信息通過調?Api server 寫?etcd 中。scheduler 在整個系統中承擔了承上啟下的重要功能，承上是指它負責接收 Controller manager 創建新的 Pod，為其安排一個落腳的目標 Node，啟下是指安置 Node 工作完成后，目標 Node 上的 kubelet 服務進程接管 Scheduler 的后繼工作。

3.3 node 節點及運行機制

Node 節點主要包括 Kubelet、Kube-proxy、Pod，其中最重要的也就是 Pod 了。

下邊我們來一一進行介紹：

Kubelet

kubelet 是 Master 在 Node 節點上的 Agent，每個節點都會啟動 kubelet 進程，該進程?于處理 Master 下發到本節點的任務，管理 Pod 及 Pod 中的容器。每個 kubelet 進程都會在 Api server 上注冊節點信息，定期向 Master 匯報節點資源的使?情況，并監控容器和節點資源。

kubelet 在啟動時通過 Api server 注冊節點信息，并定時向 Api server 發送節點的新信息，Api server 在接收到這些信息后，將這些信息寫?etcd。kubelet 監聽 etcd，所有針對 Pod 的操作都會被 kubelet 監聽。如果發現有新的綁定到本節點的 Pod，則按照 Pod 清單的要求創建該 Pod。如果發現本地的 Pod 被修改，則 kubelet 會做出相應的修改，?如在刪除 Pod 中的某個容器時，會通過操作本地容器運?時刪除該容器。

Kube-proxy

在 Kubernetes 集群的每個 Node 上都會運??個 kube-proxy 服務進程，其核?功能是將到某個 Service 的訪問請求轉發到后端的多個 Pod 實例上。kube-proxy 本質上類似一個反向代理。我們可以把每個節點上運行的 kube-proxy 看作 service 的透明代理兼負載均衡器。kube-proxy 也監聽 api server 中 service 與 Endpoint 的信息, 通過配置的 iptables 規則,請求通過 iptables 直接轉發給 pod。

Pod

Pod 是最小部署單元，一個 Pod 有一個或多個容器組成，Pod 中的容器共享存儲和網絡，在同一臺 Docker 主機上運行。

pod 的構成示意圖如下所示：

可以看到由一個 pause 的根容器，加上一個或多個業務容器構成。

kubernetes 中的 pause 容器主要為每個業務容器提供以下功能：

• PID 命名空間：Pod 中的不同應用程序可以看到其他應用程序的進程 ID。
• 網絡命名空間：Pod 中的多個容器能夠訪問同一個 IP 和端口范圍。
• IPC 命名空間：Pod 中的多個容器能夠使用 System IPC 或 POSIX 消息隊列進行通信。
• UTS 命名空間：Pod 中的多個容器共享一個主機名 Volumes(共享存儲卷)

Pod 里多個業務容器共享 pause 容器的網絡棧和 Volume 掛載卷。

正是由于業務容器共享這些資源，同一個 Pod 里的容器之間僅需通過 localhost 就能互相通信，所以他們之間通信和數據交換更為高效，在設計時我們可以充分利用這一特性將一組密切相關的服務進程放入同一個 Pod 中。

3.4 Pod 的數量和版本控制

ReplicationController 用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器異常退出，會自動創建新的 Pod 來替代。

在新版本的 Kubernetes 中建議使用 ReplicaSet 來取代 ReplicationController ，ReplicaSet ReplicaSet 跟 ReplicationController 沒有本質的不同，只是名字不一樣，并且 ReplicaSet 支持集合式的 selector。雖然 ReplicaSet 可以獨立使用，但一般還是建議使用 Deployment 來自動管理 ReplicaSet，這樣就無需擔心跟其他機制的不兼容問題。Deployment 為 Pod 和 ReplicaSet 提供了一個 聲明式定義方法，用來替代以前的 ReplicationController 來方便的管理應用。Deployment 典型的場景：滾動更新

Deployment 不僅可以滾動更新，還可以進行回滾，如何發現升級到 V2 版本后，發現服務不可用，可以回滾到 V1 版本。

3.5 Pod 的創建流程

以創建 Pod 為例，來理解 Kubernetes 中的各組件的運行流程：

• 通過 api server 向集群發起創建 Pod 的指令，api server 將 yaml 中的配置的屬性信息(metadata)寫入 etcd 中。
• apiserver 觸發 watch 機制準備創建 pod，信息轉發給調度器 Scheduler，Scheduler 使用調度算法選擇 node，然后將 node 信息給 api server，api server 將綁定的 node 信息寫入 etcd。
• api server 又通過 watch 機制，調用 kubelet，指定 pod 信息，觸發 docker run 命 令創建容器。
• 創建完成之后反饋給 kubelet, kubelet 又將 pod 的狀態信息給 api server, api server 又將 pod 的狀態信息寫入 etcd。
• ?此 Pod 真正的創建完畢。如果因為某些原因 Pod 出現了問題，集群中的 controller-manager 會向 apiserver 發起創建的請求。

4. Kubernetes 的服務暴露

Pod 能創建成功了，也能很好的對 Pod 做管理了，那么客戶端如何找出相應的 Pod 調用其服務呢?

Kubernetes 支持多種服務暴露的方式。

下面介紹ClusterIP、NodePort和Ingress是三種廣泛使用的服務暴露方式。其中 ClusterIP 和 NodePort 方式屬于 Service 資源類型，Ingress 屬于 Ingress 資源類型。

4.1 Service—ClusterIP 服務暴露

Kubernetes 集群會為一組 Pod 分配對應的集群 IP，同時產??個域名。集群內部可以通過這集群 IP 或者域名訪問 Service 對應的 Pod。

該類型只能在集群內部訪問，也是默認的 ServiceType。

apiVersion: v1kind: Servicespec:
    metadata:
    name: my-service
  selector:
    app: my-app
  type: ClusterIP
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

上面的示例定義了一個 ClusterIP Service。ClusterIP 上端口 80 的流量將轉發到 Pod 上的 8080 端口 (targetPort 配置項)上，攜帶 app: my-app標簽的 Pod 將被添加到 Service 中作為作為服務的可用節點。

常見使用場景：

集群內部服務的暴露。

4.2 Service—NodePort 服務暴露

NodePort 在固定端口號上公開向集群外部暴露服務，它允許從集群外部訪問該服務，在集群外部需要使用集群的 IP 地址和 NodePort 指定的端口才能訪問。

創建 NodePort Service 將在集群中的每個 Node 上開放該端口。

創建 NodePort Service 的同時還會自動創建一個 ClusterIP 類型的 Service，NodePort 會將端口上的流量路由給 ClusterIP` 類型的 Service。

常見使用場景：

可以使用 NodePort 快速設置開發，測試環境的服務或在其上公開 TCP 或 UDP 服務，但是對于公開 HTTP 服務來說 NodePort 不是一個的理想選擇，因為其使用的都是非 HTTP 標準的端口。

4.3 Ingress 服務暴露

Ingress 實際上是與 Service 完全不同的資源，算是 Service 上面的一層代理，通常在 Service 前使用 Ingress 來提供 HTTP 路由配置。它讓我們可以設置外部 URL、基于域名的虛擬主機、SSL 和負載均衡。

為了讓 Ingress 資源?作，集群必須有?個正在運?的 Ingress 控制器。與 Controller-manager 控制器不同，Ingress 控制器不是隨集群?動啟動的，可以選擇不同外部組件來做 Ingress 控制器。

比如：nginx-ingress，它使用 nginx 服務器作為反向代理來把流量路由給后面的 Service。

常見使用場景：

可以處理 http，https 請求的流量，并且可以處理多個域名的流量。一個 IP 可以暴露多個應用，支持同域名不同 uri，支持證書等功能。使用場景比較廣泛。

5. Kubernetes 在企業中的應用

無論是中小型企業，還是大型互聯網為了提高資源利用率，實現降本增效，利用 Kubernetes 構建一套自動化運維環境已成為最佳選擇。

下圖是企業服務云平臺正在實現的云上架構能力的一幅藍圖，其中服務容器化作為云平臺基礎中的基礎能力。在容器的編排和管理上最基礎能力上實現擴容、限流等可操作 api 和日志、監控等可觀測的 api。上層能力層可通過這些 api 提供服務構建，部署，流量控制等功能。

可見 Kubernetes 在整個架構圖中重要的位置。

從容器編排管理的實現細節來看，如下圖，經過 7 層負載，請求會打到一組 Ingress 控制器上，由于容器的 ip 會經常變動，所以 Ingress 會向上屏蔽掉變動，到達了 Ingress 請求就由 Kubernetes 來控制了，Kubernetes 會將此請求路由到相應服務的某個 Pod 上,同一個服務會有多個 Pod，這些 Pod 也會分部在不容物理機上。目前貝殼采用 Eureka 注冊，每個 Pod 對應的服務節點，都會在 Eureka 上注冊， 如果服務 A 需要調用服務 B，則請求到服務 A 的 pod 后，會從 Eureka 上尋找服務 B 的 Pod 的節點(目前通過 Eureka+DNS 來實現)拿到上游服務 Pod 信息后就直接調用服務 B 某一個 Pod 上的服務了。