As implantações do proxy de API falham indicando que o apigee-serving-cert não foi encontrado ou está expirado

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

Sintomas

As implantações de proxy de API falham com as mensagens de erro a seguir.

Mensagens de erro

Se o certificado TLS do serviço apigee-webhook-service.apigee-system.svc tiver expirado ou ainda não for válido, a seguinte mensagem de erro será exibida nos 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 possíveis

Causa Descrição
O apigee-serving-cert não foi encontrado Se apigee-serving-cert não for encontrado no namespace apigee-system, o problema poderá ocorrer.
Solicitações de certificado duplicadas foram criadas para renovar apigee-serving-cert Se solicitações duplicadas forem criadas para renovar o certificado apigee-serving-cert, o certificado apigee-serving-cert talvez não seja renovado.
O cert-manager não está íntegro Se cert-manager não estiver íntegro, o certificado apigee-serving-cert poderá não ser renovado.

Causa: o apigee-serving-cert não foi encontrado

Diagnóstico

  1. Verifique a disponibilidade do certificado apigee-serving-cert no namespace apigee-system: 

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

    Se o certificado estiver disponível, uma resposta semelhante a esta será exibida: 

    NAME                  READY   SECRET                AGE
apigee-serving-cert   True    webhook-server-cert   2d10h
  2. Se o certificado apigee-serving-cert não for encontrado no namespace apigee-system, esse poderá ser o motivo do problema.

Resolução

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

    Inclua todas as configurações mostradas, incluindo --atomic, para que a ação seja revertida em caso de falha.

  2. Verifique se o certificado apigee-serving-cert foi criado: 
    kubectl -n apigee-system get certificates apigee-serving-cert

Causa: solicitações de certificado duplicadas foram criadas para renovar o apigee-serving-cert

Diagnóstico

  1. Verifique os registros do controlador cert-manager e confira se alguma mensagem de erro semelhante à seguinte foi retornada.

    Liste todos os pods cert-manager:

    kubectl -n cert-manager get pods

    Um exemplo de saída:

    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

    Verifique os registros do controlador cert-manager:

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

    Exemplos de saídas:

    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"

    Se você receber uma das mensagens acima, os certificados apigee-serving-cert e apigee-istiod-cert não serão renovados.

  2. Liste todas as solicitações de certificado no namespace apigee-system ou apigee, dependendo do namespace impresso nas entradas de registro acima, e verifique se várias solicitações foram criadas para renovar as mesmas revisões de certificado apigee-serving-cert ou apigee-istiod-cert: 
    kubectl -n apigee-system get certificaterequests

Confira o problema cert-manager relevante para essa questão em O cert-manager criou vários objetos CertificateRequest com a mesma certificate-revision.

Resolução

  1. Exclua todas as solicitações de certificado no namespace apigee-system: 
    kubectl -n apigee-system delete certificaterequests --all
  2. Verifique se as solicitações de certificado duplicadas foram excluídas e se apenas uma solicitação está disponível para o certificado apigee-serving-cert no namespace apigee-system: 
    kubectl -n apigee-system get certificaterequests
  3. Verifique se o certificado apigee-serving-cert foi renovado: 
    kubectl -n apigee-system get certificates apigee-serving-cert -o yaml

    Um exemplo de saída:

    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: o cert-manager não está íntegro

Diagnóstico

  1. Verifique a integridade dos pods cert-manager no namespace cert-manager: 
    kubectl -n cert-manager get pods

    Se os pods cert-manager estiverem íntegros, todos os pods cert-manager estarão prontos (1/1) e no estado Running. Caso contrário, esse poderá ser o motivo do 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. O cert-manager pode falhar por vários motivos. Verifique os registros cert-manager, identifique o motivo da falha e resolva o problema adequadamente.

    Um motivo conhecido é que o cert-manager falhará se não conseguir se comunicar com a API Kubernetes. Nesse caso, uma mensagem de erro semelhante a esta será exibida: 

    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

Resolução

  1. Verifique a integridade do cluster do Kubernetes e corrija os problemas encontrados. Consulte Solução de problemas de clusters.
  2. Consulte Solução de problemas para mais informações sobre a solução de problemas do cert-manager.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte do Google Cloud.

  1. Google Cloud ID do projeto
  2. Organização da Apigee híbrida
  3. Arquivo overrides.yaml da Apigee híbrida, mascarando todas as informações sensíveis.
  4. Status do pod do Kubernetes em todos os namespaces: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Despejo do cluster-info do 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/*