java - 使用istio逐渐温暖k8s中的java应用程序

Question

我有基于 JVM 的应用程序，它们可以提供出色的性能，但在达到最高速度之前需要一些时间“预热”。

istio api (DestinationRule) 不支持端点级别权重，而 envoy 支持。

我想要一个简单的策略:在 pod 准备就绪时，该 pod 的权重 (qps) 保持较低水平并随着时间的推移而增加

例如:让我希望预热时间为 120 秒。 2 个 Pod 拥有 50%-50% 的流量，当新的 Pod 启动时，它将处理低流量并随着时间的推移而增加，并将在 120 秒内达到 33%。

举个例子，我有一个部署，其中有 2 个 Pod 正在运行，当一个新 Pod 到来时，我要为我的应用程序部署一个新版本，流量平均分为 33%，每个 Pod 均分为 3 个 Pod，而新 Pod 无法访问处理流量，因为应用程序需要一些时间来预热并启动线程来处理重负载，在 HPA(水平 Pod 扩展)期间也会出现同样的问题。

我需要一个解决方案来预热 Pod 并根据持续时间逐渐处理新 Pod 的流量

Answer 1

因此，您可以通过多种方式来实现，目标规则中的参数和 VirtualService 的流量分割

使用warmupDurationSecs的简单方法:

Istio中LoadBalancerSettings部分的warmupDurationSecs参数DestinationRule可用于控制新 Pod 流量的逐渐增加。当应用新版本的部署时，Istio 可以在指定的时间内逐渐增加更新的部署到 pod 的流量，以允许 jvm 编译所有需要的热点而不会受到限制。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destination-rule
spec:
  host: my-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 180s
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

因此，在 180 秒内，istio 将增加发送到 pod 的流量，增长速度几乎是线性的:

使用VirtualService更复杂的方式:

使用之前代码示例中的目标规则，您可以定义具有两条权重不同的路由的虚拟服务:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

然后不时更新以增加发送到新版本v2的流量，更多信息请参见istio's tutorial .