小鯨魚容器技術

轉載自：惠Thinker

什麼是容器

在容器之前， 火爆雲計算市場的是

PAAS， PAAS

已經深入人心。那時候突然有一家公司 dotCloud 劍走偏鋒， 直接開源出了

Docker

專案，並且直接面向的社群。這樣的做法直接將當時的

PAAS

流主要公司打的屁滾尿流。

回頭看，

PAAS

最核心的是隔離環境，或者叫

沙盒

，在我看來也就是

容器

。而

Docker

專案和

Cloud Foundry

的容器沒有太大的不同，但是它為什麼能針對

PAAS

進行了一場快速的閃電戰呢？

對的， 就是 Docker 映象， 這個小小的創新， 迅速改變了雲計算的發展軌跡！ Docker 映象解決的是 打包 問題。也許有人說Docker 映象就是一個壓縮包。

但是，就是這個壓縮包包含了完整的作業系統檔案和目錄， 包含了整個應用所需要的依賴，一包在手， 你可以輕易的執行你的沙盒，並且本地環境與雲端環境高度一致（這是最寶貴的）。

Docker給PAAS進行了致命打擊， 提供了便利的打包機制， 面向後端開發者來說， 遮蔽了機器、核心等技術細節， 避免了在不同環境間的差異引入的試錯成本。是一次解放生產力的革命。當然很多開發者用腳投票， 了結了PAAS時代。

Docker 三大利器

Docker

專案的高調開源， 解決了打包和釋出困擾運維的技術難題，同時它也第一次純後端的概念透過友好的設計和封裝交付到了開發者的手裡。

Swarm，Docker

是建立和啟停容器的工具，那麼

Swarm

是為了向平臺化發展而提出的。它提供了完整的整體對外提供叢集管理功能，它的亮點是完全使用

Docker

原本的管理容器的API來完成叢集管理。

# Swarm多機環境下，指令會被Swarm攔截處理，後面透過排程演算法找到合適的Docker Daemon執行

docker run -H “Swarm叢集API” “我的容器”

Compose

（Fig）專案， 這是第一次在開發者面前提出

容器編排

（Container Orchestration）概念。

應用容器 A， 資料庫容器B， 負載均衡容器C， Compose 允許 A、B、C 三個容器定義在配置檔案中， 並指定關聯關係。 只需要執行 （fig/docker-compose up）

容器化群雄並起與塵埃落定

容器開啟火爆模式， 大量圍繞

Docker

專案的網路、儲存、監控、

CI/CD

、UI 等湧現了諸如

Rancher、Tutum

等在開源和商業上取得成功的創業公司。

在

Docker 、 Google、CoreOS、ReaHat

等公司在雲計算大打出手的時候，落在下風的

Google、CoreOS、RedHat

開始忽悠

Docker

將

Libcontainer

專案捐出、組建一個完全獨立中立的基金會管理，以

RunC

（改名的

Libcontainer

）為依據，大家共同制定一套容器和映象的標準和規範。

這套標準和規範就是

OCI

（

Open Container Initiative

），

OCI

的提出，將容器執行時和映象的實現從

Docker

專案只完全剝離開來。（好一招圍魏救趙，改善

Docker

公司一家獨大，其他公司不依賴與

Docker

專案）

這是第一步，後面就是容器之上的平臺層，就是

PAAS

層了，後來

Google、RedHat

等基礎設施玩家，共同發起

CNCF

（

Cloud Native Computing Foundation

） 基金會。

以

Kubernetes

專案為基礎，建立由開源基礎設施廠商領導的按照基金會方式運營的平臺級社群。

Kubernetes

專案必須能夠在容器編排領域取得足夠大的競爭優勢

CNCF

社群必須以

Kubernetes

專案為核心，覆蓋更多的常見

Kubernetes

當初為什麼被認為設計思想過於超前，就是因為 Google 在容器化多年的沉澱和昇華（

Borg

和

Omega

特性、落在

K8S

上就是

Pod、Sidecar

的功能和設計模式）

Kubernetes

當初沒有選擇和

Swarm

展開同質化競爭，而是提出太多的設計理念和號召力，很快構建了不同的容器編排的管理的生態理念，超過了

Swarm

專案。

有了這個後，又將容器監控事實標準

prometheus

融入其中，後面又新增了

Fluentd、OpenTracing、CNDI

等諸多容器生態工具和專案。

後面又一記補刀：整個社群進行推進

民主化

架構， 從 API 到 容器執行時的 每一層，

Kubernetes

專案都為開發者暴露出了可以擴充套件的外掛機制， 鼓勵社群使用者透過程式碼的方式介入

Kubernetes

專案的每一個階段。

這個操作針對

Docker

來說是致命的，整個容器社群催生了大量的、基於

Kubernetes API

的做擴充套件的和二次開發創新的

微服務治理專案

Istio

狀態應用部署架構

Operator

…

經過一些列騷操作後，K8S 大行其道，編排之爭落下帷幕，容器社群的後續繁榮完全以

Kubernetes

專案為核心的百家爭鳴， 從

Rancher

專案的歷史迭代過程中也能看出這個精彩紛呈的展現。