近年来我们都听说过云原生应用，但是云原生基础设施呢？基础设施有什么理由不能采用云原生吗？或者也许它已经是云原生的，但您从未有机会深入堆栈来检查它？“云原生基础设施”一词实际上意味着什么？
你越想，就越感到困惑。我们都知道，构建基础设施的现代方式是将其转变为云。但是，云本身如何能够是云原生的或者说本身是原生的呢？如果这听起来很棘手，请不要担心，您来对地方了。继续阅读，看看当基础设施的未来与现在相遇时会发生什么。
1、云原生构建块
在我们开始探索云原生基础设施之前，让我们确保我们对云原生本身的概念有一个共同的理解。根据云原生计算基金会（CNCF）的官方定义，云原生是一组“使组织能够在现代动态环境中构建和运行可扩展应用程序”的技术。
流行语很多，但技术细节不多。幸运的是，CNCF定义还强调了云原生应用程序的一些示例构建块。那些是：
容器——将应用程序的代码及其依赖项打包在一起，并在运行时环境中独立运行它们
服务网格–通过集中配置的代理网络控制服务间通信
微服务——将应用程序转变为小型独立服务，通过明确定义的API相互通信
不可变的基础设施——将服务管理模式从更改组件的模式转变为替换组件的模式
声明式API–能够描述所需的应用程序状态
虽然定义并不强制云原生应用程序开发人员使用所有这些组件，但大多数云原生应用程序通常遵循这种模式。但我们是否也可以将相同的方法应用于底层基础设施？
2、一切都从云原生开始
当您在应用程序空间中操作时会更容易。基础设施已经存在，提供您所需的所有功能，例如容器运行时、回滚机制等。但是，如果您在尚未构建底层基础设施的环境中（例如私有云空间）操作该怎么办？
每个云的下面只不过是一个裸机资源池。配备CPU、RAM和磁盘的物理机器集群。云管理软件将这种原始基础设施转变为功能齐全的云。而且这个软件也不能是云原生的，没有任何单一的原因。
3、当云成为应用程序时
云本身只是另一个应用程序，大大简化了。它直接安装在金属上，并为在顶部运行的租户应用程序提供功能。这么说来，是否是云原生，取决于底层的云管理软件是如何实现的。将其架构移植到上面列出的组件上，有效地为云原生基础设施奠定了基础。
首先，我们可以将云管理软件分解为多个微服务。事实上，领先的云平台，例如OpenStack，已经遵循了这种模式。然后，我们可以在不可变容器中运行每个微服务。Kubernetes(K8s)和snapd都适合此用途。最后，声明式API支持高级抽象。我们无需费力地配置各个容器，只需声明云的所需状态即可。
对于寻求在其本地运行的面向未来的云平台的组织来说，云原生基础设施是一个理想的解决方案。虽然采用带有私有云的混合多云架构使他们能够实现成本优化、数字主权和性能目标，但使用云原生原则使他们能够有效地运营它。这样，云管理软件就成为现代容器化生态系统中的另一个应用程序，从而拉平学习曲线并提高DevOps效率。
让我们看看它在实践中是如何运作的。
4、Sunbeam–云原生基础设施实施示例
Sunbeam是云原生基础设施实施的完美示例。
Sunbeam是一个上游OpenStack项目，它彻底改变了用户部署和操作云的方式。其架构完全基于定义云原生范例的组件。通过将OpenStack的控制平面容器化并在K8s之上运行，Sunbeam有效地将OpenStack变成了Kubernetes的扩展。通过这种方式，K8s集群可以获得额外的功能，例如传统的基础设施即服务(IaaS)功能，默认情况下，这些功能在其生态系统中是不可用的。
Sunbeam的架构如下图所示：
借助Sunbeam，所有需要硬件访问的云管理软件组件都可以快速交付。这包括云管理和治理服务、Kubernetes集群和虚拟机管理程序以及数据平面服务提供的存储功能。由于snapd提供的隔离和严格限制，这种方法确保了高水平的安全性。反过来，所有不需要硬件访问的服务都作为OCI镜像运行在K8之上。这主要包括云控制平面服务。
堆栈的所有部分都被迷人的运算符包裹着。它们前面的声明式API可实现高级抽象。这样，云的初始部署就得到了显着简化，而其部署后操作（例如插件的启用）则变得完全自动化。
