[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-27。"],[],[],null,["# Resolving traffic management issues in Cloud Service Mesh\n=========================================================\n\nThis section explains common Cloud Service Mesh problems and how to resolve\nthem. If you need additional assistance, see\n[Getting support](/service-mesh/v1.25/docs/getting-support).\n\nAPI server connection errors in `istiod` logs\n---------------------------------------------\n\nIstiod cannot contact the `apiserver` if you see errors similar to the following: \n\n```\nerror k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused\n```\n\nYou can use the regular expression string `/error.*cannot list resource/` to\nfind this error in the logs.\n\nThis error is usually transient and if you reached the proxy logs using\n`kubectl`, the issue might be resolved already. This error is usually caused\nby events that make the API server temporarily unavailable, such as when an API\nserver that is not in a high availability configuration reboots for an upgrade\nor autoscaling change.\n\nThe `istio-init` container crashes\n----------------------------------\n\nThis problem can occur when the pod iptables rules are not applied to the pod\nnetwork namespace. This can be caused by:\n\n- An incomplete istio-cni installation\n- Insufficient workload pod permissions (missing `CAP_NET_ADMIN` permission)\n\nIf you use the Istio CNI plugin, verify that you followed the instructions\ncompletely. Verify that the `istio-cni-node` container is ready, and check the\nlogs. If the problem persists, establish a secure shell (SSH) into the host node\nand search the node logs for `nsenter` commands, and see if there are any errors\npresent.\n\nIf you don't use the Istio CNI plugin, verify that the workload pod has\n`CAP_NET_ADMIN` permission, which is automatically set by the sidecar injector.\n\nConnection refused after pod starts\n-----------------------------------\n\nWhen a Pod starts and gets `connection refused` trying to connect to an\nendpoint, the problem might be that the application container started before\nthe `isto-proxy` container. In this case, the application container sends the\nrequest to `istio-proxy`, but the connection is refused because `istio-proxy`\nisn't listening on the port yet.\n\nIn this case, you can:\n\n- Modify your application's startup code to make continuous requests to the\n `istio-proxy` health endpoint until the application receives a 200 code. The\n `istio-proxy` health endpoint is:\n\n http://localhost:15020/healthz/ready\n\n- Add a retry request mechanism to your application workload.\n\nListing gateways returns empty\n------------------------------\n\n**Symptom:** When you list Gateways using `kubectl get gateway --all-namespaces`\nafter successfully creating a Cloud Service Mesh Gateway, the command returns\n`No resources found`.\n\nThis problem can happen on GKE 1.20 and later because the GKE Gateway controller\nautomatically installs the GKE `Gateway.networking.x-k8s.io/v1alpha1` resource\nin clusters. To workaround the issue:\n\n1. Check if there are multiple gateway custom resources in the cluster:\n\n kubectl api-resources | grep gateway\n\n Example output: \n\n ```\n gateways gw networking.istio.io/v1beta1 true Gateway\n gatewayclasses gc networking.x-k8s.io/v1alpha1 false GatewayClass\n gateways gtw networking.x-k8s.io/v1alpha1 true Gateway\n ```\n\n \u003cbr /\u003e\n\n2. If the list shows entries other than Gateways with the `apiVersion`\n `networking.istio.io/v1beta1`, use the full resource name or the\n distinguishable short names in the `kubectl` command. For example, run\n `kubectl get gw` or `kubectl get gateways.networking.istio.io` instead of\n `kubectl get gateway` to make sure istio Gateways are listed.\n\nFor more information on this issue, see\n[Kubernetes Gateways and Istio Gateways](/kubernetes-engine/docs/how-to/deploying-gateways#istio-gateways)."]]
