大約兩年前，我們決定放棄基于Ansible的配置管理設(shè)置，以便在EC2上部署應(yīng)用程序，并轉(zhuǎn)向使用Kubernetes進(jìn)行容器化和編排應(yīng)用程序。我們已將大部分基礎(chǔ)架構(gòu)遷移到Kubernetes。這是一項(xiàng)艱巨的任務(wù)，也有其自身的挑戰(zhàn)-從運(yùn)行混合基礎(chǔ)架構(gòu)的技術(shù)挑戰(zhàn)到完成大部分遷移，再到以全新的運(yùn)營(yíng)模式培訓(xùn)整個(gè)團(tuán)隊(duì)，僅舉幾例。

在這篇文章中，我們想反思我們的經(jīng)驗(yàn)，并與您分享我們?cè)谶@次旅程中的經(jīng)驗(yàn)，以幫助您做出更好的決定并增加成功的機(jī)會(huì)。

[[383951]]

明確說(shuō)明您遷移到Kubernetes的原因

所有那些無(wú)服務(wù)器和容器的東西都很好。如果您要開(kāi)始一項(xiàng)新業(yè)務(wù)并從頭開(kāi)始構(gòu)建所有內(nèi)容，請(qǐng)務(wù)必使用容器來(lái)部署應(yīng)用程序，并在擁有帶寬(或可能不具備)的情況下使用Kubernetes來(lái)編排應(yīng)用程序，并且擁有配置和配置技術(shù)的技能。操作Kubernetes以及在Kubernetes上部署應(yīng)用程序。

即使您將Kubernetes的操作卸載到諸如EKS，GKE或AKS之類的Kubernetes托管服務(wù)上，在Kubernetes上正確部署和操作應(yīng)用程序也需要學(xué)習(xí)。您的開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)該應(yīng)對(duì)挑戰(zhàn)。只有您的團(tuán)隊(duì)遵循DevOps理念，才能實(shí)現(xiàn)很多好處。如果您有中央sysadmin團(tuán)隊(duì)為其他團(tuán)隊(duì)開(kāi)發(fā)的應(yīng)用程序編寫(xiě)清單，那么從DevOps的角度來(lái)看，我們個(gè)人認(rèn)為Kubernetes的好處較小。當(dāng)然，您可以選擇Kubernetes帶來(lái)許多其他好處，例如成本，更快的實(shí)驗(yàn)，更快的自動(dòng)縮放，彈性等。

如果您已經(jīng)在云VM或其他PaaS上進(jìn)行部署，那么為什么真正考慮從現(xiàn)有基礎(chǔ)架構(gòu)遷移到Kubernetes?您是否相信Kubernetes是解決問(wèn)題的唯一方法?您必須清楚自己的動(dòng)機(jī)，因?yàn)閷F(xiàn)有基礎(chǔ)架構(gòu)遷移到Kubernetes是一項(xiàng)艱巨的任務(wù)。

我們?cè)谶@方面犯了一些錯(cuò)誤。我們遷移到Kubernetes的主要原因是建立一個(gè)持續(xù)集成的基礎(chǔ)架構(gòu)，該基礎(chǔ)架構(gòu)可以幫助我們快速重新構(gòu)建微服務(wù)，而這些年來(lái)，這些微服務(wù)一直困擾著許多架構(gòu)。大多數(shù)新功能都需要涉及多個(gè)代碼庫(kù)，因此，一起開(kāi)發(fā)和測(cè)試所有這些功能會(huì)使我們慢下來(lái)。我們認(rèn)為有必要為每個(gè)開(kāi)發(fā)人員和每個(gè)變更提供一個(gè)集成的環(huán)境，以幫助加快開(kāi)發(fā)和測(cè)試周期，而無(wú)需協(xié)調(diào)誰(shuí)來(lái)獲得“共享階段環(huán)境”。

> One of our continuous integration pipelines that provisions a new integrated environment with all the microservices and runs automated tests

我們今天做得很好。我們今天在8分鐘內(nèi)在Kubernetes上的集成環(huán)境中提供了21種微服務(wù)。任何開(kāi)發(fā)人員都可以使用我們自己開(kāi)發(fā)的工具來(lái)執(zhí)行此操作。對(duì)于為這21個(gè)微服務(wù)中的任何一個(gè)創(chuàng)建的每個(gè)拉取請(qǐng)求，我們還提供了該環(huán)境的子集。整個(gè)測(cè)試周期(提供環(huán)境和運(yùn)行測(cè)試)需要不到12分鐘的時(shí)間。可能感覺(jué)很長(zhǎng)，但它阻止了我們?cè)诋?dāng)前所處的體系結(jié)構(gòu)混亂中進(jìn)行重大更改。

