Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Centro de ayuda/ Cloud Container Engine/ Guía del usuario/ Complementos/ coredns (complemento de recursos del sistema, obligatorio)
Actualización más reciente 2024-09-10 GMT+08:00

coredns (complemento de recursos del sistema, obligatorio)

Presentación

El complemento coredns es un servidor DNS que proporciona servicios de resolución de nombres de dominio para clústeres de Kubernetes. Complementos de coredns cadenas para proporcionar características adicionales.

coredns es un software de código abierto y ha sido parte de CNCF. Proporciona un medio para que los servicios en la nube se descubran entre sí en despliegues nativos en la nube. Cada uno de los complementos encadenados por coredns proporciona una función de DNS particular. Puede integrar coredns con solo los complementos que necesite para que sea rápido, eficiente y flexible. Cuando se utiliza en un clúster de Kubernetes, coredns puede detectar automáticamente los servicios del clúster y proporcionar la resolución de nombres de dominio para estos servicios. Al trabajar con el servidor de DNS, coredns puede resolver nombres de dominio externos para cargas de trabajo en un clúster.

coredns es un complemento de recursos del sistema. Se instala de forma predeterminada cuando se crea un clúster de Kubernetes v1.11 o posterior.

Kubernetes v1.11 y posteriores respaldan a CoreDNS como el DNS predeterminado oficial para todos los clústeres en el futuro.

Sitio web oficial de CoreDNS: https://coredns.io/

Comunidad de código abierto: https://github.com/coredns/coredns

Para obtener más información, véase DNS.

Notas y restricciones

Cuando coredns se está ejecutando correctamente o se está actualizando, asegúrese de que el número de nodos disponibles es mayor o igual que el número de instancias de coredns y todas las instancias de coredns se están ejecutando. De lo contrario, la actualización fallará.

Instalación del complemento

