Kubernetes容器平臺架構解讀
1.Kubernetes容器平臺架構解讀
Kubernetes是一個開源容器編排平臺，管理大規模分布式容器化軟件應用，是云計算發展演進的一次徹底革命性的突破。Kubernetes是谷歌的第三代容器管理系統，是Borg獨特的控制器和Omega靈活的調度器的組合。Kubernetes中的應用被打包成與環境完全分離的容器鏡像，并且自動配置應用并維護跟蹤資源分配。
Kubernetes是以應用為中心的技術架構與思想理念，向下屏蔽基礎設施差異，實現底層基礎資源統一調度及編排;向上通過容器鏡像標準化應用，實現應用負載自動化部署;中間通過Kubernetes通用的編排能力，開放API以及自定義CRD擴展能力，打造云原生操作系統能力，形成云計算新界面;助力研發團隊快速構建標準化、彈性高可靠、松耦合、易管理維護的應用系統，提升交付效率，降低運維復雜度。Kubernetes在技術架構方面具備三個能力：
敏捷的彈性伸縮能力：不同于虛擬機分鐘級的彈性伸縮響應，容器應用可實現秒級甚至毫秒級的彈性伸縮響應;
智能的服務故障自愈能力：容器應用具有極強的自愈能力，可實現應用故障的自動摘除與重構;
大規模的復制分發能力：容器應用標準化的交付制品，可實現跨平臺、跨區域，云邊一體規模化復制分發部署能力。
1.1.Kubernetes整體架構
Kubernetes是典型的主從分布式架構，由集中式管理節點(Master Node),分布式的工作節點(Worker Node)組成以及輔助工具組成。
集中式管理節點，對集群進行調度管理，有四大核心組件:
API Server：承擔集群的網關，實現統一認證鑒權對外服務，同時也是管理Node/Pod資源代理通道;
Scheduler：資源調度器，除了Kubernetes默認的調度器，也支持自定義調度器;
ETCD：集群狀態統一存儲，與Zookeeper類似的key-value存儲;
Controller Manger：控制管理器實現自愈、擴容、應用生命周期管理、服務發現、路由、服務綁定等能力;Kubernetes默認提供Replication Controller、Node Controller、Namespace Controller、Service Controller、Endpoints Controller、Persistent Controller、DaemonSet Controller等控制器。
分布式的工作節點，工作節點運行業務應用容器;默認會運行三大核心組件：
Kubelet：與管理節點通信并觸發指令執行，管理驅動網絡，存儲及容器運行時;
Kube Proxy：通過DNS實現服務發現，借助iptables規則引導訪問至服務IP，并將重定向至正確的后端應用，實現高可用負載均衡能力;
Container Runtime：容器運行時。為了擴展Kubernetes平臺適配能力，同時也標準化整個生態，通過CNI與CSI標準規范網絡及存儲的擴展;通過CRI與OCI標準規范容器鏡像及容器運行時的擴展;目前CRI支持的容器運行時有docker、rkt、cri-o、frankti、kata-containers和clear-containers等。
輔助工具，主要是輔助集群管理及網絡擴展:
kubectl通過API Server進行交互，實現集群管理的命令行工具;
Dashboard 是Kubernetes的web用戶管理監控界面;
Core DNS是可擴展的DNS服務器，實現集群服務發現能力。
1.2.Kubernetes核心理念
1.2.1.POD容器組，Kubernetes最小調度單元
Pod是Kubernetes的最小調度及資源分配單元，Pod之間相互隔離，通常情況一個Pod只建議運行一個容器，當某些容器之間關系非常緊密(Tightly coupled)，可以運行在同一Pod運行多個容器方便一起調度管理。一個Pod就是一個應用運行實例，通過同時運行多個Pod來實現應用橫向擴展能力。Pod本身沒有自恢復能力，當調度或運行失敗時，需要管理節點的Controller根絕配置觸發實現Pod重啟、重建或遷移等操作。
從Pod啟動過程來看，Pod容器主要是Pause Container，Init Container以及App Container三種類型容器組成：
Pause Container：又叫Infra Container，Pod通過Pause Container實現Pod多個容器網絡共享，Pause Container最先啟動并綁定Pod唯一IP地址與各種網絡資源，其他容器通過加入Pause Container的Network namespace來實現網絡共享。Pause是C語言實現，鏡像非常小只有700KB左右，并且永遠處于Pause(暫停)狀態;官方鏡像是gcr.io/google_containers/pause-amd64:3.0，同時也支持自定義。
Init Container：Pod中可以自定義一個或者多個Init Container，按照順序依次啟動，在應用Container之前啟動并執行一些輔助任務，比如執行腳本、拷貝文件到共享目錄、日志收集、應用監控等。將輔助功能與主業務容器解耦，實現獨立發布和能力重用。除了不支持Readiness Probe，其他與特性與普通容器保持一致。
App Container：Pod真正承接業務的Container，一般情況會獨立運行，如果是有微服務治理等需求會搭配Sidecar Container一起運行。在Init Container啟動完成之后，App Container會并行啟動，但是需要等待所有App Container處于就緒狀態，整個Pod才算啟動成功。
從POD的資源隔離來看，Pod容器主要由Linux提供的Namespace和Cgroup能力實現的，Namespace實現進程間隔離，Cgroup實現進程資源控制;其中Namespace由ipc 、uts 、net 、mnt 、pid 各種資源空間聯合組成。
CRI是Kubernetes v1.5引入的，將Kubelet與容器運行時解耦;CRI中定義了容器和鏡像的服務的接口，因為容器運行時與鏡像的生命周期是彼此隔離的，所以定義了RuntimeService和ImageService兩個服務，其中RuntimeService主要包含Sandbox和Container兩種容器的管理gRPC接口，Sandbox就是上面Pod啟動過程中提到的Pause容器。目前支持CRI的后端有cri-o，cri-containerd，rkt，frakti，docker等，cri-o是由redhat發起并開源且由社區驅動的container-runtime，輕量化專為kubernetes而生，主要目的就是替代docker作為kubernetes集群的容器運行時。
1.2.2.Volume存儲卷，Kubernetes復雜的存儲架構
存儲非常重要關鍵，同時也是生態與技術都比較復雜的領域，就linux、window兩個生態支持的文件系統就多達20+。對于Kubernete存儲架構設計一直在持續演進完善，為了盡可能多地兼容各種存儲平臺，Kubernetes以in-tree plugin的形式默認對接很多不同類型的存儲系統;同時也支持基于FlexVolume和CSI插件以out-of-tree plugin來實現自定義存儲服務。
對Kubernetes存儲，主要有應用的基本配置文件讀取、密碼密鑰管理;應用的存儲狀態、數據存取，不同應用間數據共享等三大使用場景。目前Kubernetes支持的Volume Plugins如下表：
|
Temp |
Ephermeral(Local) |
Persistent(Networked) |
Others |
|
• Empty Dir |
• Host Path |
• AWS ElasticBlockStore(EBS) |
• Flex Volume |
Empty Dir：生命周期與Pod保持一致，當Pod刪除后emptyDir中的數據也會被自動清除。當前emptyDir支持的類型有內存、大頁內存、Node節點上Pod所在的文件系統。
ConfigMap：主要是承擔配置中心，用于存儲應用的配置數據，比如Springboot應用properties配置文件數據，但是空間大小限制在1MB內。
Secret：功能與ConfigMap類似，用于存儲應用的敏感數據，比如數據密碼、token、證書等，可以與ConfigMap聯合使用，同樣空間大小限制在1MB內。
HostPath：將Node節點本地文件系統路徑映射到pod容器中使用。與emptyDir不同之處就是Pod刪除后，HostPath中的數據Kubernetes根據用戶的配置，可以不被清除。
In-tree網絡存儲：網絡存儲跟隨Pod的生命周期，通過存儲插件對接不同類型存儲;其中FlexVolume雖然允許自定義開發驅動來掛載卷到集群Node節點上供Pod使用，但生命周期與pod同步。
PersistentVolumeClaim網絡存儲：具有獨立的生命周期，可以通過存儲的out-tree插件對接不同類型存儲。當前支持的存儲插件類型有FlexVolume與CSI。
引入PV、PVC、StorageClass之后，資源管控更加靈活，團隊職責更加明確，研發人員只需考慮存儲需求(IO、容量、訪問模式等)，不需要關注底層存儲細節;底層復雜的細節都由專業的集群管理與存儲管理員來完成。
CSI是Kubernetes 1.9版本開始引入，建立一套標準的存儲管理接口，通過該接口為容器提供存儲服務。從而實現Kubernetes平臺與存儲服務驅動完全解耦。CSI主要包含CSI Controller Server與CSI Node Server兩個部分,Controller Server主要實現創建、刪除、掛載、卸載等控制功能;Node Server主要實現的是Node節點上的 mount、unmount的操作。
CSI Controller Server和External CSI SideCar是通過 Unix Socket來進行通信的，CSI Node Server和Kubelet也是通過Unix Socket來通信。CSI實現類也日趨完善，比如ExpandCSIVolumes可以實現文件系統擴容;VolumeSnapshotDataSource可以實現數據卷的快照;VolumePVCDataSource實現自定義定PVC數據源;CSIInlineVolume在Volume中定義一些CSI的驅動。阿里云也開源了阿里云盤、NAS、CPFS、OSS、LVM等CSI存儲插件。
1.2.3.Ingress與Service，百花齊放的Kubernetes網絡
Kubernetes 容器網絡非常復雜，涉及的概念也比較多，比如Pod網絡，Service網絡，Cluster IP，NodePort，LoadBalancer和Ingress等，為此將Kubernetes 的網絡參考TCP/IP協議棧抽象為四層：
第0層：Node節點網絡比較簡單，就是保證Kubernetes 節點(物理或虛擬機)之間能夠正常IP尋址和互通的網絡，一般由底層(公有云或數據中心)網絡基礎設施支持。
第1層：Pod是Kubernetes的最小調度單元，Pod網絡就是確保Kubernetes集群中所有Pod(包括同一節點及不同節點上的Pod)，邏輯上在同一個平面網絡內，能夠相互IP尋址和通信的網絡。是容器網絡最復雜部分，通過各種容器網絡插件滿足不同網絡需求，通過CNI標準化及開放網絡自定義能力。
第3層：雖然單個Pod都有IP，但是與Pod生命周期一致，為了解決一組相同Pod統一穩定的訪問地址，并且將請求均衡的分發到后端Pod應用服務中。Kubernetes引入了Service網絡，以此實現服務發現(Service Discovery)和負載均衡(Load Balancing)能力，底層是通過Kube-Proxy+iptables轉發實現，對應用無侵入且不穿透代理，沒有額外性能損耗。
第4層：Kubernetes Service網絡是集群內部網絡，集群外部是無法訪問，需要將內部服務暴露外部才能訪問。Kubernetes通過NodePort，LoadBalancer和Ingress多個方式構建外部網絡接入能力。
|
類型 |
作用 |
實現 |
|
節點網絡 |
Master/Worker節點之間網絡互通 |
路由器，交換機，網卡 |
|
Pod網絡 |
Pod虛擬機之間互通 |
虛擬網卡，虛擬網橋，網卡，路由器or覆蓋網絡 |
|
Service網絡 |
服務發現+負均衡 |
Kube-proxy, Kubelet, Master, Kube-DNS |
|
NodePort |
將Service暴露在節點網絡上 |
Kube-proxy |
|
LoadBalancer |
將Service暴露在公網上+負載均衡 |
公有云 LB + NodePort |
|
Ingress |
反向路由，安全，日志監控 |
Nginx/Envoy/Traefik/Zuul/SpringCloudGateway |
CNI最早是由CoreOS發起的容器網絡規范，是Kubernetes網絡插件的基礎。Container Runtime在創建容器時，先創建好network namespace，再調用CNI插件為network namespace配置網絡，最后啟動容器內進程。CNI插件包括CNI Plugin與IPAM Plugin兩部分：
CNI Plugin：負責配置管理容器網絡，包括兩個基本的接口：
網絡配置: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
清理網絡: DelNetwork(net NetworkConfig, rt RuntimeConf) error
IPAM Plugin：負責容器IP地址分配，實現包括host-local和dhcp。
容器網絡技術也在持續演進發展，社區開源的網絡組件眾多，比如Flannel、Calico、Cilium、OVN等，每個組件都有各自的優點及適應的場景，難以形成大一統的組件及解決方案。
1.2.4.Workload工作負載，Kubernetes應用中心理念
Kubernetes通過工作負載Workload實現應用管理部署與發布，踐行Kubernetes以應用為中心的理念。Kubernetes支持多種類型的工作負載，包含Deployment、StatefulSet、ReplicaSet、Job、CronJob、DaemonSet，以滿足不同場景的需求。
Deployment與ReplicaSet：替換原來的 ReplicationController對象，管理部署無狀態應用，Deployment管理不同版本的ReplicaSet，ReplicaSet管理相同版本的Pod，通過Deployment調整 ReplicaSet的終態副本數，控制器會維持實際運行的Pod數量與期望的數量一致，Pod 出故障時會自動重啟或恢復。
StatefulSet：管理部署有狀態應用，創建的Pod擁有根據規范創建的持久型標識符。Pod遷移或銷毀重啟后，標識符仍會保留。如每個Pod有序號，可以按序號創建更新或刪除;Pod有唯一網絡標志(hostname)或獨享的存儲PV,支持灰度發布等。
DaemonSet：管理部署每個節點運行的守護任務，如監控、日志收集等。新加入的節點也運行，移出節點是需要刪除。也可以通過標簽的指定運行節點。
Job與Cronjob：Job是一次性任務，可創建一個或多個Pod，監控Pod是否成功運行或終止;根據Pod狀態設置重復次數、并發度、重啟策略。Cronjob是定時調度的Job,可以指定運行時間、等待時間、是否并行運行、運行次數限制。
在Kubernetes生態中，還有一些提供額外操作的第三方工作負載。同時也可以通過使用CRD自定義工作負載。還有就是Device Plugin驅動的硬件工作負載，會在后續章節詳細講解。
1.2.5.Controller控制器，Kubernetes集控管理中心
Controller Manager作為Kubernetes集控管理中心，負責集群的Node、Pod副本、服務端點(Endpoint)、命名空間(Namespace)、服務賬號(ServiceAccount)、資源定額(ResourceQuota)的資源管理，并通過API Server接口實時監控集群的每個資源對象的狀態，一旦發生故障導致系統狀態發生變化，就會立即嘗試修復到“期望狀態”。
Replication Controller：保證集群中一個RC所關聯的Pod副本數始終保持預設值。
ResourceQuota Controller：確保Kubernetes中的資源對象在任何時候都不會超量占用系統物理資源。有容器，Pod以及Namespace三個級別。
Namespace Controller：通過API Server定時讀取Namespace信息。如果Namespace被API標記為優雅刪除(即設置刪除期限，DeletionTimestamp),則將該Namespace狀態設置為“Terminating”,并保存到etcd中。同時刪除該Namespace下的ServiceAccount、RC、Pod等資源對象。
Endpoint Controller：Endpoints是Service對應所有Pod副本的訪問地址，Endpoint Controller主要負責監聽Service和對應的Pod副本的變化，從而生成和維護Endpoints對象控制器。
Deployment Controller：Deployment通過控制ReplicaSet，ReplicaSet再控制Pod，最終由Deployment Controller驅動達到期望狀態，Deployment Controller會監聽 DeploymentInformer、ReplicaSetInformer、PodInformer 三種資源。
另外，在Kubernetes v1.6引入了云控制管理器Cloud Controller Manager(CCM)，提供與阿里公有云基礎產品對接的支持，后續也會詳細講解。
1.3.總結
總結一下，Kubernetes不僅是一個強大的容器編排系統本身，而且促進了一個龐大的工具和服務的生態系統，云原生時代的操作系統，形成云計算新界面。
從設計理念方面，Kubernetes是以應用為中心的構理念，向下屏蔽基礎設施差異，實現底層基礎資源統一調度及編排;向上通過容器鏡像標準化應用，實現應用負載自動化部署;中間通過Kubernetes通用的編排能力，開放API以及自定義CRD擴展能力;
從技術架構方面，Kubernetes是典型的分布式主從架構，由Master控制節點與可以水平擴展的Worker工作節點組成，Master實現集中式控制管理，Worker實現分布式運行;與Openstack的架構還有基于SpringCloud研發的分微服業務應用沒有太大區別。
從設計模式方面，Kubernetes通過定義大量的模型(原語、資源對象、配置、常用的 CRD)，通過配置管理模型實現集群資源的控制;雖然模型多切復雜，可以分層(核心層，隔離與服務訪問層，調度層，資源層)逐步理解。
從平臺擴展方面，Kubernetes是一個開放可擴展平臺，不僅有開發的API，開放標準(CNI，CSI，CRI等)以及CRD，不僅是一個單純運行時平臺，同時面向運維的開發平臺。
本文轉載自微信公眾號「巨子嘉」，可以通過以下二維碼關注。轉載本文請聯系巨子嘉公眾號。