> Continuous Integration pipeline execution report

贊!建立所有這些需要什么?我們花了將近1.5年的時(shí)間。那值得嗎?

通過(guò)構(gòu)建其他工具，遙測(cè)并重新部署每個(gè)應(yīng)用程序的方式，我們花了將近1.5年的時(shí)間來(lái)穩(wěn)定這種復(fù)雜的CI設(shè)置。為了實(shí)現(xiàn)開(kāi)發(fā)/產(chǎn)品平價(jià)，我們也必須將所有這些微服務(wù)都部署到生產(chǎn)中，否則，基礎(chǔ)架構(gòu)和部署設(shè)置之間的偏差將使應(yīng)用程序難以為開(kāi)發(fā)人員辯護(hù)，并且本應(yīng)為開(kāi)發(fā)人員做出選擇一個(gè)噩夢(mèng)。

我們對(duì)這個(gè)話題有不同的看法。回顧過(guò)去，我們認(rèn)為解決連續(xù)集成的問(wèn)題變得更加糟糕，因?yàn)閷⑺形⒎?wù)推向生產(chǎn)以實(shí)現(xiàn)開(kāi)發(fā)/產(chǎn)品平價(jià)的復(fù)雜性使得實(shí)現(xiàn)更快的CI的挑戰(zhàn)變得更加復(fù)雜和困難。在使用Kubernetes之前，我們將Ansible與Hashicorp Consul和Vault一起用于基礎(chǔ)架構(gòu)供應(yīng)，配置管理和部署。慢嗎?是的，一點(diǎn)沒(méi)錯(cuò)。但是我們認(rèn)為我們可以通過(guò)Consul引入服務(wù)發(fā)現(xiàn)并優(yōu)化Ansible部署，從而在合理的較短時(shí)間內(nèi)就足夠接近我們的目標(biāo)。

我們應(yīng)該遷移到Kubernetes嗎?是的，一點(diǎn)沒(méi)錯(cuò)。使用Kubernetes有很多好處-服務(wù)發(fā)現(xiàn)，更好的成本管理，彈性，治理，對(duì)云基礎(chǔ)架構(gòu)基礎(chǔ)架構(gòu)的抽象等等。今天，我們也收獲了所有這些好處。但這并不是我們開(kāi)始時(shí)的主要目標(biāo)，也許沒(méi)有必要施加自己的壓力和痛苦來(lái)實(shí)現(xiàn)自己的方式。

對(duì)我們來(lái)說(shuō)，一大收獲是，我們本可以采用另一種且抗性較小的方式來(lái)采用Kubernetes。我們只是被Kubernetes收購(gòu)，這是我們甚至不在乎評(píng)估其他選項(xiàng)的唯一解決方案。

我們將在此博客文章中看到，在Kubernetes上進(jìn)行遷移和操作與在云VM或裸機(jī)上進(jìn)行部署不同。您的云工程和開(kāi)發(fā)團(tuán)隊(duì)有一條學(xué)習(xí)曲線。對(duì)于您的團(tuán)隊(duì)來(lái)說(shuō)，值得一試。但是，現(xiàn)在您需要做的是這個(gè)問(wèn)題。您必須嘗試清楚地回答。

開(kāi)箱即用的Kubernetes幾乎對(duì)任何人來(lái)說(shuō)都是遠(yuǎn)遠(yuǎn)不夠的

許多人對(duì)Kubernetes作為PaaS解決方案感到困惑，這不是PaaS解決方案。它是構(gòu)建PaaS解決方案的平臺(tái)。OpenShift就是這樣一個(gè)例子。

開(kāi)箱即用的Kubernetes對(duì)于幾乎任何人來(lái)說(shuō)都是遠(yuǎn)遠(yuǎn)不夠的。這是一個(gè)學(xué)習(xí)和探索的絕佳游樂(lè)場(chǎng)。但是您很可能需要在頂部放置更多基礎(chǔ)結(jié)構(gòu)組件，并將它們很好地結(jié)合在一起，作為應(yīng)用程序的解決方案，以使其對(duì)您的開(kāi)發(fā)人員更有意義。通常，這種帶有附加基礎(chǔ)設(shè)施組件和策略的Kubernetes捆綁包稱為內(nèi)部Kubernetes平臺(tái)。這是一個(gè)非常有用的范例，并且有幾種擴(kuò)展Kubernetes的方法。

