Résoudre les problèmes liés au blocage d'Apigee hybrid lors de la création ou de la publication de l'état

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Il n'existe pas de documentation Apigee Edge équivalente pour ce sujet.

Ce document explique comment réinitialiser les composants Apigee hybrid lorsqu'ils sont bloqués à l'état creating ou releasing.

Exécutez la commande suivante pour répertorier les principaux composants d'installation d'Apigee hybrid :

kubectl get crd | grep apigee

apigeeorganization (apigeeorganizations.apigee.cloud.google.com)
apigeeenvironment (apigeeenvironments.apigee.cloud.google.com)
apigeedatastore (apigeedatastores.apigee.cloud.google.com)
apigeetelemetries (apigeetelemetries.apigee.cloud.google.com)
apigeeredis (apigeeredis.apigee.cloud.google.com)

Exécutez la commande suivante pour afficher l'état actuel :

kubectl get apigeedatastore -n NAMESPACE

Lorsqu'ils sont totalement fonctionnels, chacun de ces composants est à l'état running. Exemple :

NAME      STATE     AGE
default   running   5d6h

Si l'installation échoue, les composants peuvent être bloqués à l'état creating (ou releasing). Exemple :

NAME      STATE     AGE
default   creating   5d6h

Identifier le problème

Pour identifier la cause du problème, commencez par décrire chaque composant. Les composants sont structurés comme suit :

Chaque ressource personnalisée ApigeeOrganization est représentée par la hiérarchie suivante :

ApigeeOrganization/HASHED_VALUE
├─ApigeeDeployment/apigee-connect-agent-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-connect-agent-HASHED_VALUE
│ ├─ReplicaSet/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-connect-agent-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-mart-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-mart-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-mart-HASHED_VALUE
│ ├─ReplicaSet/apigee-mart-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-mart-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-watcher-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-watcher-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-watcher-HASHED_VALUE
│ ├─ReplicaSet/apigee-watcher-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-watcher-HASHED_VALUE-VER-xxxx

Chaque ressource personnalisée ApigeeEnvironment est représentée par la hiérarchie suivante :

ApigeeEnvironment/HASHED_VALUE
├─ApigeeDeployment/apigee-runtime-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-runtime-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-runtime-HASHED_VALUE
│ ├─ReplicaSet/apigee-runtime-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-runtime-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-synchronizer-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-synchronizer-HASHED_VALUE
│ ├─ReplicaSet/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-synchronizer-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-udca-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-udca-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-udca-HASHED_VALUE
│ ├─ReplicaSet/apigee-udca-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-udca-HASHED_VALUE-VER-xxxx

Commencez par identifier le problème en décrivant le composant racine. Exemple :

kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME

Vérifiez si la valeur State du composant est running :

      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  State:            running
Events:             <none>

Si aucun événement n'est enregistré à ce niveau, répétez le processus avec apigeedeployments suivi de ReplicaSet. Exemple :

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

Si apigeedeployments et ReplicaSet n'affichent aucune erreur, concentrez-vous sur les pods qui ne sont pas prêts :

kubectl get pods -n NAMESPACE

NAME                                                              READY   STATUS
apigee-cassandra-default-0                                        1/1     Running
apigee-connect-agent-apigee-b56a362-150rc2-42gax-dbrrn            1/1     Running
apigee-logger-apigee-telemetry-s48kb                              1/1     Running
apigee-mart-apigee-b56a362-150rc2-bcizm-7jv6w                     0/2     Running
apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb29             0/1     Running

Dans cet exemple, mart et runtime ne sont pas prêts. Inspectez les journaux des pods pour identifier les erreurs :

kubectl logs -n NAMESPACE POD_NAME

Supprimer des composants

Si vous avez commis une erreur avec l'un de ces composants, il vous suffit de le supprimer et d'appliquer apigeectl sur ce composant. Par exemple, pour supprimer un environnement, procédez comme suit :

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

Créez ensuite l'environnement (après avoir apporté les corrections nécessaires) :

apigeectl apply -f overrides.yaml –env=$ENV

Inspecter le contrôleur

Si le pod ne comporte aucun message d'erreur évident, mais que le composant n'est pas passé à l'état running, recherchez des messages d'erreur sur le contrôleur apigee-controller. Le contrôleur apigee-controller s'exécute dans l'espace de noms apigee-system.

kubectl logs -n apigee-system $(k get pods -n apigee-system | sed -n '2p' | awk '{print $1}') | grep -i error

Cela permet à l'utilisateur de voir pourquoi le contrôleur n'a pas pu traiter la requête (create/delete/update, etc.).

Datastore Apigee

Apache Cassandra est implémenté en tant que StatefulSet. Chaque instance Cassandra contient :

ApigeeDatastore/default
├─Certificate/apigee-cassandra-default
│ └─CertificateRequest/apigee-cassandra-default-wnd7s
├─Secret/config-cassandra-default
├─Service/apigee-cassandra-default
│ ├─EndpointSlice/apigee-cassandra-default-7m9kx
│ └─EndpointSlice/apigee-cassandra-default-gzqpr
└─StatefulSet/apigee-cassandra-default
  ├─ControllerRevision/apigee-cassandra-default-6976b77bd
  ├─ControllerRevision/apigee-cassandra-default-7fc76588cb
  └─Pod/apigee-cassandra-default-0

