Configura il proxy DNS

Kubernetes risolve in modo nativo i nomi DNS solo per Services nel cluster locale. Il proxy DNS ti consente di risolvere i Services di Kubernetes tra cluster remoti in una configurazione multi-cluster e di generare record DNS per le risorse ServiceEntry. In questo modo, puoi instradare il traffico verso i nomi host interni senza dover gestire server DNS interni aggiuntivi.

Configurazione del 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, esegui 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.

Se hai il seguente esempio di Service 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 a Service, dovrebbe mostrare ClusterIP come segue.

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

Risoluzione del nome per ServiceEntry

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

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

Allocazione automatica degli IP per ServiceEntry

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

Attivazione dell'allocazione automatica degli IP

Per abilitare l'allocazione automatica degli IP, segui le istruzioni per l'implementazione del control plane:

TRAFFIC_DIRECTOR

Per l'implementazione del control plane TRAFFIC_DIRECTOR, configura l'allocazione automatica degli IP in asm-options ConfigMap all'interno del namespace istio-system impostando ip_auto_allocation: "true".

L'esempio seguente mostra un ConfigMap asm-options con l'allocazione automatica degli 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 control plane ISTIOD (ISTIOD in-cluster o gestito), configura l'allocazione automatica degli IP aggiungendo ISTIO_META_DNS_AUTO_ALLOCATE: "true" ai metadati del proxy all'interno di 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 dell'allocazione automatica degli IP

Puoi verificare che l'allocazione automatica degli 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 di TRAFFIC_DIRECTOR, il controller alloca un VIP e compila 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 venga risolta nel VIP allocato:

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

Il tentativo di connessione dovrebbe risolversi nel VIP allocato automaticamente (ad esempio 240.240.0.1:80):

*   Trying 240.240.0.1:80...