【翻译】Istio是什么？

CSDN-Ada助手

于 2022-12-08 03:07:15 发布

阅读量239

点赞数

分类专栏：翻译

翻译专栏收录该内容

296 篇文章 15 订阅

订阅专栏

我的上一篇文章问道："什么是服务网格？现在我们已经熟悉了整体概念，在这篇文章中，我将深入探讨最流行的Mesh，Istio。这将比之前的博客更实用，更注重细节。

对于那些想知道的人来说，"Istio "在希腊语中是 "帆 "的意思，顺应了给kubernetes相关项目取航海、希腊或两者的名字的趋势。

历史

Istio的第一个公开版本是2017年5月的0.1.0版本，那年春天在Gluecon有一个关于它的演讲。我对0.1记得很清楚，主要是因为痛苦，但值得庆幸的是，此后情况已经好了很多。从那时起，有几个里程碑。2018年5月带来了0.8，第一个长期支持版本，保证了主要配置类型的长期稳定性。1.0在2018年7月发布，标志着核心代码已经可以生产。Istio现在遵循常规的三个月的发布节奏，在撰写本文时，最新版本是1.15。

软件，即代码，版本号只是故事的一部分；构成Istio的配置表面（API）的CRD是单独的版本。主要的API组（networking.istio.io）的稳定性对于向后兼容至关重要。正如我提到的，Istio 0.8是第一次尝试解决它们的长期定义，即v1alpha3版本，该版本至今仍被支持。下一个，也是目前最新的进化版本，v1beta1，作为Istio 1.5的一部分于2020年3月推出。

Istio是由谷歌的人启动的，在0.1.0开源后，谷歌、IBM和其他一些人继续开发。2022年4月，Istio的许可权交给了CNCF（云原生计算基金会），这是一个独立的组织，是Linux基金会的一部分。

执行环境

让我们从实际细节开始：它是什么，它在哪里运行？

正如我在上一篇文章中所概述的，一个服务网由一个控制平面和一个数据平面组成。控制平面，如果你愿意的话，就是大脑，接收用户编写的高级配置，并对数据平面进行编程--处理实际流量的边车代理。如果你愿意的话，这个控制平面是 "Istio proper"；这就是Istio项目产生的代码。虽然一些服务网（Linkerd 2是一个明显的例子）也写了他们自己的代理，但Istio数据平面是由Envoy代理的多个实例组成的（它本身就是一个独立的、蓬勃发展的项目）。请注意，当人们谈论 "网格 "时，他们通常是指数据平面。

Envoy all the way down

Istio控制平面被设计为在Kubernetes集群中运行。它实际上必须在Kubernetes中运行，因为它依赖于Kubernetes的执行环境所提供的一些支持功能。虽然它对Istio来说是 "特殊 "的，但就Kubernetes而言，控制平面只是另一个工作负载。

数据平面可以在很多不同的环境中运行，但与k8s中的工作负载一起的挎包代理是最简单和最常见的。如果工作负载在集群中，基于k8s的Istio控制平面可以使用k8s的突变webhook接纳控制器功能，自动将sidecar注入工作负载中。它还可以调用各种k8s API来了解它们的位置（工作节点、区域、地区），让它自动协调本地感知的路由（例如，首选最近的）。这些类型的功能加起来具有强大的用户体验优势。特别是，不必用边车代理信息来修改工作负载定义（如部署），不仅使它们更短、更整洁，而且还使应用和基础设施问题分开，这在组织和安全方面具有优势。

向集群外的工作负载添加sidecar的能力（所谓的 "网状扩展"）是使传统工作负载现代化的强大功能，不过请注意，你必须能够在同一主机上手动安装sidecar代理，并设置流量拦截。因此，虽然这种 "网状扩展 "并不简单，但它可以将网状的好处带给那些（还）没有在Kubernetes集群中运行的工作负载。

很多人发现这是一种将工作负载迁移到Kubernetes中的有用方法：从洞察其流量开始，对其应用策略等。一旦它们成为可观察和可控制的实体，移动它们的运行位置就变得容易多了。

管理的Istio

与Istio运行地点相关的问题是谁在运行它。

如果有任何Kubernetes集群（和足够的权限，但我假设你是管理员），你可以自己安装Istio，我将在后面简要介绍。

