一、通俗的理解編排

1. 編排是什么

編排這個詞，去搜 google 翻譯，推薦的是 Orchestration 這個單詞。但是你反過來搜 Orchestration 中文意思，它的翻譯是“管弦樂編曲”。在管弦樂曲里，要完成多種樂器之間的協調配合肯定需要一種方法，這種方法也叫編排。由此可感受到，有編排的場景存在多種組件事務，而且這些組件事務具有一定的獨立性。個人理解，編排是按照某種機制讓各種組件自動化配合運作，然后得到你想要的結果。

2. 編排與自動化

初學者經常會把自動化單純的理解為就是編排，其實這兩個概念是有區別的。編排更注重的是組建配合產生出良好的結果，而自動化更注重的是組件運行的方式和效率。但是在IT世界里，編排是離不開自動化的，沒有自動化的編排只是一種工作流，有了自動化的編排就能機動化的動起來。好比在生產車間里，每個環節如果都是靠人來運作，雖然每個工人一絲不茍很、按部就班，但是這僅僅也是體現個工作流的完美，沒有體現出高效，這樣的編排沒有靈魂。編排它會穿越你的整個 IT 環境。例如橫穿你的 web 服務器，數據庫，中間件，負載平衡器等。這里涉及到多個層次，不同的技術領域，IT管理者需要站在一個高緯度去認識你的生產系統，設計出一套復雜的編排機制。有些陳舊的系統和技術債，可能讓你寸步難行。

3. 編排意義

有些人或許會疑問，編排的意義在哪？它能帶來什么收益？通過上面兩點的講解，編排或許可以理解為一種IT工作流，它能把你負責的IT系統都串接起來，然后自動化運作。這很容易讓你想到如果真這么做到了，那不是一勞永逸？如果是輸入和輸出要求都不變的情況下或許真的能一勞永逸。但是現實的情況往往不是這樣。公司的業務更新迭代，IT支撐環境也是會不停的更新迭代，沒有一種IT環境能一直保持不變的支撐下去。但是，編排的思想卻是貫徹著整個IT階段發展，每一個發展階段都有不一樣的編排思路。物理機時代，人們用人肉運維“編排”（搬、挪）物理機；虛擬機時代，人們用腳本、CMDB、openstack heat 等“編排”虛擬機；最新容器時代，人們用 K8S、微服務編排容器。套用網上一句話：編排旨在簡化并優化重復性的頻發流程，以確保準確、快速的軟件部署。因為企業知道產品上市速度越快、成功幾率越大。只要流程是重復性的，便可通過自動執行相關任務來優化該流程，以消除重復操作。

?二、K8S 與編排

1. 實現完美編排的先決條件

其實編排的對象越“原子”、越輕量那么對于編排的操作就更加的靈活。前面提到，業務會隨時改變，那么支撐的生產系統也需要隨之變化。如果編排的工作流程組件耦合度太高，那么變更就很困難。想想我們過去沒有虛擬化的時代，應用直接跑在物理機里，那么應用的安裝、遷移都會顯得費勁。到了虛擬機時代，會簡單很多，但是虛擬機本身還是顯得有些重，遷移也受底層硬件條件的影響。可幸的是，容器時代這些問題得到了很好的解決，我們直接能操作“進程”了，通過容器我們能輕松部署、遷移、交付... 容器真是為良好的編排打好了基礎。

在當前云原生時代，應用一般由單獨容器化的組件（通常稱為微服務）組成，且必須按順序在網絡級別進行組織，以使其能夠按照計劃運行。以這種方法對多個容器進行組織的流程即稱為容器編排。在現代開發當中，整體式的應用早已成為過去時，如今的應用由數十乃至數百個松散結合的容器式組件構成，而這些組件需要通過相互間的協同合作，才能使既定的應用按照設計運作。容器編排是指對單獨組件和應用層的工作進行組織的流程。雖然諸如 Apache Mesos、Google Kubernetes 以及 Docker Swarm 等平臺均有其特定的容器管理方法，但所有的容器編排引擎均可讓用戶控制容器啟動和停止的時間、將其分組合到群集中，以及協調應用組合的流程。容器編排工具允許用戶指導容器部署與自動更新、運行狀況監控以及故障轉移等步驟。

2. K8S 如何實現編排

K8S 是容器資源管理、調度平臺，換句話說它就是容器資源的編排系統。那么容器編排都有哪些動作和流程呢？總體來講有六大部分：

• 資源調度
• 資源管理
• 服務發現
• 健康檢查
• 自動伸縮
• 更新升級

資源調度

在分布式系統里，資源的調度是非常重要的，K8S 是通過 scheduler 組件來對 Pod 進行調度的。Scheduler 調度器做為 K8S 的三大核心組件之一， 承載著整個集群資源的調度功能，其根據特定調度算法和策略，將 Pod 調度到最優工作節點上，從而更合理與充分的利用集群計算資源，使資源更好的服務于業務服務的需求。資源的調度是一套分布式系統最基本的核心指標。設想，如果連資源都無法調度好，那么上層的服務將沒法玩。

資源管理

資源，一般分為計算資源、網絡資源、存儲資源。計算資源通常是 CPU、MEM（當然現在還有 GPU 資源），對于這塊 K8S 通過可壓縮和不可壓縮的機制來做區分，這里 CPU 資源是可壓縮的，內存是不可壓縮的。這里 K8S 主要是通過 Requests 和 Limits 參數來靈活控制 Pod 對資源的使用。

服務發現

所有資源的分配、支撐都是為了跑服務。由于 Pod 的 IP 不是固定的，所以外在的程序或者內部的程序如何訪問 K8S 里面的某個 Pod，肯定需要一種固定的訪問方式，那么這種方式叫做 service。所有創建的服務只有輕松簡單地被發現、被訪問，這樣才能更加的高效。

健康檢查

計算機世界里沒有任何一種服務能一直保持正常運行（如果有，那真是太牛了！）。所以，總有各種內在、外在因素影響著服務的穩定運行。那么監控檢測服務是否正常運行非常重要，在 K8S 里一般用 liveness 和 readiness 探針機制來做健康檢查（前面文章也有提到過探針的用法）。

自動伸縮

在運維環境里，資源的擴容和管理是比較頭疼的一件事。工程師一般會比較難的精確把握業務需要多少資源，多了少了都會一定的影響成本和平臺的穩定性。所以，假如有套機制能根據當前的負載高低，動態的、精準的擴容資源那么對工程師來說是一個很大的福音。虛擬機時代之前，這個都非常難實現，因為涉及到環境的快速遷移和復制。容器化時代很自然的解決了這個問題，K8S 里使用 Horizontal Pod Autoscaling（Pod 橫向擴容機制）來保證資源的按需擴容。

更新升級

程序會隨著業務的發展而不斷的迭代，所以我們都會架設一套完整的 CICD 來完善程序的發布、更新機制。K8S 目前在 CICD 里占了很重要的角色（如圖）。另外，K8S 的內部控制器 ReplicationController 與 Deployment 也為服務的滾動和平滑升級提供了很好的機制。這樣實現什么藍綠發布，K8S 可以協助輕松做到。

?

總結

以上是生活随笔為你收集整理的Kubernetes 学习总结（34）—— 如何理解编排的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。