Los despliegues de proxies de APIs fallan y no se encuentra o ha caducado apigee-serving-cert

Estás consultando la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

Síntomas

Los despliegues de proxies de APIs fallan y devuelven los siguientes mensajes de error.

Mensajes de error

Si el certificado TLS del servicio apigee-webhook-service.apigee-system.svc ha caducado o aún no es válido, se mostrará el siguiente mensaje de error en los registros de 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

Causas posibles

Causa Descripción
No se encuentra apigee-serving-cert Este problema puede producirse si no se encuentra apigee-serving-cert en el espacio de nombres apigee-system.
Se han creado solicitudes de certificado duplicadas para renovar apigee-serving-cert. Si se crean solicitudes de certificado duplicadas para renovar el certificado apigee-serving-cert, es posible que no se renueve.apigee-serving-cert
cert-manager no está en buen estado Si cert-manager no está en buen estado, es posible que el certificado apigee-serving-cert no se renueve.

Causa: no se ha encontrado apigee-serving-cert

Diagnóstico

  1. Comprueba la disponibilidad del certificado apigee-serving-cert en el espacio de nombres apigee-system: 

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

    Si este certificado está disponible, debería aparecer un resultado similar al siguiente: 

    NAME                  READY   SECRET                AGE
apigee-serving-cert   True    webhook-server-cert   2d10h
  2. Si no se encuentra el certificado apigee-serving-cert en el espacio de nombres apigee-system, ese podría ser el motivo del problema.

Resolución

  1. Actualiza apigee-serving-cert con Helm: 
    helm upgrade ENV_NAME apigee-env/ \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --atomic \
  -f OVERRIDES_FILE

    Asegúrate de incluir todos los ajustes que se muestran, incluido --atomic para que la acción se revierta si falla.

  2. Verifica que se haya creado el certificado apigee-serving-cert: 
    kubectl -n apigee-system get certificates apigee-serving-cert

Causa: se han creado solicitudes de certificado duplicadas para renovar apigee-serving-cert.

Diagnóstico

  1. Comprueba los registros del controlador cert-manager y mira si se ha devuelto un mensaje de error similar al siguiente.

    Lista todos los pods de cert-manager:

    kubectl -n cert-manager get pods

    Ejemplo de salida:

    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

    Consulta los registros del controlador cert-manager:

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

    Ejemplos de resultados:

    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"
     
    1 controller.go:167] cert-manager/certificates-readiness "msg"="re-queuing item due to error processing" "error"="multiple CertificateRequests were found for the 'next' revision 683, issuance is skipped until there are no more duplicates" "key"="apigee/apigee-istiod"

    Si ves alguno de los mensajes que se muestran arriba, los certificados apigee-serving-cert y apigee-istiod-cert no se renovarán.

  2. Lista todas las solicitudes de certificados del espacio de nombres apigee-system o apigee, según el espacio de nombres que se haya impreso en las entradas de registro anteriores, y comprueba si se han creado varias solicitudes de certificados para renovar las mismas revisiones de certificados apigee-serving-cert o apigee-istiod-cert: 
    kubectl -n apigee-system get certificaterequests

Consulte el cert-manager problema relacionado con este problema en cert-manager ha creado varios objetos CertificateRequest con la misma certificate-revision.

Resolución

  1. Elimina todas las solicitudes de certificados del espacio de nombres apigee-system: 
    kubectl -n apigee-system delete certificaterequests --all
  2. Verifica que se hayan eliminado las solicitudes de certificado duplicadas y que solo haya una solicitud de certificado para el certificado apigee-serving-cert en el espacio de nombres apigee-system: 
    kubectl -n apigee-system get certificaterequests
  3. Verifica que el certificado apigee-serving-cert se haya renovado: 
    kubectl -n apigee-system get certificates apigee-serving-cert -o yaml

    Ejemplo de salida:

    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 no está en buen estado

Diagnóstico

  1. Comprueba el estado de los pods cert-manager en el espacio de nombres cert-manager: 
    kubectl -n cert-manager get pods

    Si los pods de cert-manager están en buen estado, todos los pods de cert-manager deberían estar listos (1/1) y en estado Running. De lo contrario, ese podría ser el motivo de este 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. La cert-manager puede fallar por muchos motivos. Consulta los registros de cert-manager para identificar el motivo del fallo y resuélvelo en consecuencia.

    Una de las razones conocidas es que cert-manager fallará si no puede comunicarse con la API de Kubernetes. En este caso, se mostrará un mensaje de error similar al siguiente:: 

    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

Resolución

  1. Comprueba el estado del clúster de Kubernetes y corrige los problemas que encuentres. Consulta Solución de problemas de clústeres.
  2. Consulta la sección Solución de problemas para obtener más información sobre cert-manager cómo solucionar problemas.

Debe recoger información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recoge la siguiente información de diagnóstico y ponte en contacto con el equipo de Asistencia de Google Cloud.

  1. Google Cloud ID de proyecto
  2. Organización de Apigee Hybrid
  3. Archivo overrides.yaml de Apigee hybrid, ocultando la información sensible.
  4. Estado de los pods de Kubernetes en todos los espacios de nombres: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Volcado de cluster-infoKubernetes: 
    # 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/*