雲的發展

之前的文章提到了雲與基礎設施的演進過程，也說了雲原生帶給團隊和公司的益處；軟件基礎設施也隨着軟件開發方式和架構模式的改變而改變。他們說不清楚是誰促進了誰，而且這並不重要。雲的發展從剛開始提出的以虛擬化爲基礎實現的雲到現在常見的以容器爲基礎的雲再到馬上要來的無服務器化（serverless），不難看出基礎設施也是一直不斷髮展的，我們不能無視時代的發展而閉門造車。所以我們需要了解現在的環境，反思自身的問題，有需要則要想法子用上，讓自己搭上更快的車不是很好嗎？

雲原生的核心概念

顧名思義，雲原生由兩部分組成 “雲” 和“原生”，“雲”指的是把軟件遷移到雲上，“原生”指的是軟件像 “原生” 運行在雲端一樣。這句話分兩部分：
“雲” 指的是基礎設施換成雲環境，具體就是從裸金屬服務器或者虛擬化主機換成基於容器的雲端平臺。這個很好理解，不做過多解釋，就是以前的軟件運行在裸金屬服務器上或者虛擬機上，現在都運行在通過編排管理的容器上。
“原生” 比較難理解，我們的應用遷移到雲原生平臺後是要改造的，不能（不合適，其實是可以直接遷移上去的）直接把原來的龐大的大單體應用一股腦放到一個容器中運行。而是需要對已有的軟件做一定的改造再放到雲原生平臺，當然改造需要成本，但肯定會有收益促進我們這麼改造。

主要組成部分

這個章節主要介紹一下雲原生的發展過程和重要組成部分，這個章節稍微涉及一些技術方向的東西，看不明白也沒關係，知道個大概就行了。現在的雲原生是一套基於容器的綜合基礎設施和開發模式的系統。它不再是單純的提供一套基礎設施，而是深入到軟件的開發和設計的全流程的一套方案。除了軟件本身需要改造以適應雲原生，甚至你的團隊也需要改變工作方式以適應雲原生環境。它從基於運維團隊的容器平臺，發展到現在的複雜系統是經過了一個長期的過程的，所以我們從容器開始介紹雲原生的重要組成部分：容器和基於容器的服務編排。

容器

容器是雲原生基礎設施的基礎，說起容器不得不說 Docker。一開始 Docker 是作爲開發人員和運維人員在開發軟件的過程中用來實現部署測試環境和其他開發工作環境（devops）使用的玩具，現在已經成熟到足夠在生產環境中了。要說起 Docker 就不得不說起跟他對比的虛擬化技術，因爲整個雲端環境就是由虛擬化發展到容器化的，而且虛擬化也接近婦孺皆知了，所以從虛擬化開始講容器比較容易，我儘量不提容器是基於多用戶操作系統 Linux，也不提 Linux 的 NameSpace、CGroup、AUFS 和 Device Mapper 等基礎技術，有技術實力的你儘量去看看其他文章介紹這些技術的細節，不想了解也沒關係，你只需知道容器是一個在 Linux 操作系統上運行的一個隔離技術就行了。以下通過圖示展示容器和虛擬機的不同之處。

從上面的比較我們可以看出，VM 多了兩層：GuestOS 和 Hypervisor，它們會佔用更多的資源來部署服務。容器中的所有服務都是運行在宿主操作系統上，它沒有自己的操作系統隔離，容器裏的服務是直接運行在宿主操作系統上，它用一種更輕量級的方式來運行服務進程。簡單說來相對虛擬機，容器有以下幾個好處：

更高效地利用系統資源

容器不需要進行硬件虛擬以及運行完整操作系統等額外開銷，Docker 對系統資源的利用率更高。無論是應用執行速度、內存損耗或者文件存儲速度，都要比傳統虛擬機技術更高效。因此，相比虛擬機技術，一個相同配置的物理主機，能運行的容器遠大於虛擬機的數量。

更快速的啓動時間

傳統的虛擬機技術啓動應用服務拉起時間往往需要數分鐘，而 Docker 容器應用，由於直接運行於宿主內核，無需啓動完整的操作系統，因此可以做到秒級、甚至毫秒級的啓動時間。大大地節約了開發、測試、部署的時間。

一致的運行環境

開發過程中一個常見的問題是環境一致性問題。由於開發環境、測試環境、生產環境不一致，導致有些 bug 並未在開發過程中被發現。而 Docker 的鏡像提供了除內核外完整的運行時環境，確保了應用運行環境一致性，從而不會再出現程序員對測試人員說 “在我這裏運行的好好的呀？” 這類問題。

持續交付和部署

