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专家。随着这些项目的不断成熟，社区的反应将是令人兴奋的。

创作场景

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