度量標(biāo)準(zhǔn)，日志，服務(wù)發(fā)現(xiàn)，分布式跟蹤，配置和秘密管理，CI / CD，本地開(kāi)發(fā)經(jīng)驗(yàn)，對(duì)自定義度量標(biāo)準(zhǔn)的自動(dòng)擴(kuò)展都是需要照顧和做出決定的事情。這些只是我們要呼吁的一些事情。肯定會(huì)有更多的決策和更多的基礎(chǔ)架構(gòu)要建立。一個(gè)重要的方面是您的開(kāi)發(fā)人員將如何使用Kubernetes的資源和清單-在本博客文章的后面將對(duì)此進(jìn)行更多介紹。

這是我們的一些決定和理由。

指標(biāo)

我們最后確定了Prometheus。Prometheus幾乎是事實(shí)上的度量標(biāo)準(zhǔn)基礎(chǔ)結(jié)構(gòu)。CNCF和Kubernetes非常喜歡它。它在Grafana生態(tài)系統(tǒng)中非常有效。而且我們喜歡Grafana!我們唯一的問(wèn)題是我們正在使用InfluxDB。我們已決定從InfluxDB遷移并完全致力于Prometheus。

日志

日志一直是我們的大難題。我們一直在努力使用ELK創(chuàng)建一個(gè)穩(wěn)定的日志記錄平臺(tái)。我們發(fā)現(xiàn)ELK具有我們團(tuán)隊(duì)無(wú)法實(shí)際使用的功能。這些功能需要付出一定的代價(jià)。另外，我們認(rèn)為將Elasticsearch用于日志存在固有的挑戰(zhàn)，使其成為昂貴的日志解決方案。我們由Grafana最終確定了Loki。這很簡(jiǎn)單。它具有滿足我們團(tuán)隊(duì)需求的必要功能。極具成本效益。但最重要的是，由于它的查詢語(yǔ)言與PromQL非常相似，因此它具有出色的UX。此外，它與Grafana搭配使用也很好。這樣一來(lái)，就可以將整個(gè)指標(biāo)監(jiān)視和日志記錄體驗(yàn)集中到一個(gè)用戶界面中。

An example of a Grafana dashboard with visualization over metrics and corresponding logs side-by-sid

配置和密鑰

您會(huì)發(fā)現(xiàn)大多數(shù)文章在Kubernetes中使用configmap和密鑰對(duì)象。我們的學(xué)習(xí)是，它可以幫助您入門，但是對(duì)于我們的用例而言，我們發(fā)現(xiàn)它還遠(yuǎn)遠(yuǎn)不夠。將configmap與現(xiàn)有服務(wù)一起使用需要一定的費(fèi)用。Configmap可以通過(guò)某種方式安裝到pod中-使用環(huán)境變量是最常見(jiàn)的方式。如果您有大量的舊式微服務(wù)從配置管理工具(如Puppet，Chef或Ansible)提供的文件中讀取配置，則您將不得不在所有代碼庫(kù)中重做配置處理，以便現(xiàn)在從環(huán)境變量中進(jìn)行讀取。我們沒(méi)有找到足夠的理由在合理的情況下執(zhí)行此操作。此外，配置或機(jī)密的更改意味著您將必須通過(guò)打補(bǔ)丁來(lái)重新部署您的部署。這將是kubectl命令的額外命令性編排。

> Design by Asif Jamal

為了避免所有這些情況，我們決定使用Consul，Vault和Consul模板進(jìn)行配置管理。今天，我們將Consul模板作為初始化容器運(yùn)行，并計(jì)劃將其作為Pod中的Sidecar運(yùn)行，以便它可以監(jiān)視Consul中的配置更改并刷新Vault中即將過(guò)期的密鑰并優(yōu)雅地重新加載應(yīng)用程序進(jìn)程。

CI / CD

