Diagnostica dei problemi relativi ai guardrail

Panoramica delle contromisure

Apigee Hybrid Guardrails è un meccanismo che avvisa i clienti di un potenziale problema prima che possa influire su un'istanza ibrida. In altre parole, Hybrid Guardrails interrompe un comando se rischia di compromettere la stabilità di un'istanza ibrida. Che si tratti di una configurazione errata o di risorse insufficienti, Hybrid Guardrails impedirà qualsiasi modifica a un'istanza ibrida finché il rischio del problema non viene rimosso. In questo modo, il cliente non deve dedicare tempo a problemi che normalmente richiederebbero ore o giorni per essere risolti.

Utilizzo di Guardrails con Apigee hybrid

Per utilizzare Hybrid Guardrails, esegui gli stessi comandi di installazione di Hybrid Helm o di upgrade di Hybrid Helm documentati nelle istruzioni di installazione di Hybrid. Per eseguire Guardrails non sono necessari comandi aggiuntivi.

Quando esegui un comando Helm per Apigee hybrid, prima che il comando Helm applichi la configurazione all'istanza ibrida, si verificano due eventi:

  • Helm crea un pod Guardrails temporaneo con la configurazione applicata. Se il pod Guardrails viene avviato in uno stato integro, testerà l'istanza ibrida in base alla configurazione applicata. Se il test viene superato, il pod Guardrails viene terminato e la configurazione viene applicata all'istanza Apigee hybrid.
  • Se il test non riesce, il pod Guardrails viene lasciato in uno stato non integro per consentire la diagnosi del pod. Il comando Helm visualizzerà un messaggio di errore che segnala l'errore del pod Guardrails.

Il seguente esempio mostra l'utilizzo di Guardrails per testare la connettività di rete da un'istanza ibrida al piano di controllo Apigee nell'ambito dell'installazione del componente apigee-datastore. Puoi utilizzare la stessa sequenza per tutti i componenti di Apigee Hybrid:

Installa il componente apigee-datastore utilizzando il seguente comando: 

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f overrides.yaml

Se si verifica un errore immediato, il comando Helm mostrerà anche un messaggio di errore che indica che i controlli delle barriere protettive non sono riusciti, come nel seguente esempio: 

 helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  -f my-overrides.yaml

  . . .
    Error: UPGRADE FAILED: pre-upgrade hooks failed: 1 error occurred:
      * pod apigee-hybrid-helm-guardrail-datastore failed

Per vedere quale controllo non è riuscito e perché, controlla i log del pod Guardrails come nel seguente esempio: 

kubectl logs -n apigee apigee-hybrid-helm-guardrail-datastore
{"level":"INFO","timestamp":"2024-02-01T20:28:55.934Z","msg":"logging enabled","log-level":"INFO"}
{"level":"INFO","timestamp":"2024-02-01T20:28:55.935Z","msg":"","checkpoint":"upgrade","component":"apigee-datastore"}
{"level":"INFO","timestamp":"2024-02-01T20:28:55.935Z","msg":"initiating pre-install checks"}
{"level":"INFO","timestamp":"2024-02-01T20:28:55.935Z","msg":"check validation starting...","check":"controlplane_connectivity"}
{"level":"ERROR","timestamp":"2024-02-01T20:28:55.961Z","msg":"connectivity test failed","check":"controlplane_connectivity","host":"https://apigee.googleapis.com","error":"Get \"https://apigee.googleapis.com\": dial tcp: lookup apigee.googleapis.com on 10.92.0.10:53: no such host"}

In questo esempio, il messaggio di errore effettivo del test è questa parte: 

{"level":"ERROR","timestamp":"2024-02-01T20:28:55.961Z","msg":"connectivity test failed","check":"controlplane_connectivity","host":"https://apigee.googleapis.com","error":"Get \"https://apigee.googleapis.com\": dial tcp: lookup apigee.googleapis.com on 10.92.0.10:53: no such host"}

Il pod Guardrails viene sottoposto a provisioning automatico quando esegui il comando Helm. Se il test di connettività del piano di controllo Apigee viene superato, il pod Guardrails viene terminato al termine dell'esecuzione.

Controlla rapidamente lo stato dei pod dopo aver eseguito il comando helm install. L'output di esempio seguente mostra i pod Guardrail in stato integro, il che significa che il test di connettività del Control Plane è stato superato: 

kubectl get pods -n apigee -w
NAME                                      READY    STATUS             RESTARTS    AGE
apigee-hybrid-helm-guardrail-datastore    0/1      Pending            0           0s
apigee-hybrid-helm-guardrail-datastore    0/1      Pending            0           1s
apigee-hybrid-helm-guardrail-datastore    0/1      ContainerCreating  0           1s
apigee-hybrid-helm-guardrail-datastore    0/1      Completed          0           2s
apigee-hybrid-helm-guardrail-datastore    0/1      Completed          0           3s
apigee-hybrid-helm-guardrail-datastore    0/1      Terminating        0           3s
apigee-hybrid-helm-guardrail-datastore    0/1      Terminating        0           3s

