Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Migrer Ingress vers l'API Gateway

Autopilot Standard

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

Pour minimiser les temps d'arrêt et limiter les risques, l'approche la plus efficace pour migrer vers l'API Gateway consiste à exécuter simultanément vos configurations d'API Ingress existantes et les nouvelles configurations d'API Gateway. Cette méthode permet de tester minutieusement la nouvelle configuration de la passerelle dans un environnement de production sans affecter vos services actuels. Après avoir validé la nouvelle configuration de la passerelle, vous pouvez effectuer un basculement DNS rapide pour rediriger le trafic vers l'API Gateway, ce qui permet d'assurer une transition fluide et à faible risque.

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

Configurez le nouvel équilibreur de charge.
Définissez des règles pour gérer le trafic entrant.
Déployez la nouvelle configuration et testez le flux de trafic vers la nouvelle adresse IP de la passerelle.
Basculez le trafic de production vers l'API Gateway.
Nettoyez les ressources Ingress restantes.

Configurer le nouvel équilibreur de charge

Dans cette phase, vous allez déployer une ressource Gateway Kubernetes pour l'équilibrage de 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 allez configurer 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 ressource Gateway qui inclut les champs suivants :

gatewayClassName: gke-l7-global-external-managed : spécifie la classe GatewayClass pour cette ressource Gateway. Cette classe de passerelle utilise un équilibreur de charge d'application externe global.
protocol: HTTP et port: 80 : spécifiez que la ressource Gateway 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 ressource Gateway vers les services de backend.

Dans cette phase, vous allez traduire votre fichier manifeste Ingress en une ressource HTTPRoute. Pour convertir le fichier manifeste Ingress, suivez les étapes de l'outil 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

Après avoir converti le fichier manifeste à l'aide de l'outil ingress2gateway, vous obtenez 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 allez appliquer les fichiers manifestes Gateway et HTTPRoute que vous avez créés lors des deux phases précédentes, puis vérifier 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. Exécutez 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 ressource Ingress précédente vers la nouvelle passerelle en mettant à jour vos enregistrements DNS pour qu'ils pointent vers la nouvelle adresse IP de la passerelle. La procédure exacte de mise à jour des enregistrements DNS varie 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 l'ancienne adresse IP Ingress par 203.0.113.90, qui est la nouvelle adresse IP de la passerelle.

Une fois l'enregistrement DNS mis à jour, le trafic commence à passer d'Ingress à Gateway, mais le basculement ne se produit pas immédiatement pour tous les clients. Les résolveurs DNS qui possèdent déjà l'enregistrement précédent en cache attendent que la valeur TTL (Time To Live) de l'enregistrement arrive à expiration avant d'interroger à nouveau l'enregistrement et de recevoir l'adresse IP mise à jour. C'est pourquoi vous devez continuer à exécuter votre objet Ingress existant et votre nouvelle passerelle en tandem jusqu'à ce que vous vérifiiez que le trafic vers l'objet Ingress a cessé, ce qui indique que la propagation DNS est terminée et que les clients ne sont plus dirigés vers l'ancienne adresse IP. Pour le vérifier, surveillez le trafic sur votre équilibreur de charge ou votre contrôleur d&Ingress. Pour en savoir plus, consultez 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 Configurer les règles de routage DNS et les vérifications de l'état.

Nettoyer les ressources Ingress restantes

Après avoir vérifié que votre nouvelle ressource Gateway s'exécute 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 la passerelle GKE

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

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

Fonctionnalité	Annotation dans Ingress	Configuration dans la passerelle GKE	Parité
Routage basé sur l'hôte	Le champ `spec.rules.host` dans l'objet Ingress.	Le champ `hostnames` de l'objet HTTPRoute.	Parité totale.
Routage basé sur le chemin d'accès	Le champ `spec.rules.http.paths` de l'objet Ingress et l'annotation `nginx.ingress.kubernetes.io/use-regex` pour la mise en correspondance des chemins d'accès par expression régulière.	Le champ `rules.matches.path` dans l'objet HTTPRoute.	Parité totale. La passerelle GKE est compatible avec la mise en correspondance exacte, de préfixe et d'expression régulière (`RegularExpression`) pour les chemins d'accès. Vous pouvez également faire correspondre des en-têtes HTTP (`rules.matches.headers`) et des paramètres de requête (`rules.matches.queryParams`) à l'aide de valeurs exactes ou d'expressions régulières.
Répartition du trafic	`nginx.ingress.kubernetes.io/canary` annotations.	HTTPRoute avec le champ `backendRefs` pondéré.	Parité totale. De plus, vous pouvez répartir le trafic avec un contrôle précis.
Affinité de session	`nginx.ingress.kubernetes.io/affinity` et `nginx.ingress.kubernetes.io/affinity-mode`.	GCPTrafficDistributionPolicy avec le champ `sessionAffinity`.	Parité totale. La passerelle GKE est compatible avec plusieurs types d'affinité de session, y compris les types d'affinité basés sur les cookies (`HTTP_COOKIE`, `GENERATED_COOKIE` et `STRONG_COOKIE_AFFINITY` avec état), l'affinité basée sur l'en-tête (`HEADER_FIELD`) et l'affinité basée sur l'adresse IP du client (`CLIENT_IP`).
CORS (Cross-Origin Resource Sharing)	`nginx.ingress.kubernetes.io/enable-cors`	HTTPRoute avec un filtre `CORS`.	Parité totale. Remarque : La passerelle GKE impose des limites sur le nombre de modèles de caractères génériques que vous pouvez définir par écouteur ou nom d'hôte.
Réécriture d'URL	`nginx.ingress.kubernetes.io/rewrite-target`	HTTPRoute avec un filtre `urlRewrite` ou GCPHTTPFilter avec le champ `spec.urlRewrite.regexModifier`.	Parité totale. La passerelle GKE est compatible avec les remplacements de chemin d'accès complet, les remplacements de préfixe et les réécritures de chemin d'accès par expression régulière.
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é totale.
Authentification	`nginx.ingress.kubernetes.io/auth-url` pour l'authentification externe.	Identity-Aware Proxy (IAP) : ressource personnalisée GCPBackendPolicy. Autre : nécessite une approche plus personnalisée, éventuellement avec un maillage de services ou des filtres personnalisés.	Parité partielle. Identity-Aware Proxy est la méthode recommandée pour sécuriser votre passerelle. Il est configuré sur le backend.

Étapes suivantes

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