砥砺奋进谱新篇,且看旧貌换新颜。欢迎访问新的 IBM Developer 中文网站! 了解详情

IBM Developer 博客

通过 IBM Developer 关注最新动态并获取信息

Kubernetes 只有几年的历史,但是开发者已经开始尝试各种方法来扩展这个平台来满足自己的需求。Istio 和 Knative 给 Kubernetes 应用程序开发者的工作带来了重大变化。


大多数人都知道 Kubernetes 实际上已经成为了基于容器的应用程序的托管平台。而且,如果您管理 Kubernetes 集群,由于已安装的自定义项,您可能已经知道集群中的许多扩展点。或者您可能自己开发了一些程序,例如自定义调度程序。或许您甚至通过创建自己的自定义资源定义 (CRD) 以及负责管理这些新资源的控制器来扩展 Kubernetes 资源模型。但是,在所有这些可用于扩展 Kubernetes 的选项中,大多数都是针对 Kubernetes 自身作为托管环境而开发的,这意味着它们有助于管理在 Kubernetes 中运行的应用程序。现在,随着两个新项目的引入,在将这两个新项目组合之后,将彻底改变应用程序开发者使用和看待 Kubernetes 的方式。

让我们探索这两个项目并解释为什么它们会彻底改变 Kubernetes 应用程序开发者的工作生活。

Istio:该下一代微服务网络管理技术

Istio 于 2017 年在 IBM、Google 和 Lyft 的联合协作中作为一个开源项目而引入,旨在提供与语言无关的方式来连接、保护、 管理和监控微服务。它采用 Envoy、Prometheus、Grafana 和 Jaeger 等开放技术构建,提供服务网格,使您可以:

  • 执行流量管理,比如 Canary 部署和 A/B 测试。
  • 收集、可视化并导出微服务中的详细指标和跟踪。
  • 服务认证、授权和自动流量加密。
  • 强制执行网格级别的策略,比如速度限制和白名单/黑名单。

Istio 执行所有以上操作,此外,不会对应用程序自身进行任何修改。Istio 通过新的 CRD 和注入的 Envoy 代理 Sidecar 来扩展 Kubernetes,后两者与您的应用程序并行运行来实现这种控制和管理功能。

如果我们了解幕后细节,我们可以看到,Istio 架构分为两个平面:

  • 数据面由一组部署为 Sidecar 的智能代理 (Envoy) 组成,这些 Sidecar 负责协调和控制微服务之间所有网络通信。
  • 控制面负责管理和配置代理以在运行时路由流量和实施策略。

此外,Istio 的架构是由以下组件构成:

  • Envoy – 与应用程序并行运行的 Sidecar,可提供代理
  • Pilot – 配置和传播到整个系统
  • Mixer – 策略和访问控制以及收集遥测数据
  • Citadel – 身份、加密和凭据管理
  • Galley – 验证用户获得授权的 Istio API 配置

尽管所有这些本身都相当令人激动(并且 Istio 肯定会在业界引起轰动并广泛采用),但它的目标受众仍然是 DevOps 工程师/操作员角色,也就是负责 Kubernetes 集群和应用程序的管理任务的人员。当然,最普通的软件开发者也可以自己配置 Istio 路由和策略,但实际上,您不清楚普通的开发者是否会这样做,甚至是否愿意这样做。他们只想专注于应用程序的代码,而不是与管理网络配置相关的所有细节。

但是,Istio 为 Kubernetes 增加了许多管理微服务所必需的缺失功能。而且 Istio 推动了 Kubernetes 成为开发者无需任何配置即可部署其代码的无缝平台的进程。就像 Kubernetes 一样,Istio 也有明确的聚焦点,而且做得很好。如果您将 Istio 视为构建块或堆栈中的某个层,Istio 支持基于自身开发新技术。这就是 Knative 令人瞩目的地方。

Knative:一种管理应用程序的新方法

与 Istio 一样,Knative 通过添加一些新的关键功能来扩展 Kubernetes:

  • 一种用于定义应用程序部署的新抽象,以启用一组旨在优化其资源利用率的丰富功能,特别是“缩容至零”。
  • 能够在您的 Kubernetes 集群中构建容器镜像。
  • 轻松注册事件源,使您的应用程序可以接收其事件。

