摘要：使用這個工具是由的幾個人創(chuàng)建的。它最厲害的地方在于，在下，使用，這對于我們來說有利無弊。在我們的這個案例中，我們添加集群層面的日志記錄，攝取應(yīng)用程序日志到，用和進(jìn)行集群監(jiān)控，基于的授權(quán)認(rèn)證，以及一些其它的事情。

在過去一年內(nèi)，Descomplica 計劃往核心組件服務(wù)化的方向發(fā)展，我們一開始使用 Elastic Beanstalk 將這些服務(wù)編排到 AWS。

那時候來說，這個決定是明智的?？傮w來說，Elastic Beanstalk 挺好用的，而且比較容易學(xué)習(xí)；所有小組為他們各自的項目使用，也不會花費太多時間。

早在幾個月之前，一切都還運行得好好的。但是在一些舊問題解決之后，新的問題接踵而至。

在 Elastic Beanstalk，每個 EC2 實例只運行一個應(yīng)用程序容器。這也就意味著，如果你遵循可靠性最佳實踐，一個應(yīng)用程序就會有兩個或者多個實例（跨越部署在多個可用域）。除了生產(chǎn)環(huán)境，如果你還有其他環(huán)境的話（比如預(yù)生產(chǎn)環(huán)境），那么你可能就需要更多實例。

無論如何，你都要為每個服務(wù)根據(jù)不同的工作負(fù)載部署多個專用實例，并且大部分時間這些實例都很閑。

我們需要找到一個方法更加明智地使用我們的可用計算資源。

后來我們才發(fā)現(xiàn)，Kubernetes 就是我們一直在尋找的 ECS 的替代品。

Kubernetes 是一個容器編排工具，建立在谷歌 15 年運行產(chǎn)品的基礎(chǔ)之上，與最佳想法、社區(qū)實踐相結(jié)合。

雖然 Kubernetes 是一個功能豐富的項目，但是只有其中的幾個關(guān)鍵功能引起了我們的注意：命名空間，自動滾動升級和回滾，通過 DNS 的服務(wù)發(fā)現(xiàn)，基于資源使用的容器自動擴(kuò)容，以及，允諾的自我修復(fù)系統(tǒng)。

Kubernetes 圍繞“容器應(yīng)該如何被組織，如何通過網(wǎng)絡(luò)聯(lián)絡(luò)”的理念，但是如果你的服務(wù)是遵從 Twelve－Factor 實踐的，那么這個理念對你來說也不是什么問題。

為了確保 Kubernetes 是個可行的選擇，我們做的第一件事就是做些可靠性測試來確保它能夠處理“不可用節(jié)點，Kubelet／Proxy／Docker daemons 終止，和可用區(qū)域運行中斷”這類的故障模式。

預(yù)測所有的故障，這是不太可能的，但是最后，我們還是被 Kubernetes 解決這些故障的能力深深折服。

那時候，我們用 kube－up 來創(chuàng)建我們的測試集群。雖然這個工具按照它的目標(biāo)來服務(wù)，但不是每一次都符合預(yù)期；它暴露出了非常多的問題，比如說不合理的默認(rèn)設(shè)置，隨機(jī)超時導(dǎo)致沒有完全創(chuàng)建成功的程序棧，以及在刪除集群時不確定的行為導(dǎo)致一些資源的遺留。

那時候我們一致同意要選擇用 Kubernetes，所以我們需要一個更加可靠的方法來創(chuàng)建或者刪除 Kubernetes 集群。

使用“kube－aws”

Kube－aws 這個工具是由 CoreOS 的幾個人創(chuàng)建的。它最厲害的地方在于，在 hoods 下，使用 CloudFormation，這對于我們來說有利無弊。

最顯著的優(yōu)點就是，用這個工具創(chuàng)建或者刪除集群十分容易，而且刪除后還不會留下任何的遺留。

另一個功能在于，與 kube－up 不同，你可以在已經(jīng)存在的 VPC 上創(chuàng)建集群，這樣所有運行在 Kubernetes 上的服務(wù)都可以立即訪問你的 AWS 資源（比如關(guān)系型數(shù)據(jù)庫）。

事實上，你可以同時在同一個 VPC 上運行多個集群。這樣就會帶來一個良性的副作用，就是你可以把每個集群都看成是不變的基礎(chǔ)設(shè)施，你不需要修改正在運行的集群——冒著破壞其中一些什么的風(fēng)險，你只需要創(chuàng)建一個新的集群，然后用影響最小的方法慢慢地把流量從舊集群轉(zhuǎn)移到新集群。

最后一個功能（也可能是最有用的一個），你可以通過配置輕松定制集群的任何方面來滿足你的需求。在我們的這個案例中，我們添加集群層面的日志記錄，攝取應(yīng)用程序日志到 Sumologic，用 InfluxDB 和 Grafana 進(jìn)行集群監(jiān)控，基于 ABAC 的授權(quán)認(rèn)證，以及一些其它的事情。

第一個環(huán)境

在解決了集群創(chuàng)建，集群刪除問題之后，我們有信心開始著手遷移我們的預(yù)生產(chǎn)環(huán)境到 Kubernetes了。

為第一個 Deployment 手動創(chuàng)建 yaml 配置十分簡單，但是我們需要自動化地在應(yīng)用鏡像被持續(xù)集成系統(tǒng)構(gòu)建完畢之后立即進(jìn)行部署。

為了證明這個概念，我們很快在 AWS Lambda（基于這篇文章）開辟了一個小的功能，這個功能可以在它收到一個測試通過了的合并通知，自動升級相應(yīng)的部署單。

