GKE-Gateway Richtlinien hinzufügen

Diese Seite gilt für Apigee, aber nicht für Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Auf dieser Seite wird beschrieben, wie Sie Apigee-Laufzeitrichtlinien und eine Google -Token-Einfügungsrichtlinie mit dem Apigee APIM Operator für Kubernetes zum Google Kubernetes Engine (GKE) Gateway hinzufügen. Wenn Sie dem Gateway eine Reihe verfügbarer Richtlinien hinzufügen, können Sie die Funktionalität des Gateways über die Durchsetzung von API-Produkten hinaus erweitern und zusätzliche Sicherheits- und Geschäftsregeln einbeziehen.

Mit dem Apigee APIM Operator für Kubernetes können Sie dem Gateway die folgenden Richtlinien hinzufügen:

Übersicht

In den folgenden Abschnitten wird beschrieben, wie Sie Folgendes tun:

Hinweise

Wenn Sie Ihr GKE Gateway mit dem vollständigen Satz von Richtlinien ändern möchten, die in diesem Leitfaden als Beispiel verwendet werden, benötigen Sie ein Dienstkonto mit den Rollen, die zum Erstellen von Tokens in Apigee und zum Bereitstellen von Proxys und Erweiterungen erforderlich sind. Wenn Sie keine Google -Tokens erstellen möchten, müssen Sie Ihrem Dienstkonto keine zusätzlichen Rollen hinzufügen und können mit dem nächsten Abschnitt fortfahren.

So erstellen Sie ein Dienstkonto mit den erforderlichen Berechtigungen:

  1. Wenn Sie ein Dienstkonto mit dem Namen apigee-apim-gsa im Installationsleitfaden für den Apigee APIM Operator für Kubernetes erstellt haben, können Sie diesen Schritt überspringen und mit dem nächsten Schritt fortfahren. Andernfalls erstellen Sie das Dienstkonto: 
    gcloud iam service-accounts create apigee-apim-gsa --project=$PROJECT_ID
  2. Weisen Sie dem Dienstkonto die erforderliche Rolle zum Erstellen von Tokens zu: 
    gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member "serviceAccount:apigee-apim-gsa@$PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/iam.serviceAccountTokenCreator"
  3. Weisen Sie dem Dienstkonto apigee-apim-gsa die erforderliche Rolle zum Bereitstellen von Proxys und Erweiterungen zu: 
    gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member "serviceAccount:apigee-apim-gsa@$PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/iam.serviceAccountUser"

GKE Gateway mit Richtlinien ändern

Sie können Ihr GKE Gateway mit einer oder mehreren Richtlinien ändern, um seine Funktionalität zu erweitern. In diesem Beispiel wird eine yaml-Datei auf das Gateway angewendet, die die Spezifikationen für zwei Apigee-Richtlinien und eine Google -Richtlinie für die Token-Einfügung enthält.

Jede der Richtlinien, die mithilfe der folgenden yaml-Datei auf das Gateway angewendet werden, spielt bei der Bewertung von Anfragen, die an das Gateway gesendet werden, eine andere Rolle:

  • Die SpikeArrest-Richtlinie steuert die maximale Nachrichtenrate, indem sie eine maximale Rate zulässiger Anfragen über einen bestimmten Zeitraum definiert. In diesem Beispiel wird die maximale Rate auf fünf pro Minute festgelegt. Weitere Informationen dazu, wie die SpikeArrest-Richtlinie verwendet wird, um plötzliche Traffic-Spitzen auszugleichen, finden Sie unter SpikeArrest-Richtlinie.
  • Mit der JavaScript-Richtlinie können Sie benutzerdefinierten JavaScript-Code zu den Gateway-Anfragen hinzufügen. In diesem Beispiel wird die Richtlinie verwendet, um der Anfrage einen benutzerdefinierten Header hinzuzufügen. Weitere Informationen zur Verwendung der JavaScript-Richtlinie zum Hinzufügen von benutzerdefiniertem Code finden Sie unter JavaScript-Richtlinie.
  • Die Google Token-Einfügungsrichtlinie wird verwendet, um ein Google Authentifizierungszugriffstoken mithilfe der AssignMessage-Richtlinie in die Gateway-Anfragen einzufügen. Apigee unterstützt die Verwendung von Google OAuth-Tokens oder OpenID Connect-Tokens zur Authentifizierung bei Google -Diensten. Weitere Informationen zu Authentifizierungstokens finden Sie unter Google-Authentifizierung verwenden.

