体验 Kiali

• 安装 Travel 演示
• 演示应用程序说明
• 第一步
• • 缺少 Sidecars
  • 启用 Sidecars
  • 向外部流量开放 Travel 演示
• 观察
• • 在所有工作负载中启用 Sidecars
  • Graph 演练
  • 应用详情
• 连接
• • 请求路由
  • 故障注入
  • 流量转移
  • TCP 流量转移
  • 请求超时
  • 断路
  • 镜像
• 安全
• • 授权策略和挎斗
• 卸载旅行演示

安装 Travel 演示

此演示应用程序将部署分组到三个命名空间中的多个服务。

请注意，在此步骤中，我们将部署应用程序而不引用 Istio。

我们将在后续步骤中将服务加入到服务网格。

要创建和部署命名空间，请执行以下命令，

kubectl create namespace travel-agency
kubectl create namespace travel-portal
kubectl create namespace travel-controlkubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travel_agency.yaml) -n travel-agency
kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travel_portal.yaml) -n travel-portal
kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travel_control.yaml) -n travel-control

检查所有部署是否按预期发布，

$ kubectl get deployments -n travel-control
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
control   1/1     1            1           128m$ kubectl get deployments -n travel-portal
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
travels   1/1     1            1           128m
viaggi    1/1     1            1           128m
voyages   1/1     1            1           128m$ kubectl get deployments -n travel-agency
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
cars-v1         1/1     1            1           128m
discounts-v1    1/1     1            1           128m
flights-v1      1/1     1            1           128m
hotels-v1       1/1     1            1           128m
insurances-v1   1/1     1            1           128m
mysqldb-v1      1/1     1            1           128m
travels-v1      1/1     1            1           128m

演示应用程序说明

Travel Portal 命名空间

Travel 演示应用程序模拟组织在不同命名空间中的两个业务域。

在名为 travel-portal 的第一个命名空间中，将部署几个 travel shops，用户可以在其中搜索和预订航班，酒店，汽车或保险。

shop 应用程序可以根据渠道（Web 或移动）或用户（新的或现有的）等请求特征而有所不同。

这些工作负载可能会生成不同类型的流量来模拟不同的真实场景。

所有 portals 都使用部署在 travel-agency 命名空间中的名为 travels 的服务。

Travel Agency 命名空间

名为 travel-agency 的第二个命名空间将托管一组为提供旅行报价而创建的服务。

主要的 travel 服务将是旅行社的业务入口点。它接收目的地城市和用户作为参数，并计算构成旅行预算的所有元素：机票、住宿、汽车预订和旅行保险。

每个服务都可以提供独立的报价，然后旅行服务必须将它们聚合到单个响应中。

此外，一些用户（如注册用户）可以访问由外部服务管理的特别折扣。

命名空间之间的服务关系可以在下图中描述：

Travel Portal 网站和 Travel Agency 流程

典型的流程包括以下步骤：

• Portal 在旅行服务中查询可用目的地。
• 旅行服务查询可用的酒店并返回门户商店。
• 用户选择目的地和旅行类型，其中可能包括航班和/或汽车、酒店和保险。
• 汽车、酒店和航班可能会提供折扣，具体取决于用户类型。

Travel Control 命名空间

travel-control 命名空间运行具有两个主要功能的业务仪表板：

• 允许更改每个旅行商店模拟器的设置（流量比率、设备、用户和旅行类型）。
• 提供从 travel-portal 命名空间到 travel-agency 服务生成的总请求的业务视图，按业务条件组织，按商店、流量类型和城市分组。
  

第一步

了解代理注入和网关。

缺少 Sidecars

旅行演示已在上一步中部署，但没有安装任何 Istio sidecar 代理。

在这种情况下，应用程序不会连接到控制平面，也不会利用 Istio 的功能。

在Kiali中，我们将在概述页面中看到新的命名空间：

但是我们不会在图形页面中看到任何这些新命名空间的任何流量：

如果我们检查“应用程序、工作负载或服务”页面，它将确认缺少 sidecars：

启用 Sidecars

在本教程中，我们将逐步将命名空间和工作负载分别添加到 ServiceMesh 中。

