This vCluster.Pro feature allows you to add custom DNS rules to the vCluster to allow communication across services in separate vClusters as well as services deployed in the host cluster.
Records, Modes and Targets
The spec for this is basically divided into 3 parts – Records, Modes and Targets.
- Record: A
recordis a section that is supposed to match a lookup for a DNS query. It can be of three types:
fqdn- is basically any 'fully qualified domain name' and will be mapped to a target of your choice
service– it is basically a mocked name of type
service_name/namespace. Any DNS query of the form
<service_name>.<namespace>will be mapped to the one in the target
namespace- this allows mapping services in an entire namespace into a namespace inside vcluster.
- Target: A
targetis a specification about what should be returned as a response to a matched
modefiled. This basically also currently has the following 4 options:
mode– specifies where to find the target, is explained in detail in next section.
vcluster- specifies that the target service is to be found in this vcluster. Only used when the
service- specifies target service itself. Needs to be in the
namespace- specifies that target namespace itself. Only used in case where
target.namespaceis set. This is for namespace-to-namespace mapping.
- Mode: A
modeis a specificaition in which a record and target combination should work in. Currently we support the following 4 modes:
url– This specifies that the record - target combination are basically just 2 FQDN mapping one to another (more details in the examples below)
host- This specifies that the DNS queries matching from the
recordfield should be mapped to the
targetin the 'host' cluster.
vcluster- This specifies that the DNS queries matching from
recordare to be mapped according to the target spec inside the given vcluster.
self- This specifies that the matching DNS queries are to be mapped to another service in that same vcluster itself
Below is the specification of how the above-explained fields are to be specified and their expected values
mode: url | host | vcluster | self
Below are a few examples showcaseing some possible combinations of the above explained fields and sections
Mapping an FQDN
Consider the following example config
This is purely a url
mode based mapping – mapping one
fqdn inside the vcluster to another
Hence dns lookups of
wikipedia.com would return a DNS response with answer as
Mapping service to host cluster service
Mapping a service inside vcluster to service on host cluster
As specified by
mode: host, this config maps
my-namespace/my-svc inside vcluster to
dns-test/nginx-svc service in the host cluster.
In this case the DNS response would be the service IP of the
dns-test namespace of the host cluster.
Mapping services across vcluster
Mapping a service inside vcluster to another service in a separate vcluster
In this case, as specified with
mode: vcluster – the target service is in another vcluster.
Here the service
my-ns-in-vcluster/my-svc-vcluster is mapped to
a vcluster named
test-vcluster deployed in namespace
Mapping with service aliasing
Mapping a service in the same vcluster but under a different alias
In this case the service
my-self-vc-ns/my-self-vc-svc is mapped to
dns-test/nginx-svc from the same vcluster itself.
Mapping whole namespaces
Mapping all services under a particular namespace under another namespace in vcluster
Here, all services in the target namespace
test-in-vcluster-ns of the vcluster
test-vcluster are mapped inside a namespace
One can visualize it as:
│nginx.external-vc-ns ││nginx.test-in-vcluster-ns │
│svcA.external-vc-ns ││svcA.test-in-vcluster-ns │
│svcB.external-vc-ns ││svcB.test-in-vcluster-ns │
│... ││... │
The same is possible under the
mode: host as well.