摘要：目前正在運行的應(yīng)用程序。內(nèi)置非配置負載均衡器如何設(shè)置運行的集群在這里你有幾個選項。它跟其它的谷歌云組件也都整合得很好，比如負載均衡器和磁盤。它會告訴負載均衡器，流量可以被重新傳到特定的。元信息和谷歌云會以正確的方式展現(xiàn)出來。

Kubernetes實踐案例分享｜在這次的 RisingStack 案例分享中，我們可以在 Kubernetes Tutorial 中學(xué)習(xí)到如何從 PaaS 供應(yīng)商中遷移 Node.js 應(yīng)用，同時降低響應(yīng)時間、提高安全性、減少成本。

在談到為什么、以及如何將我們的服務(wù)遷移到 Kubernetes 的故事之前，需要強調(diào)的是，使用 PaaS 平臺是完全沒錯的。如果要開發(fā)一個新的產(chǎn)品，PaaS 是一個很完美的平臺，同時它還是一個很好的快速迭代的解決方案——當(dāng)然，這取決于你的需求和資源。

RisingStack 的產(chǎn)品 Trace，我們的 Node.js 監(jiān)控解決方案運行在最大的 PaaS 提供商之一上已有半年多。我們在其它解決方案中選擇了 PaaS，因為我們想要重點關(guān)注產(chǎn)品而不是基礎(chǔ)設(shè)施。我們的需求其實很簡單，我們需要：

快速部署

簡單彈性伸縮

無宕機部署

回滾功能

環(huán)境變量管理

不同的 Node.js 版本

無需開發(fā)運維人員

使用PaaS平臺時，我們不希望有的副作用：

服務(wù)間網(wǎng)絡(luò)延時大

缺乏 VPC

多租戶技術(shù)引起的響應(yīng)時間高峰

更高的成本（為每個進程支付，無論大小：clock，內(nèi)部 API 等等）。

Trace 是作為一組微服務(wù)來開發(fā)的，所以你可以想象一下，網(wǎng)絡(luò)延遲和服務(wù)費很快就開始對我們造成損害。

從 PaaS 經(jīng)驗來看，我們正在尋找一種解決方案，只需要少量的開發(fā)運維工作、同時保持原有的開發(fā)流程不變。我們并不想失去任何我們上面提到過的優(yōu)勢——但是，我們也曾想要修補那些明顯的漏洞。我們那時候正在尋找更加配置化的，團隊中任何人都可以修改的基礎(chǔ)設(shè)施。

Kubernetes 關(guān)注配置、基于容器、微服務(wù)友好型的特性，折服了我們。讓我用以下的章節(jié)來說明一下，在這些專業(yè)術(shù)語背后的意思。

什么是 Kubernetes？

Kubernetes 是一個自動部署，彈性調(diào)度和管理容器化應(yīng)用程序的開源系統(tǒng)。

在這里我對 Kubernetes 就不多做介紹了，但是要看懂這篇帖子接下來要介紹的東西，Kubernetes 基礎(chǔ)結(jié)構(gòu)還是要了解的。我的解釋不一定完全正確，但是對于 Kubernetes 來說，你可以把它想象成一個 PaaS 平臺：

pod：是一個和環(huán)境變量，磁盤等等一起的處于運行狀態(tài)的容器化應(yīng)用程序。Pods 的生成，消亡都很快，比如在部署的時候。In PaaS：目前正在運行的應(yīng)用程序。

Deployment：你的應(yīng)用程序的配置描述了你需要的狀態(tài)（CPU，內(nèi)存，環(huán)境變量，Docker 鏡像版本，運行的實例的數(shù)量，部署策略等等）。In PaaS：應(yīng)用設(shè)置

Secret：你可以將你的證書從環(huán)境變量中分離出來，In PaaS：不存在，就好像已分享的分開的 secret 環(huán)境變量，對于DB證書等等來說。

Service：通過 label 將運行的 pods 暴露到其他應(yīng)用上，或者在理想的 IP 或者端口上暴露到外部世界。In PaaS：內(nèi)置非配置負載均衡器

如何設(shè)置運行的 Kubernetes 集群？

在這里你有幾個選項。最容易的一個就是，在谷歌云上創(chuàng)建一個容器引擎。它跟其它的谷歌云組件也都整合得很好，比如負載均衡器和磁盤。

同時你也要了解，Kubernetes 能夠在任何地方，比如 AWS，DigitalOcean，Azure 等地方運行。想要了解更多信息，請點擊：鏈接

