此内容没有您所选择的语言版本。
Chapter 8. Configure on-premises DNS with CoreDNS (Technology Preview)
Red Hat Connectivity Link integration with CoreDNS for on-premises DNS is currently available in Red Hat Connectivity Link as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
Red Hat Connectivity Link uses a DNSPolicy to manage DNS records based on Gateway API resources. For on-premises DNS servers like CoreDNS, direct integration might require custom controllers or elevated permissions, which can be complex and pose security risks.
To address this challenge, Connectivity Link supports DNS delegation. Instead of directly managing records on the authoritative on-premises DNS server, you configure that server to delegate a specific subdomain (for example, kuadrant.example.local) to CoreDNS instances managed by Connectivity Link.
The DNSPolicy can then interact with the CoreDNS provider within the OpenShift Container Platform cluster. This CoreDNS instance becomes authoritative for the delegated subdomain and manages the necessary DNS records (A, CNAME, and so on) for Gateways within that subdomain.
The delegate field within the DNSPolicy configuration specifies which DNS provider (in this case, CoreDNS) handles the records for the targeted Gateways.
This guide describes how to set up CoreDNS as a DNS provider for Connectivity Link in a multi-cluster, on-premises environment. This integration allows Connectivity Link to manage DNS entries within your internal network infrastructure.
Prerequisites
- Red Hat Connectivity Link is installed on two separate OpenShift Container Platform clusters (primary and secondary).
-
The
kubectlor oc command-line interface is installed and configured for access to both clusters. - You have administrator privileges on both OpenShift Container Platform clusters.
-
Your OpenShift Container Platform clusters have support for the
loadbalancedservice type that allows UDP traffic on port 53, such as MetalLB. For more information, see Load balancing with MetalLB. - You have access to configure your authoritative on-premises DNS server to delegate a subdomain.
- Kustomize is installed.
Procedure
Set up the primary cluster. Set the following environment variables for your primary cluster context:
export CTX_PRIMARY=<primary_cluster_context_name> # e.g., kind-primary export KUBECONFIG=~/.kube/config # Adjust path if necessary export PRIMARY_CLUSTER_NAME=<primary_cluster_name> # e.g., primary export ONPREM_DOMAIN=<your_onprem_domain> # e.g., example.local export KUADRANT_SUBDOMAIN=kuadrant # Subdomain to delegate
export CTX_PRIMARY=<primary_cluster_context_name> # e.g., kind-primary export KUBECONFIG=~/.kube/config # Adjust path if necessary export PRIMARY_CLUSTER_NAME=<primary_cluster_name> # e.g., primary export ONPREM_DOMAIN=<your_onprem_domain> # e.g., example.local export KUADRANT_SUBDOMAIN=kuadrant # Subdomain to delegateCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install CoreDNS using the Connectivity Link kustomization, which includes the required
kuadrantplugin. Apply the following configuration to the primary cluster, replacing <kuadrant-coredns-kustomize-url> with the actual URL for the Kuadrant CoreDNS kustomization.kustomize build --enable-helm github.com/kuadrant/dns-operator/config/coredns?ref=v0.15.0 | kubectl apply --context ${CTX_PRIMARY} -f -kustomize build --enable-helm github.com/kuadrant/dns-operator/config/coredns?ref=v0.15.0 | kubectl apply --context ${CTX_PRIMARY} -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe default CoreDNS Helm chart does not include the
kuadrantplugin. You must use the Connectivity Link-provided kustomization which bundles a customized CoreDNS build.Wait for the CoreDNS service to get an external IP address and store it:
export COREDNS_IP_PRIMARY=$(kubectl --context $CTX_PRIMARY -n kuadrant-system get service <coredns-service-name> -o jsonpath='{.status.loadBalancer.ingress[0].ip}' echo "CoreDNS Primary IP: ${COREDNS_IP_PRIMARY}"export COREDNS_IP_PRIMARY=$(kubectl --context $CTX_PRIMARY -n kuadrant-system get service <coredns-service-name> -o jsonpath='{.status.loadBalancer.ingress[0].ip}' echo "CoreDNS Primary IP: ${COREDNS_IP_PRIMARY}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow You need this IP address later to configure delegation on your authoritative on-premises DNS server.
Create a
ConfigMapto define the authoritative zone for CoreDNS on the primary cluster. This minimal configuration enables thekuadrantplugin and GeoIP features.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe
geoipplugin in this example uses theGeoLite2-City-demo.mmdbdatabase included for demonstration purposes. For production or accurate GeoIP routing, mount your licensed MaxMind GeoIP database into the CoreDNS pod and update the filename in theCorefile.Update the CoreDNS deployment to use the new configuration:
kubectl --context $CTX_PRIMARY -n kuadrant-system patch deployment <coredns-deployment-name> --patch '{"spec":{"template":{"spec":{"volumes":[{"name":"config-volume","configMap":{"name":"coredns-kuadrant-config","items":[{"key":"Corefile","path":"Corefile"}]}}]}}}}'kubectl --context $CTX_PRIMARY -n kuadrant-system patch deployment <coredns-deployment-name> --patch '{"spec":{"template":{"spec":{"volumes":[{"name":"config-volume","configMap":{"name":"coredns-kuadrant-config","items":[{"key":"Corefile","path":"Corefile"}]}}]}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Wait for the deployment rollout to complete:
kubectl --context $CTX_PRIMARY -n kuadrant-system rollout status deployment/<coredns-deployment-name>
kubectl --context $CTX_PRIMARY -n kuadrant-system rollout status deployment/<coredns-deployment-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the Kubernetes
Secretthat Connectivity Link uses to interact with CoreDNS. This secret specifies the zones this provider instance is authoritative for.kubectl create secret generic coredns-credentials \ --namespace=kuadrant-system \ --type=kuadrant.io/coredns \ --from-literal=ZONES="${KUADRANT_SUBDOMAIN}.${ONPREM_DOMAIN}" \ --context ${CTX_PRIMARY}kubectl create secret generic coredns-credentials \ --namespace=kuadrant-system \ --type=kuadrant.io/coredns \ --from-literal=ZONES="${KUADRANT_SUBDOMAIN}.${ONPREM_DOMAIN}" \ --context ${CTX_PRIMARY}Copy to Clipboard Copied! Toggle word wrap Toggle overflow On your authoritative on-premises DNS server, configure delegation for the
${KUADRANT_SUBDOMAIN}.${ONPREM_DOMAIN}subdomain to the external IP addresses of the CoreDNS services running on your primary and secondary clusters ($COREDNS_IP_PRIMARYand$COREDNS_IP_SECONDARY). The specific steps depend on your DNS server software (for example, BIND, Windows DNS Server). You typically need to add NS (Name Server) records pointing the subdomain to the CoreDNS IP addresses. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
After configuring delegation, you can test that DNS resolution for the delegated subdomain works correctly by querying your authoritative DNS server for a record within the kuadrant subdomain. The query should be referred to, and answered by, one of the CoreDNS instances.
Next steps
Create DNSPolicy resources in your OpenShift Container Platform clusters, referencing the coredns-credentials secret as the provider. Connectivity Link manages DNS records within the delegated ${KUADRANT_SUBDOMAIN}.${ONPREM_DOMAIN} zone through the CoreDNS instances.