aws eks

到現(xiàn)在，我們已經(jīng)完成了向Amazon EKS （ 工作地點）的遷移，并且集群已經(jīng)投入生產(chǎn)。 過去，我已經(jīng)寫了一些要點的簡短摘要，您可以在這里找到。 當(dāng)系統(tǒng)正在處理實際流量時，我有了一些額外的信心，因此我決定返回此過程，以獲取更具體和透徹的步驟列表和一系列注意事項。 顯然，那里有多家公司一直在使用Amazon的Kubernetes服務(wù)，因此，本文旨在作為EKS遷移和采用案例的另一參考。

平臺–網(wǎng)絡(luò)平臺

整個平臺是一個為網(wǎng)站（電子商店）提供動力的平臺，EKS集群以主動-主動模式運(yùn)行，這意味著它們共享負(fù)載并根據(jù)加權(quán)負(fù)載平衡進(jìn)行相應(yīng)利用。 集群負(fù)載均衡-如果我們可以調(diào)用它的方法是在`進(jìn)行邊緣 '，所以暫時沒有kubernetes聯(lián)盟的概念。 就CPU而言，累計計算總量約為400-600個內(nèi)核（取決于負(fù)載）。 支持該平臺的微服務(wù)的總量在20到30之間，主要是Java有效負(fù)載和混合的節(jié)點（基于Js Node）。 該平臺處于擴(kuò)展?fàn)顟B(tài)，通過向難題添加更多片段以覆蓋更多功能或棄用舊版/舊版系統(tǒng)，系統(tǒng)的熵在不斷增加。

該網(wǎng)站每天提供獨特的頁面瀏覽量，該頁面的瀏覽量范圍為每天50萬（歐洲，英國和亞太地區(qū)的15個市場），由于業(yè)務(wù)性質(zhì)的原因，流量變化很大。 與不忙碌的一天相比，在藝術(shù)家待售或宣布新活動的日子里，點擊量激增導(dǎo)致獨特頁面渲染多出50-70％。 該平臺也是不可預(yù)見的（惡意的）流量的目標(biāo)和目標(biāo)，它會刮擦整個公共API或攻擊某些區(qū)域。

支持上述站點的基礎(chǔ)架構(gòu)應(yīng)提供：

• 彈性–根據(jù)需求收縮和增長–還提供了基于手動干預(yù)的能力，可以在我們事先知道何時會出現(xiàn)激增的情況下進(jìn)行。
• 穩(wěn)定性–始終可用，始終為頁面和API響應(yīng)提供服務(wù)
• 容忍故障，通常要考慮到不同AWS az或整個區(qū)域的潛在故障。
• 成本效益，隨著時間的推移降低運(yùn)營成本（AWS使用成本）
• 安全
• 對開發(fā)團(tuán)隊公平開放。 對于一個單獨的團(tuán)隊來說，部署和理解kubernetes是開發(fā)團(tuán)隊關(guān)注的問題，而不是一個奇特的操作。

Kubernetes

Kubernetes已經(jīng)成為我們目標(biāo)部署平臺超過2年了。 唯一隨時間變化的是用于旋轉(zhuǎn)新集群的不同工具。 我們已經(jīng)擁有運(yùn)營經(jīng)驗，并且一直以來都在使用不同版本和功能的kubernetes面臨一些挑戰(zhàn)。 盡管存在挑戰(zhàn)，但采用kubernetes被認(rèn)為是成功的。 我們從未遇到過完全的中斷，集群和所實施??的概念也從未偏離手冊中的內(nèi)容（我們確實獲得了彈性，穩(wěn)定性，對部署過程的控制，最后但并非最不重要的一點–采用kubernetes加快了生產(chǎn)和交付NET的道路。商業(yè)價值。

就我們而言，開發(fā)人員從未與基礎(chǔ)架構(gòu)建立如此緊密的關(guān)系。 這種關(guān)系隨著時間的推移而發(fā)展，并有助于提高人們對兩個分離的關(guān)注點（編寫軟件的一方和在生產(chǎn)環(huán)境中操作和運(yùn)行代碼的一方）之間的認(rèn)識。 最大的勝利主要是使開發(fā)人員更加了解基礎(chǔ)架構(gòu)的過程–緩慢地導(dǎo)致軟件開發(fā)方式的潛在改進(jìn)。 顯然，相同的概念適用于任何團(tuán)隊和以云為中心的計劃。 對基礎(chǔ)設(shè)施的抽象化擔(dān)憂降低了將傳統(tǒng)開發(fā)人員轉(zhuǎn)變?yōu)榕c運(yùn)營完全脫節(jié)的障礙。 在那之后，就更深入地挖掘細(xì)節(jié)并明顯地更多地了解基礎(chǔ)架構(gòu)而言，天空是極限。 這個過程需要時間和愿意改變觀念的人們。

EKS為??什么呢？

第一個明顯的答案是因為AWS。 如果AWS是您的主要云，那么您將不斷嘗試盡可能多地利用云的功能，除非您采用不同的方式（例如，您希望通過混合使用不同的解決方案來進(jìn)行云自治對沖，或者您認(rèn)為可以在如果您負(fù)擔(dān)得起，則可以擁有）。 EKS與AWS世界的集成已經(jīng)足夠成熟，您可以在其中運(yùn)行相當(dāng)原始的Kubernetes設(shè)置（而不是愚蠢的），而在幕后則可以利用AWS / ESK為其余AWS生態(tài)系統(tǒng)提供的集成功能。

第二個答案是集群升級和安全補(bǔ)丁。 在發(fā)布EKS之前，我們必須與不同工具（安裝程序）的細(xì)節(jié)一起使用。 在許多情況下，尤其是如果您的云設(shè)置具有自定義配置，試圖使具有自定義網(wǎng)絡(luò)或特殊VPC語義的環(huán)境中的群集變得越來越具有挑戰(zhàn)性。 盡管過去進(jìn)行集群更新，但所涉及的風(fēng)險越來越大，我們很快面臨許多人和公司所面臨的通常的困境（許多人不愿承認(rèn)）–如果要升級現(xiàn)有集群，那就拋棄它并創(chuàng)建一個新的。 在作為解決方案的同時，這還涉及我們許多額外的工作，因此需要在新集群之上重新建立我們的平臺。 顯然，對于我們來說，許多平臺遷移更加自動化需要做更多的工作。

第三個答案是EKS的更新策略。 如果您想按照EKS的規(guī)則玩游戲，則可以在較小的修訂版上自動升級您的主人，然后輕輕地推動您將集群升級到主要版本。 盡管仍然可以選擇不做任何事情，但該模型鼓勵并加速了針對群集更新的自動化開發(fā)。 同樣，這也是信心問題–升級和控制升級過程的頻率越高，您就越有信心。

團(tuán)隊

2個人。 此設(shè)置上最重要的不是團(tuán)隊規(guī)模（2），而是技能組合。 由于我們希望盡可能地接近開發(fā)人員的實際需求，從而最終為企業(yè)服務(wù)，因此我們意識到，這樣的變化不可能在技能真空中發(fā)生。 您不能僅以開發(fā)人員身份配置和旋轉(zhuǎn)基礎(chǔ)架構(gòu)思維，而同時不能構(gòu)建僅由開發(fā)人員考慮操作方面的基礎(chǔ)架構(gòu)，開發(fā)人員將在其中演化和創(chuàng)建平臺。 當(dāng)開發(fā)人員對基礎(chǔ)架構(gòu)安全性或性能等方面的知識不夠充分，或者對監(jiān)控的全面監(jiān)控時，您需要同時擁有Ops的技能和專業(yè)知識，同時提供上述所有知識和知識，以便他們下次進(jìn)行改進(jìn)。

另一方面，當(dāng)開發(fā)人員不容易使用基礎(chǔ)結(jié)構(gòu)，無法訪問或存在看不見的障礙時，會使軟件制造商與其生產(chǎn)系統(tǒng)斷開連接–在這里，開發(fā)人員的觀點可以幫助找到中間立場。 與其他功能相比，迭代和漸進(jìn)式更改是軟件開發(fā)人員通常做得更好的一個領(lǐng)域。

這是當(dāng)前市場上雙方都爭奪控制權(quán)和影響力的最忌諱的事物之一。 我不確定DevOps的正確定義是什么，但是在我看來，這次旅程是DevOps旅程，我希望我在整個職業(yè)生涯中都能在其他地方體驗到它。 結(jié)合團(tuán)隊內(nèi)的技能并鼓勵知識流動，而不是引入組織障礙或隔壁。

側(cè)面關(guān)注– EKS工人網(wǎng)絡(luò)

由于這是我們第一次采用EKS，因此我們決定最安全，更靈活的方法是完全采用AWS CNI網(wǎng)絡(luò)模型。 與我們以前致力于覆蓋網(wǎng)絡(luò)的集群相比，這是一個巨大的變化。 由于Pod具有可路由的IP，因此現(xiàn)在更容易進(jìn)行故障排除和發(fā)現(xiàn)網(wǎng)絡(luò)問題。 看這里 。 遵循原始方法會引起對VPC CDIR大小的擔(dān)憂，我們選擇了一種干凈的解決方案，將群集與共享的VPC隔離開來，并啟動范圍相當(dāng)廣的全新，干凈的新VPC。

如果次要IP地址開始耗盡，或者您的工作人員能力有限（ENI數(shù)量），請參見此處 。 也很好看
在這里 。

工具類

我們的主要目標(biāo)是不破壞現(xiàn)有開發(fā)團(tuán)隊的工作流程和語義，并使我們的EKS集群看起來與現(xiàn)有集群相同。 這并不意味著我們現(xiàn)有的設(shè)置是完美的，或者我們不想進(jìn)行現(xiàn)代化。 同樣，第一要務(wù)是集群應(yīng)該滿足在其上部署服務(wù)的團(tuán)隊的需求，而不是我們一直嘗試新技術(shù)的沖動。 顯然，很多東西是新的和不同的，但是應(yīng)該迭代地介紹配置更改和工具更改。 基本流程如下：

創(chuàng)建集群并建立集群

引入或多或少相同的語義和配置-使團(tuán)隊可以輕松移動其有效載荷（應(yīng)用程序）

穩(wěn)定

逐步教育并開始在群集之上進(jìn)行更多更改，這些更改如新策略，新部署方式或?qū)嵤┬乱?guī)則。 首要任務(wù)是開發(fā)人員的生產(chǎn)率，同時還要兼顧良好實踐和明顯保持簡單 。

為了設(shè)置/升級和配置群集，我們提出了使用以下工具的解決方案

• 地形 （大師和工人/ asg）
• 基于EKS參考支持新AMI的打包程序
• 在terraform生命周期中進(jìn)行bash（通常作為運(yùn)行后步驟調(diào)用）
• 頭盔/ kubectl

工作流程如下：

• 如果要烘焙新的輔助AMI，請使用Packer（如果需要，否則請?zhí)^）
• 計劃并應(yīng)用用于控制母版和工作人員自動縮放組，IAM和其他詳細(xì)信息狀態(tài)的Terraform堆棧，從而形成集群。 即使現(xiàn)在在這里找到的參考EKS模型非常可靠，我們也有自己的terraform模塊。
• 集群形成后開始調(diào)用kubectl或helm，以安裝一些基本服務(wù)。

在集群頂部安裝服務(wù)

一旦在AWS上建立了集群，這意味著主服務(wù)器可以與各個工作程序節(jié)點進(jìn)行對話，我們將在頂部部署并配置以下組件。

安裝頭盔（翻土機(jī)）

根據(jù)我們的RBAC / AWS角色配置aws-auth以啟用對用戶的訪問– kubectl補(bǔ)丁

安裝metrics-server（修改后的舵圖）

安裝AWS Cluster-Autoscaler （頭盔圖）

安裝kubernetes-dashboard（舵圖）

安裝Prometheus / Kube-State-Metrics（Helm Chart）

安裝流利的通配符集（已預(yù)先配置為將日志發(fā)送到ES）（頭盔圖）

安裝或修改kube-proxy的正確版本，請參見此處

安裝或修改aws-cni的正確版本，請參見此處

為CoreDNS安裝修改正確版本+擴(kuò)大coreDNS

擴(kuò)大coreDNS

創(chuàng)建或更新名稱空間

在某些情況下安裝–大使-proxy –混合Ingress。

使用機(jī)密填充群集和特定的名稱空間-已經(jīng)存儲在保險柜中

總體而言，整個業(yè)務(wù)流程由Terraform控制。 集群的結(jié)構(gòu)更改（例如，工作節(jié)點的大小，縮放語義等）在terraform級別上更新。 上面指示的某些Helm圖表在供應(yīng)期間由terraform動態(tài)模板化-因此，所應(yīng)用的Helm圖表已經(jīng)同步并且具有正確的值。 這個想法是，terraform vars可以作為變量傳遞給單獨的kubectl或helm調(diào)用-local_exec和bash提供者的強(qiáng)大功能和簡單性
在這里 。

自動擴(kuò)展組和工作人員細(xì)分

支持實際的群集設(shè)置，并且非常重要的一點是自動擴(kuò)展組，使群集的工作人員處于混亂狀態(tài)。 有幾種模式和技術(shù)，通過在Internet上搜索相關(guān)材料，您會發(fā)現(xiàn)不同的方法或建議。

我們選擇了一個簡單的設(shè)置，將我們的工作人員分為兩個不同的組（自動縮放組/啟動模板）。

• 系統(tǒng)–工人 ：我們將在這些工人上安裝kube系統(tǒng)材料，這些材料將始終為生命周期類型： OnDemand或Reserve實例。 有效載荷如prometheus，集群自動縮放器， coredns pod或有時是大使代理（如果我們也選擇）。
• 普通–工作者 ：將在各種名稱空間上托管我們的應(yīng)用程序容器。 就數(shù)量而言，這是預(yù)計將增長更快的asg。

以上在terraform上的設(shè)置-必須反映并映射到我們在上面定義的一個kubernetes-aws
集群自動縮放器 。

- --namespace=kube-system - --skip-nodes-with-local-storage= false - --skip-nodes-with-system-pods= true - --expander=most-pods - --nodes={{.Values.kubesystemMinSize}}:{{.Values.kubesystemMaxSize}}:{{.Values.kubesystemAsgName}} - --nodes={{.Values.defaultMinSize}}:{{.Values.defaultMaxSize}}:{{.Values.defaultAsgName}}

上面的設(shè)置–要求我們的應(yīng)用程序掌舵表有一個最小的約定。 介紹2個節(jié)點相似性或節(jié)點選擇器規(guī)則。 當(dāng)前，更簡單的方法是通過nodeSelector，即使它們將被棄用。

競價型實例（降低成本！）


通過能夠?qū)ubernetes方面（通過集群自動縮放器配置）與AWS方面分離，尤其是由于我們使用的是terraform，我們現(xiàn)在可以靈活地試驗Spot實例。 我們的主要目標(biāo)是使競價型實例的使用對在集群上部署應(yīng)用程序的人員盡可能透明，并使它成為集群運(yùn)營商的關(guān)注重點。 顯然，所有相關(guān)各方仍應(yīng)意識到廣泛的擔(dān)憂/變化。 集群工作人員的波動性不斷增加，這意味著要在可能會在2分鐘內(nèi)通知的工作人員上運(yùn)行有效負(fù)載，從而帶來了挑戰(zhàn)，這些挑戰(zhàn)是在這些集群上編寫服務(wù)的人們應(yīng)該意識到的。

假設(shè)使用正確的啟動模板和混合實例策略，可以使用2個自動擴(kuò)展組的設(shè)置將競價型實例添加到混合中。 許多人決定將他們的工人分為2個以上的ASG，例如，您可能有5個或10個，而不是2個，在那里您可以更精確地控制所使用的EC2 /類及其生命周期。 此外，您還可以根據(jù)他們的能力或生命周期將Pod /應(yīng)用程序的某些部分定位到特定的工作組。

通常，您需要越精細(xì)的控制，并且您越想對沖終止現(xiàn)貨的風(fēng)險，您就越會傾向于以下策略或選擇。

• 將您的工作人員劃分為不同的功能組 （現(xiàn)場/按需/保留的單個或多個類/混合實例策略
• 增加每個副本集上的Pod的平均數(shù)量 -這樣您就可以對付同一副本集（部署）上的Pod落在同一類型的工人上的風(fēng)險，這些工人可能同時被殺死。
• 多無狀態(tài)少有狀態(tài) 。 這樣一來，您的平臺就可以恢復(fù)持續(xù)遭受的計算或內(nèi)存的微小或輕微故障。 對單例服務(wù)或集中式資源的依賴越多，對沖隨機(jī)中斷的可能性就越大。

現(xiàn)貨實例意味著價格降低，而且意味著終止通知。 考慮終止當(dāng)前模式時，您需要考慮3個因素

AWS區(qū)域（eu-west-1）

AWS可用性（eu-west-1a，eu-west-1b。）

類（m4.xlarge）

上述三重態(tài)通常是通常會影響該類現(xiàn)貨價格的主要因素。 當(dāng)前的策略是您的有效載荷（容器/容器）顯然需要盡可能有效地擴(kuò)散

• 區(qū)域 ：因此不止一個集群
• AZ ：您的ASG應(yīng)該在區(qū)域提供的所有可用區(qū)域上旋轉(zhuǎn)工作人員。
• 班級 ：如果您的ASG是單一班級，則與使用更大的班級列表相比，該班級出現(xiàn)隨機(jī)點終止并影響您的集群的機(jī)會要高。

通常的想法是通過運(yùn)行工作負(fù)載（多區(qū)域/多asg /多類）來規(guī)避現(xiàn)貨實例終止的風(fēng)險。 仍然存在一些風(fēng)險–例如，AWS同時大量退休–現(xiàn)貨資源–或價格快速變化。

這是一個非常棘手的區(qū)域，ASG上的設(shè)置可以幫助您對此進(jìn)行更多套期保值–例如，如果您對價格限制有嚴(yán)格的規(guī)定，則ASG可以遵守，例如“不要出價超出此價格”單一現(xiàn)貨資源”。 使ASG /啟動模板嚴(yán)格控制成本估算的次數(shù)越多，由于此硬限制和價格突然變化，遭受停機(jī)的風(fēng)險就越大。

最靈活的方法是讓ASG為您選擇“最低價格”，因此您可以確保它會盡力找到下一個可用的價格組合，以為您的群集提供計算和內(nèi)存。

在將豆莢散布給不同的工人方面，我認(rèn)為最簡單的建議不是將所有雞蛋都放在一個籃子里。
在這種情況下， Pod Affinity / AntiAffinity規(guī)則是您的第一工具+節(jié)點上的標(biāo)簽。 您可以在這里找到一篇非常不錯的文章。

最后但并非最不重要的。 當(dāng)發(fā)生競價型實例終止時，能夠在集群級別做出React至關(guān)重要，這樣這些工作程序終止不會使集群發(fā)瘋。 發(fā)生的并發(fā)終止越多，您將看到工人和az之間的吊艙移動大浪的風(fēng)險越大。 Kubernetes將嘗試平衡Pod并將其填充到剩余資源中，并明顯地旋轉(zhuǎn)新資源，但實際上，很大程度上取決于能否容忍這些移動并控制Pod的重新調(diào)度方式。 在此區(qū)域，另一個可用的有用工具是kubernetes pod中斷預(yù)算 ，它可以作為kubernetes掌握的另一套規(guī)則-將在資源可用量不斷變化（工作人員進(jìn)出）時考慮在內(nèi)。

最重要的是，為了妥善處理這些終止-實際上需要2分鐘的通知， 這種守護(hù)進(jìn)程（現(xiàn)場終止處理程序）將減輕痛苦，并提供更多可見性。 守護(hù)程序一旦競價型實例收到終止事件，將正常耗盡您的節(jié)點，這又將工作進(jìn)程標(biāo)記為尚未準(zhǔn)備好接收和調(diào)度工作負(fù)載，這又將啟動調(diào)度回合，kubernetes將嘗試將pod放置在其他節(jié)點上如果有足夠的空間或殺死新工人。 最終，系統(tǒng)將嘗試平衡并滿足您的設(shè)置配置和要求-但它實際上取決于您將擁有的并發(fā)終止數(shù)量以及Pod如何在這些工作人員周圍分布。

點差越大，影響越小。 另外，您還可以考慮采取混合政策，其中某些工人始終處于需求狀態(tài)，其余工人處于現(xiàn)貨狀態(tài)，以便您可以對沖更多，更激烈的現(xiàn)貨實例終止事件。

集群升級的擔(dān)憂與困擾

集群更新需要協(xié)調(diào)+建立流程方面的一些工作。 有3種情況：

• 沒有EKS或kubernetes版本更新–僅對安裝在群集頂部的組件進(jìn)行了修改，例如，您想將fluentd-bit更新為較新的版本。
• 需要EKS AMI更新的次要EKS更新（自動模式），使您的工作人員處于相同版本狀態(tài)。
• 主要EKS更新（例如，kubernetes從1.12升級到1.13）–需要AMI更新+一些aws EKS組件更新。

第三種情況是最具挑戰(zhàn)性的一種情況，因為不僅需要根據(jù)AWS的引用提供程序烘焙新的AMI，而且還需要遵循此處定義的組件的約定和版本：

• 核心域名系統(tǒng)
• 庫貝代理
• AWS CNI插件更新。

這意味著，在進(jìn)行更新之前，您需要更新配置腳本（在我們的情況下為terraform變量），以便在新AMI投入生產(chǎn)且我們擁有集群設(shè)置的核心時，能夠進(jìn)行更新或重新配置。 -安裝某些組件。 始終遵循本指南 .AWS的文檔非常可靠。

AWS API節(jié)流和EKS

作為您的最終用戶，AWS主服務(wù)器是一個黑匣子，但強(qiáng)烈建議您默認(rèn)情況下啟用其CloudWatch日志。 與我們之前的集群相比，這對我們來說是巨大的進(jìn)步。 主日志是隔離的并且易于搜索，因此我們避免了過濾或搜索大量日志的麻煩。 另外，請檢查這個非常好的工具，在許多支持情況下， EKS日志收集器通常都會引用該工具。

EKS的其他所有組件的主人都利用AWS API來使事情成真。 這適用于在AWS上運(yùn)行的所有內(nèi)容。 您需要知道的是，如果您在繁忙的集中式AWS賬戶上運(yùn)行，則從不同組件（EC2 / etc）發(fā)出的API調(diào)用上總會有配額。 您的EKS管理員也很健談，他們發(fā)出的API調(diào)用將計入您帳戶的其余調(diào)用中，并記入帳單（它們不是免費(fèi)的，它們會增加配額）。 這意味著您的帳戶何時以及是否發(fā)生AWS API節(jié)制–您的EKS集群也會受到影響，因此請確保您具有適當(dāng)?shù)谋O(jiān)視權(quán)以檢查何時發(fā)生這種情況。 如果節(jié)流時間很多（EKS的內(nèi)部組件無法同步或相互通信的風(fēng)險更大），這意味著整個集群可能開始報告有時無法關(guān)聯(lián)的隨機(jī)錯誤。 這是一個棘手的問題，我真的希望AWS更改EKS主機(jī)對此的政策，并保護(hù)他們免受帳戶可能發(fā)生的API限制。 另一個解決方案是將您的群集“ 裝箱 ”到特定帳戶中，而不是將所有內(nèi)容放到具有單個API配額的單個帳戶中。

在生產(chǎn)中遷移和使用EKS可以說是非常成功的。 顯然，我們的平臺仍在不斷變化，并且會不斷發(fā)生變化。 這同樣適用于EKS產(chǎn)品，隨著時間的推移，您會看到來自AWS的更改和更新，這是一個非常積極的信號，因為您可以看到AWS對該產(chǎn)品進(jìn)行了投資，并且隨著每一次主要的kubernetes更新，EKS也都在發(fā)展。 另一個積極的事情是來自AWS的支持質(zhì)量，在很多情況下，我們不得不仔細(xì)檢查AWS支持內(nèi)容，我不得不承認(rèn)解決方案和提供的答案非常徹底。

正如我在過去所說的那樣，我認(rèn)為AWS會決定在某個時候為其用戶完成集成之旅，并提供一個交鑰匙解決方案，在該解決方案中，集群的配置將以端到端的方式自動進(jìn)行端對端（主機(jī)，工作人員，插件和設(shè)置） ）。 讓我們來看看。

翻譯自: https://www.javacodegeeks.com/2019/06/configuring-using-aws-eks-production.html

aws eks

總結(jié)

以上是生活随笔為你收集整理的aws eks_在生产中配置和使用AWS EKS的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。