Cloud CDN für Gateway konfigurieren

In diesem Dokument wird beschrieben, wie Sie den GKE-Gateway-Controller (Google Kubernetes Engine) verwenden, um Cloud CDN zu konfigurieren. Ausführliche Informationen zu Cloud CDN-Konzepten, Best Practices und Fehlerbehebung finden Sie in der Cloud CDN-Dokumentation.

Cloud CDN trägt dazu bei, die Latenz für Endnutzer zu verringern und die Last auf den Ursprungsserver zu reduzieren, indem Inhalte in der Nähe der Nutzer im Cache gespeichert werden. Sie können Cloud CDN-Cachingfunktionen mit der CustomResourceDefinition GCPHTTPFilter aktivieren.

Dieses Dokument richtet sich an Anwendungsentwickler, Cloud-Architekten und Netzwerkspezialisten, die das Netzwerk ihrer Organisation entwerfen und erstellen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Cloud de Confiance Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Übersicht

Durch die Integration von GKE Gateway in Cloud CDN können Sie Kubernetes-native Ressourcen verwenden, um das Edge-Caching zu verwalten. Mit der GCPHTTPFilter-Ressource können Sie Konfigurationen wie Cache-Modi und Gültigkeitsdauer (Time-to-Live, TTL) für verschiedene Traffic-Segmente optimieren.

Sie aktivieren Cloud CDN, indem Sie ein GCPHTTPFilter-Objekt erstellen und in einer HTTPRoute-Regel darauf verweisen. Sie können mehrere GCPHTTPFilter-Objekte erstellen, um unterschiedliche Caching-Verhaltensweisen für verschiedene Arten von Traffic zu definieren. Sie können beispielsweise einen Filter für statische Bilder und einen anderen für eine Standardrichtlinie erstellen, die die von Cloud CDN empfohlenen Standardwerte verwendet.

Mit der GCPHTTPFilter-Ressource können Sie Folgendes konfigurieren:

  • Cache-Modi: Steuern, wie Cloud CDN Antworten von Ihrem Ursprungsserver im Cache speichert.
  • Konfiguration der Gültigkeitsdauer (Time to Live, TTL): Konfigurieren Sie, wie lange Objekte im Cache verbleiben.
  • Cache-Schlüssel: Hier wird definiert, welche Elemente einer Anfrage (Header, Cookies, Abfragestrings) zum Generieren von Cache-Schlüsseln verwendet werden.
  • Negatives Caching: Häufige Fehlerantworten oder Weiterleitungen im Cache speichern, um die Belastung des Ursprungs bei Fehlern zu verringern.
  • Cache-Richtlinien: Mit ihnen wird gesteuert, wie Cloud CDN Ihre cachefähigen Anfragen verarbeitet. Sie können Cloud CDN beispielsweise für Folgendes aktivieren:
    • Hohe Verfügbarkeit aufrechterhalten, indem weiterhin im Cache gespeicherte Inhalte bereitgestellt werden, auch wenn Back-End-Dienste nicht mehr verfügbar sind.
    • Definieren Sie bestimmte Anfrageheader, die den Cache umgehen, um Daten direkt von Ihrem Backend abzurufen.
    • Führen Sie mehrere gleichzeitige Anfragen für dieselbe Ressource zu einer einzigen Anfrage zusammen, um die Backend-Last zu reduzieren.

Die GCPHTTPFilter-Ressource muss sich im selben Namespace wie die HTTPRoute-Ressource befinden, an die sie angehängt ist. Nachdem Sie GCPHTTPFilter konfiguriert haben, wird der Filter in die Filterkette für Ihre Route eingefügt.

Das folgende Diagramm veranschaulicht, wie Sie mit GCPHTTPFilter verschiedene Caching-Konfigurationen auf bestimmte Traffic-Slices innerhalb einer HTTPRoute anwenden können:

Abbildung 1: Unterschiedliche Caching-Konfigurationen, die mit GCPHTTPFilter in einer HTTPRoute vorgenommen wurden.
Abbildung 1. Caching-Konfigurationen in einer HTTPRoute

