Istio API 的演进

Istio API 背后的设计原则以及这些 API 的演进方式。

2019 年 8 月 5 日 | 作者：Louis Ryan - Google，Sandeep Parikh - Google

Istio 的主要目标之一始终是，并且仍然是，使团队能够开发最适合其特定组织和工作负载的抽象。Istio 提供了用于服务间网络的强大且强大的构建块。自 Istio 0.1 以来，Istio 团队一直在从生产用户那里了解他们如何将自己的架构、工作负载和约束映射到 Istio 的功能，并且我们一直在演进 Istio 的 API 以使其更好地为您服务。

Istio API 的演进

Istio 演进的下一步是加强我们的重点并与 Istio 用户角色保持一致。安全管理员应该能够与一个 API 交互，该 API 在逻辑上对 Istio 网格内的安全操作进行分组并简化它们；服务运营商和流量管理操作也是如此。

更进一步，有机会为每个角色的初级、中级和高级用例提供改进的体验。有许多常见用例可以通过明显的默认设置和明确定义的初始体验来解决，该体验几乎不需要配置。对于中级用例，Istio 团队希望利用环境的上下文提示，并为您提供更简单的配置体验。最后，对于高级场景，我们的目标是 让简单的事情变得简单，让复杂的事情变得可能。

但是，为了提供这些角色中心抽象，底层的 API 必须能够描述所有 Istio 的功能和能力。历史上，Istio 对 API 设计的方法遵循与其他基础设施 API 类似的路径。Istio 遵循以下设计原则

  1. Istio API 应该致力于
    • 正确表示它们映射到的底层资源
    • 不应隐藏任何底层资源的有用功能
  2. Istio API 应该也是 可组合的，以便最终用户能够以对他们自己的需求有意义的方式组合基础设施 API。
  3. Istio API 应该灵活：在组织内部，应该可以对底层资源有不同的表示，并公开对每个团队有意义的表示。

在接下来的几个版本中，我们将分享我们加强 Istio API 与 Istio 用户角色之间的一致性的进展。

可组合性和抽象

Istio 和 Kubernetes 通常一起使用，但 Istio 远不止 Kubernetes 的附加组件 - 它与 Kubernetes 一样是一个平台。Istio 旨在提供基础设施，并以强大的服务网格的形式提供您所需的的功能。例如，有一些平台即服务产品使用 Kubernetes 作为其基础，并在 Kubernetes 的可组合性之上构建以向应用程序开发人员提供 API 子集。

必须配置以部署应用程序的对象数量是 Kubernetes 可组合性的一个具体示例。据我们统计，至少需要配置 10 个对象：Namespace、Service、Ingress、Deployment、HorizontalPodAutoscaler、Secret、ConfigMap、RBAC、PodDisruptionBudget 和 NetworkPolicy。

听起来很复杂，但并非每个人都需要与这些概念交互。有些是不同团队的责任，例如集群、网络或安全管理团队，并且许多团队提供了合理的默认值。云原生平台和部署工具的一大优势是，它们可以隐藏这种复杂性，通过少量信息为您配置这些对象。

网络领域中可组合性的另一个示例可以在 Google Cloud HTTP(S) 负载均衡器 (GCLB) 中找到。要正确使用 GCLB 的实例，需要创建和配置六个不同的基础设施对象。这种设计是我们 20 年来运营分布式系统的经验的结晶，每个对象与其他对象分离是有原因的。但是，当您通过 Google Cloud 控制台创建实例时，这些步骤会简化。我们提供了更常见的最终用户/角色特定配置，您可以在以后配置不太常见的设置。最终，基础设施 API 的目标是在不牺牲功能的情况下提供最大的灵活性。

Knative 是一个用于构建、运行和操作无服务器工作负载的平台，它提供了一个很棒的真实世界角色中心、更高级 API 的示例。 Knative Serving 是 Knative 的一个组件，它建立在 Kubernetes 和 Istio 之上，支持部署和提供无服务器应用程序和函数，为应用程序开发人员提供了一个有主见的工作流来管理其服务的路由和修订。得益于这种有主见的方法，Knative Serving 公开了与应用程序开发人员最相关的 Istio 网络 API 子集，通过一个简化的 Routes 对象，该对象支持修订和流量路由，抽象了 Istio 的 VirtualService 和 DestinationRule 资源。

随着 Istio 的成熟，我们也看到了生产用户在 Istio 的基础设施 API 之上开发了工作负载和组织特定的抽象。

AutoTrader UK 提供了我们最喜欢的基于 Istio 的自定义平台示例之一。在 与 Google 的 Kubernetes Podcast 的一次采访中，Russel Warman 和 Karl Stoney 描述了他们的基于 Kubernetes 的交付平台，并介绍了 使用 Prometheus 和 Grafana 的成本仪表板。他们只需很少的努力，就添加了配置选项来确定他们的开发人员想要在网络上配置的内容，现在它管理着实现这一目标所需的 Istio 对象。在企业和云原生公司中，有无数其他平台正在构建：一些旨在取代公司特定的自定义脚本网络，另一些旨在成为通用的公共工具。随着越来越多的公司开始公开讨论其工具，我们将把他们的故事带到这个博客中。

接下来会发生什么

我们正在为即将发布的版本努力改进的一些领域包括

哦，如果出于某种原因，您根据安装的 CRD 列表来判断工具箱，那么在 Istio 1.2 中，我们将数量从 54 个减少到 23 个。为什么？事实证明，如果您有很多功能，那么您需要有一种方法来配置它们。通过我们对安装程序的改进，您现在可以使用 配置 安装 Istio，该配置与您的适配器配合使用。

所有服务网格，以及更广泛地说是 Istio，都试图自动化复杂的网络和安全等基础设施操作。这意味着其 API 中将始终存在复杂性，但 Istio 将始终致力于满足运营商的需求，同时不断发展 API 以提供强大的构建块，并优先考虑通过角色中心抽象来实现灵活性。

我们迫不及待地希望您加入我们的 社区，看看您接下来将用 Istio 构建什么！

分享此帖子