Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.

Central de ajuda/ Cloud Container Engine/ Guia de usuário/ Complementos/ CoreDNS

Atualizado em 2024-11-28 GMT+08:00

Ver PDF

CoreDNS

Introdução

CoreDNS é um servidor DNS que fornece resolução de nome de domínio para clusters do Kubernetes por meio de um complemento de cadeia.

O CoreDNS é um software de código aberto e faz parte da CNCF. Ele fornece um meio para os serviços em nuvem descobrirem uns aos outros em implementações nativas da nuvem. Cada um dos plug-ins encadeados pelo CoreDNS fornece uma função de DNS específica. Você pode integrar o CoreDNS apenas com os plug-ins necessários para torná-lo rápido, eficiente e flexível. Quando usado em um cluster do Kubernetes, o CoreDNS pode descobrir automaticamente serviços no cluster e fornecer resolução de nome de domínio para esses serviços. Ao trabalhar com o servidor DNS, o CoreDNS pode resolver nomes de domínio externos para cargas de trabalho em um cluster.

Este extra é instalado por predefinição durante a criação do cluster.

O Kubernetes apoia o CoreDNS como o DNS padrão oficial para todos os clusters daqui para frente.

Site oficial do CoreDNS: https://coredns.io/

Comunidade de código aberto: https://github.com/coredns/coredns

Para mais detalhes, consulte DNS.

Restrições

Para executar o CoreDNS corretamente ou fazer upgrade do CoreDNS em um cluster, certifique-se de que o número de nós disponíveis no cluster seja maior ou igual ao número de instâncias do CoreDNS e que todas as instâncias do CoreDNS estejam em execução. Caso contrário, o complemento irá funcionar mal ou a atualização irá falhar.

Instalar o complemento

Este complemento foi instalado por padrão. Se for desinstalado devido a alguns motivos, você pode reinstalá-lo executando as seguintes etapas:

Efetue logon no console do CCE e clique no nome do cluster para acessar o console do cluster. Escolha Add-ons no painel de navegação, localize CoreDNS à direita e clique em Install.

Na página Install Add-on, configure as especificações.

**Tabela 1** Parâmetros de CoreDNS
Parâmetro	Descrição
Pods	Número de pods para o complemento. A alta disponibilidade não é possível com um único pod de complemento. Se ocorrer um erro no nó em que o pod do complemento é executado, o complemento falhará.
Containers	As consultas por segundo (QPS) do complemento CoreDNS estão positivamente correlacionadas com o consumo de CPU. Se o número de nós ou contêineres no cluster aumentar, os pods do CoreDNS suportarão cargas de trabalho mais pesadas. Ajuste o número dos pods do CoreDNS e suas cotas de CPU e memória com base na escala de cluster. Para mais detalhes, consulte Tabela 2.

**Tabela 2** Cotas recomendadas do CoreDNS
Nós	QPS recomendado	Pods	VCPUs solicitadas	Limite da vCPU	Memória solicitada	Limite de memória
50	2500	2	500m	500m	512 MiB	512 MiB
200	5000	2	1000m	1000m	1024 MiB	1024 MiB
1000	10000	2	2000m	2000m	2048 MiB	2048 MiB
2000	20000	4	2000m	2000m	2048 MiB	2048 MiB

Configure os parâmetros do complemento.

