【編者的話】

目前很多的容器雲平臺通過Docker及Kubernetes等技術提供應用執行平臺，從而實現運維自動化，快速部署應用、彈性伸縮和動態調整應用環境資源，提高研發運營效率。

從巨集觀到微觀（從抽象到具體）的思路來理解：雲端計算→PaaS→ App Engine→XAE[XXX App Engine] （XAE泛指一類應用執行平臺，例如GAE、SAE、BAE等）。

本文簡要介紹了與容器雲相關的幾個重要概念：PaaS、App Engine、Docker、Kubernetes。

1. PaaS概述

1.1. PaaS概念

1. PaaS(Platform as a service)，平臺即服務，指將軟體研發的平臺（或業務基礎平臺）作為一種服務，以SaaS的模式提交給使用者。
2. PaaS是雲端計算服務的其中一種模式，雲端計算是一種按使用量付費的模式的服務，類似一種租賃服務，服務可以是基礎設施計算資源（IaaS），平臺（PaaS），軟體（SaaS）。租用IT資源的方式來實現業務需要，如同水力、電力資源一樣，計算、儲存、網路將成為企業IT執行的一種被使用的資源，無需自己建設，可按需獲得。
3. PaaS的實質是將網際網路的資源服務化為可程式設計介面，為第三方開發者提供有商業價值的資源和服務平臺。簡而言之，IaaS就是賣硬體及計算資源，PaaS就是賣開發、執行環境，SaaS就是賣軟體。

1.2. IaaS/PaaS/SaaS說明

1.3. PaaS的特點（三種層次）

2. App Engine概述

2.1. App Engine概念

App Engine是PaaS模式的一種實現方式，App Engine將應用執行所需的 IT 資源和基礎設施以服務的方式提供給使用者，包括了中介軟體服務、資源管理服務、彈性排程服務、訊息服務等多種服務形式。App Engine的目標是對應用提供完整生命週期（包括設計、開發、測試和部署等階段）的支援，從而減少了使用者在購置和管理應用生命週期內所必須的軟硬體以及部署應用和IT 基礎設施的成本，同時簡化了以上工作的複雜度。常見的App Engine有：GAE(Google App Engine)，SAE(Sina App Engine)，BAE(Baidu App Engine)。

App Engine利用虛擬化與自動化技術實現快速搭建部署應用執行環境和動態調整應用執行時環境資源這兩個目標。一方面實現即時部署以及快速回收，降低了環境搭建時間，避免了手工配置錯誤，快速重複搭建環境，及時回收資源， 減少了低利用率硬體資源的空置。另一方面，根據應用執行時的需求對應用環境進行動態調整，實現了應用平臺的彈性擴充套件和自優化，減少了非高峰時硬體資源的空置。

簡而言之，App Engine主要目標是：Easy to maintain(維護), Easy to scale(擴容), Easy to build(構建)。

2.2. 架構設計

2.3. 組成模組說明

3. 容器雲平臺技術棧

• Namespace[資源隔離]
  Namespaces機制提供一種資源隔離方案。PID,IPC,Network等系統資源不再是全域性性的，而是屬於某個特定的Namespace。每個namespace下的資源對於其他namespace下的資源都是透明，不可見的。

• CGroups[資源控制]
  CGroup（control group）是將任意程序進行分組化管理的Linux核心功能。CGroup本身是提供將程序進行分組化管理的功能和介面的基礎結構，I/O或記憶體的分配控制等具體的資源管理功能是通過這個功能來實現的。CGroups可以限制、記錄、隔離程序組所使用的物理資源（包括：CPU、memory、IO等），為容器實現虛擬化提供了基本保證。CGroups本質是核心附加在程式上的一系列鉤子（hooks），通過程式執行時對資源的排程觸發相應的鉤子以達到資源追蹤和限制的目的。

4. Docker概述

4.1. Docker介紹

1. Docker - Build, Ship, and Run Any App, Anywhere
2. Docker是一種Linux容器工具集，它是為“構建（Build）、交付（Ship）和執行（Run）”分散式應用而設計的。
3. Docker相當於把應用以及應用所依賴的環境完完整整地打成了一個包，這個包拿到哪裡都能原生執行。因此可以在開發、測試、運維中保證環境的一致性。
4. Docker的本質：Docker=LXC(Namespace+CGroups)+Docker Images，即在Linux核心的Namespace[資源隔離]和CGroups[資源控制]技術的基礎上通過映象管理機制來實現輕量化設計。

4.2. Docker的基本概念

4.2.1. 映象

