云原生云的兴起

Kubefirst提供由流行的免费开源云原生工具制成的即时GitOps平台。多年来，我们一直支持AWS云，我们的平台在Elastic Kubernetes Service（EKS）上运行良好。我们最近宣布扩大对新Civo云的支持，这是一种在Kubernetes上运行所有基础设施的云原生云。这两种云之间有一些相当惊人的差异，但有些东西几乎完全相同，这让笔者思考了行业是如何走到这一步的。 

还记得最初的公共云吗？

还记得公共云是什么时候出现的吗？2013年，AWS试图通过其在弹性计算云（EC2）中的自助基础设施公共云模型，进一步巩固其在新的云计算领域的地位。几年后，谷歌云平台（Google Cloud Platform）和微软Azure宣布了自己的数据中心，这进一步巩固了从自我管理数据中心的架构向云的转变。

尽管与内部部署云基础设施相比，公共云基础设施的计算成本更高，但通过利用可重复的按需云基础设施节省的总体时间和资金促使公司开始拆除机架，将基础设施转移到公共云。自助服务模式为开发人员提供了更多的权力，减少了DevOps领域的移交，并为工程团队提供了更多自主权。公共云将继续存在。

IaC变革

尽管基础设施IT ticket低迷的日子已经成为过去，但对于许多组织来说，云的潜力仍然没有得到开发。按照Tesler定律，向公共云的转变并没有完全消除系统的复杂性。

为了解决这种复杂性，我们需要新的自动化方式来管理基础设施，基础设施即代码（IaC）尽了最大努力来应对这一挑战。CloudFormation、Ansible、Chef、Puppet和Terraform等新技术都尽了最大努力来满足需求，但从涉及到基础设施，通常仍然是一个相当复杂和定制的过程。

容器变革

大约在同一时间，另一场运动正在席卷应用领域：容器化。当时主要基于Docker，将应用程序容器化是创建一致的应用程序运行时环境的一种新方式，可以将应用程序与其运行的基础设施隔离开来。

有了容器化，我们突然能够在不同的操作系统或分发版上以相同的方式运行应用程序，无论是笔记本电脑、内部基础设施还是公共云。这解决了公司在基础设施需求开始向新方向急剧转变时突然出现的许多问题。

拥有经典单体应用程序的组织开始探索如何利用基于容器的微服务来优化其软件开发和扩展难题。随着容器化世界的发展，团队开始构建容器化的微前端，调用容器化的微后端，微产品的扩张开始变得难以管理。这一点在大规模应用程序、基础设施、秘密和可观察性的管理中尤为明显。

编排之战

随着将应用程序放入容器的运动以及由此产生的微服务和容器化微产品的激增，带来了一个新的挑战：管理所有这些服务。

HashiCorp Nomad、Docker Swarm和Kubernetes（现在是CNCF的一部分）迅速进入了市场。

每一个都有其独特的优势，但Kubernetes凭借其声明性设计、操作系统和云可移植性，以及前所未有的强大用户社区，脱颖而出。基于YAML的系统可以很容易地将你想要的状态组织成简单的文件，这些文件代表了应用程序工作所需的一切。它可以在任何云中运行，在内部部署基础设施上运行，甚至在笔记本电脑上运行，它拥有一个由云原生工程师组成的庞大社区，他们对现代解决方案有着统一的愿景。

Kubernetes改进

云原生工程师很快发现，所有在Kubernetes内部运行的软件都比在Kubernet外部运行的软件更容易管理。人们开始形成这样的观点：如果你的产品没有Helm图表（Kubernetes包管理器），那么负责平台技术选择的云原生工程师可能不太喜欢它。毕竟，如果需要安装复杂的第三方软件，你喜欢运行几秒钟的Helm安装命令，而不是一页接一页的安装指南和容易出错的说明。

机会主义的软件供应商很快就抓住了这一趋势，并狂热地开始重新架构系统由Helm安装并在Kubernetes上运行。提供具有复杂微架构的复杂多组件软件包，但仍能轻松安装到任何云环境，这一承诺一直是软件交付团队的梦想，最终在Kubernetes的掌舵下实现了这一目标。

你的云需要有多复杂？

我们首先构建了Kubefirst，在世界上最大的公共云AWS中提供即时云原生（Kubernetes）平台，它在那里运行得很好。AWS云的成熟度在很大程度上是无与伦比的。如果你需要处理大量复杂性、从各个角度符合联邦信息处理标准（FIPS）的端点、具有巨大数据量的极端规模等，那么选择“三大”（AWS、谷歌云或微软Azure）中的一个是很正常的选择。

