译者|李睿评论|孙淑娟）的概念得到了扩展。基础设施即代码(IaC)最初是作为连接虚拟机、网络和存储等具体基础设施的API，并逐渐扩展到包括操作系统和Kubernetes及其配置和强化策略。在查看Terraform等基础设施即代码(IaC)工具时，它们甚至支持工作负载的部署。没有改变的是人们最初对“as-code”感到兴奋的原因。这一切都归结为采用软件开发中使用的熟悉的工具（编辑器、CI/CD等）和流程（代码审查、版本控制等）并将它们应用到较低层，同时使它们具有描述性、可重复的安全性、可共享性，以及同样重要的自动化。平台即代码：前进之路下一步是将这一概念及其优势扩展到我们希望为开发人员提供的平台。目标是构建一个类似于平台即服务(PaaS)的系统，该系统抽象出基础设施并使工程师能够专注于他们的代码。理想情况下，PaaS系统将获得自助服务、标准化和共享常见最佳实践的好处，以及某种类型的安全性和强制合规性，而无需打扰开发人员。然而，典型的PaaS系统有一些应该避免的常见陷阱。首先，PaaS的抽象往往会导致人为的约束，随着软件和开发者的成长和成熟，他们会遇到更多的约束。现在，对于传统或封闭的PaaS系统，这会导致异常并被建模为糟糕的解决方案。其次，传统的PaaS往往伴随着较高的供应商锁定率。第三，人们提出了一个冷门问题：一个平台真的够用吗？您的数据科学工程师是否需要采用与其电子商务团队相同的平台？Kubernetes助力“Kubernetes是构建平台的平台”。如果您熟悉或认识KelseyHightower或JoeBeda等Kubernetes思想领袖，您可能从他们那里听过这句话。同样，有人建议Kubernetes实际上可以成为不仅仅是容器的首选平台。事实上，这可能是最终实现人们设想的平台即代码理想所需要的事情之一。Kubernetes的优势（例如作为编排器和统一接口）构成了这一论点的基础。Kubernetes作为编排器带来了高效的协调方式，可以看作是一种更强大的声明式范式。它允许对操作知识进行编码，这比将这些知识构建到任何形式的脚本中更具弹性和面向未来。此外，基于状态的存储是典型IaC工具中存储和状态的典型缺点。Kubernetes作为一个统一的接口，为人们带来了一个通用的API，其中内置了身份验证、速率限制和审计等功能。此外，该API已成为云原生工作负载管理的标准，并且凭借其原生的可扩展性，熟悉KubernetesAPI意味着到API扩展。由于Kubernetes近年来的成功和流行，从传统的持续集成(CI)/持续交付(CD)的IaC到现代GitOps方法的工具得到了广泛的支持。最后，许多企业已经为许多用例扩展了API，包括Kubernetes内的第一个共识，即为集群、应用程序和基础设施服务定义通用抽象。Kubernetes平台的构建块——超越容器编排首先是ClusterAPI项目，它在1.0中已准备好生产。对于初学者来说，ClusterAPI是ConsensusAPI的上游工作，用于在任何基础设施上以声明方式管理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集群，还可以扩展到整个开发者平台，或者提供给用户的许多平台。原标题：TheFutureofPlatform-as-CodeisKubernetesExtensions，作者：PujaAbbassi
