【51CTO.com快譯】Kubernetes是一項神奇的技術，我個人通過它在自己SaaS上實施擴展、部署和管理的過程已獲益匪淺。但是客觀而言，并非每個人都能夠在采用它之后迅速獲益的，一般有如下的原因：

• 對于容器技術熟悉程度的缺乏
• 應用架構不利于使用到Kubernetes的優勢
• 增加的工作量和所花費的時間

因此，如果你對Kubernetes感興趣，卻又不確定是否值得投入必要的時間與資源的話，那么本文應該比較適合您來參考閱讀。

一、您對容器是否有經驗?

為了理解Kubernetes能夠為您做些什么，您首先需要了解容器能夠提供哪些優勢。因此在你花時間開始使用Kubernetes之前，請事先準備如下幾點：

1.容器化您的應用程序

[[221972]]

首先也是最重要的：您的應用程序必須已經實現了容器化。這意味著您已經定義好了相關的步驟來設定一個基本的OS映像，并且將您的應用程序打包成為一個文件(通常是一個Dockerfile)安裝進去了。

通過上述過程、以及定義配置應用程序所需的環境變量(如應用程序所使用的數據庫的URL、用戶名和密碼)都是至關重要的。這些能夠保證您的容器映像對于Kubernetes來說是可用的。

同時，您還要記下應用程序所需運行時的各種依賴關系，并且理解如何去使用它們的容器版本。

2.理解存儲是如何運作的

容器一般被設計為僅保存運行某個應用程序所需的代碼。由于對容器進行卸載(tear down)和啟動(spin up)的進程(在處理多個容器時，該現象十分常見)都會破壞存儲在該容器文件系統中的所有數據，因此任何持久性數據都需要被存儲到其他地方。

在考慮Kubernetes時，您應當去理解容器存儲是如何被設定運作的，以及如何處理諸如備份數據、在容器之間移動數據、以及從容器外部訪問數據等問題。

Kubernetes通過諸如自動資源調配的功能，使得存儲管理更易于實現。該功能也使得您的存儲提供商(如AWS EBS)在忙于創建新的容器時，會及時創建一些新的卷，并自動加載它們。

3.理解網絡是如何運作的

您的網絡構建方式會對您使用Kubernetes產生巨大的影響。對于新手來說，了解如何在做好隱藏部分信息的情況下，將特定的系統開放給外部互聯網應用(如數據庫)，同時保持服務之間的通信是非常重要的。根據經驗，我們需要掌握一些更為復雜的背景知識，包括：如何集成負載平衡，以及給每個客戶的實例定義主機名等。這些都會使得Kubernetes的使用變得容易得多。

二、Kubernetes能夠解決您當前面臨的各種問題嗎?

如果您并沒有使用容器來部署自己的應用，那么您可能就不需要用到Kubernetes了。因為Kubernetes所解決的問題，一般是你在試用和擴展一個基于容器的架構時所碰到的。

下面是我認為Kubernetes在試圖解決容器擴展問題時，所能表現出的優勢之處。

1.擴展資源

從本質上來說，Kubernetes是一組節點的集群，它提供了可由容器的工作負載所使用的計算資源。這種群集架構能夠非常容易地對各種資源進行擴展或縮減。您只要在群集中添加或刪除某些節點，Kubernetes就會自動利用這些資源，或者是對您現有資源進行工作負載上的重新分配。

該特性曾經解決了我所面臨的一個棘手問題。因為我最初只有一臺單獨的服務器，為了能夠持續擴展(這本來會是一個麻煩的手動過程)，我只需要在CLI(命令行界面中)使用一條命令，就有能力對自己的架構進行自由縮放了。

2.執行大量的更新

Kubernetes的另一個能力是：它能夠解決對所有容器的更新問題。過去，我不得不編寫一些shell腳本來選擇每個相關的容器，并使用新的鏡像標簽來重新創建它們。整個過程不但要持續一個多小時，而且我都無法去驗證更新是否成功。如今，使用了Kubernetes，我就能通過如下的一條命令來執行更新操作：

// Update all the pods of frontend to a new image tage  
$ kubectl rolling-update frontend --image=image:v2 

