译者 | 李睿
审校 | 孙淑娟
基础设施即代码：从哪里来
近年来，随着Docker的出现和容器的日益普及，基础设施即代码（IaC）的概念得到了扩展。基础设施即代码（IaC）最初是用于连接虚拟机、网络和存储等具体基础设施的API，然后逐渐扩展到包括操作系统和Kubernetes以及它们的配置和强化策略。当查看诸如Terraform之类的基础设施即代码（IaC）工具时，它们甚至支持工作负载的部署。
没有改变的是人们最初对“即代码”感到兴奋的原因。这一切都归结为软件开发中使用的熟悉工具（编辑器、CI/CD等）和流程（代码审查、版本控制等），并将它们应用到较低层，同时使其具有描述性、可重复性、可共享性，以及同样重要的自动化。
平台即代码：前进的方向
下一步是将这一概念及其优势扩展到希望为开发人员提供的平台上。目标是构建类似于平台即服务（PaaS）的系统，抽象出基础设施并使工程师能够专注于他们的代码。在理想情况下，PaaS系统会在无需打扰开发人员的情况下获得自助服务、标准化和共享常见最佳实践以及某种类型的安全性和实施合规性等好处。
然而，典型的PaaS系统有一些人们应该避免的常见陷阱。
首先，PaaS的抽象通常会导致人为限制，并且随着软件和开发人员的成长和成熟，他们会遇到更多的限制。现在，对于传统或封闭的PaaS系统，这导致异常并被建模为一个糟糕的解决方案。其次，传统的PaaS往往伴随着很高的供应商锁定率。第三，人们要问一个不受欢迎的问题：采用一个平台真的就足够吗？企业的数据科学工程师是否需要与其电子商务团队采用相同的平台？
Kubernetes提供帮助
“Kubernetes是一个构建平台的平台。”如果人们熟悉或了解Kelsey Hightower或JoeBeda等Kubernetes思想领袖，可能已经听说过他们的这一声明。
同样，建议Kubernetes实际上可以成为不仅仅是容器的首选平台。事实上，这可能是最终实现人们设想的平台即代码理想目标所需的一件事。
Kubernetes的好处（例如作为一个协调器和一个统一的接口）构成了这一论点的基础。Kubernetes作为协调器带来了有效的协调方法，可以将其视为一种更强大的声明范式。它允许编码操作知识，这比将这些知识构建到任何形式的脚本中更具弹性并面向未来。此外，基于状态的存储是典型IaC工具中存储和状态的典型缺点。
Kubernetes作为一个统一的接口，为人们带来了一个通用的API，它内置了身份验证、速率限制和审计等功能。而且，该API已经成为云原生工作负载管理的标准，并且凭借其原生可扩展性，对KubernetesAPI的熟悉转化为API扩展。由于Kubernetes在近几年取得的成功和变得流行，从持续集成（CI）/持续交付（CD）上的传统IaC到现代GitOps方法的工具得到了广泛的支持。
最后，许多企业已经为许多用例扩展了API，包括在Kubernetes内部就定义集群、应用程序和基础设施服务的通用抽象达成了第一个共识。
Kubernetes平台的构建块——超越容器编排
首先，有集群API项目，它在1.0中已准备好生产。对于初学者来说，Cluster API是对共识API的上游努力，以声明方式管理任何基础设施上Kubernetes集群的生命周期。如果这对用户来说听起来只是一个普通的API，请放心，它包括所述API的工作实现，以便在许多基础设施提供商上生成集群，包括超大规模服务器以及常见的内部部署解决方案。
在检查了集群之后，接下来是所述集群中的应用程序和工作负载。对于功能齐全的云原生平台，需要采用一组基本的可观察性工具、连接工具、构成开发人员管道的工具，甚至可能需要一些额外的安全工具或服务网格。现在，作为一个社区，至少可以认同Helm作为一种通用的打包格式。但是，如何将这些Helm图表实际部署到集群中，尤其是在多集群环境中（随着集群管理变得越来越容易，这种情况变得越来越普遍）仍然是尚未达成共识的领域。如果企业已经加入了GitOps的潮流，像FluxCD这样的工具有一些抽象，例如HelmRelease，可以提供帮助。GiantSwarm开发了一个名为app-operator的开源Kubernetes扩展，它扩展了Helm，添加了多集群功能以及用于配置的多级覆盖，从而在将应用程序群部署到集群群的用例中减轻了配置管理的痛苦。它还为在部署过程中包含更多元数据（如测试结果和兼容性信息）做好了准备。
人们不能忽视的另一种类型的资源是云计算提供商的服务。在这里，看到大多数超大规模开发者都在开发自己的原生Kubernetes扩展，这样就可以生成他们所谓的第一方资源。第一方资源是诸如直接在Kubernetes中的托管数据库之类，可以从云原生工作负载连接。另一个非常有趣的方法是Crossplane，它是一个开源Kubernetes扩展，使用户能够通过同一个扩展组装来自多个供应商的服务，提供一个抽象层，减少对实际提供商的锁定。
这些只是基本的扩展；该领域有了很大的发展，越来越多的项目或者在后台使用Kubernetes，或者将其公开扩展到他们的用例。在构建平台即代码的背景下，特别需要提及一些更具体的框架和扩展，这些框架和扩展涵盖了专门但常见的用例，例如Kubeflow项目的MLOps/AI和KubeEdge的边缘计算。
未来的愿景和挑战
如今仍处于Kubernetes扩展和平台即代码的早期阶段。大多数标准化工作也处于早期阶段，但正在迅速朝着达成共识和生产就绪的方向发展。
现在需要解决的最重要的问题是此类扩展的用户体验。这不仅限于改进API的验证和默认值，还涉及扩展的发现及其文档级别。此外，一旦使用这些标准中的一些更接近生产，作为一个社区需要注意保持API的可组合性，并在不紧密耦合系统的情况下促进交互。最后，具有许多Kubernetes扩展的复杂系统中的可调试性和可追溯性仍然是可以改进的。
然而，可以肯定的是，Kubernetes将把自己确立为基础设施和云原生技术的首选接口。此外，还将建立更多标准，更多工具支持并与这些标准集成。
总之，对未来的预测是，Kubernetes将成为标准的云原生管理接口。它是一个统一社区的共识API。当然，用户仍然可以自由使用其选择的工具，但统一的开源界面保证用户不会被锁定。
借助Docker和容器，人们创造了一种工作负载是短暂的情况。使用这样技术，不仅可以将这个概念扩展到Kubernetes集群，还可以扩展到整个开发者平台，或者提供给用户的众多平台。
原文标题：The Future of Platform-as-Code is Kubernetes Extensions，作者：Puja Abbassi
