Configurer Cloud CDN pour Gateway

Ce document explique comment utiliser le contrôleur de passerelle Google Kubernetes Engine (GKE) pour configurer Cloud CDN. Vous trouverez des informations détaillées sur les concepts, les bonnes pratiques et le dépannage de Cloud CDN dans la documentation Cloud CDN.

Cloud CDN permet d'améliorer la latence côté utilisateur et de réduire la charge d'origine en mettant en cache le contenu à proximité de vos utilisateurs. Vous pouvez activer les fonctionnalités de mise en cache de Cloud CDN à l'aide de la définition de ressource personnalisée GCPHTTPFilter.

Ce document s'adresse aux développeurs d'applications, aux architectes cloud et aux spécialistes de la mise en réseau qui conçoivent et implémentent le réseau de leur organisation. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Cloud de Confiance , consultez Rôles utilisateur et tâches courantes de GKE.

Présentation

L'intégration de GKE Gateway à Cloud CDN vous permet d'utiliser des ressources Kubernetes natives pour gérer la mise en cache en périphérie. En utilisant la ressource GCPHTTPFilter, vous pouvez affiner les configurations telles que les modes de cache et la valeur TTL (Time To Live) pour différentes tranches de votre trafic.

Pour activer Cloud CDN, créez un objet GCPHTTPFilter et faites référence à l'objet dans une règle HTTPRoute. Vous pouvez créer plusieurs objets GCPHTTPFilter pour définir différents comportements de mise en cache pour différents types de trafic. Par exemple, vous pouvez créer un filtre pour les images statiques et un autre pour une règle par défaut qui utilise les valeurs par défaut recommandées de Cloud CDN.

La ressource GCPHTTPFilter vous permet de configurer les éléments suivants :

  • Modes de cache : ils contrôlent la façon dont Cloud CDN met en cache les réponses de votre origine.
  • Configuration de la durée de vie (TTL) : configurez la durée pendant laquelle les objets restent dans le cache.
  • Clés de cache : définissez les éléments d'une requête (en-têtes, cookies, chaînes de requête) utilisés pour générer des clés de cache.
  • Mise en cache négative : mettez en cache les réponses d'erreur ou les redirections courantes pour réduire la charge d'origine en cas d'échec.
  • Les stratégies de cache contrôlent la façon dont Cloud CDN gère vos requêtes pouvant être mises en cache. Par exemple, vous pouvez activer Cloud CDN pour effectuer les opérations suivantes :
    • Maintenez une haute disponibilité en continuant à diffuser du contenu mis en cache, même si les services de backend deviennent indisponibles.
    • Définissez des en-têtes de requête spécifiques qui contournent le cache pour récupérer les données directement depuis votre backend.
    • Fusionnez plusieurs requêtes simultanées pour la même ressource en une seule requête afin de réduire la charge du backend.

La ressource GCPHTTPFilter doit se trouver dans le même espace de noms que la ressource HTTPRoute à laquelle elle est associée. Une fois que vous avez configuré GCPHTTPFilter, le filtre est fusionné dans la chaîne de filtres de votre route.

Le schéma suivant montre comment utiliser GCPHTTPFilter pour appliquer différentes configurations de mise en cache à des tranches de trafic spécifiques dans une HTTPRoute :

Figure 1. Différentes configurations de mise en cache effectuées avec GCPHTTPFilter dans une HTTPRoute.
Figure 1. Configurations de mise en cache dans une HTTPRoute.

Cette architecture vous permet de configurer une gestion précise et automatisée de la mise en cache en périphérie. Une ressource HTTPRoute configure la manière dont les requêtes entrantes sont traitées en faisant correspondre le trafic entrant en fonction d'attributs tels que le chemin de la requête. Pour activer la mise en cache pour des routes spécifiques, des GCPHTTPFilters sont associés aux règles de l'HTTPRoute. Chaque GCPHTTPFilter peut spécifier une logique de mise en cache différente pour les images, les composants Web et les autres contenus. Cette logique de mise en cache est ensuite appliquée par Cloud CDN, qui diffuse le contenu mis en cache au client.