在遷移到Kubernetes之前，我們一直在使用Jenkins。遷移到Kubernetes之后，我們決定堅(jiān)持使用詹金斯。到目前為止，我們的經(jīng)驗(yàn)是，Jenkins并不是使用云原生基礎(chǔ)架構(gòu)的最佳解決方案。我們發(fā)現(xiàn)自己使用Python，Bash，Docker和腳本化/聲明性Jenkins管道做了很多工作，以使其全部正常工作。建立和維護(hù)這些工具和管道開(kāi)始變得昂貴。我們現(xiàn)在正在探索Tekton和Argo工作流作為我們的新CI / CD平臺(tái)。您可以在CI / CD環(huán)境中探索更多選項(xiàng)，例如Jenkins X，Screwdriver，Keptn等。

開(kāi)發(fā)經(jīng)驗(yàn)

在開(kāi)發(fā)工作流程中有多種使用Kubernetes的方法。我們主要將選擇權(quán)歸零到兩個(gè)選項(xiàng)-Telepresence.io和Skaffold。Skaffold能夠監(jiān)視您的本地更改并將其不斷部署到您的Kubernetes集群中。另一方面，網(wǎng)真允許您在與Kubernetes集群建立透明網(wǎng)絡(luò)代理的同時(shí)在本地運(yùn)行服務(wù)，以便您的本地服務(wù)可以與Kubernetes中的其他服務(wù)進(jìn)行通信，就好像它已部署在集群中一樣。這是個(gè)人意見(jiàn)和偏好的問(wèn)題。很難決定一種工具。目前，我們主要在嘗試網(wǎng)真，但我們并沒(méi)有放棄Skaffold對(duì)我們來(lái)說(shuō)是更好的工具的可能性。只有時(shí)間會(huì)告訴我們我們決定使用什么，或者也許我們會(huì)同時(shí)使用。還有其他解決方案，例如草稿值得一提。

分布式跟蹤

我們暫時(shí)還沒(méi)有進(jìn)行分布式跟蹤。但是，我們計(jì)劃很快就對(duì)該領(lǐng)域進(jìn)行投資。像日志記錄一樣，我們希望在Grafana旁邊提供度量標(biāo)準(zhǔn)和日志記錄旁邊的分布式跟蹤，以便為我們的開(kāi)發(fā)團(tuán)隊(duì)提供更加集成的可觀察性體驗(yàn)。

應(yīng)用程序打包，部署和工具

Kubernetes的一個(gè)重要方面是考慮開(kāi)發(fā)人員如何與集群進(jìn)行交互并部署其工作負(fù)載。我們希望使事情簡(jiǎn)單易擴(kuò)展。我們正在向Kustomize，Skaffold以及一些本地CRD匯聚，以作為開(kāi)發(fā)人員部署和管理應(yīng)用程序的方式。話雖如此，只要團(tuán)隊(duì)是開(kāi)源的并且建立在開(kāi)放標(biāo)準(zhǔn)之上，那么任何團(tuán)隊(duì)都可以自由地使用他們想與集群進(jìn)行交互的任何工具。

操作Kubernetes集群很困難

我們主要在AWS的新加坡地區(qū)以外運(yùn)營(yíng)。在我們開(kāi)始使用Kubernetes的旅程時(shí)，在新加坡地區(qū)還沒(méi)有提供EKS服務(wù)。因此，我們必須使用kops在EC2上建立自己的Kubernetes集群。

建立一個(gè)基本集群也許并不那么困難。我們能夠在一周內(nèi)建立起第一個(gè)集群。當(dāng)您開(kāi)始部署工作負(fù)載時(shí)，大多數(shù)問(wèn)題都會(huì)發(fā)生。從調(diào)整群集自動(dòng)縮放器到在正確的時(shí)間配置資源，再到正確配置網(wǎng)絡(luò)以實(shí)現(xiàn)正確的性能，您必須自己研究和配置。在大多數(shù)情況下，默認(rèn)設(shè)置在大多數(shù)情況下都不會(huì)起作用(或者至少在那時(shí)對(duì)我們不起作用)。

我們的學(xué)習(xí)是，操作Kubernetes是復(fù)雜的。有很多活動(dòng)部件。而且，學(xué)習(xí)如何操作Kubernetes很可能不是您業(yè)務(wù)的核心。盡可能將負(fù)載卸載到云服務(wù)提供商(EKS，GKE，AKS)。自己進(jìn)行此操作沒(méi)有任何價(jià)值。

您仍然必須考慮升級(jí)

