在NEXT雲端大會前一周，Google先釋出了Kubernetes 的1.2新版本，這個看似Google為了追趕Container及Docker熱潮而生的開源平臺，直到Next大會才揭開了它的真正面紗，其實這個專案源自Google已經用了10年的Container技術。
Alphabet執行董事長Eric Schmidt表示，2003年時，Google已經發展到第三代雲端平臺架構，開始使用Container技術來部署全球架構的雲端服務，因此而能催生了如Gmail這類全球規模的雲端服務。10年前，Google更發明了用來管理全球最大規模叢集的排程和服務管理工具Borg。
2008年，Google推出了App Engine，讓開發者可以快速利用各種雲端API來打造自己的應用，這個底層也是Container，但卻沒有受到開發者的青睞而使用率不佳。因為App Engine平臺出現太早，Eric Schmidt表示，「因為這是我們以為開發者應該需要的地方，卻不是當時開發者真正需要的地方。」後來Google在2010年推出了VM租用服務，這就是GCP雲端平臺的誕生。
不過，Google自家服務仍舊部署在可以提供更高彈性、以Container為主的第三代Google平臺上，而非是採用較舊VM技術的GCP雲端服務（對Google而言）。至今，Google每周啟用的Container數量超過了20億個。
直到現在，Google基礎架構副總裁Eric Brewer表示，以Container封裝應用、可動態維運、微服務架構導向的雲端原生應用風潮開始興起，Google遂將用來管理和部署大規模Container的Borg和Omega等管理平臺的經驗，重新開發成了一套開源容器叢集管理軟體Kubernetes，並推出以Kubernetes打造的Google雲端平臺提供的GKE（Google Container Engine）雲端服務。
不同於Docker要讓Container可用，Eric Brewer表示，Kubernetes的目的是要讓Container能用於Production環境，使Container叢集建置可以標準化，讓分散式App的開發更容易。
在Kubernetes 1.2新版已可做到單一叢集提供3萬個Container的管理能力，也具備了彈性自動化擴充能力。
不過，Eric Brewer認為，更重要的新功能是ConfigMap API。這提供了可程式化和高彈性的部署配置，可以在開發常見的應用部署階段之前，提供一種新的組合式部署方法稱為Construction，在部署階段仍然可以即時變更Config配置，例如由程式自動依據部署環境在測試環境、Stage或Production階段來調整不同資料庫的配置參數，可以提供比腳本程式控制或是DSL配置語言更彈性的自動化配置方法。
如此一來，Google雲端平臺副總裁Brian Stevens表示，開發者只要將容器化後的應用丟上雲端，就能自動部署成為全球架構的服務，甚至不需要管理叢集，也根本看不到伺服器。Container是史上第一個能將所有應用封裝在標準化環境的技術，這是邁向無伺服器架構的關鍵。「儘管目前全球Container使用量不到VM用量的5％，但維運角色（Ops）終究會消失，這是正在發生的事。」