現在，云原生、Kubernetes已經成為企業IT領域的時髦概念，幾乎所有的企業都在關注;如果不提這些概念，好像企業就會在云市場競爭中失去絕對話語權。那么，云原生和Kubernetes是怎樣一種關系?是什么讓Kubernetes超越了Docker ，在容器大戰中獲得領導者地位?本文將逐一進行梳理!

[[279257]]

kubernetes項目，由google公司在2014年啟動，能在這么短的時間內“迅速上位”，其實有點不合常理!

稍微有一點閱歷的人，都會記得90年代初的那場互聯網大戰，網絡牌照問題的爭議持續了好多年，直到TCP/IP協議推出，一切才歸于平靜!同時，我們也不會忘記.com時代的UNIX操作系統之戰，當很多供應商正無法抉擇時，開源Linux像一款黑馬級應用，映入人們的眼簾。

kubernetes和TCP/IP、Linux一樣，他們都有一個共同特征，那就是在基礎設施層面上構建更廣泛的應用。只是，Kubernetes為什么能以超乎尋常的速度走向容器之路?很多人都無法解釋!如果非要找一個理由，那一定是云原生帶來的強大顛覆力。

云帶來的變化

首先，云計算的快速發展，是一切變化的前提。

雖然，kubernetes的快速崛起，由多種因素匯聚而成。但是，有一個因素非常重要，那就是公有云環境的逐漸成熟。如今，公有云市場已不只是幾個大型云計算廠商在主導，一些希望通過云計算來獲得關鍵業務能力的企業也在加大推廣力度，加快公有云落地步伐。有越來越多的企業希望，借助公有云來獲得IT基礎架構的可伸縮性、可擴展性以及API工具調用模式的可配置性。

其次，DevOps也是Kubernetes能夠獲勝的關鍵力量。

DevOps并不是一個新概念，在容器和 Kubernetes 普及之前，就已經成為主流趨勢了。DevOps的核心思想其實有兩個：一個是通過人、流程、工具的優秀組合，幫助企業更好地開發、運行和管理軟件，提高企業的工作效率;另一個是核心是，DevOps提供了廣泛的工具集，能幫助開發和運維團隊自動化執行很多任務。DevOps也滲透了以API為主導的連接方式，即每個數據都可成為管理的API，通過自助服務發現和控制應用。這種可配置的特性，在云時代得到了傳承，并提供了更好的平臺。也就是說，Kubernetes和容器的出現，讓企業真正走向了DevOps，獲得了工具落地的新一代IT基礎架構。

云原生成為企業IT新的架構趨勢

在云優秀實踐和DevOps的雙重因素推動下，云本地架構發生了微妙變化，一種基于云和DevOps優秀實踐基礎之上的云原生架構，脫穎而出。云原生架構能讓企業以更快的速度實現云化目標。

雖然，云原生架構包含傳統的虛擬化、容器以及無服務器計算等很多方面，但是綜合來看，Kubernetes是不錯的選擇。

原生云不僅僅是一種架構方法，它是一個時代的縮影，是一種新的架構范例。通過原生云，企業IT將整體進入新的變革期。

云原生的前世今生

總體來看，云原生架構并不是憑空產生的，它吸收了之前許多架構的精華，讓云計算成為可能。

在2000年左右，企業部署的是面向服務的體系架構(SOA)，主要依賴于復雜的中間件來實現，通過企業服務總線(ESB)處理各種任務，包括系統集成、路由網關、數據轉換、安全性問題等，同時被Web服務應用程序發現并調用。

SOA 的架構原則，大多采用點對點的通信連接，服務調用和集成邏輯被內嵌在應用實現中。這種方式在服務數量比較少的時候，確實簡單、高效。但隨著服務規模的增長，服務與服務之間的通信愈發復雜，連接路徑和復雜性會劇增，給服務治理帶來巨大挑戰，很多人將這種模式稱為“智能管道，啞端點”。

之后，隨著云的興起，再加上容器和微服務的推波助瀾，SOA最終讓位給微服務架構體系。

與基于XML的“啞端點”式的Web服務模式不同，微服務是松耦合、高內聚的單個執行單元，整體架構更偏向于“智能端點、啞管道”模式，所有的執行都通過一個個小程序來實現。但是為了確保這些程序的集成性，我們必須通過基于HTTP協議的輕量級開源簡單隊列服務來實現。

當企業IT的內部環境，開始從SOA向以云為中心的微服務體系結構轉變的背景下，用“啞管道”替換ESB，意義重大。但是實現起來，存在著很多挑戰，無法做到彈性擴展。因此，微服務架構的這種“缺陷”，為Kubernetes的發展提供了一個完美的“溫床”。在以kubernetes為重要組件的本地云架構中，來自于SOA時代的ESB的很多優勢被引入到云架構模式中，讓用戶可以獲得“智能端點”和“智能服務網格”。