前言
我不知道你是如何獲得這本書的，可能是在百度頭條、網路廣告、朋友圈中聽說本書後購買的，也可能是某一天逛書店時，這本書剛好神奇地出現在你面前的書架上，讓你想起一千多年前那個意外獲得《太公兵法》的傳奇少年，你覺得這是冥冥之中上天的恩賜，於是果斷帶走。不管怎樣，我相信多年以後，這本書仍然值得你回憶。
Kubernetes這個名字起源於古希臘，是舵手的意思，所以它的Logo既像一張漁網，又像一個羅盤。Google採用這個名字的一層深意就是：既然Docker把自己定位為馱著集Boxing在大海上自在遨遊的鯨魚，那麼Google就要以Kubernetes掌舵大航海時代的發言權，「捕捉」和「指引」這條鯨魚按照「主人」設定的路線巡遊，確保Google傾力打造的新一代容器世界的宏偉藍圖順利實現。
雖然Kubernetes自誕生至今才1年多，其第一個正式版本Kubernetes
1.0於2015年7月才發佈，完全是個新生事物，但其影響力極大，已經吸引包含IBM、惠普、微軟、紅帽、Intel、VMware、CoreOS、Docker、Mesosphere、Mirantis等許多業界巨頭紛紛加入。紅帽這個軟體虛擬化領域的領導者之一，在容器技術方面已經完全「跟從」Google了，不僅把自家的第三代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打敗Google曾經名噪一時的開放原始碼容器技術lmctfy，並迅速風靡世界。但是，作為一個已經對全球IT公司產生重要影響的技術，Docker背後的容器標準的制定註定不可能被任何一個公司私有控制，於是就有了後來引發危機的CoreOS與Docker分手事件，其導火線是CoreOS撇開Docker，推出與Docker相對抗的開放原始碼容器專案—Rocket，並動員一些知名IT公司成立委員會來試圖主導容器技術的標準化，該分手事件愈演愈烈，最後導致CoreOS、Google一起宣佈「叛逃」Docker陣營，共同發起以CoreOS+Rocket+Kubernetes為基礎的新專案Tectonic。這讓當時的Docker陣營和Docker粉絲們無比擔心Docker的命運，不管最後鹿死誰手，容器技術分裂局勢的加劇對所有牽涉其中的人來說都沒有好處，於是Linux基金會出面調和雙方各退讓一步，最後結果是Linux基金會於2015年6月宣佈成立開放容器技術專案（Open
Container
Project），Google、CoreOS及Docker都加入OCP專案。但透過檢視OCP專案的成員名單，你會發現Docker在這個名單中只能算一個小角色了。OCP的成立最後結束了這場讓無數人揪心的「戰爭」，Docker公司被迫放棄自己的獨家控制權。作為回報，Docker的容器格式被OCP採納為新標準的基礎，並且由Docker負責起草OCP草案標準的初稿文件，當然這個「標準起草者」的角色也不是那麼容易擔當的，Docker要傳送自己的容器執行引擎的原始程式作為OCP專案的啟動資源。
事到如今，我們再來回顧當初CoreOS與Google的叛逃事件，從表面上看，Google似乎是被誘拐「出櫃」的，但局裡人都明白，Google才是這一系列事件背後的主謀，不僅為當年失敗的lmctfy報一箭之仇，還重新掌控容器技術的未來。容器標準之戰大捷之後，Google進一步擴大聯盟並加強本身影響力。2015年7月，Google正式宣佈加入OpenStack陣營，其目標是確保
Linux 容器及連結的容器管理技術Kubernetes能夠被OpenStack生態圈所容納，並且成為OpenStack平台上與KVM虛擬機器一樣的一等公民。Google加入OpenStack表示對資料中心控制平面的爭奪已經結束，以容器為代表的應用形態與以虛擬化為代表的系統形態將完美融合於OpenStack之上，並與軟體定義網路和軟體定義儲存一起統治下一代資料中心。
Google憑藉著幾十年大規模容器使用的豐富經驗，步步為營，先是祭出Kubernetes這個神器，然後又掌控了容器技術的制定標準，最後又入駐OpenStack陣營全力將Kubernetes扶上位，Google這個IT界的領導者和創新者再次王者歸來。我們都明白，在IT世界裡只有那些被大公司掌控和推廣的，同時被業界許多巨頭都認可和支援的新技術才能生存和壯大下來。Kubernetes就是當今IT界裡符合要求且為數不多的熱門技術之一，它的影響力可能長達十年，所以，每個IT人都有理由重視這門新技術。
誰能比別人領先一步掌握新技術，誰就在競爭中贏得先機。惠普中國電信解決方案領域的資深專家團一起分工協作、研究，廢寢忘食地合力撰寫，完成這本近850頁的Kubernetes權威指南。經過幾年的高速發展，Kubernetes先後發佈v1.0～v1.6這6個大版本，每個版本都帶來大量的新特性，能夠處理的應用場景也越來越豐富。本書遵循從入門到精通的學習路線，分為六大章節，涵蓋了入門、實作指南、架構原理、開發指南、進階案例、運行維護指南和原始程式分析等，內容詳實、圖文並茂，幾乎囊括Kubernetes到v1.6版本的各方面，無論是對於軟體工程師、測試工程師、運行維護工程師、軟體架構師、技術經理，還是對於資深IT人士，本書都極具參考價值。
吳治輝
惠普公司系統架構師
