告别 PaaS 和 IaaS
告别 PaaS 和 IaaS
作为一名软件工程师，为什么你只需要掌握 Kubernetes ？
翻译自 Saying Goodbye to PaaS and IaaS 。
Kubernetes 正在接管，不是吗？
几乎每个人现在都听说过 Kubernetes ，许多各种规模的组织正在使用它或至少在考虑在生产中使用它。然而，Kubernetes 不仅仅是用于运行容器化工作负载的技术。它可以改变您的 DevOps 文化。通过设计，它抽象了底层基础设施，同时允许我们在需要时创建或修改它。
软件工程师将不再需要使用 PaaS 或 IaaS 。
太过激进了吗？
也许是的，但这不是把 Kubernetes 置于至高无上的地位，让它成为我们所有问题的唯一解决方案。我完全意识到 Kubernetes 、容器和微服务可能并不是每个问题和每个组织的解决方案。然而，根据我在过去几年帮助组织成为云原生的经验，许多人在实施 DevOps 文化时遇到了很多困难。
我坚信 Kubernetes 可以帮助解决这个问题。
Kubernetes 将长久存在
毫无疑问，Kubernetes 不仅仅是一个会消失的炒作技术。
我还记得 2014 年 Kubernetes 刚刚被捐赠给 CNCF 时我开始使用它。当时几乎它是唯一的用于运行容器化工作负载的开源技术。如今，使用容器的组织中约有一半正在使用 Kubernetes 在生产环境中运行它们。
但Kubernetes的意义不仅仅在于操作容器化工作负载。
起源
我喜欢讲述这个故事，我最初是在 Nigel Poulton 的课程中听到的。然而，这是 Kubernetes 的简短故事。
IT 基础设施虚拟化（即基础设施即服务，简称 IaaS ）的兴起始于大约20年前，由亚马逊开创，随后有微软、IBM、Digital Ocean 等等。
当时，亚马逊的优势是巨大的。虽然如今谷歌也提供按需基础设施服务，但在当时，谷歌正在思考如何利用自己的专业知识在这个领域中胜过竞争对手。
谷歌还试图往前看，自问：
我们如何将所有云基础设施，包括裸金属服务器，统一到一个合适的抽象层中？
这是一个聪明的问题，因为当时已经清楚，每个基础设施提供商在其提供的细节上会略有不同（函数即为一个很好的例子）。
答案就是 Kubernetes 。
为什么？因为 Kubernetes 可以在每个云提供商上运行，甚至可以在裸金属服务器上运行。使用 Kubernetes 的开发人员无需担心或甚至了解它实际在哪个基础设施上运行。
崛起
当我和人们谈论 Kubernetes 时，我喜欢告诉他们我认为它是运行软件的头号平台。当然，你可以看出我是一个铁杆粉丝——部分原因是因为我参与了这个令人惊叹的社区，并喜欢在这里做贡献——但我们来快速看看为什么 Kubernetes 真的是解决许多问题的瑞士军刀。
一切都始于容器。没有容器，就不需要 Kubernetes ，对吧？
根据 CNCF 的 2022 年调查，容器现在被视为主流，有 44％ 的受访者表示他们在大多数或所有生产应用中使用容器。其中一半使用容器的组织在生产中使用 Kubernetes 来部署其中至少一部分容器（ 64％ 的最终用户和 49％ 的非最终用户）。
你可能会说这只是数字，只代表世界各地正在发生的特定领域的软件工程。你可能还会说，对很多人来说，Kubernetes 并不是合适的工具。在这些陈述中，你可能是对的。
但是我们来考虑一下。
对于许多组织、用例和环境来说，Kubernetes 是合适的工具。即使对于你正在处理的特定产品或所在的团队/部门来说，学习如何使用 Kubernetes 也是非常有价值的。
而且，我想用上述 CNCF 调查中的一个有趣事实来强调这一点。
Kubernetes 的使用逐渐不仅局限于运行应用负载，还用于辅助负载。这意味着安全控制、服务网格、消息系统、可观察性和持续集成/持续交付工具。令人惊讶的是，从 2021 年到 2022 年，辅助负载的数量将超过应用负载。然而，辅助负载的数量同比增长了 211％ 。
https://www.cncf.io/reports/cncf-annual-survey-2022/
Kubernetes 不仅仅是用于编排容器化应用负载的旗舰工具。
它正在成为云的操作系统
如何实现DevOps？
也许你已经看到了未来发展的方向。自从诞生以来，DevOps 运动一直在试图弥合开发人员和运维人员之间的鸿沟。而且有很多不同的方式来做到这一点。
我见过开发人员变成运维人员，反之亦然，还有 DevOps 职位和整个团队，最新的变化是平台工程师或团队。不管你采取什么解决方案，根本动机始终是赋予开发人员建立和运行他们自己的软件的能力。
你构建它，你运行它。
这就是 DevOps 的口号。尽管我个人不喜欢 DevOps 的职位或整个团队，但我喜欢平台工程的理念。当我在一家专注于 DevOps 的公司为 Cloud Foundry 构建数据服务时，我在技术层面上对 DevOps 的理念是建立一个平台。就像一个内部PaaS（如 Heroku、Cloud Foundry 等）。
这并不是什么新鲜事。我们为许多大型领先行业的客户运行了多个 Cloud Foundry 实例，使他们的开发人员能够构建和运行他们的软件。棘手的问题在于平衡类似 Cloud Foundry 的平台的限制和团队开发人员可能需要的灵活性。
如果他们需要新的数据库、网络或子网、Blob 存储等，他们仍然需要依赖运维团队。那么支持性的工作负载呢？比如安全控制、持续集成/持续交付或可观测性工具？这些也可能需要由运维部署和维护。
选项的扩展
让我们总结一下目前的情况。容器无处不在，我们有这个强大的工具可以在规模上对它们进行编排。然后，我们有开发人员和运维人员，我们仍然希望减少摩擦，以便快速交付价值。但是有许多不同的方法可以做到这一点，每种方法都有其优缺点。似乎没有一种方法是万能的。
这本身不一定是一个问题，但是让我们花一分钟来看看不同选项的影响。
- 运维人员可以给开发人员访问 IaaS 层。这将给开发人员很多自由和灵活性。但这也意味着他们需要很多运维知识。而且我们不能忘记 IaaS 提供商之间的微妙差异。开发人员需要了解不止一个 IaaS 提供商。但公平地说，在这种情况下，开发人员和运维之间的差距将非常小，因为开发人员可以自己提供所需的一切。但开发人员想要拥有这种深入的运维知识吗？他们是否有能力？他们是否被允许？考虑所有治理和安全约束。
- 运维人员可以为开发人员引入一个通用的平台即服务（PaaS）。比如说 Cloud Foundry 。它会为开发人员抽象出底层基础设施，并为他们提供一些接口来运行他们的应用程序（部署、扩展、查看日志等）。开发人员几乎不需要运维知识，但他们的灵活性也会受到限制。但如果他们需要数据库、消息服务、持续集成/持续交付或其他什么东西，仍然会有一个小的差距。
当然，这些不是唯一的可能性。我在可能性范围上指出了一些点。在这个范围内还有完全不同的选项，类似于我指出的选项，但细节上有所不同。一如既往，真相位于中间。
然而，我希望至少从开发人员的角度来看，能有一种统一的方式。我认为 Kubernetes 可以成为这种统一。它可以成为以统一方式提供开发人员所需一切的平台。
但等等，Kubernetes 是用于运行容器化工作负载的，对吗？那么我们如何使用 Kubernetes 在基础设施层面部署应用？
一戒统领天下
在过去几年中，我们看到了在 Kubernetes 领域成立的新公司，它们专注于为开发人员部署和管理（多/云）平台。Upbound 就是这样一家公司，他们创建了 Crossplane ，这是一个开源项目，可以用来创建他们所称的控制面。
控制面就是你登录到云服务提供商帐户时看到的东西。它允许我们将 Kubernetes 用作我们之前讨论的平台。一个地方，可以控制一切，包括应用程序和基础设施、配置、策略和权限。它允许开发人员进行自助服务，最酷的是，通过单个 Crossplane 安装，您甚至可以从不同的云提供商中提供基础设施资源，实现真正的多云体验。
我是 Crossplane 的铁杆粉丝，因为它运行在 Kubernetes 上，因此利用了 Kubernetes 的能力，比如自我修复和（自动）扩展。猜猜怎么着，通过 Crossplane 部署的基础设施组件也是如此。Kubernetes 将使用其协调机制，确保一切始终处于所期望的状态。
这不是很棒吗？
这里有一个小仓库，其中包含了使用 Crossplane 提供 Azure 资源的入门指南。我保证将来会发表一篇后续文章，更深入地介绍 Crossplane 。
结论
大约两年前，我说过 Kubernetes 会接管，而且事实证明我没错。相反，每个人都知道 Kubernetes ，许多组织都在使用它。然而，Kubernetes 并不是在软件工程中所有问题或难题的解决方案。
但是通过 Kubernetes 和类似 Crossplane 的工具的帮助，我们可以弥合开发人员和运维之间的鸿沟。云原生的所有动力一直都是为了提高上市时间。但我必须说，通过 DevOps 、平台人员或团队引入更多的隔阂似乎不是正确的方法。
通过强大的平台来抽象基础设施，让开发人员可以全力构建和运行他们的软件，这对我来说更自然。
希望你喜欢这篇文章，并且我非常乐意听取任何反馈或了解你对这个主题的看法。