Kubernetes非常復(fù)雜，即使您使用的是托管服務(wù)，升級(jí)也不會(huì)一帆風(fēng)順。

即使使用托管的Kubernetes服務(wù)，也要盡早投資基礎(chǔ)架構(gòu)即代碼的設(shè)置，以使災(zāi)難恢復(fù)和升級(jí)過(guò)程在未來(lái)的痛苦相對(duì)較小，并且能夠在發(fā)生災(zāi)難時(shí)快速恢復(fù)。

如果愿意，您可以嘗試推動(dòng)GitOps。如果您無(wú)法做到這一點(diǎn)，那么將手動(dòng)步驟減少到最低限度是一個(gè)很好的開(kāi)始。我們結(jié)合使用eksctl，terraform和我們的群集配置清單(包括平臺(tái)服務(wù)的清單)來(lái)建立所謂的“ Grofers Kubernetes平臺(tái)”。為了使設(shè)置和部署過(guò)程更簡(jiǎn)單，可重復(fù)，我們建立了一個(gè)自動(dòng)化管道來(lái)設(shè)置新集群并將更改部署到現(xiàn)有集群。

資源請(qǐng)求和限制

開(kāi)始遷移后，由于配置錯(cuò)誤，我們?cè)谌杭杏^察到許多性能和功能問(wèn)題。其結(jié)果之一是在資源請(qǐng)求和限制中添加了許多緩沖區(qū)，以消除資源限制，從而降低性能。

最早的觀察之一是由于節(jié)點(diǎn)上的內(nèi)存限制而導(dǎo)致的逐出。原因是與資源請(qǐng)求相比，資源限制過(guò)高。隨著流量的激增，內(nèi)存消耗的增加可能導(dǎo)致節(jié)點(diǎn)上的內(nèi)存飽和，從而進(jìn)一步導(dǎo)致Pod逐出。

我們的學(xué)習(xí)是將資源請(qǐng)求保持在足夠高的水平，但又不要過(guò)高，以便在低流量時(shí)間內(nèi)浪費(fèi)資源，并使資源限制相對(duì)接近資源請(qǐng)求，以便為尖峰流量留出一定的喘息空間，而不會(huì)由于節(jié)點(diǎn)上的內(nèi)存壓力而驅(qū)逐Pod。限制與請(qǐng)求之間的接近程度取決于您的流量模式。

這不適用于非生產(chǎn)環(huán)境(例如開(kāi)發(fā)，登臺(tái)和CI)。這些環(huán)境不會(huì)帶來(lái)任何流量高峰。從理論上講，如果將CPU請(qǐng)求設(shè)置為零并為容器設(shè)置足夠高的CPU限制，則可以運(yùn)行無(wú)限個(gè)容器。如果您的容器開(kāi)始占用大量CPU，它們將受到限制。您也可以對(duì)內(nèi)存請(qǐng)求和限制執(zhí)行相同的操作。但是，達(dá)到內(nèi)存限制的行為與CPU不同。如果您使用的內(nèi)存超過(guò)了設(shè)置的內(nèi)存限制，則容器將被殺死OOM，然后容器將重新啟動(dòng)。如果您的內(nèi)存限制異常高(例如高于節(jié)點(diǎn)的容量)，則可以繼續(xù)使用內(nèi)存，但是最終，當(dāng)節(jié)點(diǎn)可用內(nèi)存不足時(shí)，調(diào)度程序?qū)㈤_(kāi)始逐出Pod。

在非生產(chǎn)環(huán)境中，我們通過(guò)保持極低的資源請(qǐng)求和極高的資源限制來(lái)盡可能安全地超額分配資源。在這種情況下，限制因素是內(nèi)存，即無(wú)論內(nèi)存請(qǐng)求有多低和內(nèi)存限制有多高，pod逐出都是節(jié)點(diǎn)上調(diào)度的所有容器使用的內(nèi)存總和的函數(shù)。

安全與治理

Kubernetes旨在為開(kāi)發(fā)人員解鎖云平臺(tái)，使其更加獨(dú)立，并推動(dòng)DevOps文化。向開(kāi)發(fā)人員開(kāi)放平臺(tái)，減少云工程團(tuán)隊(duì)(或系統(tǒng)管理員)的干預(yù)以及使開(kāi)發(fā)團(tuán)隊(duì)獨(dú)立應(yīng)該是重要目標(biāo)之一。

