Istio 与 Knative：扩展 Kubernetes 获取新的开发体验

Kubernetes 是托管基于容器的应用程序的事实标准平台。管理 Kubernetes 集群的时候，需要我们借助各种扩展点对其进行自定义，但是 Istio 和 Knative 项目将会从根本上改变这种现象，也会改变应用开发人员使用和看待 Kubernetes 的方式。

本文最初发表于IBM博客，由 InfoQ 中文站翻译分享。

Istio 和 Knative 将会改变应用开发人员使用和看待 Kubernetes 的方式

很多人都已经知道 Kubernetes 是托管基于容器的应用程序的事实标准平台。在管理 Kubernetes 集群的时候，因为要安装各种定制的功能，你可能已经了解了它的很多可扩展点。你甚至可能开发过自己的扩展，比如自定义的调度器，或者更进一步，通过创建自定义资源定义（Custom Resource Definition，CUD）扩展 Kubernetes 资源模型并结合控制器来管理新的资源。

这些可选方案都可以扩展 Kubernetes，其中大多数都是为了将 Kubernetes 作为一个托管环境（比如，帮助管理在它里面运行的应用程序）。然而，随着两个新项目的引入，这一切正在发生变化，它们就是 Istio 和 Knative。这两个项目将会从根本上改变应用开发人员使用和看待 Kubernetes 的方式。

接下来，我们会探索这两个项目并阐述为何它们会给 Kubernetes 开发人员的生活带来显著的影响。

Istio：下一代的微服务网络管理

Istio 是由 IBM、Google 和 Lyft 联合推出的开源项目，可追随至 2017 年，它致力于提供了一种语言中立的方式来连接、保护、管理和监控微服务。它构建在像 Envoy、Prometheus、Grafana 和 Jaeger 这样的开源技术之上，提供了包含如下功能的服务网格（service mesh）：

• 执行流量管理，比如金丝雀部署和 A/B 测试；

• 收集、可视化和导出指标详情并实现跨微服务的跟踪；

• 认证、授权和自动化的流量加密服务；

• 强制实现网格范围内的策略，比如速率限制和黑/白名单。

Istio 实现这些功能（以及更多的其他功能）时，不需要对应用本身做任何修改。它使用新的 CRD 对 Kubernetes 进行了扩展并且会注入 Envoy 代理 sidecar，这些 sidecar 与应用一起运行，提供控制和管理的功能。

Istio 的架构和组件

在底层，Istio 架构分成了两个平面：

• 数据平面（Data plane）：有一组智能代理组成（Envoy），部署为 sidecar，用于协调和控制微服务之间的所有通信；

• 控制平面（Control plane）：负责管理和配置这些代理，以便于在运行时路由流量和执行策略。

Istio 还包含如下这些组件：

• Envoy：与我们的应用程序一起运行的 sidecar，提供代理功能；

• Pilot：提供配置功能，并将这些配置传播至整个系统；

• Mixer：提供策略和访问控制功能，并收集遥测数据；

• Citadel：身份识别、加密和凭证管理；

• Galley：验证用户授权的 Istio API 配置。

Istio 是技术栈的重要组成部分：允许基于它构建新的技术

尽管这些特性本身非常令人兴奋，而且 Istio 确实在业界引发了轰动并得到了广泛采用，但是它面向的依然是 DevOps 工程师/运维人员，也就是负责 Kubernetes 集群和应用管理任务的人。当然，普通的应用开发人员可以自行配置 Istio 路由和策略，但是在实践中，我们不知道他们会不会这样做（或者说愿不愿意这样做）。他们只想关注应用的代码，而不想关心网络配置相关的细节。

Istio 为 Kubernetes 增添了很多微服务管理方面所缺失的特性，而且确实提供了一个无缝的平台，开发人员无需任何配置就可以部署他们的代码。与 Kubernetes 类似，Istio 有明确的关注点并且在它关注的领域做得非常好。如果将 Istio 看作一个构建块或技术栈中的一层，那么我们可以在它之上使用一些新的技术。

而这恰好是 Knative 能够发挥作用的地方了。

Knative：管理应用的新方式

与 Istio 类似，Knative 扩展了 Kubernetes，添加了一些新的关键特性，最重要的特性包括：

• 定义了应用程序部署的新抽象形式，支持一组旨在优化资源利用率的丰富特性，甚至能够“收缩至零（scale-to-zero）”；

• 在 Kubernetes 集群中构建容器镜像的能力；

• 易于使用的事件源注册和事件管理功能，以便于支持松耦合的事件驱动应用程序。