對開發和運維（DevOps）人員來說，最希望的就是一次創建或配置，可以在任意地方正常運行。使用 Docker 可以通過定製應用鏡像來實現持續集成、持續交付、部署。開發人員可以通過 Dockerfile 來進行鏡像構建，並結合 持續集成 (Continuous Integration) 系統進行集成測試，而運維人員則可以直接在生產環境中快速部署該鏡像，甚至結合 持續部署 (Continuous Delivery/Deployment) 系統進行自動部署。而且使用 Dockerfile 使鏡像構建透明化，不僅僅開發團隊可以理解應用運行環境，也方便運維團隊理解應用運行所需條件，幫助更好的生產環境中部署該鏡像。

更輕鬆地遷移

由於 Docker 確保了執行環境的一致性，使得應用的遷移更加容易。Docker 可以在很多平臺上運行，無論是物理機、虛擬機、公有云、私有云，甚至是筆記本，其運行結果是一致的。因此用戶可以很輕易地將在一個平臺上運行的應用，遷移到另一個平臺上，而不用擔心運行環境的變化導致應用無法正常運行的情況。

更輕鬆的維護和擴展

Docker 使用的分層存儲以及鏡像的技術，使得應用重複部分的複用更爲容易，也使得應用的維護更新更加簡單，基於基礎鏡像進一步擴展鏡像也變得非常簡單。此外，Docker 團隊同各個開源項目團隊一起維護了一大批高質量的 官方鏡像，既可以直接在生產環境使用，又可以作爲基礎進一步定製，大大降低了應用服務的鏡像製作成本。

容器技術對比傳統虛擬機總結

YB4U4h

做了那麼多對比，你只需要知道它和虛擬機不一樣，沒有宿主操作系統就比擁有操作系統動輒好幾 G 幾十 G 的虛擬機更小，更小就能更快的拉起，幾十毫秒拉起一個服務比幾分鐘啓動一個虛擬機那是本質的不同。有了快速拉起的容器就可以在容器的基礎上實現容器的編排，對容器本身和它其中運行的服務管理起來，那就是服務編排了。

Kubernetes

Kubernetes 是在 Google 平臺上開發的開源容器管理軟件。它可以幫助您在各種類型的物理、虛擬和雲環境中管理容器化應用程序。
它是一種高度靈活的容器工具，甚至可以交付複雜的應用程序。應用程序 “在由成百上千臺單獨服務器組成的集羣上運行。” 它還允許您更有效地管理容器化應用程序。
作爲最著名的服務編排工具，Kubernetes 主要的作用當然就是服務編排了。它主要功能是：
服務發現和負載均衡
Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器，如果進入容器的流量很大， Kubernetes 可以負載均衡並分配網絡流量，從而使部署穩定。
存儲編排
Kubernetes 允許你自動掛載你選擇的存儲系統，例如本地存儲、公共雲提供商等。
自動部署和回滾
你可以使用 Kubernetes 描述已部署容器的所需狀態，它可以以受控的速率將實際狀態 更改爲期望狀態。例如，你可以自動化 Kubernetes 來爲你的部署創建新容器， 刪除現有容器並將它們的所有資源用於新容器。
自動完成裝箱計算
Kubernetes 允許你指定每個容器所需 CPU 和內存（RAM）。當容器指定了資源請求時，Kubernetes 可以做出更好的決策來管理容器的資源。
自我修復
Kubernetes 重新啓動失敗的容器、替換容器、殺死不響應用戶定義的 運行狀況檢查的容器，並且在準備好服務之前不將其通告給客戶端。
密鑰與配置管理
Kubernetes 允許你存儲和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。你可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置，也無需在堆棧配置中暴露密鑰。

Kubernetes 的結構說明

從上圖可以看出來，整體的 Kubernetes 分爲兩大部分：主控節點和工作節點。其中主控節點和工作節點都是多個，我爲了方便說明結構只畫了一個主控節點和 2 個工作節點。

主控節點

Kubernetes 裏的主控節點指的是集羣控制節點，每個 Kubernetes 集羣裏需要有一個主控節點來負責整個集羣的管理和控制，基本上 Kubernetes 所有的控制命令都是發給它，它來負責具體的執行過程，我們後面所有執行的命令基本都是在 Master 節點上運行的。Master 節點通常會佔據一個獨立的 X86 服務器（或者一個虛擬機），一個主要的原因是它太重要了，它是整個集羣的 “首腦”，如果它宕機或者不可用，那麼我們所有的控制命令都將失效。以下簡單介紹一下主控節點的幾個重要組成部分：
主控節點中有好多個組件來編排管理容器：Etcd 用於存儲集羣中所有資源對象的數據；API Server 用於組件之間的通信，Scheduler 決定 pod 應該在哪些節點上運行，它就像公交公司的 “調度室”；而 Controller Manager 則是所有資源對象的自動化控制中心，它是資源對象的 “大總管”

