從容器化技術到現代雲計算有多遠?

在接下來的幾周，我們將會發佈一個新的系列博客，在這個系列中，我們想闡述Google對於容器技術的一些觀點，此外我們還會和讀者分享Google在過去十年間，在容器中運行服務的一些經驗。 我們是一支由Google的產品經理、一線技術員以及架構師組成的團隊，團隊共同的目標是要説明讀者瞭解「容器技術革命」如何能更有效的構建和運行服務。 這次我們邀請了「Google 雲平臺全球解決方案」的專家Miles Ward來做分享，作為這一系列博客的開篇。

各位好！ 歡迎來到我們新的系列博客，在這個系列中，我們將要為大家介紹當今計算模型創新中最時髦的領域之一：容器化技術（containerization）。

你可能會有很多疑惑：容器到底是什麼，它究竟怎樣工作？ Docker、Kubernetes到底指的是什麼，Google Container Engine以及Managed VM又有什麼用？ 它們之間有何關聯，我們如何通過容器來構建一個功能強大的服務，並且能讓它們在生產環境的大規模集群中使用？ 使用者採用這種技術，怎樣才能獲得商業價值？ 好了，我們不再賣關子，接下來就直入主題。 我們首先會對容器技術進行具體的介紹，之後講述容器技術究竟如何使我們更好地進行工作。

隨著計算模型（computing models）的不斷發展衍化，我們曾經經歷過幾次計算模型解決方案的轉變。 回顧在過去的10年，我們從虛擬化技術的角度可以很清楚看到這種變化的過程。 受益于虛擬化技術的發展，我們對整體資源的使用效率有了巨大的提升，與此同時，我們工作的時間價值和為了交付服務所做的重複性工作得到了相應減少。 隨著多租戶、基於API的管理以及公有雲計算技術的到來，這一趨勢更是被不斷加強。 這其中，最關鍵的突破就是資源使用方式所發生的變化。 通過虛擬化的方式，我們可以在幾分鐘之內，虛擬出一個小的、獨立的、隨需隨用CPU內核，這個虛擬的CPU內核感覺像是直接運行在物理機之外。 那麼問題來了，當你僅僅需要使用一小部分資源的時候，是否還有必要虛擬出一整台機器？

Google在很早的時候就已經遇到了這個問題：我們需要更快、更便宜的方式發佈軟體，並且支撐服務運行所需要的計算資源的規模也以前從未有過的，那麼這一問題應該如何解決？ 為了滿足這一需求，我們需要對已有資源進行更高級別的抽象，使得服務可以通過更細的細微性對資源進行控制。 為此，我們為Linux內核添加了新的技術，這便是眾所周知的cgroup，我們通過這一技術來對服務運行時環境進行隔離，這種被隔離起來的運行時環境就被稱為容器。 這是一種新的虛擬化技術，通過這一技術，我們簡化了Google全部服務運行所需要的底層OS環境。 之後的幾年一直到現在，容器相關的技術不斷發展，隨著Docker的出現，這一技術的影響得到了進一步擴大，Docker也正是通過使用這一技術為基於容器的應用創建了一種可交互操作的格式（interoperable format）。

為何使用容器？
容器技術究竟提供了哪些虛擬機器所沒有的？
簡化部署（Simple deployment）：容器技術可以將你的應用打包成單一位址訪問的、registry存儲的（registry-stored）、僅通過一行命令就可以部署完成的元件。 不論你想將服務部署在哪裡，容器都可以從根本上簡化你的服務部署工作。

快速可用（Rapid availability）：容器技術對作業系統的資源進行再次抽象，而並非對整個物理機資源進虛擬化，通過這種方式，打包好的服務可以在1/20秒的時間內啟動，相比之下， 可能需要一分鐘的時間才能啟動一台虛擬機器。

