開源容器編排引擎 Kubernetes 絕對有魔力。

　　一直以來，容器就是個很酷的概念，但事實上，廣泛部署卻十分困難。你幾乎沒法手動管理容器之間的網(wǎng)絡(luò)、持續(xù)存儲和數(shù)百個容器間的自動擴展，而一個讓人拍案叫絕的容器管理平臺卻遲遲未出現(xiàn)。

　　這樣的局面一直維持到2014年，谷歌將 Kubernetes 項目發(fā)布到開放源代碼社區(qū)之前。

　　Kubernetes 一開源，企業(yè)或者開發(fā)人員就可以在 Kubernetes 集群上自動管理網(wǎng)絡(luò)、存儲、自動擴展、警報以及許多其他標(biāo)準(zhǔn)化基礎(chǔ)架構(gòu)功能，它極少宕機，而且表現(xiàn)非凡。大規(guī)模運行容器和利用分布式基礎(chǔ)設(shè)施成為許多公司的可行選擇。

　　巧合的是，云原生應(yīng)用程序的想法引來了 pets 與 cattle 的討論，基礎(chǔ)設(shè)施的每個組件都變得可替代，而不再是不可替代的 pet。隨著這種思路的更新，每個組件在運行失敗的時候都不會受影響：服務(wù)器、機架、數(shù)據(jù)中心這些。然而，諷刺的是，許多公司像對待寵物一樣對待其 Kubernetes 集群，花費大量時間和資源來照顧。

　　在我們看來，這相當(dāng)奇怪，本不該如此，因為它違背了云原生應(yīng)用的理念。因此，我們的任務(wù)很明確：我們希望 Kubernetes 成為低維護 cattle：完全管理、可擴展、多租戶和隨時可用。此外，我們希望為所有的集群提供一個 API。

　　如果 Kubernetes 為運行自動化集群提供了完美的工具，那么為什么不使用 Kubernetes 自主托管多個 Kubernetes 集群？為什么不把關(guān)注的重點從“管理一個 Kubernetes 集群”，重新轉(zhuǎn)移到“管理一個服務(wù)”？例如配置 “Kubernetes-as-a-Service” 的服務(wù)。

　　Kubernetes 中如何運行 Kubernetes 呢？

　　首先要做的是建立運行多個獨立客戶集群的主組件的外部 Kubernetes 集群。像其他 Kubernetes 集群一樣，主集群由四個主要組件組成：API server，etcd key value store，scheduler 和 controller。為了防止停機，我們?yōu)槊總€組件創(chuàng)建了一個具有多個實體的高可用性設(shè)置。

　　然后，啟動內(nèi)部集群。我們創(chuàng)建了一個命名空間，生成證書、令牌和 SSH 密鑰，并部署主組件。隨后，我們添加了一個入口，使 API 服務(wù)器等從外部訪問。最后，我們安裝了基本的插件，如 Heapster，kube-proxy，Kube-dns 和 dashboard。

　　之后，我們想知道內(nèi)部群集中發(fā)生了什么，也就是節(jié)點和 pod 實際上正在運行的地方。不幸的是，無法進行標(biāo)準(zhǔn)的 Kubernetes 設(shè)置，只能與主集群的 API 進行通信。為了進一步復(fù)雜化，我們要使用 N 個 API 服務(wù)器和 N 個擁有主集群 IP 的 etcd 實例來設(shè)置 N 個集群。因此，我們需要提供一種能夠通過 SSH 隧道向客戶 API 服務(wù)器3發(fā)送客戶 API 服務(wù)器3的加密請求的 HTTP 和 TCP 代理服務(wù)。

　　總結(jié)

　　我們展示的是：您可以在 Kubernetes 中運行 Kubernetes 來提供多個自主托管和完全管理的內(nèi)部集群。這樣可以輕松地創(chuàng)建、更新、刪除和重新安排集群，而不影響功能。此外，這種架構(gòu)確保更高的隔離度和安全性，并且很大程度上促進了多租戶。

　　雖然這個概念還處于萌芽階段，但我們認為，Kubernetes-in-Kubernetes 是為再次逃避 pet 范式所跨出的重要一步。這個概念使企業(yè)能夠大規(guī)模地運行多個集群，同時追求真正的云原生策略，讓企業(yè)只需要專注于應(yīng)用程序，而不是基礎(chǔ)設(shè)施。

相關(guān)電子資料下載