Les déploiements du proxy d'API échouent en raison d'un certificat apigee-serving-cert introuvable ou expiré

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

Symptômes

Les déploiements du proxy d'API échouent avec les messages d'erreur suivants.

Messages d'erreur

Si le certificat TLS du service apigee-webhook-service.apigee-system.svc a expiré ou n'est pas encore valide, le message d'erreur suivant s'affiche dans les journaux 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

Causes possibles :

Cause Description
Le certificat apigee-serving-cert est introuvable Ce problème peut se produire si la ressource apigee-serving-cert est introuvable dans l'espace de noms apigee-system.
Des requêtes de certificat en doublon ont été créées pour le renouvellement du certificat apigee-serving-cert Si des requêtes de certificat en doublon sont créées pour renouveler le certificat apigee-serving-cert, il est possible que ce certificat apigee-serving-cert ne soit pas renouvelé.
Le contrôleur cert-manager n'est pas opérationnel Si cert-manager n'est pas opérationnel, il est possible que le certificat apigee-serving-cert ne soit pas renouvelé.

Cause : Le certificat apigee-serving-cert est introuvable

Diagnostic

  1. Vérifiez la disponibilité du certificat apigee-serving-cert dans l'espace de noms apigee-system : 

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

    Si ce certificat est disponible, une sortie semblable à la suivante doit s'afficher : 

    NAME                  READY   SECRET                AGE
apigee-serving-cert   True    webhook-server-cert   2d10h
  2. Le fait que le certificat apigee-serving-cert soit introuvable dans l'espace de noms apigee-system peut être la cause de ce problème.

Solution

  1. Le certificat apigee-serving-cert est créé par la commande apigeectl init lors de l'installation d'Apigee hybrid. Par conséquent, exécutez cette commande avec le fichier overrides.yaml approprié pour la recréer : 
    apigeectl init -f overrides/overrides.yaml
  2. Vérifiez que le certificat apigee-serving-cert a été créé : 
    kubectl -n apigee-system get certificates apigee-serving-cert

Cause : Des requêtes de certificat en doublon ont été créées pour le renouvellement du certificat apigee-serving-cert

Diagnostic

  1. Consultez les journaux du contrôleur cert-manager et vérifiez si un message d'erreur semblable à celui ci-après a été renvoyé.

    Listez tous les pods cert-manager :

    kubectl -n cert-manager get pods

    Exemple de résultat :

    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

    Consultez les journaux du contrôleur cert-manager :

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

    Exemple de résultat :

    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 un message d'erreur semblable à celui-ci s'affiche, cela empêche le renouvellement du certificat apigee-serving-cert.

  2. Listez toutes les requêtes de certificat dans l'espace de noms apigee-system et vérifiez si plusieurs requêtes de certificat ont été créées pour renouveler une même révision de certificat apigee-serving-cert : 
    kubectl -n apigee-system get certificaterequests

Consultez la ressource cert-manager pertinente pour ce problème, intitulée cert-manager a créé plusieurs objets CertificateRequest pour une même révision de certificat.

Solution

  1. Supprimez toutes les requêtes de certificat dans l'espace de noms apigee-system : 
    kubectl -n apigee-system delete certificaterequests --all
  2. Vérifiez que les requêtes de certificat en doublon ont été supprimées et qu'une seule requête de certificat est disponible pour le certificat apigee-serving-cert dans l'espace de noms apigee-system : 
    kubectl -n apigee-system get certificaterequests
  3. Vérifiez que le certificat apigee-serving-cert a été renouvelé : 
    kubectl -n apigee-system get certificates apigee-serving-cert -o yaml

    Exemple de résultat :

    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

Cause : Le contrôleur cert-manager n'est pas opérationnel

Diagnostic

  1. Vérifiez l'état des pods cert-manager dans l'espace de noms cert-manager : 
    kubectl -n cert-manager get pods

    Des pods cert-manager opérationnels sont reconnaissables comme suit : tous les pods cert-manager doivent être prêts (1/1) et à l'état Running. Si ce n'est pas le cas, il peut s'agir de la raison de ce problème : 

    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. Le contrôleur cert-manager peut échouer pour de nombreuses raisons. Consultez les journaux cert-manager afin d'identifier la raison de l'échec, puis faites le nécessaire pour le résoudre.

    L'une des raisons connues pour l'échec du contrôleur cert-manager est l'impossibilité de communiquer avec l'API Kubernetes. Dans ce cas, un message d'erreur semblable au suivant s'affiche : 

    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

Solution

  1. Vérifiez l'état du cluster Kubernetes et corrigez les problèmes détectés. Consultez la page Résoudre les problèmes liés aux clusters.
  2. Consultez la page Dépannage pour plus d'informations sur la résolution des problèmes liés au contrôleur cert-manager.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez Google Cloud Customer Care :

  1. ID de projet Google Cloud
  2. Organisation Apigee hybrid
  3. Fichier Apigee hybrid overrides.yaml, en veillant à masquer toutes les informations sensibles.
  4. État du pod Kubernetes dans tous les espaces de noms : 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Fichier de vidage Kubernetescluster-info : 
    # 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/*