Skip to main content

Setting Up And Managing FQDNs

Configure CoreDNS for Access (MicroK8s)​

Editing the CoreDNS ConfigMap​

The CoreDNS configuration is stored in a ConfigMap within the kube-system namespace. To edit it, run:

kubectl edit configmap coredns -n kube-system

This command opens the CoreDNS Corefile in your default editor for modification.

Original Corefile​

.:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    log . {
      class error
    }
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

Required Modifications​

1. Add the header Plugin​

Insert the following snippet at the beginning of the Corefile:

header {
    response set ra
}

2. Add the hosts Plugin​

Insert the snippet below above the forward . /etc/resolv.conf line:

hosts {
    192.168.1.201 idhub.sath.com
    fallthrough
}

Note: Replace 192.168.1.201 with your server's actual local IP address (determine it using the ip a command).

Final Corefile​

.:53 {
    header {
      response set ra
    }
    errors
    health {
      lameduck 5s
    }
    ready## Configure FQDN
    log . {
      class error
    }
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    hosts {
      192.168.1.201 idhub.sath.com
      fallthrough
    }
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

Restarting CoreDNS​

After updating the Corefile, restart the CoreDNS pod to apply the changes:

kubectl delete pod -n kube-system -l k8s-app=kube-dns

Verify that the CoreDNS pod has restarted successfully:

kubectl get pods -n kube-system | grep coredns

Mapping Local IP to DNS​

Map the server's local IP to your DNS for proper resolution:

  • Linux/macOS:
    Add the following entry to /etc/hosts:

    echo "192.168.1.201 idhub.sath.com" | sudo tee -a /etc/hosts

  • Windows:
    Edit C:\Windows\System32\drivers\etc\hosts with administrative privileges and add:

    192.168.1.201 idhub.sath.com

Verifying the Configuration​

Validate DNS resolution by running:

nslookup idhub.sath.com

The output should resolve to 192.168.1.201.

Configure Ingress IP to DNS Provider​

tip

You can setup your FQDN with your DNS provider. For instance, you can sign up for a Cloudfare Trial Account to follow along.

Retrieve the Ingress NGINX External IP​

To get the external IP of the NGINX ingress controller, run the following command:

kubectl get service -n <IDHUB_INSTANCE> -l app.kubernetes.io/name=ingress-nginx
info

<IDHUB_INSTANCE> is the namespace where IDHub is installed.

This will output something like:

NAME                                   TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
stage-nginx-ingress-nginx-controller   LoadBalancer   10.96.25.146   203.0.113.100   80:30935/TCP,443:31880/TCP   60d

The EXTERNAL-IP column shows the public IP (203.0.113.100 in this example) that should be mapped to your domain.

Update Cloudflare DNS Records​

  1. Log in to your Cloudflare account.
  2. Navigate to DNS settings for your domain.
  3. Click Add Record and set:
    • Type: A
    • Name: your-subdomain
    • IPv4 Address: 203.0.113.100 (replace with your actual ingress IP)
    • TTL: Auto
    • Proxy status: Proxied
  4. Save the record.

Verify the DNS Mapping​

After updating the DNS records, verify that your domain correctly resolves to the ingress IP by opening your web browser and navigating to:

https://your-subdomain.example.com

If everything is set up correctly, your application should load as expected.

Load Balancing and Failover​

FQDNs play a vital role in load balancing and failover, ensuring that requests are distributed across multiple servers or rerouted in case of server failure.

  • Load Balancing: Configures traffic distribution across multiple servers, helping reduce load on any single server and improve site responsiveness.
  • Failover: If one server becomes unavailable, requests are redirected to a secondary server. This improves uptime and reliability.
info

For Cloudfare, please refer to Cloudfare Load Balancer for detailed instructions.

Troubleshooting and Best Practices​

  1. DNS Propagation Delays: DNS changes may take up to 24 hours to propagate across global DNS servers. Use a tool like DNS Checker to verify propagation.
  2. Incorrect IP Mapping: Verify that the IP address in your A record is correct.