<p>I have been tested OutlierDetection for one upstream pod. I expected that istio prevents request goes to target upstream pod.</p>
<p>My test environment:</p>
<ul>
<li>Tested on docker-desktop, k8s, istio, github + argocd</li>
<li>Target upstream pod always returns 500 http status and logs the request.</li>
<li>Requests were repeatedly sent within another pod like this: <code>while [ true ]; do date; curl -v 'http://http-echo-svc.trafficmgmt:80/500'; sleep 1; done</code></li>
<li>DestinationRule yaml:</li>
</ul>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-status-echo
spec:
  host: http-echo-svc.trafficmgmt
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 6
      interval: 30s
      baseEjectionTime: 2m 
      maxEjectionPercent: 100
      minHealthPercent: 0
</code></pre>
<p>And pod &amp; service yaml:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Pod
metadata:
  name: status-echo
  labels:
    app.kubernetes.io/name: echo-pod
spec:
  containers:
    - name: status-echo
      image: status-echo:0.0.3
      imagePullPolicy: Never
      ports:
        - containerPort: 8087
          name: http-echo-port
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo-svc
spec:
  selector:
    app.kubernetes.io/name: echo-pod
  ports:
    - name: http-echo
      protocol: TCP
      port: 80
      targetPort: http-echo-port
</code></pre>
<p>Upstream pod logged every requests. That means circuit breaker was not working.</p>
<p>Does OutlierDetection not work for one upstream or is my configuration wrong?</p>

Youngrok Ko
<p>The configuration looks right; I tried with the <code>fake-service</code> and configured it to always return 500.</p>
<p>Here's my configuration (that's equivalent to what you have, with the exception of different image):</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Pod
metadata:
  name: status-echo
  labels:
    app.kubernetes.io/name: echo-pod
spec:
  containers:
    - name: fake-service
      image: nicholasjackson/fake-service:v0.25.2
      env:
        - name: ERROR_RATE
          value: &quot;1&quot;
        - name: ERROR_CODE
          value: &quot;500&quot;
      imagePullPolicy: Always
      ports:
        - containerPort: 9090
          name: http-echo-port
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo-svc
spec:
  selector:
    app.kubernetes.io/name: echo-pod
  ports:
    - name: http-echo
      protocol: TCP
      port: 80
      targetPort: 9090
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-status-echo
spec:
  host: http-echo-svc
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 6
      interval: 30s
      baseEjectionTime: 2m 
      maxEjectionPercent: 100
      minHealthPercent: 0
</code></pre>
<p>I am running curl from within a pod inside the cluster and on the first 6 tries, this is the response I get from the <code>status-echo</code> pod:</p>
<pre class="lang-bash prettyprint-override"><code>&lt; HTTP/1.1 500 Internal Server Error
&lt; date: Wed, 26 Jul 2023 20:35:18 GMT
&lt; content-length: 164
&lt; content-type: text/plain; charset=utf-8
&lt; x-envoy-upstream-service-time: 4
&lt; server: envoy
&lt;
{
  &quot;name&quot;: &quot;Service&quot;,
  &quot;uri&quot;: &quot;/&quot;,
  &quot;type&quot;: &quot;HTTP&quot;,
  &quot;ip_addresses&quot;: [
    &quot;10.42.0.64&quot;
  ],
  &quot;code&quot;: 500,
  &quot;error&quot;: &quot;Service error automatically injected&quot;
}
</code></pre>
<p>On the 7th request, the response changes and looks like this:</p>
<pre><code>&lt; HTTP/1.1 503 Service Unavailable
&lt; content-length: 19
&lt; content-type: text/plain
&lt; date: Wed, 26 Jul 2023 20:35:55 GMT
&lt; server: envoy
&lt;
* Connection #0 to host http-echo-svc left intact
no healthy upstream
</code></pre>
<p>Which basically means that the outlier detection kicked in and ejected the one failing host (hence the <code>no healthy upstream</code> response). Similarly, if you look at the logs from the istio-proxy (on the client side), you'll see a similar error:</p>
<pre><code>&quot;GET / HTTP/1.1&quot; 503 UH no_healthy_upstream
</code></pre>