这将帮助您了解 Istio 边车代理的工作原理以及应用程序如何使用 Istio 的功能。

我们将从部署到 travel-control 命名空间中的 control 工作负载开始：

步骤 1：在 travel-control 命名空间上启用自动注入，

步骤 2：为 control 工作负载启用自动注入

了解发生了什么：

（一） 边车注入

（二） 自动边车注入

向外部流量开放 Travel 演示

control 工作负载现在注入了一个 Istio Sidecar 代理，但无法从外部访问此应用程序。

在此步骤中，我们将使用 Istio 入口网关公开控制服务，该网关将路径映射到网格边缘的路由。

步骤 1：为与 Istio 入口的外部 IP 关联的控制服务创建 DNS 条目

我们将检查入口网关的外部IP，

[oracle@oraclelinux8 ~]$ kubectl get services/istio-ingressgateway -n istio-system
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.96.176.63   172.18.0.230   15021:30414/TCP,80:30032/TCP,443:31682/TCP   13d

我们将在教程机器中添加一个简单的条目，其中包含所需的 DNS 条目：

$ sudo vi /etc/hosts...
172.18.0.230 control.travel-control.istio-cluster.org
...

然后，从这台机器上，url control.travel-control.istio-cluster.org 将解析为 Istio 入口网关的外部 IP。

步骤 2：使用控制服务上的请求路由向导生成流量规则

使用"Add Route Rule"按钮添加默认规则，其中任何请求都将路由到 controll 工作负载。

使用高级选项并添加带有主机 control.travel-control.istio-cluster.org 的网关并创建 Istio 配置。

单击"Preview"，然后单击"Create"，

验证生成的Istio配置。

步骤 3：通过将浏览器指向 http://control.travel-control.istio-cluster.org

步骤 4：查看 Kiali 中的 travel-control 命名空间

了解发生了什么：

• 外部流量通过网关进入集群
• 流量通过虚拟服务路由到控制服务
• Kiali Graph 可视化从控制挎斗代理报告的流量遥测数据
  • 只有 travel-control 命名空间是网格的一部分

（i） Istio Gateway

（ii） Istio 虚拟服务

观察

Kiali的可观测性：图形，指标，日志，跟踪…

在所有工作负载中启用 Sidecars

Istio sidecar 代理将工作负载添加到网格中。

