Configura el proxy de DNS

Kubernetes resuelve de forma nativa los nombres de DNS solo para Services en el clúster local. El proxy de DNS te permite resolver los Services de Kubernetes en clústeres remotos en una configuración de varios clústeres y generar registros DNS para los recursos ServiceEntry. Esto te ayuda a enrutar el tráfico a nombres de host internos sin mantener servidores DNS internos adicionales.

Configura el proxy de DNS

Para configurar el proxy de DNS, configura la marca ISTIO_META_DNS_CAPTURE de la siguiente manera. Puedes elegir la configuración de todo el clúster o por proxy.

Configuración de todo el clúster

Para configurar el proxy de DNS en el clúster, agrega los metadatos del proxy de ISTIO_META_DNS_CAPTURE al ConfigMap para MeshConfig. El nombre del ConfigMap tiene el formato istio-<revision_name>. Para obtener los detalles de la revisión, consulta la descripción general de la revisión.

apiVersion: v1
data:
  mesh: |-
    ...
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"        
    ...
kind: ConfigMap
metadata:
  name: istio-<revision_name>
  namespace: istio-system

Configuración por proxy

Para configurar el proxy de DNS para un proxy, agrega la anotación de metadatos del proxy ISTIO_META_DNS_CAPTURE de la siguiente manera:

kind: Deployment
metadata:
  name: app1
  namespace: ns1
spec:
...
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          proxyMetadata:
            ISTIO_META_DNS_CAPTURE: "true"
...

Verificando

Para verificar que todo esté configurado correctamente, ejecuta los pasos.

Resolución de nombres para Service en clústeres

Después de la configuración de varios clústeres, implementa un Service solo en uno de los clústeres para verificar la resolución de nombres entre clústeres.

Cuando tienes el siguiente ejemplo de Service ns1/svc1, puedes encontrar ClusterIP en Service.

$ kubectl get -n ns1 svc1
kind: Service
metadata:
  name: svc1
  namespace: ns1
spec:
...
  ClusterIP: 210.200.1.1
...

Luego, cuando uses curl del otro clúster al Service, debería mostrar el ClusterIP de la siguiente manera.

curl -sS -v svc1.ns1.svc.cluster.local
*   Trying 210.200.1.1:80...

Resolución de nombres para ServiceEntry

Agrega un ServiceEntry con un nombre de host que no esté registrado en tu DNS. Para verificar la resolución de nombres, el siguiente ejemplo tiene la dirección explícita 192.168.123.123.

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: test-service-entry
spec:
  addresses:
  - "192.168.123.123"
  hosts:
  - not-existing-hostname.internal
  ports:
  - name: http
    number: 80
    protocol: HTTP
EOF

Luego, prueba la resolución de DNS en un Pod en el que el proxy de DNS esté habilitado. Por ejemplo, si ejecutas un curl en el Pod, debería mostrar la dirección IP de la siguiente manera:

curl -sS -v not-existing-hostname.internal
*   Trying 192.168.123.123:80...

Asignación automática de IP para ServiceEntry

Cuando usas ServiceEntry con el proxy de DNS, puedes habilitar la asignación automática de IP de forma opcional. Cuando se habilita, las direcciones IP internas (del rango 240.240.0.0/16) se asignan de forma automática a los hosts de ServiceEntry que no especifican direcciones IP explícitas en spec.addresses.

Habilita la asignación automática de IP

Para habilitar la asignación automática de IP, sigue las instrucciones de tu implementación del plano de control:

TRAFFIC_DIRECTOR

Para la implementación del plano de control TRAFFIC_DIRECTOR, configura la asignación automática de IP en el asm-options ConfigMap dentro del espacio de nombres istio-system estableciendo ip_auto_allocation: "true".

En el siguiente ejemplo, se muestra un ConfigMap de asm-options con la asignación automática de IP habilitada:

apiVersion: v1
kind: ConfigMap
metadata:
  name: asm-options
  namespace: istio-system
data:
  # Enable IP auto-allocation for ServiceEntry (Rapid channel)
  ip_auto_allocation: "true"

También puedes aplicar esta configuración con kubectl patch:

kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ip_auto_allocation":"true"}}'

ISTIOD

Para los clústeres que usan la implementación del plano de control de ISTIOD (en el clúster o administrado ISTIOD), configura la asignación automática de IP agregando ISTIO_META_DNS_AUTO_ALLOCATE: "true" a los metadatos del proxy dentro de MeshConfig:

apiVersion: v1
data:
  mesh: |-
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
kind: ConfigMap
metadata:
  name: istio-<revision_name>
  namespace: istio-system

Verifica la asignación automática de IP

Puedes verificar que la asignación automática de IP funcione con los siguientes pasos.

Antes de la verificación, crea un ServiceEntry sin especificar spec.addresses:

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: auto-allocated-service-entry
  namespace: ns1
spec:
  hosts:
  - auto-allocated.internal
  ports:
  - name: http
    number: 80
    protocol: HTTP
  resolution: DNS
EOF

1. Verifica la dirección asignada en status.addresses (solo TRAFFIC_DIRECTOR)

En la implementación de TRAFFIC_DIRECTOR, el controlador asigna una VIP y completa el campo status.addresses del ServiceEntry:

$ kubectl get serviceentry auto-allocated-service-entry -n ns1 -o yaml

En el resultado, se muestra la dirección asignada en status.addresses:

status:
  addresses:
  - host: auto-allocated.internal
    value: 240.240.0.1

2. Prueba la resolución de DNS desde un Pod (TRAFFIC_DIRECTOR y ISTIOD)

En las implementaciones de TRAFFIC_DIRECTOR y ISTIOD, envía una solicitud desde un Pod en el que el proxy de DNS esté habilitado para verificar que la resolución de nombres se resuelva en la VIP asignada:

$ kubectl exec deploy/curl -n ns1 -- curl -sS -v http://auto-allocated.internal

El intento de conexión debería resolverse en la VIP asignada automáticamente (por ejemplo, 240.240.0.1:80):

*   Trying 240.240.0.1:80...