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

• 對于容器技術(shù)熟悉程度的缺乏
• 應(yīng)用架構(gòu)不利于使用到Kubernetes的優(yōu)勢
• 增加的工作量和所花費的時間

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

一、您對容器是否有經(jīng)驗?

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

1.容器化您的應(yīng)用程序

[[221972]]

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

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

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

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

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

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

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

3.理解網(wǎng)絡(luò)是如何運作的

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

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

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

下面是我認為Kubernetes在試圖解決容器擴展問題時，所能表現(xiàn)出的優(yōu)勢之處。

1.擴展資源

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

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

2.執(zhí)行大量的更新

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

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

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

3.自愈功能

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

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

三、您的應(yīng)用程序架構(gòu)是否需要更改?

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

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

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

1.應(yīng)用的啟動時間很重要

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

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

2.調(diào)整多租戶的架構(gòu)比較困難

多租戶架構(gòu)意味著您擁有一個單獨的應(yīng)用實例，由它來管理分區(qū)租戶環(huán)境中的所有最終用戶，當然它通常會將單個數(shù)據(jù)庫共享給每個人。

如果您的應(yīng)用不是使用群集的方式構(gòu)建的話(將多個服務(wù)器聯(lián)合為單個實例)，那么您就不應(yīng)該去使用Kubernetes。

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

• 多實例架構(gòu)，即為每個用戶分配一個應(yīng)用的實例
• 多租戶架構(gòu)，具有群集功能，能夠?qū)κ褂玫馁Y源進行向上擴展和向下縮減

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

3.遷移到無狀態(tài)應(yīng)用是一項浩大的工程

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

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

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

四、到底是否應(yīng)該采用Kubernetes呢?

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

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

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

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