什么是 Istio？

在撰写本文时，Istio 仅原生支持 Kubernetes，但其开源特性使任何人都可以编写扩展程序，因此 Istio 能在任何集群软件上运行。今天，我们将重点介绍 Istio 如何与 Kubernetes 配合使用，这是 Istio 最热门的用例。

Kubernetes 是一种容器编排工具，Kubernetes 的一个核心单元是节点。节点由一个或多个容器以及文件系统或其他组件组成。微服务架构可能有十几个不同的节点，每个节点代表不同的微服务。Kubernetes 管理节点的可用性和资源消耗，并随着需求的增加使用 Pod 自动扩缩控制器来添加 Pod。Istio 将其他容器注入 Pod 中以增加安全、管理和监控功能。

由于这种开源性，Istio 可以在支持它的公共云以及经管理员同意的私有云上运行。

以下视频详细介绍了 Istio 的基础知识：

组织转向微服务时，需要支持数十或数百个具体应用程序。单独管理这些端点需要支持大量虚拟机或 VM，包括需求。Kubernetes 这样的集群软件可以创建并扩展 Pod，但 Kubernetes 不提供路由、流量规则、强大的监控或调试工具。

输入服务网格。

随着服务数量的增加，潜在的通信方式数量呈指数级增长。2 个服务只有 2 条通信路径。3 个服务有 6 条，10 个服务有 90 条。服务网格通过创建通信策略提供一种配置这些通信路径的单一方法。

服务网格检测服务并根据预定义配置定向通信流量。这意味着管理员无需配置正在运行的容器（或编写代码来执行此操作），而是可以向服务网格提供配置并让它完成该工作。以前，此操作总是必须在 Web 服务器和服务到服务通信中进行。

在集群中执行此操作的最常见方法是使用 sidecar 模式。sidecar 是 Pod 内部的一个新容器，用于路由和观测服务和容器之间的通信流量。

如前所述，Istio 层位于 Kubernetes 之上，添加了程序员和管理员不可见的“侧柜容器”，这些容器充当“中间人”，引导流量并监控组件之间的交互。两者通过三种方式协同工作：配置、监控和管理。

使用 Kubernetes 设置配置的主要方法是 kubectl 命令，通常为“kubectl -f <filename>”，其中文件是 YAML 文件。Istio 用户可以使用 kubectl 运行新的不同类型的 YAML 文件，也可以使用新的可选 ioctl 命令。

使用 Istio，您可以轻松监控在 Kubernetes 上运行的应用程序的运行状况。Istio 的检测能力可以管理和可视化应用程序的运行状况，与 Kubernetes 对集群和节点的普通监控提供的洞察力相比，Istio 的检测能力提供的洞察力更多。

由于 Istio 的界面本质上与 Kubernetes 相同，因此管理它几乎不需要额外工作。实际上，Istio 允许用户创建影响和管理整个 Kubernetes 集群的策略，从而减少管理每个集群的时间，同时消除对自定义管理代码的需求。

服务网格的主要优点包括用于改进调试、监控、路由、安全性和使用的能力。也就是说，使用 Istio，可以用更少的工作量管理更广泛的服务组。

例如，假设一项服务存在多个依赖项。某保险公司的 pay_claim 服务调用 deductible_amt 服务，后者又调用 is_member_covered 服务，等等。一个复杂的依赖链可能包括 10 个或 12 个服务调用。当这 12 个调用中的一个出现故障时，就会引发一系列连锁故障，从而导致出现 500 个错误、400 个错误或可能根本没有响应的某种情况。

要调试这一组调用，可以使用诸如堆栈跟踪之类的工具。在前端，客户端开发人员可以看到从 Web 服务器拉取的元素和拉取顺序，并对其进行检查。前端程序员可以获得瀑布图来帮助进行调试。

该示例没有显示出数据中心内部发生的情况，即 callback=parselLotamaAudiences 如何调用其他四项 Web 服务以及哪些服务响应速度更慢。稍后，我们将了解 Istio 如何提供工具在类似这样的图表中跟踪函数调用。

DevOps 开发运维团队和 IT 管理人员可能需要观测流量，以便了解延迟、服务时间、错误占流量的百分比等。通常，他们需要查看仪表板。仪表板可以直观地显示合计值、平均值或一段时间内的指标变化，或许还能深入分析特定的节点、服务或 Pod。Kubernetes 本身并不提供这些功能。

默认情况下，Kubernetes 允许每个 Pod 将流量发送到其他每个 Pod。Istio 允许管理员创建策略来限制哪些服务可以协同工作。因此，举例来说，服务只能调用属于真正依赖项的其他服务。保持服务正常运行的另一项策略是速率限制，这项策略可以阻止过多流量堵塞服务并防止拒绝服务攻击。

默认情况下，Kubernetes 提供轮询负载均衡。如果有六个提供微服务的 Pod，Kubernetes 将提供负载均衡器，或在提供服务时按升序向每个 Pod 发送请求，然后再从头开始，。然而，有时公司会在生产环境中部署同一服务的不同版本。

最简单的例子可能是蓝绿部署。在这种情况下，软件可能会在生产环境中构建一个全新版本的应用程序，但不向其发送生产用户。推广新版本后，公司可以保留旧服务器，以便在发生故障时快速切换。

使用 Istio，这就像在配置文件中使用标记一样简单。管理员还可以使用标签来指示要连接到的服务类型，并基于标头构建规则。因此，举例来说，可将测试版用户路由到具有最新、最完善版本的 Canary Pod，而将普通用户转到稳定的生产版本。

如果服务过载或中断，会有更多请求失败，同时使系统继续过载。由于 Istio 会跟踪错误和延迟，因此它可以在请求的数量达到策略设置的特定值之后强制暂停，以使服务恢复。创建一个小文本文件并指示 Istio 将其用作新策略，即可在整个集群中实施此策略。

Istio 默认提供身份、策略和加密功能，以及身份验证、授权和审计 (AAA)。任何与其他 Pod 通信的受管 Pod 都使用加密流量，以防止任何观测。身份服务与加密相结合，有助于确保未经授权的用户无法伪造或“欺骗”服务调用。AAA 为安全和运营专业人员提供以更少的开销实施监控所需的工具。

传统应用程序仍然需要 Istio 提供的身份、策略和安全功能。这使程序员和管理员以错误的抽象级别工作，对每项服务一遍又一遍地重新实施相同的安全规则。Istio 可以让他们以正确的抽象级别工作，通过单一控制面板为集群设置策略。