Diagnostica dei problemi relativi ai guardrail

Panoramica dei guardrail

I Guardrail di Apigee Hybrid sono un meccanismo che avvisa i clienti di un potenziale problema prima che possa influire su un'istanza Hybrid. In altre parole, guardrail ibrido arresterà un comando nei suoi percorsi se il comando rischia la stabilità di un'istanza ibrida. Che si tratti di una configurazione errata o di risorse insufficienti, i sistemi di protezione ibrida impediscono qualsiasi modifica a un'istanza ibrida fino a quando il rischio del problema non viene rimosso. In questo modo, il cliente non deve perdere tempo a risolvere problemi che normalmente richiederebbero ore o giorni.

Utilizzo di Guardrails con Apigee hybrid

Per utilizzare Hybrid Guardrails, esegui gli stessi comandi di installazione o di upgrade di Helm per Hybrid descritti nelle istruzioni di installazione di Hybrid. Non sono necessari comandi aggiuntivi per eseguire i guardrail.

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

  • Helm crea un pod Guardrails temporaneo con la configurazione applicata. Se il pod Guardrails viene avviato in uno stato integro, eseguirà il test dell'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 va a buon fine, il pod Guardails viene lasciato in uno stato non integro per consentire la diagnosi del pod. Il comando Helm mostrerà un messaggio di errore che indica che il pod Guardrails non è riuscito.

L'esempio seguente mostra l'utilizzo di guardrail 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 ibridi di Apigee:

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 mostra i controlli Guardrails non riusciti, come nell'esempio seguente:

 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 capire quale controllo non è riuscito e perché, controlla i log dei pod Guardrails come nell'esempio seguente:

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 effettivo di errore di test è questa:

{"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 eseguito automaticamente quando emetti il comando Helm. Se il test di connettività del piano di controllo Apigee supera, il pod Guardrails viene terminato al termine dell'esecuzione.

Controlla rapidamente lo stato dei pod dopo aver emesso il comando helm install. L'esempio di output seguente mostra i pod Guardrail in uno stato corretto, il che significa che il test di connettività del piano di controllo è 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à in 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 di guardrail

Se devi disattivare i controlli Guardrails, 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 ../my-overrides.yaml \
  --no-hooks

Configurare i sistemi di protezione nel file delle sostituzioni

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

Ad esempio, le norme relative a URL, tag e pull delle immagini di Guardrails riportate di seguito verranno aggiunte al file delle sostituzioni:

# 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 di Kubernetes con Guardrails

Puoi anche aggiungere tolleranze ai guardrail nel tuo file overrides. Se non sono definite tolleranze con la configurazione overrides di Guardrails, il sistema utilizzerà qualsiasi tolleranza definita a livello globale.

Ad esempio, per includere le tolleranze specificamente nella sezione Limiti del file overrides, devi aggiungere qualcosa di simile alla seguente strofa:

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