一文讓你瞭解Kubernetes架構

本篇文章咱們將會探討Kubernetes的總體架構。

Kubernetes起源自Google內部系統Borg，它是容器應用集羣部署和管理的系統。Kubernetes核心功能是爲了減輕物理機或者虛擬機集羣編排、網絡以及存儲等的管理負擔，使開發者只須要關注應用的業務邏輯。經過Kubernetes開發者能夠自定義工做流甚至自動化的任務流。

Kubernetes擁有全面的集羣管理能力，主要包括：多級的受權機制、多租戶應用、透明的服務註冊和發現機制、內置的負載均衡、錯誤發現和自修復能力、服務升級回滾和自動擴容等。Kubernetes擁有完善的管理工具，主要包括：部署、部署測試、集羣的運行和資源狀態的監控等。

什麼是Borg

Borg是Google內部大規模集羣管理系統，主要工做是對Google內部服務的調度和管理。Borg的主要目標是將開發者從硬件資源管理中解放出來，將精力集中在業務邏輯上、最大化多數據中心的資源利用。

以下如所示：Borg系統主要由如下組件構成：BorgMaster、BorgLet、Borgcfg和Scheduler。

• BorgMaster 整個集羣的大腦：負責管理集羣的狀態、保證集羣存儲的數據具備高度容錯性
• Scheduler 負責任務的調度工做：按照應用的特色將它們調度到適當的機器上
• BorgLet 負責任務的運行工做
• Borgcfg 是Borg系統的命令行交互工具，事實上是經過配置文件向集羣系統提交任務

Kubernetes 架構

Kubernetes中的Pod、Service、Label以及一個Pod一個IP地址等的設計依託於Borg，所以總體上看，Kubernetes與Borg的架構很是類似。

Kubernetes中提供靈活和鬆耦合的機制用於服務發現，像大多數分佈式集羣平臺，Kubernetes集羣中至少包含一個主節點和多個工做節點。

主節點負責暴露應用程序的API、調度deployments和管理整個集羣。每一個工做節點都運行着容器運行時，（如Docker或者rkt）經過代理與主節點通訊。

工做節點同時運行着其它組件，如：日誌、監控、服務發現和其它可選組件。工做節點是Kubernetes集羣中真正運行應用的地方。工做節點能夠是雲服務商提供的虛擬機或者是運行着的服務器。

Pod是一個或多個容器的集合並扮演着Kuberntes集羣中最核心的管理單元，Pod同時也充當着容器共享的上下文和資源的邏輯邊界。Pod的分組機制彌補了容器化與虛擬化的差別從而實如今Pod中執行多個子進程。在運行時，Pod能夠經過建立replica sets實現集羣的擴容，同時Replica set保證集羣內須要的Pod數量與真正運行的Pod數量的一致。

Replica sets聲明須要掛起Pod的數量和監控預約的Pod中有效的數量。單個Pod或者Replica Set能夠經過Service向內部或外部用戶暴露服務，Service經過篩選知足條件的Pod實現服務發現。Pod經過定義鍵值對的Label，Service經過Seletor篩選合法的Pod。任何新Pod打上知足Seletor篩選器的Label後將會自動被Service服務發現。這種設計架構提供了靈活、鬆耦合的服務發現機制。

Kubernetes中的資源對象（如：Pods、Replica setsje和Service）提交到master節點後，Master節點根據Pod的需求和資源的可用性將Pod調度到適當的工做節點上。工做節點從鏡像倉庫中拉取鏡像，而後在本地運行時環境中拉起容器。

etcd是CoreOS開源的、分佈式、鍵值對數據庫，它是集羣全部組件單一數據源（SSOT）的保障。Master節點查詢etcd獲取工做節點、Pods和容器狀態的各類參數。

Kubernetes主要由如下組件構成：

• Apiserver是操做資源的入口而且提供認證、受權、權限控制、API註冊和服務發現的機制
• Controller Manager負責管理集羣的狀態，如異常發現、自動擴容和滾動更新等
• Scheduler負責資源的調度以及根據預先設定的調度策略將pod調度到合適的節點上
• Kubelet負責管理容器的生命週期、數據卷以及網絡（CNI）
• 容器運行時負責鏡像的管理
• Kube-proxy負責服務發現和集羣Service的負載均衡

除了以上核心內容，接下來咱們將討論

• 編排鬚要使用簡單、功能複雜的容器架構
• 簡要概述容器編排和Kubernetes
• 容器化環境下的網絡

編排層

在容器化的架構中，編排層須要實現對容器的部署、擴容和管理。

• 將容器調度到物理或者虛擬機上，有時還須要維護千級別的容器主機
• 在容器宕機的時候從新拉起
• 設置容器網絡
• 對容器進行擴容以及創建和解除資源間的關係
• 服務發現