這個小 Lambda 功能現(xiàn)在涉及到我們的交付管道，也編排 deployments 到其它環(huán)境，包括生產(chǎn)環(huán)境。

有了這個，將預(yù)生產(chǎn)環(huán)境服務(wù)從 Beanstalk 遷移到 Kubernetes 就相當(dāng)容易了。首先，我們?yōu)槊總€服務(wù)（一開始指的是在 Elastic Beanstalk 上遺留的部署）都創(chuàng)建了 DNS 記錄，確保所有的服務(wù)都是通過這個 DNS 互相訪問的。然后，就只要修改這些 DNS 記錄來指向相應(yīng)的 Kubernetes 管理的負(fù)載均衡器。

為了確保管道的每個部分都按照預(yù)期的來運行，我們監(jiān)控所有的預(yù)生產(chǎn)環(huán)境部署，尋找 bug，然后盡我們所能地修復(fù)它，完善功能。

測試得越多，學(xué)習(xí)到得越多

在部署我們的第一個產(chǎn)品服務(wù)到 Kubernetes 之前，我們做了一些壓力測試，來找到每個服務(wù)最佳的資源需求配置，也為了找出我們需要多少 pods 才可以支撐住目前的流量。

觀察你的 services 在負(fù)載下是如何工作的，以及他們需要多少計算量。

同樣，花些時間來理解 Kubernetes 的服務(wù)質(zhì)量等級，這樣你就可以更好地控制哪一個 pod 在內(nèi)存壓力下會被終止掉。如果你跟我們一樣，跟所有環(huán)境都分享了同一個集群，那么這一點對你來說至關(guān)重要。

提示：啟動 Cross－Zone Load Balabcing（AWS）

這一點在 Kubernetes1.4 中已經(jīng)修改，但是現(xiàn)在，如果你通過 LoadBalancer type 來暴露你的服務(wù)，不要忘記為相應(yīng)的 ELB 手動啟動 cross－zone load balancing；如果你沒有這么做，你應(yīng)該會發(fā)現(xiàn)分布在不同的可用域當(dāng)中的應(yīng)用 pod 的負(fù)載不均衡。

提示： 多了解 kube－system

如果你曾經(jīng)嘗試用過 Kubernetes，你可能就會注意到 kube－system namespace 上有非常多的東西；花點時間來理解它們的意義。
比如，拿 DNS add－on 來說；經(jīng)常能看到人們遇到 DNS 問題，因為他們忘記了隨著負(fù)載增長而要增加更多的 DNS Pod。

上線

不要立即轉(zhuǎn)換所有的流量，就如同我們在預(yù)生產(chǎn)環(huán)境中所做的，我們想的是，需要采取一個更加仔細(xì)的方法，用加權(quán)路由規(guī)則，慢慢轉(zhuǎn)換流量到 Kubernetes 集群。

一旦我們注意到已經(jīng)沒有請求可以到達(dá)遺留的 Beanstalk 環(huán)境了，我們就繼續(xù)向前，并且終止他們。

2016，9月21日更新內(nèi)容：
所有主要的服務(wù)都已經(jīng)被遷移到我們新的平臺啦！

以下是最終數(shù)字：
每月減少約53-63％開銷
實例的數(shù)量減少72-82%

Kubernetes 可以用毫不費力的方式塑造交付管道，這是我們想都不敢想的體驗。
我們的開發(fā)環(huán)境就是這樣的一個例子。

無論什么時候有人打開了 Pull Request 給我們一個項目，我之前提到的 AWS Lambda 功能就會創(chuàng)建一個臨時環(huán)境運行 PR 當(dāng)中修改后的代碼。

同樣，無論什么時候 push 新的代碼，一旦他們通過測試，這個環(huán)境就會自動更新。最后，當(dāng) PR 被合并（或者關(guān)閉），環(huán)境也就被刪除了。

這個功能使得我們的代碼審查更加徹底，因為開發(fā)人員能夠看到修改的東西在運行。這對于前端服務(wù)的 UX 來說就更有價值了；設(shè)計師和產(chǎn)品經(jīng)理有機(jī)會看到修改生效，也可以在 PR 合并之前驗證修改和分享想法。為了要發(fā)送 Github Status 通知，可以看到這些圖片中，我們用 Go 實現(xiàn)了一個守護(hù)進(jìn)程，來監(jiān)控到開發(fā)環(huán)境的部署并不斷更新各個版本的部署狀態(tài)。

Kubernetes 是一款很復(fù)雜的軟件，旨在解決復(fù)雜的問題，所以在把它用到你的項目之前要先花點時間了解一下它的那些功能是如何有條理地運行在一起的。

Kubernetes 是為生產(chǎn)準(zhǔn)備的，所以要避免受到誘惑，不要嘗試在它上面運行所有的東西。在我們的經(jīng)驗里，Kubernetes 并沒有給可能遇到的一系列問題提供簡單有效的統(tǒng)一方法，比如說有狀態(tài)應(yīng)用。

其實文檔也不怎么樣，但是比如 Kubernetes Bootcamp 以及 Kelsey Hightower 的《Kubernetes The HardWay》給了我希望，相信在不遠(yuǎn)的將來這些都將不是問題。

如果沒有 Kubernetes，我不知道我們這個小團(tuán)隊要怎么在這么短的時間內(nèi)解決這么多的問題。我們希望繼續(xù)在 Kubernetes 上工作，確保交付平臺更加有活力，更贊！

原文鏈接
轉(zhuǎn)載請聯(lián)系我們 －3-