Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Migrer Ingress vers l'API Gateway

Autopilot Standard

Cette page explique comment migrer la gestion du trafic sur Google Kubernetes Engine (GKE) de l'API Ingress vers l'API Gateway. L'API Gateway fournit une solution entièrement gérée, Google Cloud pour gérer le trafic de votre application.

Pour minimiser les temps d'arrêt et atténuer les risques, l'approche la plus efficace pour migrer vers l'API Gateway consiste à exécuter simultanément votre API Ingress existante et les nouvelles configurations de l'API Gateway. Cette méthode permet de tester en profondeur la nouvelle configuration de la passerelle dans un environnement en direct sans impacter vos services actuels. Une fois que vous avez validé la nouvelle configuration de la passerelle, vous pouvez effectuer une bascule DNS rapide pour rediriger le trafic vers l'API Gateway et faciliter une transition fluide et à faible risque.

De manière générale, la stratégie de migration comprend les phases suivantes :

Configurer le nouvel équilibreur de charge.
Définir des règles pour gérer le trafic entrant.
Déployer la nouvelle configuration et tester le flux de trafic vers la nouvelle adresse IP de la passerelle.
Basculer le trafic de production vers l'API Gateway.
Nettoyer les ressources Ingress restantes.

Configurer le nouvel équilibreur de charge

Au cours de cette phase, vous déployez une ressource Gateway Kubernetes pour équilibrer la charge du trafic vers votre cluster GKE. Lorsque vous déployez une ressource Gateway, GKE configure un équilibreur de charge d'application de couche 7 pour exposer le trafic HTTP(S) aux applications qui s'exécutent dans le cluster. Vous déployez une ressource Gateway pour chaque cluster ou pour chaque équilibreur de charge dont vous avez besoin.

Dans l'exemple suivant, vous configurez un équilibreur de charge d'application externe global. Pour créer une passerelle, enregistrez le fichier manifeste suivant sous le nom gateway.yaml :

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

Le fichier manifeste précédent décrit une passerelle qui inclut les champs suivants :

gatewayClassName: gke-l7-global-external-managed : spécifie la classe GatewayClass pour cette passerelle. Cette classe de passerelle utilise un équilibreur de charge d'application externe global.
protocol: HTTP et port: 80 : spécifient que la passerelle expose le port 80 pour le trafic HTTP.

Définir des règles de trafic pour le trafic entrant

Les ressources de routage définissent des règles spécifiques au protocole pour mapper le trafic d'une passerelle vers des services de backend.

Au cours de cette phase, vous traduisez votre fichier manifeste Ingress en ressource HTTPRoute. Pour convertir le fichier manifeste Ingress, suivez les étapes de l' ingress2gateway.

Cet exemple suppose que vous disposez de la ressource Ingress suivante :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Une fois que vous avez converti le fichier manifeste à l'aide de l'outil ingress2gateway, le résultat est le fichier manifeste HTTPRoute traduit.

Enregistrez l'exemple de fichier manifeste suivant sous le nom httproute.yaml :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

Notez que le champ rules du fichier manifeste HTTPRoute correspond directement aux règles de routage définies dans le fichier manifeste Ingress d'origine.

Déployer et tester la nouvelle configuration

Au cours de cette phase, vous appliquez les fichiers manifestes Gateway et HTTPRoute que vous avez créés au cours des deux phases précédentes, et vous vérifiez que le trafic est acheminé vers la nouvelle adresse IP de la passerelle.

Appliquez les fichiers manifestes Gateway et HTTPRoute :

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

Obtenez l'adresse IP de la passerelle. L'allocation de l'adresse IP peut prendre quelques minutes :
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
Le résultat est l'adresse IP externe de la passerelle, par exemple 203.0.113.90.
Testez la nouvelle adresse IP de la passerelle. Utilisez la commande curl suivante pour envoyer une requête à l'adresse IP et spécifier le nom d'hôte cafe.example.com. Exemple :
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
Remplacez 203.0.113.90 par l'adresse IP externe que vous avez obtenue à l'étape précédente. Le résultat confirme que la nouvelle adresse IP de la passerelle achemine correctement le trafic pour cafe.example.com sans effectuer de résolution DNS.

Diriger le trafic vers la nouvelle adresse IP de la passerelle