Conditions requises et limites

  • Votre cluster doit utiliser GKE version 1.35.2-gke.1751000 ou ultérieure.
  • Vous devez avoir configuré une passerelle externe globale à l'aide de la GatewayClass gke-l7-global-external-managed ou gke-l7-global-external-managed-mc.
  • Vous devez avoir configuré une ressource HTTPRoute.
  • Vous ne pouvez pas activer à la fois Identity-Aware Proxy (IAP) et Cloud CDN sur la même passerelle. Si IAP est requis, vous devez supprimer l'objet GCPHTTPFilter avant d'activer GCPBackendPolicy.
  • Vous ne pouvez associer qu'un seul objet GCPHTTPFilter à une règle de chemin d'accès spécifique dans une HTTPRoute.

Tarifs

La tarification de Cloud CDN s'applique lorsque la mise en cache est activée. Pour en savoir plus, consultez les tarifs de Cloud CDN.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Pour utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Rôles et autorisations

  1. Pour afficher les ressources Cloud de Confiance configurées, assurez-vous de disposer du rôle IAM roles/compute.networkViewer.

  2. Assurez-vous d'avoir accès au cluster GKE et d'être autorisé à effectuer les actions nécessaires. L'extrait suivant montre les autorisations RBAC minimales requises :

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: gateway-caching-admin
    rules:
    # 1. Full access to manage HTTPRoutes
    - apiGroups: ["gateway.networking.k8s.io"]
      resources: ["httproutes"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    # 2. Read-only access to view the Gateway
    - apiGroups: ["gateway.networking.k8s.io"]
      resources: ["gateways"]
      verbs: ["get", "list", "watch"]
    # 3. Full access to manage caching filters
    - apiGroups: ["networking.gke.io"]
      resources: ["gcphttpfilters"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    

Pour en savoir plus sur l'utilisation de RBAC et d'IAM, consultez Interaction avec Identity and Access Management.

Configurer la mise en cache avec GCPHTTPFilter

Pour activer et configurer Cloud CDN, vous devez créer une ou plusieurs ressources GCPHTTPFilter, puis les référencer dans votre objet HTTPRoute.

Créer un GCPHTTPFilter

La ressource GCPHTTPFilter définit votre règle de mise en cache. Dans l'exemple suivant, vous allez créer trois GCPHTTPFilters :

  • Le premier filtre met en cache les images statiques pour les diffuser plus rapidement aux utilisateurs finaux.
  • Le deuxième filtre met en cache les composants Web tels que les fichiers CSS.
  • Le troisième filtre sert de "fourre-tout" pour le trafic restant.
  1. Créez le premier filtre en enregistrant le fichier manifeste suivant sous le nom store-caching-images-filter.yaml :

    apiVersion: networking.gke.io/v1
    kind: GCPHTTPFilter
    metadata:
      name: store-caching-images-filter
    spec:
      cachePolicy:
        cacheKeyPolicy:
          includeQueryString: false
        cacheMode: CACHE_ALL_STATIC
        defaultTTL: 12h
    

    Dans ce fichier manifeste, les éléments suivants s'appliquent :

    • includeQueryString : indique à Cloud CDN d'ignorer les paramètres de requête dans la clé de cache. Cela permet de s'assurer que différentes requêtes utilisateur pour la même image reçoivent des copies identiques mises en cache.
    • cacheMode est défini sur CACHE_ALL_STATIC, ce qui met automatiquement en cache le contenu statique tel que les images.
    • defaultTTL : indique à Cloud CDN de mettre en cache les images pendant 12 heures. Vous pouvez spécifier la durée en heures (h), en minutes (m) ou en secondes (s).
  2. Créez le deuxième filtre. Enregistrez le manifeste suivant sous le nom store-caching-webassets-filter.yaml :

    apiVersion: networking.gke.io/v1
    kind: GCPHTTPFilter
    metadata:
      name: store-caching-webassets-filter
    spec:
      cachePolicy:
        cacheKeyPolicy:
          includeQueryString: false
        serveWhileStale: 24h
        cacheMode: CACHE_ALL_STATIC
        defaultTTL: 24h
    

    Ce fichier manifeste comporte certains des mêmes paramètres que le premier filtre, à l'exception des différences suivantes :

    • serveWhileStale : est défini sur 24 heures. Si un élément Web (tel qu'un fichier CSS) expire après son defaultTTL, Cloud CDN continue de diffuser cet élément obsolète à partir du cache pendant 24 heures supplémentaires au maximum et revalide le contenu en arrière-plan.
    • defaultTTL : est définie sur une durée plus longue de 24 heures.
  3. Créez un troisième filtre pour définir une règle de mise en cache par défaut sans aucun paramètre. Enregistrez le manifeste suivant sous le nom store-caching-default-filter.yaml :

    apiVersion: networking.gke.io/v1
    kind: GCPHTTPFilter
    metadata:
      name: store-caching-default-filter
    spec:
      cachePolicy: {}
    

    Lorsque vous ne spécifiez aucun paramètre dans votre ressource GCPHTTPFilter, GKE utilise les valeurs par défaut pour la mise en cache.

  4. Appliquez les filtres à votre cluster :

    kubectl apply -f store-caching-images-filter.yaml
    kubectl apply -f store-caching-webassets-filter.yaml
    kubectl apply -f store-caching-default-filter.yaml
    

Associer le filtre à une route HTTPRoute

Pour appliquer les règles de mise en cache, mettez à jour votre fichier manifeste HTTPRoute existant afin de référencer les filtres.

Vous pouvez faire référence à différents filtres dans le même objet HTTPRoute pour appliquer des règles de mise en cache cohérentes. Vous pouvez également réutiliser le même filtre dans différentes règles, par exemple lorsque vous répartissez le trafic entre différentes versions de backend lors d'un déploiement progressif.

  1. Modifiez votre fichier manifeste HTTPRoute existant (par exemple, store-route-external.yaml) pour inclure la section filters dans vos règles de routage :

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1
    metadata:
      name: store-external
    spec:
      parentRefs:
      - kind: Gateway
        name: external-http
      hostnames:
      - "store.example.com"
      rules:
      # RULE 1: Default /img/ traffic to store-v1
      - matches:
        - path:
            value: /img/
        filters:
        - type: ExtensionRef
          extensionRef:
            group: networking.gke.io
            kind: GCPHTTPFilter
            name: store-caching-images-filter
        backendRefs:
        - name: store-v1
          port: 8080
      # RULE 2: Default /web/ traffic to store-v1
      - matches:
        - path:
            value: /web/
        filters:
        - type: ExtensionRef
          extensionRef:
            group: networking.gke.io
            kind: GCPHTTPFilter
            name: store-caching-webassets-filter
        backendRefs:
        - name: store-v1
          port: 8080
      # RULE 3: Canary /img/ traffic (header + path match) to store-v2
      - matches:
        - headers:
          - name: env
            value: canary
          path:
            value: /img/
        filters:
        - type: ExtensionRef
          extensionRef:
            group: networking.gke.io
            kind: GCPHTTPFilter
            name: store-caching-images-filter
        backendRefs:
        - name: store-v2
          port: 8080
      # RULE 4: Canary /web/ traffic (header + path match) to store-v2
      - matches:
        - headers:
          - name: env
            value: canary
          path:
            value: /web/
        filters:
        - type: ExtensionRef
          extensionRef:
            group: networking.gke.io
            kind: GCPHTTPFilter
            name: store-caching-webassets-filter
        backendRefs:
        - name: store-v2
          port: 8080
      # RULE 5: Default (catch-all) traffic to store-v1
      - backendRefs:
        - name: store-v1
          port: 8080
        # If you need caching for default traffic, it can be enabled by placing
        # filters directly under backendRefs
        filters:
        - type: ExtensionRef
          extensionRef:
            group: networking.gke.io
            kind: GCPHTTPFilter
            name: store-caching-default-filter
    
  2. Appliquez la configuration HTTPRoute mise à jour à votre cluster :

    kubectl apply -f store-route-external.yaml
    
  3. Vérifiez que HTTPRoute et Gateway sont déployés :

    kubectl describe httproute store-external
    kubectl describe gateway external-http
    

    Le résultat montre que Cloud CDN est activé pour la ressource HTTPRoute. Cloud CDN applique les règles de mise en cache configurées à votre trafic et accélère la diffusion des images statiques, des éléments Web et d'autres types de trafic.

Invalider du contenu mis en cache

Pour supprimer du contenu obsolète du cache, vous devez envoyer une demande d'invalidation. Pour en savoir plus sur le fonctionnement de l'invalidation, consultez Invalider un contenu mis en cache dans la documentation Cloud CDN.

  1. Recherchez le mappage d'URL associé à votre passerelle :

    kubectl describe gateway external-http
    

    Recherchez l'annotation networking.gke.io/url-maps. Exemple :

    Name: external-http
    Namespace: foo
    API Version: gateway.networking.k8s.io
    Kind: Gateway
    Annotations: networking.gke.io/backend-services: gkegw-service1
                 networking.gke.io/firewalls: gkegw-l7-fw
                 networking.gke.io/forwarding-rules: gkegw-fr1
                 networking.gke.io/health-checks: gkegw-hc1
                 networking.gke.io/ssl-certificates:
                 networking.gke.io/target-proxies: gkegw-tp1
                 networking.gke.io/url-maps: gkegw-url-map1
    
  2. Vous pouvez invalider du contenu à l'aide de plusieurs critères de correspondance pour l'invalidation, y compris l'hôte, le chemin d'accès, les tags de cache, le code d'état de la réponse, le type MIME et le backend. Par exemple, pour envoyer la demande d'invalidation à l'aide des comparateurs d'hôte et de code d'état, exécutez la commande suivante :

    gcloud compute url-maps invalidate-cdn-cache URL_MAP_NAME
        --host="store.example.com" 
        --status=404
    

    Remplacez URL_MAP_NAME par le nom identifié à l'étape précédente, par exemple gkegw-url-map1.

Surveiller les performances de Cloud CDN

Vous pouvez utiliser Cloud Logging et Cloud Monitoring pour suivre les taux de succès de cache (hit) et les performances.

Les journaux Cloud CDN sont associés à l'équilibreur de charge provisionné par votre GKE Gateway Controller. Les journaux sont indexés par la règle de transfert et le mappage d'URL de l'équilibreur de charge. Pour récupérer les journaux récents, exécutez la commande suivante :

gcloud logging read 'resource.type="http_load_balancer" AND 
    resource.labels.url_map_name="URL_MAP_NAME" AND 
    logName="projects/PROJECT_ID/logs/cloudcdn_googleapis_com%2Frequests"' 
    --project PROJECT_ID --limit 100 --format json

Cloud CDN exporte les métriques vers Cloud Monitoring. Vous pouvez utiliser le filtre matched_url_path_rule dans vos requêtes de surveillance pour limiter les métriques à une route HTTP spécifique.

Pour en savoir plus sur l'affichage des journaux et la surveillance de Cloud CDN, consultez Journaux et métriques pour la mise en cache.

Désactiver Cloud CDN

Pour désactiver la mise en cache, supprimez les références GCPHTTPFilter de votre HTTPRoute.

  1. Modifiez votre fichier manifeste HTTPRoute et supprimez le bloc filters qui fait référence à GCPHTTPFilter. L'exemple suivant montre un fichier manifeste HTTPRoute sans les filtres :

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1
    metadata:
      name: store-external
    spec:
      parentRefs:
      - kind: Gateway
        name: external-http
      hostnames:
      - "store.example.com"
      rules:
      # RULE 1: Default /img/ traffic to store-v1
      - matches:
        - path:
            value: /img/
        backendRefs:
        - name: store-v1
          port: 8080
      # RULE 2: Canary /img/ traffic (header match) to store-v2
      - matches:
        - headers:
          - name: env
            value: canary
          path:
            value: /img/
        backendRefs:
        - name: store-v2
          port: 8080
      # RULE 3: Default (catch-all) traffic to store-v1
      - backendRefs:
        - name: store-v1
          port: 8080
    
  2. Appliquez le fichier manifeste HTTPRoute mis à jour à votre cluster :

    kubectl apply -f store-route-external.yaml
    

Étapes suivantes