龔正，HPE高級顧問，擁有十多年的IT從業經驗，具備豐富的雲計算、大數據分析和大型企業級應用的架構設計和實施經驗，是電信、金融、互聯網等領域的資深專家。

吳治輝，HPE資深架構師，擁有超過15年的軟件研發經驗，專注於電信軟件和雲計算方面的軟件研發，擁有豐富的大型項目架構設計經驗，是業界少有的具備很強Coding能力的S級資深架構師，也是《ZeroC Ice木權指南》《架構解密：從分布式到微服務》的作者。

王偉，HPE資深繫統架構師、大數據和雲計算技術專家，擁有多年IT行業從業經驗，參與過多個大型應用的架構設計、繫統開發和實施落地，精通大數據、雲計算及大型繫統架構和開發的相關技術，對互聯網和電信行業的熱點技術有著深刻的理解，是雲計算和大數據方面的技術專家。

崔秀龍，HPE資深架構師，開源軟件、自動化愛好者，擁有十多年從業經驗，對軟件生命周期的各個環節均有深刻的理解。

闫健勇，HPE高級項目經理、總架構師，擁有超過15年的電信行業繫統建設經驗，主導了多項電信大型繫統的架構設計和管理，對於雲計算和大數據在電信行業中的應用擁有豐富的經驗。

崔曉寧，HPE高級顧問，擁有超過7年的測試咨詢和質量管理經驗，在雲計算、大數據和分布式運算架構下的業務質量控制方面有非常豐富的項目實踐和心得，並對推動組織架構優化有豐富的經驗。幫助多個超過百人的大型項目建立軟件產品管理規範和體繫，並對其運營提供指導。

劉曉紅，HPE高級咨詢顧問，擁有超過10年的電信行業從業經驗，親歷中國移動BSS/OSS領域核心繫統的建設發展歷程，具備豐富的咨詢規劃、需求分析、產品設計、項目管理、測試管理經驗，專注於雲計算、大數據等前沿技術的研究。

