AKS : Problème critique avec le composant managé tigera-operator (Calico) en boucle de redémarrage

Question

Je rencontre actuellement un problème critique sur un cluster AKS managé concernant le composant tigera-operator (Calico). Ce composant est en crash-loop constant, et je ne peux ni le réparer ni le supprimer car il s'agit d’un composant managé par le service AKS.

Ce composant est en crash-loop constant, et je ne peux ni le réparer ni le supprimer car il s'agit d’un composant managé par le service AKS.

Contexte :

• Cluster AKS
• CNI choisi à l'installation : Calico
• Suite à une tentative de suppression accidentelle de l’objet Installation (installations.operator.tigera.io/default), le pod tigera-operator s’est mis à redémarrer en boucle.
• Le service account tigera-operator n’a plus les permissions suffisantes pour modifier les CRDs Calico (erreurs is forbidden sur customresourcedefinitions.apiextensions.k8s.io).
• J’ai tenté de réappliquer les manifests YAML, mais le comportement reste le même.
• Je ne peux pas ouvrir de ticket via le portail Azure (problème d’accès ou restrictions d’abonnement).

Conséquences actuelles :

• Le composant Calico tigera-operator est non fonctionnel.
• Les pods réseau Calico (calico-node) semblent fonctionner, mais l’état général du CNI est incertain.
• Je crains un comportement instable à moyen terme sur mon cluster de production.

__
Que faire pour réaliser une réinstallation propre de l'operator tigera afin de corriger ce problème ?__

Answer 1

Maxime GUADAGNA •

AKS avec Calico CNI (et non kubenet, ce qui signifie que vous avez choisi l'intégration native de Calico lors de la création du cluster).

Le tigera-operator est en état CrashLoopBackOff parce que :

Il est probable que son compte de service n'ait plus la permission de gérer les Calico CRD (CustomResourceDefinitions.apiextensions.k8s.io).

Cela peut être dû à une suppression accidentelle ou à une rupture des liens RBAC.

Vous ne pouvez pas le supprimer ou le patcher manuellement car c'est un composant géré d'AKS.

Collectez les diagnostics :

kubectl get pods -n tigera-operator
kubectl describe pod <tigera-operator-pod> -n tigera-operator
kubectl logs <tigera-operator-pod> -n tigera-operator

kubectl get installations.operator.tigera.io
kubectl describe installations.operator.tigera.io default

Quels sont les messages d'erreur exacts dans les journaux ?

Le CR d'installation par défaut est-il présent ?

Le compte de service et le rolebinding sont-ils toujours présents ?

kubectl get serviceaccount -n tigera-operator
kubectl get clusterrole tigera-operator
kubectl get clusterrolebinding tigera-operator

Vous pouvez essayer de recréer le ClusterRole, le ClusterRoleBinding ou le ServiceAccount manquants s'ils ont été supprimés ou endommagés. AKS ne vous empêche pas de restaurer ces éléments manuellement.

Vous ne pouvez pas supprimer directement le déploiement tigera-operator, mais vous pouvez le réduire à 0, puis supprimer les ressources dans le namespace tigera-operator, réappliquer les manifestes YAML propres (ou les récupérer depuis un cluster AKS fonctionnel de la même version).

Réduire l'opérateur à 0 :

kubectl scale deployment tigera-operator -n tigera-operator --replicas=0

Nettoyer les CRD problématiques si nécessaire :

kubectl delete installations.operator.tigera.io default

Réappliquer les manifestes de l'opérateur (obtenez-les depuis les versions de Tigera correspondant à votre version AKS).

Remonter l'opérateur à 1 :

kubectl scale deployment tigera-operator -n tigera-operator --replicas=1

Validez le compte de service et RBAC actuels.

Recréez les RBAC et CRD manquants.

Réappliquez le CR d'installation.

Réduisez l'opérateur, nettoyez les objets cassés, réappliquez les manifestes, puis remontez-le.

https://docs.tigera.io/calico/latest/getting-started/kubernetes/quickstart

Si vous avez trouvé l'information utile, veuillez cliquer sur "Vote positif" et "Accepter la réponse" sur le post pour nous le faire savoir. Merci.

Answer 2

Je vous remercie pour votre aide et toutes ces informations.