Fügen Sie dem Gateway die Richtlinien hinzu:

  1. Erstellen Sie eine neue Datei mit dem Namen apigee-policies.yaml im Namespace apim.
  2. Kopieren Sie den Inhalt der folgenden Datei in die neu erstellte Datei: 
    # apigee-policies.yaml
apiVersion: apim.googleapis.com/v1
kind: SpikeArrest
metadata:
  name: spike-arrest
  namespace: apim
spec:
  identifier:
    ref: request.header.name
  useEffectiveCount: true
  peakMessageRate:
    value: "5pm"
---
apiVersion: apim.googleapis.com/v1
kind: Javascript
metadata:
  name: js-add-headers
  namespace: apim
spec:
  timeLimit: 2000
  source: |
    var sum = 1+1;
    context.setVariable("request.header.first", 1);
    context.setVariable("request.header.second", 1);
    context.setVariable("request.header.sum", sum);
---
apiVersion: apim.googleapis.com/v1
kind: AssignMessage
metadata:
  name: google-token-policy
  namespace: apim
spec:
  setActions:
    - authentication:
        googleAccessToken:
          scopes:
            - 'https://www.googleapis.com/auth/cloud-platform'
  AssignTo:
    createNew: false
    type: request
---
apiVersion: apim.googleapis.com/v1
kind: KVM
metadata:
  name: kvm-1
  namespace: apim
spec:
  delete:
  - keys:
    - value: mykey
  exclusiveCache: true
  expiryTimeInSecs: 3600
  get:
  - assignTo: response.header.mykvm
    keys:
    - value: mykey
  initialEntries:
  - keys:
    - key1
    values:
    - val1
  - keys:
    - mykey
    values:
    - initvalue
  isEncrypted: false
  put:
  - keys:
    - value: mykey
    values:
    - value: request.header.mykvm
  scope: environment
---
apiVersion: apim.googleapis.com/v1
kind: OASValidation
metadata:
  name: oas-validation-1
  namespace: apim
spec:
  openApiSpec: |
    openapi: 3.0.4
    info:
      title: Sample API
      description: Optional multi/single line description.
      version: 0.1.9
    servers:
      - url: http://apigee-apim-operator-test.apigee.net
        description: Optional server description, our main host in httproute
    paths:
      /get:
        get:
          summary: just for test
          description: Optional extended description in CommonMark or HTML.
          parameters:
            - name: X-Request-Type
              in: header
              description: Must be 'internal' or 'external'.
              required: true
              schema:
                type: string
                enum:
                  - internal
                  - external
          responses:
            '200': # status code
              description: A JSON object
              content:
                application/json:
                  schema:
                    type: object
                    properties:
                      headers:
                        type: object
  source: request
---
apiVersion: apim.googleapis.com/v1
kind: ServiceCallout
metadata:
  name: service-callout-1
  namespace: apim
spec:
  request:
    clearPayload: true
    variable: myRequest
    ignoreUnresolvedVariables: true
    removeActions:
      - payload: true
      - queryParams:
        - name: rq-param1
        - name: rq-param2
    copyActions:
      - version: true
      - verb: true
    addActions:
      - headers:
        - name: X-header1
          value: value1
        - name: X-header2
          value: value2
      - queryParams:
        - name: q-param1
          value: value1
        - name: q-param2
          value: value2
    setActions:
      - verb: PUT
      - formParams:
        - name: f-param1
          value: value1
        - name: f-param2
          value: value2
  response: calloutResponse
  timeout: 30000
  httpTargetConnection:
    URL: https://httpbin.org/put
    properties:
      - name: success.codes
        value: 1xx,2xx,3xx,400
      - name: supports.http11
        value: "true"
  3. Wenden Sie die Datei yaml mit dem folgenden Befehl auf das Gateway an: 
    kubectl -n apim apply -f apigee-policies.yaml

TemplateRule als SharedFlow-Vorlage erstellen

In diesem Schritt erstellen Sie eine TemplateRule, um die Richtlinien zu erzwingen, die Sie dem Gateway hinzugefügt haben. Eine Vorlagenregel ist eine Regel für SharedFlows, die von Organisationsadministratoren erstellt wird, um sicherzustellen, dass von Dienstentwicklern nur genehmigte Richtlinien auf Gateway-Traffic angewendet werden. Eine Vorlagenregel sorgt dafür, dass Entwickler wissen, welche Richtlinien für sie verfügbar sind, welche Richtlinien für bestimmte Anwendungsfälle erforderlich sind und welche Richtlinien von Dienstentwicklern nicht verwendet werden können.

