翻译自 Setting Kubernetes Standards with Platform Engineering 。
使用软件目录记分卡来设置 Kubernetes 质量和安全标准，从生产就绪到多个集群等等。
你不可能对所有事情都是专家。但缺乏专业知识不应该阻止你做任何事情，或者使你需要花费很长时间才能完成任务。相反，你只需要知道什么是标准，使用最佳实践并关注重要的数据即可。
这就是平台工程的意义所在。它为开发人员创建可重用的元素，例如重新部署镜像标签、更新自动缩放组以提供新包等等。这些功能可通过内部开发人员门户访问，记分卡在那里发挥着重要作用。
让我们以 Kubernetes 和开发人员为例。仅仅因为开发人员不是 Kubernetes 专家，就说他们应该学习 Kubernetes，或者在希望不破坏任何东西的情况下自由漫游，或者等待 DevOps 工单，这是不正确的。
我们需要允许开发人员拥有自主权，而这可以通过标准实现。标准可以使开发人员摆脱基础架构的复杂性，并允许开发人员在规定的范围内处理 Kubernetes。评分卡是表达这些标准的地方。
这不仅仅是关于良好的平台工程，也关乎良好的开发人员体验。开发人员应该得到精心设计的解决方案，这些方案应该像同样的开发人员为非技术人员提供的那些方案一样设计得精美。
我们已经写过关于内部开发人员门户和它们的软件目录如何抽象出 Kubernetes 复杂性的文章。内部开发人员门户会自动映射所有 Kubernetes 元数据，并通过“白名单”数据帮助开发人员立即了解什么是重要的。在本文中，我们将讨论内部开发人员门户如何使用记分卡将组织 Kubernetes 标准付诸实践。
评分卡与内部开发人员门户中的防护栏杆紧密相连，最终定义和推动了更好的工程质量标准。定义 K8s 的生产就绪或安全标准不仅有助于个人开发人员的改进，也有助于整体工程质量的提升。
未经过滤的原始 Kubernetes 数据对于开发人员来说通常太多了。有些数据不相关，有些可能相关但以对开发人员意义不大的方式呈现。内部开发人员门户包含软件目录，它们提取数据以便开发人员可以使用它。看看这个取自 Port 的单一服务视图。仅展示相关的数据。
让我们来看看 Kubernetes 的一些具体记分卡示例。
生产就绪记分卡评估现有 Kubernetes 对象（例如部署或集群）的生产就绪情况。这有助于确保它们满足生产环境中性能、可靠性和可用性所需的标准，并且可以识别任何必要的更改或升级以随着时间的推移保持或改进它们的就绪状态，从而降低停机风险并确保最终的高质量服务用户。
记分卡应针对以下类别：
对于容器，指标应该验证容器资源配置，如内存 request 和 limit ，并确保为所有容器配置了 liveness 探针和 readiness 探针。这些配置对于确保容器高效运行并能够快速响应可能出现的任何问题至关重要。
- 对于容器，指标应验证容器资源配置（例如内存请求和限制），并确保为所有容器配置活动和就绪探测器。这些配置对于确保容器高效运行并能够快速响应可能出现的任何问题至关重要。
- 对于命名空间，规则应确保工作负载不会部署在默认的 Kubernetes 命名空间中，这有助于防止因干扰 Kubernetes 系统组件而可能出现的潜在问题。
- 对于高可用性，指标应该要求最少副本数为两个，这对于确保在任何节点或 pod 发生故障时的冗余很重要。这种冗余对于确保工作负载的高可用性至关重要。
以下是 Kubernetes 生产就绪情况的记分卡示例。
总的来说，记分卡中反映的标准旨在确保 Kubernetes 工作负载已经生产就绪，并且可以以可靠、可扩展和高效的方式运行。记分卡系统是跟踪这些标准合规性并确保开发人员和运营团队都了解其工作负载的生产就绪状态的有用方法。您可以在此处查看此记分卡的现场演示版本。
安全记分卡标准旨在确保安全措施到位，通过验证 GitHub、DataDog 和 Terraform 等外部系统的 secret 不会暴露，从而保护敏感信息。容器部署合规性标准确保容器配置了只读根文件系统，不访问底层主机并且不提升权限，所有这些对于维护容器安全性都至关重要。标签和标签标准验证工作负载是否具有有效的标签值，以及所有容器镜像是否具有标签版本，这对于有效地组织和管理工作负载非常重要。
这是此类记分卡的示例：（此处为现场演示版）。
总的来说，这些规则有助于确保 Kubernetes 工作负载得到安全部署，并能够以可靠和安全的方式运行。
虽然开发人员可能不太关心资源使用情况，但 DevOps 非常关心。您无法很好地解决资源使用问题，资源使用问题必然会造成更多事件。记分卡既可以提醒开发人员注意此类问题，这样他们就可以自行解决这些问题并设定质量标准。
回到运行服务记分卡，我们可以看到它在资源使用方面处于青铜级别，这是由于 CPU 使用和内存问题。通过搜索软件目录或使用其报告之一，这立即成为一个行动项目。
这是用于评估 ArgoCD 工作流程和部署的生产就绪情况的记分卡。这些规则可确保工作流可靠且推出过程合规，并检查错误处理、配置管理、修订历史和扩展。
由于在所有集群中维护一致配置所涉及的复杂性，管理多个 Kubernetes 集群可能具有挑战性。由于多个集群分布在不同的区域和云中，因此很难确保所有集群的配置一致且正确，并且所有配置都是最新的。错误配置可能会导致服务中断和安全漏洞等问题，从而造成严重后果。
此外，大多数 Kubernetes 可视化工具不提供可以显示不同区域和云中的所有集群的统一仪表盘，这使得难以从单一面板监控整个 Kubernetes 环境的健康状况和性能。
在内部开发人员门户中，很容易创建一个仪表板来显示所有 Kubernetes 集群和关于它们的最重要数据。您可以在现场演示版中看到它的样子：
让我们在此数据之上创建一个生产就绪记分卡：
生产就绪计分卡用于根据一组标准评估 Kubernetes 集群的就绪情况。这些是可用于确保 Kubernetes 集群的稳定性、可用性和可靠性的不同规则。
“K8s 版本稳定”和“使用最新的 K8s 版本”标准侧重于确保使用的 Kubernetes 版本稳定且最新。例如，如果组织中有将集群从 Azure 迁移到 AWS 的倡议，“Cloud provider is not Azure”规则可以帮助跟踪和推动这一倡议，“Using Argo CD”规则促进自动化和标准化部署。
“为所有 Pod 配置的 readiness 和 liveness ”和“为所有 Pod 配置的 CPU 和内存 limit ”有助于确保工作负载健康且不超过可用资源。最后，“集群节点数至少为三个”确保了工作负载的冗余和高可用性。应用这些标准可以帮助组织维护稳定、安全和可扩展的 Kubernetes 环境。
以下是关注 Kubernetes 环境的监控和可见性的其他标准。 “有 K8s 仪表盘吗？”标准检查是否安装了 Kubernetes 仪表盘，它提供了对 Kubernetes 环境的基本监控和可见性。 “有普罗米修斯吗？” standard 检查 Prometheus 是否被用于监控 Kubernetes 指标和基于这些指标的警报，这有助于快速检测和响应问题。
“有Grafana吗？”标准检查 Grafana 是否用于更高级的监控和指标可视化，这有助于监控 Kubernetes 环境的性能和健康状况。通过应用这些标准，组织可以确保其 Kubernetes 环境得到有效监控和维护，以满足其性能和可用性要求。
为不同的实体设置不同的标准很重要，这反映了软件开发生命周期的不同阶段。
例如，在生产环境中，确保 Kubernetes 集群在最新稳定版本的 Kubernetes 上运行并且有足够的节点来支持工作负载可能至关重要。可能还需要确保所有 pod 都配置了适当的资源限制以防止性能问题。此外，可能需要 Prometheus 和 Grafana 等监控工具来提供高级监控和可视化功能。
另一方面，在暂存环境中，重点可能是在将新功能或更改部署到生产环境之前对其进行测试和验证。在这种情况下，标准可能更侧重于确保正确配置 Kubernetes 环境，并使用 Argo CD 等工具实现自动化和标准化部署。
通过为不同的实体定义不同的记分卡，组织可以针对不同的环境定制他们的规则和检查，确保他们的 Kubernetes 环境针对每个环境的特定需求进行了优化。这有助于提高开发和部署过程的效率，同时确保 Kubernetes 环境稳定、安全和可靠。
记分卡做三件事。他们以适合开发人员的方式提取 K8s 数据，确保开发人员遵循 Kubernetes 最佳实践和护栏，以最大限度地提高应用程序可靠性并帮助 DevOps 推动计划。他们提供的工具可帮助开发人员拥有安全性、可靠性和云支出。当工作流自动针对记分卡运行以确定构建是否应该失败时，它们也很有价值。您可以在 Port 的现场演示中亲自观看，或在此处注册免费版本的 Port。