第1章 Kubernetes入門 1
1.1 Kubernetes是什麼 1
1.2 為什麼要用Kubernetes 4
1.3 從一個簡單的例子開始 5
1.3.1 環境準備 6
1.3.2 啟動MySQL服務 6
1.3.3 啟動Tomcat應用 9
1.3.4 通過瀏覽器訪問網頁 10
1.4 Kubernetes基本概念和術語 12
1.4.1 Master 12
1.4.2 Node 12
1.4.3 Pod 15
1.4.4 Label（標簽） 18
1.4.5 Replication Controller 22
1.4.6 Deployment 26
1.4.7 Horizontal Pod Autoscaler 28
1.4.8 StatefulSet 29
1.4.9 Service（服務） 30
1.4.10 Volume（存儲卷） 37
1.4.11 Persistent Volume 41
1.4.12 Namespace（命名空間） 42
1.4.13 Annotation（注解） 43
1.4.14 小結 44
第2章 Kubernetes實踐指南 45
2.1 Kubernetes安裝與配置 45
2.1.1 繫統要求 45
2.1.2 使用kubeadm工具快速安裝Kubernetes集群 46
2.1.3 以二進制文件方式安裝Kubernetes集群 51
2.1.4 Kubernetes集群的安全設置 59
2.1.5 Kubernetes集群的網絡配置 64
2.1.6 內網中的Kubernetes相關配置 64
2.1.7 Kubernetes的版本升級 65
2.1.8 Kubernetes核心服務配置詳解 66
2.2 kubectl命令行工具用法詳解 86
2.2.1 kubectl用法概述 86
2.2.2 kubectl子命令詳解 88
2.2.3 kubectl參數列表 90
2.2.4 kubectl輸出格式 90
2.2.5 kubectl操作示例 92
2.3 深入掌握Pod 93
2.3.1 Pod定義詳解 93
2.3.2 Pod的基本用法 98
2.3.3 靜態Pod 103
2.3.4 Pod容器共享Volume 104
2.3.5 Pod的配置管理 106
2.3.6 在容器內獲取Pod信息（Downward API） 119
2.3.7 Pod生命周期和重啟策略 124
2.3.8 Pod健康檢查 125
2.3.9 玩轉Pod調度 127
2.3.10 Init Container（初始化容器） 149
2.3.11 Pod的升級和回滾 152
2.3.12 Pod的擴容和縮容 166
2.3.13 使用StatefulSet搭建MongoDB集群 171
2.4 深入掌握Service 180
2.4.1 Service定義詳解 181
2.4.2 Service基本用法 182
2.4.3 Headless Service 187
2.4.4 集群外部訪問Pod或Service 192
2.4.5 DNS服務搭建指南 196
2.4.6 自定義DNS和上遊DNS服務器 204
2.4.7 Ingress：HTTP 7層路由機制 208
第3章 Kubernetes核心原理 226
3.1 Kubernetes API Server 原理分析 226
3.1.1 Kubernetes API Server概述 226
3.1.2 獨特的Kubernetes Proxy API接口 229
3.1.3 集群功能模塊之間的通信 230
3.2 Controller Manager 原理分析 231
3.2.1 Replication Controller 232
3.2.2 Node Controller 234
3.2.3 ResourceQuota Controller 235
3.2.4 Namespace Controller 237
3.2.5 Service Controller與Endpoint Controller 237
3.3 Scheduler原理分析 238
3.4 kubelet運行機制分析 242
3.4.1 節點管理 242
3.4.2 Pod管理 243
3.4.3 容器健康檢查 244
3.4.4 cAdvisor資源監控 245
3.5 kube-proxy 運行機制分析 247
3.6 深入分析集群安全機制 251
3.6.1 API Server認證管理（Authentication） 251
3.6.2 API Server授權管理（Authorization） 253
3.6.3 Admission Control（準入控制） 272
3.6.4 Service Account 274
3.6.5 Secret私密憑據 279
3.7 網絡原理 282
3.7.1 Kubernetes網絡模型 282
3.7.2 Docker的網絡基礎 284
3.7.3 Docker的網絡實現 296
3.7.4 Kubernetes的網絡實現 304
3.7.5 Pod和Service網絡實戰 308
3.7.6 CNI網絡模型 321
3.7.7 Kubernetes網絡策略 331
3.7.8 開源的網絡組件 333