Vorlagenregel erstellen

Erstellen Sie eine Vorlagenregel, um die Verwendung der AssignMessage-Richtlinie zu erzwingen:

  1. Erstellen Sie eine neue yaml-Datei mit dem Namen template-rule.yaml im Namespace apim.
  2. Kopieren Sie den Inhalt der folgenden Datei in die neu erstellte Datei: 
    # template-rule.yaml
apiVersion: apim.googleapis.com/v1
kind: ApimTemplateRule
metadata:
  name: template-rule
  namespace: apim
spec:
  allowList: [SpikeArrest, Javascript, GenerateJWT, KVM, OASValidation, OAuthv2, ServiceCallout]
  requiredList: [AssignMessage]
  denyList: []

    In diesem Beispiel wird Entwicklern durch die Vorlagenregel mitgeteilt, dass die AssignMessage-Richtlinie, in der die Google -Token-Einfügungsrichtlinie beschrieben wird, erforderlich ist. Außerdem wird Entwicklern mitgeteilt, dass sie die Richtlinien „SpikeArrest“, „JavaScript“, „GenerateJWT“, „KVM“, „OASValidation“, „OAuthv2“ und „ServiceCallout“ für die API-Verwaltung verwenden können. In der Ablehnungsliste sind keine Richtlinien angegeben.

Regelvorlage anwenden

Wenden Sie die Vorlagenregel mit dem folgenden Befehl an: 

kubectl apply -f template-rule.yaml

Apigee-Vorlage erstellen, um die Vorlagenregel zu verwenden

Erstellen Sie eine Apigee-Vorlage, die die Vorlagenregel enthält, die Sie im vorherigen Abschnitt erstellt haben:

  1. Erstellen Sie eine neue yaml-Datei mit dem Namen new-admin-template.yaml im Namespace apim.
  2. Kopieren Sie den Inhalt der folgenden Datei in die neu erstellte Datei: 
    # new-admin-template.yaml
apiVersion: apim.googleapis.com/v1
kind: ApimTemplate
metadata:
  name: new-admin-template
  namespace: apim
spec:
  apimTemplateRule:
    group: apim.googleapis.com
    kind: ApimTemplateRule
    name: template-rule
    namespace: apim
  templates:
  - mode: REQUEST
    flows:
    - name: preflow
      policies:
      - group: apim.googleapis.com
        kind: OASValidation
        name: oas-validation-1
        namespace: apim
      - group: apim.googleapis.com
        kind: SpikeArrest
        name: spike-arrest
        namespace: apim
    - name: ConditionalGetFlow
      policies:
      - group: apim.googleapis.com
        kind: Javascript
        name: js-add-headers
        namespace: apim
      condition: request.verb="GET"
    - name: postflow
      policies:
      - group: apim.googleapis.com
        kind: AssignMessage
        name: google-token-policy
        namespace: apim
      - group: apim.googleapis.com
        kind: ServiceCallout
        name: service-callout-1
        namespace: apim
  - mode: RESPONSE
    flows:
    - name: postflow
      policies:
      - group: apim.googleapis.com
        kind: KVM
        name: kvm-1
        namespace: apim
  3. Wenden Sie die neue Vorlage mit dem folgenden Befehl an: 
    kubectl apply -f new-admin-template.yaml

Apigee Gateway-Richtlinie bereitstellen

In diesem Schritt wenden Sie eine neue Datei auf Ihr Gateway an, die die Spezifikationen für ein ApigeeGatewayPolicy enthält. Mit dieser Richtlinie wird die Apigee-Vorlage auf dem Gateway bereitgestellt.

Stellen Sie die Apigee Gateway-Richtlinie bereit:

  1. Erstellen Sie eine neue yaml-Datei mit dem Namen apigee-gateway-policy-withSA.yaml im Namespace apim.
  2. Kopieren Sie den Inhalt der folgenden Datei in die neu erstellte Datei: 
    # apigee-gateway-policy-withSA.yaml
apiVersion: apim.googleapis.com/v1
kind: ApigeeGatewayPolicy
metadata:
  name: apim-template-injection
  namespace: apim
