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 proxies 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 duplicadas para renovar `apigee-serving-cert`	Si se crean solicitudes de certificados duplicadas 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 encontró el apigee-serving-cert

Diagnóstico

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, se debería ver un resultado similar al siguiente:
```
NAME                  READY   SECRET                AGE
apigee-serving-cert   True    webhook-server-cert   2d10h
```
Si el certificado apigee-serving-cert no se encuentra en el espacio de nombres apigee-system, ese podría ser el motivo de este problema.

Solución

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
```
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 verifica si se mostró un mensaje de error similar al siguiente.

Enumera 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, eso evitará renovar el certificado apigee-serving-cert.

Enumera todas las solicitudes de certificados en el espacio de nombres apigee-system y verifica si hay varias solicitudes de certificado creadas 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

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 nombres apigee-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 nombres cert-manager:

kubectl -n cert-manager get pods

Si los pods cert-manager están en buen estado, todos los pods cert-manager deben estar listos en (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

El cert-manager puede fallar por muchas razones. Verifica los registros de cert-manager y, luego, identifica el motivo de la falla y resuélvelos 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 soluciona cualquier problema encontrado. 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 Asistencia de Apigee.

ID del proyecto de Google Cloud
Organización híbrida de Apigee
Archivo overrides.yaml híbrido de Apigee, 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 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/*