Au cours de cette phase, vous basculez le trafic en direct de votre Ingress précédent vers la nouvelle passerelle en mettant à jour vos enregistrements DNS pour qu'ils pointent vers la nouvelle adresse IP de la passerelle. Les étapes exactes à suivre pour mettre à jour les enregistrements DNS varient en fonction de votre fournisseur DNS.

Par exemple, si vous avez configuré cafe.example.com dans Ingress, vous devez localiser l'enregistrement A pour cafe.example.com auprès de votre fournisseur DNS et remplacer la valeur de l'ancienne adresse IP Ingress par 203.0.113.90, qui correspond à la nouvelle adresse IP de la passerelle.

Une fois que vous avez mis à jour l'enregistrement DNS, le trafic commence à passer d'Ingress à Gateway, mais la bascule ne se produit pas immédiatement pour tous les clients. Les résolveurs DNS qui ont l'enregistrement précédent en cache attendent que la valeur TTL (Time To Live) de l'enregistrement expire avant d'interroger à nouveau l'enregistrement et de recevoir l'adresse IP mise à jour. Pour cette raison, vous devez continuer à exécuter votre Ingress existant et votre nouvelle passerelle en parallèle jusqu'à ce que vous vérifiiez que le trafic vers l'Ingress a cessé, ce qui indique que la propagation DNS est terminée et que les clients ne sont plus redirigés vers l'ancienne adresse IP. Vous pouvez le vérifier en surveillant le trafic sur votre équilibreur de charge ou votre contrôleur Ingress. Pour en savoir plus, consultez la section Vérifier la propagation DNS.

Si vous utilisez Cloud DNS, vous pouvez utiliser des pondérations cibles pour transférer progressivement le trafic de l'ancienne adresse IP vers la nouvelle. Pour en savoir plus, consultez la section Configurer des règles de routage DNS et des vérifications de l'état .

Nettoyer les ressources Ingress restantes

Une fois que vous avez confirmé que votre nouvelle passerelle fonctionne correctement, nettoyez les anciennes ressources Ingress.

Supprimez la ressource Ingress :
```
kubectl delete ingress cafe-ingress
```
Désinstallez le contrôleur ingress-nginx. Par exemple, si vous avez utilisé Helm pour installer le contrôleur, exécutez la commande suivante :
```
helm uninstall ingress-nginx -n ingress-nginx
```

Comparaison des fonctionnalités entre Ingress NGINX et GKE Gateway

L'API Gateway fournit un moyen plus standardisé de configurer l'entrée et offre une parité des fonctionnalités pour la plupart des fonctionnalités courantes telles que le routage, les en-têtes et la répartition du trafic.

Le tableau suivant compare les annotations utilisées pour les fonctionnalités courantes dans le contrôleur Ingress et l'API Gateway.

Fonctionnalité	Annotation dans Ingress	Annotation dans GKE Gateway	Parité
Réécriture d'URL	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` avec un filtre `urlRewrite`.	Parité partielle. GKE Gateway n'accepte que les remplacements de préfixes.
Manipulation des en-têtes	`nginx.ingress.kubernetes.io/proxy-set-headers` ou `add-headers`	`HTTPRoute` avec un modificateur `requestHeaderModifier` ou un filtre `responseHeaderModifier`.	Parité complète.
Routage basé sur le chemin d'accès	`spec.rules.http.paths` dans l'objet Ingress.	`rules.matches.path` dans l'objet HTTPRoute.	Parité complète.
Routage basé sur l'hôte	`spec.rules.host` dans l'objet Ingress.	`hostnames` dans l'objet HTTPRoute.	Parité complète.
Répartition du trafic	Annotations `nginx.ingress.kubernetes.io/canary` .	`HTTPRoute` avec `backendRefs` pondérés.	Parité complète. De plus, vous pouvez répartir le trafic avec un contrôle précis.
Authentification	`nginx.ingress.kubernetes.io/auth-url` pour l'authentification externe.	Identity-Aware Proxy (IAP) : CRD `BackendPolicy`. Autres : nécessite une approche plus personnalisée, éventuellement avec un maillage de services ou des filtres personnalisés.	Parité partielle. Identity-Aware Proxy est le moyen recommandé de sécuriser votre passerelle et est configuré sur le backend.

Étape suivante

Découvrez comment sécuriser votre passerelle.
Découvrez comment fonctionne la gestion du trafic de passerelle .