Bases du cloud et des conteneurs
Apprenez avec des QCM les espaces de noms et les cgroups sur lesquels reposent les conteneurs, les images, les couches et la copie sur écriture, les instructions d'un Dockerfile (RUN, CMD, ENTRYPOINT, COPY), le cache de construction et l'ordre des instructions, la publication de ports, les volumes et les montages bind, les tags et les condensés, les constructions multi-étapes, les Pods, Deployments, Services, Ingress et Secrets de Kubernetes, la réconciliation et les mises à jour progressives, les sondes readiness et liveness, les calculs de mise à l'échelle automatique, les requests et les limits, le modèle de responsabilité partagée, les zones de disponibilité, l'informatique sans serveur, les types de stockage, le seuil de rentabilité entre facturation à l'usage et réservations, les frais de transfert de données, l'IaC, l'infrastructure immuable, les déploiements bleu-vert et canari, et l'observabilité.
Bases du cloud et des conteneurs : points clés
Beaucoup de services web et de systèmes d'entreprise fonctionnent aujourd'hui dans le cloud, sous forme d'applications empaquetées dans des conteneurs. Un conteneur isole des processus tout en partageant le noyau de l'OS de l'hôte ; les images sont construites avec Docker, et des plateformes comme Kubernetes placent les conteneurs sur de nombreuses machines, maintiennent leur nombre et les mettent à jour.
Ce thème commence par les espaces de noms et les cgroups, les couches des images et la copie sur écriture, les instructions d'un Dockerfile et le cache de construction, la publication de ports, les volumes et les montages bind, les tags et les condensés, et les constructions multi-étapes, puis traite des Pods, Deployments, Services, Ingress et Secrets de Kubernetes, de la déclaration d'un état souhaité et de la réconciliation, des calculs de mise à jour progressive, des sondes readiness et liveness, des calculs du HorizontalPodAutoscaler, ainsi que des requests, des limits et du placement des Pods. Il examine ensuite le modèle de responsabilité partagée du cloud, les régions et les zones de disponibilité, l'informatique sans serveur et les démarrages à froid, le stockage en mode bloc, de fichiers et objet, la facturation à l'usage et le seuil de rentabilité des réservations, les frais de transfert de données, l'IaC et l'infrastructure immuable, le déploiement bleu-vert et le déploiement canari, le principe de ne construire les artefacts qu'une seule fois, la configuration par des variables d'environnement, et l'observabilité. Les valeurs des questions de calcul, y compris celles des choix erronés, ont été vérifiées par un calcul en Python. Tous les prix sont des valeurs fictives. Les différences entre hyperviseurs, conteneurs et machines virtuelles sont traitées dans « Système d'exploitation et matériel » ; IaaS, PaaS et SaaS, le scale-out, la redondance, la migration à chaud et les CDN dans « Architecture des systèmes et fiabilité » ; les répartiteurs de charge et les sessions dans « Bases des technologies web » ; le CI/CD dans « Développement logiciel et gestion de projet » ; les SLA dans « Gestion des services et audit des systèmes d'information » ; et le shell et les variables d'environnement dans « Bases de Linux et de la ligne de commande ».
Toutes les questions sur Bases du cloud et des conteneurs (40)
- Parmi les fonctions du noyau Linux qui permettent les conteneurs, quelle association entre les espaces de noms (namespaces), les cgroups (groupes de contrôle) et leur rôle est correcte ?
- Sur un hôte Linux, Docker sert à démarrer un conteneur à partir d'une image fondée sur une autre distribution que celle de l'hôte, et l'on y exécute uname -r (commande qui affiche la version du noyau) et cat /etc/os-release (commande qui affiche les informations sur la distribution). Quelle description des résultats est correcte ?
- Quelle description de la relation entre une image de conteneur et un conteneur est correcte ?
- Dans un conteneur démarré à partir d'une image, on modifie le fichier de configuration /etc/app.conf, qui fait partie de l'image. Quelle description de ce qui se passe avec le mécanisme de stockage habituel de Docker (comme overlay2) est correcte ?
- Pour décompresser une archive de 500 MB, data.tar.gz, une image a été construite avec le Dockerfile ci-dessus. Bien que l'archive ait été supprimée dans le même RUN après la décompression, l'image est restée plus grosse de la taille de l'archive. Quelle association entre la cause et le remède est la plus appropriée ?
- Cinq images empilent chacune leur propre couche de 30 MB sur la même image de base (120 MB). On néglige la compression des couches et la taille des métadonnées. Quel est l'espace disque utilisé par les images quand les cinq sont récupérées (pull) sur un même serveur ?
- Pour le Dockerfile ci-dessus, quelle association entre la commande exécutée lors de la construction de l'image avec docker build et la commande exécutée lors du démarrage d'un conteneur avec docker run est correcte ?
- Une image nommée pinger, construite à partir du Dockerfile ci-dessus, est démarrée par docker run pinger example.com. Quelle est la commande exécutée dans le conteneur ?
- Un conteneur est démarré par la commande ci-dessus à partir de l'image nginx, un serveur web qui écoute sur le port 80. L'adresse IP de l'hôte est 192.0.2.10, et il n'y a aucune restriction comme un pare-feu. Quelle est l'URL correcte pour joindre ce serveur web depuis un navigateur sur un autre PC du même réseau ?
- Le Dockerfile (B) ci-dessus a été obtenu à partir du Dockerfile (A), qui plaçait RUN npm ci après COPY . ., en changeant l'ordre pour ne copier d'abord que les fichiers de dépendances. npm ci prend 120 secondes, npm run build 30 secondes et COPY . . 2 secondes, et la durée des autres instructions est négligeable. L'image est reconstruite 20 fois par jour après une modification du seul code source sous src (package.json et package-lock.json ne changent pas). Si le cache de la construction précédente peut être utilisé, de combien la durée totale de construction par jour est-elle plus courte avec B qu'avec A ?
- Dans Docker, quelle description des volumes nommés et des montages bind (bind mounts), qui servent à conserver les données écrites par un conteneur, est correcte ?
- Une image est récupérée (pull) en indiquant registry.example.com/team/web:1.4. Quelle association donnant le sens de chaque partie de cette référence est correcte ?
- scratch est une image vide qui ne contient aucun fichier. Quelle description du contenu de l'image finale construite avec le Dockerfile multi-étapes ci-dessus est correcte ?
- Dans Kubernetes, quelle est la plus petite unité déployée et gérée, qui regroupe un ou plusieurs conteneurs partageant la même adresse IP et les mêmes volumes ?
- Dans Kubernetes, un Deployment avec replicas: 3 fait tourner trois Pods. Quelle description de ce qui se passe quand l'un de ces Pods est supprimé avec kubectl delete pod est correcte ?
- Dans un Deployment Kubernetes, l'image de conteneur du modèle de Pod est remplacée par une nouvelle version. Quelle description de ce qui se passe avec la stratégie de mise à jour par défaut (RollingUpdate) est correcte ?
- Un Deployment avec replicas: 10 a pour réglages de mise à jour progressive (rolling update) maxSurge: 25% et maxUnavailable: 25%. Quelle association entre la limite supérieure du nombre total de Pods et la limite inférieure du nombre de Pods disponibles pendant une mise à jour est correcte ?
- Dans Kubernetes, un Pod reçoit une adresse IP différente chaque fois qu'il est recréé. Quelle ressource permet à d'autres applications de se connecter, par un nom et une adresse qui ne changent pas, à plusieurs Pods sélectionnés par des labels, en répartissant la charge entre eux ?
- Dans un cluster Kubernetes, les requêtes HTTPS qui arrivent pour un même nom d'hôte doivent être envoyées au Service api si le chemin commence par /api, et au Service web sinon. Quelle ressource convient pour définir cette règle d'aiguillage ?
- Le mot de passe d'une base de données est stocké dans un Secret Kubernetes. Quelle description d'un Secret est correcte ?
- Une application web ne peut pas traiter de requêtes pendant environ 60 secondes après son démarrage, le temps de charger son cache, et renvoie 503 sur /ready pendant ce temps. Quelle description de l'effet de l'ajout des réglages ci-dessus au conteneur du Pod est correcte ?
- Dans une application web sur Kubernetes, la vérification effectuée par la sonde liveness a été étendue pour tester aussi si l'application peut se connecter à la base de données dont elle dépend. Quel est le problème le plus probable avec ce réglage ?
- Un HorizontalPodAutoscaler de Kubernetes a pour cible une utilisation CPU des Pods de 70 % et une plage de 1 à 10 Pods. Actuellement, l'utilisation CPU moyenne de 5 Pods est de 30 %. Si le nombre de Pods nécessaire est calculé par ⌈nombre actuel × utilisation actuelle ÷ utilisation cible⌉ (⌈ ⌉ désigne l'arrondi à l'entier supérieur), combien de Pods faut-il ?
- Dans un Deployment dont les conteneurs des Pods ont les réglages ci-dessus, quatre Pods tournent et chacun utilise 400m (0,4 cœur) de CPU. La cible d'utilisation CPU du HorizontalPodAutoscaler est de 60 %, et le nombre de Pods nécessaire est calculé par ⌈nombre actuel × utilisation actuelle ÷ utilisation cible⌉. Combien de Pods faut-il ?
- Dans Kubernetes, quelle description des requests et des limits de ressources définies pour un conteneur est correcte ?
- Un nœud dispose de ressources allouables de 4 cœurs de CPU et de 8 GiB de mémoire. Le conteneur de chaque Pod a pour requests 500m de CPU et 1,5 GiB de mémoire, et pour limits 1 cœur de CPU et 2 GiB de mémoire. Il n'y a ni autres Pods ni réservations pour le système. Quel est le nombre maximal de Pods que l'on peut placer sur ce nœud ?
- On utilise un service de base de données managé dans le cloud (un service dans lequel le fournisseur exploite le logiciel de base de données). Selon le modèle de responsabilité partagée, qu'est-ce qui reste en général de la responsabilité de l'utilisateur ?
- Dans le cloud, quel est le principal objectif de la répartition des serveurs web et des réplicas de la base de données entre plusieurs zones de disponibilité d'une même région ?
- Avec des fonctions sans serveur (FaaS), il arrive que seul le premier appel d'une fonction qui n'a pas été appelée depuis un certain temps réponde avec quelques centaines de millisecondes à quelques secondes de retard. Quelle explication de ce phénomène est correcte ?
- Un stockage cloud est utilisé pour trois usages : (1) le rattacher à une machine virtuelle comme disque, y créer un système de fichiers et y placer les fichiers de données d'une base de données ; (2) le monter depuis plusieurs serveurs en même temps et l'utiliser comme répertoire partagé ; (3) lire et écrire un grand nombre d'images par clé (nom) au moyen d'une API HTTP, et en augmenter la capacité sans la fixer à l'avance. Quelle association de types de stockage convient aux usages (1) à (3) ?
- On utilise des machines virtuelles facturées seulement pour la durée d'utilisation, à 40 yens de l'heure (prix fictif). En temps normal, 2 machines tournent en permanence pendant tout le mois (30 jours), et pendant 20 jours ouvrés, 4 machines sont ajoutées 6 heures par jour pour suivre la charge. Quel est le montant facturé pour le mois ?
- Une machine virtuelle coûte 50 yens de l'heure à la demande, où l'on ne paie que les heures utilisées, ou 262 800 yens par an avec une réservation qui engage à l'avance sur un an d'utilisation, quelles que soient les heures utilisées (deux prix fictifs). En comptant 8760 heures dans une année, la réservation devient moins chère dès que le nombre d'heures d'utilisation dans l'année dépasse une certaine valeur. Quelle est cette valeur ?
- Qu'est-ce qui s'applique en général à la façon dont de nombreux clouds publics facturent le transfert de données ?
- Un environnement a été créé en appliquant, avec un outil d'IaC (infrastructure en tant que code) déclaratif, un fichier qui définit un réseau et deux machines virtuelles. Juste après, on applique de nouveau le même fichier sans rien modifier. Que se passe-t-il ?
- Quelle est une manière appropriée de mettre à jour le logiciel des serveurs de production conformément à l'idée d'infrastructure immuable ?
- On prépare deux environnements ayant la même configuration que la production ; la version actuelle continue de tourner dans l'un pendant que la nouvelle version est installée et vérifiée dans l'autre, puis le répartiteur de charge est basculé d'un coup vers ce dernier. En cas de problème, on revient rapidement à l'ancienne version en rebasculant. Quelle est cette méthode de mise en production ?
- Un service qui reçoit 12 000 requêtes par heure effectue un déploiement canari d'une nouvelle version et n'envoie à celle-ci que 5 % des requêtes. La nouvelle version a un bogue qui fait échouer 3 % des requêtes qu'elle reçoit ; on s'en aperçoit au bout d'une heure, et toutes les requêtes sont renvoyées vers l'ancienne version. Combien de requêtes ont échoué à cause du bogue pendant cette heure ?
- Une image de conteneur construite par une chaîne CI/CD a été testée dans l'environnement de préproduction (staging) et validée. Quelle est la manière la plus appropriée de mettre cette image en production ?
- Comme ci-dessus, la destination de connexion à la base de données n'est pas écrite dans l'image, mais transmise sous forme de variable d'environnement au démarrage du conteneur. Quel est le principal avantage de cette conception ?
- Dans un système où plusieurs services fonctionnent ensemble, on veut savoir par quels services est passée une requête d'un utilisateur, dans quel ordre, et combien de temps elle a passé dans chacun. Parmi les données utilisées pour l'observabilité, laquelle est la plus adaptée ?
Autres thèmes de Systèmes informatiques
- Arithmétique des ordinateurs IEEE 754, virgule fixe, erreur d'arrondi
- Probabilités, statistiques et files d'attente Dénombrement, lois de probabilité, estimation et tests, M/M/1
- ISA et assembleur RISC-V, modes d'adressage, conventions d'appel
- Compilateurs Analyse syntaxique, SSA, optimisation, registres
- Éditeurs de liens, chargeurs et exécutables ELF, symboles, relocalisation, liaison dynamique
- Système d'exploitation et matériel Interruptions, appels système, défauts de page
- Bases de Linux et de la ligne de commande Shell, permissions, pipes, scripts
- Hiérarchie mémoire Cache, remplacement, trois types de défauts
- Multicœur et synchronisation MESI, instructions atomiques, barrières mémoire
- Programmation GPU Warps, mémoire partagée, coalescence, occupation
- Pile matérielle et logicielle de l'IA Inférence/entraînement, quantification, roofline
- Bases de l'apprentissage automatique Types d'apprentissage, métriques et réseaux de neurones
- Systèmes embarqués et firmware GPIO, UART/SPI/I2C, RTOS
- HDL et vérification Verilog, latches, machines à états, testbenches
- Interfaces d'E/S et bus PCIe, USB, SerDes, CXL
- Bases des réseaux informatiques TCP/IP, sous-réseaux, DNS, TLS
- Bases des technologies web HTTP, cookies, REST, CORS, cache
- Bases des communications sans fil Modulation, OFDM, MIMO et circuits RF
- Bases de la sécurité de l'information Cryptographie, authentification, attaques web
- Bases des bases de données SQL, normalisation, transactions
- Structures de données et algorithmes Complexité, recherche, tris, graphes
- Bases de la programmation (trace de pseudo-code) Pseudo-code, trace, tableaux et récursion
- Bases de la programmation en C Pointeurs, mémoire, comportement indéfini
- Développement logiciel et gestion de projet Processus, tests, délais et coûts
- Bases de la stratégie d'entreprise et de la comptabilité Comptabilité, seuil de rentabilité, stratégie, marketing
- Gestion des services et audit des systèmes d'information SLA, incidents et problèmes, audit et contrôle interne
- Architecture des systèmes et fiabilité Redondance, RAID, sauvegardes et cloud
- Analyse des performances Loi d'Amdahl, CPI, goulots d'étranglement
- Sécurité matérielle Canaux auxiliaires, secure boot, TEE, PUF
- Gestion de l'énergie DVFS, power gating, états de veille