Configura Cloud CDN para la puerta de enlace

En este documento, se describe cómo usar el controlador de puerta de enlace de Google Kubernetes Engine (GKE) para configurar Cloud CDN. Puedes encontrar información detallada sobre los conceptos, las prácticas recomendadas y la solución de problemas de Cloud CDN en la documentación de Cloud CDN.

Cloud CDN ayuda a mejorar la latencia del usuario final y reduce la carga de origen almacenando en caché el contenido cerca de los usuarios. Puedes habilitar las capacidades de almacenamiento en caché de Cloud CDN con la CustomResourceDefinition de GCPHTTPFilter.

Este documento está dirigido a desarrolladores de aplicaciones, arquitectos de nube y especialistas en redes que diseñan la red de su organización. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Cloud de Confiance , consulta Roles y tareas comunes del usuario de GKE.

Descripción general

La integración de GKE Gateway con Cloud CDN te permite usar recursos nativos de Kubernetes para administrar el almacenamiento en caché perimetral. Con el recurso GCPHTTPFilter, puedes ajustar la configuración, como los modos de caché y el tiempo de actividad (TTL) para diferentes segmentos de tu tráfico.

Para habilitar Cloud CDN, crea un objeto GCPHTTPFilter y haz referencia a él en una regla HTTPRoute. Puedes crear varios objetos GCPHTTPFilter para definir diferentes comportamientos de almacenamiento en caché para diferentes tipos de tráfico. Por ejemplo, puedes crear un filtro para las imágenes estáticas y otro para una política predeterminada que use los valores predeterminados recomendados de Cloud CDN.

El recurso GCPHTTPFilter te permite configurar lo siguiente:

  • Modos de almacenamiento en caché: Controlan cómo Cloud CDN almacena en caché las respuestas de tu origen.
  • Configuración del tiempo de actividad (TTL): Configura cuánto tiempo permanecen los objetos en la caché.
  • Claves de caché: Definen qué elementos de una solicitud (encabezados, cookies, cadenas de consulta) se usan para generar claves de caché.
  • Almacenamiento en caché negativo: Almacena en caché las respuestas de error comunes o los redireccionamientos para reducir la carga del origen durante las fallas.
  • Políticas de caché: Controlan cómo Cloud CDN controla tus solicitudes almacenables en caché. Por ejemplo, puedes habilitar Cloud CDN para hacer lo siguiente:
    • Mantener la alta disponibilidad, ya que se sigue entregando contenido almacenado en caché incluso si los servicios de backend dejan de estar disponibles
    • Define encabezados de solicitud específicos que omitan la caché para recuperar datos directamente desde tu backend.
    • Combina varias solicitudes simultáneas para el mismo recurso en una sola solicitud para reducir la carga del backend.

El recurso GCPHTTPFilter debe estar en el mismo espacio de nombres que el recurso HTTPRoute al que está adjunto. Después de configurar GCPHTTPFilter, el filtro se combina en la cadena de filtros de tu ruta.

En el siguiente diagrama, se ilustra cómo puedes usar GCPHTTPFilter para aplicar diferentes configuraciones de almacenamiento en caché a segmentos específicos del tráfico dentro de un HTTPRoute:

Figura 1. Diferentes configuraciones de almacenamiento en caché realizadas con GCPHTTPFilter dentro de un HTTPRoute.
Figura 1. Son las configuraciones de almacenamiento en caché dentro de un HTTPRoute.

Esta arquitectura te permite configurar una administración detallada y automatizada del almacenamiento en caché perimetral. Un objeto HTTPRoute configura cómo se controlan las solicitudes entrantes haciendo coincidir el tráfico entrante según los atributos, como la ruta de la solicitud. Para habilitar el almacenamiento en caché de rutas específicas, se adjuntan GCPHTTPFilters a las reglas dentro de HTTPRoute. Cada GCPHTTPFilter puede especificar una lógica de almacenamiento en caché diferente para las imágenes, los recursos web y el resto del contenido. Luego, Cloud CDN aplica esta lógica de almacenamiento en caché y entrega el contenido almacenado en caché al cliente.

Requisitos y limitaciones

  • Tu clúster debe estar en la versión 1.35.2-gke.1751000 de GKE o una posterior.
  • Debes haber configurado una puerta de enlace externa global con la GatewayClass gke-l7-global-external-managed o gke-l7-global-external-managed-mc.
  • Debes haber configurado un recurso HTTPRoute.
  • No puedes habilitar Identity-Aware Proxy (IAP) y Cloud CDN en la misma puerta de enlace. Si se requiere IAP, debes quitar el objeto GCPHTTPFilter antes de habilitar GCPBackendPolicy.
  • Solo puedes adjuntar un objeto GCPHTTPFilter a una regla de ruta específica dentro de un objeto HTTPRoute.

Precios

Se aplican los precios de Cloud CDN cuando se habilita el almacenamiento en caché. Para obtener más información, consulta Precios de Cloud CDN.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se indican en este documento.

Roles y permisos

  1. Para ver los recursos Cloud de Confiance configurados, asegúrate de tener el rol de IAMroles/compute.networkViewer.

  2. Asegúrate de tener acceso al clúster de GKE y de estar autorizado para realizar las acciones necesarias. En el siguiente fragmento, se muestran los permisos de RBAC mínimos requeridos:

    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"]
    

Para obtener más información sobre el uso de RBAC y IAM, consulta Interacción con Identity and Access Management.

Configura el almacenamiento en caché con GCPHTTPFilter