首先，我們需要先讓我們的應(yīng)用程序處于在 Docker 環(huán)境中跟Kubernetes運行得很好的狀態(tài)。如果你正在尋找關(guān)于如何用 Kubernetes 開啟應(yīng)用程序的 tutorial，查看他們的 tutorial 初級教程。

Docker 容器內(nèi)的 Node.js 應(yīng)用

Kubernetes 基于容器，所以首先我們需要把我們的應(yīng)用都容器化。關(guān)于怎么容器話應(yīng)用，如果你不確定的話，請點擊我們之前的帖子：鏈接。如果你是 NPM 個人用戶，那么這個可能對你比較有幫助：鏈接。

Kubernetes 中的“Procfile”

我們?yōu)槊總€應(yīng)用都創(chuàng)建一個 Docker 鏡像（Git Repository）。如果 repository 包括了多個進程，比如：server，worker 和 clock，我們用一個環(huán)境變量在他們之間進行選擇。你可能會覺得這很奇怪，但是我們不想從一樣的源代碼中創(chuàng)建，推進多個 Docker 鏡像，這將會拖慢我們的 CI。

預(yù)發(fā)布，產(chǎn)品

在我們的 PaaS 階段，我們給我們的服務(wù)命名：trace－foo，trace-foo-staging，預(yù)發(fā)布階段和產(chǎn)品應(yīng)用程序階段的差別就是名字前綴，和不同的環(huán)境變量。在 Kubernetes 中是可以定義命名空間的。每個命名空間總體上來說是互相獨立的，而且并不分享任何資源比如 secrets，config 等等。

應(yīng)用程序版本

在容器化的基礎(chǔ)設(shè)施上，每個應(yīng)用程序版本應(yīng)該都是打了 tag 標(biāo)簽的不同容器鏡像。我們用 Git 短 hash 函數(shù)作為一個 Docker 鏡像 tag。

要部署你的應(yīng)用程序的新版本，你只需要在你的應(yīng)用程序的部署配置中修改鏡像 tag，剩下的 Kubernetes 會幫你做。

在你部署文件中，任何的修改都會被發(fā)布到版本中，于是你就可以在任何時間回滾回去。

在部署的過程中，我們只是快速替換 Docker 鏡像——他們只需要幾秒鐘就可以。

服務(wù)發(fā)現(xiàn)

Kubernetes 有個內(nèi)置的，簡單的服務(wù)發(fā)現(xiàn)解決方案：已創(chuàng)建的服務(wù)暴露他們的主機名和端口，作為每個 pod 的環(huán)境變量。

如果你不需要高級服務(wù)發(fā)現(xiàn)，你可以試一試，而不是把服務(wù)的URL復(fù)制到其它的環(huán)境變量中。是不是很酷！

要進入一個新的技術(shù)的真正挑戰(zhàn)其實是，去了解如何讓你需要的東西在產(chǎn)品中處于已經(jīng)好了的狀態(tài)。在以下小節(jié)中，我們會列舉你應(yīng)該在應(yīng)用中設(shè)置什么。

零宕機部署和故障轉(zhuǎn)移

Kubernetes 有它特有的方式來更新你的應(yīng)用程序，這樣它就可以保持 pods 一直運行，并且以較小的步驟來部署你的修改——替代原來的那種先停止再開啟的方式。

其實防止零宕機部署也沒用了；它會在你部署錯什么東西的時候，避免殺死你的應(yīng)用程序。在 Kubernetes 發(fā)現(xiàn)新的 pod 是不健康的時候，你的錯誤會停止升級到所有在運行的 pod。
Kubernetes 支持幾個策略來部署你的應(yīng)用程序。你可以在 Deployment 策略文檔中進行檢查。

優(yōu)雅停止

這也不是完全跟 Kubernetes 相關(guān)，但是如果沒有以合適的方式開啟或者停止你的進程的話，那就不可能有一個好的應(yīng)用程序生命周期。

開啟服務(wù)器

完美的服務(wù)器停頓

活性探測（健康檢查）

在 Kubernetes 中，你應(yīng)該為你的應(yīng)用程序定義好健康檢查（活性探測）。有了這個，Kubernetes 就可以檢測到你的應(yīng)用程序什么時候需要重新啟動。

網(wǎng)頁服務(wù)器健康檢查

