Configurer le proxy DNS

Remarque : Ce guide est uniquement consacré à Cloud Service Mesh avec les API Istio. Il ne concerne pas les API Google Cloud . Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Le proxy DNS est une fonctionnalité qui offre les possibilités suivantes :

1. Propagation des entrées DNS de Services dans les clusters d'une configuration multicluster.
2. Remplissage des entrées DNS pour ServiceEntry.

Kubernetes ne fournit la résolution DNS que pour Services dans le cluster local. Lorsque vous devez fournir une résolution de nom pour Services dans un cluster distant ou utiliser un nom d'hôte interne uniquement avec ServiceEntry sans avoir de serveur DNS interne uniquement supplémentaire, le proxy DNS permet de résoudre les noms DNS dans de tels cas.

Remarque : Cette fonctionnalité est disponible à partir du plan de données 1.21.5-asm.39 et dans le canal de publication rapide.

Configurer le proxy DNS

Pour configurer le proxy DNS, configurez l'indicateur ISTIO_META_DNS_CAPTURE comme suit. Vous pouvez choisir la configuration à l'échelle du cluster ou par proxy.

Configuration à l'échelle du cluster

Pour configurer le proxy DNS dans le cluster, ajoutez les métadonnées du proxy ISTIO_META_DNS_CAPTURE à ConfigMap pour MeshConfig. Le nom de ConfigMap est au format istio-<revision_name>. Pour en savoir plus sur la révision, consultez la présentation de la révision.

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

Configuration par proxy

Pour configurer un proxy DNS pour un proxy, ajoutez l'annotation de métadonnées de proxy ISTIO_META_DNS_CAPTURE comme suit :

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

Validation

Pour vérifier que tout est correctement configuré, suivez les étapes.

Résolution de nom pour Service dans les clusters

Après la configuration multicluster, déployez un Service dans un seul des clusters pour vérifier la résolution de nom entre clusters.

Dans l'exemple suivant : Service ns1/svc1, vous pouvez trouver ClusterIP dans Service.

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

Ensuite, lorsque vous utilisez curl du cluster other vers Service, ClusterIP doit s'afficher comme suit.

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

Résolution de nom pour ServiceEntry

Ajoutez un ServiceEntry avec un nom d'hôte non enregistré dans votre DNS. Pour vérifier la résolution du nom, l'exemple suivant comporte une adresse explicite 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

Ensuite, essayez la résolution DNS dans un pod où le proxy DNS est activé. Par exemple, si vous exécutez un curl dans le pod, l'adresse IP doit s'afficher comme suit :

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

Attribution automatique d'adresses IP pour ServiceEntry

Lorsque vous utilisez ServiceEntry avec le proxy DNS, vous pouvez éventuellement activer l'allocation automatique d'adresses IP. Lorsqu'il est activé, les adresses IP internes (de la plage 240.240.0.0/16) sont automatiquement attribuées aux hôtes ServiceEntry qui ne spécifient pas d'adresses IP explicites dans spec.addresses.

Activer l'allocation automatique d'adresses IP

Pour activer l'allocation automatique d'adresses IP, suivez les instructions correspondant à l'implémentation de votre plan de contrôle :

TRAFFIC_DIRECTOR

Pour l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, configurez l'allocation automatique d'adresses IP dans asm-options ConfigMap au sein de l'espace de noms istio-system en définissant ip_auto_allocation: "true".

Remarque : Pour les implémentations TRAFFIC_DIRECTOR, l'allocation automatique d'adresses IP n'est compatible qu'avec le canal de publication Précoce.

L'exemple suivant montre un ConfigMap asm-options avec l'allocation automatique d'adresses IP activée :

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

Vous pouvez également appliquer cette configuration à l'aide de kubectl patch :

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

ISTIOD

Attention : Le plan de contrôle ISTIOD pour Cloud Service Mesh dans un cluster sur GKE sur Google Cloud est obsolète. Cloud Service Mesh avec un plan de contrôle intégré au cluster sur Google Distributed Cloud (logiciel uniquement) reste compatible, comme décrit dans Plates-formes compatibles.

Attention : L'implémentation de Cloud Service Mesh géré à l'aide du plan de contrôle ISTIOD est obsolète. Vous devez moderniser tous les parcs ISTIOD gérés vers l'implémentation du plan de contrôle TRAFFIC_DIRECTOR.

Pour les clusters utilisant l'implémentation du plan de contrôle ISTIOD (ISTIOD dans le cluster ou géré), configurez l'allocation automatique d'adresses IP en ajoutant ISTIO_META_DNS_AUTO_ALLOCATE: "true" aux métadonnées de votre proxy dans 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

Vérifier l'allocation automatique d'adresses IP

Vous pouvez vérifier que l'allocation automatique d'adresses IP fonctionne en procédant comme suit.

Avant la validation, créez un ServiceEntry sans spécifier 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

Remarque : La première étape n'est possible que si vous utilisez l'implémentation TRAFFIC_DIRECTOR. Si vous utilisez ISTIOD, passez à la deuxième étape.

1. Vérifier l'adresse attribuée dans status.addresses (TRAFFIC_DIRECTOR uniquement)

Dans l'implémentation TRAFFIC_DIRECTOR, le contrôleur alloue une adresse IP virtuelle et renseigne le champ status.addresses de ServiceEntry :

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

Le résultat affiche l'adresse attribuée sous status.addresses :

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

2. Tester la résolution DNS à partir d'un pod (TRAFFIC_DIRECTOR et ISTIOD)

Dans les implémentations TRAFFIC_DIRECTOR et ISTIOD, envoyez une requête depuis un pod où le proxy DNS est activé pour vérifier que la résolution de nom est résolue en VIP attribuée :

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

La tentative de connexion doit être résolue en VIP attribuée automatiquement (par exemple, 240.240.0.1:80) :

*   Trying 240.240.0.1:80...