容器編排是指用於自動化、管理和調度由單個容器定義的工做負載的工具和平臺。這個領域有不少參與者，包括Hashicorp的Nomad、Apache Mesos、Amazon的ECS，還有別忘了Google本身開發的Borg項目（Kubernetes就是從這個項目演變而來的）。每種技術都有優缺點，但Kubernetes的日益流行和強大的社區支持代表，Kubernetes目前是容器編排之王。 前端
Kubernetes在使用開源軟件時具備明顯的優點。做爲一個開源平臺，它與雲無關，在它之上構建其餘開源軟件是有意義的。它還擁有超過40000名貢獻者，並且因爲許多開發人員已經熟悉Kubernetes，所以用戶更容易集成在K8s之上構建的開源解決方案。 web
把Kubernetes分解成模塊 後端
分解Kubernetes的最簡單方法是瞭解容器編排器的核心概念。容器用做基本的工做構建塊，而後在彼此之上構建組件以將系統鏈接在一塊兒。api
組件有兩種核心類型：工做負載管理器（託管和運行容器的方法）、集羣管理器（表明集羣作出決策的全局方法）。 安全
在Kubernetes中，這些角色由工做節點和管理工做（即Kubernetes組件）的控制平面完成。 服務器
管理工做負載 微信
Kubernetes工做節點有一個嵌套的組件層。在底層是容器自己。 網絡
從技術上講，容器運行在pods中，pods是Kubernetes集羣中的基本對象類型。如下是它們之間的關係： app
Pod：Pod定義應用程序的邏輯單元。它能夠包含一個或多個容器，每一個Pod部署到一個節點上。 運維
節點：這是做爲集羣中工做機的虛擬機；pods在節點上運行。
集羣：由工做節點組成，由控制平面管理。
每一個節點運行一個名爲kublet的代理（用於在pod中運行容器），並運行一個kube代理（用於管理網絡規則）。
管理集羣
工做節點管理容器，Kubernetes控制平面對集羣進行全局決策。
控制平面由幾個基本組件組成：
內存存儲（etcd）：這是全部集羣數據的後端存儲。雖然可使用不一樣的備份存儲運行Kubernetes集羣，但etcd（一個開源的分佈式鍵值存儲）是默認的。
調度器（kube調度器）：調度器負責將新建立的pod分配給適當的節點。
API前端（kube-apiserver）：這是一個網關，開發人員能夠經過它與Kubernetes交互，以部署服務、獲取指標、檢查日誌等。
控制器管理器（kube Controller manager）：監控集羣並進行必要的更改，以使集羣保持在所需的狀態，例如擴展節點、保持每一個複製控制器的正確pod數以及建立新的命名空間。
控制平面作出決策以確保集羣的正常運行，並將這些決策抽象出來，這樣開發人員就沒必要擔憂它們了。它的功能很是複雜，系統用戶須要瞭解的是控制平面的邏輯約束，而沒必要過於糾結於細節。
使用控制器和模板
集羣的組件決定了集羣如何管理本身，可是開發人員或（人工）運維人員怎麼告訴集羣如何運行軟件？這就是控制器和模板的來源。
控制器編排pod，K8s對於不一樣的用例有不一樣類型的控制器。但關鍵的是Jobs（用於運行到完成的一次性做業），以及ReplicaSets（用於運行指定的一組提供服務的相同pod）。
與Kubernetes中的其餘概念同樣，這些概念構成了更復雜系統的構建模塊，容許開發人員運行彈性服務。咱們鼓勵你使用Deployments，而不是直接使用ReplicaSets。
Deployments表明用戶管理ReplicaSets並容許滾動更新。Kubernetes Deployments確保只有一些pod在更新時關閉，從而容許零停機部署。一樣，CronJobs管理Jobs並用於運行調度好的和重複的進程。K8s的許多層容許更好的定製，可是Cronjob和Deployments足以知足大多數用例。
一旦知道要選擇哪一個控制器來運行服務，就須要使用模板配置它。
模板解析
Kubernetes模板是一個YAML文件，它定義了運行容器的參數。與任何一種配置即代碼同樣，它有本身的特定格式和要求，須要學習不少東西。所幸的是，你須要提供的信息與針對任何容器編排器運行代碼時所需的信息相同：
——告訴它應用程序的名稱
——告訴它在哪裏查找容器的鏡像（一般稱爲容器註冊表）
——告訴它要運行多少個實例（ReplicaSets的數量）
配置的靈活性是Kubernetes的衆多優勢之一。使用不一樣的資源和模板，還能夠提供有關如下集羣信息：環境變量、祕密的位置、應掛載以供容器使用的任何數據卷、每一個容器或pod容許使用多少CPU和內存、容器應運行的特定命令等。
把這一切結合起來
結合來自不一樣資源的模板，用戶能夠在Kubernetes中互操做組件，並根據它們的須要進行自定義。
在一個更大的生態系統中，開發人員利用Jobs、Services和Deployments（帶有ConfigMaps和Secrets），生成須要在部署過程當中精心編排的應用程序。
管理這些步驟能夠手動完成，也可使用一個經常使用的包管理選項來完成。雖然徹底能夠根據Kubernetes API進行本身的部署，但打包配置一般是一個好主意，特別是若是你要發佈的開源軟件多是由其餘人部署和管理的。
Kubernetes選擇的打包管理器是Helm。它容許你打包本身的軟件，以便在Kubernetes集羣上輕鬆安裝。
其實並不難
位於容器頂部的許多層和擴展可能使容器編排器難以理解。但一旦你把它們分解，搞清楚它們是如何相互做用的，其實並不複雜。就像一個真正的管絃樂隊同樣，你欣賞每一種樂器，喜歡它們的合奏。
原文連接：
https://opensource.com/article/20/6/container-orchestration
後臺回覆「加羣」，帶你進入高手如雲交流羣
推薦閱讀：
▼
喜歡，就給我一個「在看」
10T 技術資源大放送！包括但不限於：雲計算、虛擬化、微服務、大數據、網絡、Linux、Docker、Kubernetes、Python、Go、C/C++、Shell、PPT 等。在公衆號內回覆「1024」，便可免費獲取！！
本文分享自微信公衆號 - Linux雲計算網絡（cloud_dev）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。