1.2 Kubernetes的誕生

讓我們從故事的開頭講起……

Amazon Web服務（Amazon Web Services, AWS）通過其現代云計算產品改變了世界。自那時起，大家都在嘗試追趕AWS的步伐。

其中一個公司就是Google。Google內部也有非常出色的云技術，并且希望通過某種方式吸取AWS的經驗，使其潛在用戶能夠更加容易地使用Google云。

Google在將容器用于擴縮容方面有豐富的管理經驗。例如，類似搜索和郵箱這種大型的Google應用，已經在極大規模的容器云上運行多年了——遠早于Docker這種易于使用的容器產品。為了編排和管理這些容器化的應用，Google內部有一套專門的系統。他們利用來自這些內部系統的經驗，創建了一套新的平臺，名為Kubernetes，并將其作為開源項目于2014年捐贈給了當時剛剛成立的云原生計算基金會（Cloud Native Computing Foundation,CNCF），Logo如圖1.1所示。

自此以后，Kubernetes就成為了世界上最重要的云原生技術。

與許多現代云原生項目一樣，Kubernetes通過Go語言編寫而成，開源在GitHub上（項目名為kubernetes/Kubernetes），開發人員在IRC頻道上進行溝通，人們也可以在Twitter上關注它，slack.k8s.io是一個不錯的用于溝通的Slack頻道。除此之外，還有一些定期舉行的見面會或大型會議。

1.2.1 Kubernetes和Docker

Kubernetes和Docker是兩個互補的技術。比如，通常人們會使用Docker進行應用的開發，然后用Kubernetes在生產環境中對應用進行編排。

在這樣的模式中，開發者使用自己喜歡的語言編寫代碼，然后用Docker進行打包、測試和交付。但是最終在測試環境或生產環境中運行的過程是由Kubernetes來完成的。

從運行架構上來說，假設在某生產環境中的Kubernetes集群是由10個節點構成的。那么其中的每個節點都是以Docker作為其容器運行時（Container Runtime）。也就是說，Docker是一種更加偏向底層的技術，它負責諸如啟停容器的操作；而Kubernetes是一種更加偏向上層的技術，它注重集群范疇的管理，比如決定在哪個節點上運行容器、決定什么適合進行擴縮容或升級。

圖1.2闡釋了由多個以Docker為容器運行時的節點構成的Kubernetes集群。

如圖1.2所示，Docker并非Kubernetes唯一支持的容器運行時。事實上，Kubernetes基于一系列特性實現了對容器運行時的抽象（從而可以兼容不同的底層容器運行時）。

（1）容器運行時接口（Container Runtime Interface, CRI）是Kubernetes用來與第三方容器運行時進行對接的標準化的抽象層。這樣容器運行時與Kubernetes是解耦的，同時又能夠以一種標準化的方式予以支持。

（2）運行時類（Runtime Class）是Kubernetes 1.12引入的新特性，并在1.14版中升級為beta。它對不同的運行時進行了歸類。例如，gVisor或Kata容器運行時或許比Docker和Containerd能提供更優的隔離性。

至本書撰寫時，Containerd已經趕超Docker成為Kubernetes中最普遍使用的容器運行時。它實際上是Docker的精簡版本，只保留了Kubernetes需要的部分。

雖有提及，不過這些底層技術不會影響到Kubernetes的學習體驗。無論使用哪種容器運行時，Kubernetes層面的操作（命令等）都是一樣的。

1.2.2 Kubernetes與Docker Swarm對比

2016—2017年間，在Docker Swarm、Mesosphere DCOS以及Kubernetes之間展開了一場容器編排平臺之戰。總之，Kubernetes贏得了勝利。

雖然Docker Swarm和其他容器編排平臺依然存活，但是它們的發展勢頭和市場份額都小于Kubernetes。

1.2.3 Kubernetes和Borg：抵抗是徒勞的

讀者很可能聽到過有關Kubernetes與Google的Borg和Omega系統的關系。

如前所述，很久以前Google就已經大規模地運行容器了——每周都可能運行數十億個容器。所以，多年以來，Google的搜索、Gmail和GFS等就已經在許多的容器中運行了。

對這些容器化應用的編排工作，是由Google內部被稱為Borg和Omega的技術來完成的。所以Kubernetes的出現也是水到渠成的事——畢竟它們都是大規模容器編排平臺，而且同出Google之門。

然而需要明確的是，Kubernetes并非Borg或Omega的開源版本。更恰當地說是Kubernetes與Borg和Omega有著相同的基因和家族史。就像是Borg最先出生，然后孕育了Omega。而Omega又與開源社區“比較熟”，并孵化了Kubernetes，如圖1.3所示。

問題在于，它們是不同的，但又是相關的。事實上，許多Borg和Omega的研發者也對Kubernetes有所貢獻。所以，盡管Kubernetes是從頭開始研發的，但是也吸收了來自Borg和Omega的經驗。

目前，Kubernetes是于2014年捐贈給CNCF的開源項目，基于Apache 2.0協議。其1.0版本早在2015年7月就已發布，至本書編寫時，已經到達1.16版。

1.2.4 Kubernetes——名字從何而來

Kubernetes（讀作koo-ber-net-eez）一詞來源于希臘語“舵手”——輪船的掌舵之人。這一主題也在圖標（見圖1.4）中得以體現。

Kubernetes的部分創始人想將其稱作九之七（Seven of Nine）。如果讀者了解星際迷航，就會知道九之七是一個被聯邦星艦企業號解救的女性博格（Borg），下令解救她的是凱瑟琳·珍妮薇艦長。然而，版權法不允許用這個名字。不過圖標中的“七個把手”也有向“九之七”致敬的意味。

關于名稱需要交代的最后一點是，Kubernetes經常被寫作K8s。其中的數字8替代了K和s中的8個字母——這一點倒是方便了發推，也方便了像我這樣懶惰的人。