代理与控制平面连接并提供服务(网格功能](https://istio.io/latest/about/service-mesh/#what-is-istio)。

自动提供指标、日志和跟踪是 sidecar 的主要功能。

在前面的步骤中，我们仅在 travel-control 命名空间的 control 工作负载中添加了一个 sidecar。

我们添加了新的强大功能，但应用程序仍然缺少其他工作负载的可见性。

步骤 1：切换到"Workload"图并选择多个命名空间以识别 Travel 演示应用程序中缺少的 Sidecars

该 control 工作负载提供了其流量的良好可见性，但遥测只是部分启用，因为 travel-portal 和 travel-agency 工作负载没有 Sidecar 代理。

步骤 2：在 travel-portal 和 travel-agency 命名空间中启用代理注入

在本教程的第一步中，我们故意没有注入 Sidecar 代理来展示只有某些工作负载具有 Sidecar 的情况。

通常，Istio 用户在部署之前注释命名空间，以允许 Istio 在应用程序推出到集群时自动添加 sidecar。执行以下命令：

kubectl label namespace travel-agency istio-injection=enabled
kubectl label namespace travel-portal istio-injection=enabledkubectl rollout restart deploy -n travel-portal
kubectl rollout restart deploy -n travel-agency

验证travel-control、travel-portal和travel-agency工作负载是否已部署 sidecars：

步骤 3：验证 travel-portal 和 travel-agency 命名空间的更新遥测数据

Graph 演练

该 Graph 提供了一组强大的图功能，用于可视化服务网格的流量拓扑。

在此步骤中，我们将展示如何使用 Graph 在 Travel 演示应用程序的上下文中显示相关信息。

我们的目标是确定演示应用程序中最关键的服务。

步骤 1：选择 Graph 中的所有 travel- 命名空间，并在显示选项中启用流量分配边缘标签：

查看网格的状态，一切似乎都很正常，但也要注意，与 travel-agency 命名空间中包含的其他服务相比，hotels 服务的负载更大。

步骤 2：选择 hotels 服务，使用 Graph 侧面板从"Trace"选项卡中选择"trace"：

结合遥测和跟踪信息将显示，从 portal 启动的跟踪涉及多个服务，但也存在仅使用 hotels 服务的其他跟踪。

步骤 3：选择主要的 travels 应用程序，然后双击以放大

Graph 可以专注于一个元素，以详细研究特定的上下文。

请注意，上下文菜单可以使用 右键单击，以轻松快捷方式导航到其他部分。

应用详情

Kiali 提供详细信息视图以导航到应用程序、工作负载和服务。

这些视图提供有关任何应用程序组件的结构、运行状况、指标、日志、跟踪和 Istio 配置的信息。

在本教程中，我们将学习如何使用它们来检查示例的主要 Travel 应用。

步骤 1：导航到 Travel 应用程序

应用程序是一组抽象的工作负载和服务，标记为具有相同的"application"名称。

从服务网格的角度来看，此概念非常重要，因为遥测和跟踪信号主要按"application"分组，即使涉及多个工作负荷也是如此。

在本教程的这一点上，travels 应用程序非常简单，只是通过 travels 服务公开的 travels-v1 工作负载。 通过单击 Travel 应用程序概述中的链接导航到 travels-v1 工作负载详细信息。

步骤 2：检查 travels-v1 工作负载的出站指标

指标选项卡提供了 Istio Sidecar 代理收集的遥测数据的强大可视化。它提供了一个图表仪表板，每个图表都可以展开以进行更仔细的检查。展开"Request volume"图表：

指标设置提供多个现成的预定义条件。此外，在单个图表中启用跨度复选框以关联指标和跟踪跨度。

我们可以在 Travel 应用程序的上下文中看到，hotels 服务请求量与其他 travel-agency 服务不同。

通过检查"Request Duration"图表还显示没有可疑的延迟，因此这种不对称卷可能是应用程序业务逻辑的一部分。

步骤 3：查看 travels-v1 工作负载的日志

日志选项卡提供了应用程序容器日志的统一视图和 Istio Sidecar 代理日志。它还提供了一个跨度复选框，提供日志和跟踪的相关视图，有助于识别感兴趣的范围。

从应用程序容器日志中，我们可以发现有两种主要的业务方法：GetDestinations和GetTravelQuote。

在 Istio sidecar 代理日志中，我们看到 GetDestination 调用了一个 GET /hotels 没有参数的请求。
（注意：练习时并没有看到 GET /hotels 的日志，下面截图使用的 kiali.io 的官方文档截图）

但是，GetTravelQuote使用特定城市作为参数调用对其他服务的多个请求。
（注意：练习时并没有看到 GET /hotels 的日志，下面截图使用的 kiali.io 的官方文档截图）

然后，如 Travle 演示设计中所述，初始查询返回所有可用的酒店，然后让用户选择一个酒店，然后获取其他目的地服务的特定报价。

这种情况表现在 hotels 服务利用率的增加上。

步骤 4：查看工作负载的 travels-v1

现在我们已经确定 hotel 服务比其他旅行社服务有更多的用途。

下一步是获取更多上下文来回答某些特定服务是否比预期慢。

"Traces"选项卡允许在跟踪和指标直方图之间进行比较，让用户确定在平均值的上下文中是否预期会出现特定的峰值。

在相同的上下文中，可以更详细地比较各个跨度，从而有助于在更广泛的场景中确定有问题的步骤。

连接

使用 Kiali 配置 Istio 的流量管理。

请求路由

Travel 演示应用程序在 travel-portal 命名空间上部署了多个 portal，这些 portal 使用部署在 travel-agency 命名空间上的 travel 服务。

travel 服务由名为 travels-v1 的单个工作负载提供支持，该工作负载接收来自所有 portal 工作负载的请求。

在生命周期的某个时刻，portal 的业务需求可能会有所不同，可能需要新版本的 travel 服务。

此步骤将显示如何将请求动态路由到 travel 服务的多个版本。

步骤 1：部署 travels-v2 和 travels-v3 工作负载

要部署新版本的 travel 服务，请执行以下步骤：

kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travels-v2.yaml) -n travel-agency
kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travels-v3.yaml) -n travel-agency

