CoreDNS : le DNS dans Kubernetes

Dans les architectures Kubernetes, la communication entre services repose sur un mécanisme souvent invisible mais absolument critique : la résolution de noms. Comment un Pod peut-il contacter un autre service simplement en utilisant son nom ? Comment les applications découvrent-elles dynamiquement les endpoints des bases de données ou des API internes ? Ces questions fondamentales trouvent leur réponse dans le système DNS du cluster, et plus précisément dans CoreDNS.

Véritable colonne vertébrale de la découverte de services dans Kubernetes, CoreDNS est le serveur DNS par défaut des clusters Kubernetes depuis la version 1.13. Ce projet open source, gradué au sein de la Cloud Native Computing Foundation (CNCF), assure la résolution des noms de services et permet aux applications de communiquer entre elles sans avoir à connaître les adresses IP, par nature éphémères dans un environnement conteneurisé. Flexible, extensible et performant, CoreDNS s'est imposé comme un composant indispensable que tout ingénieur DevOps ou administrateur Kubernetes se doit de maîtriser.

Pourquoi un DNS est indispensable dans Kubernetes

Dans un cluster Kubernetes, les Pods sont par nature éphémères. Ils peuvent être créés, détruits et recréés à tout moment, chaque fois avec une nouvelle adresse IP. Cette volatilité rend impossible l'utilisation d'adresses IP statiques pour la communication inter-services. C'est précisément là qu'intervient le DNS du cluster.

CoreDNS résout ce problème en fournissant une abstraction stable : les services Kubernetes sont accessibles via des noms DNS prévisibles, indépendamment des adresses IP sous-jacentes. Lorsqu'un Pod souhaite contacter le service backend, il effectue simplement une requête DNS vers ce nom, et CoreDNS lui retourne l'adresse IP du service (ClusterIP) ou directement les IPs des Pods associés.

Cette approche offre plusieurs avantages fondamentaux :

• Découplage : les applications n'ont pas besoin de connaître l'infrastructure réseau sous-jacente ni de gérer la découverte de services manuellement.
• Résilience : si un Pod est recréé avec une nouvelle IP, le nom DNS reste identique et la résolution est automatiquement mise à jour.
• Simplicité de configuration : les développeurs peuvent référencer les services par leur nom dans les fichiers de configuration, sans se soucier des détails d'adressage.
• Support des namespaces : la hiérarchie DNS reflète l'organisation logique du cluster, permettant une isolation et une organisation claires.

Concrètement, lorsqu'un Pod démarre dans Kubernetes, son fichier /etc/resolv.conf est automatiquement configuré pour pointer vers CoreDNS. Toute requête DNS effectuée par l'application est ainsi interceptée et traitée par le serveur DNS du cluster, qui connaît en temps réel l'état de tous les services et endpoints.

Fonctionnement et résolution de noms

CoreDNS fonctionne comme un serveur DNS classique, mais avec une connaissance native de l'API Kubernetes. Il surveille en permanence les ressources du cluster (Services, Endpoints, Pods) et maintient une base de données DNS à jour.

Structure des noms DNS dans Kubernetes

La convention de nommage DNS dans Kubernetes suit une hiérarchie bien définie. Pour un service, le nom complet (FQDN) prend la forme suivante :

<nom-service>.<namespace>.svc.cluster.local

Par exemple, un service postgres déployé dans le namespace database sera accessible via postgres.database.svc.cluster.local. Cette structure permet plusieurs niveaux de résolution :

• Depuis le même namespace : un simple postgres suffit, CoreDNS complète automatiquement avec le namespace du Pod appelant.
• Depuis un autre namespace : il faut spécifier postgres.database ou le FQDN complet.
• Pour les Pods : un format similaire existe avec l'IP du Pod encodée dans le nom : 10-244-1-5.default.pod.cluster.local.

CoreDNS gère également les enregistrements SRV, particulièrement utiles pour les services headless où l'on souhaite découvrir tous les Pods individuellement plutôt que passer par une ClusterIP unique :

# Requête SRV pour découvrir les ports d'un service
dig SRV _http._tcp.mon-service.default.svc.cluster.local

Architecture et intégration avec Kubernetes

CoreDNS est déployé comme un Deployment dans le namespace kube-system, généralement avec plusieurs réplicas pour la haute disponibilité. Un Service de type ClusterIP expose CoreDNS sur une adresse IP fixe (souvent 10.96.0.10), qui est configurée dans tous les Pods via le kubelet.