Este complemento se ha instalado de forma predeterminada. Si se desinstala por alguna razón, puede volver a instalarlo realizando los siguientes pasos:

  1. Inicie sesión en la consola de CCE y acceda a la consola del clúster. Elija Add-ons en el panel de navegación, localice coredns a la derecha y haga clic en Install.
  2. En la página Install Add-on, seleccione las especificaciones del complemento y establezca los parámetros relacionados.

    Tabla 1 parámetros de complemento de coredns

    Parámetro

    Descripción

    Add-on Specifications

    Capacidad de resolución de nombres de dominio simultáneos. Seleccione las especificaciones adicionales que mejor se adapten a sus necesidades.

    Si selecciona Custom qps, la resolución de nombres de dominio de QPS proporcionada por CoreDNS se correlaciona positivamente con el consumo de CPU. Ajuste el número de pods y las cuotas de memoria y CPU de contenedor según sea necesario.

    Pods

    Número de pods que se crearán para que coincidan con las especificaciones del complemento seleccionado.

    Containers

    Cuotas de CPU y memoria del contenedor permitidas para las especificaciones de complemento seleccionadas.

    Parameters

    • parameterSyncStrategy: indica si se debe configurar la comprobación de consistencia cuando se actualiza un complemento.
      • ensureConsistent: indica que la comprobación de consistencia de la configuración está activada. Si la configuración registrada en el clúster es incompatible con la configuración real, el complemento no se puede actualizar.
      • force: indica que la comprobación de consistencia de la configuración se ignora durante una actualización. Asegúrese de que la configuración efectiva actual es la misma que la configuración original. Después de actualizar el complemento, restaure el valor de parameterSyncStrategy a ensureConsistent y vuelva a activar la comprobación de consistencia de configuración.
      • inherit: indica que las configuraciones diferenciadas se heredan automáticamente durante una actualización. Después de actualizar el complemento, restaure el valor de parameterSyncStrategy a ensureConsistent y vuelva a activar la comprobación de consistencia de configuración.
    • stub_domains: Servidor de nombres de dominio para un nombre de dominio definido por el usuario. El formato es un par clave-valor. La clave es un sufijo de nombre de dominio de DNS y el valor es una o más direcciones IP de DNS.
    • upstream_nameservers: La dirección IP del servidor de DNS ascendente.
    • servers: La configuración de servidores está disponible desde coredns 1.23.1. Puede personalizar la configuración de los servidores. Para obtener más información, consulte dns-custom-nameservers. plugins indica la configuración de cada componente en coredns (https://coredns.io/manual/plugins/). Se recomienda conservar las configuraciones predeterminadas en escenarios comunes para evitar que CoreDNS no esté disponible debido a errores de configuración. Cada componente del complemento contiene name, parameters (opcional) y configBlock (opcional). El formato del Corefile generado es el siguiente:

      $name $parameters {

      $configBlock

      }

      Tabla 2 describe los complementos comunes.

    Por ejemplo:

    {
         "servers": [
    		   {
    			"plugins": [
    				{
    					"name": "bind",
    					"parameters": "{$POD_IP}"
    				},
    				{
    					"name": "cache",
    					"parameters": 30
    				},
    				{
    					"name": "errors"
    				},
    				{
    					"name": "health",
    					"parameters": "{$POD_IP}:8080"
    				},
    				{
    					"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"
    				},
    				{
    					"name": "log"
    				}
    			],
    			"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"]
    }
    Tabla 2 Configuración predeterminada del complemento de la zona activa de coredns

    Nombre del complemento

    Descripción

    bind

    Dirección IP del host escuchada por coredns. Se recomienda conservar el valor por defecto {$POD_IP}.

    cache

    La caché de DNS está habilitada.

    errors

    Los errores se registran en stdout.

    health

    Configuración de comprobación de estado. La dirección IP de escucha actual es {$POD_IP}:8080. Conserve el valor predeterminado. De lo contrario, la comprobación de estado de coredns falla y coredns se reinicia repetidamente.

    kubernetes

    Complemento de CoreDNS Kubernetes, que proporciona la capacidad de análisis de servicios en un clúster.

    loadbalance

    Balanceador de carga de DNS de asignación cíclica que aleatoriza el orden de los registros A, AAAA y MX en la respuesta.

    prometheus

    Puerto para obtener métricas de coredns. La dirección IP de escucha de zona predeterminada es {$POD_IP}:9153. Conserve el valor predeterminado. De lo contrario, CloudScope no pueden recopilar métricas de coredns.

    forward

    Las consultas que no estén dentro del dominio de clúster de Kubernetes se reenviarán a solucionador predefinidos (/etc/resolv.conf).

    reload

    El Corefile cambiado se puede recargar automáticamente. Después de editar el ConfigMap espere dos minutos para que la modificación surta efecto.

  3. Una vez completadas las configuraciones anteriores, haga clic en Install.

¿Cómo funciona la resolución de nombres de dominio en Kubernetes?

Las políticas de DNS se pueden establecer en función de cada pod. Actualmente, Kubernetes admite cuatro tipos de políticas de DNS: Default, ClusterFirst, ClusterFirstWithHostNet y None. Para obtener más información, véase https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/. Estas políticas se especifican en el campo dnsPolicy del pod específico.

  • Default: Los pods heredan la configuración de resolución de nombres del nodo en el que se ejecutan los pods. El servidor de DNS ascendente personalizado y el dominio stub no se pueden usar junto con esta política.
  • ClusterFirst: Cualquier consulta de DNS que no coincida con el sufijo de dominio de clúster configurado, como www.kubernetes.io, se reenvía al servidor de nombres de flujo ascendente heredado del nodo. Los administradores de clústeres pueden tener otros dominios stub y servidores de DNS ascendentes configurados.
  • ClusterFirstWithHostNet: Para los pods que se ejecutan con hostNetwork, establezca su política de DNS ClusterFirstWithHostNet.
  • None: Permite que un pod ignore la configuración de DNS del entorno de Kubernetes. Se supone que todas las configuraciones de DNS se proporcionan usando el campo dnsPolicy en el pod específico.
  • Los clústeres de Kubernetes v1.10 y posteriores admiten Default, ClusterFirst, ClusterFirstWithHostNet y None. Los clústeres anteriores a Kubernetes v1.10 solo admiten Default, ClusterFirst y ClusterFirstWithHostNet.
  • Default no es la política de DNS predeterminada. Si dnsPolicy no se especifica explícitamente, se utiliza ClusterFirst.

Routing

Without stub domain configurations: cualquier consulta que no coincida con el sufijo de dominio de clúster configurado, como www.kubernetes.io, se reenvía al servidor de DNS ascendente heredado del nodo.

With stub domain configurations: Si se configuran dominios stub y servidores de DNS ascendentes, las consultas de DNS se enrutan según el siguiente flujo:

  1. La consulta se envía primero a la capa de caché de DNS en coredns.
  2. Desde la capa de almacenamiento en caché, se examina el sufijo de la solicitud y luego la solicitud se reenvía al DNS correspondiente:
    • Nombres con el sufijo de clúster, por ejemplo, .cluster.local: La solicitud se envía a coredns.
    • Nombres con el sufijo de dominio stub, por ejemplo, .acme.local: La solicitud se envía al solucionador de DNS personalizado configurado que escucha, por ejemplo, en 1.2.3.4.
    • Nombres que no coinciden con el sufijo (por ejemplo, widget.com): la solicitud se reenvía al DNS ascendente.
Figura 1 Enrutamiento

Personalización de las especificaciones de CoreDNS

En la consola, el complemento de coredns solo se puede configurar con las especificaciones preestablecidas, que pueden satisfacer la mayoría de los requisitos de servicio. En algunos escenarios en los que hay requisitos sobre el uso de recursos de CoreDNS, es posible que deba personalizar las especificaciones del complemento.

A continuación se describe cómo personalizar los parámetros de CoreDNS, incluidas las réplicas, las CPU y la memoria.

  • La modificación incorrecta en la configuración de CoreDNS puede provocar errores de resolución de nombres de dominio en el clúster. Realice pruebas antes y después de la modificación.
  • Al modificar el número de réplicas de CoreDNS, CPUs y tamaño de memoria, se cambiará la capacidad de análisis de CoreDNS. Por lo tanto, evalúe el impacto antes de la operación.
  • De forma predeterminada, podAntiAffinity (pod anti-afinidad) está configurado para el complemento de coredns. Si un nodo ya tiene un pod de CoreDNS, no se puede agregar un pod nuevo. Es decir, solo un pod de CoreDNS puede ejecutarse en un nodo. Si el número de réplicas de CoreDNS configuradas es mayor que el número de nodos de clúster, el exceso de pods no se puede programar. Por lo tanto, mantenga el número de réplicas menor o igual que el número de nodos.
  1. Invoque a la API de consulta de complementos para consultar el ID del complemento de coredns instalado.

    GET https://{cluster_id}.{endpoint}/api/v3/addons?cluster_id={cluster_id}

    Para obtener más información sobre cómo invocar a una API, consulte Invocación de las API. {cluster_id} indica el ID del clúster, que se puede ver en la página de detalles del clúster en la consola de CCE. {endpoint} indica la dirección de acceso de CCE, que se puede obtener de Regiones y puntos de conexión. Por ejemplo, el cce.east-3.myhuaweicloud.com indica la región de Shanghai1.

    Vea el complemento uid y spec de coredns en la respuesta.

    {
        "kind": "Addon",
        "apiVersion": "v3",
        "items": [
            {
                "kind": "Addon",
                "apiVersion": "v3",
                "metadata": {
                    "uid": "2083381d-46ae-11ec-91a8-0255ac1000c5",
                    "name": "coredns",
                    "creationTimestamp": "2021-11-16T07:23:42Z",
                    "updateTimestamp": "2021-11-16T07:27:35Z"
                },
                "spec": {
                    "clusterID": "15d748b4-3de1-11ec-9199-0255ac1000c9",
                    "version": "1.17.9",
                    "addonTemplateName": "coredns",
                    "addonTemplateType": "helm",
    ...

  2. Invoque a la API de configuración para modificar las especificaciones del complemento.

    PUT https://{cluster_id}.{endpoint}/api/v3/addons/{uid}

    {cluster_id} indica el ID del clúster. {endpoint} indica la dirección para acceder a CCE, que se puede obtener de Regiones y puntos de conexión. {uid} indica el ID de complemento obtenido en el paso anterior.

    A continuación se muestra un ejemplo del cuerpo de la solicitud. spec define el contenido consultado en el paso anterior. Modifique replicas (número de réplicas) y resources (uso de CPU/memoria de un solo pod) según sea necesario. Conserve los valores de clusterID y version. El valor de addon.upgrade/type debe ser patch.

    {
        "metadata": {
            "annotations": {
                "addon.upgrade/type": "patch"
            }
        },
        "spec": {
            "clusterID": "15d748b4-3de1-11ec-9199-0255ac1000c9",
            "version": "1.17.9",
            "addonTemplateName": "coredns",
            "values": {
                "flavor": {
                    "replicas": 2,
                    "resources": [
                        {
                            "limitsCpu": "500m",
                            "limitsMem": "512Mi",
                            "requestsCpu": "500m",
                            "requestsMem": "512Mi"
                        }
                    ]
                }
            }
        }
    }

Historial de cambios

Tabla 3 Versiones de complementos de CCE

Versión del complemento

Versión de clúster admitida

Versión de la comunidad (solo para clústeres de v1.17 y posteriores)

1.25.1

/v1.(19|21|23|25).*/

1.8.4

1.23.3

/v1.(15|17|19|21|23).*/

1.8.4

1.23.2

/v1.(15|17|19|21|23).*/

1.8.4

1.23.1

/v1.(15|17|19|21|23).*/

1.8.4

1.17.15

/v1.(15|17|19|21).*/

1.8.4

1.17.9

/v1.(15|17|19).*/

1.8.4

1.17.7

/v1.(15|17|19).*/

1.8.4

1.17.4

/v1.(17|19).*/

1.6.5

1.17.3

/v1.17.*/

1.6.5

1.17.1

/v1.17.*/

1.6.5