Container Compute Service:Configurer un CoreDNS non géré

Cas d'usage

L'exemple suivant présente un pod dont la politique DNS inclut dnsPolicy: ClusterFirst :

apiVersion: v1
kind: Pod
metadata:
  name: alinux3
  namespace: default
spec:
  containers:
  - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3
    command:
      - sleep
      - "10000"
    imagePullPolicy: Always
    name: alinux3
  dnsPolicy: ClusterFirst

Pour configurer le paramètre dnsPolicy selon différents scénarios, consultez Configurer la résolution DNS.

Configurations par défaut de CoreDNS

La ConfigMap CoreDNS du namespace kube-system définit les plug-ins activés. Les ConfigMaps varient légèrement selon les versions de CoreDNS. Avant toute modification, consultez la documentation officielle de CoreDNS. L'exemple ci-dessous illustre la configuration par défaut de 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
    }

Configurer des fonctionnalités étendues avec CoreDNS

Les scénarios suivants illustrent des personnalisations courantes de CoreDNS :

• Scénario 1 : Activer Simple Log Service

  Pour journaliser toutes les résolutions DNS, ajoutez le paramètre log au 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 : Définir des serveurs DNS personnalisés pour des noms de domaine spécifiques

  Pour résoudre les noms de domaine portant un suffixe particulier (comme example.com) via un serveur DNS dédié (tel que 10.10.0.10), insérez un bloc de résolution personnalisé. Exemple :

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

  Configuration complète :

    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 : Spécifier des serveurs DNS pour les noms de domaine externes

  Si les noms de domaine nécessitant une résolution personnalisée ne partagent aucun suffixe commun, transférez toutes les requêtes externes vers vos serveurs DNS dédiés.

  Par exemple, pour diriger les requêtes vers les serveurs DNS 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 : Associer des hôtes statiques à des noms de domaine donnés

  Le plug-in hosts permet de mapper des noms de domaine à des adresses IP statiques, à l'image du fichier /etc/hosts. Par exemple, pour rediriger www.example.com vers 127.0.0.1 :

    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

  Spécifiez impérativement le paramètre fallthrough dans la section hosts. Sinon, la résolution pourrait échouer pour les noms de domaine non listés.

• Scénario 5 : Autoriser 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, définissez le paramètre nameserver du fichier /etc/resolv.conf de cette instance ECS sur l'adresse IP de cluster de kube-dns. Ne modifiez aucun autre paramètre du fichier /etc/resolv.conf.

  Pour un accès via le réseau interne, exposez les services du cluster ACS à l'aide d'une instance Classic Load Balancer (CLB) orientée vers l'interne. Connectez-vous ensuite à la console Alibaba Cloud DNS PrivateZone et créez un enregistrement A pointant vers l'adresse IP privée de l'instance CLB.

• Scénario 6 : Utiliser un nom de domaine pour accéder à un service dans un cluster ACK ou activer la résolution CNAME pour un cluster ACK

  Utilisez foo.example.com pour exposer votre service d'un cluster ACK sur Internet, sur les réseaux internes et au sein même du cluster. Procédez comme suit :

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

  • Votre service foo.default.svc.cluster.local est accessible en interne grâce à une instance CLB orientée vers l'interne. Connectez-vous à la console Alibaba Cloud DNS PrivateZone afin de faire pointer foo.example.com vers l'adresse IP privée de l'instance CLB située dans le Virtual Private Cloud (VPC) hébergeant le cluster ACK. Consultez Configurer CoreDNS non géré.

  • Au sein du cluster ACK, utilisez le plug-in rewrite pour ajouter un enregistrement CNAME dirigeant 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 : Empêcher CoreDNS de retourner des adresses IPv6 issues des enregistrements AAAA

  Si vos pods n'ont pas besoin de résolution IPv6 (enregistrements AAAA), configurez CoreDNS pour intercepter ces requêtes et renvoyer NODATA, réduisant ainsi le trafic réseau superflu. 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 .
      }