# Exemple simplifié du déploiement CoreDNS
apiVersion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system
spec:
  replicas: 2
  selector:
    matchLabels:
      k8s-app: kube-dns
  template:
    spec:
      containers:
        - name: coredns
          image: coredns/coredns:1.11.1
          ports:
            - containerPort: 53
              protocol: UDP
            - containerPort: 53
              protocol: TCP

Le plugin kubernetes de CoreDNS se connecte à l'API Server pour surveiller les changements de services et endpoints. Dès qu'un nouveau service est créé ou qu'un Pod rejoint un endpoint, CoreDNS met à jour ses enregistrements DNS en quasi temps réel.

À lire : découvrez notre formation DevOps Engineer

Configuration et personnalisation

L'une des forces de CoreDNS réside dans son architecture modulaire basée sur des plugins. La configuration se fait via un fichier appelé Corefile, stocké dans une ConfigMap Kubernetes. Cette approche permet d'adapter finement le comportement du DNS selon les besoins de l'organisation.

Le Corefile : cœur de la configuration

Le Corefile définit les zones DNS gérées et les plugins à appliquer pour chacune. Voici un exemple de configuration par défaut dans Kubernetes :

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

Chaque ligne représente un plugin avec sa configuration. Les plugins les plus importants sont :

• kubernetes : active la résolution des services et Pods Kubernetes.
• forward : transfère les requêtes non résolues localement vers des serveurs DNS externes.
• cache : met en cache les réponses pour améliorer les performances.
• prometheus : expose des métriques au format Prometheus pour le monitoring.
• health et ready : fournissent des endpoints de health check.

Personnalisation pour des cas d'usage avancés

CoreDNS peut être étendu pour répondre à des besoins spécifiques, notamment la résolution de domaines internes hors du cluster. Un cas fréquent est l'intégration avec l'infrastructure DNS existante de l'entreprise.

Résolution de domaines internes : pour permettre aux Pods de résoudre des noms appartenant au réseau d'entreprise (par exemple *.corp.example.com), on peut ajouter une règle de forwarding spécifique :

corp.example.com:53 {
    errors
    cache 30
    forward . 10.0.0.53 10.0.0.54
}

Cette configuration transfère toutes les requêtes pour corp.example.com vers les serveurs DNS internes de l'entreprise, permettant aux applications Kubernetes d'accéder aux ressources legacy.

Réécriture de noms : le plugin rewrite permet de modifier les requêtes DNS à la volée, utile pour des migrations ou des alias :

rewrite name ancien-service.default.svc.cluster.local nouveau-service.default.svc.cluster.local

Zones personnalisées : pour exposer des enregistrements DNS statiques au sein du cluster, le plugin file ou hosts permet de définir des zones supplémentaires :

example.local:53 {
    hosts {
        192.168.1.10 api.example.local
        192.168.1.11 db.example.local
        fallthrough
    }
}

Pour appliquer une modification de configuration, il suffit de mettre à jour la ConfigMap coredns dans le namespace kube-system. CoreDNS détecte automatiquement les changements grâce au plugin reload et recharge sa configuration sans interruption de service.

# Édition de la ConfigMap CoreDNS
kubectl edit configmap coredns -n kube-system

À découvrir : notre formation DevOps Engineer

Conclusion

CoreDNS s'est imposé comme le standard de facto pour la résolution DNS dans Kubernetes, offrant une solution robuste, performante et hautement configurable. En assurant la traduction transparente entre les noms de services et les adresses IP, il permet aux applications de communiquer de manière fiable dans un environnement où l'infrastructure réseau est par nature dynamique.

Au-delà de son rôle fondamental de résolution des services Kubernetes, CoreDNS offre une flexibilité remarquable grâce à son architecture modulaire. Que ce soit pour intégrer des DNS d'entreprise existants, exposer des zones personnalisées ou optimiser les performances via le cache, les possibilités de personnalisation répondent aux besoins des architectures les plus complexes. Pour les équipes DevOps, comprendre et maîtriser CoreDNS constitue un investissement essentiel : c'est souvent le premier composant à investiguer lorsque des problèmes de communication inter-services surviennent, et sa bonne configuration peut significativement améliorer la fiabilité et les performances du cluster.