Error description:
each time you upgrade the microservice (update the microservice version), there is a period of time when the visitor reports 503. istio-proxy + connect error or disconnect/reset before headers.
Reason:
Kubernetes detects Pod readiness (Running status) when a container in the Pod is ready. But once Istio is deployed, the first Pod ready is the istio-proxy container. istio-proxy receives the traffic and finds that upstream microservice has not been started, so istio-proxy will return 503.
The solution:
once you know why, the idea is simple. Just tell Kubernetes that Pod is ready after all the containers in the Pod have been started. Adding readinessprobes to other containers in Pod allows Kubernetes to confirm that the container is ready before forwarding the traffic. As added in the Pod template

livenessProbe:
      httpGet:
        path: /healthz
        port: 80
        httpHeaders:
      initialDelaySeconds: 10
      periodSeconds: 3

The readinessProbe reference: https://k8smeetup.github.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/