No se encontraron o vencieron las implementaciones de proxies de API con apigee-serving-cert

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

Síntomas

Las implementaciones de proxy de API fallan con los siguientes mensajes de error.

Mensajes de error

Si el certificado TLS del servicio apigee-webhook-service.apigee-system.svc venció o aún no es válido, se mostrará el siguiente mensaje de error en los registros 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 Si no se encuentra apigee-serving-cert en el espacio de nombres apigee-system, puede ocurrir este problema.
Se crearon solicitudes de certificados duplicados para renovar apigee-serving-cert Si se crean solicitudes de certificados duplicados para renovar el certificado apigee-serving-cert, es posible que el certificado apigee-serving-cert no se renueve.
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 encuentra apigee-serving-cert

Diagnóstico

  1. Verifica 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ías ver 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 puede ser el motivo de este problema.

Solución

  1. El comando apigeectl init crea el apigee-serving-cert durante la instalación de Apigee Hybrid. Por lo tanto, ejecuta ese comando con el archivo overrides.yaml relevante para volver a crearlo:
    apigeectl init -f overrides/overrides.yaml
  2. Verifica que se haya creado el certificado apigee-serving-cert:
    kubectl -n apigee-system get certificates apigee-serving-cert

Causa: Se crearon solicitudes de certificados duplicadas para renovar apigee-serving-cert

Diagnóstico

  1. Verifica los registros del controlador cert-manager y comprueba si se muestra un mensaje de error similar al siguiente.

    Genera una lista de todos los pods cert-manager:

    kubectl -n cert-manager get pods

    Este es un resultado de ejemplo:

    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

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

    Este es un resultado de ejemplo:

    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"

    Si se muestra un mensaje de error similar a este, no se podrá renovar el certificado apigee-serving-cert.

  2. Haz una lista de todas las solicitudes de certificados en el espacio de nombres apigee-system y verifica si se crearon varias solicitudes de certificados para renovar la misma revisión de certificado apigee-serving-cert:
    kubectl -n apigee-system get certificaterequests

Consulta el problema cert-manager relevante para este problema en cert-manager creó varios objetos CertificateRequest con la misma revisión de certificado.

Solución

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

    Este es un resultado de ejemplo:

    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. Verifica el estado de los pods cert-manager en el espacio de nombres cert-manager:
    kubectl -n cert-manager get pods

    Si los Pods cert-manager están en buen estado, todos los Pods cert-manager deberían estar listos (1/1) y en el 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. cert-manager puede fallar por muchos motivos. Verifica los registros de cert-manager, identifica el motivo de la falla y resuélvela según corresponda.

    Un motivo conocido es que cert-manager fallará si no puede comunicarse con la API de Kubernetes. En este caso, se muestra 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

Solución

  1. Verifica el estado del clúster de Kubernetes y corrige los problemas que encuentres. Consulta Soluciona problemas de clústeres.
  2. Consulta Solución de problemas para obtener información adicional sobre la solución de problemas de cert-manager.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Atención al cliente de Google Cloud.

  1. ID del proyecto de Google Cloud
  2. Organización de Apigee Hybrid
  3. El archivo overrides.yaml de Apigee Hybrid, que enmascara la información sensible
  4. Estado del Pod 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-info de 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/*