Aller plus loin

1. Quand le désastre arrive

Figure 1 : Quand le pire arrive

Quand on parle de haute disponibilité, on parle souvent, en parallèle, de reprise d’activité, d’où l’expression HA-DR (High Availability-Disaster Recovery).

Si le but de la haute disponibilité est de garantir la disponibilité des applications dans le plus grand nombre de cas de figure possible, il faut aussi prévoir ce qui semble parfois improbable : une panne majeure qui conduit à l’indisponibilité partielle ou totale du service, voire à sa destruction totale.

C’est souvent une leçon apprise trop tard : il ne faut jamais pécher par excès de confiance. Rappelons la loi de Murphy : tout ce qui est susceptible d’aller mal ira mal. Et le corollaire de Finagle (qui est un personnage de fiction) : tout ce qui peut aller mal arrivera au pire moment. Rappelons aussi qu’il existe deux sortes d’ingénieurs système : ceux qui ont fait une énorme bêtise et ceux qui vont la faire.

Les auteurs ont eu l’occasion d’expérimenter en production réelle divers cas de figure. Les métiers liés à la production informatique mettent parfois les nerfs à rude épreuve. Comment réagir lorsqu’on perd l’interconnexion entre deux centres de données ? Comment réagir lorsque quelqu’un éteint tous les répartiteurs de charge en même temps, coupant ainsi intégralement les accès à l’ensemble des serveurs ?

Tout système créé par un être humain est forcément imparfait. La plupart des incidents et accidents sont d’ailleurs le fait d’interventions humaines, involontaires ou non.

Quand tout va mal, que tout est perdu, il faut alors penser au plan B, voire au plan C. Comment redémarrer ? En ayant anticipé la catastrophe et mis en place un plan de redémarrage des services.

2. Définition

Un plan de reprise d’activité ou PRA (Disaster Recovery Plan ou DRP) est un ensemble de procédures décrites à l’avance permettant de reconstruire un système d’information et de rétablir les services en cas de sinistre.

Un sinistre est un événement impondérable et imprévu : catastrophe naturelle (tremblement de terre, inondation, tempête, tsunami, ouragan, canicule…), vol, attentat, sabotage, incendie, dégât des eaux… mais aussi acte de malveillance (dégradation volontaire, piratage, demande de rançon, effacement des données, virus, malware). Il faut aussi penser à l’erreur humaine dont les conséquences peuvent être désastreuses (effacement de données, extinction de serveurs…).

Il n’y a pas une semaine sans qu’une compagnie, un hôpital, une mairie ou un service public, perdent toutes leurs données à la suite d’une attaque informatique.

Tous ces événements doivent être répertoriés et anticipés.

HA et DR peuvent-ils fonctionner de concert ? Oui, si l’architecture technique, fonctionnelle et la topologie des datacenters et des applications le permettent. En pratique cependant, même des déploiements multizones en actif-actif présentent parfois des points faibles. Il faut souvent mettre en place une reprise manuelle en cas d’incident.

3. Mesures

Les mesures de base d’un PRA sont la prévention, la détection et la correction. Tout ceci s’inscrit dans le cadre global de l’anticipation des événements : il faut être proactif.

1. Redondance vs sauvegarde

Il est très important de souligner cette évidence. Les événements de mars 2021 qui ont conduit à la perte définitive de milliers de sites web et de services, voire à la perte de l’ensemble des données de certaines entreprises, sont un nouveau rappel à l’ordre.

Figure 3 : Pas de sauvegarde... Le désespoir à la suite de la perte d’un centre de données 

Que ce soit sur le cloud ou dans un datacenter qui vous appartient, les sauvegardes sont nécessaires et vitales. Dans un monde devenu numérique, la donnée est le composant vital de toute organisation, mais pas seulement. Combien de drames sont liés à la perte des photos de famille à la suite du crash d’une application, à la défaillance d’une clé USB, d’une carte mémoire, d’un disque dur ?

Les sauvegardes doivent être externalisées : elles ne doivent pas se situer sur le même centre de données que les serveurs. Si possible, elles doivent être disponibles en double exemplaire. Sur un cloud, on peut utiliser des volumes particuliers dupliqués entre plusieurs zones et régions pour garantir leur disponibilité. Sous AWS par exemple, des buckets S3 peuvent être répliqués entre plusieurs régions, et même entre buckets.

