diff --git a/content/es/docs/concepts/architecture/leases.md b/content/es/docs/concepts/architecture/leases.md new file mode 100644 index 0000000000..24a89cd1c0 --- /dev/null +++ b/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 +--- + + + +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. + + +## 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-`. 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í. \ No newline at end of file