Service discovery and DNS

This page describes how Google Kubernetes Engine (GKE) implements service discovery and cluster DNS.

Service discovery

In Kubernetes, service discovery is implemented with automatically generated service names that map to the Service's IP address. Service names follow a standard specification: as follows: 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

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

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

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 resolve gke-svc.ns.svc.cluster1 from gke-svc.ns.svc.cluster2.

To learn more about VPC scope DNS, see Using Cloud DNS for GKE.

Multi-cluster Services

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.

/etc/resolv.conf

For Pods using ClusterFirst DNS Policy, the value of /etc/resolv.conf depends on which features are enabled on the cluster:

Cloud DNS for GKE NodeLocal DNSCache /etc/resolv.conf value
Enabled Enabled 169.254.20.10
Enabled Disabled 169.254.169.254
Disabled Enabled kube-dns service IP address
Disabled Disabled kube-dns service IP address

What's next