微服務化（Leverage microservices）：容器可以允許開發者和系統管理人員對計算資源進行進一步細分，如果一個小型的虛擬機器所提供的資源相對於服務運行所需要的資源來說過於龐大，或者對於你的系統而言， 一次性地擴展出一台虛擬機器會需要很多的工作量，那麼容器可能會很好的改善這一狀況。

容器技術的這些優點能為你的工作帶來哪些説明？
最明顯的一個方面就是：開發者只需要通過他們的筆記本電腦就能同時運行多個容器，並進行方便快速的服務部署。 雖然在一台筆記本電腦上運行多個虛擬機器也是可以的，但是顯然通過容器的方式可以更快速、簡單、羽量級。

不僅如此，容器還可以使得服務發行版本的管理變得更加容易，發佈一個新的容器版本僅僅需要一個單獨的命令就能完成。 同時，測試工作也變得更加容易，在公有雲平臺中，虛擬機器的計費方式可能至少以10分鐘為單位（或者，一整個小時？ ），如果僅運行單個測試程式，由於測試所消費的資源可能並不多。 但是，如果你每天要運行上千個測試驅動導向的程式，資源成本就可能直線上升。 如果改用容器進行同樣的測試工作，你只需要用同樣的資源消耗（與使用一台虛擬機器相同的資源消耗）來完成這上千個測試，這將會大大節省你的服務運行成本。

另外一個重要的優勢就是組合特性，採用容器的方式進行部署，整個系統會變得易於組合，特別是對於那些需要使用到開源軟體的系統。 對於系統管理人員，以下的工作可能會使人望而卻步：安裝和配置MySQL、Memcatched、MongoDB、Hadoop、GlusterFS、RabbitMQ、Node.js、Nginx等等，之後再將這些軟體封裝起來， 為服務提供一個運行平臺。 然而，這些複雜的工作完全可以通過啟動幾個容器來完成：先將這些服務封裝在對應的容器中，之後結合一些腳本使這些容器按照要求相互協作，這樣操作不僅可以簡化部署難度還可以降低操作風險。

如果你想按照前面所描述的過程構建一個服務平臺，可能會有許多容易出錯的地方，整個配製過程也需要具備很專業的知識， 中間可能還會有許多重複的勞動。 因此，我們可以先將核心的容器元件以規範的方式來實現，之後將它們添加在公共的registry服務中。 這樣其他使用者就可以通過registry服務隨時獲得所需要的容器，擁有高品質元件的容器生態系統就這樣被構建起來。

在相當長的一段時間內，容器技術最重要的價值就是為不同的主機上運行服務提供一個輕便的、一致的格式。 例如，如果你今天要構建一個服務，你可能先要接入裸機伺服器，並且使用虛擬化之後的預先定義好的基礎設施，或者直接使用共有或者私有的雲服務平臺，當然也有許多PaaS供應商可以供你選擇。 然而，你為了使自己服務能夠運行在不同的服務平臺上，可能需要通過多種不通的方式對服務進行打包！ 而如果通過在容器格式進行標準化的操作，這些不同的計算模型的供應商們就可以給使用者提供一種獨特的交付體驗，這可以允許使用者方便地對工作負載地進行遷移，使用者可以選擇將工作任務部署在最便宜和最快的平臺上，避免局限于單一的平臺供應商。

Docker
網上已經有很多的對於容器技術和Docker相關技術如何實現的細緻的介紹文檔，特別是這裡、這裡和這裡。 這些文檔已經足夠能說明，Docker是一個「很棒的解決方案」，也就是說，目前可能還沒有其它方案能夠和它相媲美。

容器技術增強了對資源控制的細微性，這一點確實有很高的實用價值，但是對於那些需要上千台伺服器一起來運行的服務而言，單純的容器技術並沒有從本質上提高任何工作負載的運行效率。 如今的Docker僅僅是為了在單一的機器操作而設計，於是我們又可以提出一連串的問題：這些在集群上所運行的容器和容器中運行的工作負載應該被如何分配和協調，它們怎樣才能按照資源的消耗量來進行管理？ 它們如何在多租戶的網路環境下進行運行？ 它們的安全性能又該如何被保證？

