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
-
Verifica la disponibilidad del certificado
apigee-serving-cert
en el espacio de nombresapigee-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
-
Si no se encuentra el certificado apigee-serving-cert en el espacio de nombres
apigee-system
, ese puede ser el motivo del problema.
Solución
-
Actualiza el
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 parámetros de configuración que se muestran, incluido
--atomic
, para que la acción se revierta en caso de error. - 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
-
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"
Resultados 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"
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 anteriores, no se renovarán los certificados
apigee-serving-cert
niapigee-istiod-cert
. -
Enumera todas las solicitudes de certificados en el espacio de nombres
apigee-system
oapigee
, según el espacio de nombres que se imprimió en las entradas de registro anteriores, y verifica si se crearon varias solicitudes de certificados para renovar las mismas revisiones de certificadosapigee-serving-cert
oapigee-istiod-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
-
Borra todas las solicitudes de certificado en el espacio de nombres
apigee-system
:kubectl -n apigee-system delete certificaterequests --all
-
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 nombresapigee-system
:kubectl -n apigee-system get certificaterequests
-
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
-
Verifica el estado de los pods
cert-manager
en el espacio de nombrescert-manager
:kubectl -n cert-manager get pods
Si los Pods
cert-manager
están en buen estado, todos los Podscert-manager
deberían estar listos(1/1)
y en el estadoRunning
. 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
-
cert-manager
puede fallar por muchos motivos. Verifica los registros decert-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
- Verifica el estado del clúster de Kubernetes y corrige los problemas que encuentres. Consulta Soluciona problemas de clústeres.
-
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.
- Google Cloud ID del proyecto
- Organización de Apigee Hybrid
-
El archivo
overrides.yaml
de Apigee Hybrid, que enmascara la información sensible - 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
-
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/*