Knative Serving

我们首先从第一项开始介绍，Knative 有一个名为“serving”的组件，它负责运行、暴露和扩展应用程序。为了实现这一点，它定义了名为 Knative Service 的新资源（不要将其与核心 Kubernetes Service 资源相混淆）。实际上，Knative Service 更加类似于 Kubernetes Deployment，因为它定义了要为应用运行什么镜像，以及控制如何管理镜像的元数据。

Knative Service 和 Deployment 的关键区别在于如果系统探测到它不再使用的话，Service 能够收缩至零个实例。对于熟悉 serverless 平台的人来说，这里的概念是完全相同的，这样能够减少至少运行一个实例所带来的成本。基于此，Knative 通常被视为 serverless 托管环境，但实际上，它能够托管任意类型的应用（不仅是 Functions）。按照设计，它有更大的使用场景，这只是其中之一。

在 Knative Service 中，我们还可以声明“roll-out”策略，以便于从应用的一个版本切换至另一个版本。例如，我们可以指定传入网络请求的一小部分要被路由至应用程序的新版本，然后这个比例随着时间的推移逐渐增加。为了实现这一点，会利用 Istio 来管理动态网络路由。与此同时，Service 还能包含其路由或端点 URL。这意味着 Knative 能够搭建与此端点相关的所有 Kubernetes 和 Istio 网络、负载平衡和流量切分。

Knative Build

Knative Service 的另一个重要特性就是它能够指定该如何构建用于部署的镜像。在 Kubernetes Deployment 中，会假定镜像已经构建完毕，并且能够通过某个容器镜像 registry 来获取。但是，这要求开发人员有一个与应用程序部署分离的构建过程。Knative Service 允许将这些流程合并为一个过程，从而节省开发人员的时间。

Service 所引用的“build”组件是 Knative 的第二个关键组件。尽管我们可以按需定义非常灵活的构建过程，但是一般来讲构建过程与开发人员日常所做的非常类似：从仓库（如 GitHub）拉取代码、构建为容器镜像并将其推送至镜像 registry。然而，这里的关键点在于，现在所有的一切都是在 Knative Service 资源的定义内完成的，不需要单独管理的工作流。

Knative Eventing

这就涉及到 Knative 项目第三个也是最后一个组件了，那就是“eventing”。借助该组件，我们可以定义和管理对事件生成器（event producer）的订阅，然后控制如何通过应用程序编排接收到的事件。例如，传入的事件可以会直接发送到某个应用程序，也可以发送到多个感兴趣的应用程序，甚至可以作为涉及多个事件使用者的复杂工作流的一部分来进行处理。

定义整个工作流

将所有这些结合起来，我们可以清楚地看到如何利用这三个组件协同工作来定义应用程序生命周期的完整工作流。简单的例子如下所示：

• 开发人员推送新版本的代码至 GitHub 仓库；

• 推送会生成 GitHub 事件；

• 推送事件会被 Knative 接收到，然后 Knative 会将事件传递给一些代码，这些代码将生成应用程序的新修订/版本；

• 这个新的修订将会构建应用程序新版本的容器镜像；

• 构建完成之后，这个新的镜像将会部署到环境中，以便于进行一些金丝雀测试，随着时间的推移，新版本的负载会慢慢增加，直到旧版本的应用从系统中移除为止。

整个工作流可以在 Kubernetes 中执行和管理，并且可以与应用程序一起进行版本控制。从开发人员的角度来看，他们所处理的只有一个定义应用程序的 Knative Service 资源，而不像单独使用 Kubernetes 时那样需要定义众多的资源类型。

虽然上面介绍的 Knative 特性很有吸引力，但是 Knative 本身（与 Kubernetes 类似）只是社区可用的另一组构建块而已。Knative 正在设计一组可扩展点，以便于支持定制和未来要开发的高级工具。

未来将会走向何方

Istio 和 Knative 结合在一起时，它们关注点是让应用程序开发人员的工作更轻松。尽管 Kubernetes 很好，但很多人（尤其是来自其他平台的用户，如 Cloud Foundry）第一次接触它的时候可能会感到有些畏惧。它会涉及到 pod、replicaSets、deployment、ingress、端点、服务和 helm，开发人员真正想托管一些代码（大多数情况都是如此）的时候，需要学习许多概念。通过 Knative 和它对 Istio 的利用，我们前进了一大步，有助于让开发人员重新成为应用程序开发人员，而不是 DevOps 专家。随着这些项目的不断成熟，社区的反应将是令人兴奋的。