Kubernetes概述
Kubernetes由google開源，它的開發和設計都深受Google內部久負盛名的系統Borg的影響，而且，它的許多頂級貢獻者之前也是Borg系統的開發者。Borg是Google內部使用的大規模集羣管理系統。
Kubernetes吸取了Borg在過去十數年間積累的經驗和教訓，剛剛面世就立即廣受關注和青睞，目前已經成爲容器編排領域事實上的標準。很多人將Kubernetes視爲Borg系統的一個開源實現版本。
Kubernetes使用共享網絡將多個物理機或虛擬機彙集到一個集羣中，在各服務器之間進行通信，該集羣是配置Kubernetes的所有組件、功能和工作負載的物理平臺。集羣包含Master和Node。 Master Master是集羣的網關和中樞，負責諸如爲用戶和客戶端暴露API、跟蹤其他服務器的健康狀態、以最優方式調度工作負載，以及編排其他組件之間的通信等任務，它是用戶或客戶端與集羣之間的核心聯絡點，並負責Kubernetes系統的大多數集中式管控邏輯。
Node Node是Kubernetes集羣的工作節點，負責接收來自Master的工作指令並根據指令相應地創建或銷燬Pod對象，以及調整網絡規則以合理地路由和轉發流量等。
Kubernetes集羣組件
一個典型的Kubernetes集羣由一個或一組Master和多個Node、一個集羣狀態存儲系統（etcd）和add-ons組成。 Kubernetes的系統架構： 
Master節點主要由apiserver、controller-manager和scheduler三個組件，以及一個用於集羣狀態存儲的etcd存儲服務組成，而每個Node節點則主要包含kubelet、kube-proxy及容器引擎等組件。
Master組件
API Server
API Server負責輸出RESTful風格的KubernetesAPI，它是發往集羣的所有REST操作命令的接入點，並負責接收、校驗並響應所有的REST請求，結果狀態被持久存儲於etcd中。
Controller Manager
Kubernetes中，集羣級別的大多數功能都是由幾個被稱爲控制器的進程執行實現的，這幾個進程被集成於kube-controller-manager守護進程中。由控制器完成的功能主要包括生命週期功能和API業務邏輯.
- 生命週期功能：包括Namespace創建和生命週期、Event垃圾回收、Pod終止相關的垃圾回收、級聯垃圾回收及Node垃圾回收等。
- API業務邏輯：例如，由ReplicaSet執行的Pod擴展等
Scheduler
在API Server確認Pod對象的創建請求之後，Scheduler就會根據集羣內各節點的可用資源狀態，以及要運行的容器的資源需求做出調度決策。
Cluster State Store
etcd被用作Kubernetes集羣狀態的存儲，etcd是獨立的服務組件，並不隸屬於Kubernetes集羣自身。生產環境中應該以etcd集羣的方式運行以確保其服務可用性。
Node組件
kubelet
kubelet是Node的核心代理程序，它是運行於工作節點之上的守護進程，從API Server接收關於Pod對象的配置信息並確保它們處於期望的狀態（desired state）。kubelet會在API Server上註冊當前工作節點，定期向Master彙報節點資源使用情況，並通過cAdvisor監控容器和節點的資源佔用狀況。
容器運行時環境
每個Node都需要容器運行時（ContainerRuntime）環境，才能下載鏡像、啓動容器。kubelet以插件的方式載入配置的容器環境，目前支持Docker、RKT、cri-o和Fraki等容器環境。
kube-proxy
每個Node都需要運行一個kube-proxy守護進程，它能夠按需爲Service資源對象生成iptables或ipvs規則，從而捕獲訪問當前Service的ClusterIP的流量並將其轉發至正確的後端Pod對象。
Addons
Kubernetes集羣還依賴於一系列add-ons以提供完整的功能，它們通常是由第三方提供的特定應用程序，且託管運行於Kubernetes集羣之上，比如
- KubeDNS：在Kubernetes集羣中調度運行提供DNS服務的Pod，同一集羣中的其他Pod可使用此DNS服務解析主機名。
- Kubernetes Dashboard：可以通過Dashboard來管理集羣中的應用甚至是集羣自身。
- Heapster：容器和節點的性能監控與分析系統，其功能會逐漸由Prometheus結合其他組件所取代。
- Ingress Controller：與負載均衡相關。
Kubernetes網絡模型基礎
雲計算的核心是虛擬化技術，網絡虛擬化技術又是其最重要的組成部分，用於在物理網絡上虛擬多個相互隔離的虛擬網絡，實現網絡資源切片，提高網絡資源利用率，實現彈性化網絡。
爲了提供更靈活的解決方式，Kubernetes的網絡模型需要藉助於外部插件實現，它要求任何實現機制都必須滿足以下需求：
- 所有Pod間均可不經NAT（網絡地址轉換）機制而直接通信
- 所有節點均可不經NAT機制而直接與所有容器通信
- 容器自己使用的IP也是其他容器或節點直接看到的地址，所有Pod對象都位於同一平面網絡中，而且可以使用Pod自身的地址直接通信。
Kubernetes集羣包含三種網絡：
- 各主機（Master、Node和etcd等）自身所屬的網絡，用於各主機之間的通信，其地址配置於主機的網絡接口，且在Kubernetes集羣構建之前就已配置好，它並不能由Kubernetes管理。
- 專用於Pod資源對象的網絡，它是一個虛擬網絡，用於爲各Pod對象設定IP地址等網絡參數，其地址配置於Pod中容器的網絡接口之上。Pod網絡需要藉助kubenet插件或CNI插件實現，插件可獨立部署於Kubernetes集羣之外，也可託管於Kubernetes之上，在創建Pod對象時由其自動完成各網絡參數（Pod IP）的動態配置。
- 專用於Service資源對象的網絡，也是虛擬網絡，用於爲Kubernetes集羣之中的Service配置IP地址，但此地址並不配置於任何主機或容器的網絡接口之上，而是通過Node之上的kube-proxy配置爲iptables或ipvs規則，從而將發往此地址的所有流量調度至其後端的各Pod對象之上。Service網絡在Kubernetes集羣創建時予以指定，而各Service的地址（Cluster IP）則在用戶創建Service時予以動態配置。
綜上，Kubernetes爲Pod和Service資源對象分別使用了各自的專用網絡，Pod網絡由Kubernetes的網絡插件配置實現，而Service的網絡則由Kubernetes集羣予以指定。
學習資料
《Kubernetes實戰進階》 馬永亮著