Get to know the DNS controller#

Background#

About connecting to off-mesh services#

By default, Aspen Mesh is configured not to allow on-mesh services to connect to off-mesh services. To allow on-mesh services to connect to an off-mesh service, you create a Kubernetes object called an Istio service entry for the off-mesh service. If an Istio service entry exists for an off-mesh service, any pod with a sidecar—that is, any pod in the mesh—can connect to that off-mesh service.

How Istio performs off-mesh service authorization#

This table explains what happens when an application container wants to connect to an off-mesh service:

Stage	Description
1	The application container queries the Kubernetes DNS server (for example, CoreDNS) to get the IP address of the off-mesh service.
2	To connect to the off-mesh service, the application container provides the IP address to its sidecar proxy.
3	The sidecar proxy compares the IP address provided by the application container to the sidecar’s list of IP addresses for all Istio service entries. If the comparison is unsuccessful, the sidecar doesn’t allow the connection.

The Istio service entry’s resolution field#

An Istio service entry has a resolution field that specifies how the sidecar proxy should resolve the IP address of the off-mesh service.

Resolution-field values#

The resolution field can have one of several values. This table describes two common values.

Resolution-field value	Description
Static	The IP address of the off-mesh service doesn’t change regularly. The IP address is specified in the Istio service entry. When the Istio service entry is created or modified, all sidecar proxies are provided with the IP address of the off-mesh service.
DNS	The IP address of the off-mesh service may change over time. The IP address is not specified in the Istio service entry. All sidecar proxies must independently and repeatedly query the Kubernetes DNS server to obtain the IP address of the off-mesh service.

What to notice about DNS-resolution Istio service entries#

As the number of DNS-resolution Istio service entries and the number of sidecar proxies increase, the number of sidecar queries to the Kubernetes DNS server increases rapidly.

How DNS queries for DNS-resolution Istio service entries work without the DNS controller#

This diagram shows how, without the DNS controller, all sidecar proxies query the Kubernetes DNS server to obtain the IP addresses of off-mesh services associated with DNS-resolution Istio service entries.

../_images/istio-service-entry-dns-queries-without-dns-controller.svg

About the DNS controller#

Introduction#

For Istio service entries that meet specific requirements, the DNS controller can reduce the DNS traffic between sidecar proxies and the Kubernetes DNS server. And unlike the sidecar proxies, the DNS controller performs negative-cache processing.

Availability#

The DNS controller is available in Aspen Mesh 1.11.8-am3 and later.

How the DNS controller works#

You convert an original, DNS-resolution Istio service entry to an Aspen Mesh DNS static entry, which the DNS controller uses to create a managed, static-resolution Istio service entry. The DNS controller, not each sidecar proxy, queries the Kubernetes DNS server when necessary and updates the managed, static-resolution Istio service entry with the IP address of the off-mesh service.

Because the managed Istio service entry has a static resolution, all sidecar proxies are provided with the IP address of the off-mesh service when the DNS controller creates or updates the managed Istio service entry. Sidecars don’t need to query the Kubernetes DNS server to obtain the IP address of the off-mesh service.

How DNS queries for DNS-resolution Istio service entries work with the DNS controller#

This diagram shows how, with the DNS controller, no sidecar proxies query the Kubernetes DNS server to obtain the IP addresses of off-mesh services associated with DNS-resolution Istio service entries (that you’ve converted to Aspen Mesh DNS static entries). The DNS controller queries the Kubernetes DNS server on behalf of all sidecar proxies.

../_images/istio-service-entry-dns-queries-with-dns-controller.svg

Requirements for original Istio service entries#

To be eligible for conversion to Aspen Mesh DNS static entries, original Istio service entries must meet the following requirements:

The value of .spec.resolution must be DNS. Other values are not supported.
The list of hosts in .spec.hosts must include only one host.
The host specified in .spec.hosts must not use a wildcard prefix (for example, *.google.com).
The .spec.endpoints field must not be included.

Support for multiple DNS-controller instances#

Introduction#

If you don’t want to use the same Kubernetes DNS server for all of your Aspen Mesh DNS static entries, you can install more than one DNS-controller instance.

Definition: DNS-controller realm#

A DNS-controller realm is a set of labeled namespaces associated with a DNS-controller instance. All Aspen Mesh DNS static entries in a realm are managed by that realm’s DNS-controller instance.

Types of DNS-controller instances#

There are two types of DNS-controller instances:

Type	Definition
Realm-specific	A DNS-controller instance that manages only the Aspen Mesh DNS static entries in a specified realm. A cluster can have multiple realm-specific DNS-controller instances.
General	A DNS-controller instance that manages all the Aspen Mesh DNS static entries that are not in a realm. A cluster can have only one general DNS-controller instance.

One way to assign a DNS-controller instance to a Kubernetes DNS server#

To assign a DNS-controller instance to a nondefault Kubernetes DNS server, you could install a mutating webhook that changes the .spec.dnsConfig.nameservers field for workloads based on a DNS-server label (for example, dns-server=spk) and add the DNS-server label to the namespace in which the DNS-controller instance is installed. (To assign a DNS-controller instance to the default Kubernetes DNS server, you’d simply not add the DNS-server label to the namespace in which the DNS-controller instance is installed.)

Example: Kubernetes cluster with three DNS-controller instances#

This is an example of a Kubernetes cluster with three DNS-controllers, three Kubernetes DNS servers, and a mutating webhook that assigns realm-specific DNS-controller instances and other workloads in a namespace to a Kubernetes DNS server based on a DNS-server label applied to the namespace.

DNS-controller instances in the example#

This table describes the DNS-controller instances in the example Kubernetes cluster:

DNS controller instance	Description
DNS controller (general)	Manages Aspen Mesh DNS static entries in namespaces without a realm label. This DNS-controller instance and other workloads in namespaces without a DNS-server label use the default DNS server.
DNS controller (realm a)	Manages Aspen Mesh DNS static entries in namespaces with the `dnscontroller/realm=a` realm label. This DNS-controller instance and other workloads in namespaces with the `dns-server=spk` DNS-server label use the SPK DNS server.
DNS controller (realm b)	Manages Aspen Mesh DNS static entries in namespaces with the `dnscontroller/realm=b` realm label. This DNS-controller instance and other workloads in namespaces with the `dns-server=alt` DNS-server label use the Alt DNS server.