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

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

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

　　Kubernetes 一開源，企業或者開發人員就可以在 Kubernetes 集群上自動管理網絡、存儲、自動擴展、警報以及許多其他標準化基礎架構功能，它極少宕機，而且表現非凡。大規模運行容器和利用分布式基礎設施成為許多公司的可行選擇。

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

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

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

　　Kubernetes 中如何運行 Kubernetes 呢？

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

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

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

　　總結

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

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