[[["易于理解","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-09-04。"],[],[],null,["# Service discovery\n\nThis document is an overview of Kubernetes DNS-based service discovery\nand how it can be used with Kf.\n\nWhen to use Kubernetes service discovery with Kf\n------------------------------------------------\n\nKubernetes service discovery can be used by applications that need to locate\nbacking services in a consistent way regardless of where the application is\ndeployed. For example, a team might want to use a common URI in their\nconfiguration that always points at the local SMTP gateway to decouple code from\nthe environment it ran in.\n\nService discovery helps application teams by:\n\n- Reducing the amount of per-environment configuration.\n- Decoupling client and server applications.\n- Allowing applications to be portable to new environments.\n\nYou can use Kubernetes service discovery when:\n\n- Applications use their container's DNS configurations to resolve hosts.\n- Applications are deployed with their backing services in the same Kubernetes cluster or namespace.\n- Backing services have an associated [Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/). Kf creates these for each app.\n- Kubernetes NetworkPolicies allow traffic between an application and the Kubernetes service it needs to communicate with. Kf creates these policies in each Kf space.\n\nYou **should not** use Kubernetes service discovery if:\n\n- Applications need to failover between multiple clusters.\n- You override the DNS resolver used by your application.\n- Applications need specific types of load balancing.\n\nHow Kubernetes service discovery works\n--------------------------------------\n\nKubernetes service discovery works by\n[modifying the DNS configuration](/kubernetes-engine/docs/concepts/service-discovery)\nof containers running on a Kubernetes node. When an application looks up an\nunqualified domain name, the local DNS resolver will first attempt to resolve\nthe name in the local cluster.\n\nDomains without multiple parts will be resolved against the names of Kubernetes\nservices in the container's namespace. Each Kf app\ncreates a Kubernetes service with the same name. If two\nKf apps `ping` and `pong` were deployed in the same\nKf space, then `ping` could use the URL `http://pong` to\nsend traffic to the other service.\n\nDomains with a single dot will be resolved against the Kubernetes services in\nthe Kubernetes namespace with the same name as the label after the dot. For\nexample, if there was a PostgreSQL database with a `customers` service in the\n`database` namespace, an application in another namespace could\nresolve it using `postgres://customers.database`.\n\nHow to use service discovery with Kf\n------------------------------------\n\nKubernetes DNS based service discovery can be used in any\nKf app. Each Kf app creates a\nKubernetes service of the same name, and each Kf\nspace creates a Kubernetes namespace with the same name.\n\n- Refer to a Kf app in the current space using \u003cvar translate=\"no\"\u003eprotocol\u003c/var\u003e`://`\u003cvar translate=\"no\"\u003eapp-name\u003c/var\u003e.\n- Refer to a Kf app in a different space using \u003cvar translate=\"no\"\u003eprotocol\u003c/var\u003e`://`\u003cvar translate=\"no\"\u003eapp-name\u003c/var\u003e`.`\u003cvar translate=\"no\"\u003espace-name\u003c/var\u003e.\n- Refer to a Kf app in the current space listening on a custom port using \u003cvar translate=\"no\"\u003eprotocol\u003c/var\u003e`://`\u003cvar translate=\"no\"\u003eapp-name\u003c/var\u003e`:`\u003cvar translate=\"no\"\u003eport\u003c/var\u003e.\n- Refer to a Kf app in a different space listening a custom port using \u003cvar translate=\"no\"\u003eprotocol\u003c/var\u003e`://`\u003cvar translate=\"no\"\u003eapp-name\u003c/var\u003e`.`\u003cvar translate=\"no\"\u003espace-name\u003c/var\u003e`:`\u003cvar translate=\"no\"\u003eport\u003c/var\u003e.\n\n| **Note:** For Kubernetes services managed by Kf, TCP port 80 always maps to the same port in the app's `PORT` environment variable. This is even true if the Kf app doesn't serve HTTP traffic.\n\nBest practices\n--------------\n\nApplications that are going to be the target of DNS based service discovery\nshould have frequent [health checks](/migrate/kf/docs/2.11/how-to/manifest#health_check_types)\nto ensure they are rapidly added and removed from the pool of hosts that accept\nconnections.\n\nApplications using DNS based service discovery should not cache the IP addresses\nof the resolved services because they are not guaranteed to be stable.\n\nIf environment specific services exist outside of the cluster, they can be\nresolved using Kubernetes DNS if you set up\n[ExternalName Kubernetes services](https://kubernetes.io/docs/concepts/services-networking/service/#externalname).\nThese Kubernetes services provide the same resolution capabilities, but return a\nCNAME record to redirect requests to an external authority.\n\nComparison to Eureka\n--------------------\n\nEureka is an open source client-side load-balancer created by Netflix. It is\ncommonly used as part of the\n[Spring Cloud Services](https://docs.pivotal.io/spring-cloud-services/3-1/common/service-registry/index.html)\nservice broker. Eureka was\n[built to be a regional load balancer and service discovery mechanism](https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance#what-is-eureka)\nfor services running in an environment that caused frequent disruptions to\nworkloads leading to unstable IP addresses.\n\nEureka is designed as a client/server model. Clients register themselves with\nthe server indicating which names they want to be associated with and\nperiodically send the server heartbeats. The server allows all connected clients\nto resolve names.\n\nIn general, you should use Kubernetes DNS rather than Eureka in Kubernetes for\nthe following reasons:\n\n- DNS works with all programming languages and applications without the need for libraries.\n- Your application's existing health check will be reused reducing combinations of errors.\n- Kubernetes manages the DNS server, allowing you to rely on fewer dependencies.\n- Kubernetes DNS respects the same policy and RBAC constraints as the rest of Kubernetes.\n\nThere are a few times when deploying a Eureka server would be advantageous:\n\n- You need service discovery across Kubernetes and VM based applications.\n- You need client based load-balancing.\n- You need independent health checks.\n\nWhat's next\n-----------\n\n- [Read more about service discovery in GKE](/kubernetes-engine/docs/concepts/service-discovery).\n- Learn about [Service Directory](/service-directory), a managed offering similar to Eureka."]]