spec:
  serviceAccount: apigee-apim-gsa@PROJECT_ID.iam.gserviceaccount.com
  ref:
    group: apim.googleapis.com
    kind: ApimTemplate
    name: new-admin-template
    namespace: apim
  targetRef:
    group: apim.googleapis.com
    kind: APIMExtensionPolicy
    name: global-ext-lb1-apim-policy
    namespace: apim
  3. Wenden Sie die Richtlinie an: 
    kubectl apply -f apigee-gateway-policy-withSA.yaml
  4. Prüfen Sie den Bereitstellungsstatus der neuen Gateway-Richtlinie: 
    kubectl -n apim get ApigeeGatewayPolicy

    Nach der Bereitstellung sollte für die Richtlinie STATUS der Wert CREATED angezeigt werden.

Warten Sie nach der Bereitstellung der neuen Gateway-Richtlinie zwei Minuten, bevor Sie eine Anfrage an das Gateway senden, damit die Richtlinie an den Cluster weitergegeben werden kann.

Durchsetzung von Richtlinien überprüfen

Senden Sie Anfragen an das Gateway, wie in den folgenden Abschnitten beschrieben, um zu bestätigen, dass die Apigee Gateway-Richtlinien wie erwartet funktionieren.

Erzwingung der AssignMessage-Richtlinie

Um zu bestätigen, dass das Token {company_name} mit der AssignMessage-Richtlinie in die Anfrage eingefügt wird, senden Sie mit dem folgenden Befehl eine Anfrage an das Gateway: 

curl http://GATEWAY_IP_ADDRESS/get -H "Host: HOST_NAME" -H "x-api-key: API_KEY"

Wobei:

  • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen: 
    kubectl get gateway GATEWAY_NAME
  • HOST_NAME ist der Name des Hosts.
  • API_KEY ist der Wert des API-Schlüssels.

Eine erfolgreiche Antwort sollte einen Authorization-Header mit dem generierten Bearer-Token enthalten, der in etwa so aussieht: 

{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Authorization": "Bearer ya29.c.c0ASRK0Gbw03y9cfvxL11DxaRYBQUU18SmUP4Vu63OckHI5cX7wJ4DmGMG2vbDDS69HXJHqMj-lak4tcqOsJGmE65crn2gNuJLanXidwM8",
    "First": "1.0",
    "Host": "apigee-apim-operator-test.apigee.net",
    "Second": "1.0",
    "Sum": "2",
    "User-Agent": "curl/8.7.1",
    "X-Api-Key": "McYcHGR3PTSGLXExvKADwQ1JJeCjgPDUvAakCl0rJKCFaX0Y",
    "X-Cloud-Trace-Context": "0fd3dadc2a3c328fa968d5f5f1434c29/18300783092696918345"
  },
  "origin": "34.54.108.129",
  "url": "apigee-apim-operator-test.apigee.net/get"
}

Erzwingung der SpikeArrest-Richtlinie

Sie können die Durchsetzung der SpikeArrest-Richtlinie testen, indem Sie innerhalb einer Minute zehn Anfragen an das Gateway senden.

Sie können das folgende Skript ausführen, um die Anfragen zu generieren: 

#!/bin/sh
for i in $(seq 1 11); do
    curl http://GATEWAY_IP_ADDRESS/get -H "Host: HOST_NAME" -H "x-api-key: API_KEY"
    sleep 1
done

Wobei:

  • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen, wobei GATEWAY_NAME der Name des Gateways ist: 
    kubectl get gateways.gateway.networking.k8s.io GATEWAY_NAME -o=jsonpath="{.status.addresses[0].value}"
  • HOST_NAME ist der Hostname, der im HTTPRoute des Gateways definiert ist.
  • API_KEY ist der API-Schlüsselwert, der in Einrichtung testen abgerufen wurde.

Die Antwort sieht in etwa so aus: 

"fault":{"faultstring":"Spike arrest violation. Allowed rate : MessageRate{capacity=5, period=Minutes}","detail":{"errorcode":"policies.ratelimit.SpikeArrestViolation"}}}

Erzwingung der JavaScript-Richtlinie

Senden Sie mit dem folgenden Befehl eine Anfrage an das Gateway, um zu prüfen, ob die JavaScript-Richtlinie wie erwartet funktioniert: 

curl http://GATEWAY_IP_ADDRESS/get \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "X-Request-Type: external" -i

