容器技術是最近幾年非常熱門的技術，它似乎就是為雲端的應用量身定制的，所以它也被貼上了雲原生應用 (Cloud Native Application) 技術的標籤。目前最為流行的容器管理調度平臺是 Kubernetes (縮寫為 K8s)，是 Google 為支持大批量容器而開發的企業級運行平臺，可以支援負載均衡、高可靠等生產級功能。
VMware 在 VMworld 2017 上也宣佈了跟 Pivotal、Google 合作開發的 VMware Pivotal Container Service，這是一個商用的 K8s 平臺，簡稱 PKS (中間的K代表 Kubernetes)。
我們專門為 VMware 用戶寫了這篇文章，利用你所熟悉的 vSphere 平臺來跟 K8s 作一個類比，從而幫助你快速瞭解 K8s。
VSPHERE 平臺和 KUBERNETES 的總體對比
那麼到底什麼是 Kubernetes 呢? 簡單來說，K8s 和容器的關係就相當於vSphere和虛機的關係。在 VMware 發展早期的時候，那時候只有 VMware Workstation，後來出現了基於vCenter 和ESXi 的VI/vSphere 體系架構，從而使虛擬化步入了資料中心。同樣的，容器一開始的時候只有一個簡單的容器引擎 Docker，K8s 的出現為容器提供了一個生產級的運行環境。把 vSphere 和 K8s 平臺肩並肩放在一起比較的話，你會發現它們的概念有很多類似之處，這可以幫助我們很快地理解 K8s 技術的各種細節。
系統架構
就像 vSphere 平臺上的 vCenter 和 ESXi 主機， K8s 平臺上也有對應的概念：Master 和節點 (node)， Master 的作用就跟 vCenter 一樣，是對整個 K8s 集群進行管理，它也是工作負載管理 API 的存取入口。跟 ESXi 主機對應的就是K8s節點，節點是 K8s 集群中的計算資源，容器就是運行在節點上，節點可以是虛機或者實體伺服器。K8s 也有一個類似於 vCenter DB 的資料庫 “etcd”，它以的“鍵-值”方式儲存了整個集群的配置和狀態。
跟 vSphere 不同的是，K8s Master上也能運行容器負載，當然 vCenter Server 上是不運行虛機的。雖然 K8s Master 也是一種計算資源，但是一般只在上面運行系統管理相關的容器應用，普通的應用負載不應該放在 Master 上。
vSphere 有GUI 管理介面 Web Client 和命令列管理介面 vCLI 和 Power CLI，K8s 也提供了GUI 介面或命令列來管理 K8s 集群。下面的畫面是使用命令 “kubectl.exe” 來管理K8s 集群的例子，我們可以看到這個集群有一個 Master (vkubemaster007) 和4個節點 (vkubemode017~18)，K8s 的版本是v1.6.5，節點上的作業系統是Ubuntu 16.04。
工作負載
vSphere 中的工作負載調度單位是虛機， K8s 中的調度單位是Pod；一台ESXi 主機上可以運行多個虛機，一個 K8s 節點上也可以運行多個 Pod，每個 Pod 都有一個獨立的 IP 位址來跟其他的 Pod 相通訊。在vSphere 環境中，應用運行在虛機的作業系統中，K8s 平臺上應用運行在容器裡；一個虛機中只能運行一個作業系統實例，而一個 Pod 中可以運行多個容器實例。K8s 會考慮到 Pod 的關聯性而把 Pod 中的容器實例運行在同一個節點上，從而讓他們共用同一個運行環境；一般是把一個應用和它相關的輔助模組設計在同一個 Pod 中，然後作為一個整體來進行調度運行。
系統管理
我們使用 Web Client 來管理 vSphere 集群，K8s 也有一個圖形化的管理介面Dashboard，同 Web Client 一樣，這也是一個基於 Web 的應用。Dashboard 的功能也變得越來越強大，它可以實現大部分的 K8s 集群管理功能，而不用輸入很長的 kubectl 命令。
系統組態
K8s 可以通過一個YAML (Yet Another Markup Language) 檔來定義和描述 K8s 集群的配置和狀態，然後就可以基於該檔創建整個 K8s 集群，K8s 會盡力地保持集群運行在指定的狀態。例如，如果你指定了某一個 Pod 要有4個副本，K8s 就會監控所有這些 Pod 的運行，如果有任何一個 Pod 工作異常的話，它就會設法修復這個狀態，實在不行的話就另啟一個 Pod 副本。
要理解 YAML 設定檔的話，你可以把它對應為虛機的 .VMX 文件，或是 Virtual Appliance 的 .OVF 文件。當然，YAML 設定檔在 K8s 中不僅用於定義集群，也用於定義其他的組件，如： 複本集合、服務、部署等。
虛擬集群
vSphere 中為了管理資源的分配專門有一個“資源池 (Resource Pool)”的概念，就像是在物理集群中劃分出了一些小的虛擬集群，vSphere 利用資源池來控制資源的分配。K8s 也有類似的概念叫“namespaces”，namespace 的主要用途是創建多租戶環境，也可以在上面指定資源配額 (Resource Quota) 。
資源管理
vSphere 需要指定每一個 Resource Pool 的資源配置限額，K8s 可以在 namespace 上設置資源配額 (Resource Quotas) 來控制資源配置，這是在 YAML 設定檔中定義的。
工作負載標記
這在 vSphere 和 K8s 中幾乎是完全一致的，vSphere 使用 tag 標籤來標識虛機，而 K8s 使用標籤 (label) 來標識容器。所不同的是，K8s 中標籤是必須的，而不是可選的。
計算冗餘
vSphere 中有 Fault Tolerance 技術來提供計算資源的冗餘，受保護的虛機運行在一台伺服器上，另一台伺服器上有一個從被保護虛機複製而來的影子 (Shadow)，FT 技術通過 Lockstep 來同步主虛機和影子虛機之間的資料和狀態。正常情況下影子虛機是不工作的，當主要伺服器當機時，影子虛機立刻被啟動成主虛機，並繼續主虛機工作；這時 vSphere 會設法在集群中找到另一台合適的伺服器，在上面從新的主虛機複製出新的影子虛機，以繼續對主虛機進行保護。
K8s 中也有相應的資源冗餘機制，ReplicaSets 用於指定一個 Pod 需要運行的實例數量，K8s 會自動維持實例的數量，任何一個實例由於故障原因當掉了，K8s 馬上會自動啟動一個新的實例補上。當然兩者基本的工作原理是不一樣的，K8s 中的所有實例正常情況都是在工作的，在多個實例間均衡工作負載，而不存在主備的概念，這是由雲原生應用的本質所決定的。
負載均衡
vSphere 並不內置有負載均衡功能，一般是通過虛擬的 (如NSX) 或物理的 (如F5) 負載等化器來把服務請求平均分配給多台虛機。負載均衡也有多種配置模式，以單肩模式 (one-armed) 為例，我們把網路流量東西向地均衡分配給虛機。
K8s 中也有類似的概念“Service”，是一組一起協作的 Pod，每個 Pod 都被定義了一個標籤選擇器 (label selector)。K8s Service 也有多種配置模式，例如“ClusterIP“模式，每個 Service 都被分配了一個外部可見的靜態 IP 位址和 DNS 功能變數名稱以便於被訪問到，負載流量以輪循 (round-robin) 的方式分配給每一個 Pod。其他的模式如 “NodePort” ，以不同埠訪問節點的流量會被映射到不同的 Pod；當然也可以配成 “LoadBalancer” 模式來使用外部的負載等化器。
K8s 還有另外一種非常重要的負載均衡機制 “Ingress Controller”，一個 ingress-controller 以 Pod 的形式存在，並且分配有一個外部可見的 IP 位址，該 IP 位址對應著一個含有萬用字元的 DNS 記錄，ingress-controller 根據預先設定的規則來把流量分配給不同的 Pod。例如下圖中的 IP 地址 192.168.100.244 對應 DNS 功能變數名稱 sphinx-v*.esxcloud.net，訪問sphinx-v1.esxcloud.net 的流量會被重定向給 “sphinx-svc-1”，而存取sphinx-v2.esxcloud.net 的流量被重定向給 “sphinx-svc2”。
本文節選自 VMware 網路和安全事業部高級架構師Hany Michaels 的部落格文章“Kubernetes Introduction for VMware Users – Part 1: The Theory”，為我們提供了一個有趣的視角來瞭解 Kubernetes。
