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

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

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

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

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

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

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

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

然后運行以下命令行在Kubernetes中創建namespace。

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

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

在外部，它會使用一個負載均衡器，和一個簡單的IP來導向同樣的service。
用這個內容來創建一個叫做“service.yaml”的文件。

然后在Kubernetes通過運行以下命令來創建。

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

有了對負載均衡器的類型設置，網絡連接負載均衡器會自動創建在谷歌云平臺上，在端口80上進行監聽。
等待網絡負載均衡器的IP地址有了一下bash腳本之后可用。

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

為了在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是如何配置、如何用于你的應用程序的。

既然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的核心概念，告訴你在容器引擎上運行你的應用程序是多么容易，同時也給你一個概覽關于如何自動化部署這一切。

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