虛擬化與編排

 

虛擬機

‘虛擬機在某些特定的硬件和內核虛擬化組成，運行客戶端操做系統，稱爲管理程序的軟件建立虛擬化硬件，其能夠包括虛擬磁盤，虛擬網絡接口，虛擬CPU等，虛擬機還包括能夠與此虛擬硬件通訊的賓客內核。管理程序能夠託管，這意味着它是一些在主機操做系統（MacOS）上運行的軟件，如示例中所示。它也能夠是裸機，直接在機器硬件上運行（替換你的操做系統）。不管哪一種方式，管理程序方法都被認爲是重量級的，由於它須要虛擬化多個部分（若是不是所有硬件和內核）。

VM 須要硬件虛擬化才能實現機器級隔離，而容器則只須要在同一操做系統內進行隔離操做。 隨着隔離空間數量的增長，開銷差別變得很是明顯。

容器

在過去幾年裏，雲平臺發展迅速，但其中困擾運維工程師最多的，是須要爲各類迥異的開發語言安裝相應的運行時環境。雖然自動化運維工具能夠下降環境搭建的複雜度，但仍然不能從根本上解決環境的問題。

 

Docker 的出現成爲了軟件開發行業新的分水嶺，容器技術的成熟也標誌着技術新紀元的開啓。Docker 提供了讓開發工程師能夠將應用和依賴封裝到一個可移植的容器中的能力，這項舉措使得 Docker 大有席捲整個軟件行業而且進而改變行業遊戲規則的趨勢，這像極了當年智能手機剛出現時的場景——改變了整個手機行業的遊戲規則。Docker 經過集裝箱式的封裝方式，讓開發工程師和運維工程師都可以以 Docker 所提供的鏡像分發的標準化方式發佈應用，使得異構語言再也不是捆綁團隊的枷鎖。

 

 

容器是包含應用程序代碼，配置和依賴關係的軟件包，可提供運營效率和生產力。在這裏，您能夠確切地知道它將如何運行，這意味着它是可預測的，可重複的和不可變的。容器的興起是 DevOps 即服務的一個巨大推進因素，能夠克服當今面臨的最大安全障礙。容器化經過在操做系統級別進行虛擬化來使應用程序可移植，從而建立基於內核的隔離的封裝系統。容器化的應用程序能夠放在任何地方，無需依賴項運行或須要整個 VM，從而消除了依賴關係。

容器可做爲一個獨立的單元，能夠在任何支持它的地方運行。在每一個實例中，容器自己都是徹底相同的。若是主機操做系統是 CentOS，Ubuntu，MacOS，甚至是像 Windows 這樣的非 UNIX 系統都可有可無——從容器內部看操做系統將是容器指定的任何操做系統。容器還充當標準化的工做或計算單元。一個常見的範例是每一個容器運行單個 Web 服務器，數據庫的單個分片或單個 Spark 工做程序等。而後，爲了擴展應用程序，你只須要擴展容器的數量。

每一個容器都有一個固定的資源配置（CPU，RAM，線程數等），而且擴展應用程序須要只擴展容器的數量而不是單個資源原語。當應用程序須要按比例放大或縮小時，這爲工程師提供了更容易的抽象。容器也是實現微服務架構的一個很好的工具，每一個微服務只是一組協做容器。例如，可使用單個主容器和多個從容器來實現 Redis 微服務。

Linux cgroups 爲一種名爲 Linux 容器（LXC）的技術鋪平了道路。 LXC 其實是咱們今天所知的第一個實現容器的主要實現，利用 cgroup 和命名空間隔離來建立具備獨立進程和網絡空間的虛擬環境。從某種意義上說，這容許獨立和隔離的用戶空間。  容器的概念直接來自 LXC。 事實上，早期版本的 Docker 直接構建在 LXC 之上。

 

編排

隨着虛擬化技術的成熟和分佈式架構的普及，用來部署、管理和運行應用的雲平臺被愈來愈多地說起。IaaS、PaaS 和 SaaS 是雲計算的三種基本服務類型，分別表示關注硬件基礎設施的基礎設施即服務、關注軟件和中間件平臺的平臺即服務，以及關注業務應用的軟件即服務。容器的出現，使原有的基於虛擬機的雲主機應用，完全轉變爲更加靈活和輕量的「容器+編排調度」的雲平臺應用。

容器單元愈來愈散落使得管理成本逐漸上升，你們對容器編排工具的需求史無前例的強烈，Kubernetes、Mesos、Swarm 等爲雲原生應用提供了強有力的編排和調度能力，它們是雲平臺上的分佈式操做系統。容器編排是一般能夠部署多個容器以經過自動化實現應用程序的過程。像 Kubernetes 和 Docker Swarm 這樣的容器管理和容器編排引擎，使用戶可以指導容器部署並自動執行更新，運行情況監視和故障轉移過程。

容器單元愈來愈散落使得管理成本逐漸上升，你們對容器編排工具的需求史無前例的強烈，Kubernetes、Mesos、Swarm 等爲雲原生應用提供了強有力的編排和調度能力，它們是雲平臺上的分佈式操做系統。

Kubernetes 是目前世界範圍內關注度最高的開源項目，它是一個出色的容器編排系統，用於提供一站式服務。Kubernetes 出身於互聯網行業巨頭——Google，它借鑑了由上百位工程師花費十多年時間打造的 Borg 系統的理念，安裝極其簡易，網絡層對接方式十分靈活。

Mesos 則更善於構建一個可靠的平臺，用來運行多任務關鍵工做負載，包括 Docker 容器、遺留應用程序（如 Java）和分佈式數據服務（如 Spark、Kafka、Cassandra、Elastic）。Mesos 採用兩級調度的架構，開發人員能夠很方便地結合公司的業務場景定製 Mesos Framework。

其實不管是 Kubernetes 仍是 Mesos，它們都不是專門爲了容器而開發的。Mesos 早於 Docker 出現，而 Kubernetes 的前身 Borg 更是早已出現，它們都是基於解除資源與應用程序自己的耦合限制而開發的。運行於容器中的應用，其輕量級的特性剛好可以與編排調度系統完美結合。

惟一爲了 Docker 而生的編排系統是 Swarm，它由 Docker 所在的 Moby 公司出品，用於編排基於 Docker 的容器實例。不一樣於 Kubernetes 和 Mesos，Swarm 是面向 Docker 容器的，相較於 Kubernetes 面向雲原生 PaaS 平臺，以及 Mesos 面向「大數據+編排調度」平臺，Swarm 顯得功能單一。在容器技術自己已不是重點的今天，編排能力和生態規劃均略遜一籌的 Swarm 已經跟不上前二者的腳步。

Kubernetes 和 Mesos 的出色表現給行業中各種工程師的工做模式帶來了顛覆性的改變。他們不再用像照顧寵物那樣精心地「照顧」每一臺服務器，當服務器出現問題時，只要將其換掉便可。業務開發工程師沒必要再過度關注非功能需求，只需專一本身的業務領域便可。而中間件開發工程師則須要開發出健壯的雲原生中間件，用來鏈接業務應用與雲平臺。