Diese Architektur ermöglicht die Konfiguration einer detaillierten, automatisierten Edge-Caching-Verwaltung. Eine HTTPRoute konfiguriert, wie eingehende Anfragen verarbeitet werden, indem der eingehende Traffic anhand von Attributen wie dem Anfragepfad abgeglichen wird. Um das Caching für bestimmte Routen zu aktivieren, werden GCPHTTPFilters an die Regeln in der HTTPRoute angehängt. Für jeden GCPHTTPFilter kann eine andere Caching-Logik für Bilder, Web-Assets und andere Inhalte angegeben werden. Diese Caching-Logik wird dann von Cloud CDN erzwungen, das die im Cache gespeicherten Inhalte an den Client sendet.

Anforderungen und Einschränkungen

  • Ihr Cluster muss die GKE-Version 1.35.2-gke.1751000 oder höher haben.
  • Sie müssen ein globales externes Gateway mit der GatewayClass gke-l7-global-external-managed oder gke-l7-global-external-managed-mc konfiguriert haben.
  • Sie müssen eine HTTPRoute-Ressource konfiguriert haben.
  • Sie können nicht sowohl Identity-Aware Proxy (IAP) als auch Cloud CDN für dasselbe Gateway aktivieren. Wenn IAP erforderlich ist, müssen Sie das GCPHTTPFilter-Objekt entfernen, bevor Sie GCPBackendPolicy aktivieren.
  • Sie können nur ein GCPHTTPFilter-Objekt an eine bestimmte Pfadregel in einer HTTPRoute anhängen.

Preise

Die Cloud CDN-Preise gelten, wenn das Caching aktiviert ist. Weitere Informationen finden Sie unter Cloud CDN-Preise.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Rollen und Berechtigungen

  1. Wenn Sie konfigurierte Cloud de Confiance -Ressourcen aufrufen möchten, benötigen Sie die roles/compute.networkViewer-IAM-Rolle.

  2. Achten Sie darauf, dass Sie Zugriff auf den GKE-Cluster haben und berechtigt sind, die erforderlichen Aktionen auszuführen. Das folgende Snippet zeigt die minimal erforderlichen RBAC-Berechtigungen:

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

Weitere Informationen zur Verwendung von RBAC und IAM finden Sie unter Interaktion mit Identity and Access Management.

Caching mit GCPHTTPFilter konfigurieren

Um Cloud CDN zu aktivieren und zu konfigurieren, erstellen Sie eine oder mehrere GCPHTTPFilter-Ressourcen und verweisen dann in Ihrem HTTPRoute-Objekt darauf.

GCPHTTPFilter erstellen

Die GCPHTTPFilter-Ressource definiert Ihre Caching-Richtlinie. Im folgenden Beispiel erstellen Sie drei GCPHTTPFilters:

  • Der erste Filter speichert statische Bilder im Cache, damit sie schneller an Endnutzer gesendet werden können.
  • Der zweite Filter speichert Web-Assets wie CSS-Dateien im Cache.
  • Der dritte Filter dient als „Auffangbecken“ für den verbleibenden Traffic.

  1. Erstellen Sie den ersten Filter, indem Sie das folgende Manifest als store-caching-images-filter.yaml speichern:

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

    In diesem Manifest gilt Folgendes:

    • includeQueryString: weist Cloud CDN an, Abfrageparameter im Cache-Schlüssel zu ignorieren. So wird sichergestellt, dass verschiedene Nutzeranfragen für dasselbe Bild identische Kopien aus dem Cache erhalten.
    • cacheMode: ist auf CACHE_ALL_STATIC gesetzt, wodurch statische Inhalte wie Bilder automatisch im Cache gespeichert werden.
    • defaultTTL: weist Cloud CDN an, Bilder 12 Stunden lang im Cache zu speichern. Sie können die Zeit in Stunden (h), Minuten (m) oder Sekunden (s) angeben.

  2. Erstellen Sie den zweiten Filter. Speichern Sie das folgende Manifest als 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

    Dieses Manifest hat einige der gleichen Einstellungen wie der erste Filter, mit den folgenden Unterschieden:

    • serveWhileStale: ist auf 24 Stunden festgelegt. Wenn ein Web-Asset (z. B. eine CSS-Datei) nach Ablauf von defaultTTL abläuft, stellt Cloud CDN dieses alte Asset bis zu 24 Stunden lang weiterhin aus dem Cache bereit und validiert den Inhalt im Hintergrund neu.
    • defaultTTL: Die Dauer ist auf 24 Stunden festgelegt.

  3. Erstellen Sie einen dritten Filter, um eine Standard-Caching-Richtlinie ohne Parameter zu definieren. Speichern Sie das folgende Manifest als store-caching-default-filter.yaml:

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

    Wenn Sie in Ihrer GCPHTTPFilter-Ressource keine Parameter angeben, verwendet GKE die Standardwerte für das Caching.

  4. Wenden Sie die Filter auf Ihren Cluster an:

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