或許從系統設計的角度來看，我們可以提出一個更本質的問題：當前我們所討論的到底是不是正確的資源抽象方式？ 與我交流過的大多數開發者以及公司的贊助商，他們對在指定的機器上的指定容器並不感興趣，他們真正想要自己的服務如何能被啟動運行，產生價值，並且易於監管和維護，他們並不想瞭解全部的瑣碎細節（至少他們希望這樣）， 例如指定個機器上的指定個容器到底在做什麼。

Kubernetes
Google通過產品的不斷反覆運算解決了這個問題：我們構建了一個管理系統，它可以用來管理集群、網路以及命名系統。 這個管理系統的第一個版本被稱為Brog，它的後續的版本稱為Omega。 通過這個管理系統，我們可以在Google的大規模的集群資源上使用容器技術。 我們現在每秒會啟動大約7000個容器，每週可能會超過20億個容器。 我們利用Google在容器技術上的實踐經驗和技術積累，構建了Kubernetes(在論壇上有些時候被簡寫為K8s)。

Kubernetes從另一個角度對資源進行抽象，它讓開發人員和管理人員共同著眼于服務的行為和性能的提升，而不是僅僅關注對單一的元件或者是基礎資源。

那麼Kubernetes集群到底提供了哪些單一容器所沒有功能？ 它主要關注的是對服務等級的控制而並非僅僅是對容器級別的控制，Kubernetes提供了一種「機智」的管理方式，它將服務看成一個整體。 在Kubernete的解決方案中，一個服務甚至可以自我擴展，自我診斷，並且容易升級。 例如，在Google中，我們使用機器學習技術來保證每個運行的服務的目前狀態都是最高效的。

如果說單一容器能夠説明開發者減少部署工作的繁瑣，那麼Kubernetes就可以最大化的減少團隊開發過程中協同工作的複雜性。 Kubernets可以讓團隊以容器的方式將服務結合在一起，並且讓這些容器按照指定的規則來進行部署，以確保服務能夠正確運行。 在傳統的方式下，由於缺乏隔離性，服務之間或服務之間的各個部分很容易產生相互干擾，但是通過Kubernetes，這些矛盾可以從系統的角度上被避免，在Google，通過使用這種增強的協同工作的方式，開發者的生產力得以提高， 服務的可用性也進一步增強，這也使得在大規模的集群上的部署變得更加敏捷。

然而我們的技術仍然處於早期的發展階段。 目前，Kubernetes已經被許多客戶和公司的知名團隊所採用，包括RedHat ，VMware，CoreOS，以及Mesosphere 等等。 這些公司迫切地希望通過Kubernete進行的規模化部署來説明他們的客戶提取出容器技術的商業價值。

Container Engine
Google Container Engine在Google的雲平臺上引入了「容器即服務」的理念。 基於Kubernetes的技術，容器引擎為開發者提供了快速構建和運行容器的方法，此外，容器引擎還可以對容器進行部署、管理、並且使容器按著設定的邊界進行擴展。 在接下來的文章中我們會對容器引擎進行更多的介紹。

Deployment options
我們可以看到，容器化技術已經成為了計算模型演化的一個開端，Google在這場技術革命中扮演重著要的角色。 隨著讀者開始逐漸接觸容器，並對容器部署方式瞭解不斷深入，在實際服務部署中，可以對下面幾種方式進行調研，並從中選出最適合的一種：

如果你打算運行一個被管理的集群或者啟動幾十個容器，使用Google Container Engine試一試。 如果你想要在共有的基礎設施上或者是自己的系統中構建自己的集群，可以使用Kubernetes來操作。 想要在已經被管理好的基礎設施上運行一個容器，可以嘗試使用Google App Engine或者是Managed VMs。