由于没有定义特定的路由，因此当 travel 服务有多个工作负载时，请求将均匀分布。

步骤 2：调查 travel 演示应用程序使用的 http 标头

Istio 的流量管理功能允许您为动态请求路由定义匹配条件。

在我们的场景中，我们希望执行以下路由逻辑：

• 从 travels.uk 路由到 travels-v1 的所有流量
• 从 viaggi.it 路由到 travels-v2 的所有流量
• 从 voyages.fr 路由到 travels-v3 的所有流量

portal 工作负载使用 HTTP/1.1 协议来调用 travel 服务，因此一种策略可能是使用 HTTP 标头来定义匹配条件。

但是，在哪里可以找到HTTP标头？该信息通常属于应用程序域，我们应该检查代码、文档或动态跟踪请求，以了解在此上下文中使用了哪些标头。

有多种可能性。travel 演示应用程序使用 Istio 注解功能将注解添加到部署描述符中，这会将额外的 Istio 配置添加到代理中。

在我们的示例中，HTTP 标头作为跟踪上下文的一部分添加。

然后，跟踪将使用使用的门户、设备、用户和旅行填充自定义标记。

步骤 3：使用 travel 服务上的请求路径向导生成流量规则

我们将定义三个“请求匹配”规则作为此请求路由的一部分。在单击“创建”按钮之前定义所有三个规则。

在第一条规则中，我们将为门户标头的值为 travels.uk 时添加请求匹配项。

定义完全匹配，如下所示，然后单击“添加匹配”按钮以更新此规则的“所选匹配”。

移至“路由到”选项卡并更新此“请求匹配”规则的目标。然后使用“添加路由规则”创建第一个规则。

添加类似的规则，将流量从 viaggi.it 路由到 travels-v2 工作负载，以及从 voyages.fr 路由到 travels-v3 工作负载。

定义这三个规则后，您可以使用“创建”按钮生成此场景所需的所有 Istio 配置。注意 在这种情况下，规则排序无关紧要。

给定服务的 Istio 配置可以在服务详细信息页面的“Istio Config”卡片上找到。

步骤 4：验证请求路由是否从 travel portal 图表中工作

请求路由工作后，我们可以验证来自每个 portal 的出站流量是否进入单个 travel 工作负载。使用“工作负载图”可以清楚地看到这一点，对 travel-portal 命名空间，启用“流量分配”边缘标签并禁用 “服务节点”显示选项：

请注意，边缘上没有分配标签意味着 100% 的流量。

检查任何 travel 工作负载的“入站流量”将在遥测中显示类似的模式。

使用自定义时间范围选择较大的间隔，我们可以看到工作负载最初如何从所有门户接收流量，但在定义请求路由方案后仅接收单个门户。

步骤 5：更新或删除 Istio 配置

Kiali 向导允许您定义高级服务网格场景，并将生成其实现所需的 Istio 配置（虚拟服务、目的地规则、网关和对等请求）。 可以从给定服务的“操作”菜单中更新或删除这些方案。

要进一步试验，您可以导航到旅行服务并通过选择“请求路由”来更新您的配置，如下所示。当你有 完成路由请求场景的试验，然后使用“操作”菜单删除生成的 Istio 配置。

故障注入

观察步骤发现，与旅行社命名空间中部署的其他服务相比，酒店服务具有额外的流量。

此外，此服务在主业务逻辑中变得至关重要。它负责查询所有可用的目的地，将它们呈现给用户，并获取所选目的地的报价。

这也意味着酒店服务可能是旅行演示应用程序最薄弱的地方之一。

此步骤将演示如何通过将故障注入酒店服务，然后观察应用程序对此方案的反应来测试旅行演示应用程序的复原能力。

步骤 1：使用酒店服务上的故障注入向导注入延迟