有時(shí)，這種獨(dú)立性可能會(huì)帶來(lái)嚴(yán)重的風(fēng)險(xiǎn)。例如，默認(rèn)情況下，在EKS中使用LoadBalancer類型服務(wù)會(huì)配置面向ELB的公共網(wǎng)絡(luò)。添加某些注釋將確保提供內(nèi)部ELB。我們?cè)谠缙诰头噶艘恍╁e(cuò)誤。

我們使用開(kāi)放策略代理來(lái)減少各種安全風(fēng)險(xiǎn)，以及降低成本，安全和技術(shù)債務(wù)相關(guān)的風(fēng)險(xiǎn)。

部署Open Policy Agent以構(gòu)建正確的控件有助于自動(dòng)化整個(gè)變更管理過(guò)程，并為我們的開(kāi)發(fā)人員構(gòu)建正確的安全網(wǎng)。借助Open Policy Agent，我們可以限制如前所述的方案-除非存在正確的注釋，否則可以限制創(chuàng)建服務(wù)對(duì)象，以免開(kāi)發(fā)人員意外創(chuàng)建公共ELB。

成本

遷移后，我們看到了巨大的成本優(yōu)勢(shì)。但是，并非所有好處都會(huì)立即產(chǎn)生。

注意：我們正在整理有關(guān)我們最近的成本優(yōu)化計(jì)劃得更詳細(xì)的文章。提防Lambda。

更好地利用資源容量

這是最明顯的一個(gè)。今天，我們的基礎(chǔ)架構(gòu)所配置的計(jì)算，內(nèi)存和存儲(chǔ)遠(yuǎn)遠(yuǎn)少于以前。除了由于更好地包裝容器/過(guò)程而提高了容量利用率之外，我們還能夠比以前更好地利用我們的共享服務(wù)，例如過(guò)程的可觀察性(指標(biāo)，日志)。

但是，最初，我們?cè)谶w移時(shí)浪費(fèi)了大量資源。由于我們無(wú)法正確調(diào)整自我管理的Kubernetes集群，從而導(dǎo)致大量性能問(wèn)題，因此我們最終要求在Pod中使用大量資源作為緩沖區(qū)，更像是保險(xiǎn)，以減少因出現(xiàn)故障或性能問(wèn)題而導(dǎo)致的機(jī)會(huì)缺乏計(jì)算或內(nèi)存。

由于存在較大的資源緩沖區(qū)，導(dǎo)致高昂的基礎(chǔ)架構(gòu)成本是一個(gè)大問(wèn)題。由于我們應(yīng)該擁有Kubernetes，我們并沒(méi)有真正實(shí)現(xiàn)容量利用的任何好處。在遷移到EKS之后，觀察到它帶來(lái)的穩(wěn)定性使我們變得更加自信，這幫助我們采取了必要的步驟來(lái)糾正資源需求并大幅度減少資源浪費(fèi)。

實(shí)例

與Kubernetes一起使用競(jìng)價(jià)型實(shí)例比在原始VM上使用競(jìng)價(jià)型實(shí)例要容易得多。使用VM，您可以自己管理競(jìng)價(jià)型實(shí)例，這可能會(huì)有些復(fù)雜性，無(wú)法確保您的應(yīng)用程序具有適當(dāng)?shù)恼＿\(yùn)行時(shí)間，或者使用SpotInst等服務(wù)。Kubernetes同樣適用，但是Kubernetes帶來(lái)的資源效率可以為您留出足夠的空間來(lái)保留一些緩沖區(qū)，以便即使集群中的幾個(gè)實(shí)例被中斷，在其上安排的容器也可以在其他地方快速重新安排。有一些選項(xiàng)可以有效地管理現(xiàn)場(chǎng)中斷。

競(jìng)價(jià)型實(shí)例幫助我們節(jié)省了大量資金。今天，我們整個(gè)階段的Kubernetes集群都在競(jìng)價(jià)型實(shí)例上運(yùn)行，而我們的生產(chǎn)Kubernetes集群的99%都由預(yù)留實(shí)例，節(jié)省計(jì)劃和競(jìng)價(jià)型實(shí)例覆蓋。

優(yōu)化的下一步是如何在競(jìng)價(jià)型實(shí)例上運(yùn)行整個(gè)生產(chǎn)集群。在另一篇博客文章中，有關(guān)此主題的更多信息。

ELB合并

