我們已經進入雲計算下半場，不再像上半場在糾結要不要上雲，而是讨論怎麼上雲？才能把雲計算的價值發揮到淋漓盡緻。如何把雲計算與不同的業務場景深度結合？如何讓技術真正作用于企業？如何節省企業IT部署成本？

誰也不知道答案，直到“雲原生”來了。

雲原生是什麼？這個衆說紛纭，沒有統一的定義，姑且以老大哥CNCF的定義來了解雲原生。

老大哥？CNCF？

CNCF，全稱為Cloud Native Computing Foundation，中文譯為“雲原生計算基金會”。成立于2015年12月11日，CNCF是Linux基金會旗下的基金會。CNCF緻力于培育和維護一個廠商中立的開源生态系統，來推廣雲原生技術。CNCF是雲原生領域影響力最大最有話語權的組織。

說起CNCF的故事，還要從Cgroups（control groups，控制組群）開始說起，時間軸回到16年前。

2004年，谷歌開始使用容器技術，于2006年發布了Cgroups,最初叫Process Container（進程容器）。

Process Container的目的非常直白，它希望能夠像虛拟化技術那樣給進程提供操作系統級别的資源限制、優先級控制、資源審計能力和進程控制能力。帶着這樣的設計思路，Process Container在2006年由Google的工程師正式推出後，第二年就進入了Linux内核主幹。

因為在Linux内核中，容器（container）這個名詞有許多不同的意義，為避免混亂，就更名為Control Groups，也就是Cgroups。

2013 年，Docker 項目正式發布，2014 年，K8s項目也正式發布。

原因非常容易理解，因為有了容器和 Docker 之後，就需要有一種方式去幫助大家方便、快速、優雅地管理這些容器，這就是K8s項目的初衷。

K8s是雲原生的基石，後面會細講。在 Google 和 Redhat 發布了K8s 之後，這個項目的發展速度非常之快。

2015 年，由Google、Redhat 以及微軟等大型雲計算廠商以及一些開源公司共同牽頭成立了 CNCF 雲原生基金會。CNCF成立之初，就有22個創始會員，而且K8s也成為了 CNCF 托管的第一個開源項目。

在這之後，CNCF 迅猛發展。截止2020年2月，從官網看到數據顯示有433個會員。

那麼CNCF是如何定義雲原生的呢？

翻譯為中文：

雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。 這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。 雲原生計算基金會（CNCF）緻力于培育和維護一個廠商中立的開源生态系統，來推廣雲原生技術。我們通過将最前沿的模式民主化，讓這些創新為大衆所用。

除了CNCF關于雲原生的定義，網絡上流傳的另一個版本是Pivotal 公司的 Matt Stine于2013年首次提出雲原生概念；2015年，雲原生剛推廣時，Matt Stine在《遷移到雲原生架構》一書中定義了符合雲原生架構的幾個特征：12因素、微服務、自敏捷架構、基于API 協作、扛脆弱性。

到了2017年，Matt Stine 改了口風，将雲原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質；而Pivotal 官網對雲原生概括為4個要點：DevOps 持續交付 微服務 容器。

雲原生所需能力與特征 by:CNCF大使 宋淨超

MattStine認為雲原生它是一個思想的集合，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等。

雲原生即包含技術（微服務，敏捷基礎設施），也包含管理（DevOps，持續交付，康威定律，重組等）。雲原生也可以說是一系列雲技術、企業管理方法的集合。

我們以CNCF官方的定義來接着了解。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。那麼這些技術都是什麼？這些技術有什麼聯系？

容器

一般我們說的“容器”（LinuxContainer，LXC），都是“Linux容器”（當然微軟也在搞容器，但還沒linux那麼成熟）。開源解決方案供應商紅帽官網給出的容器定義：

Linux® 容器是與系統其他部分隔離開的一系列進程。運行這些進程所需的所有文件都由另一個鏡像提供，這意味着從開發到測試再到生産的整個過程中，Linux 容器都具有可移植性和一緻性。因而，相對于依賴重複傳統測試環境的開發渠道，容器的運行速度要快得多。容器比較普遍也易于使用，因此也成了 IT 安全方面的重要組成部分。

容器提供進程級的隔離，可以将操作系統管理的資源劃分到相互隔離的組中，在相互隔離的組之間解決資源使用存在沖突的問題。比如應用程序（Application，APP ）APP 1 隻能在centos 操作系統上運行，APP2隻能在ubuntu操作系統上運行，而同一個操作系統同時運行APP1和APP2就産生沖突，容器技術則恰恰可以解決這類問題。目前主流的容器技術有Docker、LXD以及RKT等。

Docker

說到容器，就不得不說Docker。

2010年，幾個大胡子的年輕人在美國舊金山成立了一家名叫“dotCloud”的公司。這家公司主要提供基于PaaS的雲計算技術服務。具體來說，是和LXC有關的容器技術。LXC，就是Linux容器虛拟技術（Linux container）