从第一项开始,有一个名为 “serving” 的 Knative 组件,负责运行、公开和扩展应用程序。为此,定义了一个称为 Knative “Service” 的新资源(不要与核心 Kubernetes“Service”资源混淆)。Knative “Service” 实际上更类似于 Kubernetes “Deployment”,因为它定义了针对应用程序运行哪个镜像以及管理镜像的一些元数据。

Knative “Service” 与 “Deployment” 的关键区别在于,如果系统检测到某个 “Service” 未在使用,则服务可以向下缩容至 0 个实例。对于熟悉无服务器平台的用户,这里的概念与“向下缩容至零”的功能相同,使您免于连续运行至少一个实例的开销。因此,经常将 Knative 作为无服务器托管环境来讨论。实际上,它可以用于托管任何类型的应用程序(不仅仅是“功能”),这也是 Knative 设计背后的更大型用例之一。

在 Knative Service 中,还可以指定“滚出”策略以从应用程序的某个版本切换到另一个版本。例如,您可以指定仅将一小部分传入的网络请求路由到应用程序的新版本,然后随着时间逐渐增加这个比例。为此,可利用 Istio 来管理这种动态网络路由。除此之外,Service 还可以包含其“路由”或端点 URL – 本质上,Knative 将为您设置与此端点关联的所有 Kubernetes 和 Istio 网络、负载均衡和流量拆分。

Knative Service 中可用的另一个主要功能是能够指定应如何构建用于部署的镜像。在 Kubernetes Deployment 中,我们假设镜像已经构建,并且通过某个容器镜像注册表可供使用。但是,这要求开发者具有一个与其应用程序部署分离的构建流程。Knative Service 允许将所有这些功能合并到一起,从而节省开发者的时间和资源。

从 Service 引用的 “build” 组件是 Knative 项目的第二个关键组件。尽管可以灵活地定义所需的任何类型的构建过程,但通常构建步骤与当今开发者采取的操作非常相似:从存储库(例如 GitHub)中提取应用程序源代码,并将其构建到容器镜像中,然后将镜像推送到镜像注册表。但是,这里的关键方面是,现在这一切都在 Knative Service 资源的定义内完成,并且不需要单独的管理型工作流程。

这为我们带来了 Knative 项目的第三个也是最后一个组件:Eventing。使用此组件,您可以定义和管理对事件生成器的订阅,然后控制如何通过应用程序编排所接收到的事件。例如,传入事件可以直接发送到单个应用程序,发送到多个关注的应用程序,在涉及到多个事件使用者时,甚至可以作为复杂工作流程的一部分。

综上所述,现在应该更加清楚如何利用所有这些协同工作的组件来定义应用程序生命周期的整个工作流程。

一个简单的场景可能如下所示:

  1. 开发者将其代码的新版本推送到 GitHub 存储库。
  2. 推送的结果是生成一个 GitHub 事件。
  3. 推送事件由 Knative 接收,然后传递给一些代码,这样会定义如何生成应用程序的新修订/新版本。
  4. 然后,新修订会为应用程序构建新版本的容器镜像。
  5. 在构建完成后,这个新镜像随后会部署到环境中以进行某个 Canary 测试,然后新版本的加载随时间缓慢增加,直至可以从系统中删除旧版本的应用程序。

可以在 Kubernetes 中执行和管理整个工作流,并且可以与应用程序一起进行版本控制。而且,从开发者的角度来看,他/她负责的只是一个用于定义应用程序的单个 Knative Service 资源,而不是开发者在单独使用 Kubernetes 时通常需要定义的众多资源类型。

尽管上述 Knative 功能集令人印象深刻,但 Knative 本身(如 Kubernetes)只是可供社区利用的另一套构建块。Knative 设计了一组扩展点,以支持自定义项和开发未来更高级的工具。

接下来我们怎么做?

Istio 和 Knative 的开发的不同之处在于,将两者结合在一起时,它们的重点是让应用程序开发者的工作变得更轻松。和 Kubernetes 一样,许多开发者第一次接触 Knative(特别是如果开发者是从 CloudFoundry 等平台而来)时可能会有些发怵。在 Pod、副本集、部署、入口、端点、服务和域方面,有很多概念需要学习和理解。如果开发者想要做的只是托管一些代码,可能弊大于利。借助 Knative 及其利用的 Istio,人们在帮助开发者重新成为应用程序开发者(而非 DevOps 专家)方面迈出了一大步。随着这些项目的成熟,我们会惊喜地看到社区对这一变化做出热烈反响。

本文翻译自:Extending Kubernetes for a new developer experience(2019-02-08)