请记住，这只是 "第0天"--网格仍然需要升级等等--所以另一个选择是使用 "管理 "Istio。有几个选择（有些比其他的更有管理性），包括。

谷歌的Anthos，这是一套解决方案，包括一个单独的网格组件。它也可以在GCP之外的集群中运行，但需要回调到谷歌的系统，在考虑故障容忍度的时候，你可能需要考虑这个问题。
RedHat的OpenShift有一个Mesh选项，由Kubernetes操作员安装和升级Mesh。
亚马逊的EKS没有Istio选项，但Tetrate的FIPS认证的Istio分布在附加市场上。

更进一步说，像Tetrate的服务桥（TSB）这样的管理计划提供了对多个Istio网格的全面管理；安装它们，升级它们，并根据更高级别的模型对它们进行配置。

安装

如果你决定运行你自己的Istio，让Istio正确部署并不一定是件小事，有几种不同的方法来实现。我不会在这篇文章中详细介绍实际的安装过程，但我将介绍各种选项，因为它们会阐明关于Istio的各种有趣的事实。如果你想在家里尝试Istio，官方文档是相当全面的。

Istio的安装曾经是通过（非常大的）舵手图，但令人欣慰的是，现代Istio版本是由一段代码来安装的。这段代码的主要工作是生成运行Istio的Kubernetes清单（部署等），并将其应用于Kubernetes集群。

这段代码可以以几种不同的方式运行。

它内置在istioctlCLI二进制文件（Istio相当于kubectl）中，通过使用动词istioctl install运行。
该代码也被打包成一个操作符；一个可以在Kubernetes集群中运行的代码。这将反复运行安装代码，调和Istio部署应该是什么样子，以及它是什么样子之间的任何差异。这就像一遍又一遍地运行安装程序，可以恢复人们对部署的系统进行临时更改而造成的问题。

两者都采用相同的配置，即一个名为IstioOperator的Kubernetes式资源，以YAML文件的形式提供。

istioctl安装命令把它作为一个命令行参数，指向一个本地文件，而对于操作者来说，它是作为一个CR部署到集群中的。

至于获得 "Istio "本身的副本，请记住，它是作为k8s工作负载运行的，其容器镜像将由集群获取。

网格管理员和用户所需要的只是一份istioctl客户端CLI的副本。它可以安装Istio（因为它包含k8s的清单），然后作为客户端与已安装的Mesh进行交互。

它在一些软件包管理器中，使用户很容易开始使用（例如，Homebrew有它，但在写这篇文章时，Ubuntu的apt存储库没有）。如果你的系统没有打包，你可以直接从上游下载（作为一个Go程序，它是静态链接的，没有外部依赖性，所以很容易在任何地方运行）。注意，你会得到一捆东西，包括大量的YAML配置样本，但bin/istioctl也在其中。

从上游下载可以保证我们得到最新版本的istioctl，这意味着我们将安装最新版本的Istio到我们的集群中--因为安装清单包含在istioctl中，这两个版本是耦合的。

例如，在生产环境中，你可能想让istioctl转出它所包含的清单，并将它们检查到git repo中，以便由Flux或ArgoCD等GitOps代理来管理Istio。

架构

那么，要安装什么呢？Istio的架构是什么？我做了几个关于Istio最初架构和工作原理的演讲，你可能想看看，因为最初的设计到今天仍然很有趣，而且与研究有关。从那时起，事情发生了一些变化，我现在就简单介绍一下内部的工作原理。

数据平面

Istio Data Plane

正如我多次提到的，每个工作负载旁边都有一个第7层（如HTTP）代理，这增强了它的网络功能--先进的流量路由、弹性功能、安全策略、强大的工作负载间的加密和深度可观察性等头条例子。很快就会有一个选项，将其减少到每个Kubernetes节点一个代理，为所有的pod服务。这背后的想法是为了节省资源，但这是否是一个好主意还存在争议。

此外，通常有一个入口网关，另一组代理做面向外部的动作，如终止TLS和检查客户端证书（如JTW）。这些代理是独立的；它们不是任何东西的副产品，它们只是处理入口。

