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.

Kubernetes résout de manière native les noms DNS uniquement pour Services dans le cluster local. Le proxy DNS vous permet de résoudre les Services Kubernetes sur des clusters distants dans une configuration multicluster et de générer des enregistrements DNS pour les ressources ServiceEntry. Cela vous permet d'acheminer le trafic vers des noms d'hôte internes sans avoir à gérer de serveurs DNS internes supplémentaires.

Remarque : Le proxy DNS nécessite la version 1.21.5-asm.39 ou ultérieure du plan de données et est disponible dans le canal de publication rapide.

Configurer le proxy DNS

Pour configurer le proxy DNS, configurez l'option 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 configuré correctement, suivez les étapes.

Résolution de noms pour Service entre les clusters

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

Lorsque vous disposez de l'exemple Service ns1/svc1 suivant, 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 de l'autre cluster vers Service, il doit afficher ClusterIP 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 de noms, l'exemple suivant comporte l'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...

Allocation 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'elle est activée, les adresses IP internes (de la plage 240.240.0.0/16) sont automatiquement alloué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 à votre implémentation du 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 le asm-options ConfigMap 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 rapide.

L'exemple suivant montre un asm-options ConfigMap 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 : Cloud Service Mesh intégré au cluster utilisant le plan de contrôle ISTIOD sur GKE sur Google Cloud est obsolète. Cloud Service Mesh avec un plan de contrôle au sein du cluster sur Google Distributed Cloud (logiciel uniquement) reste compatible, comme décrit dans Plates-formes compatibles.

Attention : Cloud Service Mesh géré utilisant l'implémentation 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 géré ou dans le cluster), 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 alloué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 à partir d'un pod sur lequel le proxy DNS est activé pour vérifier que la résolution de noms correspond à l'adresse IP virtuelle allouée :

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

La tentative de connexion doit être résolue en l'adresse IP virtuelle allouée automatiquement (par exemple, 240.240.0.1:80) :

*   Trying 240.240.0.1:80...