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

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

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

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

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

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

Kubernetes

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

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

EKS為??什么呢？

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

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

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

團(tuán)隊(duì)

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

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

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

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

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

如果次要熱點(diǎn)IP開始用盡，或者您的工作人員能力有限（ENI數(shù)量），請(qǐng)參見此處 。 也很好看
在這里 。

工具類

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

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

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

穩(wěn)定

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

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

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

工作流程如下：

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

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

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

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

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

安裝指標(biāo)服務(wù)器（修改后的頭盔圖）

安裝aws cluster-autoscaler （頭盔圖）

安裝kubernetes-dashboard（舵圖）

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

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

安裝或修改適用于kube-proxy的正確版本，請(qǐng)參見此處

為aws-cni安裝或修改正確的版本，請(qǐng)參見此處

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

擴(kuò)大核心DNS

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

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

使用機(jī)密填充群集和特定的名稱空間-已存儲(chǔ)在Vault中

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

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

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

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

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

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

- --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個(gè)節(jié)點(diǎn)相似性或節(jié)點(diǎn)選擇器規(guī)則。 當(dāng)前，更簡(jiǎn)單的方法是通過nodeSelector，即使它們將被棄用。

競(jìng)價(jià)型實(shí)例（降低成本！）


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

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

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

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

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

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

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

類（m4.xlarge）

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

• 區(qū)域 ：因此不止一個(gè)集群
• AZ ：您的ASG應(yīng)該在區(qū)域提供的所有可用區(qū)域上旋轉(zhuǎn)工作人員。
• 類別 ：如果您的ASG是單一類別，則該類別成為隨機(jī)點(diǎn)終止并影響您的集群的機(jī)會(huì)要比使用更大的類別列表高。

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

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

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

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

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

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

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

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

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

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

第三種情況是最具挑戰(zhàn)性的一種情況，因?yàn)椴粌H需要基于AWS的引用提供程序來烘焙新的AMI，而且還需要遵循此處定義的組件的約定和版本：

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

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

AWS API節(jié)流和EKS

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

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

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

正如我在過去所說的那樣，我認(rèn)為AWS會(huì)決定在某個(gè)時(shí)候?yàn)槠溆脩敉瓿杉芍?#xff0c;并提供一個(gè)交鑰匙解決方案，在該解決方案中，集群的配置將以端到端的方式自動(dòng)進(jìn)行端對(duì)端（主機(jī)，工作人員，插件和設(shè)置） ）。 讓我們來看看。

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

總結(jié)

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

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