後來，dotCloud公司将自己的容器技術進行了簡化和标準化，并命名為——Docker。

Docker項目發布時，無非也是LXC的一個使用者，它創建和使用應用容器的邏輯跟Warden等競争對手沒有本質不同。不過，我們現在也知道，真正讓PaaS項目無所适從的，是Docker項目最厲害的殺手锏：容器鏡像。

Docker項目通過容器鏡像，直接将一個應用運行所需的完整環境，即：整個操作系統的文件系統也打包了進去。這種思路，可算是解決了困擾PaaS用戶已久的一緻性問題，制作一個“一次發布、随處運行”的Docker鏡像的意義，一下子就比制作一個連開發和測試環境都無法統一的Buildpack高明了太多。

Docker項目大大降低了容器技術的使用門檻，輕量級，可移植，虛拟化，語言無關，寫了程序扔上去做成鏡像可以随處部署和運行，開發、測試和生産環境徹底統一了，還能進行資源管控和虛拟化。

Docker作為一種開源應用容器引擎，是為開發人員和系統管理員設計的用于構建、發布和運行分布式應用的平台，典型的Docker平台kubernetes、Openshift V3、Flynn、Deis等。

Docker允許開發人員将各種應用以及依賴包打包到一個可移植的Docker容器中，以Docker容器為資源分割和調度的基本單位，封裝整個軟件運行時的環境，然後發布到Linux機器上。

Docker設計原理如上圖所示。按照Docker的設計方案，應用軟件的交付過程如同海上運輸，操作系統OS如同一個貨輪，每一個在OS基礎上的軟件都如同一個集裝箱，用戶可以通過标準化手段自由組裝運行環境，同時集裝箱的内容可以由用戶自定義，也可以由專業人員（開發人員或系統管理員）定制，如此一來，交付一個應用軟件産品，就相當于交付一系列标準化組件的集合。

一句話解釋Docker?

沒有集裝箱就沒有全球化，Docker就是IT世界裡的集裝箱。

有了容器，就需要編排管理容器的生命周期，kubernetes要了解一下。

Kubernetes

說一下kubernetes，kubernetes一度被大家稱為雲原生的基石。

K8s,全稱是Kubernetes。這個單詞來自于希臘語，含義是舵手或領航員。K8s是它的縮寫，用“8”字替代了“ubernete”這8個字符。

K8s并不是一件全新的發明。它是谷歌根據其内部使用的 Borg 改造成的一個通用容器編排調度器，于2014年6月開源，同年7月，微軟、Red Hat、IBM、Docker等公司，相繼加入K8s。2015年，谷歌将其捐贈給 Linux 基金會下屬的雲原生計算基金會（CNCF），K8s也成為CNCF第一個項目。

K8s的架構，略微有一點複雜，我們簡單來看一下。

一個K8s系統，通常稱為一個K8s集群（Cluster）。這個集群主要包括兩個部分：一個Master節點（主節點）和一群Node節點（計算節點）。

列舉下一些專用術語的解釋。

Master（主節點）：控制 K8s 節點的機器，也是創建作業任務的地方。

Node（節點）：這些機器在 K8s 主節點的控制下執行被分配的任務。

Pod：由一個或多個容器構成的集合，作為一個整體被部署到一個單一節點。同一個 pod 中的容器共享 IP 地址、進程間通訊（IPC）、主機名以及其它資源。Pod 将底層容器的網絡和存儲抽象出來，使得集群内的容器遷移更為便捷。

Replicationcontroller（複制控制器）：控制一個 pod 在集群上運行的實例數量。

Service（服務）：将服務内容與具體的 pod 分離。Kubernetes服務代理負責自動将服務請求分發到正确的 pod 處，不管 pod 移動到集群中的什麼位置，甚至可以被替換掉。

Kubelet：這個守護進程運行在各個工作節點上，負責獲取容器列表，保證被聲明的容器已經啟動并且正常運行。kubectl： 這是 Kubernetes 的命令行配置工具。

理解完K8s 部分專業術語，就大緻對K8s有個了解了。

雲可以為我們提供穩定而唾手可得的基礎設施，但是業務上雲成了一個難題，K8s 的出現與其說是從最初的容器編排解決方案開始，倒不如說是為了解決應用上雲（即雲原生應用）這個難題。

CNCF 中托管的一系列項目即緻力于雲原生應用整個生命周期的管理，從部署平台、日志收集、Service Mesh（服務網格）、服務發現、分布式追蹤、監控以及安全等各個領域通過開源軟件為我們提供一整套解決方案。

