<p>I have JVM-based applications that deliver excellent performance but need some time to “warm up” before reaching the top speed.</p>
<p>istio api (DestinationRule) does not support endpoint level weight, while envoy does.</p>
<p>I want a simple strategy: at the beginning when the pod is ready, the weight (qps) of that pod keeps a low level and increases over time</p>
<p>eg: lets I want the warm-up time to be 120 seconds. 2 pods have 50%-50% traffic, and when a new pod launches it will handle low traffic and increase over time and will reach 33% in 120 sec.</p>
<p>Let's take an example I have one deployment where 2 pods are running and I'm going to deploy a new version for my app when a new pod came traffic is equally divided by 33% each into 3 pods the new pods are unable to handle the traffic because the application needs some time to warm up and initiate the thread to handle the heavy load the same issue is coming during HPA (horizontal pod scaling).</p>
<p>I need a solution to warm up the pod and handle traffic gradually for new pods based on time duration</p>

Anup
<p>So you can do it in several ways, params in Destination Rules and traffic splitting by VirtualService</p>
<p>Simple way by using <strong>warmupDurationSecs</strong>:</p>
<p>The warmupDurationSecs parameter of LoadBalancerSettings section in Istio <a href="https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings" rel="nofollow noreferrer">DestinationRule</a> can be used to control the gradual increase of traffic to a new pod. When a new version of a deployment is applied, Istio can gradually increase the traffic to pods from updated deployment over a specified period of time to allow jvm compile all needed hotspot without throttling.</p>
<pre><code>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
</code></pre>
<p>So during 180 second istio will increase amount of traffic that will be send to pod, speed of growing will be almost linear:
<a href="https://i.stack.imgur.com/iZLQJ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/iZLQJ.png" alt="enter image description here" /></a></p>
<p>More complex way with <strong>VirtualService</strong>:</p>
<p>Using Destination rule from previous code sample you can define a virtual service with two routes that have different weights:</p>
<pre><code>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
</code></pre>
<p>And then update it time to time to increase traffic that will be send to new version <code>v2</code>, see more in <a href="https://istio.io/latest/docs/tasks/traffic-management/traffic-shifting/" rel="nofollow noreferrer">istio's tutorial</a>.</p>
