Use a DNS proxy for multi-cluster service discovery - Alibaba Cloud Service Mesh

Dans un maillage de services multi-clusters, le serveur DNS de chaque cluster ne résout que les services déployés localement. Lorsqu'un service d'un cluster envoie une requête à un service qui n'existe que dans un autre cluster, la résolution DNS échoue. Le proxy DNS remédie à cette situation : le proxy sidecar intercepte les requêtes DNS et résout les noms de services sur l'ensemble des clusters gérés par le même plan de contrôle Alibaba Cloud Service Mesh (ASM).

Cette rubrique détaille les étapes suivantes :

Déployez deux services sur deux clusters distincts : sleep dans l'un, HTTPBin dans l'autre.
Vérifiez que la résolution DNS inter-clusters échoue sans le proxy DNS.
Activez le proxy DNS et vérifiez que la découverte de services inter-clusters fonctionne.

Fonctionnement du proxy DNS

Sans proxy DNS, le serveur DNS de chaque cluster ne connaît que les services déployés dans ce cluster. Si le service sleep du cluster m1c2 envoie une requête à httpbin:8000, la recherche échoue car aucun objet Service httpbin n'existe dans m1c2.

Lorsque le proxy DNS est activé, le proxy sidecar intercepte les requêtes DNS sortantes avant qu'elles n'atteignent le serveur DNS du cluster. Le plan de contrôle ASM maintient une vue unifiée de tous les services sur les clusters gérés. Ainsi, le sidecar résout httpbin vers le point de terminaison correct dans le cluster m1c1, même en l'absence d'un objet Service local.

Architecture diagram showing cross-cluster service discovery with DNS proxy

Prérequis

Avant de commencer, assurez-vous d'avoir :

Deux clusters Container Service for Kubernetes (ACK) (nommés m1c1 et m1c2 dans cette rubrique) ajoutés à une instance ASM. Pour les instructions de configuration, consultez les étapes 1 à 3 de la rubrique Utiliser une passerelle serverless ASM comme point d'entrée unique pour plusieurs clusters
L'injection automatique du proxy sidecar activée pour le namespace default. Consultez la rubrique Gérer les namespaces globaux

Étape 1 : Déployer les services sleep et HTTPBin

Déployez chaque service sur un cluster distinct afin de nécessiter la découverte inter-clusters.

1a. Déployer sleep dans m1c2

Appliquez le code YAML suivant au cluster m1c2. Pour les instructions de déploiement, consultez la rubrique Déployer une application dans une instance ASM.

Code YAML du service sleep

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curl:8.1.2
        command: ["/bin/sleep", "infinity"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true

1b. Déployer HTTPBin dans m1c1

Appliquez le code YAML suivant au cluster m1c1. Pour les instructions de déploiement, consultez la rubrique Déployer une application dans une instance ASM.

Code YAML du service HTTPBin

apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

Étape 2 : Vérifier l'échec de la découverte inter-clusters

Avant d'activer le proxy DNS, vérifiez que le service sleep dans m1c2 ne peut pas résoudre httpbin.

Connectez-vous au cluster m1c2 avec kubectl et exécutez la commande suivante :

kubectl exec -it deploy/sleep -c sleep -- curl httpbin:8000

Résultat attendu :

curl: (6) Could not resolve host: httpbin

Le serveur DNS de m1c2 ne possède aucun enregistrement pour httpbin car l'objet Service HTTPBin n'existe que dans m1c1.

Étape 3 : Activer le proxy DNS et vérifier la découverte inter-clusters

3a. Activer le proxy DNS

Activez la fonctionnalité de proxy DNS pour l'instance ASM. Consultez la section « Enable DNS Proxy » de la rubrique Configurer les proxies sidecar.

3b. Redéployer la charge de travail sleep

Redéployez la charge de travail sleep dans le cluster m1c2 afin que la configuration mise à jour du sidecar prenne effet. Consultez la section « (Optional) Redeploy workloads » de la rubrique Configurer les proxies sidecar.

3c. Tester la découverte inter-clusters

Connectez-vous au cluster m1c2 avec kubectl et exécutez la même commande :

kubectl exec -it deploy/sleep -c sleep -- curl httpbin:8000

Résultat attendu :

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <title>httpbin.org</title>
...

La réponse correspond à la page HTML HTTPBin servie depuis le cluster m1c1. Le proxy sidecar dans m1c2 a intercepté la requête DNS, a résolu httpbin via le plan de contrôle ASM et a routé la requête vers le service HTTPBin dans m1c1.

Rubriques connexes

Configurer les proxies sidecar — Paramètres du proxy DNS et options de configuration du sidecar
Gérer les namespaces globaux — Paramètres d'injection du sidecar sur l'ensemble des namespaces
Utiliser une passerelle serverless ASM comme point d'entrée unique pour plusieurs clusters — Ingress multi-clusters avec une passerelle ASM