我們使用Ingress在舞臺(tái)環(huán)境中整合了ELB，并大幅降低了ELB的固定成本。為了避免這種情況導(dǎo)致代碼之間出現(xiàn)開(kāi)發(fā)/產(chǎn)品差異，我們決定實(shí)現(xiàn)一個(gè)控制器，該控制器會(huì)將LoadBalancer類型服務(wù)與我們階段集群中的入口對(duì)象一起更改為NodePort類型服務(wù)。

對(duì)于我們來(lái)說(shuō)，向Nginx入口的遷移相對(duì)簡(jiǎn)單，并且由于采用了控制器方法，因此無(wú)需進(jìn)行大量更改。如果我們也將ingress用于生產(chǎn)中，則可以節(jié)省更多的錢。這不是一個(gè)簡(jiǎn)單的變化。在以正確的方式配置生產(chǎn)的入口時(shí)，必須考慮幾個(gè)方面，并且還必須從安全性和API管理的角度來(lái)考慮。這是我們打算在不久的將來(lái)工作的領(lǐng)域。

增加跨可用區(qū)AZ數(shù)據(jù)傳輸

盡管我們節(jié)省了很多基礎(chǔ)架構(gòu)支出，但仍有一部分基礎(chǔ)架構(gòu)成本增加了-跨可用區(qū)數(shù)據(jù)傳輸。

可以在任何節(jié)點(diǎn)上配置Pod。即使您控制Pod在群集中的分布方式，也沒(méi)有一種簡(jiǎn)單的方法來(lái)控制服務(wù)如何以一種服務(wù)的Pod與同一AZ中的另一服務(wù)的Pod交談的方式來(lái)發(fā)現(xiàn)彼此，以減少跨可用區(qū)的數(shù)據(jù)轉(zhuǎn)移。

經(jīng)過(guò)與其他公司的同行進(jìn)行大量研究和交談之后，我們了解到可以通過(guò)引入服務(wù)網(wǎng)格來(lái)控制如何將流量從Pod路由到目標(biāo)Pod來(lái)實(shí)現(xiàn)。我們還沒(méi)有準(zhǔn)備好為了節(jié)省跨可用區(qū)數(shù)據(jù)傳輸?shù)某杀径约撼袚?dān)操作服務(wù)網(wǎng)格的復(fù)雜性。

CRD，Operator和控制器–邁向簡(jiǎn)化運(yùn)營(yíng)的一步和更全面的體驗(yàn)

每個(gè)組織都有自己的工作流程和運(yùn)營(yíng)挑戰(zhàn)。我們也有我們的。

在我們使用Kubernetes的兩年旅程中，我們了解到Kubernetes很棒，但是當(dāng)您使用控制器，Operator和CRD等功能來(lái)簡(jiǎn)化日常操作并為開(kāi)發(fā)人員提供更集成的體驗(yàn)時(shí)，Kubernetes會(huì)更好。

我們已經(jīng)開(kāi)始投資大量的控制器和CRD。例如，LoadBalancer服務(wù)類型到入口的轉(zhuǎn)換是控制器操作。同樣，只要部署了新服務(wù)，我們就會(huì)使用控制器在DNS提供程序中自動(dòng)創(chuàng)建CNAME記錄。這些是幾個(gè)例子。我們還有其他5個(gè)單獨(dú)的用例，它們依靠我們的內(nèi)部控制器來(lái)簡(jiǎn)化日常操作并減少工作量。

我們還建立了一些CRD。通過(guò)聲明指定應(yīng)使用哪些監(jiān)視儀表板，其中之一已在當(dāng)今廣泛用于在Grafana上生成監(jiān)視儀表板。這使開(kāi)發(fā)人員可以在其應(yīng)用程序代碼庫(kù)旁邊嵌入其監(jiān)視儀表板，并使用相同的工作流(kubectl apply -f)部署所有內(nèi)容。。

我們正在大量看到控制者和CRD的好處。當(dāng)我們與云供應(yīng)商AWS緊密合作以簡(jiǎn)化集群基礎(chǔ)架構(gòu)操作時(shí)，我們就騰出了更多精力專注于構(gòu)建“ Grofers Kubernetes平臺(tái)”，該平臺(tái)旨在以最佳方式支持我們的開(kāi)發(fā)團(tuán)隊(duì)。

原文鏈接：https://lambda.grofers.com/learnings-from-two-years-of-kubernetes-in-production-b0ec21aa2814