Container Service for Kubernetes:Configurer CoreDNS non géré

Cette rubrique prend pour exemple un pod utilisant CoreDNS pour la résolution DNS. La stratégie DNS du pod spécifie dnsPolicy: ClusterFirst. Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: default
spec:
  containers:
  - image: alpine
    command:
      - sleep
      - "10000"
    imagePullPolicy: Always
    name: alpine
  dnsPolicy: ClusterFirst

Dans le namespace kube-system, vous trouverez un objet ConfigMap CoreDNS. CoreDNS configure et active les plug-ins spécifiés dans ce ConfigMap. Les ConfigMaps varient légèrement selon les versions de CoreDNS. Lisez la documentation officielle de CoreDNS avant de modifier les configurations. Le bloc de code suivant affiche le contenu du fichier de configuration par défaut utilisé par CoreDNS 1.6.2 :

  Corefile: |
    .:53 {
        errors
        log
        health {
           lameduck 15s
        }
        ready
        kubernetes {{.ClusterDomain}} in-addr.arpa ip6.arpa {
          pods verified
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf {
              prefer_udp
        }
        cache 30
        loop
        reload
        loadbalance
    }

Vous pouvez configurer des fonctionnalités étendues basées sur CoreDNS dans les scénarios suivants :

• Scénario 1 : Activer la collecte des journaux

  Pour collecter les journaux de tous les enregistrements de résolution DNS effectués par CoreDNS, activez le plug-in log en ajoutant le paramètre log au fichier Corefile. Exemple :

    Corefile: |
      .:53 {
          errors
          log
          health {
             lameduck 15s
          }
          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 {
                prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

• Scénario 2 : Personnaliser les serveurs DNS pour des noms de domaine spécifiques

  Si les noms de domaine se terminant par example.com doivent être résolus par un serveur DNS défini par l'utilisateur (par exemple, le serveur DNS 10.10.0.10), ajoutez une configuration de résolution personnalisée pour ces domaines. Exemple :

  example.com:53 {
    errors
    cache 30
    forward . 10.10.0.10 {
    prefer_udp
    }
  }

  Le bloc de code suivant présente la configuration complète du fichier Corefile :

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          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 {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }
      example.com:53 {
          errors
          cache 30
          forward . 10.10.0.10 {
          prefer_udp
          }
      }

• Scénario 3 : Personnaliser les serveurs DNS pour les noms de domaine externes

  Si les noms de domaine devant être résolus par des serveurs DNS définis par l'utilisateur ne partagent pas le même suffixe, utilisez ces serveurs pour résoudre tous les noms de domaine externes. Dans ce scénario, transmettez aux serveurs DNS d'Alibaba Cloud les requêtes pour les noms de domaine que les serveurs définis par l'utilisateur ne peuvent pas résoudre. Ne modifiez pas les fichiers /etc/resolv.conf sur les instances Elastic Compute Service (ECS) du cluster ACK. Par exemple, si les adresses IP des serveurs DNS définis par l'utilisateur sont 10.10.0.10 et 10.10.0.20, modifiez le paramètre forward. Exemple :

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . 10.10.0.10 10.10.0.20 {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

• Scénario 4 : Personnaliser les hôtes pour des noms de domaine spécifiques

  Configurez le plug-in hosts si vous souhaitez personnaliser les hôtes pour certains noms de domaine, par exemple pour pointer www.example.com vers 127.0.0.1. Exemple :

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          
          hosts {
            127.0.0.1 www.example.com
            fallthrough
          }
        
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

  Important

  Vous devez spécifier fallthrough. Sinon, la résolution des noms de domaine autres que celui spécifié peut échouer.

• Scénario 5 : Activer l'accès externe aux services d'un cluster ACK

  Pour permettre à un processus s'exécutant sur une instance ECS d'un cluster ACK d'accéder aux services du cluster, spécifiez l'adresse IP du cluster de kube-dns comme valeur du paramètre nameserver dans le fichier /etc/resolv.conf de l'instance ECS. Ne modifiez pas les autres paramètres du fichier /etc/resolv.conf.

  Sur le réseau interne, vous pouvez utiliser une instance Server Load Balancer (SLB) interne pour autoriser l'accès interne aux services du cluster ACK. Connectez-vous ensuite à la console Alibaba Cloud DNS PrivateZone et ajoutez un enregistrement A pointant vers l'adresse IP privée de l'instance SLB.

• Scénario 6 : Utiliser un nom de domaine pour autoriser l'accès à votre service dans un cluster ACK ou activer la résolution CNAME pour un cluster ACK

  Vous pouvez utiliser foo.example.com pour autoriser tout accès à votre service dans un cluster ACK depuis Internet, les réseaux internes et l'intérieur du cluster ACK. La section suivante décrit comment activer cette fonctionnalité :

  • Votre service foo.default.svc.cluster.local est exposé à l'accès externe via une instance SLB orientée Internet. Le nom de domaine foo.example.com est résolu vers l'adresse IP de l'instance SLB orientée Internet.

  • Votre service foo.default.svc.cluster.local est exposé à l'accès interne via une instance SLB interne. Connectez-vous à la console Alibaba Cloud DNS PrivateZone pour faire pointer foo.example.com vers l'adresse IP de l'instance SLB interne dans le VPC (Virtual Private Cloud) où le cluster ACK est déployé. Pour plus d'informations sur la procédure, consultez la rubrique Scénario 4 : Personnaliser les hôtes pour des noms de domaine spécifiques.

  • À l'intérieur du cluster ACK, vous pouvez utiliser le plug-in rewrite pour ajouter un enregistrement CNAME afin de faire pointer foo.example.com vers foo.default.svc.cluster.local. Exemple :

      Corefile: |
        .:53 {
            errors
            health {
               lameduck 15s
            }
            ready
            
            rewrite stop {
              name exact foo.example.com foo.default.svc.cluster.local
              answer name foo.default.svc.cluster.local foo.example.com 
            }
    
            kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
              ttl 30
            }
            prometheus :9153
            forward . /etc/resolv.conf {
              prefer_udp
            }
            cache 30
            loop
            reload
            loadbalance
        }

• Scénario 7 : Configurer CoreDNS pour ne pas renvoyer les adresses IPv6 résolues à partir des enregistrements AAAA

  Si vos pods d'application n'ont pas besoin des résultats de résolution basés sur les enregistrements AAAA, configurez CoreDNS pour intercepter ces résultats et renvoyer un code NODATA. Cela minimise le transfert de données. Exemple :

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          # Add the following line to enable the template plug-in. Do not modify other settings. 
          template IN AAAA .
      
      }

• Scénario 8 : Activer la fonctionnalité MCS d'ACK One

  Remarque

  CoreDNS 1.9.3 ou version ultérieure prend en charge la fonctionnalité Multi-Cluster Services (MCS) de Distributed Cloud Container Platform for Kubernetes (ACK One). Pour activer cette fonctionnalité, assurez-vous d'avoir mis à jour CoreDNS vers la version 1.9.3 ou ultérieure. Pour plus d'informations, consultez les rubriques Configurer ACK pour mettre à jour automatiquement CoreDNS et Mettre à jour manuellement CoreDNS.

  1. Exécutez la commande suivante pour mettre à jour le ConfigMap de CoreDNS :

     kubectl edit configmap/coredns -n kube-system

  2. Ajoutez une ligne au-dessus de la ligne commençant par kubernetes et spécifiez multicluster clusterset.local dans cette nouvelle ligne pour activer le plug-in multicluster, qui permet d'activer la fonctionnalité MCS d'ACK One. Cette configuration définit les suffixes des noms de domaine des services multi-clusters sur clusterset.local.

     Corefile: |
         .:53 {
             # Irrelevant lines are not shown. 
             # Add the following line. 
             multicluster clusterset.local
             kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               fallthrough in-addr.arpa ip6.arpa
               ttl 30
             }
             # Irrelevant lines are not shown. 
         }

  3. Appuyez sur Esc, saisissez :wq!, puis appuyez sur Enter pour enregistrer le fichier et quitter le mode édition.

• Scénario 9 : Spécifier différents serveurs DNS amont pour les domaines externes

  Prérequis

  CoreDNS version 1.11.3 ou ultérieure.

  Configuration

  Définissez plusieurs directives forward dans un seul bloc serveur. Chaque directive peut spécifier un serveur DNS amont différent pour un domaine spécifique. Pour la liste complète des paramètres, consultez la documentation officielle du plug-in forward.

  Exemple

  Corefile: |
      .:53 {
          # ... other configurations ...
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          # Forward queries for foo.com to DNS server 10.20.0.1
          forward foo.com 10.20.0.1
          # Forward queries for bar.com to DNS server 10.30.0.1
          forward bar.com 10.30.0.1
          # Forward all other queries to the DNS servers specified in the node's /etc/resolv.conf
          forward . /etc/resolv.conf
          # ... other configurations ...
      }