严格来说，这个组件是多余的。在这里运行的独立代理与作为侧翼运行的代理是一样的，那么为什么侧翼不能做所有的事情，包括直接与互联网上的客户互动呢？答案是，他们可以，但这需要每个服务舱通过一个公共IP直接访问整个世界。许多机构对此感到不舒服，并选择只给一组专门的代理（入口网关）提供一个公共IP，他们通常在专用服务器上运行。

虽然默认情况下不是安装配置文件的一部分（但却是演示的一部分），Istio也可以有一个出口网关。这为请求的输出增加了一跳，与入口类似，它可以执行访问控制，与外部主机建立TLS连接，等等。

和入口网关一样，这在技术上也是多余的。事实上，较少人部署它，因为通常Kubernetes集群中的所有pod都能进行向外调用（现在是通过它们的sidecars）。但还是要考虑到安全问题，可能需要通过专用节点上的特定代理来强制所有出站流量，使用防火墙来阻止来自其他地方的出口。

所有这些组件都可以 "按需选择"：根据你的需要，运行它们的数量或少。有些人只是部署 "网状 "的挎斗代理，提供他们自己的网关或不提供。也可以只部署入口网关，它类似于任何其他Kubernetes入口控制器，但由Istio的表达式CRD配置。然而，大多数人部署了所有的组件，这些组件当然可以很好地协同工作。

控制平面

侧车和网关是由控制平面配置和协调的。控制平面曾经是一组微服务（就像现在一样），但是Istio在几年前经历了一次重大的架构改变，这在Istio的一篇博文中讨论过，我将在11月谈论这个问题。

自从这次重新设计后，控制平面是一个单一的pod，即istiod，在istio-system命名空间中运行。

可扩展性

值得注意的是，一些数据平面的行为不是以配置的形式提供给代理，而是以动态注入的代码的形式，使用Envoy的WASM支持。这是架构变化的一部分：关于访问控制策略等复杂的决定过去是由一个叫做Mixer的控制面组件来完成的。通过将WASM注入到侧翼组件中，这种行为被移到了侧翼组件中。

Envoy支持通过WASM插件进行扩展，这是一个非常强大的功能：不仅仅是Istio本身可以利用这个功能，用户也可以注入任意的代码。Istio通过一个专门的自定义资源类型，可以很容易地将WASM模块注入到边栏。你可以编写任意强大的代码来验证、操作和报告请求头和体。

默认功能

现在我们知道Istio是如何工作的了，它的控制平面、侧车、入口和潜在的出口网关，它给我们带来了什么？

即使不配置网格，我们也能 "免费 "得到一些好处。

因为侧翼拦截并处理进出工作负载的所有流量，它们可以产生关于每个请求和响应的日志，这些日志可以被发送到日志服务器上。它们还可以产生流量统计，并将其发送到指标服务器，以及跟踪跨度，并将其发送到跟踪服务器。

Istio的安装程序甚至可以为你部署这些可观察性服务器中的每一个的演示实例，让你真正快速地获得服务网的好处（特别是：ElasticSearch、Prometheus和Zipkin）。在这个微服务的世界里，这种可观察性在理解和调试复杂的分布式系统方面可以证明是非常有价值的。

另一个 "免费 "的功能是自动和透明地加密侧车之间的所有流量。这是另一个伟大的开发者体验，因为应用开发者可以只提供纯文本的HTTP（而不是HTTPS）服务器，并进行纯HTTP调用，但得到这些请求的强大加密。

配置

如果我们想要免费的东西以外的行为呢？我已经介绍过几次这些功能了，所以我就不重复了，但值得注意的是，其中很多功能都不是，也不能是默认开启的。网格不能自动执行请求的最后期限，因为它不知道应用程序预计要花多长时间。同样，它也不能重试请求，因为它不知道哪些请求是可以重试的，哪些不可以。所有这些功能都需要配置，这可以通过Istio的API完成。

Istio不是以gRPC端点的形式暴露其API，而是通过在其主机Kubernetes集群中安装CRD。为了配置Istio，你也要将Istio的资源类型的实例部署到集群中。

这样做的实际结果是，管理员和用户通过编写YAML文件来配置Istio。

这些 "YAML "遵循Kubernetes的风格--组、种类、元数据、规格，有时还有状态。像其他资源一样，它们可以用kubectl apply来部署，也可以用无数个更复杂的选项来部署--用Helm图表来演示，用CD管道来部署，用GitOps来同步。

