您的服务网格还好吗？🤔 随着微服务（MSA）架构变得越来越复杂，服务数量的增加，您可能都曾经历过Istio变得越来越臃肿和缓慢。Sidecar代理的内存使用量不断飙升，配置传播的时间也越来越长。
如果您曾考虑过“是不是应该增加服务器配置？”，请等一下！✋ 也许您只是忽略了一个非常简单的设置。今天，我们将深入探讨Sidecar资源，这是Istio性能优化的关键，但许多人却忽视了它。
🌍 默认设置的陷阱：“我会告诉你一切！”
当您安装Istio并将服务加入网格时，默认情况下，注入到每个工作负载中的Sidecar代理（Envoy）会非常友好和勤奋地工作。它过于勤奋，以至于从控制平面（Istiod）接收了网格中所有服务的路由信息、端点等所有配置。
这为什么是个问题呢？🤯
当服务只有10个时，可能没问题。但想象一下，如果增加到100个、500个。即使服务A只需要与服务B通信，它仍然会把完全不相关的C、D、E…Z服务的信息全部接收并堆积在内存中。
这就像给一个只在首尔特定街区送货的快递员，却给了他整个韩国的地图和地址簿。🗺️
- 内存与CPU飙升：不必要的配置信息会急剧增加Sidecar的资源使用量。
- 配置传播缓慢：由于配置量庞大，即使是很小的更改也需要很长时间才能传播到整个网格中的所有代理。
- 性能下降：最终导致整个服务网格的性能下降。
🦸♂️ 救星登场！Sidecar 资源
为了解决这些低效率问题，Sidecar资源应运而生。Sidecar资源的作用是明智地限制每个Sidecar代理的配置范围，使其“只知道它需要知道的”。
换句话说，它是一个将“我会告诉你一切！”模式切换到“我只会告诉你你绝对需要的信息！”模式的开关。💡
Sidecar资源的核心是egress字段。通过此字段，您可以明确指定该工作负载需要对外通信（出站）的目标。
🛠️ 亲自验证一下吧？
例如，假设bookinfo示例中的reviews服务只与ratings服务通信。
1. 应用Sidecar资源之前
如果没有应用任何Sidecar资源，reviews Pod的Sidecar会接收网格中所有服务（如productpage、details等）的配置。您可以通过以下命令进行确认。（结果行数因环境而异。）
# 检查reviews Pod的名称
REVIEWS_POD=$(kubectl get pod -l app=reviews -n bookinfo -o jsonpath='{.items[0].metadata.name}')
# 检查reviews Pod的Sidecar已知集群（服务）列表
istioctl proxy-config clusters $REVIEWS_POD -n bookinfo | wc -l# 原始数据（示例）
# 可能会出现一个相当大的数字。例如...
522. 应用Sidecar资源
现在，让我们为reviews工作负载定义一个Sidecar资源。此配置将限制reviews应用程序仅与同一命名空间（bookinfo）中的ratings服务以及istio-system命名空间中的必要组件进行通信。
# 代码
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: reviews-sidecar
namespace: bookinfo
spec:
# 将此配置应用于带有'app: reviews'标签的Pod。
workloadSelector:
labels:
app: reviews
egress:
# 明确指定出站流量目标。
- hosts:
# 1. 只允许当前命名空间("./")中的服务
- "./ratings.bookinfo.svc.cluster.local"
# 2. 用于控制平面通信（如Istiod）的必要配置
- "istio-system/*"使用kubectl apply -f命令应用上述YAML文件。
3. 应用Sidecar资源之后
稍后，我们再次检查代理配置。
# 稍后再次检查配置
istioctl proxy-config clusters $REVIEWS_POD -n bookinfo | wc -l# 原始数据（示例）
# 会出现一个比之前小得多的数字。例如...
15您看到结果了吗？🚀 reviews Sidecar需要管理的配置量显著减少。这直接导致资源使用量降低和性能提升。
🧐 常见误解和错误方法
在理解Sidecar资源时，存在一些常见的误解。错误的方法反而可能使问题恶化，因此务必加以澄清。
- “直接增加内存/CPU分配量不行吗？” (❌)
- 这并非解决根本原因，而只是用金钱掩盖问题的一种权宜之计。🚚 这就像送货路线效率低下，却去买一辆更大的卡车。Sidecar的资源分配确实应该在Pod定义（Deployment）的
resources字段中进行，但正确的顺序是先优化配置范围，然后根据需要分配资源。 - “关闭Sidecar注入不就行了吗？” (❌)
- 通过命名空间标签或Pod注解（
sidecar.istio.io/inject: "false"）来控制注入，是将该工作负载完全从服务网格中排除。这更像是“放弃”而不是“优化”。我们希望在享受网格优势的同时提升性能，而不是离开网格。 - “这是调节配置更新频率的功能吗？” (❌)
- Sidecar资源不控制更新频率。它只是限制接收配置的范围和大小。
✨ 从整体角度看
虽然应用单个Sidecar资源很重要，但最好从整体角度来处理。
- 命名空间隔离：首先，将命名空间级别的Sidecar资源设置为基线，以便每个命名空间只能看到其他命名空间中绝对必要的服务（例如，
./*、istio-system/*以及其他所需的命名空间，如namespace-b/*）。 - 工作负载特化：之后，如果存在像
reviews服务这样通信范围特别窄的工作负载，使用workloadSelector应用更细粒度的Sidecar资源将是一种有效的策略。
这种方法使您的服务网格更加健壮、可预测，最重要的是，更快。如果您的Istio不知何故变慢了，请立即检查您的Sidecar资源！
发表回复