Kubernetes 是由谷歌開源的Docker 容器集群管理系統，為容器化的應用提供了資源調度、部署運行、服務發現、擴容及縮容等一整套功能。《Kubernetes 指南：從Docker 到Kubernetes 實踐全接觸(紀念版)》從架構師、開發人員和運維人員的角度，闡述了Kubernetes 的基本概念、實踐指南、核心原理、開發指導、運維指南及源碼分析等內容，圖文并茂、內容豐富、由淺入深、講解；圍繞著生產環境中可能出現的問題，給出了大量的典型案例，比如安全配置、網絡方案、共享存儲方案、高可用性方案及Trouble Shooting 技巧等，有很強的實戰指導意義。《Kubernetes指南：從Docker到Kubernetes實踐全接觸(紀念版)》隨著Kubernetes 版本更新不斷完善，目前涵蓋了Kubernetes 從v1.0 到v1.6 版本的全部特性，盡力為Kubernetes 用戶提供多方位的指南。
無論是對于軟件工程師、測試工程師、運維工程師、軟件架構師、技術經理，還是對于博學 IT 人士來說，《Kubernetes指南：從Docker到Kubernetes實踐全接觸(紀念版)》都具有參考價值。
本書是容器圈Kubernetes重磅開山作《Kubernetes指南》的紀念版，內容更新到Kubernetes v1.6 版本。
本書作者全部來自惠普公司云計算實戰一線，敏銳地捕獲和探索著各種IT前瞻技術，有著而扎實的技術架構體系、對創新技術天生的熱情、國際技術經驗豐富者的視野，還有著對企業級IT架構的深入把握。
紀念并不是為了結束，而是為了新的寫作思路的展開。我們用盡全力更新和修改本書的內容，把能想到的和K8s新的更新都詳細地寫進去了，致使本書厚達700頁，同時，我們深感不能再接著更新下去了。還好，本書記錄了K8s近的很重要的里程碑版本，之后的各種版本變化應該都是基于這個版本的小范圍內的更新，本書應該還能陪伴大家很長一段時間。
奉上寄語：“我輕輕地招手，迎接明天的云彩……”
龔正，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
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。
……
我相信這是一本到目前為止對從事云計算領域技術實踐的人來說非常有價值的書籍。本書作者來自云計算實戰一線，敏銳地捕獲和探索著各種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主編 郭蕾
內容詳實，通俗易懂
k8s入門必看
是正版，價格也不錯
不錯正在學習
好評。。。
你想想的薄點，還沒開始看呢。為毛就沒個塑封呢？難道是二手的？
相當棒的一本書，決定突擊一周看完。我好像是第一本，封面都很褶鄒。。。。。
