做公章网站,免费申请qq号网页注册,昆明建网站的公司,苏州设计网站建设aws eks到现在#xff0c;我们已经完成了向Amazon EKS #xff08; 工作地点#xff09;的迁移#xff0c;并且集群已经投入生产。 过去#xff0c;我已经写了一些要点的简短摘要#xff0c;您可以在这里找到。 当系统正在处理实际流量时#xff0c;我有了一些额外的信心… 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上建立了集群这意味着主服务器可以与各个工作程序节点进行对话我们将在顶部部署并配置以下组件。 安装头盔翻土机 根据我们的RBAC / AWS角色配置aws-auth以启用对用户的访问– kubectl补丁 安装metrics-server修改后的舵图 安装AWS Cluster-Autoscaler 头盔图 安装kubernetes-dashboard舵图 安装Prometheus / Kube-State-MetricsHelm Chart 安装流利的通配符集已预先配置为将日志发送到ES头盔图 安装或修改kube-proxy的正确版本请参见此处 安装或修改aws-cni的正确版本请参见此处 为CoreDNS安装修改正确版本扩大coreDNS 扩大coreDNS 创建或更新名称空间 在某些情况下安装–大使-proxy –混合Ingress。 使用机密填充群集和特定的名称空间-已经存储在保险柜中 总体而言整个业务流程由Terraform控制。 集群的结构更改例如工作节点的大小缩放语义等在terraform级别上更新。 上面指示的某些Helm图表在供应期间由terraform动态模板化-因此所应用的Helm图表已经同步并且具有正确的值。 这个想法是terraform vars可以作为变量传递给单独的kubectl或helm调用-local_exec和bash提供者的强大功能和简单性 在这里 。 自动扩展组和工作人员细分 支持实际的群集设置并且非常重要的一点是自动扩展组使群集的工作人员处于混乱状态。 有几种模式和技术通过在Internet上搜索相关材料您会发现不同的方法或建议。 我们选择了一个简单的设置将我们的工作人员分为两个不同的组自动缩放组/启动模板。 系统–工人 我们将在这些工人上安装kube系统材料这些材料将始终为生命周期类型 OnDemand或Reserve实例。 有效载荷如prometheus集群自动缩放器 coredns pod或有时是大使代理如果我们也选择。 普通–工作者 将在各种名称空间上托管我们的应用程序容器。 就数量而言这是预计将增长更快的asg。 以上在terraform上的设置-必须反映并映射到我们在上面定义的一个kubernetes-aws 集群自动缩放器 。 - --namespacekube-system - --skip-nodes-with-local-storage false - --skip-nodes-with-system-pods true - --expandermost-pods - --nodes{{.Values.kubesystemMinSize}}:{{.Values.kubesystemMaxSize}}:{{.Values.kubesystemAsgName}} - --nodes{{.Values.defaultMinSize}}:{{.Values.defaultMaxSize}}:{{.Values.defaultAsgName}} 上面的设置–要求我们的应用程序掌舵表有一个最小的约定。 介绍2个节点相似性或节点选择器规则。 当前更简单的方法是通过nodeSelector即使它们将被弃用。 竞价型实例降低成本 通过能够将Kubernetes方面通过集群自动缩放器配置与AWS方面分离尤其是由于我们使用的是terraform我们现在可以灵活地试验Spot实例。 我们的主要目标是使竞价型实例的使用对在集群上部署应用程序的人员尽可能透明并使它成为集群运营商的关注重点。 显然所有相关各方仍应意识到广泛的担忧/变化。 集群工作人员的波动性不断增加这意味着要在可能会在2分钟内通知的工作人员上运行有效负载从而带来了挑战这些挑战是在这些集群上编写服务的人们应该意识到的。 假设使用正确的启动模板和混合实例策略可以使用2个自动扩展组的设置将竞价型实例添加到混合中。 许多人决定将他们的工人分为2个以上的ASG例如您可能有5个或10个而不是2个在那里您可以更精确地控制所使用的EC2 /类及其生命周期。 此外您还可以根据他们的能力或生命周期将Pod /应用程序的某些部分定位到特定的工作组。 通常您需要越精细的控制并且您越想对冲终止现货的风险您就越会倾向于以下策略或选择。 将您的工作人员划分为不同的功能组 现场/按需/保留的单个或多个类/混合实例策略 增加每个副本集上的Pod的平均数量 -这样您就可以对付同一副本集部署上的Pod落在同一类型的工人上的风险这些工人可能同时被杀死。 多无状态少有状态 。 这样一来您的平台就可以恢复持续遭受的计算或内存的微小或轻微故障。 对单例服务或集中式资源的依赖越多对冲随机中断的可能性就越大。 现货实例意味着价格降低而且意味着终止通知。 考虑终止当前模式时您需要考虑3个因素 AWS区域eu-west-1 AWS可用性eu-west-1aeu-west-1b。 类m4.xlarge 上述三重态通常是通常会影响该类现货价格的主要因素。 当前的策略是您的有效载荷容器/容器显然需要尽可能有效地扩散 区域 因此不止一个集群 AZ 您的ASG应该在区域提供的所有可用区域上旋转工作人员。 班级 如果您的ASG是单一班级则与使用更大的班级列表相比该班级出现随机点终止并影响您的集群的机会要高。 通常的想法是通过运行工作负载多区域/多asg /多类来规避现货实例终止的风险。 仍然存在一些风险–例如AWS同时大量退休–现货资源–或价格快速变化。 这是一个非常棘手的区域ASG上的设置可以帮助您对此进行更多套期保值–例如如果您对价格限制有严格的规定则ASG可以遵守例如“不要出价超出此价格”单一现货资源”。 使ASG /启动模板严格控制成本估算的次数越多由于此硬限制和价格突然变化遭受停机的风险就越大。 最灵活的方法是让ASG为您选择“最低价格”因此您可以确保它会尽力找到下一个可用的价格组合以为您的群集提供计算和内存。 在将豆荚散布给不同的工人方面我认为最简单的建议不是将所有鸡蛋都放在一个篮子里。 在这种情况下 Pod Affinity / AntiAffinity规则是您的第一工具节点上的标签。 您可以在这里找到一篇非常不错的文章。 最后但并非最不重要的。 当发生竞价型实例终止时能够在集群级别做出React至关重要这样这些工作程序终止不会使集群发疯。 发生的并发终止越多您将看到工人和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.htmlaws eks