**Tabela 3** Parâmetros do complemento CoreDNS
Parâmetro	Descrição
Stub Domain	Um servidor de nomes de domínio para um nome de domínio personalizado. O formato é um par chave-valor. A chave é um sufixo de nome de domínio e o valor é um ou mais endereços IP DNS, por exemplo, acme.local -- 1.2.3.4,6.7.8.9. Para mais detalhes, consulte Configurar o domínio de stub para CoreDNS.
Advance Config	parameterSyncStrategy: indica se a verificação de consistência deve ser configurada quando o extra é atualizado. ensureConsistent: indica que a verificação de consistência da configuração está ativada. Se a configuração registrada no cluster for inconsistente com a configuração real, o complemento não poderá ser atualizado. force: indica que a verificação de consistência da configuração é ignorada durante uma atualização. Nesse caso, você deve garantir que a configuração efetiva atual seja a mesma da configuração original. Depois que o complemento é atualizado, restaure o valor de parameterSyncStrategy para ensureConsistent para habilitar a verificação de consistência de configuração novamente. inherit: indica que as configurações personalizadas são herdadas automaticamente durante uma atualização. Depois que o complemento é atualizado, restaure o valor de parameterSyncStrategy para ensureConsistent para habilitar a verificação de consistência de configuração novamente. stub_domains: subdomínios, que permitem configurar um servidor de nomes de domínio para um nome de domínio personalizado. Um subdomínio está no formato de um par chave-valor, onde a chave é o sufixo de um nome de domínio do DNS e o valor é um ou mais endereços IP do DNS. upstream_nameservers: endereço IP do servidor DNS upstream. servers: servidores de nomes, que estão disponíveis no CoreDNS v1.23.1 e versões posteriores. Você pode personalizar servidores de nomes. Para obter detalhes, consulte dns-custom-nameservers. plugins indica a configuração de cada componente no CoreDNS. Mantenha as configurações padrão normalmente para evitar que o CoreDNS fique indisponível devido a erros de configuração. Cada componente do plug-in contém name, parameters (opcional) e configBlock (opcional). O formato do Corefile gerado é o seguinte: $name $parameters { $configBlock } Tabela 4 descreve plugins comuns. Para detalhes, veja Plug-ins. Exemplo: { "servers": [ { "plugins": [ { "name": "bind", "parameters": "{$POD_IP}" }, { "name": "cache", "parameters": 30 }, { "name": "errors" }, { "name": "health", "parameters": "{$POD_IP}:8080" }, { "name": "ready", "{$POD_IP}:8081" }, { "configBlock": "pods insecure\nfallthrough in-addr.arpa ip6.arpa", "name": "kubernetes", "parameters": "cluster.local in-addr.arpa ip6.arpa" }, { "name": "loadbalance", "parameters": "round_robin" }, { "name": "prometheus", "parameters": "{$POD_IP}:9153" }, { "configBlock": "policy random", "name": "forward", "parameters": ". /etc/resolv.conf" }, { "name": "reload" } ], "port": 5353, "zones": [ { "zone": "." } ] } ], "stub_domains": { "acme.local": [ "1.2.3.4", "6.7.8.9" ] }, "upstream_nameservers": ["8.8.8.8", "8.8.4.4"] }

**Tabela 4** Configuração padrão do plug-in da zona de CoreDNS ativa
Nome do plug-in	Descrição
bind	Endereço IP do host escutado pelo CoreDNS. Mantenha o valor padrão {$POD_IP}. Para obter detalhes, consulte bind.
cache	Ativa o cache do DNS. Para obter detalhes, consulte cache.
errors	Erros são registrados no stdout. Para obter detalhes, consulte errors.
health	Verificação de integridade do CoreDNS. {$POD_IP}:8080 é escutado. Mantenha a configuração padrão. Caso contrário, a verificação de integridade do CoreDNS falhará e o complemento será reiniciado repetidamente. Para mais detalhes, veja health.
ready	Se o servidor back-end está pronto para receber tráfego. {$POD_IP}:8081 é escutado. Se o servidor back-end não estiver pronto, o CoreDNS suspenderá a resolução de DNS até que o servidor back-end esteja pronto. Para obter detalhes, veja ready.
kubernetes	O plug-in CoreDNS do Kubernetes, que fornece o recurso de análise de serviços em um cluster. Para detalhes, veja kubernetes.
loadbalance	Balanceador de carga do DNS round-robin que randomiza a ordem dos registros A, AAAA e MX em uma resposta. Para obter detalhes, consulte loadbalance.
prometheus	API para obter métricas do CoreDNS. {$POD_IP}:9153 é escutado na zona padrão. Mantenha a configuração padrão. Caso contrário, a Prometheus não poderá coletar métricas do CoreDNS. Para detalhes, veja Prometheus.
forward	Encaminha quaisquer consultas que não estejam no domínio do cluster do Kubernetes para resolvedores predefinidos (/etc/resolv.conf). Para obter detalhes, consulte forward.
reload	Recarrega automaticamente Corefiles modificados. Depois de modificar um ConfigMap, aguarde dois minutos para que a modificação tenha efeito. Para obter detalhes, consulte reload.
log	Habilita o registro em logs do CoreDNS. Para mais detalhes, consulte log. Exemplo: { "name": "log" }
template	Um modelo de resposta rápida, onde AAAA indica uma solicitação IPv6. Se NXDOMAIN é retornado em uma resposta rcode, nenhum resultado de resolução IPv6 é retornado. Para obter detalhes, consulte template. Exemplo: { "configBlock": "rcode NXDOMAIN", "name": "template", "parameters": "ANY AAAA" }

Configure as políticas de agendamento para o complemento.

As políticas de agendamento não entram em vigor em instâncias complementares do tipo DaemonSet.
Ao configurar a implementação de várias AZs ou a afinidade de nó, verifique se há nós que atendem à política de agendamento e se os recursos são suficientes no cluster. Caso contrário, o complemento não pode ser executado.

