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

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

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

RisingStack 的產(chǎn)品 Trace，我們的 Node.js 監(jiān)控解決方案運(yùn)行在最大的 PaaS 提供商之一上已有半年多。我們?cè)谄渌鉀Q方案中選擇了 PaaS，因?yàn)槲覀兿胍攸c(diǎn)關(guān)注產(chǎn)品而不是基礎(chǔ)設(shè)施。我們的需求其實(shí)很簡(jiǎn)單，我們需要：

快速部署

簡(jiǎn)單彈性伸縮

無(wú)宕機(jī)部署

回滾功能

環(huán)境變量管理

不同的 Node.js 版本

無(wú)需開(kāi)發(fā)運(yùn)維人員

使用PaaS平臺(tái)時(shí)，我們不希望有的副作用：

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

缺乏 VPC

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

更高的成本（為每個(gè)進(jìn)程支付，無(wú)論大?。篶lock，內(nèi)部 API 等等）。

Trace 是作為一組微服務(wù)來(lái)開(kāi)發(fā)的，所以你可以想象一下，網(wǎng)絡(luò)延遲和服務(wù)費(fèi)很快就開(kāi)始對(duì)我們?cè)斐蓳p害。

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

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

什么是 Kubernetes？

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

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

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

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

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

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

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

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

同時(shí)你也要了解，Kubernetes 能夠在任何地方，比如 AWS，DigitalOcean，Azure 等地方運(yùn)行。想要了解更多信息，請(qǐng)點(diǎn)擊：鏈接

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

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

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

Kubernetes 中的“Procfile”

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

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

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

應(yīng)用程序版本

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

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

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

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

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

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

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

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

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

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

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

優(yōu)雅停止

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

開(kāi)啟服務(wù)器

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

活性探測(cè)（健康檢查）

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

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

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

Worker健康檢查

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

Readiness Probe

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

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

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

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

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

用 Kubernetes 和 CircleCI 為 Node.js 來(lái)檢查我們的 example repository：
鏈接

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

用 JSON 途徑來(lái)更新 Kubernetes 部署，或者只更新鏡像 tag 是可能的。在你的 CI 機(jī)器上有一個(gè)運(yùn)行的 kubectl，你只需要運(yùn)行這個(gè)命令就可以：

調(diào)試

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

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

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

代碼 Piping

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

SSL 終端（https）

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

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

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