apiVersion:v1kind:Podmetadata:name:my-app-with-envoyspec:containers:-name:application<…>
readinessProbe:initialDelaySeconds:15periodSeconds:10failureThreshold:3exec:command:-/healthcheck.sh# using the script-name:envoy<…>
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Pod startup time\n================\n\nThis section explains common Cloud Service Mesh problems with pod startup\ntime and how to resolve them. If you need additional assistance, see\n[Getting support](/service-mesh/v1.24/docs/getting-support).\n\nPod startup and Envoy configuration synchronization\n---------------------------------------------------\n\nA common issue observed during pod startup in some Cloud Service Mesh and\nIstio environments involves the synchronization between application readiness\nand Envoy proxy configuration. The problem arises from the concurrent startup\nof the application container and the Envoy sidecar. The application may signal\nreadiness before the Envoy proxy has completed its initialization and received\nits configuration from the control plane. This creates a race condition where\nincoming requests are directed to an unconfigured Envoy proxy that is not ready\nto receive any traffic. This can lead to requests being dropped, misrouted, or\nhandled incorrectly during the initial phase of application startup, since there\nis no sidecar to forward any traffic.\n\nMitigation strategies\n---------------------\n\nThe following sections describe methods that can mitigate this issue.\n\n### Global mesh configuration: `holdApplicationUntilProxyStarts`\n\nThe first option is to set `holdApplicationUntilProxyStarts: true` in the Istio\nmesh configuration. Note that it is off by default. The flag adds hooks to delay\napplication startup until the pod's proxy is ready to accept traffic.\n\nAdding the configuration eliminates this race but may introduce a delay to\napplication readiness times for new pods if it was not previously enabled.\n\n### Readiness probes\n\nAnother solution is to implement\n[readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)\nthat incorporate both application and Envoy health checks. Readiness probes\ninform Kubernetes when a pod is ready to accept traffic. Critically, the\nreadiness probe logic should verify not only the application's readiness but\nalso the Envoy proxy's status. This can be achieved by querying Envoy's administrator\nport for its health status. By combining both checks, Kubernetes prevents\ntraffic from being directed to the pod until both the application and Envoy are\nfully initialized and configured.\n\nThis approach is more flexible and allows for more complicated startup and\nreadiness logic, but it comes at the cost of more complexity.\n\nCreate the file `healthcheck.sh` from the following code: \n\n #!/bin/sh\n APP_HEALTH=$(curl -s -o /dev/null -w \"%{http_code}\" \\\n http://localhost:8080/health)\n ENVOY_HEALTH=$(curl -s -o /dev/null -w \"%{http_code}\" \\\n http://localhost:9901/ready)\n\n if [[ \"$APP_HEALTH\" -eq 200 && \"$ENVOY_HEALTH\" -eq 200 ]]; then\n exit 0\n else\n exit 1\n fi\n\nReplace the IP/ports with your application container and Envoy's.\n\nThe following YAML file defines a readiness probe that uses the script you\npreviously create: \n\n apiVersion: v1\n kind: Pod\n metadata:\n name: my-app-with-envoy\n spec:\n containers:\n - name: application\n \u003c...\u003e\n readinessProbe:\n initialDelaySeconds: 15\n periodSeconds: 10\n failureThreshold: 3\n exec:\n command:\n - /healthcheck.sh # using the script\n - name: envoy\n \u003c...\u003e\n\nWhat's next\n-----------\n\n- [Learn more about `holdApplicationUntilProxyStarts`](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig-hold_application_until_proxy_starts)"]]