Container Service for Kubernetes:Configure CoreDNS não gerenciado

Este tópico usa como exemplo um pod que utiliza o CoreDNS para resolução de DNS. A política de DNS do pod define dnsPolicy: ClusterFirst. Exemplo:

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

O namespace kube-system contém um ConfigMap do CoreDNS. O CoreDNS configura e ativa os plug-ins especificados nesse ConfigMap. Os ConfigMaps variam ligeiramente entre as versões do CoreDNS. Leia a documentação oficial do CoreDNS antes de modificar as configurações. O bloco de código a seguir exibe o conteúdo do arquivo de configuração padrão do 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
    }

Configure recursos estendidos baseados no CoreDNS nos seguintes cenários:

• Cenário 1: Ativar coleta de logs

  Para coletar logs de todos os registros de resolução de DNS do CoreDNS, ative o plug-in de log adicionando o parâmetro log ao Corefile. Exemplo:

    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
      }

• Cenário 2: Personalizar servidores DNS para nomes de domínio específicos

  Se nomes de domínio com sufixo example.com precisarem ser resolvidos por um servidor DNS personalizado (por exemplo, servidor DNS 10.10.0.10), adicione uma configuração de resolução personalizada para esses domínios. Exemplo:

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

  O bloco de código a seguir mostra a configuração completa do 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
          }
      }

• Cenário 3: Personalizar servidores DNS para nomes de domínio externos

  Se os nomes de domínio que precisam ser resolvidos por servidores DNS personalizados não compartilharem o mesmo sufixo, utilize servidores DNS personalizados para resolver todos os nomes de domínio externos. Nesse cenário, encaminhe os nomes de domínio que os servidores DNS personalizados não puderem resolver para o Alibaba Cloud DNS. Não modifique os arquivos /etc/resolv.conf nas instâncias do Elastic Compute Service (ECS) do cluster ACK. Por exemplo, se os endereços IP dos servidores DNS personalizados forem 10.10.0.10 e 10.10.0.20, modifique o parâmetro forward. Exemplo:

    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
      }

• Cenário 4: Personalizar hosts para nomes de domínio específicos

  Configure o plug-in hosts para personalizar entradas de host para nomes de domínio específicos. Por exemplo, pode ser necessário apontar www.example.com para 127.0.0.1. Exemplo:

    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
      }

  Importante

  Especifique fallthrough. Caso contrário, a resolução de nomes de domínio diferentes do especificado poderá falhar.

• Cenário 5: Permitir acesso externo a serviços em um cluster ACK

  Para permitir que um processo em uma instância ECS dentro de um cluster ACK acesse serviços no cluster, defina o endereço IP do cluster do kube-dns como valor do parâmetro nameserver no arquivo /etc/resolv.conf da instância ECS. Não altere outras configurações no arquivo /etc/resolv.conf.

  Em uma rede interna, utilize uma instância de Server Load Balancer (SLB) voltada para a rede interna para permitir acesso interno aos serviços do cluster ACK. Em seguida, faça login no console do Alibaba Cloud DNS PrivateZone e adicione um registro A que aponte para o endereço IP privado da instância SLB.

• Cenário 6: Usar um nome de domínio para permitir acesso ao seu serviço em um cluster ACK ou ativar resolução CNAME para um cluster ACK

  Use foo.example.com para permitir todo o acesso ao seu serviço em um cluster ACK a partir da Internet, de redes internas e de dentro do próprio cluster ACK. A seção a seguir descreve como ativar esse recurso:

  • Seu serviço foo.default.svc.cluster.local está exposto a acesso externo por meio de uma instância SLB voltada para a Internet. O nome de domínio foo.example.com resolve para o endereço IP da instância SLB voltada para a Internet.

  • Seu serviço foo.default.svc.cluster.local está exposto a acesso interno por meio de uma instância SLB voltada para a rede interna. Faça login no console do Alibaba Cloud DNS PrivateZone para apontar foo.example.com para o endereço IP da instância SLB voltada para a rede interna na Virtual Private Cloud (VPC) onde o cluster ACK está implantado. Para mais informações sobre o procedimento, consulte Cenário 4: Personalizar hosts para nomes de domínio específicos.

  • Dentro do cluster ACK, use o plug-in rewrite para adicionar um registro CNAME que aponte foo.example.com para foo.default.svc.cluster.local. Exemplo:

      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
        }

• Cenário 7: Configure o CoreDNS para não retornar endereços IPv6 resolvidos com base em registros AAAA

  Se seus pods de aplicação não precisarem de resultados de resolução baseados em registros AAAA, configure o CoreDNS para interceptar esses resultados e retornar um código NODATA. Isso minimiza a transferência de dados. Exemplo:

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

• Cenário 8: Ativar o recurso MCS do ACK One

  Nota

  O CoreDNS 1.9.3 ou posterior oferece suporte ao recurso Multi-cluster Services (MCS) da Distributed Cloud Container Platform for Kubernetes (ACK One). Para ativar esse recurso, certifique-se de ter atualizado o CoreDNS para a versão 1.9.3 ou superior. Para mais informações, consulte Configure o ACK para atualizar automaticamente o CoreDNS e Atualize manualmente o CoreDNS.

  1. Execute o comando a seguir para atualizar o ConfigMap do CoreDNS:

     kubectl edit configmap/coredns -n kube-system

  2. Adicione uma linha acima da linha que começa com kubernetes e especifique multicluster clusterset.local na nova linha para ativar o plug-in multicluster, usado para habilitar o recurso MCS do ACK One. Essa configuração define os sufixos dos nomes de domínio dos Multi-cluster Services como 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. Pressione Esc, insira :wq! e pressione Enter para salvar o arquivo e sair do modo de edição.

• Cenário 9: Especificar diferentes servidores DNS upstream para domínios externos

  Pré-requisitos

  CoreDNS versão 1.11.3 ou posterior.

  Configuração

  Defina múltiplas diretivas forward dentro de um único bloco de servidor. Cada diretiva pode especificar um servidor DNS upstream diferente para um domínio específico. Para obter a lista completa de parâmetros, consulte a documentação oficial do plug-in forward.

  Exemplo

  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 ...
      }