I deployment del proxy API non riescono e apigee-serving-cert non è stato trovato o è scaduto

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza Documentazione di Apigee Edge.

Sintomi

I deployment dei proxy API non riescono e ricevono i seguenti messaggi di errore.

Messaggi di errore

Se il certificato TLS Il servizio apigee-webhook-service.apigee-system.svc è scaduto o non è ancora valido, verrà visualizzato il seguente messaggio di errore Log di apigee-watcher: 

{"level":"error","ts":1687991930.7745812,"caller":"watcher/watcher.go:60",
"msg":"error during watch","name":"ingress","error":"INTERNAL: INTERNAL: failed
to update ApigeeRoute [org-env]-group-84a6bb5, namespace apigee:
Internal error occurred: failed calling webhook
\"mapigeeroute.apigee.cloud.google.com\": Post
\"https://apigee-webhook-service.apigee-system.svc:443/mutate-apigee-cloud-google-com-v1alpha1-apigeeroute?timeout=30s\":
x509:
certificate has expired or is not yet valid: current time
2023-06-28T22:38:50Z is after 2023-06-17T17:14:13Z, INTERNAL: failed to update
ApigeeRoute [org-env]-group-e7b3ff6, namespace apigee

Possibili cause

Causa Descrizione
L'elemento apigee-serving-cert non è stato trovato Se apigee-serving-cert non viene trovato nel apigee-system, potrebbe verificarsi questo problema.
Sono state create richieste di certificato duplicate per rinnovo di apigee-serving-cert in corso... Se sono state create richieste di certificati duplicate per il rinnovo della apigee-serving-cert, il Il certificato apigee-serving-cert potrebbe non essere rinnovato.
cert-manager non è integro Se cert-manager non è integro, Il certificato apigee-serving-cert potrebbe non essere rinnovato.

Causa: apigee-serving-cert non trovato

Diagnosi

  1. Verifica la disponibilità del certificato apigee-serving-cert nello spazio dei nomi apigee-system: 

    kubectl -n apigee-system get certificates apigee-serving-cert

    Se il certificato è disponibile, dovrebbe essere visualizzato un output simile al seguente essere visti: 

    NAME                  READY   SECRET                AGE
apigee-serving-cert   True    webhook-server-cert   2d10h
  2. Se il certificato apigee-serving-cert non si trova nella apigee-system, potrebbe essere questo il motivo. problema.

Risoluzione

  1. Il parametro apigee-serving-cert viene creato dal comando apigeectl init durante l'installazione ibrida di Apigee. Pertanto, esegui questo comando con il file overrides.yaml pertinente ricrealo: 
    apigeectl init -f overrides/overrides.yaml
  2. Verifica che il certificato apigee-serving-cert sia stato creato: 
    kubectl -n apigee-system get certificates apigee-serving-cert

Causa: sono state create richieste di certificati duplicati per rinnovo di apigee-serving-cert

Diagnosi

  1. Controlla cert-manager log del controller per verificare se si è verificato un errore è stato restituito un messaggio simile al seguente.

    Elenca tutti i cert-manager pod:

    kubectl -n cert-manager get pods

    Output di esempio:

    NAME                                       READY   STATUS    RESTARTS        AGE
cert-manager-66d9545484-772cr              1/1     Running   0               6d19h
cert-manager-cainjector-7d8b6bd6fb-fpz6r   1/1     Running   0               6d19h
cert-manager-webhook-669b96dcfd-6mnm2      1/1     Running   0               6d19h

    Controlla i log del controller cert-manager:

    kubectl -n cert-manager logs cert-manager-66d9545484-772cr | grep "issuance is skipped until there are no more duplicates"

    Output di esempio:

    1 controller.go:163] cert-manager/certificates-readiness "msg"="re-queuing item due to error processing" "error"="multiple CertificateRequests were found for the 'next' revision 3, issuance is skipped until there are no more duplicates" "key"="apigee-system/apigee-serving-cert"

    Se viene visualizzato un messaggio di errore simile a questo, rinnovo del certificato apigee-serving-cert.

  2. Elenca tutte le richieste di certificato nello spazio dei nomi apigee-system e controllare se sono state create più richieste di certificato Rinnovo della stessa revisione del certificato apigee-serving-cert: 
    kubectl -n apigee-system get certificaterequests