**Tabela 5** Configurações para programação de complementos
Parâmetro	Descrição
Multi-AZ Deployment	Preferred: os pods de Implementação do complemento serão agendados preferencialmente para nós em diferentes AZs. Se todos os nós no cluster forem implementados na mesma AZ, os pods serão agendados para essa AZ. Forcible: os pods de Implementação do complemento serão forçosamente agendados para nós em diferentes AZs. Se houver menos AZs do que pods, os pods extras não funcionarão.
Node Affinity	Incompatibility: a afinidade de nó está desabilitada para o complemento. Node Affinity: especifique os nós em que o complemento é implementado. Se você não especificar os nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão. Specified Node Pool Scheduling: especifique o pool de nós em que o complemento é implementado. Se você não especificar o pool de nós, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão. Custom Policies: insira os rótulos dos nós em que o complemento será implementado para políticas de agendamento mais flexíveis. Se você não especificar rótulos de nó, o complemento será agendado aleatoriamente com base na política de agendamento de cluster padrão. Se várias políticas de afinidade personalizadas estiverem configuradas, certifique-se de que existem nós que atendam a todas as políticas de afinidade no cluster. Caso contrário, o complemento não pode ser executado.
Taints and Tolerations	O uso de manchas e tolerâncias permite (não forçosamente) que Implementação do complemento seja agendada para um nó com as manchas correspondentes e controla as políticas de despejo de Implementação depois que o nó onde a Implementação está localizada é contaminado. O complemento adiciona a política de tolerância padrão para as manchas node.kubernetes.io/not-ready e node.kubernetes.io/unreachable, respectivamente. A janela de tempo de tolerância é 60s. Para mais detalhes, consulte Manchas e tolerâncias.

Clique em Install.

Componentes

**Tabela 6** Componentes do CoreDNS
Componente	Descrição	Tipo de recurso
CoreDNS	Servidor DNS para clusters	Implementação

Como funciona a resolução de nomes de domínio no Kubernetes?

As políticas de DNS podem ser configuradas para cada pod. O Kubernetes é compatível com as políticas de DNS Default, ClusterFirst, ClusterFirstWithHostNet e None. Para obter detalhes, consulte DNS para Serviços e pods. Essas políticas são especificadas no campo dnsPolicy no pod específico.

Default: os pods herdam a configuração de resolução de nome do nó em que os pods são executados. O servidor DNS upstream personalizado e o domínio de stub não podem ser usados junto com esta política.
ClusterFirst: qualquer consulta de DNS que não corresponda ao sufixo de domínio de cluster configurado, como www.kubernetes.io, é encaminhada para o servidor de nomes upstream herdado do nó. Os administradores de cluster podem ter domínios de stub extra e servidores DNS upstream configurados.
ClusterFirstWithHostNet: para pods em execução com hostNetwork, defina a política de DNS ClusterFirstWithHostNet.
None: ela permite que um pod ignore as configurações de DNS do ambiente do Kubernetes. Todas as configurações de DNS devem ser fornecidas usando o campo dnsPolicy no pod específico.

Os clusters do Kubernetes v1.10 e posteriores são compatíveis com Default, ClusterFirst, ClusterFirstWithHostNet e None. Os clusters anteriores ao Kubernetes v1.10 suportam apenas Default, ClusterFirst e ClusterFirstWithHostNet.
Default não é a política de DNS padrão. Se dnsPolicy não for explicitamente especificado, será usado ClusterFirst.

Roteamento

Without stub domain configurations: qualquer consulta que não corresponda ao sufixo de domínio de cluster configurado, como www.kubernetes.io, é encaminhada para o servidor DNS upstream herdado do nó.

With stub domain configurations: se os domínios de stub e servidores DNS upstream estiverem configurados, as consultas de DNS serão roteadas de acordo com o seguinte fluxo:

A consulta é enviada primeiro para a camada de cache do DNS no CoreDNS.
A partir da camada de cache, o sufixo da solicitação é examinado e, em seguida, a solicitação é encaminhada para o DNS correspondente:
- Nomes com o sufixo de cluster, por exemplo, .cluster.local: a solicitação é enviada ao CoreDNS.
- Nomes com o sufixo de domínio de stub, por exemplo, .acme.local: a solicitação é enviada para o resolvedor do DNS personalizado configurado que escuta, por exemplo, em 1.2.3.4.
- Nomes que não correspondem ao sufixo (por exemplo, widget.com): a solicitação é encaminhada para o DNS upstream.