在当前1.15版本的Istio中，有15种Istio资源类型--可以把它们看作是配置API上的不同端点，或者不同的配置文件类型。我不会在这篇文章中介绍所有的自定义资源定义，此外，上游的文档也很全面。

这些资源被分成不同的组，下面是所有的组和你要使用的主要配置类型

Install.istio.io
- IstioOperator - Istio的安装时配置，例如，要部署哪些网关
Networking.istio.io
- 网关--告诉Istio向外部世界开放一个入口网关端口
- VirtualService - 匹配特定主机、路径、标题等的流量的路由和操作指令
- DestinationRule - 告诉Istio如何将流量发送到一个特定的应用程序，例如超时和重试。
Security.istio.io - 验证和授权请求的策略
Extensions.istio.io
- WasmPlugins - 自定义代码，用于注入侧边栏
Telemetry.istio.io - 用于观察性数据收集和转发的配置

出口姿态

还有一个你偶尔要用到的网络组的资源。ServiceEntry。

当VirtualServices和DestinationRules说明其目的地的主机名时，首先会在Istio的服务注册表*中检查这些名称。如果它们不在里面，就在DNS中查找。

由于k8s的集群内DNS服务器，集群内服务和外部互联网域名的主机名都会被找到，所以仅靠DNS就足以发现任何潜在目的地的服务。然而，ServiceEntries允许你覆盖DNS查询，并为主机名提供额外的元数据。通常的用途是说有关服务有一个Istio sidecar（即使它不是一个k8s工作负载）--通知Istio你将网格扩展到该传统工作负载。

遗憾的是，没有简单的方法来查看这个注册表，你只能从它所插入的服务发现系统（例如对于k8s，该集群中的服务资源），加上你手动定义的一组ServiceEntries来推断它。

还有一个全局出口设置，当它被设置时，意味着只有在服务注册表中的主机名才能被使用--向其他地方发送请求会被拒绝。

Istio从k8s的服务资源列表中自动填充其服务注册表，因此集群内的通信将自动工作。然而，每一个非k8s的工作负载，以及每一个你想对话的互联网终端，现在也必须在注册表中。ServiceEntry允许你手动添加它们，有效地允许列出出口目的地。这可能是一个很好的安全立场，对网状操作者来说也是一个很好的体验，因为这个允许列表很容易被人看穿。

用户体验

由于配置是以文件形式提供的，而且是多个独立的文件，你可以建立几种不同的开发者体验：将应用的Istio配置放在一个独立的 repo中；与该应用（Kubernetes）的部署配置一起；或者，与它的代码一起。

作为一个开发者，我喜欢把它放在一起：描述我的应用程序的一切，从编码其行为的程序到其运行时计算和网络环境的YAML定义，都在一个地方，我可以投以关注。我喜欢把Mesh看作是我的应用程序的一部分，我把功能交给它（比如JWT验证），这样我就不必一次又一次地自己写这些功能。我认为写k8s的YAML是告诉k8s这个应用是如何工作的--它是如何扩展的？生存和死亡状态是什么样子的？

同样，我也告诉Istio这个应用是如何工作的--哪些协议需要在哪些端口上使用？哪些端点是空闲的，因此可以重试？哪些路径是谁可以访问的？一个特定的API预计需要多长时间（用两倍的时间作为超时来描述）。

其他值得注意的功能

虽然我不打算介绍Istio的所有功能，但我想指出几个更令人兴奋的功能。

本地感知路由--Istio可以与Kubernetes对话，了解每个工作负载-边车对的 "位置"：它们最终在哪个云区域、区域和主机上。使用这些数据，它可以将请求路由到最近的服务实例，保持低延迟，并避免区域之间的云入口/出口费用。(你可以使用Tetrate成本分析器来了解你目前的成本）。
多集群--多个集群中的stio数据平面可以结合起来，使每个集群中的所有服务都能到达其他所有集群。有几种方法来设计，但在我看来，最好的做法是每个集群有一个Istio控制平面。你仍然可以认为这是一个网状结构，但具有更好的故障和性能特征。配置每个Istio实例，使所有的服务都能与其他所有的服务对话，这需要大量的工作。虽然这是可以手动完成的，但像Tetrate Service Bridge这样的中央管理平面可以自动生成，这将真正帮助你。