說實話，我是一個Kubernetes愛好者。Kubernetes可以說是軟件開發領域邁出的一大步。當我知道Kubernetes的時候，我就想這才是在生產環境使用容器的正確之道。我沒有任何遲疑就接受了Kubernetes。像我這樣的，還有數以千計的架構師已經成功擁抱了這一技術。

首先讓我們了解一下Kubernetes是如何解決在大多數在云端部署應用時碰到的問題，它是如何支持我們的基礎設施向云端遷移。

[[315634]]

牢記你的目標

在萬物云化的時代，對于所有公司都有一些共同的目標。

以下一些目標一般都會具有高優先級：

• 盡快遷移到云上(云端遷移)
• 減少系統管理的成本，基礎設施的成本，人力成本(成本縮減)
• 減少完成項目所需的時間(盡快面向市場)
• 系統高性能、高可用(質量提升)
• 牢記這些目標，我們就能邁上云端，然后思索下一步的動作。

我們為什么需要容器?

在我們思考為什么需要Kubernetes之前，我們需要先問自己，為什么我們需要容器?容器在軟件開發的歷史上是一次巨大的變革，因為它將生產環境帶入到每個開發者的本地環境中，我們不再需要擔心Linux和Windows的兼容問題。通過使用容器，我們可以在任何工作站上輕易地重現出任何問題。并且，我們也能輕易地將容器遷移到任何一個平臺上，不需要做任何其他多余的操作。在容器出現之前，開發者就懂得把應用程序打包進行發布，因為他們知道應用程序如何能夠正常運行，比如你可以將依賴組件和應用一起打包。站在DevOps的角度，容器非常優雅，因為每個發布系統只需要處理一件事物，那就是容器。不僅如此，所有的容器構建過程可以由開發者通過Dockerfile來描述，這意味著無論在本地開發環境還是持續集成環境，你都使用同樣的方法來構建應用。

容器意味著維護的事項更少，屏蔽環境的細節做到無差異化，那么也就更少的錯誤。

我們能夠把容器的鏡像推送到Registry。通過Registry，我們在任何地方都能下載、部署，無論是筆記本電腦還是虛擬機(本地或者云端)甚至是Serverless的場景，比如Heroku。相較于虛擬機，容器真正的優勢在于它虛擬了操作系統你那個而不是外部資源。這樣更高級別的抽象使得我們擁有一種更輕量級、更簡單也更經濟的方式來部署應用。

為什么需要Kubernetes?

在之前的一節中我們解釋了為什么大家都會使用容器，但并沒有提及我們為什么需要Kubernetes。不管怎么說，我們已經接受了容器這個事物。這帶來了一個新的需求，我們如何管理容器?我們如何可靠地編排容器?我們的答案是Kubernetes!

擁有了Kubernetes，你所需要做的事就是將鏡像推送到Registry，然后等待Kubernetes來完成剩余的工作。所有部署環節的任務都由Kubernetes來管理，我們根本無需去擔心基礎設施。

Kubernetes是業界領先的容器編排解決方案。它是在Google對容器的實踐中逐漸開發完善的，同時也是開源的。它的架構允許容器編排，也允許與舊的系統集成。這意味著你能在本地安裝Kubernetes，也可以在云端安裝、使用，甚至允許你是用混合云的架構。

所以，我們之所以會使用Kubernetes，是因為它的穩定性、可靠性和易用性。簡單來說，Kubernetes是部署容器的最佳方式。

Kubernetes是Serverless嗎?

Kubernetes是不是Serverless?我認為Kubernetes和Serverless是兩個不同領域的詞。Serverless更多是一種哲學，而Kubernetes則是一個具體的工具。讓我們暫且先回顧一下我們最初的目標，我們說我們需要減少對操作系統的依賴以及減少維護他的成本，而這就是Serverless。

那么問題就變成了，Kubernetes是否讓我們實現了這個目標呢?簡單來說，是的。

Serverless的嚴格定義是，我們不需要關心到底是什么應用容器、什么系統、什么硬件在運行我的代碼，甚至我都不知道它位于世界的哪個角落。雖然Kubernetes確實向開發者隱藏了諸多的復雜性，但我們確實還是需要了解服務器的相關部分，比如，你仍然依賴于某個特定的容器提供的操作系統。同時，你也依賴于某個特定版本的Kubernetes。這意味著，理論上來說Kubernetes并不算Serverless。

接著，讓我們來看幾個Serverless的解決方案。

Heroku Runtime[1]的底層是依賴于容器，當然你也可以在Heroku上直接部署自己的容器[2]。大部分的Lambda函數都是運行在容器中。

這就是為什么我們認為部署在云端的Kubernetes不是Serverless，因為它是基于容器的，并且還依賴于操作系統。然而，同樣依賴于容器的Heroku Runtime或是Lambda計算服務卻被認為是Serverless。