Google 通過将雲應用進行抽象簡化出的 Kubernetes 中的各種概念對象，如Pod、Deployment、Job、StatefulSet 等，形成了Cloud Native 應用的通用可移植的模型，Kubernetes 作為雲應用的部署标準，直接面向業務應用，大大提高了雲應用的可移植性，解決雲廠商鎖定的問題，讓雲應用可以在誇雲之間無縫遷移，甚至用來管理混合雲，成為企業 IT 雲平台的新标準。

微服務

在介紹微服務時，首先得先理解什麼是微服務，顧名思義，微服務得從兩個方面去理解，什麼是"微"、什麼是"服務"，微 狹義來講就是體積小、著名的 "2 pizza 團隊" 很好的诠釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來隻需要2個披薩就夠了）。

而所謂服務，一定要區别于系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。

傳統的單體架構是以整個系統為單位進行部署，而微服務則是以每一個獨立組件（例如用戶服務，商品服務）為單位進行部署。對于單體應用，如果發現某一業務的請求量非常大，那麼是無法單獨擴展該業務的，隻能拷貝整個單體應用，再部署一套環境，來實現集群。正因為單體應用的缺陷，才有了微服務。

微服務和單體應用的區别，可以用Martin Fowler的這張圖來解釋：

圖中左邊是單體架構的集群，右邊是微服務集群。

什麼意思呢？比如根據每個服務的吞吐量不同，支付服務需要部署20台機器，用戶服務需要部署30台機器，而商品服務隻需要部署10台機器。這種靈活部署隻有微服務架構才能實現。

而近幾年流行的Docker，為微服務架構提供了有效的容器。

服務網格

服務網格( Service Mesh )是指用以處理服務與服務之間通信的基礎設施層。其最早由Buoyant公司（開發Service Mesh項目Linkerd的公司）提出，并在内部使用。該公司2016年9月29日第一次公開使用這個術語。

Service Mesh一般用于微服務應用的可配置基礎架構層( configurable infrastructure layer )。Istio( 由Google、IBM、Lyft公司在背後進行支持 ) 是目前最廣為人知的一款服務網格架構。

Kubernetes(由Google最早進行設計并開源)是目前Istio唯一支持的容器組織框架。

為什麼Service Mesh這麼受歡迎？對許多公司來說，Docker 和 Kubernetes 這樣的工具已經 "解決了部署問題"，或者說幾乎解決了。但他們還沒有解決運行時的問題，這就是服務網格的由來。

什麼是解決了部署問題？使用 Docker 和 Kubernetes 等功能可顯著減輕部署的增量操作負擔。使用這些工具，部署100個應用或服務不再是部署單個應用的100倍。這是向前邁出的一大步，對許多公司來說，這導緻采用微服務的成本大幅降低。這不僅是因為 Docker 和 Kubernetes 所提供了強大的抽象，而且還因為它們使整個組織的打包和部署模式過程标準化了。

Service Mesh的出現，彌補了Kubernetes在微服務的連接、管理和監控方面的短闆，為Kubernetes提供更好的應用和服務管理。因此，Service Mesh的代表Istio一經推出，就被認為是可以和Kubernetes形成雙劍合璧效果的微服務管理的利器，受到了業界的推崇。

不可變基礎設施

在傳統的可變服務器基礎架構中，服務器會不斷更新和修改。使用此類基礎架構的工程師和管理員可以通過SSH連接到他們的服務器，手動升級或降級軟件包，逐個服務器地調整配置文件，以及将新代碼直接部署到現有服務器上。換句話說，這些服務器是可變的;它們可以在創建後進行更改。

可變基礎設施通常會導緻以下問題：

在災難發生的時候，難以重新構建服務。持續過多的手工操作，缺乏記錄，會導緻很難由标準初始化後的服務器來重新構建起等效的服務。在服務運行過程中，持續的修改服務器，就猶如程序中的可變變量的值發生變化而引入的狀态不一緻的并發風險。這些對于服務器的修改，同樣會引入中間狀态，從而導緻不可預知的問題。

不可變基礎架構是另一種基礎架構範例，其中服務器在部署後永遠不會被修改。程序設計中不可變變量（ImmutableVariable）就是在完成賦值後就不能發生更改，隻能創建新的來整體替換舊的。由于具有這樣的特性這種變量可以在并發環境下安全的使用。對于基礎設施的不可變性，最基本的就是指運行服務的服務器在完成部署後，就不在進行更改。

不可變基礎架構的好處包括基礎架構中更高的一緻性和可靠性，以及更簡單，更可預測的部署過程。

它可以緩解或完全防止可變基礎架構中常見的問題，例如配置漂移和雪花服務器。但是，有效地使用它通常包括全面的部署自動化，雲計算環境中的快速服務器配置，以及處理狀态或短暫數據（如日志）的解決方案。

聲明式API

聲明式（Declarative）的編程方式一直都會被工程師們拿來與命令式（Imperative）進行對比，這兩者是完全不同的編程方法。

