具體描述
産品特色
編輯推薦
本書是容器圈Kubernetes重磅開山作《Kubernetes木又威指南》的紀念版，內容更新到Kubernetes v1.6+版本。
本書作者全部來自惠普公司雲計算實戰一綫，敏銳地捕獲和探索著各種IT前瞻技術，有著全麵而紮實的技術架構體係、對創新技術天生的熱情、國際技術領先者的視野，還有著對企業級IT架構的深入把握。
紀念並不是為瞭結束，而是為瞭新的寫作思路的展開。我們用盡全力更新和修改本書的內容，把能想到的和K8s新的更新都詳細地寫進去瞭，緻使本書厚達700頁，同時，我們深感不能再接著更新下去瞭。還好，本書記錄瞭K8s近的很重要的裏程碑版本，之後的各種版本變化應該都是基於這個版本的小範圍內的更新，本書應該還能陪伴大傢很長一段時間。
奉上寄語：“我輕輕地招手，迎接明天的雲彩……”
內容簡介
Kubernetes 是由榖歌開源的Docker 容器集群管理係統，為容器化的應用提供瞭資源調度、部署運行、服務發現、擴容及縮容等一整套功能。《Kubernetes 木又威指南：從Docker 到Kubernetes 實踐全接觸（紀念版）》從架構師、開發人員和運維人員的角度，闡述瞭Kubernetes 的基本概念、實踐指南、核心原理、開發指導、運維指南及源碼分析等內容，圖文並茂、內容豐富、由淺入深、講解全麵；圍繞著生産環境中可能齣現的問題，給齣瞭大量的典型案例，比如安全配置、網絡方案、共享存儲方案、高可用性方案及Trouble Shooting 技巧等，有很強的實戰指導意義。《Kubernetes木又威指南：從Docker到Kubernetes實踐全接觸（紀念版）》隨著Kubernetes 版本更新不斷完善，目前涵蓋瞭Kubernetes 從v1.0 到v1.6 版本的全部特性，盡力為Kubernetes 用戶提供全方位的指南。
無論是對於軟件工程師、測試工程師、運維工程師、軟件架構師、技術經理，還是對於資深 IT 人士來說，《Kubernetes木又威指南：從Docker到Kubernetes實踐全接觸（紀念版）》都極具參考價值。
作者簡介
龔正，HPE高級顧問
擁有十多年的IT從業經驗，具備豐富的雲計算、大數據分析和大型企業級應用的架構設計和實施經驗，是電信、金融、互聯網等領域的資深專傢。
吳治輝，HPE資深架構師
擁有超過15年的軟件研發經驗，專注於電信軟件和雲計算方麵的軟件研發，擁有豐富的大型項目架構設計經驗，是業界少有的具備很強Coding能力的S級資深架構師，也是《ZeroC Ice木又威指南》《架構解密：從分布式到微服務》的作者。
王偉，HPE資深係統架構師、大數據和雲計算技術專傢
擁有多年IT行業從業經驗，參與過多個大型應用的架構設計、係統開發和實施落地，精通大數據、雲計算及大型係統架構和開發的相關技術，對互聯網和電信行業的熱點技術有著深刻的理解，是雲計算和大數據方麵的技術專傢。
崔秀龍，HPE資深架構師
開源軟件、自動化愛好者，擁有十多年從業經驗，對軟件生命周期的各個環節均有深刻的理解。
閆健勇，HPE高級項目經理、總架構師
擁有超過15年的電信行業係統建設經驗，主導瞭多項電信大型係統的架構設計和管理，對於雲計算和大數據在電信行業中的應用擁有豐富的經驗。
崔曉寜，HPE高級顧問
擁有超過7年的測試谘詢和質量管理經驗，在雲計算、大數據和分布式運算架構下的業務質量控製方麵有非常豐富的項目實踐和心得，並對推動組織架構優化有豐富的經驗。幫助多個超過百人的大型項目建立軟件産品管理規範和體係，並對其運營提供指導。
劉曉紅，HPE高級谘詢顧問
擁有超過10年的電信行業從業經驗，親曆中國移動BSS/OSS領域核心係統的建設發展曆程，具備豐富的谘詢規劃、需求分析、産品設計、項目管理、測試管理經驗，專注於雲計算、大數據等前沿技術的研究。
精彩書評
我相信這是一本到目前為止對從事雲計算領域技術實踐的人來說非常有價值的書籍。本書作者來自雲計算實戰一綫，敏銳地捕獲和探索著各種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主編 郭蕾
目錄
第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。
……
前言/序言
我不知道你是如何獲得這本書的，可能是在百度頭條、網絡廣告、朋友圈中聽說本書後購買的，也可能是某一天逛書店時，這本書恰好神奇地齣現在你麵前的書架上，讓你想起一韆多年前那個意外得到《太公兵法》的傳奇少年，你覺得這是冥冥之中上天的恩賜，於是果斷帶走。不管怎樣，我相信多年以後，這本書仍然值得你迴憶。
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人士來說，本書都極具參考價值。
吳治輝
惠普公司係統架構師
用戶評價
我購買《Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（紀念版）》，主要是因為我一直對雲計算和容器化技術的未來發展感到興奮，而Kubernetes無疑是這個領域的核心。我希望這本書能夠幫助我構建一個堅實的理論基礎，並在此基礎上進行大量的實踐操作。從Docker到Kubernetes的這個學習路徑，讓我覺得這本書的編排非常閤理，能夠循序漸進地提升我的技能。我期待書中能夠深入講解Kubernetes的控製器模式，這對我理解Kubernetes的自動化能力至關重要。例如，Deployment控製器如何確保期望的Pod數量，StatefulSet控製器如何管理有狀態應用，以及ReplicaSet控製器在其中扮演的角色。我還會非常關注書中關於Kubernetes集群的擴展性和彈性設計的部分，包括如何配置Horizontal Pod Autoscaler（HPA）和Cluster Autoscaler，以及如何應對節點故障和資源瓶頸。另外，我希望能在這本書中找到關於Kubernetes生態係統中常用工具的介紹，比如Prometheus和Grafana在監控方麵的應用，EFK（Elasticsearch, Fluentd, Kibana）或Loki在日誌收集和分析方麵的作用，以及Kubernetes Dashboard的使用。這本書的“紀念版”也讓我聯想到，作者可能在其中分享瞭許多個人在Kubernetes實踐中的經驗和教訓，這些寶貴的“坑”和“繞”是我非常渴望學習的。
評分這本書的標題瞬間吸引瞭我——“Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（紀念版）”。我一直對容器化技術，特彆是Kubernetes充滿好奇，但也總覺得它高深莫測，難以入門。看到“從Docker到Kubernetes實踐全接觸”，我心裏就有瞭底，這似乎是一條清晰的學習路徑，能夠一步步地引導我理解和掌握這個強大的編排工具。書名中的“權威指南”和“實踐全接觸”也讓我充滿瞭期待，希望它能提供紮實的技術理論，同時又不乏生動的實戰案例。我尤其看重“紀念版”這個後綴，它暗示著這本書可能經過瞭多年的沉澱和打磨，內容更加成熟和完善，也許還包含瞭一些作者對這個領域發展曆程的思考和總結，這對於一個初學者來說，無疑是極大的吸引力。我設想這本書會詳細地講解Docker的基礎知識，包括鏡像、容器、倉庫等核心概念，並且會深入到Dockerfile的編寫技巧，如何構建高效、安全的鏡像。然後，很自然地，它會引齣Kubernetes，從其架構、核心組件（如etcd、apiserver、controller-manager、scheduler、kubelet、kube-proxy）講起，層層剖析其工作原理。我期望書中會包含大量的代碼示例和圖示，讓抽象的概念變得可視化，易於理解。更重要的是，我希望這本書能提供豐富的實踐場景，例如如何部署Web應用、數據庫，如何進行服務的發現和負載均衡，如何實現自動伸縮和滾動更新，以及如何進行日誌收集和監控。畢竟，理論學習固然重要，但隻有通過親手實踐，纔能真正地將知識內化。
評分對於《Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（紀念版）》，我個人最看重的是其“實踐全接觸”這幾個字，以及“紀念版”所隱含的深度和廣度。在我的職業生涯中，我接觸過很多理論書籍，但很多在實際操作中卻顯得捉襟見肘。因此，我期望這本書能夠提供非常詳細、可操作的指導。我希望它能從Docker的基礎知識，如Dockerfile的最佳實踐、鏡像的優化、多階段構建等方麵開始，幫助我建立對容器化的深刻理解。然後，它應該能夠清晰地闡述Kubernetes的架構，包括其控製平麵組件（apiserver, etcd, controller-manager, scheduler）和工作節點組件（kubelet, kube-proxy, container runtime）的職責。我特彆想看到書中對Kubernetes核心概念的詳細講解，如Pod的生命周期、Deployment的滾動更新策略、StatefulSet的持久化存儲管理、DaemonSet的節點部署等。另外，對於網絡部分，我希望它能解釋清楚CNI插件的工作原理，以及Service和Ingress在流量路由中的作用。當然，一本“實踐全接觸”的書，必須包含豐富的實戰案例，比如如何部署一個簡單的Web應用，如何配置數據庫的持久化，如何實現服務的自動伸縮，以及如何進行集群的監控和日誌收集。這本書的“紀念版”讓我覺得，它可能包含瞭一些對Kubernetes長期演進的看法，或者作者在多年的從業經驗中總結齣的關於Kubernetes的“道”與“術”，這些是我非常期待的內容。
評分拿到這本《Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（紀念版）》，我最先關注的是它的內容組織和深度。我期待它能提供一個從零開始的進階學習模型。首先，對於Docker的部分，我希望它不僅僅停留在Docker的基本命令和概念介紹，而是能深入講解Docker的底層原理，比如cgroups和namespaces是如何工作的，以及如何利用Docker構建更復雜的應用環境。例如，如何進行多階段構建來優化鏡像大小，如何安全地管理Docker秘密信息，以及Docker Compose在本地開發環境中的應用。然後，這本書應當自然地過渡到Kubernetes，而這個過渡應該是順暢且有邏輯的。我希望它能詳細解釋Kubernetes的聲明式API，以及它如何通過控製器模式來實現自動化。對於Kubernetes的核心對象，如Pod、Deployment、Service、Ingress、StatefulSet、DaemonSet等，我期待能夠有詳盡的解析，包括它們的YAML配置、生命周期管理和最佳實踐。書名中的“實踐全接觸”讓我對實操部分寄予厚望，我希望它能覆蓋從最基礎的集群搭建（例如使用kubeadm或minikube）到更高級的主題，如網絡插件（CNI）的選擇和配置、存儲捲的管理（CSI）、RBAC授權、資源配額、命名空間隔離，以及如何實現高可用性和容錯。我還會特彆留意書中關於故障排查和性能優化的部分，因為這些往往是在實際工作中遇到的關鍵挑戰。
評分我拿到《Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（紀念版）》這本書，首先想到的是它是否能真正解答我近期在工作中遇到的一個難題。我們現在在使用Kubernetes管理微服務，但部署和管理的過程有些混亂，尤其是在處理不同環境的配置差異，以及如何高效地進行灰度發布和A/B測試時，我們常常感到力不從心。因此，我非常期待這本書能夠提供一些解決這些實際問題的具體方案和指導。例如，關於配置管理，我希望它能詳細介紹ConfigMap和Secret的使用，以及如何結閤Helm Chart來管理復雜的應用部署。在灰度發布和A/B測試方麵，我期望書中能講解如何利用Kubernetes的原生功能（如Deployment的策略）或者結閤Istio、Linkerd等服務網格來實現這些高級場景。此外，對於容器安全，我希望能有專門的章節來探討如何加固Kubernetes集群，包括Pod安全策略、網絡策略、鏡像安全掃描等。本書的“紀念版”字樣，讓我覺得它可能還包含瞭一些對Kubernetes發展趨勢的預測和行業洞察，這對於我製定長期的技術規劃非常有幫助。我還會關注書中關於CI/CD集成的內容，例如如何將Jenkins、GitLab CI或GitHub Actions與Kubernetes無縫集成，以實現自動化部署和交付。
評分一樣的商品，比平時便宜，值。
評分書肯定是好書，內容決定是頂呱呱的。。但是這紀念版怎麼紙質還沒普通版好。而且書沒有包裝的，直接散在箱子裏，不僅如此，書的膠沒粘好，前半部門總是間隔的凸齣一些頁數，一拿到書，書的側邊就有一塊黑色印記，應該是誰拿不乾淨的手直接翻過。書的左上角和右上角都好像黏過一些髒東西。還好是技術指導書。k8s的迭代很快，估計明年後年這書就過時瞭。如果這是我要收藏的小說我就直接給一星瞭。
評分今天買，明天到，非常方便，再也不用去書店扛貨瞭，謝謝京東騎士。
評分還不錯，還不錯，還不錯，還還不錯，錯，
評分經典書籍，必須收藏
評分開始看瞭，還不錯！！
評分嗯，應該是非常好的，二本書還沒有看呢，這樣吧，嗬嗬你好陰險哦，嗬嗬嗬嗬嗬！
評分書的質量很好，內容有待閱讀，價格實惠，物流很快，給好評
評分很實用的書，給力
相關圖書
![計算機網絡安全（英文版） [Computer Network Security] pdf epub mobi 電子書 下載](https://pic.qciss.net/12233446/5993f4cdNb65633a1.jpg)
![以用戶為中心的係統設計/計算機科學叢書 [Foundations for Designing User-centered Systems] pdf epub mobi 電子書 下載](https://pic.qciss.net/12233855/5a264ea9N3ba65637.jpg)
![SAP ABAP開發技術詳解：語法手冊 [SAP ABAP Detailed Development Technology-programmer Handbook] pdf epub mobi 電子書 下載](https://pic.qciss.net/12233877/5a77d22aN1c16e97e.jpg)
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.cndgn.com All Rights Reserved. 新城书站 版權所有