Visualizza il problema cert-manager attinente a questo problema all'indirizzo cert-manager ha creato più oggetti CertificateRequest con lo stesso revisione del certificato.

Risoluzione

  1. Elimina tutte le richieste di certificato nello spazio dei nomi apigee-system: 
    kubectl -n apigee-system delete certificaterequests --all
  2. Verifica che le richieste di certificati duplicate siano state eliminate e che solo una è disponibile una richiesta di certificato per apigee-serving-cert certificato nello spazio dei nomi apigee-system: 
    kubectl -n apigee-system get certificaterequests
  3. Verifica che il certificato apigee-serving-cert sia stato rinnovato: 
    kubectl -n apigee-system get certificates apigee-serving-cert -o yaml

    Output di esempio:

    apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  creationTimestamp: "2023-06-26T13:25:10Z"
  generation: 1
  name: apigee-serving-cert
  namespace: apigee-system
  resourceVersion: "11053"
  uid: e7718341-b3ca-4c93-a6d4-30cf70a33e2b
spec:
  dnsNames:
  - apigee-webhook-service.apigee-system.svc
  - apigee-webhook-service.apigee-system.svc.cluster.local
  issuerRef:
    kind: Issuer
    name: apigee-selfsigned-issuer
  secretName: webhook-server-cert
status:
  conditions:
  - lastTransitionTime: "2023-06-26T13:25:11Z"
    message: Certificate is up to date and has not expired
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
  notAfter: "2023-09-24T13:25:11Z"
  notBefore: "2023-06-26T13:25:11Z"
  renewalTime: "2023-08-25T13:25:11Z"
  revision: 1

Causa: cert-manager non è integro

Diagnosi

  1. Controlla l'integrità di cert-manager pod in Spazio dei nomi cert-manager: 
    kubectl -n cert-manager get pods

    Se cert-manager pod è integro, cert-manager pod dovrebbe essere pronto (1/1) e in Running, altrimenti potrebbe essere la causa problema: 

    NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-59cf78f685-mlkvx              1/1     Running   0          15d
cert-manager-cainjector-78cc865768-krjcp   1/1     Running   0          15d
cert-manager-webhook-77c4fb46b6-7g9g6      1/1     Running   0          15d

  2. L'errore cert-manager può non funzionare per diversi motivi. Controlla il cert-manager log e identifica il motivo dell'errore e risolverli di conseguenza.

    Uno dei motivi noti è che cert-manager non riuscirà se non possono comunicare con l'API Kubernetes. In questo caso, viene visualizzato un errore appare un messaggio simile al seguente: 

    E0601 00:10:27.841516       1 leaderelection.go:330] error retrieving
resource lock kube-system/cert-manager-controller: Get
"https://192.168.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-controller":
dial tcp 192.168.0.1:443: i/o timeout

Risoluzione

  1. Controlla l'integrità del cluster Kubernetes e risolvi eventuali problemi rilevati. Vedi Risoluzione dei problemi relativi ai cluster.
  2. Consulta Risoluzione dei problemi per ulteriori cert-manager informazioni sulla risoluzione dei problemi.

Raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta Assistenza clienti Google Cloud.

  1. ID progetto Google Cloud
  2. Organizzazione ibrida Apigee
  3. File overrides.yaml ibrido Apigee, mascherando le informazioni sensibili.
  4. Stato dei pod Kubernetes in tutti gli spazi dei nomi: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Dump cluster-info di Kubernetes: 
    # generate kubernetes cluster-info dump
kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
# zip kubernetes cluster-info dump
zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*