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 de la nouvelle API Gateway. Cette méthode permet de tester en profondeur la nouvelle configuration de la passerelle dans un environnement réel sans impacter 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 et 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 déployez une ressource Kubernetes Gateway 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 allez configurer un équilibreur de charge d'application externe mondial. 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 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 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

Dans cette phase, vous allez appliquer les fichiers manifestes Gateway et HTTPRoute que vous avez créés lors des deux phases précédentes, et vérifier que le trafic est bien 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'attribution de l'adresse IP peut prendre quelques minutes :
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
La sortie correspond à 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. La sortie 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 selon votre fournisseur DNS.

Par exemple, si vous avez configuré cafe.example.com dans Ingress, vous devez rechercher 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 la bascule ne se produit pas immédiatement pour tous les clients. Les résolveurs DNS qui possèdent 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 ancien Ingress et votre nouvelle passerelle en parallèle jusqu'à ce que vous vérifiiez que le trafic vers l'Ingress a cessé. Cela indique que la propagation DNS est terminée et que les clients ne sont plus redirigé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 de 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

Une fois que vous avez vérifié 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 offre un moyen plus standardisé de configurer l'entrée et présente une parité de 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 la configuration utilisée pour les fonctionnalités courantes du contrôleur Ingress et de 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.	Champ `hostnames` dans l'objet HTTPRoute.	Parité totale.
Routage basé sur le chemin d'accès	Le champ `spec.rules.http.paths` dans l'objet Ingress.	Champ `rules.matches.path` dans l'objet HTTPRoute.	Parité totale.
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	Annotations `nginx.ingress.kubernetes.io/affinity` et `nginx.ingress.kubernetes.io/affinity-mode`.	GCPTrafficDistributionPolicy avec le champ `sessionAffinity`.	Parité totale. GKE Gateway 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 les en-têtes (`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 : GKE Gateway impose des limites sur le nombre de modèles 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`.	Parité partielle. GKE Gateway n'accepte que les remplacements de préfixe.
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 Gateway.