我們最常接觸的其實是命令式編程，它要求我們描述為了達到某一個效果或者目标所需要完成的指令，常見的編程語言 Go、Ruby、C 其實都為開發者了命令式的編程方法，

聲明式和命令式是兩種截然不同的編程方式:

在命令式 API 中，我們可以直接發出服務器要執行的命令，例如： “運行容器”、“停止容器”等；在聲明式 API 中，我們聲明系統要執行的操作，系統将不斷向該狀态驅動。

通俗的說，命令式編程是第一人稱，我要做什麼，我要怎麼做。 操作系統最喜歡這種編程範式了， 操作系統幾乎不用"思考", 隻要一對一的将代碼翻譯成指令就可以了。 而聲明式編程則類似于"第二人稱"， 也就是你要做什麼。 有點"産品經理"和"開發“之間的關系，"産品經理"隻負責提需求，而"開發"怎麼實現他不并關心。

讓我們來總結一下上面提到的技術和工具。

k8s是整個雲原生的基石，雲原生的整個生态體系都是依靠k8s建立起來的。 容器（Container）是k8s的底層引擎； Docker是應用最廣的容器工具； 微服務是docker的好搭檔； 服務網格是微服務的輔助，建立在k8s上的針對請求的擴展功能； 不可變基礎設施是現代運維的基石； 聲明式API是k8s的編碼方式；

由于篇幅關系，簡單列舉三項雲原生應用價值。

1）快速叠代

利用雲原生應用程序開發，意味着使用敏捷與可擴展的組件，如以Kubernetes為代表的容器來提供離散和可重用的功能，這些功能以良好描述的方式集成，甚至跨越多雲等技術邊界，這使得交付團隊可以使用重複的自動化和編排來快速叠代。

2）自動部署

雲原生方法遠優于傳統的面向虛拟化的業務流程，傳統方法需要投入大量的精力來構建開發環境，以及軟件交付過程中的其他不同環境。而雲原生架構具備自動化和組合功能，并且依賴于可靠、經過驗證和審核的已知良好流程的基礎，交付十分敏捷，而不再需要人工幹預重複執行。

3）獨立高效

雲原生帶來了微服務化架構，一個微服務基本是一個能獨立發布的應用服務，因此可以作為獨立組件升級、灰度或複用等，對整個大應用的影響也較小，每個服務可以由專門的組織來單獨完成，依賴方隻要定好輸入和輸出口即可完全開發、甚至整個團隊的組織架構也會更精簡，因此溝通成本低、效率高。

談雲原生就要談雲計算，不和雲計算對比都是耍流氓。雲計算的第一個浪潮是關于成本節約和業務敏捷性，尤其是雲計算的基礎設施更加廉價。

很多企業傾向于使用微服務架構來開發應用。微服務開發快速，職責單一，能夠更快速的被客戶所采納。同時，這些應用能夠通過快速叠代的方式，得到進化，赢得客戶的認可。雲原生可以打通微服務開發、測試、部署、發布的整個流程環節。

雲供應商為迎合市場，提供了滿足各種場景方案的 API，例如用于定位的 Google Maps，用于社交協作的認證平台等。将所有這些 API 與企業業務的特性和功能混合在一起，可以讓他們為客戶構建獨特的方案。所有這些整合都在 API 層面進行。這意味着，不管是移動應用還是傳統的桌面應用都能無縫集成。所以，采用雲原生所開發的應用都且具備極強的可擴展性。

軟件不可能不出故障。傳統的企業級開發方式，需要有專職人員來對企業應用進行監控與維護。而在雲原生架構下，底層的服務或者是API都由将部署到雲中，等價于将繁重的運維工作轉移給了雲平台供應商。這意味着客戶應用将得到更加專業的看護，同時，也節省了運維成本。

9年前，Netscape公司的創始人馬克·安德森說：“軟件正在吞噬世界”；6年前，OpenStack基金會創始人Jonathan Bryce 補充說：“世界的一切源于開源”；再之後，業内普遍認同“雲計算已改變了天空的顔色”；但近兩年雲計算概念又被清晰細分，“雲原生”才是那條最大的魚。

“大魚”來了，我們能做的不是墨守成規，而是擁抱“大魚”，時代在召喚雲原生，但是雲原生不是一蹴而就，而是有個循序漸進的過程。排斥雲原生，了解雲原生，擁抱雲原生，追随雲原生。

參考資料：

1.Kubernetes 是什麼？，Linux中國

2.Kubernetes與雲原生應用概覽，宋淨超

3.雲原生的不同解釋及正确含義，倚天碼農4.10分鐘看懂Docker和K8S，鮮棗課堂

5.CNCF官方大使張磊：什麼是雲原生？

如果閱讀有收獲，求幫忙擴散文章！感謝！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!