Spanish translation of the document leases

content/es/docs/concepts/architecture/leases.md

@@ -0,0 +1,103 @@
+---
+title: Arrendamientos
+api_metadata:
+- apiVersion: "coordination.k8s.io/v1"
+  kind: "Lease"
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+
+Los sistemas distribuidos suelen necesitar _arrendamientos_, que proporcionan un mecanismo para bloquear recursos compartidos
+y coordinar la actividad entre los miembros de un conjunto.
+En Kubernetes, el concepto de arrendamiento está representado por objetos [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
+en el {{< glossary_tooltip text="grupo API" term_id="api-group" >}} de `coordination.k8s.io`,
+que se utilizan para capacidades críticas del sistema, como los latidos del nodo y la elección del líder a nivel de componente.
+<!-- body -->
+
+## Latidos del nodo {#node-heart-beats}
+
+Kubernetes utiliza la API Lease para comunicar los latidos de los nodos kubelet al servidor API de Kubernetes.
+Para cada `Nodo` , existe un objeto `Lease` con un nombre coincidente en el espacio de nombres `kube-node-lease`.
+Bajo el capó, cada latido kubelet es una solicitud **update** a este objeto `Lease`, actualizando
+el campo `spec.renewTime` del objeto Lease. El plano de control de Kubernetes utiliza la marca de tiempo de este campo
+para determinar la disponibilidad de este «Nodo».
+
+Véase [Objetos Lease de nodos](/docs/concepts/architecture/nodes/#heartbeats) para más detalles.
+
+## Elección del líder
+Kubernetes también utiliza Leases para asegurar que sólo una instancia de un componente se está ejecutando en un momento dado.
+Esto lo utilizan componentes del plano de control como `kube-controller-manager` y `kube-scheduler` en configuraciones de
+HA, donde sólo una instancia del componente debe estar ejecutándose activamente mientras las otras 
+instancias están en espera.
+
+## Identidad del servidor API
+
+{{< feature-state feature_gate_name="APIServerIdentity" >}}
+
+A partir de Kubernetes v1.26, cada `kube-apiserver` utiliza la API Lease para publicar su identidad al resto del sistema. 
+Aunque no es particularmente útil por sí mismo, esto proporciona un mecanismo para que los clientes
+descubrir cuántas instancias de `kube-apiserver` están operando el plano de control de Kubernetes.
+La existencia de los objetos leases de kube-apiserver permite futuras capacidades que pueden requerir la coordinación entre
+cada kube-apiserver.
+
+Puede inspeccionar los leases de cada kube-apiserver buscando objetos leases en el espacio de nombres `kube-system`
+con el nombre `kube-apiserver-<sha256-hash>`. También puede utilizar el selector de etiquetas `apiserver.kubernetes.io/identity=kube-apiserver`:
+
+```shell
+kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver
+```
+```
+NAME                                        HOLDER                                                                           AGE
+apiserver-07a5ea9b9b072c4a5f3d1c3702        apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05        5m33s
+apiserver-7be9e061c59d368b3ddaf1376e        apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f        4m23s
+apiserver-1dfef752bcb36637d2763d1868        apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e        4m43s
+
+```
+El hash SHA256 utilizado en el nombre del lease se basa en el nombre de host del sistema operativo visto por ese servidor API. Cada kube-apiserver debe ser
+configurado para utilizar un nombre de host que es único dentro del clúster. Las nuevas instancias de kube-apiserver que utilizan el mismo nombre de host
+asumirán los leases existentes utilizando una nueva identidad de titular, en lugar de instanciar nuevos objetos leases. Puede comprobar el
+nombre de host utilizado por kube-apiserver comprobando el valor de la etiqueta `kubernetes.io/hostname`:
+
+```shell
+kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml
+```
+```yaml
+apiVersion: coordination.k8s.io/v1
+kind: Lease
+metadata:
+  creationTimestamp: "2023-07-02T13:16:48Z"
+  labels:
+    apiserver.kubernetes.io/identity: kube-apiserver
+    kubernetes.io/hostname: master-1
+  name: apiserver-07a5ea9b9b072c4a5f3d1c3702
+  namespace: kube-system
+  resourceVersion: "334899"
+  uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1
+spec:
+  holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05
+  leaseDurationSeconds: 3600
+  renewTime: "2023-07-04T21:58:48.065888Z"
+```
+
+Los leases caducados de los kube-apiservers que ya no existen son recogidos por los nuevos kube-apiservers después de 1 hora.
+
+Puede desactivar el lease de identidades del servidor API desactivando la opción `APIServerIdentity` de la [puerta de función](/docs/reference/command-line-tools-reference/feature-gates/).
+
+## Cargas de trabajo {#custom-workload}
+
+Su propia carga de trabajo puede definir su propio uso de los leases. Por ejemplo, puede ejecutar un
+{{< glossary_tooltip term_id=«controller» text=«controlador» >}} en la que un miembro principal o líder
+realiza operaciones que sus compañeros no realizan. Usted define un Lease para que las réplicas del controlador puedan seleccionar
+o elegir un líder, utilizando la API de Kubernetes para la coordinación.
+Si utiliza un lease, es una buena práctica definir un nombre para el lease que esté obviamente vinculado a
+el producto o componente. Por ejemplo, si tiene un componente denominado Ejemplo Foo, utilice un lease denominado
+`ejemplo-foo`.
+
+Si un operador de clúster u otro usuario final puede desplegar varias instancias de un componente, seleccione un nombre
+prefijo y elija un mecanismo (como el hash del nombre del despliegue) para evitar colisiones de nombres
+para los leases.
+
+Puede utilizar otro enfoque siempre que consiga el mismo resultado: los distintos productos de software no entran en conflicto entre sí.
+no entren en conflicto entre sí.