Kubernetes還允許您基于任何標準、通過各種命令，來更新Kubernetes的任一部分(包括網絡、存儲等)。從編寫自己的腳本來進行架構更改的角度來說，這是一項巨大的進步。

3.自愈功能

自愈功能是***一個需要在此提及的，卻又是Kubernetes最重要的能力。如果Kubernetes在其架構中檢測到諸如：某個節點沒響應了、或是某個容器未通過健康檢查之類的問題出現時，它會根據既定的步驟執行重新創建相應涉及到的部分，一直到它們能夠重新恢復運作為止。

這是非常有用的。如果群集中的某個部分因為某種原因而下線時，其對應的工作負載應當被重新分配，而且您甚至可以讓Kubernetes重建整個服務器來解決問題。

三、您的應用程序架構是否需要更改?

[[221973]]
有時候，在您的應用上采用Kubernetes，就像將一個方木釘打入一個圓孔中。

由于我的應用最初就是被構建為：通過多個容器的部署，產生一個多實例的平臺，因此當被遷移到Kubernetes時，我并沒有做太多的更改。

下面我分享一些在把自己的工作負載遷移到Kubernetes的過程中所學到的內容。

1.應用的啟動時間很重要

當創建新的部署時，您必須等待應用啟動之后，才能讓最終用戶可用。這樣就會產生一個問題：如果在最終用戶按下某個按鈕的時刻，或是在您對所有客戶實例上執行更新的那一刻，部署進程正好涉及到創建新的實例的話，那么就需要重新生成一些pod了。

因此在遷移到Kubernetes的時候，您可能需要對代碼庫進行一些更改，使得啟動進程更為高效，以至于最終用戶在使用您的產品時，不會產生體驗上的下降。

2.調整多租戶的架構比較困難

多租戶架構意味著您擁有一個單獨的應用實例，由它來管理分區租戶環境中的所有最終用戶，當然它通常會將單個數據庫共享給每個人。

如果您的應用不是使用群集的方式構建的話(將多個服務器聯合為單個實例)，那么您就不應該去使用Kubernetes。

通常在使用Kubernetes時，我們會采用兩種類型的架構：

• 多實例架構，即為每個用戶分配一個應用的實例
• 多租戶架構，具有群集功能，能夠對使用的資源進行向上擴展和向下縮減

相對于群集式的多租戶架構而言，我個人更喜歡多實例的架構，因為它們更容易被實施。此外，相對于為多實例架構增加各種群集的能力，將多租戶遷移到多實例架構所涉及的工作量要小得多。

3.遷移到無狀態應用是一項浩大的工程

Kubernetes的一個重要特點是：在部署中具有向上擴展和向下縮減pod數量的能力。但是，如果您的應用程序既不是群集化的、又不是無狀態的，那么此功能就等于浪費，因為在部署過程中，那些額外的pod既不會被正確地配置、又無法被使用到。

大多數情況下，由于您需要在應用中對其處理配置的方式進行重寫，因此在Kubernetes中使用無狀態的進程往往會得不償失。

如果您不想花費時間將應用程序改成無狀態或群集模式的話，那也沒關系，畢竟Kubernetes能提供許多其他的方法，來幫助您改成有狀態的部署模式。當然這些方法也會有其自身的各種問題，本文在此就不深入討論了。

四、到底是否應該采用Kubernetes呢?

對于是否遷移Kubernetes這個問題，您應該考慮它是否真的適合于您當前的系統。對于大多數早期初創公司來說，可能不會需要Kubernetes;而對于一些更成熟的公司來說，他們可能已經在其他技術上有了大量的投入，因此遷移也是不太可行的。

在此我認為最適合遷移到Kubernetes的應該是：某個初創公司，它希望能從現有最小規模、且正在運行的云基礎架構中，轉向更為穩定的狀態，并且通過使用容器來“賦能”其生產環境中的工作負載。其實這就是我所經歷的過程。也就是說，我自己經歷了從資源管理不足和服務器過載所導致的周期性宕機，到使用和遷移到Kubernetes的整個過程。如今我已經不再擔心自己的基礎架構了。

原文標題：How to know if Kubernetes is right for your SaaS，作者：Ben Sears

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】