3.8 共享存儲原理 363
3.8.1 共享存儲機制概述 363
3.8.2 PV詳解 364
3.8.3 PVC詳解 368
3.8.4 PV和PVC的生命周期 370
3.8.5 StorageClass詳解 373
3.8.6 動態存儲管理實戰：GlusterFS 376
第4章 Kubernetes開發指南 388
4.1 REST簡述 388
4.2 Kubernetes API詳解 390
4.2.1 Kubernetes API概述 390
4.2.2 API版本 395
4.2.3 API Groups（API組） 395
4.2.4 API方法說明 397
4.2.5 API響應說明 398
4.3 使用Java程序訪問Kubernetes API 400
4.3.1 Jersey 401
4.3.2 Fabric8 412
4.3.3 使用說明 413
第5章 Kubernetes運維指南 434
5.1 Kubernetes集群管理指南 434
5.1.1 Node的管理 434
5.1.2 更新資源對像的Label 436
5.1.3 Namespace：集群環境共享與隔離 437
5.1.4 Kubernetes資源管理 441
5.1.5 資源緊缺時的Pod驅逐機制 475
5.1.6 Pod Disruption Budget（主動驅逐保護） 483
5.1.7 Kubernetes集群的高可用部署方案 485
5.1.8 Kubernetes集群監控 496
5.1.9 集群統一日志管理 513
5.1.10 Kubernetes審計日志（Audit Log） 522
5.1.11 使用Web UI（Dashboard）管理集群 523
5.1.12 Helm：Kubernetes應用包管理工具 527
5.2 Trouble Shooting指導 538
5.2.1 查看繫統Event事件 538
5.2.2 查看容器日志 540
5.2.3 查看Kubernetes服務日志 541
5.2.4 常見問題 542
5.2.5 尋求幫助 546
5.3 Kubernetes開發中的新功能 546
5.3.1 Pod Preset（運行時參數注入策略） 546
5.3.2 Cluster Federation（集群聯邦） 553
5.3.3 容器運行時接口（Container Runtime Interface-CRI） 557
5.3.4 對GPU的支持 561
5.3.5 Kubernetes的演進路線（Roadmap）和開發模式 565
第6章 Kubernetes源碼導讀 568
6.1 Kubernetes源碼結構和編譯步驟 568
6.2 kube-apiserver進程源碼分析 572
6.2.1 進程啟動過程 572
6.2.2 關鍵代碼分析 574
6.2.3 設計總結 589
6.3 kube-controller-manager進程源碼分析 592
6.3.1 進程啟動過程 592
6.3.2 關鍵代碼分析 595
6.3.3 設計總結 603
6.4 kube-scheduler進程源碼分析 605
6.4.1 進程啟動過程 605
6.4.2 關鍵代碼分析 610
6.4.3 設計總結 617
6.5 kubelet進程源碼分析 619
6.5.1 進程啟動過程 619
6.5.2 關鍵代碼分析 624
6.5.3 設計總結 647
6.6 kube-proxy進程源碼分析 648
6.6.1 進程啟動過程 648
6.6.2 關鍵代碼分析 650
6.6.3 設計總結 665
6.7 kubectl進程源碼分析 666
6.7.1 kubectl create命令 667
6.7.2 rolling-update命令 671

      我不知道你是如何獲得這本書的，可能是在百度頭條、網絡廣告、朋友圈中聽說本書後購買的，也可能是某一天逛書店時，這本書恰好神奇地出現在你面前的書架上，讓你想起一千多年前那個意外得到《太公兵法》的傳奇少年，你覺得這是冥冥之中上天的恩賜，於是果斷帶走。不管怎樣，我相信多年以後，這本書仍然值得你回憶。
