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

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

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

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

快速部署

簡單彈性伸縮

無宕機部署

回滾功能

環境變量管理

不同的 Node.js 版本

無需開發運維人員

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

服務間網絡延時大

缺乏 VPC

多租戶技術引起的響應時間高峰

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

Trace 是作為一組微服務來開發的，所以你可以想象一下，網絡延遲和服務費很快就開始對我們造成損害。

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

Kubernetes 關注配置、基于容器、微服務友好型的特性，折服了我們。讓我用以下的章節來說明一下，在這些專業術語背后的意思。

什么是 Kubernetes？

Kubernetes 是一個自動部署，彈性調度和管理容器化應用程序的開源系統。

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

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

Deployment：你的應用程序的配置描述了你需要的狀態（CPU，內存，環境變量，Docker 鏡像版本，運行的實例的數量，部署策略等等）。In PaaS：應用設置

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

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

如何設置運行的 Kubernetes 集群？

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

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

首先，我們需要先讓我們的應用程序處于在 Docker 環境中跟Kubernetes運行得很好的狀態。如果你正在尋找關于如何用 Kubernetes 開啟應用程序的 tutorial，查看他們的 tutorial 初級教程。

Docker 容器內的 Node.js 應用

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

Kubernetes 中的“Procfile”

我們為每個應用都創建一個 Docker 鏡像（Git Repository）。如果 repository 包括了多個進程，比如：server，worker 和 clock，我們用一個環境變量在他們之間進行選擇。你可能會覺得這很奇怪，但是我們不想從一樣的源代碼中創建，推進多個 Docker 鏡像，這將會拖慢我們的 CI。

預發布，產品

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

應用程序版本

在容器化的基礎設施上，每個應用程序版本應該都是打了 tag 標簽的不同容器鏡像。我們用 Git 短 hash 函數作為一個 Docker 鏡像 tag。

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

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

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

服務發現

Kubernetes 有個內置的，簡單的服務發現解決方案：已創建的服務暴露他們的主機名和端口，作為每個 pod 的環境變量。

如果你不需要高級服務發現，你可以試一試，而不是把服務的URL復制到其它的環境變量中。是不是很酷！

要進入一個新的技術的真正挑戰其實是，去了解如何讓你需要的東西在產品中處于已經好了的狀態。在以下小節中，我們會列舉你應該在應用中設置什么。

零宕機部署和故障轉移

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

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

優雅停止

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

開啟服務器

完美的服務器停頓

活性探測（健康檢查）

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

網頁服務器健康檢查

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

Worker健康檢查

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

Readiness Probe

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

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

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

我們用 Trace 來檢查我們的應用程序，Trace 充分利用來監控，設想微服務架構。Trace 的服務地圖在理解應用程序間的互相交流的時候到幫了我們很多，同樣，在理解數據庫和外部依賴是什么的時候也起到了作用。

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

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

用 CI 進行連續部署

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

調試

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

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

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

代碼 Piping

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

SSL 終端（https）

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

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

原文鏈接
如果需要轉載，請聯系我們，尊重知識產權人人有責；0