工作節點

工作節點構成了 Kubernetes 集羣的集體計算能力。這是容器實際部署運行的地方。節點是你的應用程序運行的物理基礎設施。當它宕機或者因其他原因不可用的時候，主控節點會把它上面運行的工作負載自動遷移到別的工作節點上去。每個工作節點除了運行工作負載也同時運行着以下兩個重要的組成部分：
kubelet：負責 Pod 對應的容器的創建、啓停等任務，同時與 Master 節點密切協作，實現集羣管理的基本功能。
kube-proxy：實現 Kubernetes Service 的通信與負載均衡機制的重要組件。kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集羣內部或外部的網絡會話與 Pod 進行網絡通信。如果操作系統提供了數據包過濾層並可用的話，kube-proxy 會通過它來實現網絡規則。否則， kube-proxy 僅轉發流量本身。
當然同時工作節點中還運行着 Pod，Pod 是 Kubernetes 集羣中最低級別的資源。一個 Pod 由一個或多個容器組成，但最常見的只是一個容器。在定義集羣時，會爲 Pod 設置限制，這些限制定義了它們需要運行的資源、CPU 和內存，Scheduler 通過這個定義來決定把 Pod 放到哪個工作節點上。

總結

你看以上的容器和基於容器的服務編排系統，就幾乎解決了雲原生中的絕大多數問題，你有了一個整體的服務運行平臺，你能在上面運行你的服務，它會自動保證你的服務正確的運行，出錯了它會想辦法再讓它運行起來，你可以通過資源定義保證你某個服務的算力要求等。你還能通過它管理除：CPU、內存、存儲以外的資源，例如：配置和網絡等。

雲原生的其他組成部分

雲原生除了提供服務運行的基礎環境以外，同時雲原生也是一個團隊和基礎設施共同協作的平臺，你不能僅僅使用整個平臺上的基礎設施，而團隊的工作方式還是老樣子。整個其他組成部分就是除基礎設施以外的其他部件。

微服務

前面兩章說了一大堆微服務改造的必要性，這一章我就不詳細說了，請自己參考前兩章內容。

持續交付

爲了滿足業務需求頻繁變動和快速迭代，軟件產品要擁有能隨時能發佈的能力，這也是持續支付的開發實踐方法。它可分爲持續集成、持續部署、持續發佈等階段，用來保證從需求提出到設計開發和測試，再到代碼快速、安全部署到產品環境中。持續集成是指每當開發人員提交一次變動，就立刻進行構建、自動化測試，確保業務應用和服務能符合預期，從而可以確定新代碼和原有代碼能否正確地集成在一起。持續交付是軟件發佈能力，是在持續集成完成之後，達到能夠將系統發佈到生產環境的條件。持續部署是指使用完全的自動化過程來把每個變更自動提交到測試環境，然後將應用安全部署到產品環境，打通開發、測試、生產的各個環節，自動持續、增量地交付產品，也是大量產品追求的最終目的。當然，在實際運行過程中，有些產品會增加灰度發佈等環境。總之，它更多是代表一種軟件交付的能力。

DevOps 組件

DevOps 如果從字面上來理解只是 Dev（開發人員）+Ops（運維人員），實際上它是一組過程、方法與系統的統稱，其概念從 2009 年首次提出發展到現在，內容非常豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不同方面：①組織架構、企業文化與理念等，需要自上而下設計，用於促進開發部門、運維部門和質量保障部門之間的溝通、協作與整合，簡單而言組織形式類似於系統分層設計；②自動是指所有的操作都不需要人工參與，全部依賴系統自動完成，比如上述的持續交付過程必須自動化纔有可能完成快速迭代；③DevOps 的起因是 IT 行業漸漸意識到，如果要準時交付軟件產品或者服務，開發部、運維部必須緊密合作。總之，DevOps 提倡的是高效組織團隊之間的合作，通過自動化軟件協作，完成軟件的生命週期管理，目的是迅速頻繁地交付應用軟件。

監控和運維

這一部分內容會在後面詳細說，你只需要知道除了以上的必要部件，監控和運維繫統也是必須的，而且雲原生的監控和運維還和傳統的不太一樣。它在內容上除了要對平臺層運維和監控以外，也需要對運行在其上的服務進行運維和監控。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/hiJdkb5hioUvKEPmcFfRNw