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

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

那時(shí)候來說，這個(gè)決定是明智的。總體來說，Elastic Beanstalk 挺好用的，而且比較容易學(xué)習(xí)；所有小組為他們各自的項(xiàng)目使用，也不會(huì)花費(fèi)太多時(shí)間。

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

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

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

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

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

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

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

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

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

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

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

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

使用“kube－aws”

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

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

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

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

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

第一個(gè)環(huán)境

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

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

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

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

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

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

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

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

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

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

提示：啟動(dòng) Cross－Zone Load Balabcing（AWS）

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

提示： 多了解 kube－system

如果你曾經(jīng)嘗試用過 Kubernetes，你可能就會(huì)注意到 kube－system namespace 上有非常多的東西；花點(diǎn)時(shí)間來理解它們的意義。
比如，拿 DNS add－on 來說；經(jīng)常能看到人們遇到 DNS 問題，因?yàn)樗麄兺浟穗S著負(fù)載增長而要增加更多的 DNS Pod。

上線

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

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

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

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

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

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

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

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

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

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

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

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

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