Travix是如何部署應用程序到Kubernetes上的

在Travix內部的100個開發好的應用，有差很少一半是運行在谷歌GCE上面。早在2015年5月，Kubernetes仍是Alpha版本的時候，Travix就已經開始使用了，從那以後接受它而且將它做爲新應用程序的默認承載平臺來使用。

在這篇文章中，咱們來看Travix是如何部署應用程序到Kubernetes，以及如何將它做爲一個公共服務的。

鏈接到Kubernetes

在咱們開始以前，確認你已經在Google Cloud console上面建立了一個谷歌GCE集羣，而且已經安裝了gcloud命令行工具，配置在你的電腦上。

kubectl命令行工具能夠經過gcloud cli來安裝。

有了如下命令你就能夠安裝kubectl來跟你的集羣進行交流。確認爲你本身的集羣用正確的值來替代名字和zone。

Namespace

在Kubernetes中，你在其中的一個namespace中運行你的應用程序；在同一個namespace中，你就能夠經過service名字來發現其它應用程序。隔離的namespace容許你在不一樣的namespace從新使用相同的service名，目的是運行在這些namespace上的應用程序。這就容許你在同一個集羣上建立不一樣的「環境」，若是你想要建立的話。開發，測試，驗收和生產，你須要建立4個單獨的namespace。

Namespace是用來設置其餘組件的，因此讓咱們從建立namespace開始吧！用如下內容保存一個命名爲「namespace.yaml」的文件。

而後運行如下命令行在Kubernetes中建立namespace。

Service

在Kubernetes中的service是跟應用程序通訊的入口。它能夠用來訪問Kubernetes集羣內部的應用程序，也能夠經過鏈接到公共網絡的外部負載均衡器來暴露應用程序。咱們這裏要作的是後者。

在外部，你能夠用URL：  http：／／<service name>/.來訪問service。只要是在同一個namespace，那麼它就會自動解析到service。當配置爲一個外部的負載均衡service的時候，也仍然是可行的。

在外部，它會使用一個負載均衡器，和一個簡單的IP來導向一樣的service。

用這個內容來建立一個叫作「service.yaml」的文件。

而後在Kubernetes經過運行如下命令來建立。

在service中，選擇器用來直接跟全部的應用程序通訊，方法是經過匹配的標籤。應用程序須要用相同的名稱做爲端口用於targetport。在這個案例中，咱們將端口命名爲http，你以後會在配置清單中看到。

有了對負載均衡器的類型設置，網絡鏈接負載均衡器會自動建立在谷歌雲平臺上，在端口80上進行監聽。

等待網絡負載均衡器的IP地址有了一下bash腳本以後可用。

你如今可使用這個IP來鏈接到service，或者爲它設置一個DNS記錄。在Travix，是從部署腳本自動這麼作的。

Pod

爲了在Kubernetes上運行容器，因此使用了「pod」這樣一個概念。Pod就是一個或者多個關係很近的容器組。他們一塊兒開啓或者一塊兒運行，而且是在同一個主機上面。

每一個Pod在Kubernetes集羣上都有一個專用的IP地址。多個pod能夠運行在同一個主機上，同時，pod之間又是互相獨立的。應用程序在不一樣的pod中可使用相同的端口進行交流而不會引發任何問題。在pod以外，他們的端口是被NAT的，容許多個應用程序使用同一個端口在同一個主機上運行。

在pod中，localhost解析到pod，而不是由主機來運行pod。這就能夠用來讓多個應用程序運行在同一個pod上互相進行交流，這個過程使用localhost和應用程序監聽的原始端口就能夠。這樣在pod中的交流更快，更安全，由於這樣不會攻擊網絡。

在Travix，咱們用pod來將一些橫切關注點移出咱們的應用程序，轉移到專用容器。每一個pod——除了運行在部署的主要應用程序上的——也爲TLS終端運行HAProxy。在這篇博客中，咱們就只是在pod中運行單個容器。接下來你會看到一個pod是如何配置、如何用於你的應用程序的。

 

Deployment

既然service已經設置了，那麼它就沒有地方來發送通訊了，由於service中沒有帶標籤的pod來跟選擇器匹配。Kubernetes中的這些service與pods之間的解耦容許建立，任意的順序均可以。

建立這些pod，最簡單的方法就是使用部署對象，即便是在測試版均可以。它使用了一個清單，這個清單指定容器在pod中運行什麼，指定什麼環境變量注入到這些容器中，哪一個端口被暴露，以及什麼pod被設置什麼標籤。

部署是高級別的抽象。建立的時候，它會建立一個ReplicaSet來負責一些pod的建立，至關於配置必定數量的副本。對於每一個新的部署來講，一個新的ReplicaSet被建立了，可是爲了快速回滾，它會保持原來的那些，ReplicaSet的最大值至關於revisionHistoryLimit的值。部署的滾動更新確保全部舊的ReplicaSet已經被更新到0 replicas，而且確保只有最新的pods是在運行的。

用如下內容建立一個名爲「deployment.yaml」的文件，用你的以及它監聽的正確的端口來替代容器鏡像。

爲了開啓部署，運行如下命令

 

Deployment清單中的選擇器被用來匹配Deployment建立的ReplicaSets。當從新部署的時候，必定要保持一致，不然它就會建立一個新的ReplicaSet，不須要設置replica，將其它ReplicaSets設置爲0。

雖然應用程序監聽端口5000，service使用端口80，可是由於它使用的端口名字——http——因此它就會自動NAT端口，而且從service的用戶角度隱藏這個轉換過程。

 

部署新版本

當你想要部署下一個版本，在清單中更新鏡像標籤和版本標籤，而且從新運行。

就是那麼簡單。Depoyment而後就會運行滾動更新用一個新的1每次替代一個pod。這樣的話，當只有3個replicas被使用的時候，一般花費的時間不到半分鐘。

Kubectl apply命令不會等待deployment完成，所以你就不得不跳過一些環節。

目前，咱們就是用如下內容來作的。

 

你可能想要確保你設置了一個時間上限來等待部署的完成，若是須要長時間使用如下命令回滾。

模版清單

Bash並無模版引擎，可是在清單裏面作替換的基本形式，能夠按照如下思路來完成。在你的清單中使用變量標記，而且確保要使用大括號。

而且運行如下命令來替代清單中的變量，而後從最終清單建立namespace。

或者，若是你安裝了gettext，可使用更短的命令行。

對於全部的對象來講，咱們已經使用了可以從新應用的同一個清單，若是它不存在，Kubernetes就會建立一個；或者若是它已經存在了，那麼Kubernetes就會更新。因此，每次你部署的時候，你能夠從新應用service、namespace和deployment，不會有反作用。

但願這篇文章呈現給你Kubernetes的核心概念，告訴你在容器引擎上運行你的應用程序是多麼容易，同時也給你一個概覽關於如何自動化部署這一切。

 

（若是須要轉載，請聯繫咱們哦，尊重知識產權人人有責:）