北美KubeCon + CloudNativeCon虚拟大会赞助文章作者：Josh Berkus，Red Hat
云原生技术是否会取代较旧的DevOps工具，像Kubernetes取代配置管理？还是补充它呢？代替是种流行的说法，但是使用新技术来增强和重建旧技术更为有效。在我们的案例中，我们将说明如何使用Kubernetes、CloudEvents和Knative使Ansible更具可扩展性、分布性和有效性。
但是，为了理解这种方法，你必须首先摆脱关于无服务器是什么的流行想法。
无服务器：不仅仅是FaaS
在大多数情况下，无服务器被视为FaaS（Function as a Service，函数即服务）。虽然当今大多数正在实施的无服务器代码确实是FaaS，但这不是目标，而是进站。无服务器领域仍在发展。让我们一起去探索无服务器的发展趋势。
我们的行业始于我所说的“1.0阶段”，那时我们刚开始谈论或听到有关Serverless的内容，并且在大多数情况下，我们只是将其视为“函数”，即按需在短时间内运行的小段代码。AWS Lambda使得这种范例非常流行，但是它在执行时间、协议和本地开发经验方面存在其自身的局限性。
从那时起，越来越多的人意识到可以将相同的无服务器特性和好处应用于微服务和Linux容器。这将我们引向我所说的“1.5阶段”。这里的一些解决方案完全抽象了Kubernetes，通过位于其之上的抽象层（如Knative）提供了无服务器体验。通过向容器开放Serverless，用户不仅限于函数运行时，而且现在可以使用他们想要的任何编程语言。他们还可以利用容器的可移植性并转移工作负载，从而打破云提供商的锁定。
但是，我们的旅程的终点，是当我们发展无服务器实现以处理更复杂的编排和集成模式，以及某种程度的状态管理。在大多数情况下，无服务器意味着无状态的应用程序，但是现在正在创建许多解决方案，以帮助业务流程重新创建众所周知的集成模式，但以无服务器的方式。此外，当我们实现此“2.0阶段”时，无服务器实质上将成为你的平台即服务的另一功能，因为实际上大多数企业将运行无服务器和非无服务器工作负载的组合。微服务、单体或函数都作为容器运行，使我们的客户有能力在需要时选择最佳工具。
此2.0阶段无服务器的核心是什么？事件（Events和Eventing）。以最简单的形式，当有请求进入时，就需要执行任务。从事件和动作方面进行思考，揭示了使用无服务器方法发展基础架构和应用程序的广泛机会。这是迁移到事件驱动自动化（EDA）的驱动力，该驱动器比以前的模型更好地处理云的弹性、规模和响应性。EDA是无服务器，请求驱动的应用程序/函数扩展的核心，它具有强大的基础结构来生成和使用事件。
DevOps：不仅仅是配置
正如无服务器通常被误认为是FaaS一样，像Ansible这样的DevOps自动化平台经常被错误地定义为完全与配置管理有关。人们会忘记，DevOps的核心目标是使人类以前完成的任务自动化，以使其可重复和可扩展，并且自动化远比配置管理大。因此，尽管你当然可以使用Ansible之类的工具来管理配置，但它们能够执行范围更广的自动化任务。“使一切自动化”是项目的口号。
当开始将DevOps平台视为自动化工具，它们在云原生时代的持续适用性就变得更加明显。尽管我们可能已经完全改变了处理配置的方式，但我们并没有失去管理硬件、网络、外部系统、第三方API和安全策略并与之交互的需求。传统的DevOps工具已经具有处理所有这些问题的模块，而新的云原生工具通常没有。
事件驱动自动化
这向我们展示了旧的自动化与新的无服务器之间的一些清晰的集成点。无服务器平台侦听并路由事件；自动化平台接收命令或状态声明，然后执行工作。以最简单的形式，当请求进入时，需要执行任务。这是向事件驱动架构过渡的动力，事实证明，EDA可以解决许多前所未有的挑战。它使分布式应用程序的弹性和规模成为可能。
例如，我们可以设置一个队列来处理来自AWS账户的CloudWatch事件。由SQS数据馈送为CloudWatch生成的事件由Knative事件源转换为CloudEvents，而这些CloudEvents又可以通过队列放入Kubernetes上的Knative中。
该流水线允许工作流根据平台中的事件自动触发，例如发生某些网络事件，或者自动扩展到超过一定数量的节点，从而启动负载平衡器的自动重新配置。你还可以将团队策略应用于创建新的VPC或VM，并警告某人或在配置不足时自动删除它们。
使用此处演示的技术和标准，可以从多个云或本地平台上实现工作流自动化，然后你可以选择要在哪里处理这些事件。例如，如果你在另一个公有云或数据中心上有容量或访问问题，则可以使用它在一个公有云或数据中心上增加资源。开发人员甚至可以使用它来实现ChatOps。
在此仓库和此仓库中，有一些简单的示例可用于设置和使用带有Knative的Serverless和Ansible。
想像一下：
-
支持案例已经具有工程师所需的所有必需信息，可以立即开始进行故障排除
-
动态文档，你所拥有的信息在需要时准确无误
-
与你所有基础架构的无缝集成，将最佳的容器和传统环境结合在一起
-
自我修复的基础结构，事件可在其中进行故障排除Ansible Playbook，无需人工干预即可纠正问题
希望我们能帮助你了解将新的云原生技术和较旧的DevOps技术融合到单个事件驱动的架构中的可能性。可以利用新功能，而无需放弃对现有自动化的投资。只需将你的想法扩展到功能和配置之外，然后立即开始扩展自动化。
链接：
Knative-Ansible Github项目：
入门指南：
无服务器：
Cloud Events项目：
问卷链接（https://www.wjx.cn/jq/97146486.aspx）
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
4118
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