选择 HTTP 延迟并指定“延迟百分比”和“固定延迟”值。默认值将在 5% 收到的请求中引入 100 秒延迟。

步骤 2：了解源指标和目标指标

遥测数据是从代理收集的，并使用有关源和目标工作负载的信息进行标记。

在我们的示例中，假设旅行服务（下图中的“服务 A”）调用了酒店服务（图中的“服务 B”）。旅行是“源”工作负载，酒店是“目的地”工作负载。旅行代理将从源角度报告遥测数据，酒店代理将从目标角度报告遥测数据。让我们从两个角度看一下延迟报告。

行程工作负载代理具有故障注入配置，因此它将执行对酒店服务的调用，并将在差旅工作负载端应用延迟（这报告为源遥测）。

我们可以在源（旅行代理）报告的酒店遥测中看到，有一个明显的差距，显示请求持续时间延迟 5 秒。

但是，由于故障注入延迟应用于源代理（行程），因此目标代理（酒店）不受影响，其目标遥测不会显示延迟。

步骤 3：研究旅行服务延误的影响

注入的延迟将从旅行服务传播到部署在旅行门户命名空间上的下游服务，从而降低整体响应时间。但下游服务不知不觉，运行正常，并显示绿色状态。

步骤 4：更新或删除 Istio 配置

作为此步骤的一部分，您可以更新故障注入方案以测试不同的延迟。完成后，您可以删除为酒店服务生成的 Istio 配置。

流量转移

在前面的请求路由步骤中，我们使用 travels-v2 和 travels-v3 工作负载部署了两个新版本的差旅服务。

该场景展示了 Istio 如何将特定请求路由到特定工作负载。它的配置使得部署在旅行门户命名空间（travels.uk、viaggi.it 和 voyages.fr）中的每个门户都路由到特定的旅行工作负载（旅行 v1、旅行 v2 和旅行 v3）。

此流量转移步骤将模拟一个新方案：新的 travels-v2 和 travels-v3 工作负载将代表所有请求将使用的差旅服务的新改进。

travels-v2 和 travels-v3 中实施的这些新改进代表了解决特定问题的两种替代方法。我们的目标是在决定将哪一个版本用作下一个版本之前对其进行测试。

一开始，我们会将 80% 的流量发送到原始 travels-v1 工作负载中，并将在 travels-v10 和 travels-v2 上各分配 3% 的流量。

步骤 1：在旅行服务上使用流量换档向导

创建一个方案，其中 80% 的流量分配给 travels-v1 工作负载，10% 的流量分别分配给 travels-v2 和 travels-v3。

步骤 2：从旅行社图表中检查流量转移分布

步骤 3：比较差旅工作负载并评估差旅 v2 和差旅 v3 中提出的新更改

Istio 遥测是按逻辑应用程序分组的。这具有轻松比较一个或多个服务的不同但相关的工作负载的优势。

在我们的示例中，我们可以使用旅行应用程序详细信息中的“入站指标”和“出站指标”选项卡，按“本地版本”分组，并比较旅行 v2 和旅行 v3 的工作方式。

图表显示流量分布正在相应地工作，80% 的流量分布正在分配给 travels-v1 工作负载，它们也显示 travels-v2 和 travels-v3 在请求持续时间方面没有太大差异。

步骤 4：更新或删除 Istio 配置
作为此步骤的一部分，您可以更新流量转移方案以测试不同的分配。完成后，您可以删除为旅行服务生成的 Istio 配置。

TCP 流量转移

旅行演示应用程序具有一个数据库服务，该服务由部署在旅行社命名空间中的多个服务使用。

在应用程序生命周期的某个时刻，遥测显示数据库服务降级并开始增加平均响应时间。

这是一种常见的情况。在这种情况下，由于数据增长，数据库专家建议更新原始索引。

我们的数据库专家建议采用两种方法，并建议准备两个版本的数据库服务来测试哪个版本可能更好。

此步骤将展示如何将“流量转移”策略应用于 TCP 服务，以测试哪种新的数据库索引策略效果更好。

步骤 1：部署 mysqldb-v2 和 mysqldb-v3 工作负载