Se il test di connettività del piano di controllo Apigee non va a buon fine, il pod Guardrails rimarrà nello stato di errore simile all'output di esempio seguente: 

kubectl get pods -n apigee -w
NAME                                      READY    STATUS             RESTARTS    AGE
apigee-hybrid-helm-guardrail-datastore    0/1      Pending            0           0s
apigee-hybrid-helm-guardrail-datastore    0/1      Pending            0           0s
apigee-hybrid-helm-guardrail-datastore    0/1      ContainerCreating  0           0s
apigee-hybrid-helm-guardrail-datastore    0/1      Error              0           4s
apigee-hybrid-helm-guardrail-datastore    0/1      Error              0           5s
apigee-hybrid-helm-guardrail-datastore    0/1      Error              0           6s

Disattivazione temporanea dei guardrail

Se devi disattivare i controlli delle barriere protettive, aggiungi il flag --no-hooks al comando Helm. L'esempio seguente mostra il flag --no-hooks in un comando Helm: 

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  -f overrides.yaml \
  --no-hooks

Configurare i sistemi di protezione nel file di override

A partire dalla versione 1.12 di Apigee Hybrid, i guardrail sono configurati per impostazione predefinita in ogni grafico. Puoi ignorare l'URL immagine, il tag e le norme di pull delle immagini nel file overrides.

Ad esempio, l'URL, il tag e la policy di pull dell'immagine Guardrails riportati di seguito verranno aggiunti al file di override:

# Apigee Ingressgateway
ingressGateway:
  image:
    pullPolicy: Always

## NOTE: The Guardrails config is below. The ingressgateway config above is for position reference only and is NOT required for Guardrails config.

# Apigee Guardrails
guardrails:
  image:
    url: "gcr.io/ng-hybrid/guardrails/apigee-watcher"
    tag: "12345_6789abcde"
    pullPolicy: Always

Utilizzo delle tolleranze Kubernetes con Guardrails

Puoi anche aggiungere tolleranze alle barriere protettive nel file overrides. Se non sono definite tolleranze nella configurazione di Guardrails overrides, Guardrails utilizzerà le tolleranze definite a livello globale.

Ad esempio, per includere le tolleranze specificamente nella sezione Guardrail del file overrides, aggiungi una stanza simile alla seguente:

  # Apigee Guardrails
  guardrails:
    image:
      url: "gcr.io/ng-hybrid/guardrails/apigee-watcher"
      tag: "12345_6789abcde"
      pullPolicy: Always
    tolerations:
    - key: "say"
      operator: "Equal"
      value: "taunt"
      effect: "NoSchedule"

Risoluzione dei problemi relativi ai guardrail

Checkpoint variabile di ambiente mancante o vuoto

Se visualizzi l'errore Client.Timeout exceeded nel log del pod guardrail dell'operatore apigee, ecco alcuni passaggi per la risoluzione dei problemi per determinare se il problema riguarda i guardrail o l'infrastruttura.

  1. Crea un nuovo file YAML con i seguenti contenuti. Il nome del file YAML può essere qualsiasi.
    2.     apiVersion: v1
    kind: Pod
    metadata:
      labels:
      name: apigee-simple-client  
    spec:
      containers:
      - name: apigee-simple-client
        image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:1.10.1"
        imagePullPolicy: Always
        command:
        - sleep
        - "3650d"
      restartPolicy: Never
      hostNetwork: false
  2. Applica il nuovo file YAML con questo comando:
    3.     kubectl apply -n apigee-system -f name of the yaml file
  3. Esegui l'accesso al pod con questo comando:
    4.     kubectl exec -it -n apigee-system apigee-simple-client -- /bin/bash
  4. Esegui questo comando all'interno del pod apigee-simple-client e controlla l'output:
    5.     curl -v -I --proxy http://forwarding-proxy.example.com:5678 \
      https://apigee.googleapis.com

    forwarding-proxy.example.com è l'indirizzo proxy. Puoi utilizzare qualsiasi indirizzo proxy a cui hai accesso. Se non hai accesso a un proxy, puoi utilizzare il seguente comando per testare la connettività di rete:

        curl -v -I https://apigee.googleapis.com

    Se il comando curl si connette correttamente al proxy HTTP e raggiunge apigee.googleapis.com, il comando curl dovrebbe restituire un codice di risposta HTTP. Se il comando curl non riesce a raggiungere il proxy o non riesce a connettersi a apigee.googleapis.com tramite il proxy, dovrebbe mostrare un errore.