Wobei:

  • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen, wobei GATEWAY_NAME der Name des Gateways ist: 
    kubectl get gateways.gateway.networking.k8s.io GATEWAY_NAME -o=jsonpath="{.status.addresses[0].value}"
  • HOST_NAME ist der Hostname, der im HTTPRoute des Gateways definiert ist.
  • API_KEY ist der API-Schlüsselwert, der in Einrichtung testen abgerufen wurde.

In der JavaScript-Richtlinie werden drei Anfrageheader festgelegt: First, Second und Sum, wie in der Antwort zu sehen ist: 

HTTP/1.1 200 OK
...
{
  "args": {},
  "headers": {
    ...
    "First": "1.0",
    ...
    "Second": "1.0",
    "Sum": "2",
    ...
  },
  ...
}

Erzwingung der OASValidation-Richtlinie

Um zu bestätigen, dass die OASValidation-Richtlinie wie erwartet funktioniert, senden Sie mit dem folgenden Befehl eine Anfrage an das Gateway: 

curl "http://GATEWAY_IP_ADDRESS/get"  \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "X-Request-Type: badvalue"

Wobei:

  • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen, wobei GATEWAY_NAME der Name des Gateways ist: 
    kubectl get gateways.gateway.networking.k8s.io GATEWAY_NAME -o=jsonpath="{.status.addresses[0].value}"
  • HOST_NAME ist der Hostname, der im HTTPRoute des Gateways definiert ist.
  • API_KEY ist der API-Schlüsselwert, den Sie unter Einrichtung testen erhalten haben.

Der Befehl enthält einen ungültigen Wert für den Header X-Request-Type. Die Anfrage schlägt mit einer Antwort ähnlich der folgenden fehl: 

{"fault":{"faultstring":"OASValidation oas-validation-1 with resource \"oas:\/\/oas-validation-1.yaml\": failed with reason: \"[ERROR - Instance value (\"badvalue\") not found in enum (possible values: [\"internal\",\"external\"]): []]\"","detail":{"errorcode":"steps.oasvalidation.Failed"}}}

Wenn Sie dieselbe Anfrage mit einem gültigen Wert für den X-Request-Type-Header senden, ist sie erfolgreich. Beispiel: 

curl "http://GATEWAY_IP_ADDRESS/get"  \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "X-Request-Type: external" -i

Wobei:

  • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen, wobei GATEWAY_NAME der Name des Gateways ist: 
    kubectl get gateways.gateway.networking.k8s.io GATEWAY_NAME -o=jsonpath="{.status.addresses[0].value}"
  • HOST_NAME ist der Hostname, der im HTTPRoute des Gateways definiert ist.
  • API_KEY ist der API-Schlüsselwert, den Sie unter Einrichtung testen erhalten haben.

Durchsetzung der ServiceCallout-Richtlinie

Sie können die Erzwingung der ServiceCallout-Richtlinie überprüfen, indem Sie eine Debugging-Sitzung öffnen und einige gültige Anfragen an den Proxy senden.

So öffnen Sie eine Debugging-Sitzung:

  1. Rufen Sie in der Google Cloud Console die Seite API-Proxys auf.

    Zu „API-Proxys“

  2. Wählen Sie den global-ext-lb1-apim-policy-Proxy aus, den Sie in der Umgebung bereitgestellt haben, die für den Apigee APIM Operator für Kubernetes erstellt wurde.
  3. Klicken Sie auf den Tab Debugging.
  4. Klicken Sie im Fenster Debugging-Sitzung auf Debugging-Sitzung starten.
  5. Treffen Sie im Bereich Fehlerbehebungssitzung die folgenden Auswahlen:
    • Umgebung: Wählen Sie in der Liste der verfügbaren Umgebungen die Umgebung aus, die Sie für den APIM-Operator erstellt haben.
    • Filter: Wählen Sie Keine (Alle Transaktionen) aus.
  6. Klicken Sie auf Start.

Sobald die Sitzung gestartet wurde, können Sie gültige Anfragen an den Proxy senden: 

curl "GATEWAY_IP_ADDRESSget"  \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "X-Request-Type: external" -i

Wobei:

  • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen, wobei GATEWAY_NAME der Name des Gateways ist: 
    kubectl get gateway GATEWAY_NAME
  • HOST_NAME ist der Hostname, der im HTTPRoute des Gateways definiert ist.
  • API_KEY ist der API-Schlüsselwert, den Sie unter Einrichtung testen erhalten haben.