Cet exemple montre un pod. Cependant, les installations de production classiques contiennent au moins trois pods.

Si l'état de Cassandra est creating ou releasing, il DOIT être réinitialisé. Certains problèmes (tels que les modifications de mot de passe Cassandra) et les problèmes non liés à la mise en réseau peuvent nécessiter la suppression de composants. Dans ce cas, il est tout à fait possible que vous ne puissiez pas supprimer l'instance (c'est-à-dire, kubectl delete apigeedatastore -n NAMESPACE default). L'utilisation de --force ou --grace-period=0 ne résout pas non plus le problème.

L'objectif de reset est de faire passer l'état du composant (apigeedatastore) de creating ou releasing à running. Modifier l'état de cette manière ne résout généralement pas le problème sous-jacent. Dans la plupart des cas, le composant doit être supprimé après une réinitialisation.

Avertissement : La suppression de apigeedatastore entraîne également la suppression des volumes persistants. Toutes les données de Cassandra seront perdues. Il est recommandé de sauvegarder les données Cassandra.

Essayez d'effectuer une suppression (cette opération échouera) :
```
kubectl delete -n NAMESPACE apigeedatastore default
```
Il est fréquent que cette commande ne se termine pas. Appuyez sur Ctrl+C pour mettre fin à l'appel.

Réinitialisez l'état :

Dans la fenêtre 1 :

kubectl proxy

Dans la fenêtre 2 :

curl -X PATCH -H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'

Supprimez le finaliseur (fenêtre 2) :

kubectl edit -n NAMESPACE apigeedatastore default

Recherchez les deux lignes suivantes et supprimez-les :

finalizers:
- apigeedatastore.apigee.cloud.google.com

Scénarios d'erreur courants

Configuration du proxy non disponible avec l'environnement d'exécution

Cette erreur peut se manifester de deux manières :

L'état de runtime n'est pas ready.
runtime n'a pas reçu la dernière version de l'API.

Commencez avec les pods synchronizer.

Inspectez les journaux de synchronizer. Voici les erreurs fréquentes :
- Connectivité réseau insuffisante (vers *.googleapi.com)
- Accès IAM incorrect (compte de service non disponible ou fourni par l'autorisation "Gestionnaire de synchronisateur")
- L'API setSyncAuthorization n'a pas été appelée
Inspectez les pods runtime.

L'inspection des journaux à partir des pods runtime indique pourquoi runtime n'a pas chargé la configuration. Le plan de contrôle tente d'empêcher la plupart des erreurs de configuration d'atteindre le plan de données. Dans les cas où une validation est impossible ou n'est pas correctement mise en œuvre, le pod runtime ne parvient pas à la charger.

"Aucun pod d'exécution" dans le plan de contrôle

Commencez avec les pods synchronizer.

Inspectez les journaux de synchronizer. Voici les erreurs fréquentes :
- Connectivité réseau insuffisante (vers *.googleapi.com)
- Accès IAM incorrect (compte de service non disponible ou fourni par l'autorisation "Gestionnaire de synchronisateur")
- L'API setSyncAuthorization n'a pas été appelée. La configuration n'a peut-être jamais atteint le plan de données.
Inspectez les pods runtime.

L'inspection des journaux à partir des pods runtime indique pourquoi runtime n'a pas chargé la configuration.
Inspectez les pods watcher.

Il s'agit du composant watcher qui configure l'entrée (routage), et indique l'état du déploiement de l'entrée et du proxy au plan de contrôle. Examinez ces journaux pour savoir pourquoi watcher ne signale pas l'état. Parmi les principales raisons possibles, citons une incohérence entre les noms du fichier overrides.yaml et le plan de contrôle pour le nom de l'environnement et/ou du groupe d'environnements.

La session de débogage ne s'affiche pas dans le plan de contrôle

Commencez avec les pods synchronizer.

Inspectez les journaux de synchronizer. Voici les erreurs fréquentes :
- Connectivité réseau insuffisante (vers *.googleapi.com)
- Accès IAM incorrect (compte de service non disponible ou fourni par l'autorisation "Gestionnaire de synchronisateur")
- L'API setSyncAuthorization n'a pas été appelée.
Inspectez les pods runtime.
L'inspection des journaux des pods runtime montre pourquoi runtime n'envoie pas de journaux de débogage à UDCA.
Inspectez les pods UDCA.
L'inspection des journaux de l'UDCA indique pourquoi UDCA n'envoie pas d'informations de session de débogage au plan de contrôle.

Cassandra renvoie des réponses de cache volumineuses

Le message d'avertissement suivant indique que Cassandra reçoit des requêtes de lecture ou d'écriture avec une charge utile plus importante et peut être ignoré en toute sécurité, car ce seuil d'avertissement est défini sur une valeur inférieure pour indiquer les tailles de charge utile de réponse.

Batch for [cache_ahg_gap_prod_hybrid.cache_map_keys_descriptor, cache_ahg_gap_prod_hybrid.cache_map_entry] is of size 79.465KiB, exceeding specified threshold of 50.000KiB by 29.465KiB