開發者能夠經過購買業界雲服務商提供的IaaP和IaaS服務實現容器編排。根據業務分佈式容器管理架構的需求，開發者能夠在雲服務商那裏選擇具有適當編排難度的服務。

簡單編排架構

你知道簡單的node.js架構嗎？若是你的程序只須要或者與下面類似的架構（不多的進程、一個或者兩個數據庫、一個負載均衡器、一個客戶端和一個宿主機），docker內置的[編排工具就能夠知足你的需求。

若是你的技術架構比上圖複雜不少，我以爲Amazon ECS或者Kubenrnets更適合你的需求，接下來咱們在談談K8s。

Kubernetes組件

依託於Kubernets主從的設計架構，系統能夠提供高效、水平擴容的分佈式系統。網絡特性促進大量組件間的高效通訊。

下面是Kubernetes中的核心組件：

• Pod：Kubernets中最小的管理和部署單位，一個Pod中能夠有一個或多個容器。同一Pod中的容器共享IP地址、經過localhost相互通訊、共享數據卷
• Node：Kubernetes中工做節點，可使物理機或者虛擬機、爲Pods提供運行資源
• Service：一組邏輯Pods和它們訪問策略的抽象，爲一組相同屬性的Pods抽象出一個固定IP地址，容許Pod之間以及Pod與Service之間相互通訊
• ReplicaSet：保證集羣在任什麼時候間點上都有指定數量的Pod副本，除非你須要定製滾動更新的策略或者不須要滾動更新，K8s推薦使用Deployment而不是直接操做ReplicaSet
• Deployment：提供Pods滾動更新和ReplicaSets的控制器
• Namespace：將集羣資源

下圖經過虛擬的邊界描述Kubernetes組件各自的做用範圍：

標籤和篩選器

Kubernetes爲區分用戶和資源提供許多特性：

• Labels: 附在資源對象（如Pod）的鍵值對，可使如發佈期限、環境和堆棧等具備辨識度的元數據
• Selector：Kubernetes中的核心分組原語，標籤篩選器能夠經過標籤分組管理資源對象

Labels、Selector和namespces在Kubernetes中實現靈活動態的配置能力發揮着相當重要的做用。須要明確一點相同namespace下的兩個控制器的標籤篩選器不能重合，否則會引起衝突。

Kubernetes的設計是以分佈式框架的基礎，它在構建和管理其它微服務以及分佈式框架等方便表現的很是出色。深刻探討Kubernetes提供服務的詳細信息不在本書探討的範圍內，下圖是展現Kubernete上各組件間相互做用的更高級視圖。

當咱們研究Kubernetes如何處理容器網路時請記住上圖的中的信息流。

容器網絡

容器間的網絡問題是容器編排中最嚴苛的挑戰之一，在這一部分咱們將會探討Docker處理容器連通的網絡策略，這種策略是如何限制容器編排的規模以及Kubernetes是如何在上實現容器網絡連通的基礎上實現快速優雅的擴容。

Docker處理容器間網絡

默認狀況下Docker容器使用host-private網絡。爲了實現容器間網絡連通，Docker所在的宿主機提供默認名爲docker0的虛擬網橋，宿主機並會爲網橋上的容器預留足夠的空間。容器和網橋是如何鏈接的？Docker爲每一個容器分配一個虛擬網絡設備（veth），經過網絡地址轉換（NAT）將虛擬網橋的地址與容器的地址映射到一塊兒。NAT方法是經過修改網絡包的IP頭信息將一個IP地址映射爲其它的IP地址。

這種方案對自動化運維的挑戰

首先這種經過網橋實現容器網絡的連通須要容器在同一臺宿主機或連接在相同的網橋上。這對於容器網絡量有限，限制集羣數量的狀況下是能夠知足的，可是對多宿主機的集羣就會形成網絡故障。另外徹底依靠NAT實現網絡的連通也會形成性能故障。

Kubernetes處理容器間網絡

Kubernetes的網絡方案比Docker默認的網絡方案更加高效且更易擴容。爲了實現這個目的，Kubernetes的網絡實現必須知足如下需求。

• 全部容器在不使用NAT時能夠與其餘容器通訊
• 全部子節點能夠在不使用NAT時能夠與其它容器通訊
• 全部容器本身看到的IP地址與其它節點或者容器看到的IP地址是同樣的

當知足這些條件後，在多個團隊和開發人員之間協調移植變得更加容易。諸如Flannel、WeaveNet、Calico均可以實現Kubernetes容器網路的連通。

文章翻譯自Kubernetes architecture Quick Introduction，行文時略有刪減