Kubernetes權威指南：從Docker到Kubernetes實踐全接觸（紀念版） 下載 mobi epub pdf 電子書 2025

簡體網頁||繁體網頁

☆☆☆☆☆

閆健勇，龔正，吳治輝，王偉，崔秀龍 ... 著

圖書標籤:

• Kubernetes
• 容器化
• Docker
• DevOps
• 雲原生
• 微服務
• 係統運維
• 技術指南
• 運維實踐
• 架構設計

齣版社： 電子工業齣版社

ISBN：9787121323515

版次：1

商品編碼：12230380

品牌：Broadview

包裝：平裝

開本：16開

齣版時間：2017-09-01

用紙：膠版紙

頁數：692

産品特色

編輯推薦

　　

　　本書是容器圈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人士來說，本書都極具參考價值。
　　吳治輝
　　惠普公司係統架構師

評分☆☆☆☆☆

書本質量很好，還有塑封保護，味道不錯

評分☆☆☆☆☆

很好很好很好 物流很快 價格很便宜

評分☆☆☆☆☆

老公需要的?，活動很劃算，物流很給力，第二天就到瞭

評分☆☆☆☆☆

書的質量很好，物流速度快，包裝不錯。

評分☆☆☆☆☆

學無止境 買來看看 希望get到更多的點

評分☆☆☆☆☆

書介紹得很全麵，就是例子稍微簡單瞭點，需要有一定基礎纔能懂並且實踐

評分☆☆☆☆☆

嗯，應該是非常好的，二本書還沒有看呢，這樣吧，嗬嗬你好陰險哦，嗬嗬嗬嗬嗬！

評分☆☆☆☆☆

不錯不錯，很好很好，不錯不錯，很好很好，不錯不錯，很好很好，不錯不錯，很好很好，不錯不錯，很好很好，

評分☆☆☆☆☆

很好的工具書，不會瞭就來翻翻。哈哈！