eks入门教程,为什么需要eks 集群

这类反模式已经为许多研究所证明，比如Puppet的DevOps现状报告或是最近Humanitec的基准测试研究。后面这份报告根据标准的 DevOps 指标（准备时间、部署频率、MTTR 等），对表现最好和最差的组织进行了分组。如下图所示，44%的低效组织存在着上述反模式，有些开发人员要自己完成 DevOps 任务，并帮助经验不足的同事。与此相比，表现最好的组织全部成功实施了真正的“谁构建，谁运行”方法。

那么，低效组织和高效组织之间的关键区别是什么？最好的团队是如何确保他们的开发人员能够运行自己的应用程序和服务，而不需要借助资深同事的不断帮助？你猜对了，他们有一个搭建内部开发平台的平台团队。Puppet的《2020年DevOps现状报告》清楚地说明了内部平台的使用与组织 DevOps 演进程度之间的相关性。

最好的工程组织就是这样做的。他们成立了内部平台团队，负责构建 IDP。在使用这些 IDP 时，开发者可以根据自己的喜好选择合适的抽象级别来运行他们的应用和服务。例如，他们喜欢摆弄 Helm 图表、YAML 文件和 Terraform 模块吗？很好，他们可以这么做。他们是不关心应用是否在 EKS 上运行的新手吗？没问题，他们可以通过自助服务为自己提供一个环境，这个环境包含了他们部署和测试代码所需的一切，而且不用管它在哪里运行。

这里所说的铺就金光大道是什么意思呢？让我们具体看下。如今，大多数 CI/CD 设置的重点都只是简单地更新镜像。CI 构建它们，更新配置中的镜像路径，完成。这覆盖了大多数部署用例。但是，当我们需要做一些基本工作流程之外的事情时，情况就开始变得更加复杂和耗时，例如：

• 增加环境变量和修改配置
• 添加服务和依赖项
• 回滚和调试
• 启动一个新环境
• 重构
• 添加/修改资源
• 强制使用 RBAC
• 
  

这样的例子不胜枚举。平台工程就是为所有这些需求铺好路。平台工程师提供粘合剂，将所有这些操作都绑定到一个一致的自助服务体验中，而不是让每个人什么操作都做，而且还必须了解整个工具链才能做到。

这种粘合剂就是内部平台。用 Evan Bottcher（https://martinfowler.com/articles/talk-about-platforms.html）的话来说，平台是“自助服务 API、工具、服务、知识和技术支持的基础，它们被定位成一个令人信服的内部产品。自主交付团队可以利用该平台更快地交付产品功能，减少协调时间。”

以这个定义为基础，我们可以将内部开发平台定义为“一个自助服务层，旨在让开发人员可以独立操作组织的交付设置，使他们能够通过自助服务获取环境、部署、数据库、日志以及任何他们运行应用程序所需的东西。”

许多组织开始意识到内部开发平台和开发者自助服务所带来的好处。按照 Puppet《2021年DevOps现状报告》的说法，“平台团队的存在并不一定会解锁更高层次的 DevOps；不过，优秀的平台团队会扩大 DevOps 方案的好处。”

然而，招聘合适的人才来构建这样的平台和工作流程并不简单。更麻烦的是，要确保他们始终如一地向工程组织的其他部门提供可靠的产品，并将对方的反馈纳入 IDP。

以下是一些有用的原则，成功的平台团队和自助服务驱动的组织都是以此为主线。

要明确平台团队的任务。例如，“构建可靠的工作流，使工程师们能够独立地操作设置，并针对他们运行应用程序和服务所需的基础设施提供自助服务。”无论对你的团队来说哪块最重要，都要确保一开始就把这个定义好。为平台团队赋予一个明确的角色也极其重要，不应该将平台团队视为另一个按需提供环境的服务台，而应该将其视为一个专门为内部客户服务的产品团队。

关于聚焦产品，我们再展开说明下。平台团队需要秉持产品思维，以内部客户也就是应用开发者的反馈为基础，专注于能够真正为他们提供价值的东西。要保证平台团队基于这个反馈循环来交付功能，而不被刚刚出现的新技术所吸引。

对于内部其他团队共有的问题，平台团队要防止他们处理这些问题时重复发明轮子。找出这些常见问题的关键是：首先要了解导致开发进度放缓的开发痛点和阻力。这些信息既可以是通过开发人员反馈收集的定性信息，也可以通过查看工程 KPI 收集的定量信息。

通常，平台团队会被视为纯粹的成本中心，因为他们不为最终用户提供任何实际的产品功能。他们只是把我们的系统粘合在一起而已。这样的观点非常危险，当然，这种粘合剂非常有价值。平台工程师需要在内部肯定和宣传自己以及自己的价值主张。一旦你们为其他团队设计并铺就了金光大道，那么作为一个平台团队，你们所创造的主要价值是将工具链整合在一起，为工程师们提供顺畅的自助服务工作流。

同样，平台团队应该防止组织内的其他团队重复发明轮子，为同样的问题寻找新的创造性解决方案，他们自己也应该避免犯这样的错误。不管你自己开发的 CI/CD 解决方案多么优秀，商业供应商最终都会迎头赶上。平台团队应该经常问自己有什么不同之处。与其构建内部的 CI 系统或指标仪表板，并与能力强 20 或 50 倍的企业竞争，还不如专注于组织的特定需求，并根据这些需求定制现成的解决方案。无论如何，商业竞争对手更多的是针对行业中比较通用的需求进行优化。

根据Puppet的《2021年DevOps现状报告》，“高度发展的组织往往会遵循 Team Topologies 模式”。

Matthew Skelton 和 Manuel Pais 合著的Team Topologies一书于 2019 年出版，在成功的工程组织中，成为最具影响力的现代团队设置蓝图之一。根据他们描绘的蓝图，团队应该围绕四种基本拓扑结构来设置。