External DNS 🌐

Overview

ExternalDNS is a Kubernetes add-on that dynamically configures DNS records for Kubernetes resources like Services, Ingresses, and Istio gateways. Unlike KubeDNS, External-DNS is not a DNS server but instead integrates with DNS providers (e.g., AWS Route 53, Google Cloud DNS) to manage DNS records. The integration provides visibility into External-DNS sync status and its managed records availability, allowing you to track, manage, and debug external-dns issues across multiple clusters.

Pre-requisites

• Komodor agent version 0.2.117 and above, chart version 2.7.1 and above
• external-dns is labeled with either one of:
  • app.kubernetes.io/name (default label)
  • komodor.io/detect

Key capabilities

• Cross-cluster support: Automatically detect External-DNS across multiple clusters from a single interface.
• Comprehensive filtering: Filter External-DNS by cluster, namespace, DNS provider, and status.
• Automated alerts: Receive alerts in the form of reliability risks for out-of-sync external-dns'.
• Detailed managed records status: View External-DNS managed records, their sync status and associated workloads.
• Using Komodor AI for root cause analysis: Leverage Komodor AI (KlaudiaAI) to help debug issues by analyzing logs and related resources.

Use Cases

1. Monitoring External DNS health: Use the External-DNS dashboard to gain insight into the health of DNS configurations across your clusters.
2. Debugging external DNS sync failures: Leverage Komodor’s root cause analysis (RCA) and resource views to identify and resolve DNS sync issues, such as API rate limits, authentication errors, or incorrect record configurations.
3. Proactive alerts: Get Reliability Risks for External-DNS sync delays or failures based on custom thresholds, to avoid downtime or misrouted traffic.

How it works

Under Kubernetes Add-ons → External DNS in the left-side navigation bar, Komodor provides a unified dashboard to view all external-dns across your clusters. The dashboard includes:

• All External-DNS instances in one single place, enriched with their status, last synced time, number of managed records and DNS provider name
  • To identify external-dns services, Komodor fetches them based on either one of the 2 labels:
    • app.kubernetes.io/name - the default label that's supposed to contain external-dns
    • komodor.io/detect
  • If you have external-dns across your clusters, but you don't see them in the external-dns Add-on view, make sure they are properly labeled with one of the above. 
• Quick filters to narrow down the view based on the external-dns you are interested in
  • External-DNS Add-On also works with Workspaces, to focus even more on the relevant areas in the environment.
• Ability to dive into a specific External-DNS and get additional information on the status, settings and managed records. 
  • Komodor agent resolves the target host from within the cluster (using nslookup). If a managed record is not resolved, this means it was not available through the cluster.

External DNS Details

Clicking on an External-DNS opens a detailed view with the following information, to simplify the debugging and resolution of External-DNS:

• Status: Details on the External-DNS status, last sync attempt and last successful sync attempt. 
• Managed records table: A table listing DNS records with details like associated workloads and sources.
• Associated Workload: Details on the Kubernetes resources that are related to the managed record.
• Komodor AI-powered root cause analysis: Automatic detection of External-DNS issues and suggestions for fixing them, based on related controller logs.
• Relevant Logs: View detailed External-DNS controller-logs for each instance, including error messages related to DNS record updates, API failures, or rate-limiting issues.

Reliability Risks

External DNS that are out of sync will automatically generate a reliability risk in Komodor. These risks are created within the “Add-ons risks” impact group, and are prioritized by severity based on the out-of-sync duration (during the last 7 days):

• High: The time the managed record is out of sync is between 3-5 minutes.
• Medium: The time the managed record is out of sync is between 5-7 minutes.
• Low: The time the managed record is out of sync for more than 7 minutes.

Those thresholds are configurable through our Reliability Policies. 

Each risk includes:

• Which services are affected, and which records were out of sync
• Possible root cause analyzed by Klaudia AI
• Actionable insights to resolve the issue