关于istio:如何通过Sidecar自定义资源减少Istio代理资源消耗

32次阅读

共计 2789 个字符，预计需要花费 7 分钟才能阅读完成。

在 Istio 体系中，数据立体次要组件是 istio proxy(envoy)，对于 istio proxy，有两个问题咱们比拟关注：

申请提早
资源耗费

对于申请提早咱们很好了解，毕竟咱们的业务在 mesh 中，多了一层代理。

明天咱们次要讲述 Istio 代理的资源耗费以及如何应用新的 Sidecar 自定义资源来缩小耗费。

与 VirtualService 和 DestinationRule 这些罕用资源不同，Sidecar 资源并不是被所有人熟知。

Sidecar形容了 sidecar 代理的配置，其可协调与其连贯的工作负载实例的入站和出站通信。默认状况下，Istio 将应用达到网格中每个工作负载实例所需的必要配置对网格中的所有 sidecar 代理进行编程，并在与工作负载相干的所有端口上承受流量。Sidecar配置提供了一种微调端口集的性能，代理在将流量转发到工作负载或从工作负载转发流量时代理将承受的协定。此外，当转发来自工作负载实例的出站流量时，能够限度代理能够拜访的服务集。

每个命名空间只能具备一个 Sidecar 配置，而没有任何工作负载选择器，该负载指定该命名空间中所有 Pod 的默认值。对于命名空间范畴的 sidecar，倡议应用默认名称。如果给定命名空间中存在多个不应用选择器的 Sidecar 配置，则零碎的行为是不确定的。如果两个或多个带有工作负载选择器的 Sidecar 配置抉择雷同的工作负载实例，则零碎的行为是不确定的。
默认状况下，MeshConfig 根名称空间中的 Sidecar 配置将利用于所有没有 Sidecar 配置的命名空间。此全局默认 Sidecar 配置不应具备任何工作负载选择器。

接下来咱们通过一些官网示例去更好地了解。

上面的示例在根命名空间中申明了全局默认的 Sidecar 配置 default，该配置在所有命名空间中配置了 sidecar，以仅容许将流量发送到同一命名空间中的其余工作负载以及 istio-system 命名空间中的服务。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: istio-config
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

上面的示例在 prod-us1 命名空间中申明 Sidecar 配置，该配置将笼罩下面定义的全局默认值，并在命名空间中配置 sidecar，以容许拜访 prod-us1，prod-apis 和istio-system命名空间中的服务。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: prod-us1
spec:
  egress:
  - hosts:
    - "prod-us1/*"
    - "prod-apis/*"
    - "istio-system/*"

以下示例在 prod-us1 命名空间中为所有带有标签 app: ratings 的 pod 申明 Sidecar 配置，这些 pod 属于 rating.prod-us1 服务。工作负载在端口 9080 上承受入站 HTTP 通信。而后，将通信转发到侦听 Unix 域套接字的附加工作负载实例。在出站方向上，除了 istio-system 命名空间外，sidecar 仅代理绑定到端口 9080 的 prod-us1 命名空间中的服务的 HTTP 通信。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: ratings
  namespace: prod-us1
spec:
  workloadSelector:
    labels:
      app: ratings
  ingress:
  - port:
      number: 9080
      protocol: HTTP
      name: somename
    defaultEndpoint: unix:///var/run/someuds.sock
  egress:
  - port:
      number: 9080
      protocol: HTTP
      name: egresshttp
    hosts:
    - "prod-us1/*"
  - hosts:
    - "istio-system/*"

Sidecar 形容蕴含以下 4 局部：

workloadSelector — 用于抉择应在其上利用此 Sidecar 配置的特定 Pod/VM 组的条件。如果省略，则 Sidecar 配置将利用于同一名称空间中的所有工作负载实例。
ingress — ingress 指定工作负载实例的入站流量的 Sidecar 的配置。如果省略，Istio 将基于从业务流程平台取得的无关工作负载的信息 (例如，公开的端口，服务等) 主动配置 sidecar。如果指定，则仅当工作负载实例与服务关联时，才配置入站端口。
egress — egress 指定用于解决从连贯的工作负载实例到网格中其余服务的出站流量的 Sidecar 的配置。如果未指定，则从命名空间范畴或全局默认 Sidecar 继承检测到的零碎默认值。
outboundTrafficPolicy — 出站流量策略的配置。如果您的应用程序应用未知的一项或多项内部服务，则将该策略设置为 ALLOW_ANY 将导致 sidecar 将源自该应用程序的所有未知流量路由到其申请的目的地。如果未指定，则从命名空间范畴或全局默认 Sidecar 继承检测到的零碎默认值。

在不应用此自定义资源的状况下，Pilot 会主动将雷同的配置发送到代理，其中蕴含无关网格中每个工作负载实例的信息。

那么应用 Sidecar 自定义资源有什么益处？

平安。Istio 运维能够限度从特定名称空间或工作负载拜访的服务集，因而能够确保这些工作负载将无法访问其范畴之外的任何内容。
性能。默认状况下，集群中的所有 Envoy 代理通过 xDS 从 Pilot 接管雷同的配置，该配置蕴含集群中的所有 Pod。这种配置可能十分宏大，尤其是在大型集群中，而在大多数状况下，简略的工作负载只能与少数几个通信。将此配置更改为仅蕴含一组必要的服务可能会对 Istio 代理的内存占用量产生很大影响。

上面咱们看下测试数据，来比照一下。

下面的两个仪表板显示了基本相同的内存耗费指标，然而第一个仪表板是每个 sidecar，而第二个仪表板是集群中所有 Istio 代理的总内存使用量。

当集群处于闲暇状态时，配置命名空间隔离时，Envoy 代理耗费的内存缩小约 40%。当集群处于负载状态时，百分比差别会放大一点，依然超过 30%。而且这只是一个具备约 150 个 Pod 的 10 节点集群，出站流量仅限于名称空间！在生产集群中，Pod 数量很容易达到数百甚至数千，而且这些限度能够进一步严格到工作负载级别。因而，通过正确的设置，您能够轻松节俭约 40-50%的 sidecar 代理内存耗费。

正文完