Kubernetes這個名字起源於古希臘，是舵手的意思，所以它的Logo既像一張漁網，又像一個羅盤。谷歌采用這個名字的一層深意就是：既然Docker把自己定位為馱著集裝箱在大海上自在遨遊的鯨魚，那麼谷歌就要以Kubernetes掌舵大航海時代的話語木又，“捕獲”和“指引”這條鯨魚按照“主人”設定的路線巡遊，確保谷歌傾力打造的新一代容器世界的宏偉藍圖順利實現。
雖然Kubernetes自誕生至今纔1年多，其個正式版本Kubernetes 1.0於2015年7月纔發布，完全是個新生事物，但其影響力巨大，已經吸引了包括IBM、惠普、微軟、紅帽、Intel、VMware、CoreOS、Docker、Mesosphere、Mirantis等在內的眾多業界巨頭紛紛加入。紅帽這個軟件虛擬化領域的領導者之一，在容器技術方面已經完全“跟從”谷歌了，不僅把自家的第三代OpenShift產品的架構底層換成了Docker Kubernetes，還直接在其新一代容器操作繫統Atomic內原生集成了Kubernetes。
Kubernetes是個將“一切以服務（Service）為中心，一切圍繞服務運轉”作為指導思想的創新型產品，它的功能和架構設計自始至終地遵循了這一指導思想，構建在Kubernetes上的繫統不僅可以獨立運行在物理機、虛擬機集群或者企業私有雲上，也可以被托管在公有雲中。Kubernetes方案的另一個亮點是自動化，在Kubernetes的解決方案中，一個服務可以自我擴展、自我診斷，並且容易升級，在收到服務擴容的請求後，Kubernetes會觸發調度流程，終在選定的目標節點上啟動相應數量的服務實例副本，這些副本在啟動成功後會自動加入負載均衡器中並生效，整個過程無須額外的人工操作。另外，Kubernetes會定時巡查每個服務的所有實例的可用性，確保服務實例的數量始終保持為預期的數量，當它發現某個實例不可用時，會自動重啟該實例或者在其他節點重新調度、運行一個新實例，這樣，一個復雜的過程無須人工干預即可全部自動化完成。試想一下，如果一個包括幾十個節點且運行著幾萬個容器的復雜繫統，其負載均衡、故障檢測和故障修復等都需要人工介入進行處理，那將是多麼的難以想像。
通常我們會把Kubernetes看作Docker的上層架構，就好像Java與J2EE的關繫一樣：J2EE是以Java為基礎的企業級軟件架構，而Kubernetes則以Docker為基礎打造了一個雲計算時代的全新分布式繫統架構。但Kubernetes與Docker之間還存在著更為復雜的關繫，從表面上看，似乎Kubernetes離不開Docker，但實際上在Kubernetes的架構裡，Docker隻是其目前支持的兩種底層容器技術之一，另一個容器技術則是Rocket，後者來源於CoreOS這個Docker昔日的“戀人”所推出的競爭產品。
Kubernetes同時支持這兩種互相競爭的容器技術，這是有深刻的歷史原因的。快速發展的Docker打敗了谷歌曾經名噪一時的開源容器技術lmctfy，並迅速風靡世界。但是，作為一個已經對全球IT公司產生重要影響的技術，Docker背後的容器標準的制定注定不可能被任何一個公司私有控制，於是就有了後來引發危機的CoreOS與Docker分手事件，其導火索是CoreOS撇開了Docker，推出了與Docker相對抗的開源容器項目—Rocket，並動員一些知名IT公司成立委員會來試圖主導容器技術的標準化，該分手事件愈演愈烈，終導致CoreOS“傍上”谷歌一起宣布“叛逃”Docker陣營，共同發起了基於CoreOS Rocket Kubernetes的新項目Tectonic。這讓當時的Docker陣營和Docker粉絲們無比擔心Docker的命運，不管終鹿死誰手，容器技術分裂態勢的加劇對所有牽涉其中的人來說都沒有好處，於是Linux基金會出面調和矛盾，雙方都退讓一步，終的結果是Linux基金會於2015年6月宣布成立開放容器技術項目（Open Container Project），谷歌、CoreOS及Docker都加入了OCP項目。但通過查看OCP項目的成員名單，你會發現Docker在這個名單中隻能算一個小角色了。OCP的成立終結束了這場讓無數人揪心的“戰爭”，Docker公司被迫放棄了自己的獨家控制木又。作為回報，Docker的容器格式被OCP采納為新標準的基礎，並且由Docker負責起草OCP草案規範的初稿文檔，當然這個“標準起草者”的角色也不是那麼容易擔當的，Docker要提交自己的容器執行引擎的源碼作為OCP項目的啟動資源。
事到如今，我們再來回顧當初CoreOS與谷歌的叛逃事件，從表面上看，谷歌貌似是被誘拐“出櫃”的，但局裡人都明白，谷歌纔是這一繫列事件背後的主謀，其不僅為當年失敗的lmctfy報了一箭之仇，還重新掌控了容器技術的未來。容器標準之戰大捷之後，谷歌進一步擴大了聯盟並提高了自身影響力。2015年7月，谷歌正式宣布加入OpenStack陣營，其目標是確保 Linux 容器及關聯的容器管理技術Kubernetes能夠被OpenStack生態圈所容納，並且成為OpenStack平臺上與KVM虛擬機一樣的一等公民。谷歌加入OpenStack意味著對數據中心控制平面的爭奪已經結束，以容器為代表的應用形態與以虛擬化為代表的繫統形態將會完美融合於OpenStack之上，並與軟件定義網絡和軟件定義存儲一起統治下一代數據中心。
谷歌憑借著幾十年大規模容器使用的豐富經驗，步步為營，先是祭出Kubernetes這個神器，然後又掌控了容器技術的制定標準，後又入駐OpenStack陣營全力將Kubernetes扶上位，谷歌這個IT界的領導者和創新者再次王者歸來。我們都明白，在IT世界裡隻有那些被大公司掌控和推廣的，同時被業界眾多巨頭都認可和支持的新技術纔能生存和壯大下去。Kubernetes就是當今IT界裡符合要求且為數不多的熱門技術之一，它的影響力可能長達十年，所以，我們每個IT人都有理由重視這門新技術。
誰能比別人領先一步掌握新技術，誰就在競爭中贏得了先機。惠普中國電信解決方案領域的資深專家團一起分工協作，並行研究，廢寢忘食地合力撰寫，完成了這部近700頁的Kubernetes木又威指南。經過兩年的高速發展，Kubernetes先後發布了v1.0～v1.6這6個大版本，每個版本都帶來了大量的新特性，能夠處理的應用場景也越來越豐富。本書遵循從入門到精通的學習路線，全書共分為六大章節，涵蓋了入門、實踐指南、架構原理、開發指南、高級案例、運維指南和源碼分析等內容，內容詳實、圖文並茂，幾乎囊括了Kubernetes到v1.6版本的方方面面，無論是對於軟件工程師、測試工程師、運維工程師、軟件架構師、技術經理，還是對於資深IT人士來說，本書都極具參考價值。
吳治輝
惠普公司繫統架構師

      我相信這是一本到目前為止對從事雲計算領域技術實踐的人來說非常有價值的書籍。本書作者來自雲計算實戰一線，敏銳地捕獲和探索著各種IT前瞻技術，他們在惠普如日中天的時期加入惠普，是純粹的技術癖，為*的企業構建著相當龐大的信息繫統。他們有著全面而扎實的技術架構體繫，有著對創新技術天生的熱情，有著國際技術領先者的視野，還有著對企業級IT架構的深入把握。
