Postmortem
Résumé
- Impact utilisateurice : certains services (visio, nuage, …) deviennent inacessibles ou instables.
- Cause : Une partie du trafic réseau passant par le réseau privé (vSwitch) du load balancer était perdu.
- Résolution : Modification du routage de Kubernetes pour passer par l’IP publique du load balancer au lieu du réseau privé.
Il y a un glossaire en bas du post pour expliquer les termes techniques.
Durées
| Start Time | Incident Detected By(User-reported/ Ad-hoc monitoring/ Alerting system) |
|---|---|
| Durée de détection : <5min | L’incident a démarré lors du redémarrage d’un service par un de nos opérateurs. La détection de l’incident a donc été immédiate. |
| Durée d’investigation : 19h | La source de l’erreur et son contournement trouvés 20h après la détection |
| Durée du retour à un service fonctionnel : 20h | Une fois le workaround appliqué progressivement les services sont revenus dans l’heure suivante |
| Durée de résolution : 2,5 jours | Certains services étaient encore un peu lent jusqu’à la résolution finale le 10/02 à |
Chronologie
| Date | Quoi |
|---|---|
| Vendredi 07/02 14h30 | Erreur de création d’un pod à cause d’une erreur réseau. |
| 14h30 | Redémarrage du pod calico |
| 14h45 | Alerte sur Calico. Echec du redémarrage du pod |
| 15h | Début de l’incident réseau |
| 15h10 | Communication de l’incident sur le chat Entraide Liiibre (@liiibre-entraide:liiib.re) |
| 16h | Il est clair dans les logs que le pod calico est reparti mais qu’il y a toujours des erreurs de conflit d’IPs. |
| 16h30 | Communication de l’incident sur le Forum |
| 17h20 | Le noeud p12 n’a aucun pod en Running Les noeuds p2, p5, p6, p9, p10 ont tous leurs pods en Running Les autres noeuds ont certains pods OK et d’autres KO |
| 18h | Il devient clair dans les logs, que le pod calico ne peut accéder à l’API kubernetes, et ce chemin réseau passe par le réseau privé du cluster. |
| 21h30 | Certains noeuds ne ping pas internet en IPv4, seulement IPv6. |
| 22h30 | Modification de la config /etc/sysctl.d/kubernetes.conf sur p3 => résultat: Maintenant p3 ping en IPv4. |
| 23h | Test de faire pointer calico sur l’IP publique de l’API de kubernetes, le lien fonctionne, mais le mTLS non. |
| 01h19 | Fin des investigations pour la soirée. |
| Samedi 08/02 09h30 | Réunion d’équipe pour définir le plan d’action |
| 10h06 | Mise à jour de debian sur p3 et passage de Calico sur le mode IPVS plutôt que iptables, pas d’amélioration |
| 10h19 | Changement de l’IP de l’api server kubernetes dans calico sur l’IP publique plutôt que l’IP privé, calico fonctionne normalement. |
| 10h20 | Procédure appliquée sur tous les noeuds - mise à jours debian, ip publique, ipvs et reboot |
| 12h20 | fin de la procédure, et retour de la plupart des services à un fonctionnement normal. |
| 14h | mise à jour des OS de tous les noeuds |
| 15h | mise à jour de la version de kubernetes |
| 17h10 | fin des interventions pour le weekend. |
| Lundi 10/02 9h40 | Un contrib nous prévient de forts ralentissements sur leur nuage |
| 9h50 | Nous détectons des erreurs d’accès à des fichiers et des serveurs de bases de données secondaires qui ne répondent pas (pas d’impact direct sur le service). |
| 10h40 | Un des serveurs de stockage MinIO avait des erreurs. Suite à son redémarrage les services reviennent à leur état nominal |
| 17h35 | Fin de redémarrage des pods secondaires postgres en erreur. |
Impact
Impact sur les utilisateurices
Indisponibilité d’une partie des services pendant toute la durée de l’incident.
Impact sur l’infrastructure
Les backups Postgres (sauvegardes de la base de données) n’ont pas tournés pendant l’incident.
Cause de l’incident
- Une partie du trafic réseau passant par le réseau privé (vSwitch) du load balancer était perdu.
Mitigation & Résolution
- Se passer du réseau privé.
- Utiliser IPVS plutot que iptable
Leçons apprises
Ce qui s’est bien passé
- Réactivité et disponibilité de l’équipe technique.
- incident en fin de semaine => moins d’utilisatrices impactées.
- la moitié des services étaient UP
Ce qui s’est mal passé
-
la compléxité de notre stack réseau:
- calico (vxlan)
- wireguard (vpn chiffré)
- kube proxy (iptable / ipvs)
- reseau privé hetzner (vswitch)
- interface publique
-
la moitié des services était UP (dont le cluster de stockage), cela nous a empeché de prendre des décisions radicales, mais qui auraient été plus efficaces.
Actions
Actions à mettre en place
- [Fait] Migrer l’architecture réseeau vers IP publiques
Glossaire des termes techniques
- Kubernetes : Kubernetes est un logiciel qui permet de faire l’abstraction de la partie matérielle. Il peut être vu comme un hyperviseur permettant d’ordonnancer des containeurs.
- Pod : Pod est un élement de Kubernetes. C’est un ensemble cohérent de containeurs pour une application. Dans notre infrastructure, pour une application comme Nextcloud, nous avons plusieurs pods (2 pour la base de données, 2 pour le redis, 2 à 10 pour l’application).
- Calico : Gère le réseau virtuel dans Kubernetes sous forme de vxlan (encapsulation par dessus le vlan)
- Kubeproxy : Gestion du traffic réseau par Kubernetes. Plusieurs modes sont configurables comme iptable ou ipvs.
- vSwitch : Switch virtuel configuré sur l’IP privé du load balancer d’Hetzner.
- Wireguard : Tunnel VPN chiffré.
- MinIO : Logiciel d’exploitation de notre cluster de stockage. Implémentation libre du « standard de fait » Amazon Object Store S3, qui stocke les données sous forme d’objets. Contrairement aux technologies classiques de systèmes de fichiers qui stocke les données sous forme de dossiers et de fichiers. Permet une meilleure efficacité de stockage et un versionnage plus fin.