Para habilitar y configurar Cloud CDN, crea uno o más recursos de GCPHTTPFilter y, luego, haz referencia a ellos en tu objeto HTTPRoute.

Crea un GCPHTTPFilter

El recurso GCPHTTPFilter define tu política de almacenamiento en caché. En el siguiente ejemplo, se crean tres GCPHTTPFilters:

  • El primer filtro almacena en caché las imágenes estáticas para acelerar la entrega a los usuarios finales.
  • El segundo filtro almacena en caché los recursos web, como los archivos CSS.
  • El tercer filtro sirve como un "comodín" para el tráfico restante.
  1. Para crear el primer filtro, guarda el siguiente manifiesto como 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
    

    En este manifiesto, se aplican las siguientes condiciones:

    • includeQueryString: Indica a Cloud CDN que ignore los parámetros de consulta en la clave de caché. Esto ayuda a garantizar que las diferentes solicitudes de los usuarios para la misma imagen reciban copias idénticas almacenadas en caché.
    • cacheMode: Se establece en CACHE_ALL_STATIC, que almacena en caché automáticamente el contenido estático, como las imágenes.
    • defaultTTL: Indica a Cloud CDN que almacene en caché las imágenes durante 12 horas. Puedes especificar el tiempo en horas (h), minutos (m) o segundos (s).
  2. Crea el segundo filtro. Guarda el siguiente manifiesto como 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
    

    Este manifiesto tiene algunos de los mismos parámetros de configuración que el primer filtro, excepto por las siguientes diferencias:

    • serveWhileStale: Se establece en 24 horas. Si un recurso web (como un archivo CSS) vence después de su defaultTTL, Cloud CDN sigue entregando ese recurso inactivo desde la caché durante un máximo de 24 horas adicionales y vuelve a validar el contenido en segundo plano.
    • defaultTTL: Se establece en una duración más larga de 24 horas.
  3. Crea un tercer filtro para definir una política de almacenamiento en caché predeterminada sin parámetros. Guarda el siguiente manifiesto como store-caching-default-filter.yaml:

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

    Cuando no especificas ningún parámetro en tu recurso GCPHTTPFilter, GKE usa los valores predeterminados para el almacenamiento en caché.

  4. Aplica los filtros a tu clúster:

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

Adjunta el filtro a una HTTPRoute

Para aplicar las políticas de almacenamiento en caché, actualiza tu manifiesto de HTTPRoute existente para hacer referencia a los filtros.

Puedes hacer referencia a diferentes filtros dentro del mismo objeto HTTPRoute para aplicar reglas de almacenamiento en caché coherentes. También puedes volver a usar el mismo filtro en diferentes reglas, por ejemplo, cuando divides el tráfico entre diferentes versiones de backend durante un lanzamiento progresivo.

  1. Modifica tu manifiesto de HTTPRoute existente (por ejemplo, store-route-external.yaml) para incluir la sección filters en tus reglas de enrutamiento:

    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. Aplica la configuración actualizada de HTTPRoute a tu clúster:

    kubectl apply -f store-route-external.yaml
    
  3. Verifica que se hayan implementado la HTTPRoute y la puerta de enlace:

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

    El resultado muestra que Cloud CDN está habilitado para el recurso HTTPRoute. Cloud CDN aplica las políticas de almacenamiento en caché configuradas a tu tráfico y acelera la entrega de imágenes estáticas, recursos web y otro tráfico.

Invalida contenido almacenado en caché

Para purgar el contenido obsoleto de la caché, debes enviar una solicitud de invalidación. Para obtener información detallada sobre cómo funciona la invalidación, consulta Invalida contenido almacenado en caché en la documentación de Cloud CDN.

  1. Busca el mapa de URL asociado con tu puerta de enlace:

    kubectl describe gateway external-http
    

    Busca la anotación networking.gke.io/url-maps. Por ejemplo:

    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. Puedes invalidar el contenido con varios comparadores de invalidación, incluidos el host, la ruta de acceso, las etiquetas de caché, el código de estado de la respuesta, el tipo de MIME y el backend. Por ejemplo, para enviar la solicitud de invalidación con los comparadores de host y código de estado, ejecuta el siguiente comando:

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

    Reemplaza URL_MAP_NAME por el nombre identificado en el paso anterior, por ejemplo, gkegw-url-map1.

Supervisa el rendimiento de Cloud CDN

Puedes usar Cloud Logging y Cloud Monitoring para hacer un seguimiento de las tasas de acierto de caché y el rendimiento.

Los registros de Cloud CDN están asociados con el balanceador de cargas aprovisionado por tu GKE Gateway Controller. Los registros se indexan según la regla de reenvío y el mapa de URL del balanceador de cargas. Para recuperar los registros recientes, ejecuta el siguiente comando:

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 exporta métricas a Cloud Monitoring. Puedes usar el filtro matched_url_path_rule en tus consultas de supervisión para limitar las métricas a una HTTPRoute específica.

Para obtener más información sobre cómo ver los registros y la supervisión de Cloud CDN, consulta Registros y métricas para el almacenamiento en caché.

Inhabilita Cloud CDN

Para inhabilitar el almacenamiento en caché, quita las referencias a GCPHTTPFilter de tu HTTPRoute.

  1. Edita tu manifiesto HTTPRoute y quita el bloque filters que hace referencia a GCPHTTPFilter. En el siguiente ejemplo, se muestra un manifiesto de HTTPRoute con los filtros quitados:

    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. Aplica el manifiesto de HTTPRoute actualizado a tu clúster:

    kubectl apply -f store-route-external.yaml
    

¿Qué sigue?