要部署新版本的 mysqldb 服务，请执行以下命令：

kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/mysql-v2.yaml) -n travel-agency
kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/mysql-v3.yaml) -n travel-agency

步骤 2：在 mysqldb 服务上使用 TCP 流量转移向导

创建一个场景，其中 80% 的流量分配给 mysqldb-v1 工作负载，10% 的流量分别分配给 mysqldb-v2 和 mysqldb-v3。

步骤 3：从旅行社图表中检查流量转移分布

请注意，TCP 遥测具有不同类型的指标，因为“流量分布”仅适用于 HTTP/gRPC 服务，对于此服务，我们需要使用“流量速率”来评估 mysqldb 工作负载之间的数据分布（每秒字节数）。

步骤 4：比较 mysqldb 工作负载并研究 mysqldb-v2 和 mysqldb-v3 中提出的新索引

TCP 服务具有不同的遥测数据，但仍按版本分组，允许用户比较和研究 mysqldb-v2 和 mysqldb-v3 的模式差异。

与 mysqldb-v2 相比，图表显示了 mysqldb-v3 中的更多峰值，但总体上行为相似，因此选择任一策略来转移所有流量可能是安全的。

步骤 5：更新或删除 Istio 配置
作为此步骤的一部分，您可以更新 TCP 流量转移方案以测试不同的分配。完成后，您可以删除为 mysqldb 服务生成的 Istio 配置。

请求超时

在故障注入步骤中，我们展示了如何在关键酒店服务中引入延迟并测试应用程序的弹性。

延迟在服务之间传播，Kiali 展示了服务如何接受延迟而不会在系统上产生错误。

但在实际情况下，延迟可能会产生重要后果。服务可能更愿意更快地失败并恢复，而不是跨服务传播延迟。

此步骤将显示如何为部署在旅行门户命名空间中的某个门户添加请求超时。travel.uk 和 viaggi.it 门户将接受延迟，但 voyages.fr 将超时并失败。

步骤 1：使用酒店服务上的故障注入向导注入延迟

重复故障注入步骤以增加酒店服务的延迟。

步骤 2：使用行程服务上的请求路径向导添加具有延迟 voyages.fr 的路径规则

添加规则以仅对来自门户的请求添加请求超时 voyages.fr：

• 使用“请求匹配”选项卡为具有 voyages.fr 值的门户标头添加匹配条件。
• 使用“请求超时”选项卡为此规则添加 HTTP 超时。
• 将规则添加到方案中。

应将第一条规则添加到列表中，例如：

添加第二个规则以匹配任何请求并创建方案。使用此配置，来自 voyages.fr 的请求将与第一条规则匹配，所有其他请求将与第二条规则匹配。

步骤 3：查看请求超时对旅行服务的影响

创建规则。该图将显示由于引入的请求超时，来自 voyages.fr 的请求如何开始失败。

来自其他门户的请求可以正常工作，但会因酒店延迟而降级。

如果我们检查“入站指标”并按“远程应用”和“响应代码”进行分组，则可以详细可视化此方案。

正如预期的那样，来自 voyages.fr 的请求不会传播延迟，并且在 2 秒范围内失败，同时来自其他门户的请求不会失败，但它们会传播酒店服务中引入的延迟。

步骤 4：更新或删除 Istio 配置

作为此步骤的一部分，您可以更新围绕酒店和旅行服务定义的场景以试验更多条件，或者您可以删除两个服务中生成的 Istio 配置。

断路

分布式系统将受益于快速故障和施加背压，而不是通过系统传播延迟和错误。

断路是用于限制故障、延迟峰值和其他类型的网络问题影响的重要技术。

此步骤将展示如何将断路器应用于旅行服务，以限制并发请求和连接的数量。

步骤 1：在旅行门户命名空间中部署新的负载测试器门户

在此示例中，我们将部署一个新的工作负载，该工作负载将模拟系统负载的重要增加。

kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travel_loadtester.yaml) -n travel-portal

负载测试器工作负载将尝试创建 50 个与旅行服务的并发连接，这给旅行机构命名空间增加了相当大的压力。

旅行演示应用程序能够处理此负载，乍一看，它不会显示不正常状态。

