Istio 是一个可配置的开源服务网格层，用于连接、监控和保护 Kubernetes 集群中的容器。 在本文撰写之时，Istio 仅以原生方式与 Kubernetes 一起使用，但其开源性质使任何人都可以编写扩展，从而使 Istio 能够在任何集群软件上运行。 今天，我们将着重关注 Istio 与 Kubernetes 的结合使用，这也是 Istio 最受欢迎的用例。

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

因为它是开源的，所以 Istio 可以在任何支持它的公有云提供商以及任何管理员愿意的私有云上运行。

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

当组织转向微服务时，他们需要支持数十乃至数百个特定应用。 单独管理这些终端意味着要支持大量的虚拟机，包括需求。 Kubernetes 这样的集群软件可以创建 Pod 并向上扩展，但 Kubernetes 不提供路由、流量规则，也不提供强大的监控或调试工具。

认识服务网格。

随着服务数量的增加，潜在的通信方式数量也成倍增长。 两种服务只有两条通信路径。 三种服务有 6 条，十种服务则有 90 条。 服务网格通过创建通信策略，为配置这些通信路径提供了统一的方式。 

服务网格根据预定义的配置检测服务并引导通信流量。 这意味着管理员可以为服务网格提供配置，让其完成该工作，而不是配置正在运行的容器（或编写代码来执行操作）。 这种情况以前总是发生在 Web 服务器和服务间通信中。

在集群中执行此操作时，最常见的方式就是使用 Sidecar 模式。 Sidecar 是 Pod 中的新容器，用于路由和观测服务与容器之间的通信流量。

如前所述，Istio 层位于 Kubernetes 之上，添加了程序员和管理员基本上看不到的容器。 这些容器被称为“Sidecar”容器，它们充当“中间人”，引导流量并监视组件之间的交互。 这两者以三种方式配合使用：配置、监控和管理。

配置

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

监控

利用 Istio，您可以轻松监控与 Kubernetes 一起运行的应用的运行状况。 借助 Istio 的检测能力，可以管理和直观呈现应用的运行状况，提供更深入的洞察，而不只是对 Kubernetes 提供的集群和节点进行常规监控。

管理

因为 Istio 的接口与 Kubernetes 基本相同，所以管理起来几乎无需额外的工作。 事实上，Istio 支持用户创建相应的策略，用来影响和管理整个 Kubernetes 集群，这减少了每个集群的管理时间，同时也无需定制管理代码。

服务网格的主要优势包括能够改善调试、监控、路由、安全和使用情况。 也就是说，利用 Istio，只需更少的工作即可管理更广泛的服务。

改进了调试

比如说，某种服务具有多个依赖项。 保险公司的 pay_claim 服务会调用 deductible_amt 服务，后者则会调用 is_member_covered 服务，以此类推。 复杂的依赖链可能会有 10 或 12 次服务调用。 当这 12 次调用中的某一次调用发生故障时，将会产生连锁反应，带来一系列故障，从而导致 500 错误或 400 错误，或者可能根本没有响应。

要调试这一系列调用，可以使用类似于堆栈跟踪的方法。 在前端，客户端开发者可以看到从 Web 服务器中以什么顺序拉回哪些元素，然后进行检查。 前端程序员可以获取瀑布图来帮助调试。

该示例不会显示数据中心发生的情况 - parselLotamaAudiences 回调如何调用其他四个 Web Service，以及哪些 Web Service 响应速度较慢。 稍后，我们将会在与此类似的图中看到 Istio 如何提供工具来跟踪函数调用。

监控和观测能力

DevOps 团队和 IT 管理人员可能希望观测流量，查看等待时间、服务时间、错误占流量的百分比等等。 通常，他们希望看到仪表板。 仪表板以可视化形式显示总和、平均值或这些度量随时间变化情况，或许还能够“向下钻取”到特定节点、服务或 Pod。 Kubernetes 本身不提供此功能。

策略

缺省情况下，Kubernetes 支持 Pod 之间相互发送流量。 Istio 支持管理员创建策略，限制哪些服务可以相互协作。 例如，服务只能调用其他真正具有依赖关系的服务。 保持服务正常运行的另一个策略是速率限制，这将阻止过量流量阻塞服务，并防止拒绝服务攻击。

路由和负载均衡

缺省情况下，Kubernetes 提供了循环式负载均衡功能。 如果有六个 Pod 提供微服务，Kubernetes 将会提供负载均衡器或“服务”，以递增顺序向每个 Pod 发送请求，然后再重新开始。 但是，公司有时候会在生产环境中部署同一服务的不同版本。

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

借助“Istio”，这如同在配置文件中使用标记一样简单。 管理员还可以使用标签来指示要连接到的服务类型，并根据标头构建规则。 例如，测试用户可以路由到具有最新和最佳构建的“canary”Pod，而普通用户则可以转到稳定的生产构建。

回路中断

如果服务超负荷或关闭，那么在继续使系统过载时，其他请求将会失败。 因为 Istio 会跟踪错误和延迟，所以它可以在策略设置的特定数量请求之后强制暂停（允许服务恢复）。 通过创建小型文本文件并引导 Istio 将其用作新策略，您可以跨整个集群实施此策略。

安全

Istio 在缺省情况下提供身份、策略和加密功能，同时还提供认证、授权和审计 (AAA) 功能。 与他人通信的任何接受管理的 Pod 都将使用加密流量，防止任何观测。 身份服务与加密相结合，确保未经授权的用户无法伪造或“假冒”服务调用。 AAA 为安全和运营专业人员提供必要的监控工具，并且减少了开销。

简化了管理

传统应用仍需要 Istio 提供的识别、策略和安全功能。 这会使程序员和管理员在错误的抽象级别上工作，反复地为每个服务重新实施相同的安全规则。 Istio 支持他们通过单一控制面板在正确的级别上工作，为集群设置策略。