翻译自 Developer Portals Can Abstract away Kubernetes Complexity 。
软件目录中的 Kubernetes 数据可以“列入白名单”，仅仅是开发人员需要，但可以为其他类型的用户编译更多数据。
开发人员和 Kubernetes 专业人士说的不是同一种语言。 Kubernetes 是关于集群、节点、控制平面、pod、版本和命名空间的。当开发人员说“部署”时，他们并不是指管理 Pod 的一组副本的所需状态的 Kubernetes 对象。但 Kubernetes DevOps 专业人士可能认为他们就是这个意思。 DevOps 工程师可能会将“部署”解释为“运行中的 pod”，而开发人员则将其理解为在 CI 管道中运行的部署。我们可以避免这种通天塔互动吗？
诚然，开发人员必须对 Kubernetes 概念（例如 pod、service、deployment 和 replica set）有基本的了解。他们应该熟悉 Kubernetes API 并能够使用命令行工具（例如 kubectl）与集群进行交互。但这是有限制的。您不可能成为所有方面的专家，并且在认知负荷方面需要付出代价。
我们如何帮助开发人员对大量 Kubernetes 数据进行整理，以了解他们的应用程序版本、状态、副本数量和负载？
Kubernetes 原生 CD 解决方案，例如 Argo CD 或 Flux CD或 Lens 或 Rancher 等工具，是否为开发人员提供了一定程度的 Kubernetes 可见性？
没那么简单。在大多数情况下，大量的 Kubernetes 元数据被倾倒在里面，结果让开发人员充满了不必要的信息。此外，这些工具通常显示有关单个集群的数据，并且需要一些工作来显示多集群数据并在之后维护这些视图。
这是一个 Argo CD 示例：
虽然这张图提供了很好的可见性，但它可能非常吓人，而且一眼看去很难理解。在图中的所有不同节点中，什么代表我正在运行的实际应用程序代码？我如何区分我的代码和 K8s 提供的额外基础设施，我作为开发人员无法控制？什么是我的微服务出现问题的良好指标？
此视图无法编辑或过滤，使开发人员更难理解图表并有效回答上面列出的问题。
另一种选择是使用特定于 Kubernetes 的工具，例如 Lens、K9S 或 Rancher。这些工具为管理 Kubernetes 集群提供了更加简化和用户友好的界面。与默认的 kubectl CLI 相比，这些工具确实提供了改进的终端体验。然而，它们仍然需要一些 Kubernetes 知识和经验才能充分使用，这对于第一次接触 K8s 的开发人员来说太复杂了。
这不足为奇。这些工具是为 DevOps 构建的。它们是为 DevOps 基础架构关系而设计的，而不是为 DevOps 开发人员对话而设计的，更不用说开发人员有所有权了。
您可能听说过平台工程、内部开发人员门户或两者。
平台工程通过自动化基础架构操作实现可重用和自助服务功能。它优化了开发人员体验并提高了开发人员的工作效率。它还将 DevOps 从工单 Ops 转变为构建更好的应用程序交付平台的能力。
平台工程方法的核心是内部开发人员门户。内部开发人员门户是开发人员通过类似产品的界面使用平台团队构建的自助服务操作的地方。
在开发人员门户中，软件目录对于它为组织带来的价值非常重要。这是 K8s 数据可以为开发人员转储、抽象和可视化的地方。
可以将在软件目录中显示 K8s 数据视为将开发人员所需的数据“列入白名单”，同时仍然允许为其他类型的用户保留更多的 K8s 数据。这些额外的数据很有价值，因为 DevOps 也需要软件目录。
开发人员门户可以包含您发送给它的任何和所有数据，如果没有为消费者开发人员适当地抽象、修改和显示，数据就会显得太多了。巧合的是，高质量的开发人员门户为您提供了准确的工具来实现适合开发人员的正确抽象，根据他们的角色、经验和组织。
可是等等！ K8s 数据如何填充到软件目录中？这是我们需要数据模型的地方。软件目录以软件目录资产的模式定义开始。在 Backstage 中，它们被称为“kinds”（有六个预定义的：component, API, resource, system, domain 和 group），在 Port 中它们被称为蓝图。
不管名称如何，这个基本构建块代表微服务、环境、集群、包等资产。这些定义很重要，因为它们让您可以创建一个与您一样自以为是的数据模型，并且与工程组织的实际方式相匹配作品。一旦定义了这些模式，数据就会填充到其中，从而创建实体。在这种情况下，我们将映射和填充 Kubernetes 数据。
传统观点将所有 Kubernetes 数据流式传输到给定的微服务。然而，最好将数据流式传输到属于代表 K8s 集群中每个逻辑单元或组件的蓝图的实体，以帮助理解数据，这并不总是微服务。例如，对于一个正在运行的集群，您可以使用一个集群实体，将其与所有可用的命名空间实体相关联，这些实体整齐地显示在一个表中，并查看每个命名空间中部署了哪些服务。
在下面的示例中，我们可以看到如何将 Kubernetes 数据插入到软件目录中的正确实体中。有些数据反映在微服务中，有些数据反映在环境中，有些数据反映在运行的服务实体中。在上下文中显示 Kubernetes 数据使其更容易理解。
让我们更深入地了解正在运行的服务视图。它显示了与开发人员相关的部分 K8s 数据，但不是所有数据。开发人员不关心的东西已经被抽象掉了。
运行的服务实体统一了来自多个来源的数据。标记的属性来自 Kubernetes。查看当前和所需副本之间的比较等信息可以立即帮助开发人员了解他们的服务是否健康，是否能够处理当前负载以及是否经常崩溃。策略等字段可以在部署新版本时更轻松地了解服务可用性。
此外，将 Kubernetes 数据与日志 URL 以及从其他来源提供给正在运行的服务的其他信息相结合，可以为开发人员描绘一幅完整的画面。
这个问题的正确答案是“视情况而定”。组织各不相同，并且没有一种通用的方法来设置软件目录。平台工程师应该了解最适合其组织的抽象级别，具体取决于开发人员 Kubernetes 专业知识的水平。
用户角色也各不相同。前端工程师需要与基础设施或后端团队不同的抽象。例如，前端工程师可能只关心他们的微服务健康状况，可能需要指向包含工件的日志或 S3 存储桶的链接，而后端工程师则希望查看 CPU 和内存限制、实例的活跃度探测和网络策略.
一个设计良好的开发人员门户应该允许您为不同类型的角色或团队创建不同的抽象。
让我们看看 Port 如何使用其 Kubernetes Exporter 将 K8s 元数据反映到开发人员门户中。
通常，将元数据提取到目录中需要来自各种来源的数据。 Git 提供者数据将用于映射多存储库、单存储库以反映微服务并反映开发人员门户内的 GitOps 操作。这同样适用于 Jira、PagerDuty、Snyk 等工具以及云资源和 CI/CD 工具。
对于 Kubernetes，我们希望带来 K8s API 支持的所有数据，以显示正在运行的服务、环境等。 Port 提供了一个开源 Kubernetes Exporter ，允许您对来自 K8s 的数据执行提取、转换、加载 (ETL) 到所需的软件目录数据模型中。
它是安装在集群上的 Helm Chart。设置完成后，它会继续同步更改，这意味着所有更改、删除或添加都会准确自动地反映在 Port 中。
helm chart 使用 YAML 配置文件来描述将数据加载到开发人员门户的 ETL 过程。该方法反映了一个黄金中间点，介于可能不适用于所有人的过于固执己见的 K8s 可视化与可能将不必要的复杂性引入开发人员门户的过于宽泛的方法之间。
- Extract：在K8s exporter的配置中，可以指定要拉取哪些 K8s 数据。支持 K8s API 中的每个对象，包括 CRD。在上面的示例中，我们选择了副本集。为避免数据疲劳，您可以指定查询后跟用 jq 编程语言编写的过滤模式。在上面的查询中，我们决定只引入不以 kube 开头的命名空间元数据，这些元数据是内部 kubernetes 命名空间。
- Transform：在此部分中，您可以选择要向软件目录报告的数据并执行 jq 操作以确保它符合您在开发人员门户中的期望表示。
- Load：这会构建对象主体，然后是软件目录中的对象模式。这就像一个 POST 请求，其主体是您为 REST API 而为开发人员门户设计的。
内部开发人员门户中的软件目录可以通过显示适合他们的 Kubernetes 数据来支持开发人员，使他们能够自主和高效地工作。这样做需要考虑软件目录中的数据模型以及数据开发人员需要和想要什么。