This page describes how Google Kubernetes Engine (GKE) implements service discovery and cluster DNS.
In Kubernetes, service discovery is implemented with automatically generated
service names that map to the Service's IP address. Service names follow a
my-svc.my-namespace.svc.cluster-domain.example. Pods can also
access external services through their names, such as
example.com. For more
information about how DNS works in Kubernetes, see
DNS for Services and Pods.
Cluster DNS in GKE
Autopilot clusters always use kube-dns and you cannot modify the DNS provider.
For Standard, GKE provides the following cluster DNS options to resolve service names and external names:
- kube-dns: a cluster add-on that is deployed by default in all GKE clusters.
- Cloud DNS: a cloud-managed cluster DNS infrastructure that leverages Cloud DNS and does not require managing in-cluster DNS servers such as kube-dns.
You can also register your services with Service Directory for GKE.
GKE also provides NodeLocal DNSCache as an optional add-on that can be used with kube-dns or Cloud DNS.
kube-dns is the default DNS provider for Standard clusters and the only DNS provider for Autopilot clusters.
kube-dns runs as a Deployment that schedules kube-dns pods to nodes in the cluster.
To learn more about kube-dns, see Using kube-dns.
Cloud DNS provides Pod and Service DNS resolution without a cluster-hosted DNS provider like kube-dns. The Cloud DNS controller automatically provisions DNS records for pods and services in Cloud DNS for ClusterIP, headless and external name services.
To learn how to configure Cloud DNS, see Using Cloud DNS for GKE.
NodeLocal DNSCache runs as a DaemonSet that schedules a DNS cache Pod on every cluster node. This DNS cache improves DNS lookup latency, makes DNS lookup times more consistent, and can reduce the number of DNS queries to kube-dns or Cloud DNS.
To learn how to configure NodeLocal DNSCache, see Setting up NodeLocal DNSCache.
Service discovery outside a single cluster
You can configure service discovery beyond the scope of a single cluster using one of the following methods.
Cloud DNS VPC scope
A cluster that uses Cloud DNS for cluster DNS must operate in one of two available modes: GKE cluster scope or Virtual Private Cloud (VPC) scope.
When you configure a cluster in cluster scope, DNS records are only resolvable
within the cluster using the schema
<svc>.<ns>.svc.cluster.local. This is the
same behavior as kube-dns.
When you configure a cluster in VPC scope, DNS records for
cluster services are resolvable within the entire VPC. This
means that clients in the same VPC or connected to the
VPC through Cloud VPN or Cloud Interconnect can directly
resolve the DNS records for Services in the GKE cluster. You can
also configure unique cluster DNS names so that non-GKE clients
can resolve DNS records. For example, a non-GKE client could
To learn more about VPC scope DNS, see Using Cloud DNS for GKE.
Multi-cluster Services provides multi-cluster service discovery and load balancing for GKE that leverages the existing Service object. Multi-cluster Services are discoverable and accessible across any GKE cluster with a single virtual IP address. This is the same behavior as a ClusterIP Service that is accessible in a single cluster.
Multi-cluster Services aggregates service across clusters and makes them
addressable as a single multi-cluster DNS record using the schema
<svc>.<ns>.svc.clusterset.local. This provides a unique name for a given
service that is consistent and addressable from any GKE cluster
using multi-cluster Services.
To learn more about Multi-cluster Services, see Multi-cluster Services.
Service Directory for GKE
Service Directory for GKE provides a single view of services across all of your Kubernetes deployments. Service Directory can register both GKE and non-GKE services in a single registry. Service Directory is particularly useful if you want:
- A single registry for Kubernetes and non-Kubernetes applications to discover each other.
- A managed service discovery tool.
- To store metadata about your service that can be accessed by other clients.
- To set access permissions on a per-service level.
Service Directory services can be resolved via DNS, HTTP, and gRPC. Service Directory is integrated with Cloud DNS, and can populate Cloud DNS records that match services in Service Directory.
To learn more, see Configuring Service Directory for GKE.
For Pods using
ClusterFirst DNS Policy,
the value of
/etc/resolv.conf depends on which features are enabled on the
|Cloud DNS for GKE||NodeLocal DNSCache||
|Disabled||Enabled||kube-dns service IP address|
|Disabled||Disabled||kube-dns service IP address|
- Learn how to use Cloud DNS for GKE.
- Learn how to provide scalable DNS resolution for clusters requiring high volumes of DNS queries using NodeLocal DNSCache.