如果你在这种类型的环境中工作，kubeirst的速度非常快，可以将12个月的平台构建变成一个30分钟的命令（kubeirst-aws-create）。

我们仍然喜欢AWS。然而，当我们问社区应该扩展到什么云时，我们发现人们对一个更简单的云选项感兴趣，该选项专注于托管Kubernetes。Civo、Vultr、DigitalOcean等较新的云提供商以其快速的集群供应时间和显著降低的复杂性而著称。由于要管理的资源比云先驱所能提供的要少，你可以更快地进入新集群。

让我们从Terraform云资源的角度来分解这一点，即基础设施即代码中的对象代码。为了在AWS中从头开始创建一个新的kubefirst即时平台，我们的kubeirst CLI需要提供95个AWS云资源。这包括所有内容——专有网络、子网、密钥管理服务密钥、状态存储桶、后端、身份和访问管理（IAM）角色、策略绑定、安全组以及EKS集群本身。这些资源中的许多都是在Kubefirst平台内的Terraform模块后面抽象出来的，因此从平台工程师的角度来看，云的复杂性已经大大降低，但仍有相当多的“云在运行”。如果你的组织需要的话，这也是一个非常复杂的企业级设置。

但这种复杂是有代价的。要配置这95个资源并让你进入集群，你需要等待大约25分钟的完全自动化时间，其中大部分时间都在等待集群配置。配置主控制平面大约需要15分钟，配置节点组并将其连接到主控制平面需要10分钟。如果需要销毁所有这些资源，还需要20分钟的（自动）等待。

但是，要在Civo拥有相同的Kubefirst平台，你只需要管理三个Terraform资源，而不是95个，而且你可以在大约四分钟内完成同样的任务，而不是45分钟的供应和销毁。当基础设施是更改和测试的一部分时，这对平台团队来说是一个非常重要的细节。

平台工程与云原生云的兴起

平台工程是一种新兴的实践，它允许组织通过建立一个平台团队来构建一个自助开发平台作为其产品，从而实现软件交付的现代化。该实践要求平台团队定期迭代基础设施、云原生应用程序套件、应用程序CI/CD以及第2天的可观察性和监控。随着整个软件开发生态系统的不断供应成为新常态，在迭代之间花费45分钟而不是4分钟会给平台团队的生产力造成高昂的成本。

即使你最终会需要“三大”云的复杂性，这并不意味着你今天需要借用云的复杂性。Kubefirst能够从平台中抽象出云，因此你今天可以在kubefirst civo上构建平台，明天可以使用所有相同的云原生平台工具以相同的方式工作，将其转移到kubefirst aws。

云原生云上的Kubefirst平台

Kubefirst在AWS、Civo、Vultr（beta）、DigitalOcean（beta）和有k3d Kubernetes的本地主机上提供开源即时全自动开源云原生平台。

要创建新的Civo帐户，请添加一个域，在域注册商处配置名称服务器记录，然后运行kubefirst civo create。

几分钟内，你将拥有：

——添加到你的GitHub/GitLab的gitops repo为新平台提供了动力，因此你可以添加喜欢的工具并根据需要扩展平台。

——Civo云和Kubernetes集群由Terraform IaC提供和配置。

——云原生平台应用程序配置的GitOps注册表，预配置为彼此良好协作。

——HashiCorp Vault秘密管理，所有平台秘密都已预配置并绑定到各自的工具。

——一个为管理员和工程师提供单点登录（SSO）的用户管理平台，以及一个预配置为与所有平台工具一起使用的OpenID Connect（OIDC）提供商。

——一个示例React微服务，其源代码演示了GitOps管道以及向新的Kubernetes开发、阶段和生产环境的交付。

——Argo工作流模板库，用于执行GitOps CI并将Kubernetes原生CI与GitHub Actions/GitLab管道集成。

——Atlantis将任何Terraform更改与你的拉取或合并请求工作流集成，以便基础设施更改实现自动化并可供团队审核。

——自托管GitLab/GitHub运行程序，让工作负载免费且无限制地使用。

使用Kubefirst，你可以丢弃生产集群，因为下一次迭代几分钟就可用了——云原生云的兴起就在这里。

原文链接：

https://thenewstack.io/the-rise-of-the-cloud-native-cloud/