启动内部Kubernetes产品
Kubernetes已经成为集装箱化世界的新标准。开发团队可以利用各种有用的抽象，以可靠的方式编排容器。尽管Kubernetes很有魅力，但它是一个非常复杂的平台。操作和维护它需要一支技术高超的团队。在本文中，我想分享一下我们是如何解决构建内部Kubernetes产品的问题，以帮助我们的开发团队最大限度地利用Kubernetes。
本文较少关注平台的实际技术设计。我们想要了解为什么这样的产品对我们来说是有意义的，以及我们认为引导我们进行可靠设计的各种主题。
如果我们的组织中没有集中管理的Kubernetes产品，团队将开始构建自己的集群。通常，这些服务将由云提供商(GKE、AKS、…)管理。需要团队投入大量额外的时间和精力。
在某些用例中，每个开发团队使用一个集群是有意义的，但是，通常情况下，我们在使用此模型时遇到了多个问题：
规模经济：Kubernetes的构建是为了利用规模经济。单个群集通常具有较低的Pod密度和较高的财务开销。命名空间、资源配额或RBAC等多个概念本身就支持多租户。
技能：开发团队需要几个月的时间才能达到这样的水平，即他们拥有在生产中运行自己的集群所需的技能和经验。我们不能期望，也不希望每支球队都走上这条路。如果一个不合格的团队运行您的Kubernetes基础设施，您最终支付的费用将比购买中央平台团队的费用高得多。
成本：这与规模经济有关，但足够重要，需要单独指出。几个云提供商都有支持您的群集所需的最低节点数。也就是说，遵循每个团队一个群集的方法时，群集往往会过度调配/未得到充分利用。除了资源方面的考虑外，每个团队都必须计划额外的时间和精力(成本)来运营自己的集群。
卓越中心：如果每个团队都运行自己的集群，那么几个团队很可能会遇到相同的问题，并且不交换任何信息。在大型组织中，所学到的经验教训通常不会共享。您很可能会看到不同的配置和糟糕的安全实践-简而言之：治理的噩梦。中央团队可以强制执行最佳实践，并专注于其最擅长的工作：运行集群。
有几个Kubernetes as a Service产品可能值得一看。本文重点介绍如何为您的组织启动内部Kubernetes产品，以及如何使其成为对您的开发人员有吸引力的替代产品。
“集装化浪潮”最近席卷了我们的组织，大多数团队决定使用Kubernetes作为他们的容器编排引擎。库伯内斯对许多球队来说都是新的，但这并没有阻止他们使用它。部署您的容器化应用程序并不那么困难。然而，操作和维护集群是很重要的，而且这对大多数团队来说并不需要太长时间就会变得显而易见。
值得一提的是，许多不熟悉Kubernetes的团队低估了在生产环境中运行集群所需的知识和经验。启蒙可以很快到来，但也可能需要几个月的时间-但它肯定会到来。
不幸的是，当团队意识到运行一个或多个集群确实有多难时，往往为时已晚。您必须维护您的集群，并将您的资源花在应该由平台团队处理的运营任务上。
在构建新产品之前，您应该很好地了解客户的痛点和您要解决的问题。让您的客户参与此阶段以确保您了解要求和需求，这一点至关重要。
根据痛点和您的总体组织目标，您可以得出您的KPI，完成此步骤非常重要。没有关键绩效指标，您就不知道您的产品表现有多好。花点时间思考一下KPI，这些KPI实际表明平台做得有多好，以及确定的痛点减少到了什么程度。关键绩效指标应该会影响您的路线图。内部Kubernetes产品的一些KPI可能包括：
理想情况下，对于您确定的每个痛点，您还需要一个KPI来衡量您的产品在多大程度上减少或消除了此痛点。
根据这些痛点和您的KPI，让我们看看将引导我们为您的组织引入替代模式的高级需求。事先要有一个重要的思维定势：使用自己的单独集群的团队不应该被强迫迁移到共享集群。我们的想法应该是以开发团队想要迁移到内部产品的方式构建内部产品。为了构建如此引人注目的产品，以下是需要满足的一些高级要求：
容易迁移：在单个集群中，在出现故障之前不会引起注意的不良做法。在共享集群中，必须强制执行最佳实践以使其适用于所有人。例如，您必须调整部署应用程序的方式，以支持自动伸缩或防止吵闹的邻居。其中一个需求是通过帮助开发团队应用这些最佳实践来简化他们的迁移。
功能对等：开发团队应该至少获得他们当前通过各自集群获得的功能集。此外，它对应用程序应该是透明的，无论它是在独占集群中运行还是在共享集群中运行。所有功能(例如云提供商区域的可用性或服务发现)应该从一开始就可供客户使用。
运营稳定性：大多数团队转移到集中管理的集群的主要原因是Kubernetes带来的运营痛苦。因此，平台团队必须做好工作，使尽可能多的操作任务远离开发团队。这包括故障转移到其他区域和快速启动新群集的能力。
孤立和吵闹的邻居问题：共享模型中的大多数开发团队最关心的是“我不想因为其他团队搞砸了而处理停机时间”。我们必须确保利用Kubernetes概念和其他工具来防止一个团队干扰同一集群上的另一个团队。
监测和遥测：通过遥测获得信任并能够根据实际数据回答问题是关键。对于成本降低和可用性等关键绩效指标，平台必须生成自动报告。
以下各节将探讨您必须花费时间来满足确定的需求的一些主题。
Kubernetes提供多种支持多租户和隔离的功能。目标应该是提供最少数量的特权，范围限定为您的每个团队所需的资源。应该很好地理解和实施的一些功能包括：
确保平台团队强制执行它们，并且开发团队将它们考虑在内，然后部署他们的应用程序。这意味着开发团队需要很好地了解其资源需求，并且必须能够在没有集群管理员访问权限的情况下工作。提供详细的文档和部署示例对您的开发团队有很大帮助。
运行多租户工作负载时，您可以信任的唯一隔离级别是虚拟机管理程序，以确保真正的安全性。这意味着Kubernetes的安全域成为整个集群。因此，建议在物理上将您的非PROD和PROD环境分开。
如果您必须通过您的平台服务于所有主要市场，并且目标是将PROD与非NPROD群集物理隔离，则设置可能如下所示：
作为灾难恢复计划以及支持具有高可用性要求的团队，提供了两个可用性区域(区域#1、区域#2)。这些是您的云提供商的配对区域，因此数据中心故障不会同时影响这两个区域。
与单个群集相比，此设置提供了巨大的优势。开发团队必须运行至少6个集群才能在平台级实现相同质量的服务(灾难恢复或高可用性)。
为了将应用程序从单个群集迁移到共享群集，您不仅需要群集级别的功能奇偶校验，还需要遵守共享模型中所需的一些策略。要在移动到共享集群之前检查团队的部署，可能值得通过策略自动执行冲突检查，例如缺少资源定义和部署到默认命名空间。此处的一个选项是Open Policy Agent：
要使集群自动缩放器有效运行，您必须定义您的资源(请求/限制)。这就是为什么在共享集群中，您必须强制每个团队配置资源定义。
尽可能自动执行迁移。理想情况下，提供一种自助体验，开发团队可以在其中提供命名空间名称、资源配额和RBAC组等信息。特别是对于生产流量而言，对金丝雀部署的工具支持是必不可少的。
在开始时限制您迁移到您的平台的应用程序的类型可能是个好主意。您只能允许无状态应用程序或流量较低的应用程序。此外，这可能是一个好时机来质疑球队的决定，甚至去库伯内斯。与其盲目地让团队接受您的产品，您可能需要为他们的问题提出不同的解决方案。
这里的目标是监视整个群集的运行状况。我们感兴趣的是集群中节点的健康状态、容量大小、每个节点上运行了多少应用程序以及整个集群的资源利用率。
在这里，您开始涉足您的客户的领域。如果有系统或平台Pod，则必须由平台团队进行监控。如果您希望您的开发负责他们的命名空间中发生的事情，他们需要研究这种监视。
对于生产中的Kubernetes来说，对资源指标的洞察是至关重要的。通常，生产中的Kubernetes错误是由CPU或内存资源不足引起的。通过实时了解资源使用情况，可以避免此类事件。使用方法是分析任何系统性能的一种方法。资源指标对于成本洞察和成本控制也很重要，如下面的成本管理部分所述。有关监控资源指标的一篇很棒的帖子可以在这里找到：
当涉及到监控Kubernetes时，开源工具的事实标准是Prometheus&；Grafana。如果您的组织习惯于麋鹿，这也是一个有效的选择。如果您有足够的人数和经验来管理开源解决方案，那么根据我们的经验推荐使用Prometheus&；Grafana。
如果您的组织负担得起，您绝对应该考虑几种SaaS解决方案，DataDog就是一个例子：
监控工具应该为您提供涵盖上述主题以及验证SLO和KPI所需的洞察力。
如果您的KPI之一是在组织级别上降低成本，那么在迁移前后跟踪每个团队的支出是至关重要的。这假设团队的应用程序负载在度量的时间范围内没有显著变化。即使成本不是您的KPI的一部分，您也可能希望为管理报告建立按存储容量使用计费模型或跟踪成本。
在这两种情况下，您都需要能够将成本分配给导致它的团队。这些功能不是Kubernetes或任何主要云提供商的Kubernetes产品的开箱即用功能。幸运的是，您可以选择以下几个选项：
Kubecost模型为团队提供了对当前和历史Kubernetes支出和资源分配的可见性。这些模型在支持多个应用程序、团队、部门等的Kubernetes环境中提供成本透明性。
Kubernetes成本核算、分配和按存储容量使用计费是生产Kubernetes实施遇到的首批操作问题之一。准确分配Kubernetes成本不仅是管理要求，也是优化Kubernetes成本的第一步。
除了资源成本，日志记录可能成为一个重要的成本因素。您的平台团队不应为客户生成的日志收费，请在设计解决方案时牢记这一点。
当开始提供Kubernetes平台时，事情就会失败。从一开始就不会一帆风顺，您的平台团队将以与开发团队相同的方式吸取教训。尝试尽快获得生产流量的经验，因为这是真正学习它的唯一途径。从小型的特殊用途群集开始，而不是构建满足所有工作负载要求的单个群集。
您的客户必须知道您的责任在哪里结束，他们的责任从哪里开始。为了防止给您的客户带来任何意外，请在您的文档中划出这条线，并将其非常清楚地显示出来。
确保对每一次停机进行分析，并将其记录在运行手册中，以防止再次发生这种情况。运行手册的编写方式应该是，即使是在半夜，随叫随到的团队中的任何人都知道该做什么。
Kubernetes是一项快速发展的技术，每年都会有多次版本升级。您需要清楚地记录该流程，并将其传达给您的客户。在这种情况下，您必须做出的另一个决定是就地升级还是新群集。就地升级应该是可行的，而且通常是对您的客户影响最小的方法。如果您想让客户有机会按照自己的进度迁移到新版本，那么使用新版本的单独群集是个好主意。
有多个案例研究和失败案例值得您查看，其中一个例子就是：