La même chose existe bien sûr sur Azure, où les données et les sauvegardes peuvent être répliquées selon plusieurs modèles, au sein d’une même région, entre plusieurs zones, et entre plusieurs régions. Les sauvegardes doivent être testées : on s’assure régulièrement qu’elles sont accessibles et disponibles, que les données peuvent être restaurées, notamment en cas de montée de version. Il arrive qu’une version n+1 ne puisse plus relire les anciennes données. On s’assurera alors de pouvoir réinstaller une version du logiciel pouvant relire ces données. On met en place un plan de sauvegarde qui définit :

2. Que sauvegarder ?

Tout sauvegarder n’a pas toujours du sens. Si on est capable de restaurer intégralement des serveurs via des processus d’automatisation, parce que ces serveurs sont normalisés, alors il est plus pertinent de faire une sauvegarde de ces processus que des serveurs eux-mêmes. Sur le cloud ou pour des machines virtuelles, on peut cependant s’appuyer sur des mécanismes de snapshots pour sauvegarder une machine dans un état donné.

Doit-on sauver les images applicatives, ou leur code, leur Dockerfile et les scripts de build ? Si on est capable de reconstruire rapidement les images, alors pourquoi pas... Mais si on parle de centaines d’images à reconstruire, peut-être est-il pertinent de sauver les artefacts complets.

Dans notre cas, par exemple, il y a plusieurs dépendances externes des images Docker. D’abord l’image de base (tomcat:10.1-jre21-temurin), puis les éléments de build (maven:3.9-eclipse-temurin-21), et enfin les JAR du projet.

Pour les données (bases de données, fichiers dépendants, assets statiques, par exemple les fichiers téléchargés de eni-todo), la question ne se pose même pas : il faut sauvegarder.

Quant à Kubernetes, il existe plusieurs stratégies de sauvegarde, qui incluent d’ailleurs les précédentes. Si on dispose de tous les fichiers YAML pour recréer nos projets, c’est très bien. Mais il ne faut pas oublier que la configuration de Kubernetes est intégralement placée dans une base etcd.

Kubernetes a des dépendances extérieures. Si les volumes persistants et les demandes de volumes persistants sont bien des objets Kubernetes, les données qui y sont stockées ne le sont pas.

On sauvegardera les volumes persistants.

3. GitOps

Le GitOps est une pratique qui consiste à stocker la configuration de ses composants d’infrastructure dans un dépôt...

1. Container et root

$ docker run --name some-nginx -d nginx 
... 
11a90c92c2c3b3507fa5068198a780bf9be39a74df5f427f8a601945c9d15a54 

$ docker exec -ti 11a90c92c2c3 bash 
root@11a90c92c2c3:/# id 
uid=0(root) gid=0(root) groups=0(root) 

seb@infra01:~$ docker run --name some-nginx -v /etc:/mnt/etc -d 
9f4d178c388e3df5e8e0f68137054339e7b0a0fbd8562245ddf4263fd7685cbd 
seb@infra01:~$ docker exec -ti 9f4d178c388e3 bash 
root@9f4d178c388e:/# echo "seb ALL=(ALL) NOPASSWD: ALL" > 
/mnt/etc/sudoers.d/seb 
root@9f4d178c388e:/# exit 
exit 
seb@infra01:~$ sudo -l 
User seb may run the following commands on infra01: 
    (ALL) NOPASSWD: ALL 

RUN useradd -ms /bin/bash my_user 
USER my_user 

$ docker run --user 1001:1001 ... 

$ cat /etc/subuid 
seb:100000:65536 

{ 
  "userns-remap": "seb" 
} 

$ sudo systemctl restart docker 

$ docker run --name some-nginx2 -d nginx 
$ docker exec -ti 79f9b398aa94 bash 
root@79f9b398aa94:/# id 
uid=0(root) gid=0(root) groups=0(root) 
root@79f9b398aa94:/# exit 
 
seb@infra01:~$ ps ax -o cmd,uid | grep nginx 
nginx: master process nginx 100000 
nginx: worker process       100101 

