启用 Sidecar 注入
以下操作步骤使用 Bookinfo 应用演示配置 Sidecar 注入的各种方法。
先决条件
- 已安装 Alauda Service Mesh v2 Operator,已创建
Istio资源,并且 Operator 已成功部署 Istio。 - 已创建
IstioCNI资源,并且 Operator 已部署所需的IstioCNIPod。 - 已创建计划加入网格的命名空间,并且 Istio 控制平面可以发现这些命名空间。
- 可选:计划加入网格的工作负载已完成部署。在后续示例中,Bookinfo 应用部署在
bookinfo命名空间中,但尚未配置 Sidecar 注入(如步骤 2 所述)。有关详细信息,请参阅“部署 Bookinfo 应用”。
使用命名空间标签启用 Sidecar 注入
此方法会将 Sidecar 代理注入给定命名空间中的所有工作负载。当该命名空间中的大多数工作负载都需要加入网格时,这是理想的方法。
操作步骤
-
使用以下命令检查 Istio 控制平面的修订版本名称:
您应看到类似以下示例的输出:
示例输出
由于修订版本名称为
default,因此可以使用标准注入标签,而无需指定确切的修订版本。 -
运行以下命令,确认目标命名空间中的现有工作负载显示
1/1个就绪容器。这可以验证 Pod 当前未运行 Sidecar。您应看到类似以下示例的输出:
示例输出
-
执行以下命令,为
bookinfo命名空间应用注入标签:示例输出
-
要应用 Sidecar 注入,请重新部署
bookinfo命名空间中的工作负载。使用以下命令对所有 Deployment 发起滚动更新:
验证
-
要验证发布是否完成,请检查新 Pod 是否显示处于
READY状态的2/2个容器,这表示 Sidecar 注入成功。使用以下命令:您应看到类似以下示例的输出:
示例输出
将工作负载排除在网格之外
即使整个命名空间已启用注入,也可以阻止为特定工作负载注入 Sidecar。
此示例仅用于演示。要使 Bookinfo 应用正常运行,其所有工作负载都必须加入网格。
操作步骤
-
编辑应用的
Deployment资源。在此示例中,我们将排除ratings-v1服务。 -
在
Deployment的spec.template.metadata.labels部分中,添加标签sidecar.istio.io/inject: "false"以禁用 Sidecar 注入。NOTE如果将此标签添加到
Deployment顶层的labels部分,则不会影响 Sidecar 注入过程。更新 Deployment 时会触发发布,从而创建包含修改后 Pod 的新 ReplicaSet。
验证
-
执行以下命令,确认更新后的 Pod 不包含 Sidecar 容器,并显示
1/1个运行中容器:您应看到类似以下示例的输出:
示例输出
使用 Pod 标签启用 Sidecar 注入
使用此方法,可以选择单个工作负载进行 Sidecar 注入,而不必为整个命名空间启用注入。此方法最适用于只有少量工作负载需要加入服务网格的情况。此示例还展示了如何使用修订版本标签进行 Sidecar 注入,其中 Istio 资源名为 my-mesh。当一个集群中存在多个 Istio 控制平面,或在基于修订版本进行控制平面升级期间,必须使用不同的 Istio 资源名称。
操作步骤
-
运行以下命令,检查 Istio 控制平面的修订版本名称:
您应看到类似以下示例的输出:
示例输出
由于修订版本名称为
my-mesh,因此必须使用修订版本标签istio.io/rev=my-mesh来激活 Sidecar 注入。 -
检查现有 Pod 是否显示处于
READY状态的1/1个容器,以确认它们在未使用 Sidecar 的情况下运行。使用以下命令:您应看到类似以下示例的输出:
示例输出
-
编辑应用的
Deployment资源。在此示例中,修改ratings-v1服务。 -
修改
Deployment的spec.template.metadata.labels部分,添加所需的 Pod 注入标签或修订版本标签。此处为istio.io/rev: my-mesh:NOTE将标签放在
Deployment资源的顶层labels部分中不会影响 Sidecar 注入。此 Deployment 更新会发起发布,从而生成包含已更改 Pod 的新 ReplicaSet。
验证
-
验证只有
ratings-v1Pod 显示2/2个就绪容器,以确认 Sidecar 已成功注入。运行以下命令:您应看到类似以下示例的输出:
示例输出
-
对要添加到网格中的任何其他工作负载重复相同的操作步骤。