As implementações de proxy de API falham com o erro apigee-serving-cert is not found or expired

Está a ver a documentação do Apigee e do Apigee Hybrid.
Ver documentação do Apigee Edge.

Sintomas

As implementações de proxy de API falham com as seguintes mensagens de erro.

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, é apresentada a seguinte mensagem de erro nos registos 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
The apigee-serving-cert is not found Se o apigee-serving-cert não for encontrado no espaço de nomes apigee-system, este problema pode ocorrer.
Foram criados pedidos de certificados duplicados para a renovação de apigee-serving-cert Se forem criados pedidos de certificados duplicados para renovar o certificado apigee-serving-cert, o certificado apigee-serving-cert pode não ser renovado.
O cert-manager não está em bom estado Se cert-manager não estiver em bom estado, o certificado apigee-serving-cert pode não ser renovado.

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

Diagnóstico

  1. Verifique a disponibilidade do certificado apigee-serving-cert no espaço de nomes apigee-system: 

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

    Se este certificado estiver disponível, deve ver um resultado semelhante ao seguinte: 

    NAME                  READY   SECRET                AGE
apigee-serving-cert   True    webhook-server-cert   2d10h
  2. Se o certificado apigee-serving-cert não for encontrado no espaço de nomes apigee-system, esse pode ser o motivo deste problema.

Resolução

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

    Certifique-se de que inclui todas as definições apresentadas, 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: foram criados pedidos de certificados duplicados para a renovação de apigee-serving-cert

Diagnóstico

  1. Verifique os registos do controlador e veja se foi devolvida uma mensagem de erro semelhante à seguinte.cert-manager

    Apresente todos os agrupamentos de anúncios cert-manager:

    kubectl -n cert-manager get pods

    Exemplo de resultado:

    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 registos do comando cert-manager:

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

    Exemplos de resultados:

    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 vir qualquer uma das mensagens apresentadas acima, os certificados apigee-serving-cert e apigee-istiod-cert não são renovados.

  2. Liste todos os pedidos de certificados no espaço de nomes apigee-system ou no espaço de nomes apigee, consoante o espaço de nomes impresso nas entradas do registo acima, e verifique se existem vários pedidos de certificados criados para renovar as mesmas revisões de certificados apigee-serving-cert ou apigee-istiod-cert: 
    kubectl -n apigee-system get certificaterequests

Consulte o problema cert-managerrelevante para este problema em O cert-manager criou vários objetos CertificateRequest com a mesma certificate-revision.

Resolução

  1. Elimine todos os pedidos de certificados no espaço de nomes apigee-system: 
    kubectl -n apigee-system delete certificaterequests --all
  2. Verifique se os pedidos de certificados duplicados foram eliminados e se apenas um pedido de certificado está disponível para o certificado apigee-serving-cert no espaço de nomes 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

    Exemplo de resultado:

    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á em bom estado

Diagnóstico

  1. Verifique o estado dos pods cert-manager no espaço de nomes cert-manager: 
    kubectl -n cert-manager get pods

    Se os pods cert-manager estiverem em bom estado, todos os pods cert-manager devem estar prontos (1/1) e no estado Running. Caso contrário, pode ser o motivo deste 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. A cert-manager pode falhar por vários motivos. Verifique os registos cert-manager e identifique o motivo da falha, resolvendo-o em conformidade.

    Um motivo conhecido é que o cert-manager falha se não conseguir comunicar com a API Kubernetes. Neste caso, é apresentada uma mensagem de erro semelhante à seguinte: 

    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 o estado do cluster do Kubernetes e corrija os problemas encontrados. Consulte o artigo Resolução de problemas de clusters.
  2. Consulte a secção Resolução de problemas para ver cert-manager informações adicionais sobre a resolução de problemas.

Tem de recolher informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, recolha as seguintes informações de diagnóstico e, em seguida, contacte o apoio ao cliente do Google Cloud.

  1. Google Cloud ID do projeto
  2. Organização do Apigee Hybrid
  3. Ficheiro overrides.yaml do Apigee hybrid, ocultando quaisquer informações confidenciais.
  4. Estado do pod do Kubernetes em todos os namespaces: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Captura do Kubernetes cluster-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/*