本書囊括了Kubernetes入門、運行機制、原理和高級案例等內容，由淺入深地介紹了當前發展速度極快且被認可度極高的Kubernetes容器雲平臺，並圍繞著生產環境中可能出現的問題，給出了大量的典型案例，有很好的可借鋻性。
不論你是程序員、架構師，還是咨詢顧問、IT管理者，你都會通過本書接觸到非常熱門的Docker和Kubernetes技術的非常清晰、細膩的實踐脈絡，感受到雲計算技術領域的清新氣息。
——HPE CMS負責人  張紅忠

Kubernetes是2014年開源的容器應用管理調度繫統，深受谷歌使用多年的Borg繫統的影響，吸收了Borg中的理念，簡化了操作。Kubernetes自問世以來，就引起了人們的廣泛關注，已然成為私有雲市場上冉冉升起的明星。本書作者擁有豐富的Kubernetes實戰經驗，並且及時抓住了市場的需求，對Kubernetes這個復雜的繫統進行了精闢的分析和解剖，為渴望理解、迅速上手Kubernetes的程序員同學提供了全方位的指南，也為資深架構師拓寬思路提供了源泉。願在此書的幫助下，Kubernetes的社區能更健康地成長。
——*集團副總裁  翁志

本書內容詳實、深入淺出，向讀者展示了Kubernetes的完整畫像，堪稱一部“從入門到精通”的經典教材。作為過去幾年裡推進Docker與Kubernetes大規模生產應用的技術實踐者，我向每一名雲計算或基礎架構從業者推薦本書。
——*商城總架構師 & 基礎平臺部負責人  劉海鋒

Kubernetes是容器生態圈中的重要一員，發展速度非常快，現在已經擁有800多名代碼貢獻者。谷歌在容器編排調度方面有著非常豐富的經驗，所以Kubernetes的架構設計和理念都很不錯。現在，國內已經有很多公司在應用Kubernetes，InfoQ也在這方面發表和策劃了很多文章。這是國內專門講解Kubernetes的重磅開山之作，從架構到源代碼、從原理到案例，內容全面而詳盡，非常不錯。
——InfoQ主編  郭蕾
  

      5.3.2  Cluster Federation（集群聯邦）