所以我仍然認為Kubernetes是一種Serverless的解決方案，即使它不滿足嚴格的定義。這個世界并不是非黑即白的，云端版本的Kubernetes提供的抽象程度(如屏蔽了操作系統以及底層資源)對我來說已經足夠了。

我不希望在這里咬文嚼字。除開我們是否要給Kubernetes貼上Serverless這個標簽的問題，Kubernetes確實能夠讓我們迅速上云，是減少系統管理成本、基礎設施維護成本，提高業務質量的一大利器。所以我們實際上無須去關心那些標簽，黑貓白貓抓到老鼠就是好貓。

Kubernetes的優勢

Kubernetes是一個非常優秀的平臺，使我們能夠脫下傳統虛擬機的戎裝去擁抱云。它帶來活力，減少系統管理成本，并且將服務的質量推上一個新的高度，在Kubernetes誕生之前我們很難做到這一步。許多傳統的問題比如網絡，數據保護等在Kubernetes中都能夠通過高級配置來實現。

以下是Kubernetes帶來的一些優勢：

• 可擴展性：你只需要部署一個容器，就能夠毫無障礙地設置擴容策略。然后，你只需要保證你的賬戶里有足夠的余額就行了。
• 透明化：每個容器只完成一項工作。容器之間的關系被映射成配置文件，不需要擔心遺漏什么，當然細節也無法被隱藏。
• 節約時間：流程非常簡單，所有的步驟都能夠被重復。
• 版本控制：從設計上來看，每一次部署都被版本化。當然，稍微花點時間，你也可以將配置文件用Git管理起來。

與其他方式相比，Kubernetes簡化了所有開發運維的事項，將開發者帶入到一個幾乎不需要運維的理想狀態。開發團隊和運維團隊之間的摩擦也減少了，因為原本兩者職責的模糊地帶現在也劃清了界線，系統本身也保持了相當的透明度。

其他的一些優點列舉如下：

• 水平擴展：Kubernetes本身能夠自動擴展，支持在集群中增加節點或者調整可用的物理資源。同時，他也能擴展邏輯資源，如調整一個服務的Pod數目。
• 智能升級：每次你升級容器鏡像的時候，升級的過程是平滑的。舊的Pod會一直保持可用的狀態直到新的Pod啟動完成才會被銷毀。這就是我們常說的零宕機部署。
• 支持本地搭建或是云端服務：使用使用云以外還有別的選擇嗎?當然!我總是偏好完全云端的解決方案，當然在一些場景下，可能也需要在本地環境或者機房部署，當然Kubernetes也能夠完美支持。
• 遠離廠商捆綁：Kubernetes在每個通過認證的公有云平臺具有一致性[3]。如果你對你的服務商不滿，你只需要花費少量的時間就可以更換廠商。
• 對開發者沒有額外的成本：任何已經被容器化的軟件都能一鍵部署。開發團隊不需要學習額外的知識。

我們到底如何選擇?

Kubernetes的靈活性很強，利用云端的方案，你可以輕松地管理Kubernetes集群。當我了解到Kubernetes的時候，我就認為它是一個可行的、安全的方案，能夠有效減少開發者的負擔。它具備所有傳統基礎設施的優勢，同時讓我們在不重構應用的同時，享受不需要運行維護的便利。和很多其他看上去閃閃發亮的解決方案(如Serverless)相比，Kubernetes更加實在。Serverless確實很不錯，但是很多復雜的場景，它并不能很自如地應付。并且從邏輯上來看，全盤接受像Lambda這樣前沿的技術需要一個巨大的思維轉變。對于運維團隊來說，這樣的改變并不容易。

如今，減少系統管理的工作量，擁有能夠易于部署、能夠簡化運維核心痛點的基礎設施對大部分團隊來說都是核心需求。而Kubernetes滿足這所有的需求。

如果讓我現在去設計一套架構，尤其是面向企業的解決方案，我會首選容器技術和Kubernetes。或許我會選擇云服務商提供的Kubernetes來減少運維成本。我也有可能會用Git來管理DevOps流水線相關的配置。

這個方案對操作系統的依賴很少，對云廠商的依賴也很少，所有的基礎設施及其配置都依賴于代碼。

有人會說，這個方案并不完全擺脫了運維，也不完全擺脫了服務器。但Kubernetes具有穩定、模塊化、可伸縮的特性，能夠滿足最重要的架構設計目標。所以我們為什么不用Kubernetes呢?

那我們能不能做得更好?毫無疑問。我們能努力擺脫更多的負擔嗎?當然可以。我們當然能百尺竿頭更進一步。然而，仰望星空也要腳踏實地，我們必須要承認Kubernetes是一個極佳的折中方案：在大部分案例中，Kubernetes是成功的保障。