摘要：在這篇文章中，我們來看是如何部署應(yīng)用程序到，以及如何將它作為一個公共服務(wù)的。在中的是跟應(yīng)用程序通信的入口。每個除了運行在部署的主要應(yīng)用程序上的也為終端運行。部署是高級別的抽象。

Travix總部位于荷蘭，是一家在線旅游商務(wù)網(wǎng)站，業(yè)務(wù)輻射全球28個國家，成立于2011年，旗下有五個網(wǎng)站：CheapTickets，BudgetAir，Vliegwinkel和Flugladen。公司通過這五個網(wǎng)站的合并形成。Travix同時還隸屬于SGR，ANVR，國際航空運輸協(xié)議和荷蘭家庭購物組織。

在Travix內(nèi)部的100個開發(fā)好的應(yīng)用，有差不多一半是運行在谷歌GCE上面。早在2015年5月，Kubernetes還是Alpha版本的時候，Travix就已經(jīng)開始使用了，從那之后接受它并且將它作為新應(yīng)用程序的默認(rèn)承載平臺來使用。

在這篇文章中，我們來看Travix是如何部署應(yīng)用程序到Kubernetes，以及如何將它作為一個公共服務(wù)的。

在我們開始之前，確認(rèn)你已經(jīng)在Google Cloud console上面創(chuàng)建了一個谷歌GCE集群，并且已經(jīng)安裝了gcloud命令行工具，配置在你的電腦上。
kubectl命令行工具可以通過gcloud cli來安裝。

有了以下命令你就可以安裝kubectl來跟你的集群進行交流。確認(rèn)為你自己的集群用正確的值來替代名字和zone。

在Kubernetes中，你在其中的一個namespace中運行你的應(yīng)用程序；在同一個namespace中，你就可以通過service名字來發(fā)現(xiàn)其它應(yīng)用程序。隔離的namespace允許你在不同的namespace重新使用相同的service名，目的是運行在這些namespace上的應(yīng)用程序。這就允許你在同一個集群上創(chuàng)建不同的“環(huán)境”，如果你想要創(chuàng)建的話。開發(fā)，測試，驗收和生產(chǎn)，你需要創(chuàng)建4個多帶帶的namespace。

Namespace是用來設(shè)置其他組件的，所以讓我們從創(chuàng)建namespace開始吧！用以下內(nèi)容保存一個命名為“namespace.yaml”的文件。

然后運行以下命令行在Kubernetes中創(chuàng)建namespace。

在Kubernetes中的service是跟應(yīng)用程序通信的入口。它可以用來訪問Kubernetes集群內(nèi)部的應(yīng)用程序，也可以通過連接到公共網(wǎng)絡(luò)的外部負載均衡器來暴露應(yīng)用程序。我們這里要做的是后者。

在外部，你可以用URL： http：／／/.來訪問service。只要是在同一個namespace，那么它就會自動解析到service。當(dāng)配置為一個外部的負載均衡service的時候，也仍然是可行的。

在外部，它會使用一個負載均衡器，和一個簡單的IP來導(dǎo)向同樣的service。
用這個內(nèi)容來創(chuàng)建一個叫做“service.yaml”的文件。

然后在Kubernetes通過運行以下命令來創(chuàng)建。

在service中，選擇器用來直接跟所有的應(yīng)用程序通信，方法是通過匹配的標(biāo)簽。應(yīng)用程序需要用相同的名稱作為端口用于targetport。在這個案例中，我們將端口命名為http，你之后會在配置清單中看到。

有了對負載均衡器的類型設(shè)置，網(wǎng)絡(luò)連接負載均衡器會自動創(chuàng)建在谷歌云平臺上，在端口80上進行監(jiān)聽。
等待網(wǎng)絡(luò)負載均衡器的IP地址有了一下bash腳本之后可用。

你現(xiàn)在可以使用這個IP來連接到service，或者為它設(shè)置一個DNS記錄。在Travix，是從部署腳本自動這么做的。

為了在Kubernetes上運行容器，所以使用了“pod”這樣一個概念。Pod就是一個或者多個關(guān)系很近的容器組。他們一起開啟或者一起運行，并且是在同一個主機上面。

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