集群聯邦從Kubernetes v1.3版本開始引入，目標是對多個Kubernetes集群進行統一管理，將用戶的應用部署到全球各地的不同數據中心或者雲環境中，同時通過動態優化部署來節約運營成本。本節介紹Kubernetes中Federation（集群聯邦）的主要特性和使用Federation管理多集群的原理。
1. Federation的主要特性
Federation主要通過以下特性來實現多集群的統一管理。
◎ 跨群集資源同步：Federation提供在多個集群之間保持資源同步的能力，比如通過Federation可以確保跨集群的Deployment在多個集群中始終同時存在並保持一致。
◎ 跨集群服務發現：Federation提供了自動配置DNS服務器和全局負載均衡器（可訪問所有Kubernetes集群後端服務的負載均衡器）的能力，比如通過Federation可以確保使用一條全局虛擬IP（VIP）或DNS記錄即可訪問部署在多個Kubernetes集群中的後端服務。
◎ 高可用性：Kubernetes Federation可以在集群之間分發負載，並且支持自動配置DNS服務器和全局負載均衡器，大大降低了發生繫統故障的幾率，提高了繫統的可用性。
◎ 避免廠商鎖定：Federation使得應用進行跨不同類型的雲平臺聯合部署變得很容易，而集群中應用程序的遷移也變得更加輕松，因此可以有效地避免出現廠商鎖定的情況。
2. Federation要解決的主要挑戰
在Federation的實際使用場景中，會面對一些非常重要的挑戰。
1）位置親和性
在使用多集群部署分布式應用時，前端應用與後端資源（可以Pod形式的應用、存儲或者其他為前端應用提供服務的資源）的相對位置對於訪問延遲、資源開銷和繫統穩定性具有決定性的影響。那麼Federation中應該如何考慮這種位置親和決策呢？在Federation的設計理念中，針對前後端的相對位置，將前後端關繫分為三類：嚴格耦合、嚴格解耦和優先耦合。三者分別對應前後端必須綁定、可以完全分離及優先綁定這三種應用場景。通過位置親和性，就可以將嚴格解耦的應用進行基於Pod的平均分配或者隨機分配，對優先耦合的應用進行優先分配到同一集群並接受部分移動，而對於嚴格耦合的應用則嚴格分配到同一集群環境中。
2）跨集群服務發現
在Federation中Pod使用外部DNS客戶端來實現與單集群類似的標準服務發現。DNS將服務解析為本地集群地址或者外部集群地址。除嚴格耦合的前後端場景外，前端都可以不用關心DNS解析的結果是位於同一集群內還是同一集群外。
3）跨集群應用調度
Federation的跨集群調度機制中，Federation控制平面在接收到所有集群的資源對像創建請求後，可以簡單地將這個請求重定向給某個集群，也可以將請求“分解”為多個子請求發送給不同的集群。同時，Federation控制平面需要分析應用的屬性（位置親和性、隱私級別等），並以此作為依據執行更優化的跨集群調度。此外，完善的跨集群調度機制還需要支持準入控制機制、自動擴容和縮容機制、故障重調度機制及基於計算能力的調度優化等。
4）跨集群應用遷移
在Federation的使用過程中，可能會遇到部分集群容量將滿、轉換雲供應商、變換核心集群位置等需要進行應用遷移的場景。在這種情況下，Federation的跨集群遷移工作是按照應用位置親和性來分別進行的：對嚴格解耦的應用采取一次或多次分步遷移的方式進行，每次遷移的粒度也很自由；對優先耦合的應用，需要首先找到具有足夠多的資源容量可以容納待遷移應用的目標集群，並鎖定該部分的資源容量，之後按照特定的順序在特定的時間內完成遷移工作；而對於嚴格耦合的程序而言，除了需要符合與優先耦合類似的資源要求，在遷移過程中還需要考慮是否能滿足數據一致性和應用一致性的要求，如果不能滿足要求，則不建議直接進行遷移。
5）故障隔離
Federation保留了Kubernetes集群的應用隔離機制，一般情況下並不會顯著地增加多個集群之間故障的關聯性。Federation控制平面與每個Kubernetes集群的控制平面是嚴格獨立的，Federation控制平面的故障應不影響每個Kubernetes自身的正常運行。
◎ 統一監控、統一預警和跨集群聯合審計。
◎ 統一認證授木又、跨集群的配額管理。
3. Federation的架構設計
針對這些調整，Federation的整體架構設計采用了解耦和分層的思路：Federation控制平面位於所有Kubernetes集群之上，而每個Kubernetes集群都是可以獨立運行的。除了部分基礎配置信息，每個Kubernetes集群都不知道其他Kubernetes集群的存在，也不知道Federation控制平面的存在。在這種設計中，Federation控制平面就像每個Kubernetes集群的API客戶端，因此與每個集群解除了耦合關繫。與Federation解耦和分層的架構相對的是一體式架構設計：即為每個Kubernetes集群搭建一個控制平面，這個控制平面隻負責管理這個Kubernetes集群，而多個控制平面之間通過通信的方式來實現對所有Kubernetes集群的聯合管理。
Federation分層解耦的設計具有如下優勢。
1）故障隔離性好
如前面所述，Federation分層解耦的設計保證了Federation控制平面與集群的隔離，每個集群和Federation控制平面都可以獨立運行，出現故障時可以進行單獨隔離而互不影響。另外，每個集群和Federation控制平臺的軟件和配置都可以進行獨立更新，這為繫統的維護提供了極大的便利。
2）失效幾率更低
整體而言，分層設計的繫統比一體式設計的繫統出現故障的概率要高（概率疊加），但由於各繫統解除了耦合，所以繫統完全失效的幾率要低於一體式設計的繫統。
3）可擴展性高
在Federation的分層解耦設計中，每個底層的Kubernetes集群內部都可以完全獨立地進行擴展，而Federation中也可以很容易擴展加入新的集群而不影響現有集群。基於分層架構的優勢，在未來的Kubernetes版本裡，甚至可能會提供集群聯邦的聯邦功能（Federation of Federation）。
4）代碼模塊化和分離
Federation控制平面的代碼與每個雲供應商的Kubernetes控制平面的代碼是分離的，它們之間通過共享庫的方式來實現部分代碼共享。這種設計允許Kubernetes和Federation的代碼開發工作在很大程度上獨立進行，同時促進了更好的代碼模塊化和獨立的接口設計。
5）更靈活的管理策略
一體式設計的繫統看似管理工作更簡單，但是由於不同的雲供應商和本地數據中心有不同的特點（硬件、定價、限制等），而Federation的分層解耦架構允許獨立地管理每個Kubernetes集群，這雖然看似提高了管理的復雜性，但是對於整個繫統而言，提供了更豐富的控制手段和管理策略。
◎ 更好的代碼模塊化和界面設計。
◎ 控制平面的成本更低。
在一體式設計的繫統中，每個Kubernetes集群均需要部署自己的控制平面，而在分層解耦的設計中，Federation的控制平面隻需要獨立部署一次。如果我們需要實現控制平面的高可用，那麼也隻需要再部署一個Federation控制平面。可見Federation的分層設計在控制平面的成本開銷上的優勢非常明顯。
4. Federation的優勢
Federation是Kubernetes多集群的解決方案，如果不需要使用多個Kubernetes集群，則Federation並沒有太大用處。在下列情況下，可以考慮引入Federation。
◎ 低延遲：通過多地區部署服務，配合就近選擇集群提供服務的方式，Federation可以小化服務訪問的延遲。
◎ 故障隔離：當繫統發生故障時，由多個小型集群（這些集群通常分布在不同的區域）組成的Federation比單個大型集群更適合快速有效地隔離，而且對整體服務的影響會更小。
◎ 可擴展性：根據谷歌的經驗，在超大規模的生產環境中，單個Kubernetes集群的擴展性受到集群規模的制約。當單個集群規模過大時，集群性能下降。而多集群Federation則可以提高集群規模的上限，提供更好的可擴展性。
◎ 混合雲：Federation支持私有雲和公有雲的組合，可以使用Federation在不同的雲供應商或多個本地數據中心上搭建多個Kubernetes集群，實現混合雲部署。
5. Federation的局限性
除了上述優勢，在使用Federation之前也應充分考慮一些潛在問題。
◎ 網絡帶寬和成本的增加：為確保所有的集群運行狀態符合預期，Federation控制平面會持續監控所有集群。如果Federation中的集群運行在同一個雲供應商的不同地區上（一般同一雲供應商跨地區的網絡通信是需要收費的）或者運行在不同的雲供應商上，那麼將會導致顯著的網絡開銷和成本的提升。
◎ 削弱了多集群之間的隔離性：Federation控制平面一旦出現問題，就可能會影響到所有的集群。一種可能的方案是，通過盡可能減少Federation控制平面中的邏輯，將Federation控制平面的邏輯盡可能多地傳遞給各Kubernetes子集群的控制平面，來減緩這種情況。但這類問題很難完全避免。同樣，目前Federation這種“中心控制”的設計思路和實現方式還可能導致安全性及多集群同時不可用方面的問題。
◎ 成熟度：相對而言，Federation出現較晚，還不是很成熟。目前Kubernetes中的資源對像隻有一部分在Federation中是可用的，而且很多可用的資源對像目前還隻是Alpha狀態。此外，Federation的設計、實現和用法目前隨著Kubernetes大版本的變更都發生了很多改變，因此給使用者帶來了不少困難。
5.3.3  容器運行時接口（Container Runtime Interface-CRI）
歸根結底，Kubernetes Node（kubelet）的主要功能就是啟動和停止容器的組件，我們稱之為容器運行時（Container Runtime），其中知名的就是Docker了。為了讓Kubernetes更具擴展性，從其v1.5版本開始加入了容器運行時插件API，我們稱之為Container Runtime Interface，簡稱CRI。
1. CRI概述
每種容器運行時都有其特點，因此不少用戶希望Kubernetes能夠支持更多的運行時。Kubernetes從v1.5版本開始引入了CRI接口規範，通過插件接口模式，讓Kubernetes無須重新編譯就可以使用更多的容器運行時。CRI包含Protocol Buffers、gRPC API、運行庫支持及開發中的標準規範和工具。Docker-CRI的實現在Kubernetes v1.6版本時更新為Beta版本，並在kubelet啟動時默認啟動。
可替代的容器運行時支持是Kubernetes中的新概念。在Kubernetes v1.3發布時，rktnetes項目同時發布，讓rkt容器引擎成為除Docker外的又一選擇。然而，不管是Docker還是rkt，都用到了kubelet的內部接口，同kubelet源碼糾纏不清。這種程度的集成需要對kubelet的內部機制有非常深入的了解，還會給社區帶來管理壓力，這就給新生代容器運行時造成了難於跨越的集成壁壘。CRI接口規範試圖用定義清晰的抽像層清除這一壁壘，讓開發者能夠專注於容器運行時本身。在通向插件式容器支持及建設健康生態環境的路上，這是一小步，也是重要的一步。
2. CRI的主要組件
kubelet使用gRPC框架利用UNIX Socket與容器運行時（或CRI代理）進行通信。在這個過程中kubelet是客戶端，CRI代理（shim）是服務端。
Protocol Buffers API包含兩個gRPC服務：ImageService和RuntimeService。
ImageService提供了從倉庫拉取鏡像、查看和移除鏡像的功能。
RuntimeService負責Pod和容器的生命周期管理、與容器的交互（exec/attach/port-forward）。rkt和Docker這樣的容器運行時可以使用一個Socket同時提供兩個服務。在kubelet中可以用--container-runtime-endpoint和--image-service-endpoint參數設置這個Socket。
……