Docker 映象就是一個只讀的模板，可以把映象理解成一個模子（模具），由模子（映象）製作的成品（容器）都是一樣的（除非在生成時加額外引數），修改成品（容器）本身並不會對模子（映象）產生影響（除非將成品提交成一個模子），容器重建時，即由模子（映象）重新制作成一個成品（容器），與其他由該模子製作成的成品並無區別。

例如：一個映象可以包含一個完整的 ubuntu 作業系統環境，裡面僅安裝了 Apache 或使用者需要的其它應用程式。映象可以用來建立 Docker 容器。Docker 提供了一個很簡單的機制來建立映象或者更新現有的映象，使用者可以直接從其他人那裡下載一個已經做好的映象來直接使用。

4.2.2. 容器

Docker 利用容器來執行應用。容器是從映象建立的執行例項。它可以被啟動、開始、停止、刪除。每個容器都是相互隔離的、保證安全的平臺。可以把容器看做是一個簡易版的 Linux 環境（包括root使用者許可權、程序空間、使用者空間和網路空間等）和執行在其中的應用程式。

4.2.3. 倉庫

倉庫是集中存放映象檔案的場所。有時候會把倉庫和倉庫註冊伺服器（Registry）混為一談，並不嚴格區分。實際上，倉庫註冊伺服器上往往存放著多個倉庫，每個倉庫中又包含了多個映象，每個映象有不同的標籤（tag）。

4.3. Docker的優勢

1. 容器的快速輕量

   容器的啟動，停止和銷燬都是以秒或毫秒為單位的，並且相比傳統的虛擬化技術，使用容器在CPU、記憶體，網路IO等資源上的效能損耗都有同樣水平甚至更優的表現。

2. 一次構建，到處執行

   當將容器固化成映象後，就可以非常快速地載入到任何環境中部署執行。而構建出來的映象打包了應用執行所需的程式、依賴和執行環境， 這是一個完整可用的應用集裝箱，在任何環境下都能保證環境一致性。

3. 完整的生態鏈

   容器技術並不是Docker首創，但是以往的容器實現只關注於如何執行，而Docker站在巨人的肩膀上進行整合和創新，特別是Docker映象的設計，完美地解決了容器從構建、交付到執行，提供了完整的生態鏈支援。

5. Kubernetes概述

5.1. Kubernetes介紹

Kubernetes是Google開源的容器叢集管理系統。它構建Docker技術之上，為容器化的應用提供資源排程、部署執行、服務發現、擴容縮容等整一套功能，本質上可看作是基於容器技術的Micro-PaaS平臺，即第三代PaaS的代表性專案。

5.2. Kubernetes的基本概念

5.2.1. Pod

Pod是若干個相關容器的組合，是一個邏輯概念，Pod包含的容器執行在同一個宿主機上，這些容器使用相同的網路名稱空間、IP地址和埠，相互之間能通過localhost來發現和通訊，共享一塊儲存卷空間。在Kubernetes中建立、排程和管理的最小單位是Pod。一個Pod一般只放一個業務容器和一個用於統一網路管理的網路容器。

5.2.2. Replication Controller

Replication Controller是用來控制管理Pod副本(Replica，或者稱例項)，Replication Controller確保任何時候Kubernetes叢集中有指定數量的Pod副本在執行，如果少於指定數量的Pod副本，Replication Controller會啟動新的Pod副本，反之會殺死多餘的以保證數量不變。另外Replication Controller是彈性伸縮、滾動升級的實現核心。

5.2.3. Service

Service是真實應用服務的抽象，定義了Pod的邏輯集合和訪問這個Pod集合的策略，Service將代理Pod對外表現為一個單一訪問介面，外部不需要了解後端Pod如何執行，這給擴充套件或維護帶來很大的好處，提供了一套簡化的服務代理和發現機制。

5.2.4. Label

Label是用於區分Pod、Service、Replication Controller的Key/Value鍵值對，實際上Kubernetes中的任意API物件都可以通過Label進行標識。每個API物件可以有多個Label，但是每個Label的Key只能對應一個Value。Label是Service和Replication Controller執行的基礎，它們都通過Label來關聯Pod，相比於強繫結模型，這是一種非常好的鬆耦合關係。

5.2.5. Node

Kubernets屬於主從的分散式叢集架構，Kubernets Node（簡稱為Node，早期版本叫做Minion）執行並管理容器。Node作為Kubernetes的操作單元，將用來分配給Pod（或者說容器）進行繫結，Pod最終執行在Node上，Node可以認為是Pod的宿主機。

5.3. Kubernetes架構