<p>I've this configuration on my service mesh:</p>

<ul>
<li>mTLS globally enabled and meshpolicy default </li>
<li>simple-web deployment exposed as clusterip on port 8080</li>
<li>http gateway for port 80 and virtualservice routing on my service</li>
</ul>

<p>Here the gw and vs yaml</p>

<pre><code>apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway # Specify the ingressgateway created for us
  servers:
  - port:
      number: 80 # Service port to watch
      name: http-gateway
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: simple-web
spec:
  gateways:
  - http-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /simple-web
    rewrite:
      uri: /
    route:
    - destination:
        host: simple-web
        port:
          number: 8080
</code></pre>

<p>Both vs and gw are in the same namespace.
The deployment was created and exposed with these commands:</p>

<pre><code>k create deployment --image=yeasy/simple-web:latest simple-web
k expose deployment simple-web --port=8080 --target-port=80 --name=simple-web
</code></pre>

<p>and with k get pods I receive this:</p>

<pre><code>pod/simple-web-9ffc59b4b-n9f85   2/2     Running
</code></pre>

<p>What happens is that from outside, pointing to ingress-gateway load balancer I receive 503 HTTP error.
If I try to curl from ingressgateway pod I can reach the simple-web service.
Why I can't reach the website with mTLS enabled? What's the correct configuration?</p>

Manuel Castro
<p>As @suren mentioned in his answer this issue is not present in istio version 1.3.2 . So one of solutions is to use newer version.</p>

<p>If you chose to upgrade istio to newer version please review documentation <a href="https://istio.io/docs/setup/upgrade/steps/" rel="nofollow noreferrer">1.3 Upgrade Notice</a> and <a href="https://istio.io/docs/setup/upgrade/notice/" rel="nofollow noreferrer">Upgrade Steps</a> as Istio is still in development and changes drastically with each version.</p>

<p>Also as mentioned in comments by @Manuel Castro this is most likely issue addressed in <a href="https://istio.io/docs/ops/traffic-management/deploy-guidelines/#avoid-503-errors-while-reconfiguring-service-routes" rel="nofollow noreferrer">Avoid 503 errors while reconfiguring service routes</a> and newer version simply handles them better.</p>

<blockquote>
  <p>Creating both the VirtualServices and DestinationRules that define the
  corresponding subsets using a single kubectl call (e.g., kubectl apply
  -f myVirtualServiceAndDestinationRule.yaml is not sufficient because the resources propagate (from the configuration server, i.e.,
  Kubernetes API server) to the Pilot instances in an eventually
  consistent manner. If the VirtualService using the subsets arrives
  before the DestinationRule where the subsets are defined, the Envoy
  configuration generated by Pilot would refer to non-existent upstream
  pools. This results in HTTP 503 errors until all configuration objects
  are available to Pilot.</p>
</blockquote>

<p>It should be possible to avoid this issue by temporarily disabling <code>mTLS</code> or by using <code>permissive mode</code> during the deployment.</p>