Die Anfrage- und Antworttransaktionen werden im Bereich Transaktionen angezeigt. Wählen Sie eine erfolgreiche Transaktion aus der Liste aus, um den Ablauf aufzurufen. Sie sollten sehen, dass die ServiceCallout-Richtlinie erfolgreich ausgeführt wurde.

Durchsetzung der KVM-Richtlinie

Wenn die KVM-Richtlinie erfolgreich ausgeführt wird, wird die KVM mit einem Startwert für den Schlüssel mykey initialisiert. Bei einer Antworttransaktion ruft die KVM-Richtlinie den Wert von mykey ab und speichert ihn im Antwortheader mykvm. Wenn die KVM-Richtlinie noch einmal ausgeführt wird, wird der neue Wert für mykey eingefügt, der aus dem Anfrageheader mykvm abgerufen wurde.

Sie können die Header für jede Transaktion prüfen, um zu bestätigen, dass die Richtlinie in einer Transaktion einen Wert in der KVM speichert und denselben Wert in der nächsten Transaktion abruft, wie im folgenden Beispiel dargestellt.

KVM-Richtlinie testen:

  1. Senden Sie eine Anfrage an das Gateway: 
    curl -i "http://GATEWAY_IP_ADDRESS/get" \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "X-Request-Type: external" \
  -H "KVM_NAME: next-value1" -i

    Wobei:

    • GATEWAY_IP_ADDRESS ist die IP-Adresse des Gateways. Sie können die Gateway-IP-Adresse mit dem folgenden Befehl abrufen, wobei GATEWAY_NAME der Name des Gateways ist: 
      kubectl get gateway GATEWAY_NAME
    • HOST_NAME ist der Hostname, der im HTTPRoute des Gateways definiert ist.
    • API_KEY ist der API-Schlüsselwert, den Sie unter Einrichtung testen erhalten haben.
    • KVM_NAME ist der Name des KVM.

  2. Prüfen Sie die Antwortheader, um zu bestätigen, dass die KVM-Richtlinie erfolgreich ausgeführt wurde und ein Anfangswert für mykvm gespeichert wurde. Die Antwort sollte in etwa so aussehen: 
    HTTP/1.1 200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
Content-Length: 517
content-type: application/json
date: ...
server: gunicorn/19.9.0
mykvm: initvalue
via: 1.1 google
{
  "args": {
  ...
  "url": "http://apigee-apim-operator-test.apigee.net/get"
  }
}
  3. Senden Sie eine weitere Anfrage an das Gateway: 
    curl -i "http://GATEWAY_IP_ADDRESS/get" \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "mykvm: next"X-Request-Type: external" -H "mykvm: next-value2" -i

    Die Antwort sollte in etwa so aussehen: 

    HTTP/1.1 200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
Content-Length: 517
content-type: application/json
date: ...
server: gunicorn/19.9.0
mykvm: next-value2
via: 1.1 google
{
  "args": {
  ...
  "url": "http://apigee-apim-operator-test.apigee.net/get?rq-param2=rq-val1&x-param1=xval1"
  }
}

    Sie sehen, dass die KVM-Richtlinie erfolgreich ausgeführt wurde, da der Wert des Headers mykvm auf den Wert des Anfrageheaders mykvm aktualisiert wurde.

  4. Senden Sie eine weitere Anfrage: 
    curl -i "http://GATEWAY_IP_ADDRESS/get" \
  -H "Host: HOST_NAME" \
  -H "x-api-key: API_KEY" \
  -H "X-Request-Type: external" -H "mykvm: next-value3" -i

    Die Antwort sollte in etwa so aussehen: 

    HTTP/1.1 200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
Content-Length: 517
content-type: application/json
date: ...
server: gunicorn/19.9.0
mykvm: next-value2
via: 1.1 google
{
  "args": {
  ...
  "url": "http://apigee-apim-operator-test.apigee.net/get?rq-param2=rq-val1&x-param1=xval1"
  }
}

    Der Wert des mykvm-Headers wird noch einmal aktualisiert. Er zeigt, dass der in der Antwort angezeigte Wert die in der vorherigen Transaktion gespeicherten Werte sind.

Fehlerbehebung

Wenn beim Hinzufügen von Richtlinien zum GKE Gateway Probleme auftreten, finden Sie unter Fehlerbehebung für den APIM-Operator Lösungen für häufige Fehler.

Nächste Schritte