你有好幾個選項可以檢查應(yīng)用程序的健康，但是我覺得最容易一個就是，創(chuàng)建一個 GET/healthz 端點來檢查你的應(yīng)用 logic/DB 連接這里。有個重要的事情要提一下的就是，每個應(yīng)用程序都是不一樣的，只有你能夠知道需要怎樣的檢查來確認它是否在正常工作。

Worker健康檢查

對于我們的 worker 來說，我們也會用同樣的／healthz 端點來設(shè)置非常小的 HTTP 服務(wù)器，同樣都是活性探測，這個端點是用不同的標(biāo)準(zhǔn)來檢查的。我們這么做是為了擁有公司水平的健康檢查端點。

Readiness Probe

Readiness probe 跟Livenessprobe（健康檢查）有點相似，但是它只對網(wǎng)頁服務(wù)器可行。它會告訴 Kubernetes service（～負載均衡器），流量可以被重新傳到特定的 pod。
在部署的時候避免服務(wù)中斷是基本的要求。

對于日志來說，你們可以從不同的途徑選擇，比如添加 side containers 到你的應(yīng)用程序，收集你的日志并且發(fā)送到定制日志解決方案，或者你可以跟隨著內(nèi)置谷歌云的腳步。我們的選擇是內(nèi)置的那個。
為了能夠在谷歌云上解析內(nèi)置日志水平，你需要以特定的格式來登錄。你可以用 winston－gke 模塊輕松地完成。

如果你想要以特定的方式登錄，Kubernetes 會用容器，Deployment 等等自動合并你的日志信息。元信息和谷歌云會以正確的方式展現(xiàn)出來。
為了完成這個，我們轉(zhuǎn)換我們的npm start到靜音，Dockerfile 中的 npm start－s：CMD ["npm","start", "-s"]

我們用 Trace 來檢查我們的應(yīng)用程序，Trace 充分利用來監(jiān)控，設(shè)想微服務(wù)架構(gòu)。Trace 的服務(wù)地圖在理解應(yīng)用程序間的互相交流的時候到幫了我們很多，同樣，在理解數(shù)據(jù)庫和外部依賴是什么的時候也起到了作用。

既然 Trace 獨立于環(huán)境，我們就沒必要在代碼庫中修改任何東西，我們可以用它來驗證遷移和我們對性能提升的期望。

用 Kubernetes 和 CircleCI 為 Node.js 來檢查我們的 example repository：
鏈接

用 CI 進行連續(xù)部署

用 JSON 途徑來更新 Kubernetes 部署，或者只更新鏡像 tag 是可能的。在你的 CI 機器上有一個運行的 kubectl，你只需要運行這個命令就可以：

調(diào)試

在 Kubernetes，在任意的容器內(nèi)運行 shell 都是可能的，就像下圖一樣容易：

另一個有用的事情就是用下圖所示代碼檢查 pod events：

同樣你也可以以下代碼來獲取任意的日志信息：

代碼 Piping

在我們 PaaS 提供商層面，我們傾向于喜歡在預(yù)發(fā)布和產(chǎn)品基礎(chǔ)設(shè)施這兩個階段間的代碼 piping。在 Kubernetes 中，我們漏掉了這個部分，所以我們創(chuàng)建了我們自己的解決方案。
這是一個簡單的 npm 庫，能夠從 staging 版本讀取目前的鏡像標(biāo)簽，并且在 production 版本部署時進行設(shè)置。
因為 Docker 容器很像，只有環(huán)境變量改變了。

SSL 終端（https）

Kubernetes 服務(wù)默認設(shè)置下不是作為 https 來暴露的，但是你能夠很輕松地修改它。為了做到這樣，點擊網(wǎng)址了解如何用 Kubernetes 上的 TLS 來暴露你的應(yīng)用程序。

用一句話來總結(jié)我們使用 Kubernetes 的經(jīng)歷就是：我們十分滿意。
我們在微服務(wù)架構(gòu)中優(yōu)化了應(yīng)用程序的響應(yīng)時間，成功地用應(yīng)用間的私人網(wǎng)絡(luò)配置（VPC）提高了安全性。
同樣，我們降低了成本，并且用內(nèi)置滾動更新策略和健康檢查提高了故障轉(zhuǎn)移效率。
如果你正在思考基礎(chǔ)設(shè)施的未來，那么絕對應(yīng)該考慮使用 Kubernetes。
如果在從 PaaS 轉(zhuǎn)移到 Kubernetes 的過程中，有任何的疑問，歡迎留言評論。

原文鏈接
如果需要轉(zhuǎn)載，請聯(lián)系我們，尊重知識產(chǎn)權(quán)人人有責(zé)；0