Configurare il proxy DNS

Il proxy DNS è una funzionalità che fornisce le seguenti funzionalità:

  1. Propagazione delle voci DNS di Services tra i cluster in una configurazione multi-cluster.
  2. Popolazione delle voci DNS per ServiceEntry.

Kubernetes fornisce la risoluzione DNS solo per Services nel cluster locale. Quando devi fornire la risoluzione dei nomi per Services in un cluster remoto o utilizzare un nome host solo interno con ServiceEntry senza avere un server DNS solo interno aggiuntivo, il proxy DNS fornisce un modo per risolvere i nomi DNS in questi casi.

Configurare il proxy DNS

Per configurare il proxy DNS, configura il flag ISTIO_META_DNS_CAPTURE come segue. Puoi scegliere la configurazione a livello di cluster o di proxy.

Configurazione a livello di cluster

Per configurare il proxy DNS nel cluster, aggiungi i metadati del proxy ISTIO_META_DNS_CAPTURE a ConfigMap per MeshConfig. Il nome di ConfigMap ha il formato istio-<revision_name>. Per i dettagli della revisione, consulta la panoramica della revisione.

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

Configurazione per proxy

Per configurare il proxy DNS per un proxy, aggiungi l'annotazione dei metadati del proxy ISTIO_META_DNS_CAPTURE come segue:

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

In fase di verifica

Per verificare che tutto sia configurato correttamente, segui i passaggi.

Risoluzione dei nomi per Service tra i cluster

Dopo la configurazione multi-cluster, esegui il deployment di un Service solo in uno dei cluster per verificare la risoluzione dei nomi tra cluster.

Quando hai il seguente Service di esempio ns1/svc1, puoi trovare ClusterIP in Service.

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

Poi, quando utilizzi curl dall'altro cluster al Service, dovrebbe mostrare ClusterIP come segue.

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

Risoluzione dei nomi per ServiceEntry

Aggiungi un ServiceEntry con un nome host non registrato nel tuo DNS. Per verificare la risoluzione dei nomi, l'esempio seguente ha l'indirizzo esplicito 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

Quindi, prova la risoluzione DNS in un pod in cui è abilitato il proxy DNS. Ad esempio, se esegui un curl nel pod, dovrebbe visualizzare l'indirizzo IP come segue:

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

Allocazione automatica dell'IP per ServiceEntry

Quando utilizzi ServiceEntry con il proxy DNS, puoi facoltativamente abilitare l'allocazione automatica dell'IP. Se abilitata, gli indirizzi IP interni (dell'intervallo 240.240.0.0/16) vengono allocati automaticamente per gli host ServiceEntry che non specificano indirizzi IP espliciti in spec.addresses.

Abilitare l'allocazione automatica dell'IP

Per abilitare l'allocazione automatica dell'IP, segui le istruzioni per l'implementazione del piano di controllo:

TRAFFIC_DIRECTOR

Per l'implementazione del control plane TRAFFIC_DIRECTOR, configura l'allocazione automatica dell'IP in asm-options ConfigMap nello spazio dei nomi istio-system impostando ip_auto_allocation: "true".

L'esempio seguente mostra un ConfigMap asm-options con l'allocazione automatica dell'IP abilitata:

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

Puoi anche applicare questa configurazione utilizzando kubectl patch:

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

ISTIOD

Per i cluster che utilizzano l'implementazione del piano di controllo ISTIOD (in-cluster o gestito ISTIOD), configura l'allocazione automatica dell'IP aggiungendo ISTIO_META_DNS_AUTO_ALLOCATE: "true" ai metadati del proxy in 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

Verificare l'allocazione automatica dell'IP

Puoi verificare che l'allocazione automatica dell'IP funzioni seguendo questi passaggi.

Prima della verifica, crea un ServiceEntry senza specificare 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. Controlla l'indirizzo allocato in status.addresses (solo TRAFFIC_DIRECTOR)

Nell'implementazione TRAFFIC_DIRECTOR, il controller alloca un VIP e popola il campo status.addresses di ServiceEntry:

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

L'output mostra l'indirizzo allocato in status.addresses:

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

2. Testa la risoluzione DNS da un pod (TRAFFIC_DIRECTOR e ISTIOD)

Nelle implementazioni TRAFFIC_DIRECTOR e ISTIOD, invia una richiesta da un pod in cui è abilitato il proxy DNS per verificare che la risoluzione dei nomi risolva il VIP allocato:

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

Il tentativo di connessione dovrebbe risolvere il VIP allocato automaticamente (ad esempio, 240.240.0.1:80):

*   Trying 240.240.0.1:80...