What are the primary modes of service discovery within a Kubernetes cluster?

What are the primary modes of service discovery within a Kubernetes cluster?

• A. Environment Variables and DNS
• B. Host file entries
• C. Static config maps
• D. API server calls

Answer: (A)

In Kubernetes, applications discover services mainly through two built-in mechanisms: DNS and environment variables. DNS provides dynamic, names-based discovery by resolving a service name to its cluster IP, so you can reach a service by its name (often using the full domain like service.namespace.svc.cluster.local) and the DNS system updates as services and endpoints change. Environment variables are another runtime mechanism: for each service, Kubernetes injects host and port details into containers, giving apps a straightforward way to connect without DNS lookups. These approaches work together because a service has a stable virtual IP and a set of endpoints that map to the current pods, so DNS stays in sync with the actual endpoints, and the environment variables reflect the same service access details. Host file entries aren’t used for dynamic service discovery in a cluster, as they would require manual updates. Static config maps are for configuration data, not discovering or routing to services. API server calls can fetch service objects, but they aren’t the typical in-cluster runtime path that applications use for discovering and connecting to services.

In Kubernetes, applications discover services mainly through two built-in mechanisms: DNS and environment variables. DNS provides dynamic, names-based discovery by resolving a service name to its cluster IP, so you can reach a service by its name (often using the full domain like service.namespace.svc.cluster.local) and the DNS system updates as services and endpoints change. Environment variables are another runtime mechanism: for each service, Kubernetes injects host and port details into containers, giving apps a straightforward way to connect without DNS lookups.

These approaches work together because a service has a stable virtual IP and a set of endpoints that map to the current pods, so DNS stays in sync with the actual endpoints, and the environment variables reflect the same service access details.

Host file entries aren’t used for dynamic service discovery in a cluster, as they would require manual updates. Static config maps are for configuration data, not discovering or routing to services. API server calls can fetch service objects, but they aren’t the typical in-cluster runtime path that applications use for discovering and connecting to services.