在生产中配置和使用AWS EKS
到現在，我們已經完成了向Amazon EKS （ 工作地點）的遷移，并且集群已經投入生產。 過去，我已經寫了一些要點的簡短摘要，您可以在這里找到。 當系統正在為實際流量提供服務時，我有了一些額外的信心，因此我決定返回此過程，以獲取更具體和透徹的步驟清單和一系列注意事項。 顯然，那里有多家公司一直在使用Amazon的Kubernetes服務，因此，本文旨在作為EKS遷移和采用案例的另一個參考點。
平臺–網絡平臺
整個平臺是一個為網站（電子商店）提供動力的平臺，EKS集群以主動-主動模式運行，這意味著它們共享負載并根據加權負載平衡進行相應利用。 集群負載均衡-如果我們可以調用它的方法是在`進行邊緣 '，所以暫時沒有kubernetes聯盟的概念。 就CPU而言，累計計算總量約為400-600個內核（取決于負載）。 支持該平臺的微服務的總量在20到30之間，主要是Java有效負載和混合的節點（基于Js Node）。 該平臺處于擴展狀態，通過向難題添加更多片段以覆蓋更多功能或棄用舊版/舊版系統，系統的熵在不斷增加。
該網站每天提供獨特的頁面瀏覽量，該頁面的瀏覽量范圍為每天50萬（歐洲，英國和亞太地區的15個市場），由于業務性質的原因，流量變化很大。 與不忙碌的一天相比，在藝術家待售或宣布新活動的日子里，訪問量的激增導致獨特頁面渲染多出50-70％。 該平臺也是不可預見的（惡意的）流量的目標和目標，它會刮擦整個公共API或攻擊某些區域。
支持上述站點的基礎架構應提供：
- 彈性–根據需求收縮和增長–還提供了基于手動干預的能力，可以在我們事先知道何時會有激增的情況下進行。
- 穩定性–始終可用，始終為頁面和API響應提供服務
- 容忍故障，通常要考慮到不同AWS AZ或整個區域的潛在故障。
- 成本效益，隨著時間的推移降低運營成本（AWS使用成本）
- 安全
- 對開發團隊公平開放。 對于一個單獨的團隊來說，部署和理解kubernetes是開發團隊關注的問題，而不是一個奇特的操作。
Kubernetes
Kubernetes已經成為我們目標部署平臺超過2年了。 唯一隨時間變化的是用于旋轉新集群的不同工具。 我們已經擁有運營經驗，并且一直以來，使用不同版本和功能的kubernetes都面臨著一些挑戰。 盡管存在挑戰，但采用kubernetes被認為是成功的。 我們從未遇到過完全的中斷，集群和所實施??的概念也從未偏離手冊中的內容（我們確實獲得了彈性，穩定性，對部署過程的控制，最后但并非最不重要的一點–采用kubernetes加快了生產和交付NET的道路。商業價值。
就我們而言，開發人員從未與基礎架構建立如此緊密的關系。 這種關系隨著時間的推移而發展，并有助于提高人們對兩個分離的關注點（編寫軟件的一方和在生產環境中操作和運行代碼的一方）之間的認識。 最大的勝利主要是使開發人員更加了解基礎架構的過程–緩慢地導致軟件開發方式的潛在改進。 顯然，相同的概念適用于任何團隊和以云為中心的計劃。 對基礎結構的抽象化擔憂降低了將傳統開發人員轉變為與運營完全脫節的障礙。 在那之后，就更深入地挖掘細節并明顯地更多地了解基礎架構而言，天空是極限。 這個過程需要時間和愿意改變觀念的人們。
EKS為??什么呢？
第一個明顯的答案是因為AWS。 如果AWS是您的主要云，那么您將不斷嘗試盡可能多地利用云的功能，除非您采用不同的方式（例如，您希望通過混合使用不同的解決方案來進行云自治對沖，或者您認為可以在如果您負擔得起，則可以擁有）。 EKS與AWS世界的集成已經足夠成熟，您可以在其中運行相當原始的Kubernetes設置（而不是愚蠢的），而在幕后則可以利用AWS / ESK提供的與其他AWS生態系統集成的功能。
第二個答案是集群升級和安全補丁。 在發布EKS之前，我們不得不與不同工具（安裝程序）的細節打交道。 在許多情況下，尤其是如果您的云設置具有自定義配置，試圖使具有自定義網絡或特殊VPC語義的環境中的群集變得越來越具有挑戰性。 盡管過去進行集群更新，但涉及的風險越來越大，我們很快面臨許多人和公司所面臨的通常的困境（許多人不愿承認）–如果要升級現有集群，那就拋棄它并創建一個新的。 在作為解決方案的同時，這還涉及我們許多額外的工作，需要在新集群之上重新建立我們的平臺。 顯然，對于我們來說，許多平臺遷移更加自動化需要做更多的工作。
第三個答案是EKS的更新策略。 如果您想按照EKS的規則玩游戲，則可以在較小的修訂版本上自動升級主服務器，然后輕輕地推動您將集群升級到主要版本。 盡管仍然可以選擇不做任何事情，但是該模型鼓勵并加速了針對群集更新的自動化開發。 同樣，這也是信心問題–升級和控制升級過程的頻率越高，您就越有信心。
團隊
2個人。 此設置上最重要的不是團隊規模（2），而是技能的組合。 由于我們希望盡可能地接近開發人員的實際需求，從而最終為企業服務，因此我們意識到，這樣的變化不可能在技能真空中發生。 您不能僅以開發人員身份配置和旋轉基礎架構思維，而同時不能構建僅由開發人員考慮操作方面的基礎架構，開發人員將在其中演化和創建平臺。 當開發人員對基礎架構安全性或性能等方面的知識不夠充分或對開發人員進行全面監控時，您需要同時具備這兩項功能，而Ops的技能和專業知識將提供上述所有內容并同時進行教育，以便下次獲得改進。
另一方面，當開發人員不容易使用基礎結構，無法訪問或存在看不見的障礙時，會使軟件制造商與生產系統脫離連接–在這里，開發人員的觀點可以幫助找到中間立場。 與其他功能相比，迭代和漸進式更改是軟件開發人員通常做得更好的一個領域。
這是當前市場上雙方都爭奪控制權和影響力的最忌諱的事物之一。 我不確定DevOps的正確定義是什么，但是在我看來，這次旅程是DevOps旅程，我希望我在整個職業生涯中都能在其他地方體驗到它。 在團隊中結合技能并鼓勵知識流動，而不是引入組織障礙或隔壁。
側面關注– EKS工人網絡
由于這是我們第一次采用EKS，因此我們決定最安全，更靈活的方法是完全采用AWS CNI網絡模型。 與我們以前專注于覆蓋網絡的集群相比，這是一個巨大的變化。 由于Pod具有可路由的IP，因此現在更容易進行故障排除和發現網絡問題。 看這里 。 遵循原始方法會引起對VPC CDIR大小的擔憂，我們選擇了一種干凈的解決方案，將群集與共享的VPC隔離開來，并啟動范圍相當廣的全新，干凈的新VPC。
如果次要熱點IP開始用盡，或者您的工作人員能力有限（ENI數量），請參見此處 。 也很好看
在這里 。
工具類
我們的主要目標不是破壞現有開發團隊的工作流程和語義，而是使我們的EKS集群看起來與現有集群相同。 這并不意味著我們現有的設置是完美的，或者我們不想進行現代化。 同樣，第一要務是集群應滿足在其上部署服務的團隊的需求，而不是我們一直嘗試新技術的沖動。 顯然，有很多東西是新的和不同的，但是應該迭代地介紹配置更改和工具更改。 基本流程如下：
為了設置/升級和配置集群，我們提出了使用以下工具的解決方案
- 地形 （大師和工人/ asg）
- 基于EKS參考支持新AMI的打包程序
- 在terraform生命周期中進行bash（通常作為運行后步驟調用）
- 頭盔/ kubectl
工作流程如下：
- 如果要烘焙新的輔助AMI，請使用Packer（如果需要，否則請跳過）
- 計劃并應用用于控制母版和工作人員自動縮放組，IAM和其他詳細信息狀態的Terraform堆棧，從而形成集群。 即使現在在這里找到的參考EKS模型非常可靠，我們也有自己的terraform模塊。
- 集群形成后開始調用kubectl或helm，以安裝一些基本服務。
在集群頂部安裝服務
一旦在AWS上建立了集群，這意味著主服務器可以與各種工作程序節點進行對話，我們將在頂部部署并配置以下組件。
總體而言，整個業務流程由Terraform控制。 集群的結構更改（例如，工作節點的大小，縮放語義等）在terraform級別上更新。 在供應期間，上面指示的某些Helm圖表由terraform動態地模板化-因此所應用的Helm圖表已經同步并且具有正確的值。 這個想法是，terraform vars可以作為變量傳遞給單獨的kubectl或helm調用-local_exec和bash提供者的強大功能和簡單性
在這里 。
自動擴展組和工作人員細分
支持實際的群集設置，并且非常重要的一點是自動擴展組，使群集的工作人員旋轉。 有幾種模式和技術，通過在Internet上搜索相關材料，您會發現不同的方法或建議。
我們選擇了一個簡單的設置，將我們的工作人員分為兩個不同的組（自動縮放組/啟動模板）。
- 系統–工人 ：我們將在這些工人上安裝kube系統材料，這些材料將始終為生命周期類型： OnDemand或Reserve實例。 有效載荷如prometheus，集群自動縮放器， coredns pod或有時是Ambassador Proxy（如果我們也選擇的話）。
- 普通–工作者 ：將在各種名稱空間上托管我們的應用程序容器。 就數量而言，這是預計將增長更快的asg。
以上在terraform上的設置-必須反映并映射到我們上面定義的一個kubernetes-aws
集群自動縮放器 。
上面的設置–要求最小化我們的應用程序頭盔圖。 介紹2個節點相似性或節點選擇器規則。 當前，更簡單的方法是通過nodeSelector，即使它們將被棄用。
競價型實例（降低成本！）
通過能夠將Kubernetes方面（通過集群自動縮放器配置）與AWS方面分離，尤其是由于我們使用的是terraform，我們現在可以靈活地試驗Spot實例。 我們的主要目標是使競價型實例的使用對在集群上部署應用程序的人員盡可能透明，并使它成為集群運營商的關注點。 顯然，所有相關各方仍應意識到廣泛的擔憂/變化。 集群工作人員的波動性不斷增加，這意味著要在可能會在2分鐘內通知的工作人員上運行有效負載，從而帶來了挑戰，這些挑戰是在這些集群上編寫服務的人們應該意識到的。
假設使用正確的啟動模板和混合實例策略，可以使用2個自動擴展組的設置將競價型實例添加到混合中。 許多人決定將他們的工人分為兩個以上的ASG，例如，您可能有5個或10個，而不是2個，在那里您可以更精確地控制所使用的EC2 /類及其生命周期。 此外，您還可以根據他們的能力或生命周期將Pod /應用程序的某些部分定位到特定的工作組。
通常，您需要越精細的控制，并且您越想對沖終止現貨的風險，您就越會傾向于以下策略或選擇。
- 將您的工作人員劃分為不同的功能組 （現場/按需/保留的單個或多個類/混合實例策略
- 增加每個副本集上的Pod的平均數量 -這樣您就可以對付同一副本集（部署）上的Pod落在同一類型的工人上的風險，這些工人可能同時被殺死。
- 多無狀態少有狀態 。 這樣一來，您的平臺就可以恢復持續遭受的計算/內存的微小或輕微故障。 對單例服務或集中式資源的依賴越多，對沖隨機中斷的可能性就越大。
現貨實例意味著價格降低，但也意味著終止通知。 考慮終止當前模式時，您需要考慮3個因素
上述三重態通常是通常會影響該類現貨價格的主要因素。 當前的策略是您的有效載荷（容器/容器）需要明顯地盡可能有效地散布
- 區域 ：因此不止一個集群
- AZ ：您的ASG應該在區域提供的所有可用區域上旋轉工作人員。
- 類別 ：如果您的ASG是單一類別，則該類別成為隨機點終止并影響您的集群的機會要比使用更大的類別列表高。
總體思路是通過運行工作負載（多區域/多asg /多類）來規避現貨實例終止的風險。 仍然存在一些風險–例如，AWS同時大量退休–現貨資源–或價格快速變化。
這是一個非常棘手的區域，ASG上的設置可以幫助您對此進行更多套期保值–例如，如果您對價格限制有嚴格的規定，則ASG可以遵守，例如“不要出價超出此價格”之類的規則單一現貨資源”。 使ASG /啟動模板嚴格控制成本估算的次數越多，由于此硬限制和價格突然變化，遭受停機的風險就越大。
最靈活的方法是讓ASG為您選擇“最低價格”，因此您可以確保它會盡力找到下一個可用的價格組合，以為您的群集提供計算和內存。
關于將豆莢散布給不同的工人，我認為最簡單的建議不是將所有雞蛋都放在一個籃子里。
在這種情況下， Pod Affinity / AntiAffinity規則是您的第一工具+節點上的標簽。 您可以在這里找到一篇非常不錯的文章。
最后但并非最不重要的。 當發生競價型實例終止時，能夠在集群級別做出反應至關重要，這樣這些工作程序終止不會使集群變得瘋狂。 發生的并發終止越多，您將看到工人和az之間的吊艙移動大浪的風險越大。 Kubernetes將嘗試平衡Pod并將其填充到剩余資源中，并明顯地旋轉新資源，但這確實取決于在很大程度上可以容忍這些運動，并控制Pod的重新調度方式。 在該區域，另一個可供您使用的有用工具是kubernetes pod中斷預算 ，它可以作為kubernetes掌握的另一套規則-將在其資源可用性不斷變化時考慮（意味著工作人員進出）。
最重要的是，為了優雅地處理這些終止，實際上需要2分鐘的通知， 這種守護進程（現場終止處理程序）將減輕痛苦，并提供更多可見性。 守護程序一旦競價型實例收到終止事件，就會正常耗盡您的節點，這又將工作進程標記為尚未準備好接收和調度工作負載，這又將啟動一個調度回合，而kubernetes會嘗試將pod放置在其他節點上如果有足夠的空間或殺死新工人。 最終，系統將嘗試平衡并滿足您的設置配置和要求-但它實際上取決于您將擁有的并發終止數量以及Pod如何在這些工作人員周圍分布。
點差越大，影響越小。 此外，您還可以考慮采用混合策略，其中某些工人始終處于需求狀態，其余工人處于現貨狀態，以便您可以對沖更多，更激烈的現貨實例終止事件。
集群升級的擔憂與困擾
集群更新需要協調+建立流程方面的一些工作。 有3種情況：
- 沒有EKS或kubernetes版本更新–僅對安裝在群集頂部的組件進行了修改，例如，您想將fluentd-bit更新為較新的版本。
- 需要EKS AMI更新的次要EKS更新（自動模式），使您的工作人員處于相同版本狀態。
- 主要EKS更新（例如，kubernetes從1.12升級到1.13）–需要AMI更新+一些aws EKS組件更新。
第三種情況是最具挑戰性的一種情況，因為不僅需要基于AWS的引用提供程序來烘焙新的AMI，而且還需要遵循此處定義的組件的約定和版本：
- 核心域名系統
- 庫貝代理
- AWS CNI插件更新。
這意味著在進行更新之前，您需要更新配置腳本（在我們的情況下為terraform變量），以便在新AMI投入生產并且我們擁有集群設置的核心時，能夠進行更新或重新配置。 -安裝某些組件。 始終遵循本指南 .AWS的文檔非常可靠。
AWS API節流和EKS
作為您的最終用戶，AWS主服務器是一個黑匣子，但強烈建議您默認情況下啟用其CloudWatch日志。 與我們之前的集群相比，這對我們而言是巨大的進步。 主日志是隔離的且易于搜索，因此我們避免了過濾或搜索大量日志的麻煩。 另外，請檢查這個非常好的工具，在許多支持情況下， EKS日志收集器通常都會引用該工具。
EKS的其他所有組件的主人都利用AWS API來使事情成真。 這適用于在AWS上運行的所有內容。 您需要知道的是，如果您在繁忙的集中式AWS賬戶上進行操作，則從不同組件（EC2 / etc）發出的API調用上總會有配額。 您的EKS管理員也很健談，他們發出的API調用將計入您帳戶的其余調用中，并記入帳單中（它們不是免費的，它們會增加配額）。 這意味著您的帳戶何時以及是否發生AWS API節制–您的EKS集群也會受到影響，因此請確保您具有適當的監視權以檢查何時發生這種情況。 如果節流時間很多（EKS的內部組件無法同步或相互通信的風險更大），這意味著整個群集可能開始報告有時無法關聯的隨機錯誤。 這是一個棘手的問題，我真的希望AWS更改EKS主機對此的政策，并保護他們免受帳戶可能發生的API限制。 另一種解決方案是將您的群集“ 裝箱 ”到特定帳戶中，而不是將所有內容放到具有單個API配額的單個帳戶中。
在生產中遷移和使用EKS可以說是非常成功的。 顯然，我們的平臺仍在不斷變化，并且隨著時間的流逝會發生變化。 這同樣適用于EKS產品，隨著時間的推移，您會看到來自AWS的更改和更新，這是一個非常積極的信號，因為您可以看到AWS對該產品進行了投資，并且隨著每一次主要的kubernetes更新，EKS也都在發展。 另一個積極的事情是來自AWS的支持質量，在很多情況下，我們不得不重復檢查AWS支持內容，我不得不承認解決方案和提供的答案非常徹底。
正如我在過去所說的那樣，我認為AWS會決定在某個時候為其用戶完成集成之旅，并提供一個交鑰匙解決方案，在該解決方案中，集群的配置將以端到端的方式自動進行端對端（主機，工作人員，插件和設置） ）。 讓我們來看看。
翻譯自: https://www.javacodegeeks.com/2019/06/configuring-using-aws-eks-production.html
總結
以上是生活随笔為你收集整理的在生产中配置和使用AWS EKS的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 剧集综艺爆款不断 王晓晖揭秘爱奇艺创作方
- 下一篇： 处理异常功能样式