Cette page a été traduite par l'API Cloud Translation.

Migrer Ingress vers l'API Gateway

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

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 votre configuration d'API Ingress existante et la nouvelle configuration d'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. Une fois la nouvelle configuration de passerelle validée, vous pouvez effectuer un basculement DNS rapide pour rediriger le trafic vers l'API Gateway. Cela vous aidera à 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 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 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

Une fois le fichier manifeste converti à 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

Dans cette phase, vous allez appliquer les 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'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 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 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 ancien Ingress 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 modification 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 correspond à la nouvelle adresse IP de la passerelle.

Une fois l'enregistrement DNS mis à jour, le trafic commence à passer d'Ingress à Gateway, mais la transition 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. 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é, ce qui 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, vous pouvez surveiller 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

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 les annotations utilisées pour les fonctionnalités courantes du contrôleur Ingress et de 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é totale.
Routage basé sur le chemin d'accès	`spec.rules.http.paths` dans l'objet Ingress.	`rules.matches.path` dans l'objet HTTPRoute.	Parité totale.
Routage basé sur l'hôte	`spec.rules.host` dans l'objet Ingress.	`hostnames` dans l'objet HTTPRoute.	Parité totale.
Répartition du trafic	`nginx.ingress.kubernetes.io/canary` annotations.	`HTTPRoute` avec une pondération de `backendRefs`.	Parité totale. 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`. 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.