apiVersion: v1 
kind: Pod 
metadata: 
  name: secure-eni-todo 
spec: 
  securityContext: 
    runAsUser: 1001 
    runAsGroup: 1001 
    fsGroup: 1001 

2. Réseau Kubernetes

Kubernetes s’appuie sur un modèle réseau flexible permettant de disposer de ses propres modèles et contrôleurs. Nous avons utilisé Flannel parce qu’il est simple et efficace pour illustrer tous les exemples de ce livre. Mais Flannel n’offre aucune protection spécifique, aucune segmentation entre les pods, les services, les namespaces. Nous avons pu illustrer très simplement ce fait en autorisant eni-todo à se connecter au service de base de données Galera qui fait pourtant partie d’un autre namespace : Flannel ne propose aucune isolation réseau.

Si ce n’est pas un problème dans le cadre d’un cluster Kubernetes entièrement dédié à notre application, ça l’est si le cluster a pour vocation d’être multienvironnement (développement, intégration, production...) et multiclient, avec des projets bien distincts devant être isolés.

Kubertenes dispose...

1. Métriques

Les métriques sont essentiellement la collecte d’informations sur les processeurs, la mémoire, les disques et le réseau afin d’en vérifier les performances. Grâce à ces valeurs et à leur suivi, il devient possible d’analyser les consommations des différentes ressources et d’agir en conséquence :

La surveillance des métriques se fait souvent avec des outils de monitoring et des sondes comme Nagios et Centreon, qui sont libres, et des protocoles comme SNMP. Des outils système en ligne de commande comme sar, iostat, mpstat, etc. permettent d’obtenir des informations utiles.

Kubernetes propose une API dédiée aux métriques, qui nécessite l’utilisation d’un contrôleur annexe et optionnel. Cette API donne accès à de nouvelles fonctions, comme l’autoscaling (ajout et suppression dynamique de pods en fonction d’une charge).

Pour tester cette fonctionnalité, il faut installer un pipeline de collecte de métriques. Il en existe de deux sortes selon qu’ils sont basés sur la collecte des métriques liées uniquement au cluster, par exemple metrics-server, ou sur la collecte des métriques liées à l’environnement complet, comme Prometheus.

Metrics-server est disponible ici :  https://github.com/kubernetes-sigs/metrics-server

Prometheus, plus complet mais aussi plus complexe, est disponible ici : https://prometheus.io/

Vous pouvez installer rapidement metrics-server comme ceci :

$ kubectl apply -f https://github.com/kubernetes-sigs/
metrics-server/releases/latest/download/components.yaml 
serviceaccount/metrics-server created 
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-
reader created 
clusterrole.rbac.authorization.k8s.io/system:metrics-server created 
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created 
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system: 
auth-delegator created 
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created 
service/metrics-server created 
deployment.apps/metrics-server created 
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created 

$ kubectl -n kube-system edit deployment.apps/metrics-server 
... 
    spec: 
      containers: 
      - args: 
... 
        - --kubelet-insecure-tls 
... 

Dès lors, les métriques de base sont accessibles, par exemple avec kubectl top :

$ kubectl top node 
 
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY% 
k8s-cplane01   73m          3%     1670Mi          93% 
k8s-cplane02   67m          3%     1422Mi          79% 
k8s-cplane03   79m          3%     1481Mi          82% 
k8s-worker01   40m          2%     1167Mi          65% 
k8s-worker02   21m          1%     1247Mi          69% 
k8s-worker03   18m          0%     1013Mi          56% 
k8s-worker04   22m          1%     1142Mi          63% 

Les métriques fonctionnent aussi pour les pods :

$ kubectl -n eni-todo top pod 
NAME                        CPU(cores)   MEMORY(bytes) 
eni-todo-578d497b88-spcgr   1578m        228Mi 
eni-todo-578d497b88-tn8dk   1472m        225Mi 

Il est maintenant possible d’utiliser les deux modes d’autoscaling de Kubernetes :

Nous pouvons rapidement tester une ressource HPA (horizontale) indiquant que eni-todo nécessite au minimum un pod, au maximum quatre...