但在实际场景中，此类服务负载的意外增加可能会对整体系统状态产生重大影响。

步骤 2：使用出行服务上的流量移位向导生成流量规则

使用“流量转移”向导将流量（均匀地）分配到行程工作负载，并使用“高级选项”向方案添加“断路器”。

“连接池”设置将指示当并发连接数和请求数超过一个时，代理挎斗将拒绝请求。

如果出现多个连续错误，“异常值检测”将从连接池中弹出主机。

步骤 3：研究断路器在旅行服务中的行为

在负载测试仪版本化应用程序图中，我们可以看到旅行服务的断路器接受一些连接，但大多数连接失败。

请记住，这些连接由负载测试仪端的代理停止。这种“更快失败”模式可防止网络过载。

使用图形，我们可以选择故障边，检查标志选项卡，并查看这些请求是否已被断路器关闭。

如果我们从“出站指标”选项卡中检查“请求量”指标，我们可以看到请求的演变，以及断路器的引入如何使代理减少请求量。

步骤 4：更新或删除 Istio 配置

作为此步骤的一部分，您可以更新围绕旅行服务定义的场景以试验更多的断路器设置，或者您可以删除服务中生成的 Istio 配置。

了解发生了什么：

(i) Circuit Breaking

(ii) Outlier Detection

(iii) Connection Pool Settings

(iv) Envoy’s Circuit breaking Architecture

镜像

本教程展示了几个场景，在这些场景中，Istio 可以将流量路由到不同的版本，以便比较版本并评估哪个版本效果最好。

流量转移步骤侧重于旅行服务添加新的 travel-v2 和 travel-v3 工作负载 TCP 流量转移展示了如何在 mysqldb 服务等 TCP 服务上使用此场景。

镜像（或影子）是流量转移方案的一种特殊情况，其中代理将实时流量的副本发送到镜像服务。

镜像流量发生在主请求路径的带外。它允许在生产环境中以最小的风险测试备用服务。

Istio 镜像流量仅支持 HTTP/gRPC 协议。

此步骤将显示如何将镜像流量应用于行程服务。

步骤 1：在旅行服务上使用流量换档向导

我们将模拟以下内容：

• travels-v1 是原始流量，它将保留 80% 的流量
• travels-v2 是要部署的新版本，正在评估中，它将获得 20% 的流量以与 Travels-v1 进行比较
• 但是 travels-v3 将被视为一个新的实验版本，用于在常规请求路径之外进行测试。它将定义为 50% 原始请求的镜像工作负载。

步骤 2：从旅行社图表中检查流量转移分布

请注意，Istio 不会报告来自源代理的镜像流量遥测。它从目标代理报告， 尽管它未标记为镜像，因此从 Travels 到 Travels-v3 工作负载的边缘将显示在图形中。 请注意，流量速率反映了 travels-v80 和 travels-v20 之间的预期比率为 1/2，travels-v3 约为 总数的一半。

使用“入站指标”选项卡中的“源”和“目标”指标可以更好地检查这一点。

“源”代理（在本例中为注入 travel-portal 命名空间工作负载的代理）不会报告 travels-v3 镜像工作负载的遥测数据。

但“目标”代理（在本例中为注入 travels-v3 工作负载的代理）将从镜像流量中收集遥测数据。

步骤 3：更新或删除 Istio 配置

作为此步骤的一部分，您可以更新镜像方案以测试不同的镜像分发。

完成后，您可以删除为旅行服务生成的 Istio 配置。

安全

使用 Kiali 配置和观察网状网络安全性。

授权策略和挎斗

安全性是 Istio 功能的主要支柱之一。

Istio 安全高级架构提供了一个全面的解决方案来设计和实现多个安全场景。

在本教程中，我们将展示 Kiali 如何使用遥测信息为部署在给定命名空间中的工作负载创建安全策略。

Istio 遥测聚合了工作负载通信中使用的服务帐户信息。此信息可用于定义授权策略，以拒绝和允许对未来的实时流量通信状态执行操作。

此外，可以创建 Istio 挎斗来限制给定工作负载可以与之通信的主机。这改善了流量控制，并减少了代理的内存占用。