在pod中，localhost解析到pod，而不是由主機來運行pod。這就可以用來讓多個應(yīng)用程序運行在同一個pod上互相進行交流，這個過程使用localhost和應(yīng)用程序監(jiān)聽的原始端口就可以。這樣在pod中的交流更快，更安全，因為這樣不會攻擊網(wǎng)絡(luò)。

在Travix，我們用pod來將一些橫切關(guān)注點移出我們的應(yīng)用程序，轉(zhuǎn)移到專用容器。每個pod——除了運行在部署的主要應(yīng)用程序上的——也為TLS終端運行HAProxy。在這篇博客中，我們就只是在pod中運行單個容器。接下來你會看到一個pod是如何配置、如何用于你的應(yīng)用程序的。

既然service已經(jīng)設(shè)置了，那么它就沒有地方來發(fā)送通信了，因為service中沒有帶標(biāo)簽的pod來跟選擇器匹配。Kubernetes中的這些service與pods之間的解耦允許創(chuàng)建，任意的順序都可以。

創(chuàng)建這些pod，最簡單的方法就是使用部署對象，即使是在測試版都可以。它使用了一個清單，這個清單指定容器在pod中運行什么，指定什么環(huán)境變量注入到這些容器中，哪個端口被暴露，以及什么pod被設(shè)置什么標(biāo)簽。

部署是高級別的抽象。創(chuàng)建的時候，它會創(chuàng)建一個ReplicaSet來負責(zé)一些pod的創(chuàng)建，相當(dāng)于配置一定數(shù)量的副本。對于每個新的部署來說，一個新的ReplicaSet被創(chuàng)建了，但是為了快速回滾，它會保持原來的那些，ReplicaSet的最大值相當(dāng)于revisionHistoryLimit的值。部署的滾動更新確保所有舊的ReplicaSet已經(jīng)被更新到0 replicas，并且確保只有最新的pods是在運行的。

用以下內(nèi)容創(chuàng)建一個名為“deployment.yaml”的文件，用你的以及它監(jiān)聽的正確的端口來替代容器鏡像。

為了開啟部署，運行以下命令

Deployment清單中的選擇器被用來匹配Deployment創(chuàng)建的ReplicaSets。當(dāng)重新部署的時候，一定要保持一致，否則它就會創(chuàng)建一個新的ReplicaSet，不需要設(shè)置replica，將其它ReplicaSets設(shè)置為0。

雖然應(yīng)用程序監(jiān)聽端口5000，service使用端口80，但是因為它使用的端口名字——http——所以它就會自動NAT端口，并且從service的用戶角度隱藏這個轉(zhuǎn)換過程。

當(dāng)你想要部署下一個版本，在清單中更新鏡像標(biāo)簽和版本標(biāo)簽，并且重新運行。

就是那么簡單。Depoyment然后就會運行滾動更新用一個新的1每次替代一個pod。這樣的話，當(dāng)只有3個replicas被使用的時候，通常花費的時間不到半分鐘。

Kubectl apply命令不會等待deployment完成，因此你就不得不跳過一些環(huán)節(jié)。

目前，我們就是用以下內(nèi)容來做的。

你可能想要確保你設(shè)置了一個時間上限來等待部署的完成，如果需要長時間使用以下命令回滾。

Bash并沒有模版引擎，但是在清單里面做替換的基本形式，可以按照以下思路來完成。在你的清單中使用變量標(biāo)記，并且確保要使用大括號。

并且運行以下命令來替代清單中的變量，然后從最終清單創(chuàng)建namespace。

或者，如果你安裝了gettext，可以使用更短的命令行。

對于所有的對象來說，我們已經(jīng)使用了能夠重新應(yīng)用的同一個清單，如果它不存在，Kubernetes就會創(chuàng)建一個；或者如果它已經(jīng)存在了，那么Kubernetes就會更新。所以，每次你部署的時候，你可以重新應(yīng)用service、namespace和deployment，不會有副作用。

希望這篇文章呈現(xiàn)給你Kubernetes的核心概念，告訴你在容器引擎上運行你的應(yīng)用程序是多么容易，同時也給你一個概覽關(guān)于如何自動化部署這一切。

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