Resume los principales componentes del plano de control de un clúster Kubernetes a partir de este párrafo
Kubernetes define un conjunto de bloques de construcción ("primitivas") que proporcionan colectivamente mecanismos que despliegan, mantienen y escalan aplicaciones en función de la CPU, la memoria o métricas personalizadas Kubernetes está débilmente acoplado y es extensible para satisfacer diferentes cargas de trabajo. Los componentes internos, así como las extensiones y los contenedores que se ejecutan en Kubernetes, se basan en la API de Kubernetes. La plataforma ejerce su control sobre los recursos informáticos y de almacenamiento definiendo los recursos como Objetos, que pueden gestionarse como tales.

Kubernetes sigue la arquitectura primario/réplica. Los componentes de Kubernetes pueden dividirse en los que gestionan un nodo individual y los que forman parte del plano de control.

Plano de control
El nodo maestro de Kubernetes se encarga del plano de control de Kubernetes del clúster, gestionando su carga de trabajo y dirigiendo la comunicación en todo el sistema. El plano de control de Kubernetes consta de varios componentes, cada uno con su propio proceso, que pueden ejecutarse tanto en un único nodo maestro como en varios maestros que soporten clústeres de alta disponibilidad Los distintos componentes del plano de control de Kubernetes son los siguientes:

etcd es un almacén de datos clave-valor persistente, ligero y distribuido que ha desarrollado CoreOS. Almacena de forma fiable los datos de configuración del clúster, representando el estado general del clúster en un momento dado. etcd favorece la consistencia frente a la disponibilidad en caso de partición de la red (véase el teorema CAP). La consistencia es crucial para programar y operar correctamente los servicios.
El servidor API sirve a la API de Kubernetes utilizando JSON sobre HTTP, que proporciona la interfaz interna y externa a Kubernetes El servidor API procesa y valida las solicitudes REST y actualiza el estado de los objetos API en etcd, permitiendo así a los clientes configurar cargas de trabajo y contenedores en los nodos trabajadores El servidor API utiliza la API de vigilancia de etcd para supervisar el clúster, desplegar cambios de configuración críticos o restaurar cualquier divergencia del estado del clúster a lo que declaró el desplegador. Por ejemplo, el desplegador puede especificar que deben ejecutarse tres instancias de un "pod" concreto (ver más abajo). etcd almacena este dato. Si el controlador de despliegue comprueba que sólo se están ejecutando dos instancias (en conflicto con la declaración de etcd), programa la creación de una instancia adicional de ese pod.
El programador es el componente extensible que selecciona en qué nodo se ejecuta un pod no programado (la entidad básica gestionada por el programador), en función de la disponibilidad de recursos. El programador realiza un seguimiento del uso de recursos en cada nodo para garantizar que la carga de trabajo no se programe por encima de los recursos disponibles. Para ello, el programador debe conocer los requisitos de recursos, la disponibilidad de recursos y otras restricciones o directivas políticas proporcionadas por el usuario, como la calidad del servicio, los requisitos de afinidad frente a antiafinidad y la localidad de los datos. El papel del programador es hacer coincidir la "oferta" de recursos con la "demanda" de cargas de trabajo.
Un controlador es un bucle de reconciliación que dirige el estado real del clúster hacia el estado deseado, comunicándose con el servidor API para crear, actualizar y eliminar los recursos que gestiona (por ejemplo, pods o puntos finales de servicio) Un tipo de controlador es un Controlador de Replicación, que gestiona la replicación y el escalado ejecutando un número determinado de copias de un pod en todo el clúster. También se encarga de crear pods de sustitución si falla el nodo subyacente. Otros controladores que forman parte del núcleo del sistema Kubernetes son un Controlador DaemonSet para ejecutar exactamente un pod en cada máquina (o en algún subconjunto de máquinas), y un Controlador de Trabajos para ejecutar pods que se ejecutan hasta su finalización (por ejemplo, como parte de un trabajo por lotes). Los selectores de etiquetas que forman parte de la definición del controlador especifican el conjunto de pods que gestiona un controlador.
El gestor de controladores es un proceso que gestiona un conjunto de controladores del núcleo de Kubernetes.
El plano de control del clúster kubernetes se ejecuta en uno o más nodos maestros. Los componentes son:
1. etcd - un almacén de datos de valor clave que contiene los datos de configuración del clúster.
2. El api-server es un servidor que sirve y actualiza el estado del clúster kubernetes. Vigila el etcd y mantiene el estado real del clúster sincronizado con su estado deseado.
3. El programador es un componente que selecciona en qué nodo debe ejecutarse un pod no programado, en función de lo que necesita cada pod y de lo que pueden soportar los nodos del clúster.
4. El gestor de controladores gestiona varios controladores que mantienen el clúster sincronizado con su estado deseado.
Summarize the main components of a Kubernetes cluster control plane from this paragraph
Kubernetes defines a set of building blocks ("primitives") that collectively provide mechanisms that deploy, maintain, and scale applications based on CPU, memory[33] or custom metrics.[34] Kubernetes is loosely coupled and extensible to meet different workloads. The internal components as well as extensions and containers that run on Kubernetes rely on the Kubernetes API.[35] The platform exerts its control over compute and storage resources by defining resources as Objects, which can then be managed as such.

Kubernetes follows the primary/replica architecture. The components of Kubernetes can be divided into those that manage an individual node and those that are part of the control plane.[35][36]

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.
The kubernetes cluster control plane runs on one more more master nodes. The components are:
1. etcd - a key value datastore containing the configuration data of the cluster.
2. The api-server is a server which serves and updates the state of the kubernetes cluster. It watches etcd and keeps the clusters actual state in sync with its desired state.
3. The scheduler is a component which selects on which node an unscheduled pod should run, based on what each pod needs and what the nodes in the cluster can support.
4. The controller manager manages several controllers which keep the cluster in sync with its desired state.