容器技術的快速發展為我們帶來了一個新的問題：如何有效管理和協調這些容器？當容器數量從幾個增長到數百甚至數千個時，手動管理變得不可行。這就是為什麼容器協調系統變得如此重要。
容器協調的現狀與挑戰
在當今技術環境中，沒有一種放之四海而皆準的協調方法。不同組織根據自身需求和背景，採用不同的協調策略。這種多樣性反映了一個重要現實：雖然容器化技術已經成熟，但使用者和企業的需求仍在不斷變化，這將持續推動協調技術的演進。
容器領域中一個尚未解決的核心爭論是：容器應該是臨時的、短暫的功能載體，還是持久的功能封裝體？這是一場重要的辯論，雙方都有合理的論點：
- 永續性需求：許多應用需要某些功能保永續性，以維護資料完整性
- 臨時性優勢：微服務架構要求容器具有臨時性或短暫性，以避免工作流程演變成複雜的「義大利麵條式」程式碼
另一個關鍵因素是人員在工作流程中的角色。擁抱DevOps理念的企業習慣於將應用視為不可變映像。在這種思維模式中，不可變性歸因於軟體而非基礎設施。企業選擇協調工具的方式不僅反映了他們與軟體的互動方式，也體現了團隊成員之間的協作模式。
五種工作負載協調風格
由於設定管理、DevOps和雲端服務佈建在現代企業中扮演著不同程度的角色，組織可能採用不同的協調策略，甚至在不同部門使用多種策略。
1. 根據Docker的系統
從易用性角度看，Docker原生的協調系統並不複雜。該系統根據命令列，對開發人員和管理員都很熟悉。但它的基本假設是由開發人員在開發過程中使用。
Docker的核心元件包括：
- Docker Engine：包含執行容器的守護程式(daemon)
- Docker Swarm：將多個地址空間集中到一個中央叢集，執行「反向虛擬化」，為Docker Engine抽象化叢集的複雜性
- Docker Compose：透過Dockerfile描述容器中應用的需求，Docker Engine執行這些命令來產生完全活躍的執行環境
雖然有些公司可能會爭論這些工具是否構成真正的協調方法，但Compose用於啟動、監控和存取容器內執行服務的命令足夠規範，可以自動化。從這個角度來看，協調確實是可行的。
2. 多租戶排程的微服務平台
目前最受認可的協調平台之一是那些支援微服務的平台。Google是最早嘗試這種架構的組織之一，它建立了一個名為Borg的協調系統，其原則被傳遞給了Google管理的開放原始碼專案Kubernetes與Swarm一樣，維護由伺服器叢集組成的池化分散式計算環境，每個節點可以是虛擬或物理伺服器。Kubernetes在這些節點內識別稱為「pod」的容器群組，它們可以分享資源並同時執行。
Pod在建立工作負載分配策略中發揮重要作用。在導向微服務的系統中，單個服務和功能可能同時被多個應用程式使用。將具有相似資源需求的功能劃分到pod中，可以實作一種管理方案，其中pod內的功能根據當時執行的應用程式的需求重新分配資源。
這改變了負載平衡的功能，負載平衡最初是複製伺服器的問題，然後變成複製應用程式的問題。現在，應用程式不必僅因為其功能需要擴充套件而整體擴充套件。
Apache Mesos是另一個廣泛用於池化容器資源並在該池上排程工作負載執行的開放原始碼工具。Mesosphere生產一個商業協調環境，稱為「資料中心作業系統」(DCOS)，包括在伺服器叢集上執行的多個工作負載的即時視覺表示。
Marathon，Mesosphere為在其平台上排程容器工作負載而生產的工具之一，最初是作為Kubernetes的替代方案提供的。如今，公司將這兩個協調系統都包含在DCOS中，並讓客戶選擇在實際使用案例中使用其中之一或兩者。
3. Jenkins整合的變更控制平台
Jenkins本身不是容器協調器。它是一個開放原始碼CI/CD平台，自動化開發、測試和預備環境，然後將應用佈署到生產環境。更重要的是，Jenkins旨在規範人們在開發新軟體時需要做的工作。在Jenkins中，可以自動化和指令碼化的工作階段被稱為「管道」(pipelines)。
最初，Jenkins和其他CI/CD系統中的工作負載被封裝為虛擬機器(VM)。當組織開始採用Docker時，很快就發現與容器相關的人工作流程並不能與VM維護一對應。
CloudBees，生產Jenkins商業版本的公司，製造了一個名為Workflow的外掛程式，重新定義了Jenkins自身的持續交付概念，以更開放地支援容器化。Workflow的配套外掛程式被增加到Docker中，使用Groovy語言編寫的指令碼啟用管道入口點，這些指令碼更符合容器開發者日常執行的流程類別。
值得注意的是，使用CloudBees Jenkins以這種方式籌備工作負載，與Kubernetes、Tectonic和Mesosphere/Marathon的典型使用案例並不衝突。CI/CD管道專注於使用容器自動化開發過程，而這些其他協調平台專注於使用容器管理佈署和常規使用。
然而，在當今企業中，遵循CI/CD理念與遵從DevOps原則密不可分。Jenkins經常與Chef、Puppet、Salt和Ansible等設定管理(CM)工具整合。雖然這些CM工具的供應商描述自己與協調工具相容，但在實際中，許多企業認為它們功能重複，因此不會同時使用它們。
一個從一開始就設計為與Jenkins及其管道化工作流程相容的替代協調器是Docker Cloud。它以一種非常直接的、類別似Amazon的風格呈現工作流程自動化，IT管理員可能會感到舒適。
4. DevOps不可知的整合平台
在幾乎每個軟體行業，都有一些平台以「端對端」的優勢呈現自己。幾十年來，有「生命週期管理」工具，許多CM套件被作為此類別工具進行行銷，無論好壞。但這些平台經常同時使用的事實，說明瞭一個尚未發現的事實：組織內的「端點」往往會移動。
Shippable生產了一個根據雲的持續整合平台，它與Docker整合，但避免使用Jenkins。它還透過佈署容器映像的方式繞過了典型的設定管理。選擇將容器視為持久而非瞬態，Shippable的方法是監控資源並相應地調整其設定。
5. 微分段的混合平台
由於容器化平台沒有傳統虛擬機器的位置，VMware不可避免地直接解決了Docker使用者的需求。該公司設計了一種「擁抱和擴充套件」政策，包括將Docker容器包裝在一個名為「jeVM」的封裝中，使其現有的vSphere環境像接受任何其他VM一樣接受它。
透過包含該公司的Photon作業系統(OS)，容器可以由VMware虛擬機器監控程式而不是Linux核心託管。在這種方案中，協調變成了在現有環境中佈署容器例項（如VM）的問題。雖然這停用了按照當前模型的微服務的任何前景，但這種模式確實具有與企業現有的CM和CI/CD平台即時整合的優勢。然而，在這種模型下根據容器的應用程式的相對可擴充套件性尚未得到證明。
協調市場
本文呈現了協調市場中設定管理的現狀，但我們沒有詳細介紹雲協調作為市場概念的角色，這足以保證其自身的研究。考慮到Docker本身只有幾年歷史，這裡陳述的事實可能很快就會成為歷史。但可能仍然成立的認識是：工作負載可能獨立於佈署它們的應用程式或其製造商的品牌進行管理。
協調今天是一個新的現實，幾年後，它可能仍然是一個新的現實。在容器技術持續發展的今天，我們需要保持開放的心態，擁抱變化，選擇最適合自身需求的協調策略。雖然沒有一種放諸四海而皆準的解決方案，但理解不同協調風格的優缺點，將幫助我們做出更明智的技術選擇。
容器協調與排程：現代基礎設施的關鍵能力
IT產業正經歷一場完美風暴，由三個重要趨勢交織而成：真正可程式化的基礎設施崛起（包括雲端、組態管理工具和容器技術）、適應性應用架構的發展（如微服務、大規模分散式訊息處理和事件驅動應用）以及新流程方法論的出現（如精實開發和DevOps）。
在這樣的變革浪潮中，為何容器協調和排程如此重要？這就像農業革命後成功的農民關心他們的牲畜在哪裡吃草一樣至關重要。
容許我用這個比喻：我們越來越被要求將基礎設施和應用視為「牲畜」而非「寵物」。對待牲畜，我們關心但不會過度依附。我們不會魯莽對待牲畜，我們希望它們在最好的土地上放牧，我們想定期將它們從擁擠或危險的牧場移開，如果它們生病了，我們希望有人照料它們還原健康。
在容器平台世界中，協調和排程框架正是為我們的應用「牲畜」執行這些角色。最優秀的應用「牧場主」能在資源利用最大化的同時，平衡系統上不斷變化的需求與容錯需求。
你在經營哪種類別的容器牧場？
目前，託管和佈署容器化應用的選擇非常廣泛。僅考慮現代雲端平台，我們可以將技術格局大致分為三類別：基礎設施即服務（IaaS）、容器即服務（CaaS）和平台即服務（PaaS）。根據佈署的應用類別，每個類別都有其固有的優勢和劣勢。雖然某些組織可能傾向於根據直覺、分析報告或現有供應商關係做出選擇，但這是一個需要認真評估的根本決策。
平台選擇會嚴重影響可以實施的協調和排程類別。以下表格嘗試提供對這三種類別的關鍵抽象層、控制平面和適用案例的洞察。
平台與服務比較
| 類別 | IaaS | CaaS / 容器服務 | PaaS |
|---|---|---|---|
| 描述 | 虛擬化計算資源（CPU、RAM、儲存、網路等），必須組裝並準備好佈署應用。 | 提供計算資源的抽象層，允許容器的佈署和協調。 | 提供計算基礎設施的抽象層，允許應用的佈署和協調。 |
| 關鍵抽象 | 計算資源 | 容器 | 應用 |
| 範例 | Amazon Web Services、Azure、DigitalOcean、Google Cloud Platform、IBM Cloud Infrastructure、VMware | CoreOS Tectonic、Docker Cloud、Google Container Engine (GKE)、HashiCorp Nomad、IBM Container Service、Joyent Triton、Mesosphere DCOS | AWS Elastic Beanstalk、Deis、Google App Engine、Heroku、IBM Bluemix、Pivotal Cloud Platform、Red Hat OpenShift |
| 應用排程 | 手動或透過組態管理(CM)工具。資源需求通常由基礎設施選擇和組態指定。容錯通常透過程式實作。 | 容器排程通常內建於平台，能力範圍從粗略到精細。資源需求以宣告式方式指定。容錯自動處理。 | 內建於平台。資源需求以宣告式方式指定。容錯自動處理。 |
| 服務發現 | 手動或透過Puppet、Chef或Ansible等CM工具。CM工具通常與Consul或ZooKeeper等分散式KV儲存結合用於服務發現。 | 從程式性指定（例如，使用Mesos、Registrator和srv_router）到宣告式指定（例如，在Kubernetes中使用服務和標籤）不等。 | 通常內建於平台，例如，服務發現作為「服務」提供。 |
| 資源設定（佈建） | 手動或透過Puppet、Chef或Ansible等CM工具。操作員決定資源設定和分配，以實作容錯和擴充套件方法。 | 通常內建於平台，演算法如bin-packing或spread可用於最大化利用率或容錯。容器例項的擴充套件可透過平台實作。 | 對使用者隱藏。成本通常根據資源設定/消耗。 |
| 資料儲存/中介軟體 | 通常是資料函式庫務(DBaaS)或自行託管。 | 通常根據IaaS的DBaaS，可能努力提供容器化資料函式庫 | 作為平台的一部分提供，例如服務代理。 |
| 典型使用情境 | 進行雲端遷移並將內部佈署VM和應用按原樣遷移的組織，或需要對資源組裝和分配進行更精細控制的組織。 | 已在開發雲原生應用的組織，希望擺脫IaaS的營運複雜性，但不想採用固執己見的PaaS生態系統。 | 從尋求降低維護平台基礎設施成本的初創公司，到尋求標準化和開發人員生產力的大型組織。 |
值得注意的是，「容器即服務」仍是一個備受爭議的領域。許多人認為我們傳統上稱為容器服務的也是一種容器即服務；然而，Docker提出了不同的解決方案標準，核心是要具備雲基礎設施不可知論的特性。玄貓認為這個產品類別的市場解釋仍有待澄清。
延續我們的農場比喻，我們可以將計算資源（CPU、記憶體、硬碟、網路等）視為應用牲畜放牧的土地。容器平台內協調和排程的角色是以最有效和高效的方式將應用比對到資源 — 牲畜比對到土地。乍看之下，有效比對應用與資源可能看起來不是特別具挑戰性，但最佳化資源使用的裝箱方法在計算上是一個NP難問題。當我們將這一事實與雲端基礎架構的易變和短暫性質結合時，我們肯定面臨著挑戰。
圈養容器化牲畜的策略
從IaaS建立容器化應用平台，就像買一塊光禿的土地並從頭開始建造自己的牧場 — 相當艱辛，但你擁有最大的控制權。利用CaaS就像買牧場，並僱用專業牧人建圍欄並引導牛群。這讓你能看到土地，宣告你的意圖，讓別人做出即時決策。將應用佈署到PaaS基本上是將你的牲畜託付給另一個農民。可以說，這讓你專注於真正重要的事情（購買和飼養最好的牲畜，迅速將牲畜帶到市場），但你可能無法看到牧場，也可能不總是同意另一個農民經營農場的方式。
實際案例：容器協調的現實世界應用
在我的工作中，我與多個客戶合作設計、構建和營運容器化應用和平台。以下部分享了兩個案例研究的細節，這些例子旨在展示建立這些協調堆積積疊所涉及的決策。
在Mesos和Google Cloud Platform上執行Spring Boot服務
在第一個客戶案例中，Apache Mesos是被實施的協調器。客戶希望混合長時間執行的容器化應用服務和根據Spark的批次資料處理。Mesos本質上是一個「資料中心核心」，它從基礎設施叢集中抽象出計算資源，並將這些資源提供給框架，如Mesosphere的Marathon（用於長時間執行的服務）、Chronos（用於批次作業）和Spark（用於資料處理工作負載）。
佈署和執行Mesos在操作上可能很複雜；然而，它已被Twitter、Airbnb和eBay等公司證明可以大規模工作，而與能夠混合工作負載並在整個資料中心排程應用是一個吸引人的提議。
Mesos是透過Ansible佈署和管理的，容器化應用透過Jenkins構建並佈署到Marathon框架中。服務發現由Consul、Registrator和srv_router的組合提供，服務重啟或重新分配（為了容錯）由Marathon提供。QA團隊能夠在Google Cloud Platform（GCP）中啟動個人Mesos平台例項，這有助於減少資源爭用來促進測試（這曾是個問題）。然而，我們學到了一些艱難的教訓，因為資源受限的個人環境與完整平台相比，工作負載排程方式不同。例如，在一台機器的叢集內執行多個Mesos框架常導致其中一個框架資源不足。
將微服務佈署到AWS上的Kubernetes
在這個專案中，Kubernetes透過Terraform和Ansible佈署到Amazon Web Services（AWS）上，主要目標是為開發者提供高於IaaS的抽象層，但無需全面投資PaaS。由於客戶/供應商限制，無法使用Google Container Engine（GKE）。可以說，絕大多陣列織最終都會建立某種形式的PaaS，因為典型開發團隊需要許多這些功能，例如測試、佈署、服務發現、儲存、資料函式庫和開發者社群便利化。因此，這個案例確實施了這些功能中的許多。
Kubernetes提供了名稱空間隔離，這對在同一叢集上執行多個測試和預發布佈署很有用。為了真正的隔離，使用了單獨的叢集。佈署透過整合Kubernetes API或kubectl CLI工具管理。我們使用了持續整合框架Jenkins，它也負責構建和測試應用服務。服務發現是開箱即用的，容錯能力也很好，提供了節點健康檢查和應用/容器級活性探測健康檢查。儲存和資料函式庫由底層IaaS層提供，開發模式透過版本控制系統（VCS）和內部維護良好的wiki分享和重用。
從牧場經驗中學到的教訓
本文的目的是提供選擇容器平台的意見，並根據你的需求，選擇相關的協調和排程機制。然而，這主要根據兩個客戶案例研究。還有許多其他產品組合和結果堆積積疊，從Docker Swarm與Mesos混合到專注於根據PaaS的雲協調構建（如IBM）都有。
以下是玄貓在實踐中獲得的一些關鍵經驗：
工具選擇
盡可能自動化，目標是節省時間、大規模重複性，以及減少基礎設施/設定的偏差。不鼓勵但允許手動干預，尤其是將這種新容器技術引入組織時。我們都知道不應該SSH進入生產主機，但保留這種進入方法作為最後手段可能是業務救星。
效能錯誤處理
語義錯誤（即「業務影響」錯誤）在雲和容器世界中比底層基礎設施故障更為重要。最終，即使你失去了一半的生產環境，只要系統能夠優雅降級與客戶仍能從應用中獲得價值，這都不是大問題。太多次我們看到營運團隊被基礎設施故障警示淹沒，但他們不知道實際導向使用者的影響。
選擇合適的容器協調策略
在評估容器協調解決方案時，玄貓建議考慮以下幾個關鍵因素：
應用特性與需求
應用的性質決定了最適合的協調策略。例如，有狀態應用與無狀態應用有著不同的需求。在我的實踐中，發現無狀態微服務通常更適合Kubernetes這類別平台，而有狀態應用可能需要特殊考慮，如使用永續性儲存區或專用節點。
團隊能力與學習曲線
不同協調平台有不同的學習曲線。Kubernetes功能全面但複雜，而Docker Swarm相對簡單但功能較少。評估團隊現有技能和學習新技術的能力是關鍵。在一個專案中，我們選擇了Kubernetes，儘管
容器即服務：橋接開發與營運的關鍵策略
在容器技術快速發展的今日，我們面臨了一個有趣的現象：開發團隊對容器技術的熱情有時與營運團隊的謹慎形成鮮明對比。開發者們熱衷於容器能夠加速佈署流程的能力，而系統管理員和營運人員則更關注支援容器化流程可能需要的大量內部系統重組工作。
這種差距催生了一個新興的服務模式：容器即服務（Containers as a Service, CaaS）。在我參與多個企業容器化轉型專案的經驗中，CaaS 模式已經證明能夠同時滿足這兩個群體的核心需求。
為何 CaaS 模式正在崛起？
容器即服務徹底改變了營運團隊對容器的認知方式。在大規模環境中，容器技術帶來了對新工具、服務和平台的需求。對大多數企業而言，管理建立在容器叢集上的複雜平台所需的專業知識往往是缺乏的。
根據我的觀察，容器技術的採用主要由開發人員推動，而與通常是獨立進行的。營運團隊對容器技術的接觸相對有限，不熟悉容器的工作原理和管理應用程式中心架構所需的工具。這導致了一個有趣的現象：開發人員出於必要開始自行管理這些環境。
CaaS 的價值在於它能夠抽象化建立大規模平台的複雜性。更重要的是，它意味著 IT 部門可以將其作為授權服務，並圍繞它實施所有必要的控制措施，如安全性和治理，不僅在本地資料中心提供服務，還可能跨越公共雲端。
CaaS 市場格局與服務定位
一個真正產品類別的誕生
2015 年以來，營運組織對如何最佳佈署和管理容器的興趣大幅增加。過去幾年中，許多雲端服務提供商開發了自己的 CaaS 平台。正如資深分析師 Janakiram MSV 所言，CaaS 正在成為新一代的平台即服務（PaaS）。
值得注意的是，容器即服務仍是一個有爭議的領域。許多人認為，傳統上所謂的容器服務也是一種廣義的 CaaS；然而，Docker 提出了一套不同的標準，其中核心是雲端基礎設施的不可知性。我認為，這個產品類別的更廣泛市場解釋仍有待進一步釐清。
CaaS 功能期望的分歧
在處理容器協調專案時，我注意到供應商和終端使用者對 CaaS 功能的期望存在顯著差異。根據 The New Stack 的調查，供應商和終端使用者對 CaaS 應包含哪些功能有不同看法：
- 容器協調：供應商 83%，終端使用者 54%
- 佈署和持續交付/整合：供應商 76%，終端使用者 44%
- 登入檔：供應商 68%，終端使用者 40%
- 雲端或 IaaS 協調：供應商 64%，終端使用者 38%
- 執行時期：供應商 55%，終端使用者 40%
- 建立映像檔：供應商 52%，終端使用者 35%
這種差異反映了市場對 CaaS 定義的不一致理解，也暗示了供應商可能正在推動更廣泛的功能集，而使用者則專注於更核心的需求。
主要 CaaS 平台技術解析
在過去幾年中，我深入研究了各大雲端供應商的 CaaS 產品，發現它們在技術實作上各有特色。以下是對主要 CaaS 解決方案的技術剖析：
Azure Container Service
微軟的 Azure Container Service 本質上是其自身資產與協調層之間的介面。它允許將區塊儲存、虛擬機器和其他資產對映到協調層。其目標是讓開發人員能夠像啟動「Linux 上的 HDInsight Hadoop 叢集」一樣簡單地從命令列啟動容器叢集。
Google Container Engine (GKE)
GKE 作為 Google Compute Engine 和 Kubernetes 之間的分隔層。它充當 Google Compute Engine 與 Kubernetes 支援的協調引擎之間的薄橋接層。GKE 根據使用者定義的需求（如 CPU 和記憶體）自動將容器排程到叢集中並管理它們。
GKE 的叢集由虛擬機器組成，這是相當常規的，因為大多數基礎設施都是虛擬機器池。其架構在 Kubernetes 系統上構建，提供了利用內部佈署、混合或公共雲端基礎設施的靈活性。
Amazon EC2 Container Service (ECS)
Amazon ECS 在 EC2 基礎設施即服務 (IaaS) 層上執行，提供託管容器服務。Amazon 的服務完全是專有的，支援 Docker 容器，並允許使用者在受管的 Amazon Elastic Compute Cloud (EC2) 例項叢集上執行應用程式。
透過簡單的 API 呼叫，您可以啟動和停止支援容器的應用程式，並瞭解叢集的狀態。Amazon ECS 可與其他 AWS 服務結合使用，並且可以利用熟悉的功能，如彈性負載平衡、EBS 磁碟區、EC2 安全群組和 IAM 角色。
IBM Containers on Bluemix
IBM 於 2015 年 6 月推出了 IBM Containers on Bluemix，提供了最早的託管 Docker 容器服務之一。Bluemix 是 IBM 的雲端平台，提供 PaaS、IaaS，現在還有 CaaS，為使用者提供多種選擇以滿足其需求。
使用 IBM Containers，使用者的 Docker 體驗從佈署容器開始，而不是佈署作為 Docker 主機的虛擬機器叢集。IBM Containers 允許管理員指定使用者配額，並確定可以從私有託管 Docker 登入檔佈署哪些映像。該服務還提供容器級別的整合監控和日誌記錄、覆寫網路、具有整合負載平衡和自動還原功能的可擴充套件群組、用於持久資料需求的儲存卷、對登入檔中每個 Docker 映像的內容和策略漏洞察，以及繫結到 Bluemix 目錄中任何 150 多種服務的能力。
Joyent Triton
Joyent 的 Triton 服務將容器視為原生物件，允許容器在裸機上執行，同時消除了虛擬機器抽象層，Joyent 技術長布萊恩·坎特里爾 (Bryan Cantrill) 稱之為「不必要的重層」。他在 The New Stack 的一篇文章中表示，挑戰在於用於容器的 Linux 基層（即名稱空間和 cgroups）並非設計用於多租戶，這會造成安全問題，使得在裸機上佈署 Linux 容器變得困難或不明智。
Triton 服務使用 Joyent 的 SmartOS 基層，該基層建立在 Sun Microsystems 在 Solaris 開放原始碼變體中完成的一些先前安全工作之上。
Rackspace Carina
Rackspace 推出的 Carina 是一種由 Rackspace 託管和管理的服務。Carina 的網頁式控制檯設計用於例項化和佈署可擴充套件的容器映像。在此之後，Rackspace 的管理員接管排程和協調的角色，根據需要擴充套件工作負載，並承擔所有維護責任。
Carina 使用開放容器計劃（Open Container Initiative），允許它吸收容器並遵循客戶關於如何佈署它們的指示，包括他們選擇裸機或根據虛擬機器的基礎設施。
OpenStack 的 Nova 排程器識別主機聚合，或設計與其他可用性區域分離的物理伺服器叢集。這些主機聚合內的伺服器可能是特定「風味」，這（理論上）使 OpenStack 上的 Windows 託管成為可能。它還允許容器託管。
在這些主機聚合叢集中，Magnum 將 Nova 例項池化成它所謂的海灣（bays）。這些個別海灣可以使用 Docker Swarm、Kubernetes 和 Mesos 進行協調。隨著 Carina 的發展，使用者將被允許選擇其協調引擎偏好。
Docker Datacenter (DDC)
2016 年初，Docker 發布了用於執行 CaaS 操作的軟體 Docker Datacenter (DDC)。它提供了一種佈署應用程式的方式，無需擔心將程式碼函式庫發環境移到生產環境可能產生的問題。這個整合包是用於佈署和管理容器的開放原始碼技術集合。
Docker 營運長 Scott Johnston 表示：「這不僅是認識到我們需要管理這些容器，還要提供一套產品來成功管理它們。」
應用程式正在推動這下一波浪潮，而營運部門希望支援它，而不是阻礙它。使用者需要能夠對計算、網路和儲存資源進行治理的產品，同時提供開發團隊正在生產的應用程式的靈活性、敏捷性和可攜性。
容器監控與資源爭用的實戰經驗
在管理大規模容器佈署時，監控和資源管理變得尤為關鍵。以下是我在多個容器專案中總結的一些關鍵實踐：
效能分析方法論
我發現 Brendan Gregg 的使用率、飽和度和錯誤（USE）以及 Tom Wilkie 的速率、錯誤和持續時間（RED）方法論在解決效能問題時非常有用。這些方法提供了系統性的框架來識別和解決效能瓶頸。
多層次監控策略
- 全方位可見性：必須在所有層級都有可見性。容器監控和管理是公司在生產環境中實施容器的主要關注點。
- 適當的應用程式檢測：只記錄必要的資訊，避免過度日誌記錄導致的效能影響。
- 業務級指標：這對推動關鍵利益相關者採用特別有用，在故障時也能提供很大幫助。
資源爭用管理
- 網路資源：確保在建立自己的平台時適當調整計算例項的大小。例如，您的應用程式可能只需要「小型」例項提供的 CPU 和記憶體，但您是否確認了相關的網路頻寬？
- 磁碟與 CPU 監控：在磁碟和 CPU 層級進行廣泛監控至關重要。對於 CPU，如果您佈署在公共雲上，請注意竊取時間（steal time）。
- 熵不足問題：在多個容器爭用主機 /dev/random 的環境中，熵不足是令人驚訝的常見問題。容器化應用程式通常會因為看似不明顯的原因而掛起，經過除錯後發現是安全操作（例如，工作階段或加密令牌生成）阻塞了它。
CaaS 與統一框架整合
在容器技術變得更加主流的同時，統一元件和跨系統與框架整合的需求也變得至關重要。Michael Hausenblas 在一次深度討論中強調，這不僅是關於整合這些元件，而是擁有一個有主見的分佈，能夠指向服務，說明應該如何設定它們，提取什麼資源，在哪些節點上執行等。
這種思維背後是 Mesosphere 資料中心作業系統（DCOS）的願景，以及其他元件如 Marathon 和 Chronos 如何融入整體架構。更進一步的主題還包括自我修復系統和大資料的融合，這些都是當前容器協調領域的
容器即服務市場崛起：整合開發與維運的未來
維運與開發團隊的新合作模式
在現代軟體交付過程中，維運團隊正從傳統的被動角色轉變為開發流程中的積極合作夥伴。這種轉變主要由應用程式開發團隊推動，雙方共同尋求更高效的協作方式。
以安全性為例，2016年開始出現更多對端對端安全解決方案的需求。玄貓觀察到，安全性不再是隻在生產環境中考慮的事項，而是必須從開發初期就納入考量的關鍵因素。如果等到應用程式準備佈署到生產環境時才考慮安全問題，這往往只能是一種修補或臨時解決方案。
容器安全與映像檔簽署
映像檔簽署技術成為早期吸引企業採用容器的關鍵功能之一。當容器化應用程式透過開發流程時，不同部門（如品質保證團隊）可以對其進行簽署，提供應用程式流轉路徑的完整追蹤記錄。
這種機制使維運團隊能夠做出即時決策——最終甚至可自動化這些決策——關於如何佈署應用程式。例如，某些包含敏感智慧財產權的容器必須保留在內部環境，而簡單的測試應用程式則可以佈署到公有雲。這種對安全性的早期考量是對未來堆積積疊效能的重要投資。正如業界工作者所言：「安全性是如何在流程初期進行工作能在下游帶來巨大效益的絕佳例子。」
CaaS為企業提供的價值
映像檔簽署只是容器即服務（CaaS）如何同時提供開發人員所需的敏捷性和維運人員所需控制力的一個例子。類別似的發展也出現在網路和儲存領域。
企業客戶普遍要求：「不要在應用程式從開發到品質保證再到生產的過程中破壞應用程式的完整性。讓我的應用程式保持其邏輯關係，同時根據不同階段替換實際實作方式。」這一需求正促使儲存和網路供應商開發實作外掛程式，並為應用程式視角下的網路和儲存API設計提供寶貴反饋。
容器生態系統的互操作性挑戰
容器技術面臨的真正挑戰在於解決周圍的混亂。容器採用的障礙包括技術堆積積疊各個部分中看似競爭的解決方案，許多人不理解這些元件如何相互競爭或互補。目前，互操作性往往被視為次要關注點。
因此，互操作性在2016年成為更大的關注焦點。業界急需定義這些解決方案如何介面，否則開發人員將無法在該整合層級以下進行創新。
這種對互操作性的關注並非某些希望提供下一個「魔法堆積積疊」作為單一解決方案的供應商想聽到的。玄貓和許多業界工作者認為，這種單一解決方案方法不太可行——協調和管理將需要多種工具的協作。正如一位工作者指出：「它將比人們想像的更加異質化、更加可組合、更具互操作性。」
CaaS市場的成熟與發展
容器即服務的市場引入及其不斷增長的使用者群體，代表了容器管理的成熟度提升，同時吸引了開發和維運團隊。這意味著企業採用容器的生命週期可能大幅縮短，不再需要在開發、維運和真正的生產使用之間緩慢爬行。提供容器服務允許預先封裝的安全性和治理，在本地資料中心和跨公有雲提供服務。
隨著這種新型產品和服務隨時間演進，使用者和供應商必須明確定義所期望的功能，並瞭解團隊的實際需求。在可互操作的套件中滿足功能需求將是整個協調市場未來的關鍵。
開放原始碼工具與民主化的網際網路
Docker的創始人Solomon Hykes談到了對程式設計技能和工具更廣泛公共存取的需求——這是他所稱的網際網路民主化的一部分。將網際網路作為分散式公共設施進行基礎建設有巨大潛力釋放創新。
Hykes表示，雖然科技產業在實作這些可存取性目標方面未能取得成功，但他相信Docker及其開發的工具是朝著正確方向邁出的一小步。他認為Docker建立了一種基礎技術，可能促成新的變革。他還討論了關於Docker在基礎架構中的角色的批評、Docker開發新工具的方法，以及尋找整合所有元件的通用框架。
自動化與協調
隨著容器技術的持續發展，自動化佈署和協調工具將在企業IT生態系統中扮演越來越重要的角色。這些工具不僅提高了開發效率，還增強了維運團隊對複雜系統的控制能力。
玄貓認為，未來幾年，我們將看到更多針對特定行業和使用場景的專業容器協調解決方案出現，同時基礎平台之間的互操作性將成為關鍵競爭因素。企業需要謹慎評估這些解決方案，確保它們能夠滿足當前需求，同時為未來技術演進提供靈活性。
容器技術已不再是實驗性質，而是企業數位轉型戰略中不可或缺的組成部分。那些能夠成功整合容器技術到其開發和維運流程中的組織，將在市場競爭中獲得顯著優勢。
