Compte tenu de ce paragraphe sur Kubernetes, quelle est la couche de stockage du plan de contrôle de Kubernetes ?
Le nœud maître Kubernetes gère le plan de contrôle Kubernetes du cluster, en gérant sa charge de travail et en dirigeant la communication à travers le système. Le plan de contrôle Kubernetes se compose de divers éléments, chacun étant son propre processus, qui peuvent s'exécuter à la fois sur un seul nœud maître ou sur plusieurs maîtres prenant en charge les clusters à haute disponibilité :

etcd est un magasin de données clé-valeur persistant, léger et distribué que CoreOS a développé. Il stocke de manière fiable les données de configuration du cluster, représentant l'état général du cluster à un moment donné. etcd privilégie la cohérence à la disponibilité en cas de partition du réseau (voir le théorème CAP). La cohérence est cruciale pour planifier et exploiter correctement les services.
Le serveur API sert l'API Kubernetes à l'aide de JSON sur HTTP, qui constitue l'interface interne et externe de Kubernetes. Le serveur API traite et valide les demandes REST et met à jour l'état des objets API dans etcd, permettant ainsi aux clients de configurer les charges de travail et les conteneurs sur les nœuds de travail. Le serveur API utilise l'API watch d'etcd pour surveiller le cluster, déployer les changements de configuration critiques ou restaurer toute divergence de l'état du cluster par rapport à ce qui a été déclaré par le responsable du déploiement. Par exemple, le responsable du déploiement peut spécifier que trois instances d'un "pod" particulier (voir ci-dessous) doivent être en cours d'exécution. etcd enregistre ce fait. Si le contrôleur de déploiement constate que seules deux instances sont en cours d'exécution (en conflit avec la déclaration etcd), il planifie la création d'une instance supplémentaire de ce pod.
L'ordonnanceur est le composant extensible qui sélectionne le nœud sur lequel un pod non programmé (l'entité de base gérée par l'ordonnanceur) s'exécute, en fonction de la disponibilité des ressources. L'ordonnanceur suit l'utilisation des ressources sur chaque nœud afin de s'assurer que la charge de travail n'est pas programmée au-delà des ressources disponibles. À cette fin, l'ordonnanceur doit connaître les besoins en ressources, la disponibilité des ressources et d'autres contraintes ou directives de politique fournies par l'utilisateur, telles que la qualité de service, les exigences d'affinité ou d'anti-affinité et la localité des données. Le rôle de l'ordonnanceur est de faire correspondre l'"offre" de ressources à la "demande" de charge de travail.
Un contrôleur est une boucle de réconciliation qui conduit l'état actuel du cluster vers l'état souhaité, en communiquant avec le serveur API pour créer, mettre à jour et supprimer les ressources qu'il gère (par exemple, les pods ou les points d'extrémité de service) Un type de contrôleur est un contrôleur de réplication, qui gère la réplication et la mise à l'échelle en exécutant un nombre spécifié de copies d'un pod à travers le cluster. Il gère également la création de pods de remplacement si le nœud sous-jacent tombe en panne. D'autres contrôleurs qui font partie du cœur du système Kubernetes comprennent un contrôleur DaemonSet pour exécuter exactement un pod sur chaque machine (ou un certain sous-ensemble de machines), et un contrôleur Job pour exécuter des pods qui s'exécutent jusqu'à la fin (par exemple, dans le cadre d'un travail par lots). Les sélecteurs d'étiquettes qui font partie de la définition du contrôleur spécifient l'ensemble de pods qu'un contrôleur gère.
Le gestionnaire de contrôleur est un processus qui gère un ensemble de contrôleurs Kubernetes de base.
ETCD
Given this paragraph about kubernetes, what is the storage layer of Kubernetes control plane?
The Kubernetes master node handles the Kubernetes control plane of the cluster, managing its workload and directing communication across the system. The Kubernetes control plane consists of various components, each its own process, that can run both on a single master node or on multiple masters supporting high-availability clusters.[36] The various components of the Kubernetes control plane are as follows:

etcd[37] is a persistent, lightweight, distributed, key-value data store that CoreOS has developed. It reliably stores the configuration data of the cluster, representing the overall state of the cluster at any given point of time. etcd favors consistency over availability in the event of a network partition (see CAP theorem). The consistency is crucial for correctly scheduling and operating services.
The API server serves the Kubernetes API using JSON over HTTP, which provides both the internal and external interface to Kubernetes.[35][38] The API server processes and validates REST requests and updates the state of the API objects in etcd, thereby allowing clients to configure workloads and containers across worker nodes.[39] The API server uses etcd's watch API to monitor the cluster, roll out critical configuration changes, or restore any divergences of the state of the cluster back to what the deployer declared. As an example, the deployer may specify that three instances of a particular "pod" (see below) need to be running. etcd stores this fact. If the Deployment Controller finds that only two instances are running (conflicting with the etcd declaration),[40] it schedules the creation of an additional instance of that pod.[36]
The scheduler is the extensible component that selects on which node an unscheduled pod (the basic entity managed by the scheduler) runs, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints or policy directives such as quality-of-service, affinity vs. anti-affinity requirements, and data locality. The scheduler's role is to match resource "supply" to workload "demand".[41]
A controller is a reconciliation loop that drives the actual cluster state toward the desired state, communicating with the API server to create, update, and delete the resources it manages (e.g., pods or service endpoints).[42][38] One kind of controller is a Replication Controller, which handles replication and scaling by running a specified number of copies of a pod across the cluster. It also handles creating replacement pods if the underlying node fails.[42] Other controllers that are part of the core Kubernetes system include a DaemonSet Controller for running exactly one pod on every machine (or some subset of machines), and a Job Controller for running pods that run to completion (e.g., as part of a batch job).[43] Labels selectors that are part of the controller's definition specify the set of pods that a controller manages.[44]
The controller manager is a process that manages a set of core Kubernetes controllers.
ETCD