此步骤将展示我们如何在旅行演示应用程序中为给定时间段内的所有现有流量为旅行社命名空间定义授权策略。

定义授权策略后，如果新工作负载与定义的安全规则不匹配，则将被拒绝。

步骤 1：从旅行门户命名空间取消部署负载测试仪工作负载

在此示例中，我们将使用负载测试仪工作负载作为安全规则中的“入侵者”。

如果我们按照前面的教程步骤操作，则需要从系统中取消部署它。

kubectl delete -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travel_loadtester.yaml) -n travel-portal

我们应该验证遥测是否已更新旅行门户命名空间，并且可以在图形显示选项中启用“安全性”。

步骤 2：为旅行社命名空间的当前流量创建授权策略和 Istio Sidecar

群集中的每个工作负载都使用一个服务帐户。

travels.uk、viaggi.it 和 voyages.fr 工作负载使用默认 cluster.local/ns/travel-portal/sa/default ServiceAccount，每个命名空间自动定义。

这些信息被传播到 Istio 遥测中，Kiali 可以使用它来定义一组 AuthorizationPolicy 规则和 Istio Sidecars。

挎斗根据当前流量限制每个工作负载可以与之通信的主机列表。

位于“概述”页面中的“创建流量策略”操作将创建这些定义。

这将生成一个主 DENY ALL 规则来保护整个命名空间，以及一个单独的 ALLOW 规则，每个工作负荷在遥测中标识。

它还将为每个工作负载创建一个单独的 Sidecar，每个工作负载都包含一组主机。

例如，我们可以看到，对于 travels-v1 工作负载，以下主机列表已添加到挎斗中。

步骤 3：在旅行门户命名空间中部署负载测试仪门户

如果负载测试器工作负载使用不同的服务帐户，则在部署时，它将不符合上一步中定义的授权策略规则。

kubectl apply -f <(curl -L https://raw.githubusercontent.com/engchina/kiali-demos/master/travels/travel_loadtester.yaml) -n travel-portal

现在，行程工作负载将拒绝负载测试器工作负载发出的请求，这种情况将反映在 Graph 中：

也可以在详细信息页面中使用按响应代码分组的“出站指标”选项卡（仅存在 403 行）进行验证。
（注意：练习时未获得和文档同样效果，此截图是官方文档截图）

检查“日志”选项卡可确认负载测试器工作负载正在按预期从旅行工作负载获取 HTTP 403 禁止响应。
（注意：练习时未获得和文档同样效果，此截图是官方文档截图）

步骤 4：更新行程 v1 授权策略以允许负载测试服务帐户

授权策略资源是使用匹配的选择器为每个工作负载定义的。

作为示例的一部分，我们可以演示如何将服务帐户添加到现有规则中，以仅允许来自负载测试器工作负载的流量进入 travels-v1 工作负载。

正如预期的那样，现在我们可以看到 travels-v1 工作负载接受来自所有 travel-portal 命名空间工作负载的请求，但 travels-v2 和 travels-v3 继续拒绝来自负载测试器源的请求。

使用负载测试器工作负载中的“出站指标”选项卡，我们可以按“远程版本”和“响应代码”进行分组，以获取此授权策略更改的详细视图。

步骤 5：验证代理群集列表是否受挎斗限制

根据 Istio Sidecar 文档，Istio 配置所有网格 sidecar 代理以访问每个网格工作负载。创建挎斗后，主机列表会根据当前流量减少。为了验证这一点，我们可以查找每个代理中配置的集群。

例如，查看cars-v1工作负载，我们可以看到代理可以与之通信的集群数量减少了。

步骤 6：更新或删除 Istio 配置

作为此步骤的一部分，您可以更新为旅行社命名空间生成的授权策略和 Istio Sidecars，并尝试更多安全规则。或者，您可以删除为命名空间生成的 Istio 配置。

卸载旅行演示

总结本教程。要卸载旅行演示应用程序，请执行以下步骤：

kubectl delete namespace travel-agency
kubectl delete namespace travel-portal
kubectl delete namespace travel-control

完结！