Filter an eine HTTPRoute anhängen

Um die Caching-Richtlinien anzuwenden, aktualisieren Sie Ihr vorhandenes HTTPRoute-Manifest, damit auf die Filter verwiesen wird.

Sie können im selben HTTPRoute-Objekt auf verschiedene Filter verweisen, um einheitliche Caching-Regeln anzuwenden. Sie können denselben Filter auch für verschiedene Regeln wiederverwenden, z. B. wenn Sie Zugriffe während eines progressiven Rollouts auf verschiedene Back-End-Versionen aufteilen.

  1. Ändern Sie Ihr vorhandenes HTTPRoute-Manifest (z. B. store-route-external.yaml), um den Abschnitt filters in Ihre Routingregeln aufzunehmen:

    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. Wenden Sie die aktualisierte HTTPRoute-Konfiguration auf Ihren Cluster an:

    kubectl apply -f store-route-external.yaml

  3. Prüfen Sie, ob die HTTPRoute und das Gateway bereitgestellt wurden:

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

    Die Ausgabe zeigt, dass Cloud CDN für die HTTPRoute-Ressource aktiviert ist. Cloud CDN wendet die konfigurierten Caching-Richtlinien auf Ihren Traffic an und beschleunigt die Bereitstellung von statischen Bildern, Web-Assets und anderem Traffic.

Im Cache gespeicherte Inhalte entwerten

Wenn Sie veraltete Inhalte aus dem Cache entfernen möchten, müssen Sie einen Entwertungsantrag stellen. Ausführliche Informationen zur Funktionsweise der Entwertung finden Sie in der Cloud CDN-Dokumentation unter Cache-Inhalte entwerten.

  1. Suchen Sie die URL-Zuordnung, die Ihrem Gateway zugeordnet ist:

    kubectl describe gateway external-http

    Suchen Sie nach der Annotation networking.gke.io/url-maps. Beispiel:

    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. Sie können Inhalte mithilfe verschiedener Invalidierungsabgleichsfunktionen ungültig machen, darunter Host, Pfad, Cache-Tags, Antwortstatuscode, MIME-Typ und Back-End. Wenn Sie beispielsweise die Invalidierungsanfrage mit den Host- und Statuscode-Matcher einreichen möchten, führen Sie den folgenden Befehl aus:

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

    Ersetzen Sie URL_MAP_NAME durch den Namen aus dem vorherigen Schritt, z. B. gkegw-url-map1.

Cloud CDN-Leistung überwachen

Mit Cloud Logging und Cloud Monitoring können Sie Cache-Trefferraten und Leistung verfolgen.

Cloud CDN-Logs sind mit dem Load Balancer verknüpft, der von Ihrem GKE Gateway Controller bereitgestellt wird. Die Logs werden nach der Weiterleitungsregel und der URL-Zuordnung des Load-Balancers indexiert. Führen Sie den folgenden Befehl aus, um aktuelle Logs abzurufen:

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 exportiert Messwerte in Cloud Monitoring. Mit dem Filter matched_url_path_rule in Ihren Monitoring-Abfragen können Sie Messwerte auf eine bestimmte HTTPRoute eingrenzen.

Weitere Informationen zum Aufrufen von Logs und Monitoring für Cloud CDN finden Sie unter Logs und Messwerte für das Caching.

Cloud CDN deaktivieren

Wenn Sie das Caching deaktivieren möchten, entfernen Sie die GCPHTTPFilter-Verweise aus Ihrer HTTPRoute.

  1. Bearbeiten Sie das HTTPRoute-Manifest und entfernen Sie den filters-Block, der auf den GCPHTTPFilter verweist. Das folgende Beispiel zeigt ein HTTPRoute-Manifest ohne Filter:

    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. Wenden Sie das aktualisierte HTTPRoute-Manifest auf Ihren Cluster an:

    kubectl apply -f store-route-external.yaml

Nächste Schritte