From e5e42fe5592ae372aea41ceb238148a9bb813ed4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sat, 20 Jan 2024 21:53:38 +0100
Subject: [PATCH 1/8] First review of new PT content. Changes on base README,
 SUMMARY and days 5,8,9

---
 es/README.md        | 325 +++++++++++++++++++++++++++++--
 es/SUMMARY.md       |  34 ++--
 es/day-11/README.md | 362 ++++++++++++++++++++++++++++++++++
 es/day-12/README.md | 337 ++++++++++++++++++++++++++++++++
 es/day-13/README.md | 458 ++++++++++++++++++++++++++++++++++++++++++++
 es/day-5/README.md  |   4 +-
 es/day-8/README.md  | 456 ++-----------------------------------------
 es/day-9/README.md  | 328 +++++++++++++++++++++++++++++--
 8 files changed, 1813 insertions(+), 491 deletions(-)
 create mode 100644 es/day-11/README.md
 create mode 100644 es/day-12/README.md
 create mode 100644 es/day-13/README.md

diff --git a/es/README.md b/es/README.md
index 457cd294..307f5c9e 100644
--- a/es/README.md
+++ b/es/README.md
@@ -1,30 +1,325 @@
-# Descomplicando Kubernetes
+# Simplificando Kubernetes
 
+Este material es parte del curso "Simplificando Kubernetes" de LINUXtips. Ha sido diseñado para capacitar a persona estudiante o profesional de TI a trabajar con Kubernetes en entornos críticos.
 
-Debido a la pandemia del [Coronavirus (COVID-19)](https://coronavirus.jhu.edu/map.html), [Jeferson Fernando](https://twitter.com/badtux_) liberó el acceso público a este repositorio como forma de ayudar en el combate a la pandemia incentivando a las personas a quedarse en casa adquiriendo conocimientos y aprimorarse en profesión para que pudieran contrinuir en el lugar de trabajo o que se prepararan para nuevas oportunidades.
+El curso consta de material escrito, clases grabadas en vídeo y clases en vivo. Durante el curso, la persona será evaluada de manera práctica y deberá completar desafíos reales para avanzar en el curso.
 
-El contenido de este material está dividido en partes, donde llamamos a cada una de ellas de "day" (day-1, day-2, day-3, etc), para facilitar el aprendizaje. La idea es que el alumno se enfoque en el aprendizaje por etapas y por ese motivo recomendamos que vaya a la próxima parte solamente cuando estuviera totalmente cómodo  con el contenido actual.
+El enfoque del curso es capacitar a la persona para trabajar con Kubernetes de manera eficiente y estar completamente preparada para trabajar en entornos críticos que utilizan contenedores.
 
-En este material tendrás contacto con contenidos que abordan desde el nivel 0 a avançado sobre Kubernetes, y ahora que el mismo está abierto, com la ayuda de todos vamos a construir el mayor y más completo material sobre Kubernetes del mundo.
+¡Siéntase libre de aprender mucho sobre Kubernetes utilizando este libro!
 
-En el futuro, el contenido de este repositorio se convertirá en un livro, con los nombres de todas las personas que contribuyan para el projeto. El valor que será recaudado con la la venta del livro, será totalmente destinado para alguna organización que ayude a las personas con problemas financieros y/u problemas con acceso a la información, como por ejemplo, [Bienal da Quebrada](https://twitter.com/bienalquebrada).
+## Contenido
 
-Contamos con tu ayuda para que este material sea aún más completo, colabora! Para contribuir con mejoras en el contenido, sigue las instrucciones de este [tutorial](CONTRIBUTING.md).
+<details>
+<summary>DÍA 1</summary>
 
-Ve los vídeos sobre Kubernetes, DevOps, Automatización y otros asuntos relacionados con la tecnologia en los canaes de LINUXtips:
+- [Simplificando Kubernetes](day-1/README.md#simplificando-kubernetes)
+  - [Día 1](day-1/README.md##día-1)
+    - [Contenido del Día 1](day-1/README.md#contenido-del-día-1)
+    - [¿Qué vamos a ver hoy?](day-1/README.md#qué-vamos-a-ver-hoy)
+    - [Início de la clase Día 1](day-1/README.md#início-de-la-clase-día-1)
+    - [¿Cual distribución GNU/Linux debo utilizar?](day-1/README.md#cual-distribución-gnulinux-debo-utilizar)
+    - [Algunos sitios web que debemos visitar](day-1/README.md#algunos-sitios-web-que-debemos-visitar)
+    - [El Container Engine](day-1/README.md#el-container-engine)
+      - [OCI - Open Container Initiative](day-1/README.md#oci---open-container-initiative)
+      - [El Container Runtime](day-1/README.md#el-container-runtime)
+    - [¿Qué es Kubernetes?](day-1/README.md#qué-es-kubernetes)
+    - [Arquitectura de k8s](day-1/README.md#arquitectura-de-k8s)
+    - [Puertos de los que debemos preocuparnos](day-1/README.md#puertos-de-los-que-debemos-preocuparnos)
+      - [CONTROL PLANE](day-1/README.md#control-plane)
+    - [Conceptos clave de k8s](day-1/README.md#conceptos-clave-de-k8s)
+    - [Instalación y personalización de Kubectl](day-1/README.md#instalación-y-personalización-de-kubectl)
+      - [Instalación de Kubectl en GNU/Linux](day-1/README.md#instalación-de-kubectl-en-gnulinux)
+      - [Instalación de Kubectl en macOS](day-1/README.md#instalación-de-kubectl-en-macos)
+      - [Instalación de Kubectl en Windows](day-1/README.md#instalación-de-kubectl-en-windows)
+    - [Personalización de kubectl](day-1/README.md#personalización-de-kubectl)
+      - [Auto-completado](day-1/README.md#auto-completado)
+      - [Creando un alias para kubectl](day-1/README.md#creando-un-alias-para-kubectl)
+    - [Creando un clúster Kubernetes](day-1/README.md#creando-un-clúster-kubernetes)
+    - [Creando el clúster en tu máquina local](day-1/README.md#creando-el-clúster-en-tu-máquina-local)
+      - [Minikube](day-1/README.md#minikube)
+        - [Requisitos básicos](day-1/README.md#requisitos-básicos)
+        - [Instalación de Minikube en GNU/Linux](day-1/README.md#instalación-de-minikube-en-gnulinux)
+        - [Instalación de Minikube en MacOS](day-1/README.md#instalación-de-minikube-en-macos)
+        - [Instalación de Minikube en Microsoft Windows](day-1/README.md#instalación-de-minikube-en-microsoft-windows)
+        - [Iniciando, deteniendo y eliminando Minikube](day-1/README.md#iniciando-deteniendo-y-eliminando-minikube)
+        - [Bien, ¿cómo puedo saber si todo está funcionando correctamente?](day-1/README.md#bien-cómo-puedo-saber-si-todo-está-funcionando-correctamente)
+        - [Ver detalles sobre el clúster](day-1/README.md#ver-detalles-sobre-el-clúster)
+        - [Descubriendo la dirección de Minikube](day-1/README.md#descubriendo-la-dirección-de-minikube)
+        - [Accediendo a la máquina de Minikube a través de SSH](day-1/README.md#accediendo-a-la-máquina-de-minikube-a-través-de-ssh)
+        - [Panel de control de Minikube](day-1/README.md#panel-de-control-de-minikube)
+        - [Logs de Minikube](day-1/README.md#logs-de-minikube)
+        - [Eliminar el clúster](day-1/README.md#eliminar-el-clúster)
+      - [Kind](day-1/README.md#kind)
+        - [Instalación en GNU/Linux](day-1/README.md#instalación-en-gnulinux)
+        - [Instalación en MacOS](day-1/README.md#instalación-en-macos)
+        - [Instalación en Windows](day-1/README.md#instalación-en-windows)
+          - [Instalación en Windows via Chocolatey](day-1/README.md#instalación-en-windows-via-chocolatey)
+        - [Creando un clúster con Kind](day-1/README.md#creando-un-clúster-con-kind)
+        - [Creando un clúster con múltiples nodos locales usando Kind](day-1/README.md#creando-un-clúster-con-múltiples-nodos-locales-usando-kind)
+    - [Primeros pasos en k8s](day-1/README.md#primeros-pasos-en-k8s)
+      - [Verificación de namespaces y pods](day-1/README.md#verificación-de-namespaces-y-pods)
+        - [Ejecutando nuestro primer pod en k8s](day-1/README.md#ejecutando-nuestro-primer-pod-en-k8s)
+        - [Ejecutando nuestro primer pod en k8s](day-1/README.md#ejecutando-nuestro-primer-pod-en-k8s-1)
+      - [Exponiendo el pod y creando un Service](day-1/README.md#exponiendo-el-pod-y-creando-un-service)
+      - [Limpiando todo y yendo a casa](day-1/README.md#limpiando-todo-y-yendo-a-casa)
 
-* [Canal de LINUXtips en Youtube](https://www.youtube.com/LINUXtips)
-* [Canal de LINUXtips en Twitch](https://www.twitch.com/LINUXtips)
+</details>
 
-Echa un vistazo a los entrenamientos disponibles de LINUXtips:
+<details>
+<summary>DAY-2</summary>
 
-* [Site Oficial de LINUXtips](https://linuxtips.io/loja)
 
+- [Simplificando Kubernetes](day-2/README.md#simplificando-kubernetes)
+  - [Día 2](day-2/README.md#día-2)
+    - [Contenido del Día 2](day-2/README.md#contenido-del-día-2)
+    - [Ínicio de la clase Día 2](day-2/README.md#ínicio-de-la-clase-día-2)
+    - [¿Qué vamos a ver hoy?](day-2/README.md#qué-vamos-a-ver-hoy)
+    - [¿Qué es un Pod?](day-2/README.md#qué-es-un-pod)
+      - [Creando un Pod](day-2/README.md#creando-un-pod)
+      - [Visualización de detalles sobre los Pods](day-2/README.md#visualización-de-detalles-sobre-los-pods)
+      - [Eliminando un Pod](day-2/README.md#eliminando-un-pod)
+      - [Creando un Pod mediante un archivo YAML](day-2/README.md#creando-un-pod-mediante-un-archivo-yaml)
+      - [Visualizando los registros (logs) del Pod](day-2/README.md#visualizando-los-registros-logs-del-pod)
+      - [Creando un Pod con múltiples contenedores](day-2/README.md#creando-un-pod-con-múltiples-contenedores)
+    - [Los comandos `attach` y `exec`](day-2/README.md#los-comandos-attach-y-exec)
+    - [Creando un contenedor con límites de memoria y CPU](day-2/README.md#creando-un-contenedor-con-límites-de-memoria-y-cpu)
+    - [Agregando un volumen EmptyDir al Pod](day-2/README.md#agregando-un-volumen-emptydir-al-pod)
 
-Links principales de LINUXtips:
+</details>
 
-* [Todos los Links de LINUXtips](https://linktr.ee/LINUXtips)
+<details>
+<summary>DAY-3</summary>
 
+- [Simplificando Kubernetes](day-3/README.md#simplificando-kubernetes)
+  - [Día 3](day-3/README.md#día-3)
+    - [Contenido del Día 3](day-3/README.md#contenido-del-día-3)
+    - [Inicio de la Lección del Día 3](day-3/README.md#inicio-de-la-lección-del-día-3)
+    - [¿Qué veremos hoy?](day-3/README.md#qué-veremos-hoy)
+    - [¿Qué es un Deployment?](day-3/README.md#qué-es-un-deployment)
+      - [Cómo crear un Deployment](day-3/README.md#cómo-crear-un-deployment)
+      - [¿Qué significa cada parte del archivo?](day-3/README.md#qué-significa-cada-parte-del-archivo)
+      - [¿Cómo aplicar el Deployment?](day-3/README.md#cómo-aplicar-el-deployment)
+      - [¿Cómo verificar si el Deployment se ha creado?](day-3/README.md#cómo-verificar-si-el-deployment-se-ha-creado)
+      - [¿Cómo verificar los Pods que el Deployment está gestionando?](day-3/README.md#cómo-verificar-los-pods-que-el-deployment-está-gestionando)
+      - [Cómo verificar el ReplicaSet que el Deployment está gestionando?](day-3/README.md#cómo-verificar-el-replicaset-que-el-deployment-está-gestionando)
+      - [Cómo verificar los detalles del Deployment?](day-3/README.md#cómo-verificar-los-detalles-del-deployment)
+      - [Cómo actualizar el Deployment?](day-3/README.md#cómo-actualizar-el-deployment)
+      - [¿Cuál es la estrategia de actualización predeterminada del Deployment?](day-3/README.md#cuál-es-la-estrategia-de-actualización-predeterminada-del-deployment)
+      - [Estrategias de actualización del Deployment](day-3/README.md#estrategias-de-actualización-del-deployment)
+        - [Estrategia RollingUpdate (Actualización gradual)](day-3/README.md#estrategia-rollingupdate-actualización-gradual)
+        - [Estrategia Recreate](day-3/README.md#estrategia-recreate)
+      - [Realizando un rollback de una actualización](day-3/README.md#realizando-un-rollback-de-una-actualización)
+      - [Eliminando un Deployment](day-3/README.md#eliminando-un-deployment)
+      - [Conclusión](day-3/README.md#conclusión)
 
-Acceso al Libro Descomplicando Kubernetes:  
-- [LIBRO - Descomplicando Kubernetes](SUMMARY.md)
\ No newline at end of file
+</details>
+
+<details>
+<summary>DAY-4</summary>
+
+- [Simplificando Kubernetes](day-4/README.md#simplificando-kubernetes)
+  - [Día 4](day-4/README.md#día-4)
+  - [Contenido del Día 4](day-4/README.md#contenido-del-día-4)
+  - [Inicio de la Lección del Día 4](day-4/README.md#inicio-de-la-lección-del-día-4)
+    - [¿Qué veremos hoy?](day-4/README.md#qué-veremos-hoy)
+    - [ReplicaSet](day-4/README.md#replicaset)
+      - [El Deployment y el ReplicaSet](day-4/README.md#el-deployment-y-el-replicaset)
+      - [Creando un ReplicaSet](day-4/README.md#creando-un-replicaset)
+      - [Desactivando el ReplicaSet](day-4/README.md#desactivando-el-replicaset)
+    - [El DaemonSet](day-4/README.md#el-daemonset)
+      - [Creando un DaemonSet](day-4/README.md#creando-un-daemonset)
+      - [Creación de un DaemonSet utilizando el comando kubectl create](day-4/README.md#creación-de-un-daemonset-utilizando-el-comando-kubectl-create)
+      - [Añadiendo un nodo al clúster](day-4/README.md#añadiendo-un-nodo-al-clúster)
+      - [Eliminando un DaemonSet](day-4/README.md#eliminando-un-daemonset)
+    - [Las sondas de Kubernetes](day-4/README.md#las-sondas-de-kubernetes)
+      - [¿Qué son las sondas?](day-4/README.md#qué-son-las-sondas)
+      - [Sonda de Integridad (Liveness Probe)](day-4/README.md#sonda-de-integridad-liveness-probe)
+      - [Sonda de preparación (Readiness Probe)](day-4/README.md#sonda-de-preparación-readiness-probe)
+      - [Sonda de Inicio](day-4/README.md#sonda-de-inicio)
+    - [Ejemplo con todas las sondas](day-4/README.md#ejemplo-con-todas-las-sondas)
+    - [Tu tarea](day-4/README.md#tu-tarea)
+    - [Final del Día 4](day-4/README.md#final-del-día-4)
+  
+</details>
+
+<details>
+<summary>DAY-5</summary>
+
+- [Simplificando Kubernetes - Expert Mode](day-5/README.md#simplificando-kubernetes---expert-mode)
+  - [Día 5](day-5/README.md#día-5)
+  - [Contenido del Día 5](day-5/README.md#contenido-del-día-5)
+  - [Inicio de la Lección del Día 5](day-5/README.md#inicio-de-la-lección-del-día-5)
+    - [¿Qué veremos hoy?](day-5/README.md#qué-veremos-hoy)
+    - [Instalación de un cluster Kubernetes](day-5/README.md#instalación-de-un-cluster-kubernetes)
+      - [¿Qué es un clúster de Kubernetes?](day-5/README.md#qué-es-un-clúster-de-kubernetes)
+    - [Formas de instalar Kubernetes](day-5/README.md#formas-de-instalar-kubernetes)
+    - [Creando un clúster Kubernetes con kubeadm](day-5/README.md#creando-un-clúster-kubernetes-con-kubeadm)
+      - [Instalación de kubeadm](day-5/README.md#instalación-de-kubeadm)
+      - [Deshabilitar el uso de swap en el sistema](day-5/README.md#deshabilitar-el-uso-de-swap-en-el-sistema)
+      - [Cargar los módulos del kernel](day-5/README.md#cargar-los-módulos-del-kernel)
+        - [Configurando parámetros del sistema](day-5/README.md#configurando-parámetros-del-sistema)
+        - [Instalando los paquetes de Kubernetes](day-5/README.md#instalando-los-paquetes-de-kubernetes)
+        - [Instalando containerd](day-5/README.md#instalando-containerd)
+        - [Configurando containerd](day-5/README.md#configurando-containerd)
+        - [Habilitando el servicio kubelet](day-5/README.md#habilitando-el-servicio-kubelet)
+        - [Configurando los puertos](day-5/README.md#configurando-los-puertos)
+        - [Inicializando el clúster](day-5/README.md#inicializando-el-clúster)
+        - [Comprendiendo el archivo admin.conf](day-5/README.md#comprendiendo-el-archivo-adminconf)
+          - [Clusters](day-5/README.md#clusters)
+          - [Contextos](day-5/README.md#contextos)
+          - [Contexto actual](day-5/README.md#contexto-actual)
+          - [Preferencias](day-5/README.md#preferencias)
+          - [Usuarios](day-5/README.md#usuarios)
+        - [Agregando los demás nodos al clúster](day-5/README.md#agregando-los-demás-nodos-al-clúster)
+        - [Instalando Weave Net](day-5/README.md#instalando-weave-net)
+        - [¿Qué es CNI?](day-5/README.md#qué-es-cni)
+      - [Visualizando detalles de los nodos](day-5/README.md#visualizando-detalles-de-los-nodos)
+    - [Tu tarea](day-5/README.md#tu-tarea)
+  - [Final del Día 5](day-5/README.md#final-del-día-5)
+
+</details>
+
+<details>
+<summary>DAY-6</summary>
+
+- [Simplificando Kubernetes](day-6/README.md#simplificando-kubernetes)
+  - [Día 6](day-6/README.md#día-6)
+  - [Contenido del Día 6](day-6/README.md#contenido-del-día-6)
+  - [Inicio de la Lección del Día 6](day-6/README.md#inicio-de-la-lección-del-día-6)
+    - [¿Qué veremos hoy?](day-6/README.md#qué-veremos-hoy)
+      - [¿Qué son los volúmenes?](day-6/README.md#qué-son-los-volúmenes)
+        - [EmpytDir](day-6/README.md#empytdir)
+        - [Clase de Almacenamiento (Storage Class)](day-6/README.md#clase-de-almacenamiento-storage-class)
+        - [PV - Persistent Volume](day-6/README.md#pv---persistent-volume)
+        - [PVC - Persistent Volume Claim](day-6/README.md#pvc---persistent-volume-claim)
+    - [Tu tarea](day-6/README.md#tu-tarea)
+
+</details>
+
+<details>
+<summary>DAY-7</summary>
+
+- [Simplificando Kubernetes](day-7/README.md#simplificando-kubernetes)
+  - [Día 7](day-7/README.md#día-7)
+  - [Contenido del Día 7](day-7/README.md#contenido-del-día-7)
+  - [Inicio de la Lección del Día 7](day-7/README.md#inicio-de-la-lección-del-día-7)
+    - [¿Qué veremos hoy?](day-7/README.md#qué-veremos-hoy)
+      - [¿Qué es un StatefulSet?](day-7/README.md#qué-es-un-statefulset)
+        - [¿Cuándo usar StatefulSets?](day-7/README.md#cuándo-usar-statefulsets)
+        - [¿Y cómo funcionan?](day-7/README.md#y-cómo-funcionan)
+        - [El StatefulSet y los volúmenes persistentes](day-7/README.md#el-statefulset-y-los-volúmenes-persistentes)
+        - [El StatefulSet y el Headless Service](day-7/README.md#el-statefulset-y-el-headless-service)
+        - [Creación de un StatefulSet](day-7/README.md#creación-de-un-statefulset)
+        - [Eliminando un StatefulSet](day-7/README.md#eliminando-un-statefulset)
+        - [Eliminando un Servicio Headless](day-7/README.md#eliminando-un-servicio-headless)
+        - [Eliminando un PVC](day-7/README.md#eliminando-un-pvc)
+      - [Servicios](day-7/README.md#servicios)
+        - [Tipos de Servicios](day-7/README.md#tipos-de-servicios)
+        - [Cómo funcionan los Servicios](day-7/README.md#cómo-funcionan-los-servicios)
+        - [Los Servicios y los Endpoints](day-7/README.md#los-servicios-y-los-endpoints)
+        - [Creando un Servicio](day-7/README.md#creando-un-servicio)
+          - [ClusterIP](day-7/README.md#clusterip)
+          - [NodePort](day-7/README.md#nodeport)
+          - [LoadBalancer](day-7/README.md#loadbalancer)
+          - [ExternalName](day-7/README.md#externalname)
+        - [Verificando los Services](day-7/README.md#verificando-los-services)
+        - [Verificando los Endpoints](day-7/README.md#verificando-los-endpoints)
+        - [Eliminando un Service](day-7/README.md#eliminando-un-service)
+    - [Tu tarea](day-7/README.md#tu-tarea)
+
+</details>
+
+<details>
+<summary>DAY-8</summary>
+TO DO
+</details>
+
+<details>
+<summary>DAY-9</summary>
+TO DO
+</details>
+
+<details>
+<summary>DAY-10</summary>
+TO DO
+</details>
+
+<details>
+<summary>DAY-11</summary>
+TO DO
+</details>
+TO DO
+<details>
+<summary>DAY-12</summary>
+TO DO
+</details>
+TO DO
+<details>
+<summary>DAY-13</summary>
+TO DO
+</details>
+TO DO
+<details>
+<summary>DAY-14</summary>
+TO DO
+</details>
+
+&nbsp;
+
+## El entrenamiento Simplificando Kubernetes
+
+Hemos diseñado un entrenamiento verdaderamente práctico en el que podrás aprender los conceptos y la teoría con una excelente didáctica, utilizando ejemplos y desafíos prácticos para que puedas aplicar todo el conocimiento adquirido. Esto es fundamental para que puedas asimilar y explorar aún más el contenido del entrenamiento.
+Y finalmente, simularemos algunas conversaciones para que se asemeje un poco más al día a día en el entorno laboral.
+
+Durante el entrenamiento, abordaremos todos los temas importantes de Kubernetes, para que al final del mismo, tengas todo el conocimiento y la confianza necesaria para implementar y administrar Kubernetes en entornos críticos y complejos.
+
+¿Estás listo para comenzar nuestro viaje?
+&nbsp;
+
+### El contenido del programa
+
+El contenido aún se está ajustando, y al final del entrenamiento tendremos el contenido completo.
+
+&nbsp;
+
+### ¿Cómo adquirir el entrenamiento?
+
+Para adquirir el entrenamiento [Simplificando Kubernetes](https://www.linuxtips.io/), debes visitar la tienda de [LINUXtips](https://www.linuxtips.io/).
+
+&nbsp;
+
+## La idea del formato del entrenamiento
+
+Enseñar Kubernetes de una manera más real, entregando todo el contenido de forma práctica y conectándolo con el entorno real de trabajo.
+
+Este es el primer entrenamiento sobre Kubernetes de forma realmente práctica, basado en la vida real. Entendemos que la práctica es el conjunto de comprensión de un tema, seguido de ejemplos reales que pueden ser reproducidos y conectando todo esto con la forma en que trabajamos.
+
+Así, la definición de práctica se convierte en un enfoque en el conocimiento de la herramienta y agregando la realidad de un profesional en su día a día al aprender una nueva tecnología, una nueva herramienta.
+
+Prepárate para un nuevo tipo de entrenamiento, y lo mejor, prepárate para un nuevo concepto de entrenamiento práctico y aprendizaje de tecnología.
+&nbsp;
+
+El contenido de este material está dividido en partes llamadas, a las que llamamos "día" (day_one, day_two, day_three, etc.), para facilitar el aprendizaje. La idea es que el estudiante se enfoque en aprender por etapas y, por lo tanto, recomendamos que pase a la siguiente parte solo cuando se sienta completamente cómodo con el contenido actual.
+
+En este material, encontrarás contenido que abarca desde nivel principiante hasta avanzado sobre Kubernetes, y ahora que se ha vuelto de código abierto, con la ayuda de todos, construiremos el material más grande y completo sobre Kubernetes del mundo.
+
+Contamos con tu colaboración para hacer que este material sea aún más completo, ¡colabora! Para contribuir con mejoras en el contenido, sigue las instrucciones de este [tutorial](CONTRIBUTING.md).
+
+Mira los videos sobre Kubernetes, DevOps, Automatización y otros temas relacionados con la tecnología en los canales de LINUXtips:
+
+- [Canal de LINUXtips en Youtube](https://www.youtube.com/LINUXtips)
+
+- [Canal de LINUXtips en Twitch](https://www.twitch.com/LINUXtips)
+
+Consulta los cursos disponibles de LINUXtips:
+
+- [Sitio Oficial de LINUXtips](https://linuxtips.io/)
+
+Principales enlaces de LINUXtips:
+
+- [Todos los Enlaces de LINUXtips](https://linktr.ee/LINUXtips)
+
+Acceso al Libro Simplificando Kubernetes:
+
+- [LIBRO - Simplificando Kubernetes](SUMMARY.md)
diff --git a/es/SUMMARY.md b/es/SUMMARY.md
index e8c5b917..84f4a6a4 100644
--- a/es/SUMMARY.md
+++ b/es/SUMMARY.md
@@ -1,26 +1,26 @@
-# Summary
+# Resumen
 
-## Sobre
+## Acerca de
 
 * [Introducción](README.md)
 
 ## Capítulos
 
-* [Simplificando Kubernetes dia 1](day-1/README.md)
-* [Simplificando Kubernetes dia 2](day-2/README.md)
-* [Simplificando Kubernetes dia 3](day-3/README.md)
-* [Simplificando Kubernetes dia 4](day-4/README.md)
-* [Simplificando Kubernetes dia 5](day-5/README.md)
-* [Simplificando Kubernetes dia 6](day-6/README.md)
-* [Simplificando Kubernetes dia 7](day-7/README.md)
-* [Simplificando Kubernetes dia 8](day-8/README.md)
-* [Simplificando Kubernetes dia 9](day-9/README.md)
-* [Simplificando Kubernetes dia 10](day-10/README.md)
-* [Simplificando Kubernetes dia 11](day-11/README.md)
-* [Simplificando Kubernetes dia 12](day-12/README.md)
-* [Simplificando Kubernetes dia 13](day-13/README.md)
-* [Simplificando Kubernetes dia 14](day-14/README.md)
-* [Simplificando Kubernetes dia 15](day-15/README.md)
+* [Simplificando Kubernetes día 1](day-1/README.md)
+* [Simplificando Kubernetes día 2](day-2/README.md)
+* [Simplificando Kubernetes día 3](day-3/README.md)
+* [Simplificando Kubernetes día 4](day-4/README.md)
+* [Simplificando Kubernetes día 5](day-5/README.md)
+* [Simplificando Kubernetes día 6](day-6/README.md)
+* [Simplificando Kubernetes día 7](day-7/README.md)
+* [Simplificando Kubernetes día 8](day-8/README.md)
+* [Simplificando Kubernetes día 9](day-9/README.md)
+* [Simplificando Kubernetes día 10](day-10/README.md)
+* [Simplificando Kubernetes día 11](day-11/README.md)
+* [Simplificando Kubernetes día 12](day-12/README.md)
+* [Simplificando Kubernetes día 13](day-13/README.md)
+* [Simplificando Kubernetes día 14](day-14/README.md)
+* [Simplificando Kubernetes día 15](day-15/README.md)
 
 ## Contribuir
 
diff --git a/es/day-11/README.md b/es/day-11/README.md
new file mode 100644
index 00000000..c8d0085b
--- /dev/null
+++ b/es/day-11/README.md
@@ -0,0 +1,362 @@
+# Descomplicando o Kubernetes
+## DAY-11
+
+&nbsp;
+
+## Conteúdo do Day-11
+
+- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes)
+  - [DAY-11](#day-11)
+  - [Conteúdo do Day-11](#conteúdo-do-day-11)
+    - [Início da aula do Day-11](#início-da-aula-do-day-11)
+      - [O que iremos ver hoje?](#o-que-iremos-ver-hoje)
+      - [Introdução ao Horizontal Pod Autoscaler (HPA)](#introdução-ao-horizontal-pod-autoscaler-hpa)
+      - [Como o HPA Funciona?](#como-o-hpa-funciona)
+  - [Introdução ao Metrics Server](#introdução-ao-metrics-server)
+    - [Por que o Metrics Server é importante para o HPA?](#por-que-o-metrics-server-é-importante-para-o-hpa)
+    - [Instalando o Metrics Server](#instalando-o-metrics-server)
+      - [No Amazon EKS e na maioria dos clusters Kubernetes](#no-amazon-eks-e-na-maioria-dos-clusters-kubernetes)
+      - [No Minikube:](#no-minikube)
+      - [No KinD (Kubernetes in Docker):](#no-kind-kubernetes-in-docker)
+      - [Verificando a Instalação do Metrics Server](#verificando-a-instalação-do-metrics-server)
+      - [Obtendo Métricas](#obtendo-métricas)
+    - [Criando um HPA](#criando-um-hpa)
+    - [Exemplos Práticos com HPA](#exemplos-práticos-com-hpa)
+      - [Autoscaling com base na utilização de CPU](#autoscaling-com-base-na-utilização-de-cpu)
+      - [Autoscaling com base na utilização de Memória](#autoscaling-com-base-na-utilização-de-memória)
+      - [Configuração Avançada de HPA: Definindo Comportamento de Escalonamento](#configuração-avançada-de-hpa-definindo-comportamento-de-escalonamento)
+      - [ContainerResource](#containerresource)
+      - [Detalhes do Algoritmo de Escalonamento](#detalhes-do-algoritmo-de-escalonamento)
+      - [Configurações Avançadas e Uso Prático](#configurações-avançadas-e-uso-prático)
+      - [Integrando HPA com Prometheus para Métricas Customizadas](#integrando-hpa-com-prometheus-para-métricas-customizadas)
+    - [A sua lição de casa](#a-sua-lição-de-casa)
+    - [Final do Day-11](#final-do-day-11)
+  
+&nbsp;
+
+### Início da aula do Day-11
+
+#### O que iremos ver hoje?
+
+Hoje é um dia particularmente fascinante! Vamos desbravar os territórios do Kubernetes, explorando a magia do Horizontal Pod Autoscaler (HPA), uma ferramenta indispensável para quem almeja uma operação eficiente e resiliente. Portanto, afivelem os cintos e preparem-se para uma jornada de descobertas. A aventura #VAIIII começar!
+
+#### Introdução ao Horizontal Pod Autoscaler (HPA)
+
+O Horizontal Pod Autoscaler, carinhosamente conhecido como HPA, é uma das joias brilhantes incrustadas no coração do Kubernetes. Com o HPA, podemos ajustar automaticamente o número de réplicas de um conjunto de pods, assegurando que nosso aplicativo tenha sempre os recursos necessários para performar eficientemente, sem desperdiçar recursos. O HPA é como um maestro que, com a batuta das métricas, rege a orquestra de pods, assegurando que a harmonia seja mantida mesmo quando a sinfonia do tráfego de rede atinge seu crescendo.
+
+#### Como o HPA Funciona?
+
+O HPA é o olheiro vigilante que monitora as métricas dos nossos pods. A cada batida do seu coração métrico, que ocorre em intervalos regulares, ele avalia se os pods estão suando a camisa para atender às demandas ou se estão relaxando mais do que deveriam. Com base nessa avaliação, ele toma a decisão sábia de convocar mais soldados para o campo de batalha ou de dispensar alguns para um merecido descanso.
+
+Certamente! O Metrics Server é uma componente crucial para o funcionamento do Horizontal Pod Autoscaler (HPA), pois fornece as métricas necessárias para que o HPA tome decisões de escalonamento. Vamos entender um pouco mais sobre o Metrics Server e como instalá-lo em diferentes ambientes Kubernetes, incluindo Minikube e KinD.
+
+---
+
+## Introdução ao Metrics Server
+
+Antes de começarmos a explorar o Horizontal Pod Autoscaler (HPA), é essencial termos o Metrics Server instalado em nosso cluster Kubernetes. O Metrics Server é um agregador de métricas de recursos de sistema, que coleta métricas como uso de CPU e memória dos nós e pods no cluster. Essas métricas são vitais para o funcionamento do HPA, pois são usadas para determinar quando e como escalar os recursos.
+
+### Por que o Metrics Server é importante para o HPA?
+
+O HPA utiliza métricas de uso de recursos para tomar decisões inteligentes sobre o escalonamento dos pods. Por exemplo, se a utilização da CPU de um pod exceder um determinado limite, o HPA pode decidir aumentar o número de réplicas desse pod. Da mesma forma, se a utilização da CPU for muito baixa, o HPA pode decidir reduzir o número de réplicas. Para fazer isso de forma eficaz, o HPA precisa ter acesso a métricas precisas e atualizadas, que são fornecidas pelo Metrics Server.
+Portanto, precisamos antes conhecer essa peça fundamental para o dia de hoje! :D
+
+### Instalando o Metrics Server
+
+#### No Amazon EKS e na maioria dos clusters Kubernetes
+
+Durante a nossa aula, estou com um cluster EKS, e para instalar o Metrics Server, podemos usar o seguinte comando:
+
+```bash
+kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
+```
+
+Esse comando aplica o manifesto do Metrics Server ao seu cluster, instalando todos os componentes necessários.
+
+#### No Minikube:
+
+A instalação do Metrics Server no Minikube é bastante direta. Use o seguinte comando para habilitar o Metrics Server:
+
+```bash
+minikube addons enable metrics-server
+```
+
+Após a execução deste comando, o Metrics Server será instalado e ativado em seu cluster Minikube.
+
+#### No KinD (Kubernetes in Docker):
+
+Para o KinD, você pode usar o mesmo comando que usou para o EKS:
+
+```bash
+kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
+```
+
+#### Verificando a Instalação do Metrics Server
+
+Após a instalação do Metrics Server, é uma boa prática verificar se ele foi instalado corretamente e está funcionando como esperado. Execute o seguinte comando para obter a lista de pods no namespace `kube-system` e verificar se o pod do Metrics Server está em execução:
+
+```bash
+kubectl get pods -n kube-system | grep metrics-server
+```
+
+#### Obtendo Métricas
+
+Com o Metrics Server em execução, agora você pode começar a coletar métricas de seu cluster. Aqui está um exemplo de como você pode obter métricas de uso de CPU e memória para todos os seus nodes:
+
+```bash
+kubectl top nodes
+```
+
+E para obter métricas de uso de CPU e memória para todos os seus pods:
+
+```bash
+kubectl top pods
+```
+
+Esses comandos fornecem uma visão rápida da utilização de recursos em seu cluster, o que é crucial para entender e otimizar o desempenho de seus aplicativos.
+
+### Criando um HPA
+
+Antes de nos aprofundarmos no HPA, vamos recapitular criando um deployment simples para o nosso confiável servidor Nginx.
+
+```yaml
+# Definição de um Deployment para o servidor Nginx
+apiVersion: apps/v1  # Versão da API que define um Deployment
+kind: Deployment     # Tipo de recurso que estamos definindo
+metadata:
+  name: nginx-deployment  # Nome do nosso Deployment
+spec:
+  replicas: 3             # Número inicial de réplicas
+  selector:
+    matchLabels:
+      app: nginx         # Label que identifica os pods deste Deployment
+  template:
+    metadata:
+      labels:
+        app: nginx       # Label aplicada aos pods
+    spec:
+      containers:
+      - name: nginx      # Nome do contêiner
+        image: nginx:latest  # Imagem do contêiner
+        ports:
+        - containerPort: 80  # Porta exposta pelo contêiner
+        resources:
+          limits:
+            cpu: 500m        # Limite de CPU
+            memory: 256Mi    # Limite de memória
+          requests:
+            cpu: 250m        # Requisição de CPU
+            memory: 128Mi    # Requisição de memória
+```
+
+Agora, com nosso deployment pronto, vamos dar o próximo passo na criação do nosso HPA.
+
+```yaml
+# Definição do HPA para o nginx-deployment
+apiVersion: autoscaling/v2  # Versão da API que define um HPA
+kind: HorizontalPodAutoscaler  # Tipo de recurso que estamos definindo
+metadata:
+  name: nginx-deployment-hpa  # Nome do nosso HPA
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1        # A versão da API do recurso alvo
+    kind: Deployment           # O tipo de recurso alvo
+    name: nginx-deployment     # O nome do recurso alvo
+  minReplicas: 3               # Número mínimo de réplicas
+  maxReplicas: 10              # Número máximo de réplicas
+  metrics:
+  - type: Resource             # Tipo de métrica (recurso do sistema)
+    resource:
+      name: cpu                # Nome da métrica (CPU neste caso)
+      target:
+        type: Utilization      # Tipo de alvo (utilização)
+        averageUtilization: 50 # Valor alvo (50% de utilização)
+```
+
+Neste exemplo, criamos um HPA que monitora a utilização da CPU do nosso `nginx-deployment`. O HPA se esforçará para manter a utilização da CPU em torno de 50%, ajustando o número de réplicas entre 3 e 10 conforme necessário.
+
+Para aplicar esta configuração ao seu cluster Kubernetes, salve o conteúdo acima em um arquivo chamado
+
+ `nginx-deployment-hpa.yaml` e execute o seguinte comando:
+
+```bash
+kubectl apply -f nginx-deployment-hpa.yaml
+```
+
+Agora, você tem um HPA monitorando e ajustando a escala do seu `nginx-deployment` baseado na utilização da CPU. Fantástico, não é?
+
+### Exemplos Práticos com HPA
+
+Agora que você já entende o básico sobre o HPA, é hora de rolar as mangas e entrar na prática. Vamos explorar como o HPA responde a diferentes métricas e cenários.
+
+#### Autoscaling com base na utilização de CPU
+
+Vamos começar com um exemplo clássico de escalonamento baseado na utilização da CPU, que já discutimos anteriormente. Para tornar a aprendizagem mais interativa, vamos simular um aumento de tráfego e observar como o HPA responde a essa mudança.
+
+```bash
+kubectl run -i --tty load-generator --image=busybox /bin/sh
+
+while true; do wget -q -O- http://nginx-deployment.default.svc.cluster.local; done
+```
+
+Este script simples cria uma carga constante no nosso deployment, fazendo requisições contínuas ao servidor Nginx. Você poderá observar como o HPA ajusta o número de réplicas para manter a utilização da CPU em torno do limite definido.
+
+#### Autoscaling com base na utilização de Memória
+
+O HPA não é apenas um mestre em lidar com a CPU, ele também tem um olho afiado para a memória. Vamos explorar como configurar o HPA para escalar baseado na utilização de memória.
+
+```yaml
+# Definição do HPA para escalonamento baseado em memória
+apiVersion: autoscaling/v2  # Versão da API que define um HPA
+kind: HorizontalPodAutoscaler    # Tipo de recurso que estamos definindo
+metadata:
+  name: nginx-deployment-hpa-memory  # Nome do nosso HPA
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1              # A versão da API do recurso alvo
+    kind: Deployment                 # O tipo de recurso alvo
+    name: nginx-deployment           # O nome do recurso alvo
+  minReplicas: 3                     # Número mínimo de réplicas
+  maxReplicas: 10                    # Número máximo de réplicas
+  metrics:
+  - type: Resource                   # Tipo de métrica (recurso do sistema)
+    resource:
+      name: memory                   # Nome da métrica (memória neste caso)
+      target:
+        type: Utilization            # Tipo de alvo (utilização)
+        averageUtilization: 70       # Valor alvo (70% de utilização)
+```
+
+Neste exemplo, o HPA vai ajustar o número de réplicas para manter a utilização de memória em cerca de 70%. Assim, nosso deployment pode respirar livremente mesmo quando a demanda aumenta.
+
+#### Configuração Avançada de HPA: Definindo Comportamento de Escalonamento
+
+O HPA é flexível e permite que você defina como ele deve se comportar durante o escalonamento para cima e para baixo. Vamos explorar um exemplo:
+
+```yaml
+# Definição de HPA com configurações avançadas de comportamento
+apiVersion: autoscaling/v2      # Versão da API que define um HPA
+kind: HorizontalPodAutoscaler        # Tipo de recurso que estamos definindo
+metadata:
+  name: nginx-deployment-hpa         # Nome do nosso HPA
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1              # A versão da API do recurso alvo
+    kind: Deployment                 # O tipo de recurso alvo
+    name: nginx-deployment           # O nome do recurso alvo
+  minReplicas: 3                     # Número mínimo de réplicas
+  maxReplicas: 10                    # Número máximo de réplicas
+  metrics:
+  - type: Resource                   # Tipo de métrica (recurso do sistema)
+    resource:
+      name: cpu                      # Nome da métrica (CPU neste caso)
+      target:
+        type: Utilization            # Tipo de alvo (utilização)
+        averageUtilization: 50       # Valor alvo (50% de utilização)
+  behavior:
+    scaleUp:
+      stabilizationWindowSeconds: 0  # Período de estabilização para escalonamento para cima
+      policies:
+      - type: Percent                # Tipo de política (percentual)
+        value: 100                   # Valor da política (100%)
+        periodSeconds: 15            # Período da política (15 segundos)
+    scaleDown:
+      stabilizationWindowSeconds: 300  # Período de estabilização para escalonamento para baixo
+      policies:
+      - type: Percent                  # Tipo de política (percentual)
+        value: 100                     # Valor da política (100%)
+        periodSeconds: 15              # Período da política (15 segundos)
+```
+
+Neste exemplo, especificamos um comportamento de escalonamento onde o HPA pode escalar para cima imediatamente, mas vai esperar por 5 minutos (300 segundos) após o último escalonamento para cima antes de considerar um escalonamento para baixo. Isso ajuda a evitar flutuações rápidas na contagem de réplicas, proporcionando um ambiente mais estável para nossos pods.
+
+
+#### ContainerResource
+
+O tipo de métrica `ContainerResource` no Kubernetes permite que você especifique métricas de recursos específicas do container para escalar. Diferente das métricas de recurso comuns que são aplicadas a todos os contêineres em um Pod, as métricas `ContainerResource` permitem especificar métricas para um contêiner específico dentro de um Pod. Isso pode ser útil em cenários onde você tem múltiplos contêineres em um Pod, mas quer escalar com base na utilização de recursos de um contêiner específico.
+
+Aqui está um exemplo de como você pode configurar um Horizontal Pod Autoscaler (HPA) usando uma métrica `ContainerResource` para escalar um Deployment com base na utilização de CPU de um contêiner específico:
+
+```yaml
+apiVersion: autoscaling/v2beta2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: nginx-hpa
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: nginx
+  minReplicas: 3
+  maxReplicas: 10
+  metrics:
+  - type: ContainerResource
+    containerResource:
+      name: cpu
+      container: nginx-NOME-COMPLETO-DO-CONTAINER
+      target:
+        type: Utilization
+        averageUtilization: 50
+```
+
+No exemplo acima:
+
+- O tipo de métrica é definido como `ContainerResource`.
+- Dentro do bloco `containerResource`, especificamos o nome da métrica (`cpu`), o nome do contêiner (`my-container`) e o alvo de utilização (`averageUtilization: 50`).
+
+Isso significa que o HPA vai ajustar o número de réplicas do Deployment `my-app` para manter a utilização média de CPU do contêiner `nginx-NOME-COMPLETO-DO-CONTAINER` em torno de 50%.
+
+Este tipo de configuração permite um controle mais granular sobre o comportamento de autoscaling, especialmente em ambientes onde os Pods contêm múltiplos contêineres com diferentes perfis de utilização de recursos.
+
+
+#### Detalhes do Algoritmo de Escalonamento
+
+**Cálculo do Número de Réplicas**
+O núcleo do Horizontal Pod Autoscaler (HPA) é o seu algoritmo de escalonamento, que determina o número ideal de réplicas com base nas métricas fornecidas. A fórmula básica utilizada pelo HPA para calcular o número desejado de réplicas é:
+
+\[ \text{desiredReplicas} = \lceil \text{currentReplicas} \times \left( \frac{\text{currentMetricValue}}{\text{desiredMetricValue}} \right) \rceil \]
+
+**Exemplos com Valores Específicos:**
+1. **Exemplo de Escala para Cima:**
+   - Réplicas atuais: 2
+   - Valor atual da métrica (CPU): 80%
+   - Valor desejado da métrica (CPU): 50%
+   - Cálculo: \(\lceil 2 \times (80\% / 50\%) \rceil = \lceil 3.2 \rceil = 4\) réplicas
+
+2. **Exemplo de Escala para Baixo:**
+   - Réplicas atuais: 5
+   - Valor atual da métrica (CPU): 30%
+   - Valor desejado da métrica (CPU): 50%
+   - Cálculo: \(\lceil 5 \times (30\% / 50\%) \rceil = \lceil 3 \rceil = 3\) réplicas
+
+**Considerações Sobre Métricas e Estado dos Pods:**
+- **Métricas de Recurso por Pod e Personalizadas:** O HPA pode ser configurado para usar métricas padrão (como CPU e memória) ou métricas personalizadas definidas pelo usuário, permitindo maior flexibilidade.
+- **Tratamento de Pods sem Métricas ou Não Prontos:** Se um Pod não tiver métricas disponíveis ou não estiver pronto, ele pode ser excluído do cálculo de média, evitando decisões de escalonamento baseadas em dados incompletos.
+
+#### Configurações Avançadas e Uso Prático
+
+**Configurando Métricas Personalizadas e Múltiplas Métricas:**
+O HPA não se limita apenas a métricas de CPU e memória; ele pode ser configurado para usar uma variedade de métricas personalizadas.
+
+**Uso de Métricas Personalizadas: Exemplos e Dicas:**
+- **Exemplo:** Suponha que você tenha um serviço que deve escalar com base no número de solicitações HTTP por segundo. Você pode configurar o HPA para escalar com base nessa métrica personalizada.
+- **Dicas:** Ao usar métricas personalizadas, assegure-se de que as métricas sejam um indicador confiável da carga de trabalho e que o serviço de métricas esteja corretamente configurado e acessível pelo HPA.
+
+**Escalonamento com Base em Várias Métricas:**
+- O HPA pode ser configurado para levar em conta várias métricas ao mesmo tempo, permitindo um controle mais refinado do escalonamento.
+- Por exemplo, você pode configurar o HPA para escalar com base tanto na utilização de CPU quanto na memória, ou qualquer combinação de métricas padrão e personalizadas.
+
+
+#### Integrando HPA com Prometheus para Métricas Customizadas
+
+Para levar o autoscaling para o próximo nível, podemos integrar o HPA com o Prometheus. Com essa integração, podemos usar métricas do Prometheus para informar nossas decisões de autoscaling.
+
+A integração geralmente envolve a configuração de um adaptador de métricas personalizadas, como o `k8s-prometheus-adapter`. Uma vez configurado, o HPA pode acessar métricas do Prometheus e usá-las para tomar decisões de autoscaling. A documentação completa sobre como integrar o HPA com o Prometheus pode ser encontrada [aqui](#adicionar-link).
+
+### A sua lição de casa
+
+Agora que você foi equipado com o conhecimento sobre o HPA, é hora de colocar esse conhecimento em prática. Configure um HPA em seu ambiente e experimente com diferentes métricas: CPU, memória e métricas personalizadas. Documente suas observações e compreenda como o HPA responde a diferentes cargas e situações.
+
+### Final do Day-11
+
+E assim, chegamos ao fim do Day-11, uma jornada repleta de aprendizado e exploração. Hoje, você descobriu o poder do Horizontal Pod Autoscaler e como ele pode ajudar a manter seu aplicativo performando de maneira eficiente, mesmo sob diferentes condições de carga. Você não apenas aprendeu como ele funciona, mas também colocou a mão na massa com exemplos práticos. Continue praticando e explorando, e nos vemos no próximo dia da nossa aventura pelo Kubernetes! #VAIIII
\ No newline at end of file
diff --git a/es/day-12/README.md b/es/day-12/README.md
new file mode 100644
index 00000000..540663b1
--- /dev/null
+++ b/es/day-12/README.md
@@ -0,0 +1,337 @@
+# Descomplicando o Kubernetes
+## DAY-12: Dominando Taints e Tolerations
+
+## Conteúdo do Day-12
+
+- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes)
+  - [DAY-12: Dominando Taints e Tolerations](#day-12-dominando-taints-e-tolerations)
+  - [Conteúdo do Day-12](#conteúdo-do-day-12)
+    - [Introdução](#introdução)
+    - [O que são Taints e Tolerations?](#o-que-são-taints-e-tolerations)
+    - [Por que usar Taints e Tolerations?](#por-que-usar-taints-e-tolerations)
+    - [Anatomia de um Taint](#anatomia-de-um-taint)
+    - [Anatomia de uma Toleration](#anatomia-de-uma-toleration)
+    - [Aplicando Taints](#aplicando-taints)
+    - [Configurando Tolerations](#configurando-tolerations)
+    - [Cenários de Uso](#cenários-de-uso)
+      - [Isolamento de Workloads](#isolamento-de-workloads)
+      - [Nodes Especializados](#nodes-especializados)
+      - [Evacuação e Manutenção de Nodes](#evacuação-e-manutenção-de-nodes)
+    - [Combinando Taints e Tolerations com Affinity Rules](#combinando-taints-e-tolerations-com-affinity-rules)
+    - [Exemplos Práticos](#exemplos-práticos)
+      - [Exemplo 1: Isolamento de Workloads](#exemplo-1-isolamento-de-workloads)
+      - [Exemplo 2: Utilizando Hardware Especializado](#exemplo-2-utilizando-hardware-especializado)
+      - [Exemplo 3: Manutenção de Nodes](#exemplo-3-manutenção-de-nodes)
+    - [Conclusão](#conclusão)
+    - [Tarefas do Dia](#tarefas-do-dia)
+- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes-1)
+  - [DAY-12+1: Entendendo e Dominando os Selectors](#day-121-entendendo-e-dominando-os-selectors)
+  - [Conteúdo do Day-12+1](#conteúdo-do-day-121)
+    - [Introdução](#introdução-1)
+    - [O que são Selectors?](#o-que-são-selectors)
+    - [Tipos de Selectors](#tipos-de-selectors)
+      - [Equality-based Selectors](#equality-based-selectors)
+      - [Set-based Selectors](#set-based-selectors)
+    - [Selectors em Ação](#selectors-em-ação)
+      - [Em Services](#em-services)
+      - [Em ReplicaSets](#em-replicasets)
+      - [Em Jobs e CronJobs](#em-jobs-e-cronjobs)
+    - [Selectors e Namespaces](#selectors-e-namespaces)
+    - [Cenários de Uso](#cenários-de-uso-1)
+      - [Roteamento de Tráfego](#roteamento-de-tráfego)
+      - [Scaling Horizontal](#scaling-horizontal)
+      - [Desastre e Recuperação](#desastre-e-recuperação)
+    - [Dicas e Armadilhas](#dicas-e-armadilhas)
+    - [Exemplos Práticos](#exemplos-práticos-1)
+      - [Exemplo 1: Selector em um Service](#exemplo-1-selector-em-um-service)
+      - [Exemplo 2: Selector em um ReplicaSet](#exemplo-2-selector-em-um-replicaset)
+      - [Exemplo 3: Selectors Avançados](#exemplo-3-selectors-avançados)
+    - [Conclusão](#conclusão-1)
+
+
+### Introdução
+
+Olá, galera! No capítulo de hoje, vamos mergulhar fundo em um dos conceitos mais poderosos e flexíveis do Kubernetes: Taints e Tolerations. Prepare-se, pois este capítulo vai além do básico e entra em detalhes que você não vai querer perder. #VAIIII
+
+### O que são Taints e Tolerations?
+
+Taints são "manchas" ou "marcações" aplicadas aos Nodes que os marcam para evitar que certos Pods sejam agendados neles. Por outro lado, Tolerations são configurações que podem ser aplicadas aos Pods para permitir que eles sejam agendados em Nodes com Taints específicos.
+
+### Por que usar Taints e Tolerations?
+
+Em um cluster Kubernetes diversificado, nem todos os Nodes são iguais. Alguns podem ter acesso a recursos especiais como GPUs, enquanto outros podem ser reservados para workloads críticos. Taints e Tolerations fornecem um mecanismo para garantir que os Pods sejam agendados nos Nodes apropriados.
+
+### Anatomia de um Taint
+
+Um Taint é composto por uma `chave`, um `valor` e um `efeito`. O efeito pode ser:
+
+- `NoSchedule`: O Kubernetes não agenda o Pod a menos que ele tenha uma Toleration correspondente.
+- `PreferNoSchedule`: O Kubernetes tenta não agendar, mas não é uma garantia.
+- `NoExecute`: Os Pods existentes são removidos se não tiverem uma Toleration correspondente.
+
+### Anatomia de uma Toleration
+
+Uma Toleration é definida pelos mesmos elementos de um Taint: `chave`, `valor` e `efeito`. Além disso, ela contém um `operador`, que pode ser `Equal` ou `Exists`.
+
+### Aplicando Taints
+
+Para aplicar um Taint a um Node, você utiliza o comando `kubectl taint`. Por exemplo:
+
+```bash
+kubectl taint nodes node1 key=value:NoSchedule
+```
+
+### Configurando Tolerations
+
+Tolerations são configuradas no PodSpec. Aqui está um exemplo:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: my-pod
+spec:
+  tolerations:
+  - key: "key"
+    operator: "Equal"
+    value: "value"
+    effect: "NoSchedule"
+```
+
+### Cenários de Uso
+
+#### Isolamento de Workloads
+
+Imagine um cenário onde você tem Nodes que devem ser dedicados a workloads de produção e não devem executar Pods de desenvolvimento.
+
+Aplicar Taint:
+
+```bash
+kubectl taint nodes prod-node environment=production:NoSchedule
+```
+
+Toleration em Pod de produção:
+
+```yaml
+tolerations:
+- key: "environment"
+  operator: "Equal"
+  value: "production"
+  effect: "NoSchedule"
+```
+
+#### Nodes Especializados
+
+Se você tem Nodes com GPUs e quer garantir que apenas Pods que necessitem de GPUs sejam agendados ali.
+
+Aplicar Taint:
+
+```bash
+kubectl taint nodes gpu-node gpu=true:NoSchedule
+```
+
+Toleration em Pod que necessita de GPU:
+
+```yaml
+tolerations:
+- key: "gpu"
+  operator: "Equal"
+  value: "true"
+  effect: "NoSchedule"
+```
+
+#### Evacuação e Manutenção de Nodes
+
+Se você precisa realizar manutenção em um Node e quer evitar que novos Pods sejam agendados nele.
+
+Aplicar Taint:
+
+```bash
+kubectl taint nodes node1 maintenance=true:NoExecute
+```
+
+### Combinando Taints e Tolerations com Affinity Rules
+
+Você pode combinar Taints e Tolerations com regras de afinidade para um controle ainda mais granular.
+
+### Exemplos Práticos
+
+#### Exemplo 1: Isolamento de Workloads
+
+Vamos criar um Node com um Taint e tentar agendar um Pod sem a Toleration correspondente.
+
+```bash
+# Aplicar Taint
+kubectl taint nodes dev-node environment=development:NoSchedule
+
+# Tentar agendar Pod
+kubectl run nginx --image=nginx
+```
+
+Observe que o Pod não será agendado até que uma Toleration seja adicionada.
+
+#### Exemplo 2: Utilizando Hardware Especializado
+
+Vamos criar um Node com uma GPU e aplicar um Taint correspondente.
+
+```bash
+# Aplicar Taint
+kubectl taint nodes gpu-node gpu=true:NoSchedule
+
+# Agendar Pod com Toleration
+kubectl apply -f gpu-pod.yaml
+```
+
+Onde `gpu-pod.yaml` contém a Toleration correspondente.
+
+#### Exemplo 3: Manutenção de Nodes
+
+Vamos simular uma manutenção, aplicando um Taint em um
+
+ Node e observando como os Pods são removidos.
+
+```bash
+# Aplicar Taint
+kubectl taint nodes node1 maintenance=true:NoExecute
+```
+
+### Conclusão
+
+Taints e Tolerations são ferramentas poderosas para o controle refinado do agendamento de Pods. Com elas, você pode isolar workloads, aproveitar hardware especializado e até gerenciar manutenções de forma mais eficaz.
+
+### Tarefas do Dia
+
+1. Aplique um Taint em um dos seus Nodes e tente agendar um Pod sem a Toleration correspondente.
+2. Remova o Taint e observe o comportamento.
+3. Adicione uma Toleration ao Pod e repita o processo.
+
+# Descomplicando o Kubernetes
+## DAY-12+1: Entendendo e Dominando os Selectors
+
+## Conteúdo do Day-12+1
+
+
+
+
+
+### Introdução
+
+E aí, pessoal! No capítulo de hoje, vamos nos aprofundar em um dos recursos mais versáteis e fundamentais do Kubernetes: os Selectors. Preparados? Então #VAIIII!
+
+### O que são Selectors?
+
+Selectors são formas de selecionar recursos, como Pods, com base em suas labels. Eles são a cola que une vários componentes do Kubernetes, como Services e ReplicaSets.
+
+### Tipos de Selectors
+
+#### Equality-based Selectors
+
+Estes são os mais simples, usando operadores como `=`, `==`, e `!=`.
+
+Exemplo:
+
+```bash
+kubectl get pods -l environment=production
+```
+
+#### Set-based Selectors
+
+Estes são mais complexos e usam operadores como `in`, `notin`, e `exists`.
+
+Exemplo:
+
+```bash
+kubectl get pods -l 'environment in (production, qa)'
+```
+
+### Selectors em Ação
+
+#### Em Services
+
+Services usam selectors para direcionar tráfego para Pods específicos.
+
+Exemplo:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+```
+
+#### Em ReplicaSets
+
+ReplicaSets usam selectors para saber quais Pods gerenciar.
+
+Exemplo:
+
+```yaml
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+  name: my-replicaset
+spec:
+  selector:
+    matchLabels:
+      app: MyApp
+```
+
+#### Em Jobs e CronJobs
+
+Jobs e CronJobs também podem usar selectors para executar tarefas em Pods específicos.
+
+### Selectors e Namespaces
+
+É crucial entender que os selectors não atravessam namespaces; eles são eficazes apenas dentro do namespace atual, a menos que especificado de outra forma.
+
+### Cenários de Uso
+
+#### Roteamento de Tráfego
+
+Use selectors em Services para direcionar tráfego para versões específicas de uma aplicação.
+
+#### Scaling Horizontal
+
+Use selectors em Horizontal Pod Autoscalers para escalar apenas os Pods que atendem a critérios específicos.
+
+#### Desastre e Recuperação
+
+Em casos de failover, você pode usar selectors para direcionar tráfego para Pods em um cluster secundário.
+
+### Dicas e Armadilhas
+
+- Não mude as labels de Pods que são alvos de Services sem atualizar o selector do Service.
+- Use selectors de forma consistente para evitar confusões.
+
+### Exemplos Práticos
+
+#### Exemplo 1: Selector em um Service
+
+Vamos criar um Service que seleciona todos os Pods com a label `frontend`.
+
+```bash
+kubectl apply -f frontend-service.yaml
+```
+
+#### Exemplo 2: Selector em um ReplicaSet
+
+Vamos criar um ReplicaSet que gerencia todos os Pods com a label `backend`.
+
+```bash
+kubectl apply -f backend-replicaset.yaml
+```
+
+#### Exemplo 3: Selectors Avançados
+
+Vamos fazer uma query complexa para selecionar Pods com base em múltiplas labels.
+
+```bash
+kubectl get pods -l 'release-version in (v1, v2),environment!=debug'
+```
+
+### Conclusão
+
+Selectors são uma ferramenta poderosa e flexível no Kubernetes, permitindo um controle fino sobre como os recursos interagem. Dominar este conceito é fundamental para qualquer um que trabalhe com Kubernetes.
diff --git a/es/day-13/README.md b/es/day-13/README.md
new file mode 100644
index 00000000..73b6512a
--- /dev/null
+++ b/es/day-13/README.md
@@ -0,0 +1,458 @@
+# Descomplicando o Kubernetes
+## DAY-13: Descomplicando Kyverno e as Policies no Kubernetes
+
+## Conteúdo do Day-13
+
+- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes)
+  - [DAY-13: Descomplicando Kyverno e as Policies no Kubernetes](#day-13-descomplicando-kyverno-e-as-policies-no-kubernetes)
+  - [Conteúdo do Day-13](#conteúdo-do-day-13)
+  - [O que iremos ver hoje?](#o-que-iremos-ver-hoje)
+  - [Inicio do Day-13](#inicio-do-day-13)
+    - [Introdução ao Kyverno](#introdução-ao-kyverno)
+    - [Instalando o Kyverno](#instalando-o-kyverno)
+      - [Utilizando Helm](#utilizando-helm)
+    - [Verificando a Instalação](#verificando-a-instalação)
+    - [Criando a nossa primeira Policy](#criando-a-nossa-primeira-policy)
+    - [Mais exemplos de Policies](#mais-exemplos-de-policies)
+      - [Exemplo de Política: Adicionar Label ao Namespace](#exemplo-de-política-adicionar-label-ao-namespace)
+        - [Detalhes da Política](#detalhes-da-política)
+        - [Arquivo de Política: `add-label-namespace.yaml`](#arquivo-de-política-add-label-namespaceyaml)
+        - [Utilização da Política](#utilização-da-política)
+      - [Exemplo de Política: Proibir Usuário Root](#exemplo-de-política-proibir-usuário-root)
+        - [Detalhes da Política](#detalhes-da-política-1)
+        - [Arquivo de Política: `disallow-root-user.yaml`](#arquivo-de-política-disallow-root-useryaml)
+        - [Implementação e Efeito](#implementação-e-efeito)
+      - [Exemplo de Política: Gerar ConfigMap para Namespace](#exemplo-de-política-gerar-configmap-para-namespace)
+        - [Detalhes da Política](#detalhes-da-política-2)
+        - [Arquivo de Política: `generate-configmap-for-namespace.yaml`](#arquivo-de-política-generate-configmap-for-namespaceyaml)
+        - [Implementação e Utilidade](#implementação-e-utilidade)
+      - [Exemplo de Política: Permitir Apenas Repositórios Confiáveis](#exemplo-de-política-permitir-apenas-repositórios-confiáveis)
+        - [Detalhes da Política](#detalhes-da-política-3)
+        - [Arquivo de Política: `registry-allowed.yaml`](#arquivo-de-política-registry-allowedyaml)
+        - [Implementação e Impacto](#implementação-e-impacto)
+        - [Exemplo de Política: Require Probes](#exemplo-de-política-require-probes)
+        - [Detalhes da Política](#detalhes-da-política-4)
+        - [Arquivo de Política: `require-probes.yaml`](#arquivo-de-política-require-probesyaml)
+        - [Implementação e Impacto](#implementação-e-impacto-1)
+      - [Exemplo de Política: Usando o Exclude](#exemplo-de-política-usando-o-exclude)
+        - [Detalhes da Política](#detalhes-da-política-5)
+        - [Arquivo de Política](#arquivo-de-política)
+        - [Implementação e Efeitos](#implementação-e-efeitos)
+    - [Conclusão](#conclusão)
+      - [Pontos-Chave Aprendidos](#pontos-chave-aprendidos)
+
+## O que iremos ver hoje?
+
+Hoje, exploraremos as funcionalidades e aplicações do Kyverno, uma ferramenta de gerenciamento de políticas essencial para a segurança e eficiência de clusters Kubernetes. Com uma abordagem detalhada e prática, você aprenderá a usar o Kyverno para automatizar tarefas cruciais, garantir a conformidade com normas e regras estabelecidas e melhorar a administração geral de seus ambientes Kubernetes.
+
+**Principais Tópicos Abordados:**
+
+1. **Introdução ao Kyverno:** Uma visão geral do Kyverno, destacando sua importância e as principais funções de validação, mutação e geração de recursos.
+
+2. **Instalação e Configuração:** Passo a passo para a instalação do Kyverno, incluindo métodos usando o Helm e arquivos YAML, e como verificar se a instalação foi bem-sucedida.
+
+3. **Desenvolvendo Políticas Eficientes:** Aprenda a criar políticas para diferentes cenários, desde garantir limites de CPU e memória em Pods até aplicar automaticamente labels a namespaces e restringir a execução de containers como root.
+
+4. **Exemplos Práticos:** Vários exemplos de políticas, ilustrando como o Kyverno pode ser aplicado para resolver problemas reais e melhorar a segurança e conformidade dos clusters Kubernetes.
+
+5. **Dicas de Uso e Melhores Práticas:** Orientações sobre como aproveitar ao máximo o Kyverno, incluindo dicas de segurança, eficiência e automatização de processos.
+
+Ao final deste e-book, você terá uma compreensão abrangente do Kyverno e estará equipado com o conhecimento e as habilidades para implementá-lo efetivamente em seus próprios clusters Kubernetes. Este e-book é projetado tanto para iniciantes quanto para profissionais experientes, proporcionando informações valiosas e práticas para todos os níveis de expertise.
+
+---
+
+## Inicio do Day-13
+
+### Introdução ao Kyverno
+
+Kyverno é uma ferramenta de gerenciamento de políticas para Kubernetes, focada na automação de várias tarefas relacionadas à segurança e configuração dos clusters de Kubernetes. Ele permite que você defina, gerencie e aplique políticas de forma declarativa para garantir que os clusters e suas cargas de trabalho estejam em conformidade com as regras e normas definidas.
+
+**Principais Funções do Kyverno:**
+
+1. **Validação de Recursos:** Verifica se os recursos do Kubernetes estão em conformidade com as políticas definidas. Por exemplo, pode garantir que todos os Pods tenham limites de CPU e memória definidos.
+
+2. **Mutação de Recursos:** Modifica automaticamente os recursos do Kubernetes para atender às políticas definidas. Por exemplo, pode adicionar automaticamente labels específicos a todos os novos Pods.
+
+3. **Geração de Recursos:** Cria recursos adicionais do Kubernetes com base nas políticas definidas. Por exemplo, pode gerar NetworkPolicies para cada novo Namespace criado.
+
+---
+
+### Instalando o Kyverno
+  
+A instalação do Kyverno em um cluster Kubernetes pode ser feita de várias maneiras, incluindo a utilização de um gerenciador de pacotes como o Helm, ou diretamente através de arquivos YAML. Aqui estão os passos básicos para instalar o Kyverno:
+
+#### Utilizando Helm
+
+O Helm é um gerenciador de pacotes para Kubernetes, que facilita a instalação e gerenciamento de aplicações. Para instalar o Kyverno com Helm, siga estes passos:
+
+1. **Adicione o Repositório do Kyverno:**
+   
+   ```shell
+   helm repo add kyverno https://kyverno.github.io/kyverno/
+   helm repo update
+   ```
+
+2. **Instale o Kyverno:**
+   
+   Você pode instalar o Kyverno no namespace `kyverno` usando o seguinte comando:
+
+   ```shell
+   helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
+   ```
+
+### Verificando a Instalação
+
+Após a instalação, é importante verificar se o Kyverno foi instalado corretamente e está funcionando como esperado.
+
+- **Verifique os Pods:**
+
+  ```shell
+  kubectl get pods -n kyverno
+  ```
+
+  Este comando deve mostrar os pods do Kyverno em execução no namespace especificado.
+
+- **Verifique os CRDs:**
+
+  ```shell
+  kubectl get crd | grep kyverno
+  ```
+
+  Este comando deve listar os CRDs relacionados ao Kyverno, indicando que foram criados corretamente.
+
+Lembrando que é sempre importante consultar a documentação oficial para obter as instruções mais atualizadas e detalhadas, especialmente se estiver trabalhando com uma configuração específica ou uma versão mais recente do Kyverno ou do Kubernetes.
+
+---
+
+### Criando a nossa primeira Policy
+
+Kyverno permite que você defina, gerencie e aplique políticas de forma declarativa para garantir que os clusters e suas cargas de trabalho estejam em conformidade com as regras e normas definidas.
+
+As políticas, ou as policies em inglês, do Kyverno podem ser aplicadas de duas maneiras principais: a nível de cluster (`ClusterPolicy`) ou a nível de namespace específico (`Policy`).
+
+1. **ClusterPolicy**: Quando você define uma política como `ClusterPolicy`, ela é aplicada a todos os namespaces no cluster. Ou seja, as regras definidas em uma `ClusterPolicy` são automaticamente aplicadas a todos os recursos correspondentes em todos os namespaces, a menos que especificamente excluídos.
+
+2. **Policy**: Se você deseja aplicar políticas a um namespace específico, você usaria o tipo `Policy`. As políticas definidas como `Policy` são aplicadas apenas dentro do namespace onde são criadas.
+
+Se você não especificar nenhum namespace na política ou usar `ClusterPolicy`, o Kyverno assumirá que a política deve ser aplicada globalmente, ou seja, em todos os namespaces.
+
+---
+
+**Exemplo de Políticas do Kyverno:**
+
+1. **Política de Limites de Recursos:** Garantir que todos os containers em um Pod tenham limites de CPU e memória definidos. Isso pode ser importante para evitar o uso excessivo de recursos em um cluster compartilhado.
+
+**Arquivo `require-resources-limits.yaml`:**
+   ```yaml
+   apiVersion: kyverno.io/v1
+   kind: ClusterPolicy
+   metadata:
+     name: require-cpu-memory-limits
+   spec:
+     validationFailureAction: enforce
+     rules:
+     - name: validate-limits
+       match:
+         resources:
+           kinds:
+           - Pod
+       validate:
+         message: "CPU and memory limits are required"
+         pattern:
+           spec:
+             containers:
+             - name: "*"
+               resources:
+                 limits:
+                   memory: "?*"
+                   cpu: "?*"
+   ```
+
+
+Depois do arquivo criado, agora bastar realizar o deploy em nosso cluster Kubernetes.
+
+```bash
+kubectl apply -f require-resources-limits.yaml
+```
+
+Agora, tenta realizar o deploy de um simples Nginx sem definir o limite para os recursos.
+
+**Arquivo `pod.yaml`:**
+```bash
+apiVersion: v1
+kind: Pod
+metadata:
+  name: exemplo-pod
+spec:
+  containers:
+  - name: exemplo-container
+    image: nginx
+```
+
+```bash
+kubectl apply -f pod.yaml
+```
+---
+
+### Mais exemplos de Policies
+Continuando com a explicação e exemplos de políticas do Kyverno para gerenciamento de clusters Kubernetes:
+
+Entendi, vou formatar o texto para que esteja pronto para ser copiado para o Google Docs:
+
+---
+
+#### Exemplo de Política: Adicionar Label ao Namespace
+
+A política `add-label-namespace` é projetada para automatizar a adição de um label específico a todos os Namespaces em um cluster Kubernetes. Esta abordagem é essencial para a organização, monitoramento e controle de acesso em ambientes complexos.
+
+##### Detalhes da Política
+
+O label adicionado por esta política é `Jeferson: "Lindo_Demais"`. A aplicação deste label a todos os Namespaces facilita a identificação e a categorização dos mesmos, permitindo uma gestão mais eficiente e uma padronização no uso de labels.
+
+##### Arquivo de Política: `add-label-namespace.yaml`
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: add-label-namespace
+spec:
+  rules:
+  - name: add-label-ns
+    match:
+      resources:
+        kinds:
+        - Namespace
+    mutate:
+      patchStrategicMerge:
+        metadata:
+          labels:
+            Jeferson: "Lindo_Demais"
+```
+
+##### Utilização da Política
+
+Esta política garante que cada Namespace no cluster seja automaticamente etiquetado com `Jeferson: "Lindo_Demais"`. Isso é particularmente útil para garantir a conformidade e a uniformidade na atribuição de labels, facilitando operações como filtragem e busca de Namespaces com base em critérios específicos.
+
+---
+
+#### Exemplo de Política: Proibir Usuário Root
+
+A política `disallow-root-user` é uma regra de segurança crítica no gerenciamento de clusters Kubernetes. Ela proíbe a execução de containers como usuário root dentro de Pods. Este controle ajuda a prevenir possíveis vulnerabilidades de segurança e a reforçar as melhores práticas no ambiente de contêineres.
+
+##### Detalhes da Política
+
+O principal objetivo desta política é garantir que nenhum Pod no cluster execute containers como o usuário root. A execução de containers como root pode expor o sistema a riscos de segurança, incluindo acessos não autorizados e potenciais danos ao sistema host.
+
+##### Arquivo de Política: `disallow-root-user.yaml`
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: disallow-root-user
+spec:
+  validationFailureAction: Enforce
+  rules:
+  - name: check-runAsNonRoot
+    match:
+      resources:
+        kinds:
+        - Pod
+    validate:
+      message: "Running as root is not allowed. Set runAsNonRoot to true."
+      pattern:
+        spec:
+          containers:
+          - securityContext:
+              runAsNonRoot: true
+```
+
+##### Implementação e Efeito
+
+Ao aplicar esta política, todos os Pods que tentarem executar containers como usuário root serão impedidos, com a exibição de uma mensagem de erro indicando que a execução como root não é permitida. Isso assegura uma camada adicional de segurança no ambiente Kubernetes, evitando práticas que possam comprometer a integridade e a segurança do cluster.
+
+---
+
+#### Exemplo de Política: Gerar ConfigMap para Namespace
+
+A política `generate-configmap-for-namespace` é uma estratégia prática no gerenciamento de Kubernetes para automatizar a criação de ConfigMaps em Namespaces. Esta política simplifica a configuração e a gestão de múltiplos ambientes dentro de um cluster.
+
+##### Detalhes da Política
+
+Esta política é projetada para criar automaticamente um ConfigMap em cada Namespace recém-criado. O ConfigMap gerado, denominado `default-configmap`, inclui um conjunto padrão de chaves e valores, facilitando a configuração inicial e a padronização dos Namespaces.
+
+##### Arquivo de Política: `generate-configmap-for-namespace.yaml`
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: generate-configmap-for-namespace
+spec:
+  rules:
+    - name: generate-namespace-configmap
+      match:
+        resources:
+          kinds:
+            - Namespace
+      generate:
+        kind: ConfigMap
+        name: default-configmap
+        namespace: "{{request.object.metadata.name}}"
+        data:
+          data:
+            key1: "value1"
+            key2: "value2"
+```
+
+##### Implementação e Utilidade
+
+A aplicação desta política resulta na criação automática de um ConfigMap padrão em cada Namespace novo, proporcionando uma forma rápida e eficiente de distribuir configurações comuns e informações essenciais. Isso é particularmente útil em cenários onde a consistência e a automatização de configurações são cruciais.
+
+---
+
+#### Exemplo de Política: Permitir Apenas Repositórios Confiáveis
+
+A política `ensure-images-from-trusted-repo` é essencial para a segurança dos clusters Kubernetes, garantindo que todos os Pods utilizem imagens provenientes apenas de repositórios confiáveis. Esta política ajuda a prevenir a execução de imagens não verificadas ou potencialmente mal-intencionadas.
+
+##### Detalhes da Política
+
+Esta política impõe que todas as imagens de containers usadas nos Pods devem ser originárias de repositórios especificados e confiáveis. A estratégia é crucial para manter a integridade e a segurança do ambiente de containers, evitando riscos associados a imagens desconhecidas ou não autorizadas.
+
+##### Arquivo de Política: `registry-allowed.yaml`
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: ensure-images-from-trusted-repo
+spec:
+  validationFailureAction: enforce
+  rules:
+  - name: trusted-repo-check
+    match:
+      resources:
+        kinds:
+        - Pod
+    validate:
+      message: "Only images from trusted repositories are allowed"
+      pattern:
+        spec:
+          containers:
+          - name: "*"
+            image: "trustedrepo.com/*"
+```
+
+##### Implementação e Impacto
+
+Com a implementação desta política, qualquer tentativa de implantar um Pod com uma imagem de um repositório não confiável será bloqueada. A política assegura que apenas imagens de fontes aprovadas sejam usadas, fortalecendo a segurança do cluster contra vulnerabilidades e ataques externos.
+
+---
+
+##### Exemplo de Política: Require Probes
+
+A política `require-readinessprobe` desempenha um papel crucial no gerenciamento de tráfego e na garantia da disponibilidade de serviços em um cluster Kubernetes. Ela exige que todos os Pods tenham uma sonda de prontidão (readiness probe) configurada, assegurando que o tráfego seja direcionado para os Pods apenas quando estiverem prontos para processar solicitações.
+
+##### Detalhes da Política
+
+Esta política visa melhorar a confiabilidade e eficiência dos serviços executados no cluster, garantindo que os Pods estejam prontos para receber tráfego antes de serem expostos a solicitações externas. A sonda de prontidão verifica se o Pod está pronto para atender às solicitações, ajudando a evitar interrupções e problemas de desempenho.
+
+##### Arquivo de Política: `require-probes.yaml`
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: require-readinessprobe
+spec:
+  validationFailureAction: Enforce
+  rules:
+    - name: require-readinessProbe
+      match:
+        resources:
+          kinds:
+            - Pod
+      validate:
+        message: "Readiness probe is required."
+        pattern:
+          spec:
+            containers:
+              - readinessProbe:
+                  httpGet:
+                    path: "/"
+                    port: 8080
+```
+
+##### Implementação e Impacto
+
+Com a aplicação desta política, todos os novos Pods ou Pods atualizados devem incluir uma configuração de sonda de prontidão, que normalmente envolve a especificação de um caminho e porta para checagem HTTP. Isso assegura que o serviço só receba tráfego quando estiver totalmente operacional, melhorando a confiabilidade e a experiência do usuário.
+
+---
+
+#### Exemplo de Política: Usando o Exclude
+
+A política `require-resources-limits` é uma abordagem proativa para gerenciar a utilização de recursos em um cluster Kubernetes. Ela garante que todos os Pods tenham limites de recursos definidos, como CPU e memória, mas com uma exceção específica para um namespace.
+
+##### Detalhes da Política
+
+Essa política impõe que cada Pod no cluster tenha limites explícitos de CPU e memória configurados. Isso é crucial para evitar o consumo excessivo de recursos, que pode afetar outros Pods e a estabilidade geral do cluster. No entanto, esta política exclui especificamente o namespace `giropops` desta regra.
+
+##### Arquivo de Política
+
+```yaml
+apiVersion: kyverno.io/v1
+kind: ClusterPolicy
+metadata:
+  name: require-resources-limits
+spec:
+  validationFailureAction: Enforce
+  rules:
+  - name: validate-limits
+    match:
+      resources:
+        kinds:
+        - Pod
+    exclude:
+      resources:
+        namespaces:
+        - giropops
+    validate:
+      message: "Precisa definir o limites de recursos"
+      pattern:
+        spec:
+          containers:
+          - name: "*"
+            resources:
+              limits:
+                cpu: "?*"
+                memory: "?*"
+```
+
+##### Implementação e Efeitos
+
+Ao aplicar esta política, todos os Pods novos ou atualizados precisam ter limites de recursos claramente definidos, exceto aqueles no namespace `giropops`. Isso assegura uma melhor gestão de recursos e evita situações onde alguns Pods possam monopolizar recursos em detrimento de outros.
+
+---
+
+### Conclusão
+
+Ao longo deste artigo, exploramos as capacidades e funcionalidades do Kyverno, uma ferramenta inovadora e essencial para o gerenciamento de políticas em clusters Kubernetes. Compreendemos como o Kyverno simplifica e automatiza tarefas críticas relacionadas à segurança, conformidade e configuração, tornando-se um componente indispensável na administração de ambientes Kubernetes.
+
+#### Pontos-Chave Aprendidos
+
+1. **Automação e Conformidade:** Vimos como o Kyverno permite definir, gerenciar e aplicar políticas de forma declarativa, garantindo que os recursos do Kubernetes estejam sempre em conformidade com as regras e normas estabelecidas. Esta abordagem reduz significativamente o esforço manual, minimiza erros e assegura uma maior consistência em todo o ambiente.
+
+2. **Validação, Mutação e Geração de Recursos:** Aprendemos sobre as três funções principais do Kyverno – validação, mutação e geração de recursos – e como cada uma delas desempenha um papel vital na gestão eficaz do cluster. Estas funções proporcionam um controle granular sobre os recursos, desde a garantia de limites de CPU e memória até a aplicação automática de labels e a criação dinâmica de ConfigMaps.
+
+3. **Flexibilidade de Políticas:** Discutimos a diferença entre `ClusterPolicy` e `Policy`, destacando como o Kyverno oferece flexibilidade para aplicar políticas em todo o cluster ou em namespaces específicos. Isso permite uma gestão personalizada e adaptada às necessidades de diferentes partes do cluster.
+
+4. **Instalação e Verificação:** Abordamos as várias maneiras de instalar o Kyverno, com foco especial no uso do Helm, um gerenciador de pacotes popular para Kubernetes. Também exploramos como verificar a instalação correta do Kyverno, assegurando que tudo esteja funcionando conforme esperado.
+
+5. **Práticas de Segurança:** O artigo enfatizou a importância da segurança em Kubernetes, demonstrada por políticas como a proibição de execução de containers como usuário root e a exigência de imagens provenientes de repositórios confiáveis. Essas políticas ajudam a prevenir vulnerabilidades e garantir a integridade do cluster.
+
+6. **Automatização e Eficiência:** Por fim, aprendemos como o Kyverno facilita a automatização e a eficiência operacional. As políticas do Kyverno reduzem a necessidade de intervenção manual, aumentam a segurança e ajudam na conformidade regulatória, tornando a administração do Kubernetes mais simples e confiável.
+
+Em resumo, o Kyverno é uma ferramenta poderosa que transforma a maneira como as políticas são gerenciadas em Kubernetes. Seu enfoque na automação, flexibilidade e segurança o torna um componente essencial para qualquer administrador de Kubernetes que deseja otimizar a gestão de clusters, assegurar a conformidade e reforçar a segurança. Com o Kyverno, podemos atingir um nível mais alto de eficiência e confiança nos nossos ambientes Kubernetes, preparando-nos para enfrentar os desafios de um ecossistema em constante evolução.
+
+---
\ No newline at end of file
diff --git a/es/day-5/README.md b/es/day-5/README.md
index 32ca4df1..665074c9 100644
--- a/es/day-5/README.md
+++ b/es/day-5/README.md
@@ -36,7 +36,7 @@
         - [¿Qué es CNI?](#qué-es-cni)
       - [Visualizando detalles de los nodos](#visualizando-detalles-de-los-nodos)
     - [Tu tarea](#tu-tarea)
-  - [Fin del Día 5](#fin-del-día-5)
+  - [Final del Día 5](#final-del-día-5)
 
 &nbsp;
 
@@ -766,7 +766,7 @@ Lo más importante es tener un clúster de Kubernetes funcionando y listo para s
 
 &nbsp;
 
-## Fin del Día 5
+## Final del Día 5
 
 Durante el Día 5, aprendiste cómo crear un clúster de Kubernetes utilizando 3 nodos a través de Kubeadm. Aprendiste todos los detalles importantes sobre el clúster y sus componentes. Instalamos el complemento de red Weave Net y también conocimos qué es la CNI y los complementos de red más utilizados en Kubernetes.
 
diff --git a/es/day-8/README.md b/es/day-8/README.md
index 061cc10c..a0c9e9ef 100644
--- a/es/day-8/README.md
+++ b/es/day-8/README.md
@@ -16,34 +16,25 @@
         - [Antes de crear un Secret, el Base64](#antes-de-crear-un-secret-el-base64)
         - [Creando nuestro primer Secret](#creando-nuestro-primer-secret)
         - [Usando nuestro primer Secret](#usando-nuestro-primer-secret)
-<<<<<<< HEAD
-        - [Creando un Secret para almacenar credenciales Docker](#creando-un-secret-para-almacenar-credenciales-docker)
-        - [Creando un Secret TLS](#creando-un-secret-tls)
-      - [ConfigMaps](#configmaps)
-      - [External Secret Operator](#external-secret-operator)
-        - [El Papel Destacado del ESO](#el-papel-destacado-del-eso)
-        - [Conceptos Clave del External Secrets Operator](#conceptos-clave-del-external-secrets-operator)
-=======
         - [Creando un Secreto para almacenar credenciales de Docker](#creando-un-secreto-para-almacenar-credenciales-de-docker)
-        - [Criando um Secret TLS](#criando-um-secret-tls)
+        - [Creando un Secret TLS](#creando-un-secret-tls)
       - [ConfigMaps](#configmaps)
       - [Operador de Secretos Externos](#operador-de-secretos-externos)
         - [El Rol Destacado del ESO](#el-rol-destacado-del-eso)
         - [Conceptos Clave del Operador de Secretos Externos](#conceptos-clave-del-operador-de-secretos-externos)
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
         - [SecretStore](#secretstore)
         - [ExternalSecret](#externalsecret)
         - [ClusterSecretStore](#clustersecretstore)
         - [Control de Acceso y Seguridad](#control-de-acceso-y-seguridad)
       - [Configurando el External Secrets Operator](#configurando-el-external-secrets-operator)
         - [¿Qué es Vault?](#qué-es-vault)
-<<<<<<< HEAD
         - [¿Por Qué Usar Vault?](#por-qué-usar-vault)
         - [Comandos Básicos de Vault](#comandos-básicos-de-vault)
         - [El Vault en el Contexto de Kubernetes](#el-vault-en-el-contexto-de-kubernetes)
         - [Instalación y Configuración de Vault en Kubernetes](#instalación-y-configuración-de-vault-en-kubernetes)
         - [Requisitos Previos](#requisitos-previos)
         - [Instalando y Configurando Vault con Helm](#instalando-y-configurando-vault-con-helm)
+- [Este comando agrega el repositorio Helm de HashiCorp a nuestra configuración de Helm.](#este-comando-agrega-el-repositorio-helm-de-hashicorp-a-nuestra-configuración-de-helm)
         - [Agregar el Repositorio del Operador de Secretos Externos a Helm](#agregar-el-repositorio-del-operador-de-secretos-externos-a-helm)
         - [Instalando el Operador de Secretos Externos](#instalando-el-operador-de-secretos-externos)
         - [Verificación de la Instalación de ESO](#verificación-de-la-instalación-de-eso)
@@ -51,21 +42,6 @@
         - [Configuración del ClusterSecretStore](#configuración-del-clustersecretstore)
         - [Creación de un ExternalSecret](#creación-de-un-externalsecret)
   - [Final del Día 8](#final-del-día-8)
-=======
-        - [¿Por qué usar Vault?](#por-qué-usar-vault)
-        - [Comandos Básicos de Vault](#comandos-básicos-de-vault)
-        - [El Vault en el contexto de Kubernetes](#el-vault-en-el-contexto-de-kubernetes)
-        - [Instalación y configuración de Vault en Kubernetes](#instalación-y-configuración-de-vault-en-kubernetes)
-        - [Requisitos previos](#requisitos-previos)
-        - [Instalación y configuración de Vault con Helm](#instalación-y-configuración-de-vault-con-helm)
-        - [Adicionando o Repositório do External Secrets Operator ao Helm](#adicionando-o-repositório-do-external-secrets-operator-ao-helm)
-        - [Instalando o External Secrets Operator](#instalando-o-external-secrets-operator)
-        - [Verificando a Instalação do ESO](#verificando-a-instalação-do-eso)
-        - [Criando um Segredo no Kubernetes](#criando-um-segredo-no-kubernetes)
-        - [Configurando o ClusterSecretStore](#configurando-o-clustersecretstore)
-        - [Criando um ExternalSecret](#criando-um-externalsecret)
-  - [Final do Day-8](#final-do-day-8)
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 &nbsp;
 
@@ -260,15 +236,6 @@ Si comparas las cadenas de los campos `username` y `password` del Secret creado
 
 ##### Usando nuestro primer Secret
 
-<<<<<<< HEAD
-Ahora que ya tenemos nuestro primer Secret creado, es hora de aprender cómo utilizarlo en un Pod.
-
-En este primer ejemplo, solo mostraré cómo usar el Secret en un Pod, pero todavía sin ninguna "función" especial, solo para demostrar cómo se utiliza el Secret.
-
-Para usar el Secret en un Pod, necesitas definir el campo spec.containers[].env[].valueFrom.secretKeyRef en el archivo YAML del Pod. Estoy presentando el campo en este formato para que puedas empezar a familiarizarte con él, ya que lo utilizarás bastante para buscar alguna información más específica en la línea de comandos, usando el comando kubectl get, por ejemplo.
-
-Volviendo al tema principal, necesitamos crear nuestro Pod, ¡así que vamos allá! Crea un archivo llamado giropops-pod.yaml con el siguiente contenido:
-=======
 Ahora que ya hemos creado nuestro primer Secret, es hora de aprender cómo usarlo en un Pod.
 
 En este primer ejemplo, solo mostraré cómo usar el Secret en un Pod, pero aún sin ninguna "función" especial, solo para demostrar cómo usar el Secret.
@@ -276,7 +243,6 @@ En este primer ejemplo, solo mostraré cómo usar el Secret en un Pod, pero aún
 Para utilizar el Secret en un Pod, debes definir el campo `spec.containers[].env[].valueFrom.secretKeyRef` en el archivo YAML del Pod. Estoy presentando este campo en este formato para que puedas empezar a familiarizarte con él, ya que lo utilizarás bastante para buscar información más específica en la línea de comandos, por ejemplo, usando el comando `kubectl get`.
 
 Volviendo al tema principal, necesitamos crear nuestro Pod, ¡así que vamos allá! Crea un archivo llamado `giropops-pod.yaml` con el siguiente contenido:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: v1
@@ -288,18 +254,6 @@ spec:
   - name: giropops-container
     image: nginx
     env: # Inicio de la definición de las variables de entorno
-<<<<<<< HEAD
-    - name: USERNAME # Nombre de la variable de entorno que se usará en el Pod
-      valueFrom: # Inicio de la definición de dónde se buscará el valor de la variable de entorno
-        secretKeyRef: # Inicio de la definición de que el valor de la variable de entorno se buscará en un Secret, a través de una clave
-          name: giropops-secret # Nombre del Secret que contiene el valor de la variable de entorno que se usará en el Pod
-          key: username # Nombre de la clave del campo del Secret que contiene el valor de la variable de entorno que se usará en el Pod
-    - name: PASSWORD # Nombre de la variable de entorno que se usará en el Pod
-      valueFrom: # Inicio de la definición de dónde se buscará el valor de la variable de entorno
-        secretKeyRef: # Inicio de la definición de que el valor de la variable de entorno se buscará en un Secret, a través de una clave
-          name: giropops-secret # Nombre del Secret que contiene el valor de la variable de entorno que se usará en el Pod
-          key: password # Nombre de la clave del campo del Secret que contiene el valor de la variable de entorno que se usará en el Pod
-=======
     - name: USERNAME # Nombre de la variable de entorno que se utilizará en el Pod
       valueFrom: # Inicio de la definición de dónde se buscará el valor de la variable de entorno
         secretKeyRef: # Inicio de la definición de que el valor de la variable de entorno se buscará en un Secreto, a través de una clave
@@ -310,24 +264,12 @@ spec:
         secretKeyRef: # Inicio de la definición de que el valor de la variable de entorno se buscará en un Secreto, a través de una clave
           name: giropops-secret # Nombre del Secreto que contiene el valor de la variable de entorno que se utilizará en el Pod
           key: password # Nombre de la clave del campo del Secreto que contiene el valor de la variable de entorno que se utilizará en el Pod
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 ```
 
 &nbsp;
 
 He añadido comentarios en las líneas que son nuevas para ti, para que puedas entender lo que hace cada línea.
 
-<<<<<<< HEAD
-Pero aquí te traigo una explicación más detallada sobre el campo `spec.containers[].env[].valueFrom.secretKeyRef`:
-
-- `spec.containers[].env[].valueFrom.secretKeyRef.name`: el nombre del Secret que contiene el valor de la variable de entorno que se utilizará en el Pod;
-
-- `spec.containers[].env[].valueFrom.secretKeyRef.key`: la clave del campo del Secret que contiene el valor de la variable de entorno que se utilizará en el Pod;
-
-Con esto tendremos un Pod, que tendrá un contenedor llamado `giropops-container`, que contará con dos variables de entorno, `USERNAME` y `PASSWORD`, que tendrán los valores definidos en el Secret `giropops-secret`.
-
-Ahora vamos a crear el Pod usando el comando kubectl apply:
-=======
 Pero ahora proporcionaré una explicación más detallada sobre el campo `spec.containers[].env[].valueFrom.secretKeyRef`:
 
 - `spec.containers[].env[].valueFrom.secretKeyRef.name`: el nombre del Secreto que contiene el valor de la variable de entorno que se utilizará en el Pod.
@@ -336,8 +278,7 @@ Pero ahora proporcionaré una explicación más detallada sobre el campo `spec.c
 
 Con esto, tendremos un Pod que tendrá un contenedor llamado `giropops-container` con dos variables de entorno, `USERNAME` y `PASSWORD`, que tendrán los valores definidos en el Secret `giropops-secret`.
 
-Ahora crearemos el Pod utilizando el comando kubectl apply:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
+Ahora crearemos el Pod utilizando el comando `kubectl apply`:
 
 ```bash
 Copy code
@@ -348,11 +289,7 @@ pod/giropops-pod created
 
 &nbsp;
 
-<<<<<<< HEAD
 Ahora vamos a verificar si el Pod ha sido creado y si los Secrets han sido inyectados en el Pod:
-=======
-Luego verificaremos si el Pod ha sido creado y si los Secretos se han inyectado en el Pod:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl get pods
@@ -363,11 +300,7 @@ giropops-pod   1/1     Running   0          2m
 
 &nbsp;
 
-<<<<<<< HEAD
-Para verificar si los Secrets han sido inyectados en el Pod, puedes utilizar el comando kubectl exec para ejecutar el comando env dentro del contenedor del Pod:
-=======
-Para verificar si los Secretos se han inyectado en el Pod, puedes utilizar el comando `kubectl exec` para ejecutar el comando `env` dentro del contenedor del Pod:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
+Para verificar si los Secrets han sido inyectados en el Pod, puedes utilizar el comando `kubectl exec` para ejecutar el comando `env` dentro del contenedor del Pod:
 
 ```bash
 kubectl exec giropops-pod -- env
@@ -392,33 +325,14 @@ HOME=/root
 
 &nbsp;
 
-<<<<<<< HEAD
-¡Mira ahí nuestros Secrets como variables de entorno dentro del contenedor del Pod!
-
-¡Listo! ¡Tarea ejecutada con éxito! \o/
-
-Ahora creo que ya podemos pasar a los siguientes tipos de Secrets!
-
-&nbsp;
-
-##### Creando un Secret para almacenar credenciales Docker
-
-Docker Hub es un servicio de registro de imágenes Docker, que permite almacenar y compartir imágenes Docker públicamente o de manera privada. En 2022, Docker Hub comenzó a limitar el número de descargas de imágenes Docker públicas a 100 descargas cada 6 horas para usuarios no autenticados, y para usuarios autenticados, el límite es de 200 descargas cada 6 horas.
-
-Pero el punto aquí es que puedes usar Docker Hub para almacenar imágenes Docker privadas, y para eso necesitas una cuenta en Docker Hub, y para acceder a tu cuenta en Docker Hub, necesitas un nombre de usuario y una contraseña. ¿Entiendes a dónde quiero llegar? :D
-
-Para que Kubernetes pueda acceder a Docker Hub, necesitas crear un Secret que almacene el nombre de usuario y la contraseña de tu cuenta en Docker Hub, y luego necesitas configurar Kubernetes para usar ese Secret.
-
-Cuando ejecutas `docker login` y tu autenticación es exitosa, Docker crea un archivo llamado `config.json` en el directorio `~/.docker/` de tu usuario, y ese archivo contiene el nombre de usuario y la contraseña de tu cuenta en Docker Hub, y es ese archivo el que necesitas usar para crear tu Secret.
-
-El primer paso es obtener el contenido de tu archivo `config.json` y codificarlo en base64, y para eso puedes usar el comando `base64`:
-=======
 Mira allí nuestros Secretos como variables de entorno dentro del contenedor del Pod.
 
 ¡Listo! ¡Tarea ejecutada con éxito! \o/
 
 Ahora creo que podemos avanzar hacia los próximos tipos de Secrets.
 
+&nbsp;
+
 ##### Creando un Secreto para almacenar credenciales de Docker
 
 Docker Hub es un servicio de registro de imágenes Docker que te permite almacenar y compartir imágenes Docker de forma pública o privada. En 2022, Docker Hub comenzó a limitar la cantidad de descargas de imágenes Docker públicas a 100 descargas cada 6 horas para usuarios no autenticados, y para usuarios autenticados, el límite es de 200 descargas cada 6 horas.
@@ -430,7 +344,6 @@ Para que Kubernetes pueda acceder a Docker Hub, necesitas crear un Secreto que a
 Cuando ejecutas `docker login` y la autenticación se realiza con éxito, Docker crea un archivo llamado `config.json` en el directorio `~/.docker/` de tu usuario. Este archivo contiene el nombre de usuario y la contraseña de tu cuenta en Docker Hub, y es este archivo el que debes utilizar para crear tu Secreto.
 
 El primer paso es tomar el contenido de tu archivo `config.json` y codificarlo en base64, para lo cual puedes usar el comando `base64`:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 base64 ~/.docker/config.json
@@ -440,40 +353,24 @@ QXF1aSB0ZW0gcXVlIGVzdGFyIG8gY29udGXDumRvIGRvIHNldSBjb25maWcuanNvbiwgY29pc2EgbGlu
 
 &nbsp;
 
-<<<<<<< HEAD
-¡Entonces vamos allá! Crea un archivo llamado `dockerhub-secret.yaml`con el siguiente contenido:
-=======
-¡Entonces, adelante! Crea un archivo llamado dockerhub-secret.yaml con el siguiente contenido:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
+¡Entonces, adelante! Crea un archivo llamado `dockerhub-secret.yaml` con el siguiente contenido:
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-<<<<<<< HEAD
-  name: docker-hub-secret # nombre del Secret
-type: kubernetes.io/dockerconfigjson # tipo del Secret, en este caso es un Secret que almacena credenciales Docker
-data:
-  .dockerconfigjson: |  # sustituye este valor por el contenido de tu archivo config.json codificado en base64
-=======
   name: docker-hub-secret # nombre del Secreto
 type: kubernetes.io/dockerconfigjson # tipo de Secreto, en este caso, es un Secreto que almacena credenciales de Docker
 data:
   .dockerconfigjson: |  # reemplace este valor con el contenido de su archivo config.json codificado en base64
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
     QXF1aSB0ZW0gcXVlIGVzdGFyIG8gY29udGXDumRvIGRvIHNldSBjb25maWcuanNvbiwgY29pc2EgbGluZGEgZG8gSmVmaW0=
 ```
-&nbsp;
 
-<<<<<<< HEAD
-Lo nuevo aquí es en el campo `type`, que define el tipo del Secret, y en este caso es un Secret que almacena credenciales Docker, y en el campo `data` tenemos el campo `dockerconfigjson`, que es el nombre del campo del Secret que almacena el contenido del archivo `config.json` codificado en base64.
+&nbsp;
 
-Ahora vamos a crear el Secret usando el comando `kubectl apply`:
-=======
 Lo que tenemos de nuevo aquí es en el campo `type`, que define el tipo del Secret, y en este caso es un Secret que almacena credenciales de Docker. Y en el campo data, tenemos el campo `dockerconfigjson`, que es el nombre del campo del Secret que almacena el contenido del archivo `config.json` codificado en `base64`.
 
 Ahora crearemos el Secret utilizando el comando `kubectl apply`:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl apply -f dockerhub-secret.yaml
@@ -483,11 +380,7 @@ secret/docker-hub-secret created
 
 &nbsp;
 
-<<<<<<< HEAD
-Para listar el Secret que acabamos de crear, puedes usar el comando `kubectl get`:
-=======
 Para listar el Secret que acabamos de crear, puedes utilizar el comando `kubectl get`:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl get secrets
@@ -498,19 +391,11 @@ docker-hub-secret   kubernetes.io/dockerconfigjson   1      1s
 
 &nbsp;
 
-<<<<<<< HEAD
 Secret creada, ¡ahora ya podemos probar el acceso al Docker Hub!
 
 Ahora Kubernetes ya tiene acceso al Docker Hub, y puedes usar Kubernetes para hacer pull de imágenes Docker privadas del Docker Hub.
 
 Una cosa importante, siempre que necesites crear un Pod que requiera utilizar una imagen Docker privada del Docker Hub, necesitas configurar el Pod para usar el Secret que almacena las credenciales del Docker Hub, y para eso necesitas usar el campo `spec.imagePullSecrets` en el archivo YAML del Pod.
-=======
-¡Secret creado, ahora podemos probar el acceso a Docker Hub!
-
-Ahora Kubernetes tiene acceso a Docker Hub, y puedes utilizar Kubernetes para hacer la descarga de imágenes Docker privadas desde Docker Hub.
-
-Una cosa importante, cada vez que necesites crear un Pod que deba utilizar una imagen Docker privada de Docker Hub, debes configurar el Pod para que utilice el Secret que almacena las credenciales de Docker Hub, y para ello, debes utilizar el campo `spec.imagePullSecrets` en el archivo YAML del Pod.
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: v1
@@ -521,43 +406,25 @@ spec:
   containers:
   - name: mi-container
     image: mi-imagen-privada
-<<<<<<< HEAD
   imagePullSecrets: # campo que define el Secret que almacena las credenciales del Docker Hub
-=======
-  imagePullSecrets: # campo que define el Secret que almacena las credenciales de Docker Hub
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
   - name: docker-hub-secret # nombre del Secret
 ```
 
 &nbsp;
 
-<<<<<<< HEAD
 Observa la utilización del campo `spec.imagePullSecrets` en el archivo YAML del Pod, y el campo `name` que define el nombre del Secret que almacena las credenciales del Docker Hub. Esto es todo lo que necesitas hacer para que Kubernetes pueda acceder al Docker Hub.
 
 &nbsp;
-=======
-Observa el uso del campo `spec.imagePullSecrets` en el archivo YAML del Pod y el campo `name` que define el nombre del Secreto que almacena las credenciales de Docker Hub. Esto es todo lo que necesitas hacer para que Kubernetes pueda acceder a Docker Hub.
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ##### Creando un Secret TLS
 
-<<<<<<< HEAD
-El Secret `kubernetes.io/tls`, se utiliza para almacenar certificados TLS y claves privadas. Se usan para proporcionar seguridad en la comunicación entre los servicios en Kubernetes. Por ejemplo, puedes usar un Secret TLS para configurar HTTPS en tu servicio web.
-
-Para crear un Secret TLS, necesitas tener un certificado TLS y una clave privada, y necesitas codificar el certificado y la clave privada en base64 para luego crear el Secret.
-
-Vamos a crear un Secret TLS para nuestro servicio web, pero para eso, necesitas tener un certificado TLS y una clave privada antes de nada.
-
-Para crear un certificado TLS y una clave privada, puedes usar el comando `openssl`:
-=======
-El Secreto `kubernetes.io/tls` se utiliza para almacenar certificados TLS y claves privadas. Se utilizan para proporcionar seguridad en la comunicación entre servicios en Kubernetes. Por ejemplo, puedes utilizar un Secreto TLS para configurar HTTPS en tu servicio web.
+El Secret `kubernetes.io/tls` se utiliza para almacenar certificados TLS y claves privadas. Se utilizan para proporcionar seguridad en la comunicación entre servicios en Kubernetes. Por ejemplo, puedes utilizar un Secreto TLS para configurar HTTPS en tu servicio web.
 
 Para crear un Secreto TLS, necesitas tener un certificado TLS y una clave privada, y debes codificar el certificado y la clave privada en base64 antes de crear el Secreto.
 
 Crearemos un Secreto TLS para nuestro servicio web, pero primero debes tener un certificado TLS y una clave privada.
 
 Para crear un certificado TLS y una clave privada, puedes utilizar el comando `openssl`:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout clave-privada.key -out certificado.crt
@@ -565,7 +432,6 @@ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout clave-privada.key -o
 
 &nbsp;
 
-<<<<<<< HEAD
 En el comando anterior, estamos creando un certificado TLS y una clave privada, y el certificado y la clave privada se almacenarán en los archivos `certificado.crt` y `clave-privada.key`, respectivamente. Puedes sustituir los nombres de los archivos por cualquier nombre que quieras.
 Estamos usando el comando `openssl` para crear un certificado TLS auto-firmado, y para ello necesitas responder algunas preguntas, como el país, estado, ciudad, etc. Puedes responder cualquier cosa, no hay problema. Este certificado TLS auto-firmado es solo para fines de prueba, y no debe ser utilizado en producción. Estamos pasando el parámetro `-nodes` para que la clave privada no sea cifrada con una contraseña, y el parámetro `-days` para definir la validez del certificado TLS, que en este caso es de 365 días. El parámetro `-newkey` se utiliza para definir el algoritmo de cifrado de la clave privada, que en este caso es `rsa:2048`, un algoritmo de cifrado asimétrico que utiliza claves de 2048 bits.
 
@@ -581,33 +447,13 @@ Con el certificado TLS y la clave privada creados, vamos a crear nuestro Secret,
 
 ```bash
 kubectl create secret tls mi-servicio-web-tls-secret --cert=certificado.crt --key=clave-privada.key
-=======
-En el comando anterior, estamos creando un certificado TLS y una clave privada, y el certificado y la clave privada se almacenarán en los archivos `certificado.crt` y `chave-privada.key`, respectivamente. Puedes cambiar los nombres de los archivos por cualquier nombre que desees. Estamos utilizando el comando `openssl` para crear un certificado TLS autofirmado, para lo cual debes responder algunas preguntas, como el país, el estado, la ciudad, etc. Puedes responder cualquier cosa, no hay problema. Este certificado TLS autofirmado es solo para fines de prueba y no debe utilizarse en producción. Estamos utilizando el parámetro `-nodes` para que la clave privada no esté cifrada con una contraseña, y el parámetro `-days` para establecer la vigencia del certificado TLS, que en este caso es de 365 días. El parámetro `-newkey` se utiliza para establecer el algoritmo de cifrado de la clave privada, que en este caso es `rsa:2048`, que es un algoritmo de cifrado asimétrico que utiliza claves de 2048 bits.
-
-No entraré en detalles sobre lo que es un certificado TLS y una clave privada, pero en resumen, un certificado TLS (Transport Layer Security) se utiliza para autenticar y establecer una conexión segura entre dos partes, como un cliente y un servidor. Contiene información sobre la entidad para la que se emitió y la entidad que lo emitió, así como la clave pública de la entidad para la que se emitió.
-
-Por otro lado, la clave privada se utiliza para descifrar la información que se ha cifrado con la clave pública. Debe mantenerse en secreto y nunca compartirla, ya que cualquier persona con acceso a la clave privada puede descifrar la comunicación segura. Juntos, el certificado TLS y la clave privada forman un par de claves que permite la autenticación y la comunicación segura entre las partes.
-
-¿Entendido? Espero que sí, porque no entraré en más detalles sobre esto. ¡jajaja!
-
-Ahora volvamos a enfocarnos en la creación del Secreto TLS.
-
-Con el certificado TLS y la clave privada creados, crearemos nuestro Secreto, solo para variar un poco. Crearemos el Secreto utilizando el comando `kubectl apply`:
-
-```bash
-kubectl create secret tls meu-servicio-web-tls-secret --cert=certificado.crt --key=chave-privada.key
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 secret/mi-servicio-web-tls-secret created
 ```
 
 &nbsp;
 
-<<<<<<< HEAD
-Vamos a ver si el Secret fue creado:
-=======
 Vamos a comprobar si el Secret ha sido creado:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl get secrets
@@ -617,15 +463,9 @@ mi-servicio-web-tls-secret   kubernetes.io/tls                2      4s
 
 &nbsp;
 
-<<<<<<< HEAD
-Sí, el Secret está allí y es del tipo `kubernetes.io/tls`.
-
-Si quieres ver el contenido del Secret, puedes usar el comando `kubectl get secret` con el parámetro `-o yaml`:
-=======
 Sí, el Secret está ahí y es del tipo `kubernetes.io/tls`.
 
 Si deseas ver el contenido del Secret, puedes utilizar el comando `kubectl get secret` con el parámetro `-o yaml`:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl get secret mi-servicio-web-tls-secret -o yaml
@@ -633,11 +473,7 @@ kubectl get secret mi-servicio-web-tls-secret -o yaml
 
 &nbsp;
 
-<<<<<<< HEAD
-Ahora puedes usar ese Secret para tener Nginx funcionando con HTTPS, y para eso necesitas usar el campo `spec.tls` en el archivo YAML del Pod:
-=======
-Ahora puedes utilizar este Secreto para ejecutar Nginx con HTTPS, y para ello necesitas utilizar el campo `spec.tls` en el archivo YAML del Pod:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
+Ahora puedes utilizar este Secret para ejecutar Nginx con HTTPS, y para ello necesitas utilizar el campo `spec.tls` en el archivo YAML del Pod:
 
 ```yaml
 apiVersion: v1
@@ -675,25 +511,6 @@ spec:
 
 &nbsp;
 
-<<<<<<< HEAD
-Aquí tenemos bastante información nueva, así que vamos por partes.
-
-La primera cosa de la que tenemos que hablar es sobre el `spec.containers`, principalmente sobre los volúmenes, que es el campo `spec.containers.volumeMounts`.
-
-El campo `spec.containers.volumeMounts` se utiliza para montar un volumen en un directorio dentro del contenedor. En nuestro caso, estamos montando dos volúmenes, uno para el archivo de configuración de Nginx, y otro para el certificado TLS y la clave privada.
-
-Y usamos el campo `spec.volumes` para definir los volúmenes que serán utilizados por el Pod, y estamos definiendo dos volúmenes, el `nginx-config-volume` y el `nginx-tls`.
-
-El volumen `nginx-config-volume` es un volumen del tipo `configMap`, y se utiliza para montar el archivo de configuración de Nginx, que está almacenado en el ConfigMap `nginx-config`. El próximo tema es sobre ConfigMaps, así que no te preocupes por eso ahora.
-
-El volumen `nginx-tls` es un volumen del tipo `secret`, y se utiliza para montar el Secret `meu-servico-web-tls-secret`, que contiene el certificado TLS y la clave privada que se utilizarán para configurar HTTPS en Nginx.
-
-Y como estamos configurando un Nginx para usar nuestro Secret, necesitamos hablar de dónde queremos que los archivos del Secret se monten, y para eso usamos el campo `spec.containers.volumeMounts.path` para definir el directorio donde queremos que se monten los archivos del Secret, que en este caso es el directorio `/etc/nginx/tls`.
-
-Dije que el volumen `nginx-config-volume`, es un volumen del tipo `configMap`, eso es una gran introducción para iniciar el próximo tema, que es sobre ConfigMaps! :D
-
-Así que, continuemos con nuestro ejemplo de cómo usar Nginx con HTTPS, pero en el próximo tema sobre ConfigMaps. \o/
-=======
 Aquí tenemos mucha información nueva, así que vamos por partes.
 
 Lo primero de lo que debemos hablar es sobre `spec.containers`, en particular sobre los volúmenes, que es el campo `spec.containers.volumeMounts`.
@@ -711,13 +528,11 @@ Y como estamos configurando un Nginx para utilizar nuestro Secret, debemos indic
 Mencioné que el volumen `nginx-config-volume` es un volumen de tipo `configMap`, lo que es una excelente introducción para el próximo tema, que trata sobre ConfigMaps. :D
 
 Por lo tanto, continuaremos con nuestro ejemplo de cómo utilizar Nginx con HTTPS en el próximo tema sobre ConfigMaps. ¡Vamos allá! \o/
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 #### ConfigMaps
 
 Los ConfigMaps se utilizan para almacenar datos de configuración, como variables de entorno, archivos de configuración, etc. Son muy útiles para almacenar datos de configuración que pueden ser utilizados por varios Pods.
 
-<<<<<<< HEAD
 Los ConfigMaps son una forma eficiente de desacoplar los parámetros de configuración de las imágenes de contenedores. Esto permite que tengas la misma imagen de contenedor en diferentes entornos, como desarrollo, prueba y producción, con diferentes configuraciones.
 
 Aquí hay algunos puntos importantes sobre el uso de ConfigMaps en Kubernetes:
@@ -750,40 +565,6 @@ http { # configuración del protocolo HTTP, que es el protocolo que Nginx va a u
     location / { # configuración de la ruta /
       return 200 '¡Bienvenido a Nginx!\n'; # devuelve el código 200 y el mensaje ¡Bienvenido a Nginx!
       add_header Content-Type text/plain; # añade el header Content-Type con el valor text/plain
-=======
-Los ConfigMaps son una forma eficiente de desacoplar los parámetros de configuración de las imágenes de contenedor. Esto permite tener la misma imagen de contenedor en diferentes entornos, como desarrollo, prueba y producción, con diferentes configuraciones.
-
-Aquí hay algunos puntos importantes sobre el uso de ConfigMaps en Kubernetes:
-
-- Actualizaciones: Los ConfigMaps no se actualizan automáticamente en los Pods que los utilizan. Si actualizas un ConfigMap, los Pods existentes no recibirán la nueva configuración. Para que un Pod reciba la nueva configuración, debes recrear el Pod.
-
-- Múltiples ConfigMaps: Es posible usar múltiples ConfigMaps para un solo Pod. Esto es útil cuando tienes diferentes aspectos de la configuración que deseas mantener separados.
-
-- Variables de entorno: Además de montar el ConfigMap en un volumen, también es posible utilizar el ConfigMap para definir variables de entorno para los contenedores en el Pod.
-
-- Inmutabilidad: A partir de la versión 1.19 de Kubernetes, es posible hacer que los ConfigMaps (y Secrets) sean inmutables, lo que puede mejorar el rendimiento de tu clúster si tienes muchos ConfigMaps o Secrets.
-
-Como en el ejemplo del capítulo anterior, donde creamos un Pod con Nginx y utilizamos un ConfigMap para almacenar el archivo de configuración de Nginx, el `ConfigMap` se utiliza para almacenar el archivo de configuración de Nginx en lugar de almacenar el archivo de configuración dentro del Pod, lo que resulta en un Pod más limpio y fácil de mantener. Y, por supuesto, siempre es bueno utilizar las cosas para lo que fueron diseñadas, y el ConfigMap fue diseñado para almacenar datos de configuración.
-
-Sigamos con nuestro ejemplo de cómo utilizar Nginx con HTTPS, pero esta vez utilizando un ConfigMap para almacenar el archivo de configuración de Nginx.
-
-Creemos el archivo de configuración de Nginx llamado `nginx.conf`, que será utilizado por el ConfigMap:
-
-```bash
-events { } # Configuración de eventos
-
-http { # Configuración del protocolo HTTP, que es el protocolo que utilizará Nginx
-  server { # Configuración del servidor
-    listen 80; # Puerto en el que Nginx escuchará
-    listen 443 ssl; # Puerto en el que Nginx escuchará para HTTPS y se pasa el parámetro ssl para habilitar HTTPS
-
-    ssl_certificate /etc/nginx/tls/certificado.crt; # Ruta del certificado TLS
-    ssl_certificate_key /etc/nginx/tls/clave-privada.key; # Ruta de la clave privada
-
-    location / { # Configuración de la ruta /
-      return 200 '¡Bienvenido a Nginx!\n'; # Retorna el código 200 y el mensaje ¡Bienvenido a Nginx!
-      add_header Content-Type text/plain; # Agrega el encabezado Content-Type con el valor text/plain
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
     } 
   }
 }
@@ -791,7 +572,6 @@ http { # Configuración del protocolo HTTP, que es el protocolo que utilizará N
 
 &nbsp;
 
-<<<<<<< HEAD
 He dejado el contenido del archivo anterior con comentarios para facilitar la comprensión.
 
 Lo que el archivo anterior está haciendo es:
@@ -801,17 +581,6 @@ Lo que el archivo anterior está haciendo es:
 - Configurando la ruta `/` para devolver el código 200 y el mensaje `¡Bienvenido a Nginx!` con el header `Content-Type` con el valor `text/plain`.
 
 Ahora vamos a crear el ConfigMap `nginx-config` con el archivo de configuración de Nginx:
-=======
-Dejé el contenido del archivo anterior con comentarios para facilitar la comprensión.
-
-Lo que hace el archivo anterior es:
-
-- Configurar Nginx para escuchar en los puertos 80 y 443, donde el puerto 443 se utiliza para HTTPS.
-- Configurar Nginx para utilizar el certificado TLS y la clave privada que se encuentran en el directorio `/etc/nginx/tls`.
-- Configurar la ruta `/` para devolver el código de estado 200 y el mensaje `¡Bienvenido a Nginx!` con el encabezado `Content-Type` con el valor `text/plain`.
-
-Ahora crearemos el ConfigMap `nginx-config` con el archivo de configuración de Nginx:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl create configmap nginx-config --from-file=nginx.conf
@@ -819,17 +588,10 @@ kubectl create configmap nginx-config --from-file=nginx.conf
 
 &nbsp;
 
-<<<<<<< HEAD
 Muy sencillo, ¿verdad? :)
 
 Lo que estamos haciendo es crear un ConfigMap llamado `nginx-config` con el contenido del archivo `nginx.conf`.
 Podemos hacer lo mismo a través de un manifiesto, como en el ejemplo a continuación:
-=======
-¡Es bastante simple, ¿verdad? :)
-
-Lo que estamos haciendo es crear un ConfigMap llamado `nginx-config` con el contenido del archivo `nginx.conf`.
-Podemos hacer lo mismo a través de un manifiesto, como se muestra en el siguiente ejemplo:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: v1
@@ -849,11 +611,7 @@ data:
         ssl_certificate_key /etc/nginx/tls/clave-privada.key;
 
         location / {
-<<<<<<< HEAD
           return 200 '¡Bienvenido a Nginx!\n';
-=======
-          return 200 'Bienvenido a Nginx!\n';
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
           add_header Content-Type text/plain;
         }
       }
@@ -862,21 +620,12 @@ data:
 
 &nbsp;
 
-<<<<<<< HEAD
 El archivo es muy similar a los manifiestos de `Secret`, pero con algunas diferencias:
 
 - El campo `kind` es `ConfigMap` en lugar de `Secret`.
 - El campo `data` se utiliza para definir el contenido del ConfigMap, y el campo `data` es un mapa de clave-valor, donde la clave es el nombre del archivo y el valor es el contenido del archivo. Usamos el carácter `|` para definir el valor del campo `data` como un bloque de texto, y así podemos definir el contenido del archivo `nginx.conf` sin la necesidad de usar el carácter `\n` para romper las líneas del archivo.
 
 Ahora solo queda aplicar el manifiesto anterior:
-=======
-El archivo se parece mucho a los manifiestos de `Secret`, pero con algunas diferencias:
-
-- El campo `kind` es `ConfigMap` en lugar de `Secret`.
-- El campo `data` se utiliza para definir el contenido del ConfigMap, y el campo `data` es un mapa de clave-valor, donde la clave es el nombre del archivo y el valor es el contenido del archivo. Utilizamos el carácter `|` para definir el valor del campo `data` como un bloque de texto, de esta manera podemos definir el contenido del archivo `nginx.conf` sin necesidad de utilizar el carácter `\n` para separar las líneas del archivo.
-
-Ahora solo tienes que aplicar el manifiesto anterior:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl apply -f nginx-config.yaml
@@ -884,11 +633,7 @@ kubectl apply -f nginx-config.yaml
 
 &nbsp;
 
-<<<<<<< HEAD
 Para ver el contenido del ConfigMap que creamos, basta con ejecutar el comando:
-=======
-Para ver el contenido del ConfigMap que creamos, simplemente ejecuta el comando:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl get configmap nginx-config -o yaml
@@ -898,11 +643,7 @@ kubectl get configmap nginx-config -o yaml
 
 También puedes usar el comando `kubectl describe configmap nginx-config` para ver el contenido del ConfigMap, pero el comando `kubectl get configmap nginx-config -o yaml` es mucho más completo.
 
-<<<<<<< HEAD
-Ahora que ya tenemos nuestro `ConfigMap` creado, vamos a aplicar el manifiesto que creamos en el capítulo anterior, voy a pegar aquí el manifiesto para facilitar:
-=======
 Ahora que ya tenemos nuestro `ConfigMap` creado, vamos a aplicar el manifiesto que creamos en el capítulo anterior. Lo copiaré aquí para facilitar:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: v1
@@ -919,7 +660,6 @@ spec:
     - containerPort: 80
     - containerPort: 443
     volumeMounts:
-<<<<<<< HEAD
     - name: nginx-config-volume # nombre del volumen que vamos a usar para montar el archivo de configuración de Nginx
       mountPath: /etc/nginx/nginx.conf # ruta donde se montará el archivo de configuración de Nginx
       subPath: nginx.conf # nombre del archivo de configuración de Nginx
@@ -942,28 +682,6 @@ spec:
 &nbsp;
 
 Ahora solo queda aplicar el manifiesto anterior:
-=======
-    - name: nginx-config-volume # Nombre del volumen que utilizaremos para montar el archivo de configuración de Nginx
-      mountPath: /etc/nginx/nginx.conf # Ruta donde se montará el archivo de configuración de Nginx
-      subPath: nginx.conf # Nombre del archivo de configuración de Nginx
-    - name: nginx-tls # Nombre del volumen que utilizaremos para montar el certificado TLS y la clave privada
-      mountPath: /etc/nginx/tls # Ruta donde se montará el certificado TLS y la clave privada
-  volumes: # Lista de volúmenes que utilizaremos en el Pod
-  - name: nginx-config-volume # Nombre del volumen que utilizaremos para montar el archivo de configuración de Nginx
-    configMap: # Tipo de volumen que utilizaremos
-      name: nginx-config # Nombre del ConfigMap que utilizaremos
-  - name: nginx-tls # Nombre del volumen que utilizaremos para montar el certificado TLS y la clave privada
-    secret: # Tipo de volumen que utilizaremos
-      secretName: mi-servicio-web-tls-secret # Nombre del Secret que utilizaremos
-      items: # Lista de archivos que montaremos, ya que dentro del secret hay dos archivos, el certificado TLS y la clave privada
-        - key: tls.crt # Nombre del archivo que montaremos, nombre que está en el campo `data` del Secret
-          path: certificado.crt # Nombre del archivo que se montará, nombre que se utilizará en el campo `ssl_certificate` del archivo de configuración de Nginx
-        - key: tls.key # Nombre del archivo que montaremos, nombre que está en el campo `data` del Secret
-          path: clave-privada.key # Nombre del archivo que se montará, nombre que se utilizará en el campo `ssl_certificate_key` del archivo de configuración de Nginx
-```
-
-Ahora solo tienes que aplicar el manifiesto anterior:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 kubectl apply -f nginx.yaml
@@ -1003,54 +721,31 @@ kubectl port-forward service/nginx 4443:443
 
 &nbsp;
 
-<<<<<<< HEAD
-El comando anterior hará el `port-forward` del puerto 443 del Service `nginx` al puerto 4443 de tu computador, ¡el `port-forward` salvando nuestra vida una vez más! :)
-
-Vamos a usar `curl` para probar si nuestro Nginx está funcionando:
-=======
 El comando anterior realizará el `port-forward` del puerto 443 del Service `nginx` al puerto 4443 de tu computadora, ¡el `port-forward` nos está salvando nuevamente! :)
 
 Utilizaremos `curl` para comprobar si nuestro Nginx está funcionando:"
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 curl -k https://localhost:4443
 
-<<<<<<< HEAD
 ¡Bienvenido a Nginx!
-=======
-Bienvenido a Nginx!
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 ```
 
 &nbsp;
 
-<<<<<<< HEAD
-¡Funcionando perfectamente!
-Recuerda que este es un ejemplo muy simple, el objetivo aquí es mostrar cómo usar el ConfigMap y el Secret para montar archivos dentro de un Pod. El certificado TLS y la clave privada que usamos aquí son auto-firmados, y no se recomiendan para uso en producción y no son aceptados por los navegadores, pero para probar está genial.
-
-Creo que ya es posible entender cómo funciona el ConfigMap, y recuerda que es posible usar el ConfigMap para montar archivos, pero también es posible usar el ConfigMap para definir variables de entorno, y eso es muy útil cuando necesitas pasar una configuración a un contenedor a través de una variable de entorno.
-
-En caso de que quieras hacer un ConfigMap inmutable, puedes usar el campo `immutable` en el manifiesto del ConfigMap, como en el ejemplo a continuación:
-=======
 ¡Funciona maravillosamente!
 Recuerda que este es un ejemplo muy simple; el objetivo aquí es mostrar cómo usar ConfigMap y Secret para montar archivos dentro de un Pod. El certificado TLS y la clave privada que usamos aquí son auto-firmados y no se recomiendan para su uso en producción, ni son aceptados por los navegadores, pero son adecuados para pruebas.
 
 Creo que ya has comprendido cómo funciona ConfigMap, y recuerda que puedes usar ConfigMap no solo para montar archivos, sino también para definir variables de entorno, lo cual es muy útil cuando necesitas pasar una configuración a un contenedor a través de una variable de entorno.
 
 Si deseas hacer que un ConfigMap sea inmutable, puedes utilizar el campo `immutable` en el manifiesto del ConfigMap, como se muestra en el siguiente ejemplo:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: nginx-config
-<<<<<<< HEAD
   immutable: true # Convierte el ConfigMap en inmutable
-=======
-  immutable: true # convierte el ConfigMap en inmutable
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 data:
   nginx.conf: |
     events { }
@@ -1064,11 +759,7 @@ data:
         ssl_certificate_key /etc/nginx/tls/clave-privada.key;
 
         location / {
-<<<<<<< HEAD
           return 200 '¡Bienvenido a Nginx!\n';
-=======
-          return 200 'Bienvenido a Nginx!\n';
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
           add_header Content-Type text/plain;
         }
       }
@@ -1077,26 +768,16 @@ data:
 
 &nbsp;
 
-<<<<<<< HEAD
-Con esto, no será posible alterar el ConfigMap, y si intentas alterar el ConfigMap, Kubernetes devolverá un error.
-
-En caso de que quieras colocar el ConfigMap en un namespace específico, puedes usar el campo `namespace` en el manifiesto del ConfigMap, como en el ejemplo a continuación:
-=======
 Con esto, no será posible cambiar el ConfigMap, y si intentas modificarlo, Kubernetes devolverá un error.
 
 Si deseas colocar el ConfigMap en un espacio de nombres específico, puedes utilizar el campo `namespace` en el manifiesto del ConfigMap, como se muestra en el siguiente ejemplo:"
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: v1
 kind: ConfigMap
 metadata:
   name: nginx-config
-<<<<<<< HEAD
-  namespace: mi-namespace # deja el ConfigMap en el namespace `mi-namespace`
-=======
   namespace: mi-namespace # coloca el ConfigMap en el espacio de nombres mi-namespace
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 data:
   nginx.conf: |
     events { }
@@ -1110,11 +791,7 @@ data:
         ssl_certificate_key /etc/nginx/tls/clave-privada.key;
 
         location / {
-<<<<<<< HEAD
           return 200 '¡Bienvenido a Nginx!\n';
-=======
-          return 200 'Bienvenido a Nginx!\n';
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
           add_header Content-Type text/plain;
         }
       }
@@ -1123,35 +800,6 @@ data:
 
 &nbsp;
 
-<<<<<<< HEAD
-En fin, creo que ya hemos visto bastante sobre ConfigMap, creo que ya podemos pasar al siguiente tema, ¿verdad? \o/
-
-&nbsp;
-
-#### External Secret Operator
-
-External Secrets Operator es un maestro de los secretos de Kubernetes, capaz de trabajar en perfecta armonía con una amplia variedad de sistemas de gestión de secretos externos. Esto incluye, pero no se limita a, gigantes como AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault e IBM Cloud Secrets Manager.
-
-El papel del ESO es buscar información de esas APIs externas y traerla al escenario de Kubernetes, transformándola en Kubernetes Secrets listos para su uso.
-
-##### El Papel Destacado del ESO
-
-La gran misión del ESO es sincronizar secretos de APIs externas con el entorno de Kubernetes. Para ello, utiliza tres recursos de API personalizados: ExternalSecret, SecretStore y ClusterSecretStore. Estos recursos crean un puente entre Kubernetes y las APIs externas, permitiendo que los secretos sean gestionados y utilizados de manera amigable y eficiente.
-
-Para simplificar, nuestro ESO es el encargado de llevar los Secrets de Kubernetes a un nuevo nivel, permitiéndote utilizar herramientas especializadas en la gestión de secretos, como Hashicorp Vault, por ejemplo, y que ya conoces.
-
-##### Conceptos Clave del External Secrets Operator
-
-Vamos a explorar algunos conceptos fundamentales para nuestro trabajo con el External Secrets Operator (ESO).
-
-##### SecretStore
-
-El SecretStore es un recurso que separa las preocupaciones de autenticación/acceso y los secretos y configuraciones necesarios para las cargas de trabajo. Este recurso está basado en namespaces.
-
-Imagina el SecretStore como un gestor de secretos que conoce la forma de acceder a los datos. Contiene referencias a secretos que mantienen las credenciales para acceder a la API externa.
-
-Aquí hay un ejemplo simplificado de cómo se define el SecretStore:
-=======
 En resumen, creo que hemos cubierto bastante sobre ConfigMap. ¿Estás listo para pasar al próximo tema? ¡Vamos adelante! \o/
 
 &nbsp;
@@ -1179,7 +827,6 @@ SecretStore es un recurso que separa las preocupaciones de autenticación/acceso
 Imagina SecretStore como un administrador de secretos que conoce la forma de acceder a los datos. Contiene referencias a secretos que almacenan las credenciales para acceder a la API externa.
 
 Aquí tienes un ejemplo simplificado de cómo se define SecretStore:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: external-secrets.io/v1beta1
@@ -1205,15 +852,9 @@ spec:
 
 Un ExternalSecret declara qué datos buscar y tiene una referencia al SecretStore, que sabe cómo acceder a esos datos. El controlador utiliza este ExternalSecret como un plan para crear secretos.
 
-<<<<<<< HEAD
 Piensa en un ExternalSecret como una solicitud hecha al gestor de secretos (SecretStore) para buscar un secreto específico. La configuración del ExternalSecret define qué buscar, dónde buscar y cómo formatear el secreto.
 
 Aquí hay un ejemplo simplificado de cómo se define el ExternalSecret:
-=======
-Imagina un ExternalSecret como una solicitud al administrador de secretos (SecretStore) para recuperar un secreto específico. La configuración del ExternalSecret define qué buscar, dónde buscarlo y cómo formatear el secreto.
-
-Aquí tienes un ejemplo simplificado de cómo se define un ExternalSecret:
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```yaml
 apiVersion: external-secrets.io/v1beta1
@@ -1241,7 +882,6 @@ spec:
 
 ##### ClusterSecretStore
 
-<<<<<<< HEAD
 El ClusterSecretStore es un SecretStore global, que puede ser referenciado por todos los namespaces. Puedes usarlo para proporcionar una puerta de acceso central a tu proveedor de secretos. Es como un SecretStore, pero con alcance en todo el cluster, en lugar de solo un namespace.
 
 ##### Control de Acceso y Seguridad
@@ -1270,36 +910,6 @@ Con Vault, puedes centralizar la gestión de secretos, reduciendo la superficie
 ##### Comandos Básicos de Vault
 
 Vault puede ser un poco complejo para los principiantes, pero si ya has trabajado con él, los comandos básicos son relativamente simples.
-=======
-El ClusterSecretStore es un SecretStore global que puede ser referenciado desde todos los namespaces. Puedes usarlo como una puerta de enlace central para tu proveedor de secretos. Es similar a un SecretStore, pero con alcance en todo el clúster en lugar de estar limitado a un solo namespace.
-
-##### Control de Acceso y Seguridad
-
-ESO es un operador potente con un alto nivel de acceso. Crea, lee y actualiza secretos en todos los namespaces y tiene acceso a secretos almacenados en algunas APIs externas. Por lo tanto, es crucial garantizar que ESO tenga solo los privilegios mínimos necesarios y que SecretStore/ClusterSecretStore estén diseñados con cuidado.
-
-Además, considera el uso de un sistema de control de admisión de Kubernetes (como OPA o Kyverno) para un control de acceso más refinado.
-
-Ahora que tenemos una comprensión sólida de los conceptos clave, continuemos con la instalación de ESO en Kubernetes.
-
-#### Configurando el External Secrets Operator
-
-Echemos un vistazo a cómo instalar y configurar el External Secrets Operator en Kubernetes.
-En este ejemplo, utilizaremos ESO para que Kubernetes pueda acceder a los secretos en un clúster Vault.
-
-Antes de comenzar, comprendamos qué es Vault, en caso de que aún no lo conozcas.
-
-##### ¿Qué es Vault?
-
-HashiCorp Vault es una herramienta para administrar secretos de manera segura. Le permite almacenar y controlar el acceso a tokens, contraseñas, certificados, claves de cifrado y otra información confidencial. En nuestro contexto, Vault se convierte en una poderosa solución para abordar los problemas inherentes a la forma en que Kubernetes maneja los Secrets.
-
-##### ¿Por qué usar Vault?
-
-Con Vault, puedes centralizar la gestión de secretos, reduciendo la superficie de ataque y minimizando el riesgo de fugas de datos. Vault también ofrece un control detallado de las políticas de acceso, lo que permite determinar quién puede acceder a qué, cuándo y dónde.
-
-##### Comandos Básicos de Vault
-
-Vault puede ser un poco complejo para los principiantes, pero si ya has trabajado con él, los comandos básicos son relativamente sencillos.
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 **Instalando el Hashicorp Vault**
 
@@ -1311,49 +921,29 @@ echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://
 sudo apt update && sudo apt install vault
 ```
 
-<<<<<<< HEAD
-**Iniciando Vault en Modo Dev**
-=======
 **Iniciando el Vault en Modo Dev**
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 vault server -dev
 ```
 
-<<<<<<< HEAD
 Este comando inicia Vault en modo de desarrollo, que es útil para fines de aprendizaje y experimentación.
 
 **Configurando el Ambiente**
-=======
-El comando inicia Vault en modo de desarrollo, lo cual es útil para propósitos de aprendizaje y experimentación.
-
-**Configurando el Entorno**
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 export VAULT_ADDR='http://127.0.0.1:8200'
 ```
 
-<<<<<<< HEAD
 Esto establece la variable de entorno `VAULT_ADDR`, apuntando hacia la dirección del servidor Vault.
 
 **Escribiendo Secrets**
-=======
-Esto configura la variable de entorno `VAULT_ADDR`, apuntando hacia la dirección del servidor de Vault.
-
-**Escribiendo los Secrets**
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 ```bash
 vault kv put secret/my-secret password=my-password
 ```
 
-<<<<<<< HEAD
 Este comando escribe un secreto llamado `my-secret` con la contraseña `my-password`.
-=======
-Este comando escribe un secreto llamado "my-secret" con la contraseña "my-password".
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 **Leyendo Secrets**
 
@@ -1361,7 +951,6 @@ Este comando escribe un secreto llamado "my-secret" con la contraseña "my-passw
 vault kv get secret/my-secret
 ```
 
-<<<<<<< HEAD
 Este comando lee el secreto llamado `my-secret`.
 
 ##### El Vault en el Contexto de Kubernetes
@@ -1373,38 +962,17 @@ Ahora que ha recordado lo básico de Vault, el siguiente paso es comprender cóm
 Ahora, vamos a sumergirnos en la parte práctica. Configuraremos Vault en Kubernetes, paso a paso, utilizando Helm. Al final de este proceso, tendremos Vault instalado, configurado y listo para usar.
 
 ##### Requisitos Previos
-=======
-Este comando lee el secreto llamado "my-secret".
-
-##### El Vault en el contexto de Kubernetes
-
-Ahora que ha repasado los conceptos básicos de Vault, el siguiente paso es comprender cómo puede trabajar en conjunto con Kubernetes y ESO para mejorar la gestión de secretos.
-
-##### Instalación y configuración de Vault en Kubernetes
-
-Ahora profundizaremos en la parte práctica. Configuraremos Vault en Kubernetes paso a paso utilizando Helm. Al final de este proceso, tendremos Vault instalado, configurado y listo para su uso.
-
-##### Requisitos previos
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 Antes de comenzar, asegúrese de tener lo siguiente:
 
 1. Una instancia de Kubernetes en funcionamiento.
 2. Helm instalado en su máquina local o en su clúster.
 
-<<<<<<< HEAD
 ##### Instalando y Configurando Vault con Helm
 
 Aquí están los pasos para instalar y configurar Vault utilizando Helm:
 
-**1. Agregue el repositorio de HashiCorp a Helm**
-=======
-##### Instalación y configuración de Vault con Helm
-
-Aquí están los pasos para instalar y configurar Vault utilizando Helm:
-
-**1. Agregue el repositorio HashiCorp a Helm.**
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
+**1. Agregue el repositorio de HashiCorp a Helm.**
 
 ```bash
 helm repo add hashicorp https://helm.releases.hashicorp.com
@@ -1651,4 +1219,4 @@ Finalmente, combinamos ConfigMaps y Secrets para configurar un Pod de Nginx para
 
 Esta combinación de ConfigMaps y Secrets nos permite gestionar eficientemente nuestras configuraciones y datos sensibles de manera segura, al tiempo que nos brinda un alto grado de flexibilidad y control sobre nuestras aplicaciones.
 
-¡Y eso es todo por hoy! Nos vemos en el próximo día. ¡Hasta entonces! 👋✌️
\ No newline at end of file
+¡Y eso es todo por hoy! Nos vemos en el próximo día. ¡Hasta entonces! &nbsp; :wave: &nbsp; :v:
diff --git a/es/day-9/README.md b/es/day-9/README.md
index e97166de..0091fdd6 100644
--- a/es/day-9/README.md
+++ b/es/day-9/README.md
@@ -5,7 +5,7 @@
 
 ### ¿Qué veremos hoy?
 
-Durante el día de hoy,
+"Si estás aquí, es probable que ya tengas una idea de lo que hace Kubernetes. Pero, ¿cómo exponer tus servicios de manera eficiente y segura al mundo exterior? Aquí es donde entra en juego nuestro protagonista del día: el Ingress. En esta sección, desvelaremos qué es el Ingress, para qué sirve y cómo se diferencia de otras formas de exponer aplicaciones en Kubernetes.
 
 &nbsp;
 
@@ -15,26 +15,328 @@ Durante el día de hoy,
 
 &nbsp;
 
-### ¿Por qué?
+# ¿Qué es Ingress?
 
-&nbsp;
+## ¿Qué es Ingress?
 
-&nbsp;
+Ingress es un recurso de Kubernetes que gestiona el acceso externo a los servicios dentro de un clúster. Funciona como una capa de enrutamiento HTTP/HTTPS, permitiendo la definición de reglas para dirigir el tráfico externo a diferentes servicios backend. Ingress se implementa a través de un controlador de Ingress, que puede ser alimentado por varias soluciones, como NGINX, Traefik o Istio, por mencionar algunas.
 
-### Tu tarea
+Técnicamente, Ingress actúa como una abstracción de reglas de enrutamiento de alto nivel que son interpretadas y aplicadas por el controlador de Ingress. Permite características avanzadas como el equilibrio de carga, SSL/TLS, redirección, reescritura de URL, entre otras.
 
-Tu tarea es
+Principales Componentes y Funcionalidades:
+Controlador de Ingress: Es la implementación real que satisface un recurso Ingress. Puede implementarse mediante varias soluciones de proxy inverso, como NGINX o HAProxy.
 
-&nbsp;
+**Reglas de Enrutamiento:** Definidas en un objeto YAML, estas reglas determinan cómo deben dirigirse las solicitudes externas a los servicios internos.
 
-## Desafío del Día 9
+**Backend Predeterminado:** Un servicio de respaldo al que se dirigen las solicitudes si no se cumple ninguna regla de enrutamiento.
 
-No te olvides
+**Balanceo de Carga:** Distribución automática del tráfico entre múltiples pods de un servicio.
 
-&nbsp;
+**Terminación SSL/TLS:** Ingress permite la configuración de certificados SSL/TLS para la terminación de la encriptación en el punto de entrada del clúster.
 
-## Final del Día 9
+**Adjuntos de Recursos:** Posibilidad de adjuntar recursos adicionales como ConfigMaps o Secrets, que pueden utilizarse para configurar comportamientos adicionales como la autenticación básica, listas de control de acceso, etc."
 
-Durante el Día 9, has aprendido
+# Componentes de Ingress
 
-&nbsp;
+Ahora que ya sabemos qué es Ingress y por qué utilizarlo, es hora de sumergirnos en los componentes que lo componen. Como buen "portero" de nuestro clúster Kubernetes, Ingress no trabaja solo; está compuesto por varias "piezas" que orquestan el tráfico. ¡Vamos a explorarlas!
+
+## Componentes Clave
+
+### Controlador de Ingress
+
+El Controlador de Ingress es el motor detrás del objeto Ingress. Es responsable de aplicar las reglas de enrutamiento definidas en el recurso Ingress. Ejemplos populares incluyen el Controlador de Ingress de Nginx, Traefik y HAProxy Ingress.
+
+### Recursos de Ingress
+
+Los Recursos de Ingress son las configuraciones que defines para indicar al Controlador de Ingress cómo debe ser enrutado el tráfico. Estas se definen en archivos YAML y se aplican en el clúster.
+
+### Anotaciones y Personalizaciones
+
+Las anotaciones permiten personalizar el comportamiento predeterminado de tu Ingress. Por ejemplo, puedes forzar la redirección de HTTP a HTTPS o agregar políticas de seguridad, como protección contra ataques DDoS.
+
+### Instalación del Nginx Ingress Controller
+
+Vamos a instalar el Nginx Ingress Controller. Es importante tener en cuenta la versión del Ingress Controller que estás instalando, ya que las versiones más recientes o más antiguas pueden no ser compatibles con la versión de Kubernetes que estás utilizando. Para este tutorial, utilizaremos la versión 1.8.2.
+En tu terminal, ejecuta los siguientes comandos:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
+```
+
+Verifica si el Ingress Controller se ha instalado correctamente:
+
+```bash
+kubectl get pods -n ingress-nginx
+```
+
+Puedes utilizar la opción `wait` de `kubectl`, de esta manera, cuando los pods estén listos, liberará la terminal, así:
+
+```bash
+kubectl get pods -n ingress-nginx --wait
+```
+
+```markdown
+```bash
+kubectl wait --namespace ingress-nginx \
+  --for=condition=ready pod \
+  --selector=app.kubernetes.io/component=controller \
+  --timeout=90s
+```
+
+En el comando anterior, estamos esperando que los pods del Controlador de Ingress estén listos, con la etiqueta `app.kubernetes.io/component=controller`, en el namespace `ingress-nginx`, y en caso de que no estén listos en 90 segundos, el comando fallará.
+
+#### Instalación del Controlador de Ingress Nginx en Kind
+
+Kind es una herramienta muy útil para realizar pruebas y desarrollo con Kubernetes. En esta sección actualizada, proporcionamos detalles específicos para asegurarnos de que Ingress funcione como se espera en un clúster Kind.
+
+##### Creación del Clúster con Configuraciones Especiales
+
+Al crear un clúster KinD, podemos especificar varias configuraciones que incluyen asignaciones de puertos y etiquetas para los nodos.
+
+1. Cree un archivo llamado `kind-config.yaml` con el siguiente contenido:
+
+```yaml
+kind: Cluster
+apiVersion: kind.x-k8s.io/v1alpha4
+nodes:
+- role: control-plane
+  kubeadmConfigPatches:
+  - |
+    kind: InitConfiguration
+    nodeRegistration:
+      kubeletExtraArgs:
+        node-labels: "ingress-ready=true"
+  extraPortMappings:
+  - containerPort: 80
+    hostPort: 80
+    protocol: TCP
+  - containerPort: 443
+```
+
+2. Luego, cree el clúster utilizando este archivo de configuración:
+
+```bash
+kind create cluster --config kind-config.yaml
+```
+
+##### Instalación de un Controlador de Ingress
+
+Continuaremos utilizando el Controlador de Ingress de Nginx como ejemplo, ya que es ampliamente adoptado y bien documentado.
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
+```
+
+Puede utilizar la opción `wait` de `kubectl`, de modo que cuando los pods estén listos, liberará la terminal, como se muestra a continuación:
+
+```bash
+kubectl wait --namespace ingress-nginx \
+  --for=condition=ready pod \
+  --selector=app.kubernetes.io/component=controller \
+  --timeout=90s
+```
+
+En el comando anterior, estamos esperando que los pods del Controlador de Ingress estén listos, con la etiqueta `app.kubernetes.io/component=controller`, en el espacio de nombres `ingress-nginx`, y si no están listos en 90 segundos, el comando fallará.
+
+### Instalación de Giropops-Senhas en el Cluster
+
+Para la instalación de Giropops-Senhas, utilizaremos los siguientes archivos:
+
+Archivo: app-deployment.yaml
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: giropops-senhas
+  name: giropops-senhas
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: giropops-senhas
+  template:
+    metadata:
+      labels:
+        app: giropops-senhas
+    spec:
+      containers:
+      - image: linuxtips/giropops-senhas:1.0
+        name: giropops-senhas
+        env:
+        - name: REDIS_HOST
+          value: redis-service
+        ports:
+        - containerPort: 5000
+        imagePullPolicy: Always
+```
+
+Archivo: app-service.yaml
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: giropops-senhas
+  labels:
+    app: giropops-senhas
+spec:
+  selector:
+    app: giropops-senhas
+  ports:
+    - protocol: TCP
+      port: 5000
+      targetPort: 5000
+      name: tcp-app
+  type: ClusterIP
+```
+
+Archivo: redis-deployment.yaml
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: redis
+  name: redis-deployment
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: redis
+  template:
+    metadata:
+      labels:
+        app: redis
+    spec:
+      containers:
+      - image: redis
+        name: redis
+        ports:
+          - containerPort: 6379
+        resources:
+          limits:
+            memory: "256Mi"
+            cpu: "500m"
+          requests:
+            memory: "128Mi"
+            cpu: "250m"
+```
+
+Archivo: redis-service.yaml
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: redis-service
+spec:
+  selector:
+    app: redis
+  ports:
+    - protocol: TCP
+      port: 6379
+      targetPort: 6379
+  type: ClusterIP
+```
+
+Con los archivos mencionados anteriormente, estamos creando un Deployment y un Service para Giropops-Senhas, y un Deployment y un Service para Redis.
+
+Para aplicarlos, simplemente ejecute los siguientes comandos:
+
+```bash
+kubectl apply -f app-deployment.yaml
+kubectl apply -f app-service.yaml
+kubectl apply -f redis-deployment.yaml
+kubectl apply -f redis-service.yaml
+```
+
+Para verificar si los pods están en funcionamiento, ejecute el siguiente comando:
+
+```bash
+kubectl get pods
+```
+
+Para asegurarse de que los servicios estén en funcionamiento, ejecute el siguiente comando:
+
+```bash
+kubectl get services
+```
+
+Si está utilizando Kind, puede acceder a la aplicación Giropops-Senhas localmente mediante el siguiente comando:
+
+```bash
+kubectl port-forward service/giropops-senhas 5000:5000
+```
+
+Esto es válido si está utilizando Kind. Si no lo está haciendo, necesitará obtener la dirección IP de su Ingress, lo que se explicará más adelante.
+
+Para probar la aplicación, simplemente abra su navegador web y acceda a la siguiente dirección: http://localhost:5000
+
+### Creación de un Recurso de Ingress
+
+Ahora, vamos a crear un recurso de Ingress para nuestro servicio `giropops-senhas`, que fue creado anteriormente. Cree un archivo llamado `ingress-1.yaml` con el siguiente contenido:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: giropops-senhas
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /giropops-senhas
+        pathType: Prefix
+        backend:
+          service: 
+            name: giropops-senhas
+            port:
+              number: 5000
+```
+
+Después de crear el archivo, aplíquelo con el siguiente comando:
+
+```bash
+kubectl apply -f ingress-1.yaml
+```
+
+Ahora vamos verificar si nuestro Ingress se ha creado correctamente:
+
+```bash
+kubectl get ingress
+```
+
+Para obtener más detalles, puede utilizar el comando `describe`:
+
+```bash
+kubectl describe ingress giropops-senhas
+```
+
+Tanto en la salida del comando `get` como en la salida del comando `describe`, debería ver la dirección IP de su Ingress en el campo `Address`.
+
+Puede obtener esta dirección IP con el siguiente comando:
+
+```bash
+kubectl get ingress giropops-senhas -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
+```
+
+Si está utilizando un clúster gestionado por un proveedor de servicios en la nube, como GKE, puede utilizar el siguiente comando:
+
+```bash
+kubectl get ingress giropops-senhas -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
+```
+
+Esto se debe a que cuando tienes un clúster EKS, AKS, GCP, etc., el controlador de Ingress creará un equilibrador de carga para ti, y la dirección IP del equilibrador de carga será la dirección IP de tu Ingress, así de simple.
+
+Para probarlo, puedes usar el comando curl con la dirección IP, el nombre de host o el equilibrador de carga de tu Ingress:
+
+```bash
+curl DIRECCIÓN_DEL_INGRESS/giropops-senhas
+```
+
+# TBD (Por determinar)
\ No newline at end of file

From 871716438a19a23237d3fa8d863253200b230af2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sat, 20 Jan 2024 22:11:33 +0100
Subject: [PATCH 2/8] Update Spanish translation Fixes #196

---
 es/day-11/README.md | 354 ++++++++++++++++++++++----------------------
 1 file changed, 176 insertions(+), 178 deletions(-)

diff --git a/es/day-11/README.md b/es/day-11/README.md
index c8d0085b..4c2aea09 100644
--- a/es/day-11/README.md
+++ b/es/day-11/README.md
@@ -1,197 +1,194 @@
-# Descomplicando o Kubernetes
-## DAY-11
+# Simplificando Kubernetes
+
+## Día 11
 
 &nbsp;
 
-## Conteúdo do Day-11
-
-- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes)
-  - [DAY-11](#day-11)
-  - [Conteúdo do Day-11](#conteúdo-do-day-11)
-    - [Início da aula do Day-11](#início-da-aula-do-day-11)
-      - [O que iremos ver hoje?](#o-que-iremos-ver-hoje)
-      - [Introdução ao Horizontal Pod Autoscaler (HPA)](#introdução-ao-horizontal-pod-autoscaler-hpa)
-      - [Como o HPA Funciona?](#como-o-hpa-funciona)
-  - [Introdução ao Metrics Server](#introdução-ao-metrics-server)
-    - [Por que o Metrics Server é importante para o HPA?](#por-que-o-metrics-server-é-importante-para-o-hpa)
-    - [Instalando o Metrics Server](#instalando-o-metrics-server)
-      - [No Amazon EKS e na maioria dos clusters Kubernetes](#no-amazon-eks-e-na-maioria-dos-clusters-kubernetes)
-      - [No Minikube:](#no-minikube)
-      - [No KinD (Kubernetes in Docker):](#no-kind-kubernetes-in-docker)
-      - [Verificando a Instalação do Metrics Server](#verificando-a-instalação-do-metrics-server)
-      - [Obtendo Métricas](#obtendo-métricas)
-    - [Criando um HPA](#criando-um-hpa)
-    - [Exemplos Práticos com HPA](#exemplos-práticos-com-hpa)
-      - [Autoscaling com base na utilização de CPU](#autoscaling-com-base-na-utilização-de-cpu)
-      - [Autoscaling com base na utilização de Memória](#autoscaling-com-base-na-utilização-de-memória)
-      - [Configuração Avançada de HPA: Definindo Comportamento de Escalonamento](#configuração-avançada-de-hpa-definindo-comportamento-de-escalonamento)
+## Contenido del Día 11
+
+- [Simplificando Kubernetes](#simplificando-kubernetes)
+  - [Día 11](#día-11)
+  - [Contenido del Día 11](#contenido-del-día-11)
+    - [Comienzo de la lección del Día 11](#comienzo-de-la-lección-del-día-11)
+      - [¿Qué veremos hoy?](#qué-veremos-hoy)
+      - [Introducción al Escalador Automático de Pods Horizontales (HPA)](#introducción-al-escalador-automático-de-pods-horizontales-hpa)
+      - [¿Cómo funciona el HPA?](#cómo-funciona-el-hpa)
+  - [Introducción al Metrics Server](#introducción-al-metrics-server)
+    - [¿Por qué es importante el Metrics Server para el HPA?](#por-qué-es-importante-el-metrics-server-para-el-hpa)
+    - [Instalación del Metrics Server](#instalación-del-metrics-server)
+      - [En Amazon EKS y la mayoría de los clústeres Kubernetes](#en-amazon-eks-y-la-mayoría-de-los-clústeres-kubernetes)
+      - [En Minikube](#en-minikube)
+      - [En KinD (Kubernetes in Docker)](#en-kind-kubernetes-in-docker)
+      - [Verificando la Instalación del Metrics Server](#verificando-la-instalación-del-metrics-server)
+      - [Obteniendo Métricas](#obteniendo-métricas)
+    - [Creando un HPA](#creando-un-hpa)
+    - [Ejemplos Prácticos con HPA](#ejemplos-prácticos-con-hpa)
+      - [Escalado automático basado en el uso de CPU](#escalado-automático-basado-en-el-uso-de-cpu)
+      - [Escalado automático basado en el uso de Memoria](#escalado-automático-basado-en-el-uso-de-memoria)
+      - [Configuración Avanzada de HPA: Definición del Comportamiento de Escalado](#configuración-avanzada-de-hpa-definición-del-comportamiento-de-escalado)
       - [ContainerResource](#containerresource)
-      - [Detalhes do Algoritmo de Escalonamento](#detalhes-do-algoritmo-de-escalonamento)
-      - [Configurações Avançadas e Uso Prático](#configurações-avançadas-e-uso-prático)
-      - [Integrando HPA com Prometheus para Métricas Customizadas](#integrando-hpa-com-prometheus-para-métricas-customizadas)
-    - [A sua lição de casa](#a-sua-lição-de-casa)
-    - [Final do Day-11](#final-do-day-11)
-  
-&nbsp;
+      - [Detalles del Algoritmo de Escalado](#detalles-del-algoritmo-de-escalado)
+      - [Configuraciones Avanzadas y Uso Práctico](#configuraciones-avanzadas-y-uso-práctico)
+      - [Integración del HPA con Prometheus para Métricas Personalizadas](#integración-del-hpa-con-prometheus-para-métricas-personalizadas)
+    - [Tu Tarea](#tu-tarea)
+    - [Fin del Día 11](#fin-del-día-11)
 
-### Início da aula do Day-11
+&nbsp;
 
-#### O que iremos ver hoje?
+### Comienzo de la lección del Día 11
 
-Hoje é um dia particularmente fascinante! Vamos desbravar os territórios do Kubernetes, explorando a magia do Horizontal Pod Autoscaler (HPA), uma ferramenta indispensável para quem almeja uma operação eficiente e resiliente. Portanto, afivelem os cintos e preparem-se para uma jornada de descobertas. A aventura #VAIIII começar!
+#### ¿Qué veremos hoy?
 
-#### Introdução ao Horizontal Pod Autoscaler (HPA)
+¡Hoy es un día particularmente fascinante! Vamos a explorar los territorios de Kubernetes, adentrándonos en la magia del Escalador Automático de Pods Horizontales (Horizontal Pod Autoscaler - HPA, por sus siglas en inglés), una herramienta indispensable para aquellos que buscan una operación eficiente y resistente. Así que abróchense los cinturones y prepárense para un viaje de descubrimientos. ¡La aventura #VAIIII comienza!
 
-O Horizontal Pod Autoscaler, carinhosamente conhecido como HPA, é uma das joias brilhantes incrustadas no coração do Kubernetes. Com o HPA, podemos ajustar automaticamente o número de réplicas de um conjunto de pods, assegurando que nosso aplicativo tenha sempre os recursos necessários para performar eficientemente, sem desperdiçar recursos. O HPA é como um maestro que, com a batuta das métricas, rege a orquestra de pods, assegurando que a harmonia seja mantida mesmo quando a sinfonia do tráfego de rede atinge seu crescendo.
+#### Introducción al Escalador Automático de Pods Horizontales (HPA)
 
-#### Como o HPA Funciona?
+El Escalador Automático de Pods Horizontales, cariñosamente conocido como HPA, es una de las joyas brillantes incrustadas en el corazón de Kubernetes. Con el HPA, podemos ajustar automáticamente el número de réplicas de un conjunto de pods, asegurando que nuestra aplicación siempre tenga los recursos necesarios para funcionar de manera eficiente, sin desperdiciar recursos. El HPA es como un director de orquesta que, con la batuta de las métricas, dirige la orquesta de pods, asegurando que la armonía se mantenga incluso cuando la sinfonía del tráfico de red alcance su clímax.
 
-O HPA é o olheiro vigilante que monitora as métricas dos nossos pods. A cada batida do seu coração métrico, que ocorre em intervalos regulares, ele avalia se os pods estão suando a camisa para atender às demandas ou se estão relaxando mais do que deveriam. Com base nessa avaliação, ele toma a decisão sábia de convocar mais soldados para o campo de batalha ou de dispensar alguns para um merecido descanso.
+#### ¿Cómo funciona el HPA?
 
-Certamente! O Metrics Server é uma componente crucial para o funcionamento do Horizontal Pod Autoscaler (HPA), pois fornece as métricas necessárias para que o HPA tome decisões de escalonamento. Vamos entender um pouco mais sobre o Metrics Server e como instalá-lo em diferentes ambientes Kubernetes, incluindo Minikube e KinD.
+El HPA es el vigilante que monitorea las métricas de nuestros pods. En cada latido de su corazón métrico, que ocurre a intervalos regulares, evalúa si los pods están esforzándose al máximo para satisfacer las demandas o si están descansando más de lo necesario. Basándose en esta evaluación, toma la sabia decisión de convocar a más soldados al campo de batalla o de darles un merecido descanso.
 
----
+¿El servidor de métricas es importante para el funcionamiento del Escalador Automático de Pods Horizontales (HPA)? ¡Absolutamente! El servidor de métricas es un componente crucial, ya que proporciona las métricas necesarias para que el HPA tome decisiones de escalado. Ahora, profundicemos un poco más en el servidor de métricas y cómo instalarlo en diferentes entornos de Kubernetes, incluyendo Minikube y KinD.
 
-## Introdução ao Metrics Server
+## Introducción al Metrics Server
 
-Antes de começarmos a explorar o Horizontal Pod Autoscaler (HPA), é essencial termos o Metrics Server instalado em nosso cluster Kubernetes. O Metrics Server é um agregador de métricas de recursos de sistema, que coleta métricas como uso de CPU e memória dos nós e pods no cluster. Essas métricas são vitais para o funcionamento do HPA, pois são usadas para determinar quando e como escalar os recursos.
+Antes de comenzar a explorar el Escalador Automático de Pods Horizontales (HPA), es esencial tener el Metrics Server instalado en nuestro clúster Kubernetes. El Metrics Server es un agregador de métricas de recursos del sistema que recopila métricas como el uso de la CPU y la memoria de los nodos y pods en el clúster. Estas métricas son vitales para el funcionamiento del HPA, ya que se utilizan para determinar cuándo y cómo escalar los recursos.
 
-### Por que o Metrics Server é importante para o HPA?
+### ¿Por qué es importante el Metrics Server para el HPA?
 
-O HPA utiliza métricas de uso de recursos para tomar decisões inteligentes sobre o escalonamento dos pods. Por exemplo, se a utilização da CPU de um pod exceder um determinado limite, o HPA pode decidir aumentar o número de réplicas desse pod. Da mesma forma, se a utilização da CPU for muito baixa, o HPA pode decidir reduzir o número de réplicas. Para fazer isso de forma eficaz, o HPA precisa ter acesso a métricas precisas e atualizadas, que são fornecidas pelo Metrics Server.
-Portanto, precisamos antes conhecer essa peça fundamental para o dia de hoje! :D
+El HPA utiliza métricas de uso de recursos para tomar decisiones inteligentes sobre la escalabilidad de los pods. Por ejemplo, si el uso de la CPU de un pod supera cierto límite, el HPA puede decidir aumentar el número de réplicas de ese pod. Del mismo modo, si el uso de la CPU es muy bajo, el HPA puede decidir reducir el número de réplicas. Para hacer esto de manera efectiva, el HPA necesita acceder a métricas precisas y actualizadas, que son proporcionadas por el Metrics Server.
+Por lo tanto, es fundamental comprender esta pieza clave para el día de hoy. :D
 
-### Instalando o Metrics Server
+### Instalación del Metrics Server
 
-#### No Amazon EKS e na maioria dos clusters Kubernetes
+#### En Amazon EKS y la mayoría de los clústeres Kubernetes
 
-Durante a nossa aula, estou com um cluster EKS, e para instalar o Metrics Server, podemos usar o seguinte comando:
+Durante nuestra lección, estoy utilizando un clúster EKS, y para instalar el Metrics Server, podemos utilizar el siguiente comando:
 
 ```bash
 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
 ```
 
-Esse comando aplica o manifesto do Metrics Server ao seu cluster, instalando todos os componentes necessários.
+Este comando aplica el manifiesto del Metrics Server a su clúster, instalando todos los componentes necesarios.
 
-#### No Minikube:
+#### En Minikube
 
-A instalação do Metrics Server no Minikube é bastante direta. Use o seguinte comando para habilitar o Metrics Server:
+La instalación del Metrics Server en Minikube es bastante sencilla. Utilice el siguiente comando para habilitar el Metrics Server:
 
 ```bash
 minikube addons enable metrics-server
 ```
 
-Após a execução deste comando, o Metrics Server será instalado e ativado em seu cluster Minikube.
+Después de ejecutar este comando, el Metrics Server se instalará y activará en su clúster Minikube.
 
-#### No KinD (Kubernetes in Docker):
+#### En KinD (Kubernetes in Docker)
 
-Para o KinD, você pode usar o mesmo comando que usou para o EKS:
+Para KinD, puede utilizar el mismo comando que utilizó para EKS:
 
 ```bash
 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
 ```
 
-#### Verificando a Instalação do Metrics Server
+#### Verificando la Instalación del Metrics Server
 
-Após a instalação do Metrics Server, é uma boa prática verificar se ele foi instalado corretamente e está funcionando como esperado. Execute o seguinte comando para obter a lista de pods no namespace `kube-system` e verificar se o pod do Metrics Server está em execução:
+Después de instalar el Metrics Server, es una buena práctica verificar si se ha instalado correctamente y si está funcionando según lo previsto. Ejecute el siguiente comando para obtener la lista de pods en el espacio de nombres `kube-system` y verificar si el pod del Metrics Server está en ejecución:
 
 ```bash
 kubectl get pods -n kube-system | grep metrics-server
 ```
 
-#### Obtendo Métricas
+#### Obteniendo Métricas
 
-Com o Metrics Server em execução, agora você pode começar a coletar métricas de seu cluster. Aqui está um exemplo de como você pode obter métricas de uso de CPU e memória para todos os seus nodes:
+Con el Metrics Server en funcionamiento, ahora puede comenzar a recopilar métricas de su clúster. Aquí hay un ejemplo de cómo puede obtener métricas de uso de CPU y memoria para todos sus nodos:
 
 ```bash
 kubectl top nodes
 ```
 
-E para obter métricas de uso de CPU e memória para todos os seus pods:
+Y para obtener métricas de uso de CPU y memoria para todos sus pods:
 
 ```bash
 kubectl top pods
 ```
 
-Esses comandos fornecem uma visão rápida da utilização de recursos em seu cluster, o que é crucial para entender e otimizar o desempenho de seus aplicativos.
+Estos comandos proporcionan una visión rápida del uso de recursos en su clúster, lo cual es fundamental para comprender y optimizar el rendimiento de sus aplicaciones.
 
-### Criando um HPA
+### Creando un HPA
 
-Antes de nos aprofundarmos no HPA, vamos recapitular criando um deployment simples para o nosso confiável servidor Nginx.
+Antes de profundizar en el HPA, hagamos un resumen creando un despliegue simple para nuestro confiable servidor Nginx.
 
 ```yaml
-# Definição de um Deployment para o servidor Nginx
-apiVersion: apps/v1  # Versão da API que define um Deployment
-kind: Deployment     # Tipo de recurso que estamos definindo
+# Definición de un Despliegue para el servidor Nginx
+apiVersion: apps/v1  # Versión de la API que define un Despliegue
+kind: Deployment     # Tipo de recurso que estamos definiendo
 metadata:
-  name: nginx-deployment  # Nome do nosso Deployment
+  name: nginx-deployment  # Nombre de nuestro Despliegue
 spec:
   replicas: 3             # Número inicial de réplicas
   selector:
     matchLabels:
-      app: nginx         # Label que identifica os pods deste Deployment
+      app: nginx         # Etiqueta que identifica los pods de este Despliegue
   template:
     metadata:
       labels:
-        app: nginx       # Label aplicada aos pods
+        app: nginx       # Etiqueta aplicada a los pods
     spec:
       containers:
-      - name: nginx      # Nome do contêiner
-        image: nginx:latest  # Imagem do contêiner
+      - name: nginx      # Nombre del contenedor
+        image: nginx:latest  # Imagen del contenedor
         ports:
-        - containerPort: 80  # Porta exposta pelo contêiner
+        - containerPort: 80  # Puerto expuesto por el contenedor
         resources:
           limits:
-            cpu: 500m        # Limite de CPU
-            memory: 256Mi    # Limite de memória
+            cpu: 500m        # Límite de CPU
+            memory: 256Mi    # Límite de memoria
           requests:
-            cpu: 250m        # Requisição de CPU
-            memory: 128Mi    # Requisição de memória
+            cpu: 250m        # Solicitud de CPU
+            memory: 128Mi    # Solicitud de memoria
 ```
 
-Agora, com nosso deployment pronto, vamos dar o próximo passo na criação do nosso HPA.
+Ahora, con nuestro despliegue listo, demos el siguiente paso en la creación de nuestro HPA.
 
 ```yaml
-# Definição do HPA para o nginx-deployment
-apiVersion: autoscaling/v2  # Versão da API que define um HPA
-kind: HorizontalPodAutoscaler  # Tipo de recurso que estamos definindo
+# Definición del HPA para nginx-deployment
+apiVersion: autoscaling/v2  # Versión de la API que define un HPA
+kind: HorizontalPodAutoscaler  # Tipo de recurso que estamos definiendo
 metadata:
-  name: nginx-deployment-hpa  # Nome do nosso HPA
+  name: nginx-deployment-hpa  # Nombre de nuestro HPA
 spec:
   scaleTargetRef:
-    apiVersion: apps/v1        # A versão da API do recurso alvo
-    kind: Deployment           # O tipo de recurso alvo
-    name: nginx-deployment     # O nome do recurso alvo
+    apiVersion: apps/v1        # Versión de la API del recurso objetivo
+    kind: Deployment           # Tipo de recurso objetivo
+    name: nginx-deployment     # Nombre del recurso objetivo
   minReplicas: 3               # Número mínimo de réplicas
   maxReplicas: 10              # Número máximo de réplicas
   metrics:
-  - type: Resource             # Tipo de métrica (recurso do sistema)
+  - type: Resource             # Tipo de métrica (recurso del sistema)
     resource:
-      name: cpu                # Nome da métrica (CPU neste caso)
+      name: cpu                # Nombre de la métrica (CPU en este caso)
       target:
-        type: Utilization      # Tipo de alvo (utilização)
-        averageUtilization: 50 # Valor alvo (50% de utilização)
+        type: Utilization      # Tipo de destino (utilización)
+        averageUtilization: 50 # Valor objetivo (50% de utilización)
 ```
 
-Neste exemplo, criamos um HPA que monitora a utilização da CPU do nosso `nginx-deployment`. O HPA se esforçará para manter a utilização da CPU em torno de 50%, ajustando o número de réplicas entre 3 e 10 conforme necessário.
+En este ejemplo, creamos un HPA que supervisa el uso de la CPU de nuestro `nginx-deployment`. El HPA se esforzará por mantener el uso de la CPU en torno al 50%, ajustando el número de réplicas entre 3 y 10 según sea necesario.
 
-Para aplicar esta configuração ao seu cluster Kubernetes, salve o conteúdo acima em um arquivo chamado
-
- `nginx-deployment-hpa.yaml` e execute o seguinte comando:
+Para aplicar esta configuración a su clúster Kubernetes, guarde el contenido anterior en un archivo llamado `nginx-deployment-hpa.yaml` y ejecute el siguiente comando:
 
 ```bash
 kubectl apply -f nginx-deployment-hpa.yaml
 ```
 
-Agora, você tem um HPA monitorando e ajustando a escala do seu `nginx-deployment` baseado na utilização da CPU. Fantástico, não é?
+Ahora que tienes un HPA supervisando y ajustando la escala de tu `nginx-deployment` basado en el uso de la CPU. ¡Fantástico, ¿verdad?
 
-### Exemplos Práticos com HPA
+### Ejemplos Prácticos con HPA
 
-Agora que você já entende o básico sobre o HPA, é hora de rolar as mangas e entrar na prática. Vamos explorar como o HPA responde a diferentes métricas e cenários.
+Ahora que ya tienes una comprensión básica del HPA, es hora de poner manos a la obra. Exploraremos cómo el HPA responde a diferentes métricas y escenarios.
 
-#### Autoscaling com base na utilização de CPU
+#### Escalado automático basado en el uso de CPU
 
-Vamos começar com um exemplo clássico de escalonamento baseado na utilização da CPU, que já discutimos anteriormente. Para tornar a aprendizagem mais interativa, vamos simular um aumento de tráfego e observar como o HPA responde a essa mudança.
+Comencemos con un ejemplo clásico de escalado basado en el uso de la CPU, que ya discutimos anteriormente. Para que el aprendizaje sea más interactivo, simularemos un aumento de tráfico y observaremos cómo el HPA responde a este cambio.
 
 ```bash
 kubectl run -i --tty load-generator --image=busybox /bin/sh
@@ -199,83 +196,82 @@ kubectl run -i --tty load-generator --image=busybox /bin/sh
 while true; do wget -q -O- http://nginx-deployment.default.svc.cluster.local; done
 ```
 
-Este script simples cria uma carga constante no nosso deployment, fazendo requisições contínuas ao servidor Nginx. Você poderá observar como o HPA ajusta o número de réplicas para manter a utilização da CPU em torno do limite definido.
+Este sencillo script crea una carga constante en nuestro despliegue, realizando solicitudes continuas al servidor Nginx. Podrás observar cómo el HPA ajusta el número de réplicas para mantener el uso de la CPU cerca del límite definido.
 
-#### Autoscaling com base na utilização de Memória
+#### Escalado automático basado en el uso de Memoria
 
-O HPA não é apenas um mestre em lidar com a CPU, ele também tem um olho afiado para a memória. Vamos explorar como configurar o HPA para escalar baseado na utilização de memória.
+El HPA no solo es experto en el manejo de la CPU, sino que también tiene un agudo sentido para la memoria. Exploraremos cómo configurar el HPA para escalar basado en el uso de la memoria.
 
 ```yaml
-# Definição do HPA para escalonamento baseado em memória
-apiVersion: autoscaling/v2  # Versão da API que define um HPA
-kind: HorizontalPodAutoscaler    # Tipo de recurso que estamos definindo
+# Definición del HPA para escalado basado en memoria
+apiVersion: autoscaling/v2  # Versión de la API que define un HPA
+kind: HorizontalPodAutoscaler  # Tipo de recurso que estamos definiendo
 metadata:
-  name: nginx-deployment-hpa-memory  # Nome do nosso HPA
+  name: nginx-deployment-hpa-memory  # Nombre de nuestro HPA
 spec:
   scaleTargetRef:
-    apiVersion: apps/v1              # A versão da API do recurso alvo
-    kind: Deployment                 # O tipo de recurso alvo
-    name: nginx-deployment           # O nome do recurso alvo
-  minReplicas: 3                     # Número mínimo de réplicas
-  maxReplicas: 10                    # Número máximo de réplicas
+    apiVersion: apps/v1  # Versión de la API del recurso objetivo
+    kind: Deployment     # Tipo de recurso objetivo
+    name: nginx-deployment  # Nombre del recurso objetivo
+  minReplicas: 3          # Número mínimo de réplicas
+  maxReplicas: 10         # Número máximo de réplicas
   metrics:
-  - type: Resource                   # Tipo de métrica (recurso do sistema)
+  - type: Resource        # Tipo de métrica (recurso del sistema)
     resource:
-      name: memory                   # Nome da métrica (memória neste caso)
+      name: memory        # Nombre de la métrica (memoria en este caso)
       target:
-        type: Utilization            # Tipo de alvo (utilização)
-        averageUtilization: 70       # Valor alvo (70% de utilização)
+        type: Utilization  # Tipo de objetivo (utilización)
+        averageUtilization: 70  # Valor objetivo (70% de utilización)
 ```
 
-Neste exemplo, o HPA vai ajustar o número de réplicas para manter a utilização de memória em cerca de 70%. Assim, nosso deployment pode respirar livremente mesmo quando a demanda aumenta.
+En este ejemplo, el HPA ajustará el número de réplicas para mantener el uso de la memoria en alrededor del 70%. De esta manera, nuestro despliegue puede funcionar sin problemas incluso cuando la demanda aumenta.
 
-#### Configuração Avançada de HPA: Definindo Comportamento de Escalonamento
+#### Configuración Avanzada de HPA: Definición del Comportamiento de Escalado
 
-O HPA é flexível e permite que você defina como ele deve se comportar durante o escalonamento para cima e para baixo. Vamos explorar um exemplo:
+El HPA es flexible y te permite definir cómo debe comportarse durante el escalado hacia arriba y hacia abajo. Vamos a explorar un ejemplo:
 
 ```yaml
-# Definição de HPA com configurações avançadas de comportamento
-apiVersion: autoscaling/v2      # Versão da API que define um HPA
-kind: HorizontalPodAutoscaler        # Tipo de recurso que estamos definindo
+# Definición de HPA con configuración avanzada de comportamiento
+apiVersion: autoscaling/v2  # Versión de la API que define un HPA
+kind: HorizontalPodAutoscaler  # Tipo de recurso que estamos definiendo
 metadata:
-  name: nginx-deployment-hpa         # Nome do nosso HPA
+  name: nginx-deployment-hpa  # Nombre de nuestro HPA
 spec:
   scaleTargetRef:
-    apiVersion: apps/v1              # A versão da API do recurso alvo
-    kind: Deployment                 # O tipo de recurso alvo
-    name: nginx-deployment           # O nome do recurso alvo
-  minReplicas: 3                     # Número mínimo de réplicas
-  maxReplicas: 10                    # Número máximo de réplicas
+    apiVersion: apps/v1  # Versión de la API del recurso objetivo
+    kind: Deployment     # Tipo de recurso objetivo
+    name: nginx-deployment  # Nombre del recurso objetivo
+  minReplicas: 3  # Número mínimo de réplicas
+  maxReplicas: 10  # Número máximo de réplicas
   metrics:
-  - type: Resource                   # Tipo de métrica (recurso do sistema)
+  - type: Resource  # Tipo de métrica (recurso del sistema)
     resource:
-      name: cpu                      # Nome da métrica (CPU neste caso)
+      name: cpu  # Nombre de la métrica (CPU en este caso)
       target:
-        type: Utilization            # Tipo de alvo (utilização)
-        averageUtilization: 50       # Valor alvo (50% de utilização)
+        type: Utilization  # Tipo de objetivo (utilización)
+        averageUtilization: 50  # Valor objetivo (50% de utilización)
   behavior:
     scaleUp:
-      stabilizationWindowSeconds: 0  # Período de estabilização para escalonamento para cima
+      stabilizationWindowSeconds: 0  # Período de estabilización para el escalado hacia arriba
       policies:
-      - type: Percent                # Tipo de política (percentual)
-        value: 100                   # Valor da política (100%)
-        periodSeconds: 15            # Período da política (15 segundos)
+      - type: Percent  # Tipo de política (porcentaje)
+        value: 100  # Valor de la política (100%)
+        periodSeconds: 15  # Período de la política (15 segundos)
     scaleDown:
-      stabilizationWindowSeconds: 300  # Período de estabilização para escalonamento para baixo
+      stabilizationWindowSeconds: 300  # Período de estabilización para el escalado hacia abajo
       policies:
-      - type: Percent                  # Tipo de política (percentual)
-        value: 100                     # Valor da política (100%)
-        periodSeconds: 15              # Período da política (15 segundos)
+      - type: Percent  # Tipo de política (porcentaje)
+        value: 100  # Valor de la política (100%)
+        periodSeconds: 15  # Período de la política (15 segundos)
 ```
 
-Neste exemplo, especificamos um comportamento de escalonamento onde o HPA pode escalar para cima imediatamente, mas vai esperar por 5 minutos (300 segundos) após o último escalonamento para cima antes de considerar um escalonamento para baixo. Isso ajuda a evitar flutuações rápidas na contagem de réplicas, proporcionando um ambiente mais estável para nossos pods.
-
+En este ejemplo, especificamos un comportamiento de escalado en el que el HPA puede escalar hacia arriba de inmediato, pero esperará durante 5 minutos (300 segundos) después del último escalado hacia arriba antes de considerar un escalado hacia abajo. Esto ayuda a evitar fluctuaciones rápidas en el recuento de réplicas, proporcionando un entorno más estable para nuestros pods.
 
 #### ContainerResource
 
-O tipo de métrica `ContainerResource` no Kubernetes permite que você especifique métricas de recursos específicas do container para escalar. Diferente das métricas de recurso comuns que são aplicadas a todos os contêineres em um Pod, as métricas `ContainerResource` permitem especificar métricas para um contêiner específico dentro de um Pod. Isso pode ser útil em cenários onde você tem múltiplos contêineres em um Pod, mas quer escalar com base na utilização de recursos de um contêiner específico.
+El tipo de métrica `ContainerResource` en Kubernetes te permite especificar métricas de recursos específicas del contenedor para el escalado. A diferencia de las métricas de recursos comunes que se aplican a todos los contenedores en un Pod, las métricas `ContainerResource` te permiten especificar métricas para un contenedor específico dentro de un Pod. Esto puede ser útil en escenarios en los que tienes múltiples contenedores en un Pod, pero deseas escalar en función del uso de recursos de un contenedor en particular.
 
-Aqui está um exemplo de como você pode configurar um Horizontal Pod Autoscaler (HPA) usando uma métrica `ContainerResource` para escalar um Deployment com base na utilização de CPU de um contêiner específico:
+Aquí tienes un ejemplo de cómo configurar un Horizontal Pod Autoscaler (HPA) utilizando una métrica `ContainerResource` para escalar un Deployment en función del uso de CPU de un contenedor específico:
 
 ```yaml
 apiVersion: autoscaling/v2beta2
@@ -293,70 +289,72 @@ spec:
   - type: ContainerResource
     containerResource:
       name: cpu
-      container: nginx-NOME-COMPLETO-DO-CONTAINER
+      container: nginx-NOMBRE-COMPLETO-DEL-CONTENEDOR
       target:
         type: Utilization
         averageUtilization: 50
 ```
 
-No exemplo acima:
+En el ejemplo anterior:
 
-- O tipo de métrica é definido como `ContainerResource`.
-- Dentro do bloco `containerResource`, especificamos o nome da métrica (`cpu`), o nome do contêiner (`my-container`) e o alvo de utilização (`averageUtilization: 50`).
+- El tipo de métrica se define como `ContainerResource`.
+- Dentro del bloque `containerResource`, especificamos el nombre de la métrica (`cpu`), el nombre del contenedor (`mi-contenedor`) y el objetivo de utilización (`averageUtilization: 50`).
 
-Isso significa que o HPA vai ajustar o número de réplicas do Deployment `my-app` para manter a utilização média de CPU do contêiner `nginx-NOME-COMPLETO-DO-CONTAINER` em torno de 50%.
+Esto significa que el HPA ajustará el número de réplicas del Deployment `my-app` para mantener el uso promedio de CPU del contenedor `nginx-NOMBRE-COMPLETO-DEL-CONTENEDOR` en alrededor del 50%.
 
-Este tipo de configuração permite um controle mais granular sobre o comportamento de autoscaling, especialmente em ambientes onde os Pods contêm múltiplos contêineres com diferentes perfis de utilização de recursos.
+Este tipo de configuración permite un control más granular sobre el comportamiento del escalado automático, especialmente en entornos donde los Pods contienen múltiples contenedores con perfiles de uso de recursos diferentes.
 
+#### Detalles del Algoritmo de Escalado
 
-#### Detalhes do Algoritmo de Escalonamento
-
-**Cálculo do Número de Réplicas**
-O núcleo do Horizontal Pod Autoscaler (HPA) é o seu algoritmo de escalonamento, que determina o número ideal de réplicas com base nas métricas fornecidas. A fórmula básica utilizada pelo HPA para calcular o número desejado de réplicas é:
+**Cálculo del Número de Réplicas**
+El núcleo del Horizontal Pod Autoscaler (HPA) es su algoritmo de escalado, que determina el número óptimo de réplicas en función de las métricas proporcionadas. La fórmula básica utilizada por el HPA para calcular el número deseado de réplicas es:
 
 \[ \text{desiredReplicas} = \lceil \text{currentReplicas} \times \left( \frac{\text{currentMetricValue}}{\text{desiredMetricValue}} \right) \rceil \]
 
-**Exemplos com Valores Específicos:**
-1. **Exemplo de Escala para Cima:**
-   - Réplicas atuais: 2
-   - Valor atual da métrica (CPU): 80%
-   - Valor desejado da métrica (CPU): 50%
+**Ejemplos con Valores Específicos:**
+
+1. **Ejemplo de Escalado hacia Arriba:**
+   - Réplicas actuales: 2
+   - Valor actual de la métrica (CPU): 80%
+   - Valor deseado de la métrica (CPU): 50%
    - Cálculo: \(\lceil 2 \times (80\% / 50\%) \rceil = \lceil 3.2 \rceil = 4\) réplicas
 
-2. **Exemplo de Escala para Baixo:**
-   - Réplicas atuais: 5
-   - Valor atual da métrica (CPU): 30%
-   - Valor desejado da métrica (CPU): 50%
+2. **Ejemplo de Escalado hacia Abajo:**
+   - Réplicas actuales: 5
+   - Valor actual de la métrica (CPU): 30%
+   - Valor deseado de la métrica (CPU): 50%
    - Cálculo: \(\lceil 5 \times (30\% / 50\%) \rceil = \lceil 3 \rceil = 3\) réplicas
 
-**Considerações Sobre Métricas e Estado dos Pods:**
-- **Métricas de Recurso por Pod e Personalizadas:** O HPA pode ser configurado para usar métricas padrão (como CPU e memória) ou métricas personalizadas definidas pelo usuário, permitindo maior flexibilidade.
-- **Tratamento de Pods sem Métricas ou Não Prontos:** Se um Pod não tiver métricas disponíveis ou não estiver pronto, ele pode ser excluído do cálculo de média, evitando decisões de escalonamento baseadas em dados incompletos.
+**Consideraciones sobre Métricas y Estado de los Pods:**
+
+- **Métricas de Recursos por Pod y Personalizadas:** El HPA se puede configurar para utilizar métricas estándar (como CPU y memoria) o métricas personalizadas definidas por el usuario, lo que permite una mayor flexibilidad.
+- **Tratamiento de Pods sin Métricas o no Listos:** Si un Pod no tiene métricas disponibles o no está listo, puede ser excluido del cálculo promedio, evitando decisiones de escalado basadas en datos incompletos.
+
+#### Configuraciones Avanzadas y Uso Práctico
 
-#### Configurações Avançadas e Uso Prático
+**Configuración de Métricas Personalizadas y Múltiples Métricas:**
+El HPA no se limita a métricas de CPU y memoria; se puede configurar para utilizar una variedad de métricas personalizadas.
 
-**Configurando Métricas Personalizadas e Múltiplas Métricas:**
-O HPA não se limita apenas a métricas de CPU e memória; ele pode ser configurado para usar uma variedade de métricas personalizadas.
+**Uso de Métricas Personalizadas: Ejemplos y Consejos:**
 
-**Uso de Métricas Personalizadas: Exemplos e Dicas:**
-- **Exemplo:** Suponha que você tenha um serviço que deve escalar com base no número de solicitações HTTP por segundo. Você pode configurar o HPA para escalar com base nessa métrica personalizada.
-- **Dicas:** Ao usar métricas personalizadas, assegure-se de que as métricas sejam um indicador confiável da carga de trabalho e que o serviço de métricas esteja corretamente configurado e acessível pelo HPA.
+- **Ejemplo:** Supongamos que tiene un servicio que debe escalar según el número de solicitudes HTTP por segundo. Puede configurar el HPA para escalar en función de esta métrica personalizada.
+- **Consejos:** Al utilizar métricas personalizadas, asegúrese de que las métricas sean un indicador confiable de la carga de trabajo y de que el servicio de métricas esté configurado correctamente y sea accesible para el HPA.
 
-**Escalonamento com Base em Várias Métricas:**
-- O HPA pode ser configurado para levar em conta várias métricas ao mesmo tempo, permitindo um controle mais refinado do escalonamento.
-- Por exemplo, você pode configurar o HPA para escalar com base tanto na utilização de CPU quanto na memória, ou qualquer combinação de métricas padrão e personalizadas.
+**Escalado Basado en Múltiples Métricas:**
 
+- El HPA se puede configurar para tener en cuenta varias métricas al mismo tiempo, lo que permite un control más refinado del escalado.
+- Por ejemplo, puede configurar el HPA para escalar en función tanto del uso de la CPU como de la memoria, o cualquier combinación de métricas estándar y personalizadas.
 
-#### Integrando HPA com Prometheus para Métricas Customizadas
+#### Integración del HPA con Prometheus para Métricas Personalizadas
 
-Para levar o autoscaling para o próximo nível, podemos integrar o HPA com o Prometheus. Com essa integração, podemos usar métricas do Prometheus para informar nossas decisões de autoscaling.
+Para llevar el escalado automático al siguiente nivel, podemos integrar el HPA con Prometheus. Con esta integración, podemos utilizar métricas de Prometheus para informar nuestras decisiones de escalado automático.
 
-A integração geralmente envolve a configuração de um adaptador de métricas personalizadas, como o `k8s-prometheus-adapter`. Uma vez configurado, o HPA pode acessar métricas do Prometheus e usá-las para tomar decisões de autoscaling. A documentação completa sobre como integrar o HPA com o Prometheus pode ser encontrada [aqui](#adicionar-link).
+La integración generalmente implica configurar un adaptador de métricas personalizadas, como el `k8s-prometheus-adapter`. Una vez configurado, el HPA puede acceder a las métricas de Prometheus y utilizarlas para tomar decisiones de escalado automático. Puede encontrar la documentación completa sobre cómo integrar el HPA con Prometheus [aquí](#enlace-a-la-documentación).
 
-### A sua lição de casa
+### Tu Tarea
 
-Agora que você foi equipado com o conhecimento sobre o HPA, é hora de colocar esse conhecimento em prática. Configure um HPA em seu ambiente e experimente com diferentes métricas: CPU, memória e métricas personalizadas. Documente suas observações e compreenda como o HPA responde a diferentes cargas e situações.
+Ahora que has adquirido conocimientos sobre el HPA, es hora de poner en práctica ese conocimiento. Configura un HPA en tu entorno y experimenta con diferentes métricas: CPU, memoria y métricas personalizadas. Documenta tus observaciones y comprende cómo responde el HPA a diferentes cargas y situaciones.
 
-### Final do Day-11
+### Fin del Día 11
 
-E assim, chegamos ao fim do Day-11, uma jornada repleta de aprendizado e exploração. Hoje, você descobriu o poder do Horizontal Pod Autoscaler e como ele pode ajudar a manter seu aplicativo performando de maneira eficiente, mesmo sob diferentes condições de carga. Você não apenas aprendeu como ele funciona, mas também colocou a mão na massa com exemplos práticos. Continue praticando e explorando, e nos vemos no próximo dia da nossa aventura pelo Kubernetes! #VAIIII
\ No newline at end of file
+Y así llegamos al final del Día 11, un viaje lleno de aprendizaje y exploración. Hoy has descubierto el poder del Horizontal Pod Autoscaler y cómo puede ayudar a que tu aplicación funcione eficientemente incluso bajo diferentes condiciones de carga. No solo has aprendido cómo funciona, sino que también has puesto en práctica ejemplos prácticos. Sigue practicando y explorando, ¡y nos vemos en el próximo día de nuestra aventura en Kubernetes! #VAIIII

From 534e11aef19065a3e3eae79b21ab5f54fb311380 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sat, 20 Jan 2024 22:27:00 +0100
Subject: [PATCH 3/8] Update days 8 & 9

---
 es/day-8/README.md |  6 ------
 es/day-9/README.md | 20 +++++++++++++++++---
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/es/day-8/README.md b/es/day-8/README.md
index a0c9e9ef..71d280ad 100644
--- a/es/day-8/README.md
+++ b/es/day-8/README.md
@@ -34,7 +34,6 @@
         - [Instalación y Configuración de Vault en Kubernetes](#instalación-y-configuración-de-vault-en-kubernetes)
         - [Requisitos Previos](#requisitos-previos)
         - [Instalando y Configurando Vault con Helm](#instalando-y-configurando-vault-con-helm)
-- [Este comando agrega el repositorio Helm de HashiCorp a nuestra configuración de Helm.](#este-comando-agrega-el-repositorio-helm-de-hashicorp-a-nuestra-configuración-de-helm)
         - [Agregar el Repositorio del Operador de Secretos Externos a Helm](#agregar-el-repositorio-del-operador-de-secretos-externos-a-helm)
         - [Instalando el Operador de Secretos Externos](#instalando-el-operador-de-secretos-externos)
         - [Verificación de la Instalación de ESO](#verificación-de-la-instalación-de-eso)
@@ -978,12 +977,7 @@ Aquí están los pasos para instalar y configurar Vault utilizando Helm:
 helm repo add hashicorp https://helm.releases.hashicorp.com
 ```
 
-<<<<<<< HEAD
 Este comando agrega el repositorio Helm de HashiCorp a nuestra configuración de Helm.
-=======
-#################
-Este comando adiciona o repositório Helm da HashiCorp à nossa configuração do Helm.
->>>>>>> 56019ba70c5320a1b7dc63d54c013d46fef8569a
 
 **2. Instale Vault utilizando Helm**
 
diff --git a/es/day-9/README.md b/es/day-9/README.md
index 0091fdd6..08337d47 100644
--- a/es/day-9/README.md
+++ b/es/day-9/README.md
@@ -11,14 +11,28 @@
 
 ### Contenido del Día 9
 
-- [¿Por qué?](#por-que-)
+- [Simplificando Kubernetes](#simplificando-kubernetes)
+  - [DÍA 9](#día-9)
+    - [¿Qué veremos hoy?](#qué-veremos-hoy)
+    - [Contenido del Día 9](#contenido-del-día-9)
+- [¿Qué es Ingress?](#qué-es-ingress)
+- [Componentes de Ingress](#componentes-de-ingress)
+  - [Componentes Clave](#componentes-clave)
+    - [Controlador de Ingress](#controlador-de-ingress)
+    - [Recursos de Ingress](#recursos-de-ingress)
+    - [Anotaciones y Personalizaciones](#anotaciones-y-personalizaciones)
+    - [Instalación del Nginx Ingress Controller](#instalación-del-nginx-ingress-controller)
+      - [Instalación del Controlador de Ingress Nginx en Kind](#instalación-del-controlador-de-ingress-nginx-en-kind)
+        - [Creación del Clúster con Configuraciones Especiales](#creación-del-clúster-con-configuraciones-especiales)
+        - [Instalación de un Controlador de Ingress](#instalación-de-un-controlador-de-ingress)
+    - [Instalación de Giropops-Senhas en el Cluster](#instalación-de-giropops-senhas-en-el-cluster)
+    - [Creación de un Recurso de Ingress](#creación-de-un-recurso-de-ingress)
+- [TBD (Por determinar)](#tbd-por-determinar)
 
 &nbsp;
 
 # ¿Qué es Ingress?
 
-## ¿Qué es Ingress?
-
 Ingress es un recurso de Kubernetes que gestiona el acceso externo a los servicios dentro de un clúster. Funciona como una capa de enrutamiento HTTP/HTTPS, permitiendo la definición de reglas para dirigir el tráfico externo a diferentes servicios backend. Ingress se implementa a través de un controlador de Ingress, que puede ser alimentado por varias soluciones, como NGINX, Traefik o Istio, por mencionar algunas.
 
 Técnicamente, Ingress actúa como una abstracción de reglas de enrutamiento de alto nivel que son interpretadas y aplicadas por el controlador de Ingress. Permite características avanzadas como el equilibrio de carga, SSL/TLS, redirección, reescritura de URL, entre otras.

From c09eda66461fd957e1dd5c4ffeca493bcb81a525 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sun, 28 Jan 2024 10:01:09 +0100
Subject: [PATCH 4/8] Update Spanish translation Fixes #196

---
 es/README.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/es/README.md b/es/README.md
index 307f5c9e..afe9c547 100644
--- a/es/README.md
+++ b/es/README.md
@@ -1,6 +1,6 @@
 # Simplificando Kubernetes
 
-Este material es parte del curso "Simplificando Kubernetes" de LINUXtips. Ha sido diseñado para capacitar a persona estudiante o profesional de TI a trabajar con Kubernetes en entornos críticos.
+Este material es parte del curso "Simplificando Kubernetes" de LINUXtips. Ha sido diseñado para capacitar a la persona estudiante o profesional de TI a trabajar con Kubernetes en entornos críticos.
 
 El curso consta de material escrito, clases grabadas en vídeo y clases en vivo. Durante el curso, la persona será evaluada de manera práctica y deberá completar desafíos reales para avanzar en el curso.
 
@@ -69,7 +69,6 @@ El enfoque del curso es capacitar a la persona para trabajar con Kubernetes de m
 <details>
 <summary>DAY-2</summary>
 
-
 - [Simplificando Kubernetes](day-2/README.md#simplificando-kubernetes)
   - [Día 2](day-2/README.md#día-2)
     - [Contenido del Día 2](day-2/README.md#contenido-del-día-2)
@@ -308,7 +307,7 @@ Contamos con tu colaboración para hacer que este material sea aún más complet
 
 Mira los videos sobre Kubernetes, DevOps, Automatización y otros temas relacionados con la tecnología en los canales de LINUXtips:
 
-- [Canal de LINUXtips en Youtube](https://www.youtube.com/LINUXtips)
+- [Canal de LINUXtips en YouTube](https://www.youtube.com/LINUXtips)
 
 - [Canal de LINUXtips en Twitch](https://www.twitch.com/LINUXtips)
 

From 60bedd86c49ef9826a45ccd916883600d8115ab0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sun, 28 Jan 2024 10:39:26 +0100
Subject: [PATCH 5/8] =?UTF-8?q?Revisi=C3=B3n,=20modificaci=C3=B3n=20y=20cr?=
 =?UTF-8?q?eaci=C3=B3n=20de=20los=20nuevos=20d=C3=ADas=20de=20formaci?=
 =?UTF-8?q?=C3=B3n=20a=C3=B1adidos=20por=20Jeferson.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 es/day-12/README.md                  | 337 ++++++++-------------------
 es/day-7/README.md                   |   5 +
 es/day-7/files/headless-service.yaml |   2 +-
 es/day-8/README.md                   |   8 +-
 es/day-9/README.md                   |  32 +--
 5 files changed, 119 insertions(+), 265 deletions(-)

diff --git a/es/day-12/README.md b/es/day-12/README.md
index 540663b1..9f924f18 100644
--- a/es/day-12/README.md
+++ b/es/day-12/README.md
@@ -1,89 +1,69 @@
-# Descomplicando o Kubernetes
-## DAY-12: Dominando Taints e Tolerations
-
-## Conteúdo do Day-12
-
-- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes)
-  - [DAY-12: Dominando Taints e Tolerations](#day-12-dominando-taints-e-tolerations)
-  - [Conteúdo do Day-12](#conteúdo-do-day-12)
-    - [Introdução](#introdução)
-    - [O que são Taints e Tolerations?](#o-que-são-taints-e-tolerations)
-    - [Por que usar Taints e Tolerations?](#por-que-usar-taints-e-tolerations)
-    - [Anatomia de um Taint](#anatomia-de-um-taint)
-    - [Anatomia de uma Toleration](#anatomia-de-uma-toleration)
-    - [Aplicando Taints](#aplicando-taints)
-    - [Configurando Tolerations](#configurando-tolerations)
-    - [Cenários de Uso](#cenários-de-uso)
-      - [Isolamento de Workloads](#isolamento-de-workloads)
-      - [Nodes Especializados](#nodes-especializados)
-      - [Evacuação e Manutenção de Nodes](#evacuação-e-manutenção-de-nodes)
-    - [Combinando Taints e Tolerations com Affinity Rules](#combinando-taints-e-tolerations-com-affinity-rules)
-    - [Exemplos Práticos](#exemplos-práticos)
-      - [Exemplo 1: Isolamento de Workloads](#exemplo-1-isolamento-de-workloads)
-      - [Exemplo 2: Utilizando Hardware Especializado](#exemplo-2-utilizando-hardware-especializado)
-      - [Exemplo 3: Manutenção de Nodes](#exemplo-3-manutenção-de-nodes)
-    - [Conclusão](#conclusão)
-    - [Tarefas do Dia](#tarefas-do-dia)
-- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes-1)
-  - [DAY-12+1: Entendendo e Dominando os Selectors](#day-121-entendendo-e-dominando-os-selectors)
-  - [Conteúdo do Day-12+1](#conteúdo-do-day-121)
-    - [Introdução](#introdução-1)
-    - [O que são Selectors?](#o-que-são-selectors)
-    - [Tipos de Selectors](#tipos-de-selectors)
-      - [Equality-based Selectors](#equality-based-selectors)
-      - [Set-based Selectors](#set-based-selectors)
-    - [Selectors em Ação](#selectors-em-ação)
-      - [Em Services](#em-services)
-      - [Em ReplicaSets](#em-replicasets)
-      - [Em Jobs e CronJobs](#em-jobs-e-cronjobs)
-    - [Selectors e Namespaces](#selectors-e-namespaces)
-    - [Cenários de Uso](#cenários-de-uso-1)
-      - [Roteamento de Tráfego](#roteamento-de-tráfego)
-      - [Scaling Horizontal](#scaling-horizontal)
-      - [Desastre e Recuperação](#desastre-e-recuperação)
-    - [Dicas e Armadilhas](#dicas-e-armadilhas)
-    - [Exemplos Práticos](#exemplos-práticos-1)
-      - [Exemplo 1: Selector em um Service](#exemplo-1-selector-em-um-service)
-      - [Exemplo 2: Selector em um ReplicaSet](#exemplo-2-selector-em-um-replicaset)
-      - [Exemplo 3: Selectors Avançados](#exemplo-3-selectors-avançados)
-    - [Conclusão](#conclusão-1)
-
-
-### Introdução
-
-Olá, galera! No capítulo de hoje, vamos mergulhar fundo em um dos conceitos mais poderosos e flexíveis do Kubernetes: Taints e Tolerations. Prepare-se, pois este capítulo vai além do básico e entra em detalhes que você não vai querer perder. #VAIIII
-
-### O que são Taints e Tolerations?
-
-Taints são "manchas" ou "marcações" aplicadas aos Nodes que os marcam para evitar que certos Pods sejam agendados neles. Por outro lado, Tolerations são configurações que podem ser aplicadas aos Pods para permitir que eles sejam agendados em Nodes com Taints específicos.
-
-### Por que usar Taints e Tolerations?
-
-Em um cluster Kubernetes diversificado, nem todos os Nodes são iguais. Alguns podem ter acesso a recursos especiais como GPUs, enquanto outros podem ser reservados para workloads críticos. Taints e Tolerations fornecem um mecanismo para garantir que os Pods sejam agendados nos Nodes apropriados.
-
-### Anatomia de um Taint
-
-Um Taint é composto por uma `chave`, um `valor` e um `efeito`. O efeito pode ser:
-
-- `NoSchedule`: O Kubernetes não agenda o Pod a menos que ele tenha uma Toleration correspondente.
-- `PreferNoSchedule`: O Kubernetes tenta não agendar, mas não é uma garantia.
-- `NoExecute`: Os Pods existentes são removidos se não tiverem uma Toleration correspondente.
-
-### Anatomia de uma Toleration
-
-Uma Toleration é definida pelos mesmos elementos de um Taint: `chave`, `valor` e `efeito`. Além disso, ela contém um `operador`, que pode ser `Equal` ou `Exists`.
-
-### Aplicando Taints
-
-Para aplicar um Taint a um Node, você utiliza o comando `kubectl taint`. Por exemplo:
+# Simplificando Kubernetes
+
+## Día 12: Dominando Taints y Tolerations
+
+&nbsp;
+
+## Contenido del Día 12
+
+- [Simplificando Kubernetes](#simplificando-kubernetes)
+  - [Día 12: Dominando Taints y Tolerations](#día-12-dominando-taints-y-tolerations)
+  - [Contenido del Día 12](#contenido-del-día-12)
+    - [Introducción](#introducción)
+    - [¿Qué son Taints y Tolerations?](#qué-son-taints-y-tolerations)
+    - [¿Por qué usar Taints y Tolerations?](#por-qué-usar-taints-y-tolerations)
+    - [Anatomía de un Taint](#anatomía-de-un-taint)
+    - [Anatomía de una Tolerations](#anatomía-de-una-tolerations)
+    - [Aplicación de Taints](#aplicación-de-taints)
+    - [Configuración de Tolerations](#configuración-de-tolerations)
+    - [Escenarios de Uso](#escenarios-de-uso)
+      - [Aislamiento de Cargas de Trabajo](#aislamiento-de-cargas-de-trabajo)
+      - [Nodos Especializados](#nodos-especializados)
+      - [Toleration en un Pod que Requiere GPU:](#toleration-en-un-pod-que-requiere-gpu)
+      - [Evacuación y Mantenimiento de Nodos](#evacuación-y-mantenimiento-de-nodos)
+      - [Combinando Taints y Tolerations con Reglas de Afinidad](#combinando-taints-y-tolerations-con-reglas-de-afinidad)
+    - [Ejemplos Prácticos](#ejemplos-prácticos)
+      - [Ejemplo 1: Aislamiento de Cargas de Trabajo](#ejemplo-1-aislamiento-de-cargas-de-trabajo)
+      - [Ejemplo 2: Utilización de Hardware Especializado](#ejemplo-2-utilización-de-hardware-especializado)
+      - [Ejemplo 3: Mantenimiento de Nodos](#ejemplo-3-mantenimiento-de-nodos)
+    - [Conclusión](#conclusión)
+    - [Tareas del Día](#tareas-del-día)
+
+### Introducción
+
+¡Hola a todos! En el capítulo de hoy, vamos a sumergirnos profundamente en uno de los conceptos más poderosos y flexibles de Kubernetes: Taints (Marcas) y Tolerations (Tolerancias). Prepárense, porque este capítulo va más allá de lo básico y entra en detalles que no querrán perderse. #VAMOS
+
+### ¿Qué son Taints y Tolerations?
+
+Los Taints son "manchas" o "marcas" aplicadas a los Nodos que los marcan para evitar que ciertos Pods sean programados en ellos. Por otro lado, las Tolerations son configuraciones que se pueden aplicar a los Pods para permitir que sean programados en Nodos con Taints específicos.
+
+### ¿Por qué usar Taints y Tolerations?
+
+En un clúster Kubernetes diverso, no todos los Nodos son iguales. Algunos pueden tener acceso a recursos especiales como GPUs, mientras que otros pueden estar reservados para cargas de trabajo críticas. Los Taints y Tolerations proporcionan un mecanismo para asegurar que los Pods se programen en los Nodos adecuados.
+
+### Anatomía de un Taint
+
+Un Taint está compuesto por una `clave`, un `valor` y un `efecto`. El efecto puede ser:
+
+- `NoSchedule`: Kubernetes no programa el Pod a menos que tenga una Tolerations correspondiente.
+- `PreferNoSchedule`: Kubernetes intenta no programar, pero no hay garantía.
+- `NoExecute`: Los Pods existentes son eliminados si no tienen una Tolerations correspondiente.
+
+### Anatomía de una Tolerations
+
+Una Tolerations se define mediante los mismos elementos que un Taint: `clave`, `valor` y `efecto`. Además, contiene un `operador`, que puede ser `Equal` o `Exists`.
+
+### Aplicación de Taints
+
+Para aplicar un Taint a un Nodo, puedes utilizar el comando `kubectl taint`. Por ejemplo:
 
 ```bash
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes nodo1 clave=valor:NoSchedule
 ```
 
-### Configurando Tolerations
+### Configuración de Tolerations
 
-Tolerations são configuradas no PodSpec. Aqui está um exemplo:
+Las Tolerations se configuran en el PodSpec. Aquí tienes un ejemplo:
 
 ```yaml
 apiVersion: v1
@@ -98,39 +78,39 @@ spec:
     effect: "NoSchedule"
 ```
 
-### Cenários de Uso
+### Escenarios de Uso
 
-#### Isolamento de Workloads
+#### Aislamiento de Cargas de Trabajo
 
-Imagine um cenário onde você tem Nodes que devem ser dedicados a workloads de produção e não devem executar Pods de desenvolvimento.
+Imagina un escenario en el que tienes Nodos que deben estar dedicados a cargas de trabajo de producción y no deben ejecutar Pods de desarrollo.
 
-Aplicar Taint:
+Aplicación de Taint:
 
 ```bash
 kubectl taint nodes prod-node environment=production:NoSchedule
 ```
 
-Toleration em Pod de produção:
+Tolerancia en el Pod de producción:
 
 ```yaml
 tolerations:
 - key: "environment"
   operator: "Equal"
-  value: "production"
+  value: "producción"
   effect: "NoSchedule"
 ```
 
-#### Nodes Especializados
+#### Nodos Especializados
 
-Se você tem Nodes com GPUs e quer garantir que apenas Pods que necessitem de GPUs sejam agendados ali.
+Si tienes Nodos con GPUs y deseas asegurarte de que solo se programen Pods que necesiten GPUs allí.
 
-Aplicar Taint:
+Aplicación de Taint:
 
 ```bash
 kubectl taint nodes gpu-node gpu=true:NoSchedule
 ```
 
-Toleration em Pod que necessita de GPU:
+#### Toleration en un Pod que Requiere GPU:
 
 ```yaml
 tolerations:
@@ -140,9 +120,9 @@ tolerations:
   effect: "NoSchedule"
 ```
 
-#### Evacuação e Manutenção de Nodes
+#### Evacuación y Mantenimiento de Nodos
 
-Se você precisa realizar manutenção em um Node e quer evitar que novos Pods sejam agendados nele.
+Si necesitas realizar mantenimiento en un Nodo y deseas evitar que se programen nuevos Pods en él.
 
 Aplicar Taint:
 
@@ -150,188 +130,57 @@ Aplicar Taint:
 kubectl taint nodes node1 maintenance=true:NoExecute
 ```
 
-### Combinando Taints e Tolerations com Affinity Rules
+#### Combinando Taints y Tolerations con Reglas de Afinidad
 
-Você pode combinar Taints e Tolerations com regras de afinidade para um controle ainda mais granular.
+Puedes combinar Taints y Tolerations con reglas de afinidad para un control aún más granular.
 
-### Exemplos Práticos
+### Ejemplos Prácticos
 
-#### Exemplo 1: Isolamento de Workloads
+#### Ejemplo 1: Aislamiento de Cargas de Trabajo
 
-Vamos criar um Node com um Taint e tentar agendar um Pod sem a Toleration correspondente.
+Creemos un Nodo con un Taint y tratemos de programar un Pod sin la Toleration correspondiente.
 
 ```bash
 # Aplicar Taint
 kubectl taint nodes dev-node environment=development:NoSchedule
 
-# Tentar agendar Pod
+# Intentar programar el Pod
 kubectl run nginx --image=nginx
 ```
 
-Observe que o Pod não será agendado até que uma Toleration seja adicionada.
+Observa que el Pod no se programará hasta que se agregue una Toleration correspondiente.
 
-#### Exemplo 2: Utilizando Hardware Especializado
+#### Ejemplo 2: Utilización de Hardware Especializado
 
-Vamos criar um Node com uma GPU e aplicar um Taint correspondente.
+Creemos un Nodo con una GPU y apliquemos un Taint correspondiente.
 
 ```bash
 # Aplicar Taint
 kubectl taint nodes gpu-node gpu=true:NoSchedule
 
-# Agendar Pod com Toleration
+# Programar Pod con Toleration
 kubectl apply -f gpu-pod.yaml
 ```
 
-Onde `gpu-pod.yaml` contém a Toleration correspondente.
-
-#### Exemplo 3: Manutenção de Nodes
+Donde `gpu-pod.yaml` contiene la Toleration correspondiente.
 
-Vamos simular uma manutenção, aplicando um Taint em um
+#### Ejemplo 3: Mantenimiento de Nodos
 
- Node e observando como os Pods são removidos.
+Simulemos un mantenimiento aplicando un Taint a un Nodo y observemos cómo se eliminan los Pods.
 
 ```bash
 # Aplicar Taint
 kubectl taint nodes node1 maintenance=true:NoExecute
 ```
 
-### Conclusão
-
-Taints e Tolerations são ferramentas poderosas para o controle refinado do agendamento de Pods. Com elas, você pode isolar workloads, aproveitar hardware especializado e até gerenciar manutenções de forma mais eficaz.
-
-### Tarefas do Dia
-
-1. Aplique um Taint em um dos seus Nodes e tente agendar um Pod sem a Toleration correspondente.
-2. Remova o Taint e observe o comportamento.
-3. Adicione uma Toleration ao Pod e repita o processo.
-
-# Descomplicando o Kubernetes
-## DAY-12+1: Entendendo e Dominando os Selectors
-
-## Conteúdo do Day-12+1
-
-
-
-
-
-### Introdução
-
-E aí, pessoal! No capítulo de hoje, vamos nos aprofundar em um dos recursos mais versáteis e fundamentais do Kubernetes: os Selectors. Preparados? Então #VAIIII!
-
-### O que são Selectors?
-
-Selectors são formas de selecionar recursos, como Pods, com base em suas labels. Eles são a cola que une vários componentes do Kubernetes, como Services e ReplicaSets.
-
-### Tipos de Selectors
-
-#### Equality-based Selectors
-
-Estes são os mais simples, usando operadores como `=`, `==`, e `!=`.
-
-Exemplo:
-
-```bash
-kubectl get pods -l environment=production
-```
-
-#### Set-based Selectors
-
-Estes são mais complexos e usam operadores como `in`, `notin`, e `exists`.
-
-Exemplo:
-
-```bash
-kubectl get pods -l 'environment in (production, qa)'
-```
+Estos ejemplos prácticos te ayudarán a comprender mejor cómo funcionan los Taints y Tolerations en situaciones del mundo real.
 
-### Selectors em Ação
+### Conclusión
 
-#### Em Services
-
-Services usam selectors para direcionar tráfego para Pods específicos.
-
-Exemplo:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: my-service
-spec:
-  selector:
-    app: MyApp
-```
-
-#### Em ReplicaSets
-
-ReplicaSets usam selectors para saber quais Pods gerenciar.
-
-Exemplo:
-
-```yaml
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
-  name: my-replicaset
-spec:
-  selector:
-    matchLabels:
-      app: MyApp
-```
-
-#### Em Jobs e CronJobs
-
-Jobs e CronJobs também podem usar selectors para executar tarefas em Pods específicos.
-
-### Selectors e Namespaces
-
-É crucial entender que os selectors não atravessam namespaces; eles são eficazes apenas dentro do namespace atual, a menos que especificado de outra forma.
-
-### Cenários de Uso
-
-#### Roteamento de Tráfego
-
-Use selectors em Services para direcionar tráfego para versões específicas de uma aplicação.
-
-#### Scaling Horizontal
-
-Use selectors em Horizontal Pod Autoscalers para escalar apenas os Pods que atendem a critérios específicos.
-
-#### Desastre e Recuperação
-
-Em casos de failover, você pode usar selectors para direcionar tráfego para Pods em um cluster secundário.
-
-### Dicas e Armadilhas
-
-- Não mude as labels de Pods que são alvos de Services sem atualizar o selector do Service.
-- Use selectors de forma consistente para evitar confusões.
-
-### Exemplos Práticos
-
-#### Exemplo 1: Selector em um Service
-
-Vamos criar um Service que seleciona todos os Pods com a label `frontend`.
-
-```bash
-kubectl apply -f frontend-service.yaml
-```
-
-#### Exemplo 2: Selector em um ReplicaSet
-
-Vamos criar um ReplicaSet que gerencia todos os Pods com a label `backend`.
-
-```bash
-kubectl apply -f backend-replicaset.yaml
-```
-
-#### Exemplo 3: Selectors Avançados
-
-Vamos fazer uma query complexa para selecionar Pods com base em múltiplas labels.
-
-```bash
-kubectl get pods -l 'release-version in (v1, v2),environment!=debug'
-```
+Taints y Tolerations son herramientas poderosas para un control refinado de la programación de Pods. Con ellas, puedes aislar workloads, aprovechar hardware especializado e incluso gestionar el mantenimiento de manera más eficaz.
 
-### Conclusão
+### Tareas del Día
 
-Selectors são uma ferramenta poderosa e flexível no Kubernetes, permitindo um controle fino sobre como os recursos interagem. Dominar este conceito é fundamental para qualquer um que trabalhe com Kubernetes.
+1. Aplica un Taint en uno de tus Nodos y trata de programar un Pod sin la Toleration correspondiente.
+2. Elimina el Taint y observa el comportamiento.
+3. Agrega una Toleration al Pod y repite el proceso.
diff --git a/es/day-7/README.md b/es/day-7/README.md
index b05b9291..14a91197 100644
--- a/es/day-7/README.md
+++ b/es/day-7/README.md
@@ -33,6 +33,7 @@
         - [Verificando los Endpoints](#verificando-los-endpoints)
         - [Eliminando un Service](#eliminando-un-service)
     - [Tu tarea](#tu-tarea)
+  - [Final del Día 7](#final-del-día-7)
 
 ## Inicio de la Lección del Día 7
 
@@ -696,6 +697,10 @@ Por último, pero no menos importante, crea un `Service` de tipo `ExternalName`
 
 Recuerda que la práctica hace al maestro, ¡así que no te saltes esta tarea! ;) Y si tienes preguntas o problemas, no dudes en pedir ayuda. ¡Estamos aquí para aprender juntos!
 
+&nbsp;
+
+## Final del Día 7
+
 ¡Hasta aquí llegamos por el Día 7! Durante este día, has aprendido acerca de dos recursos esenciales en Kubernetes: `StatefulSets` y `Services`. A través de ellos, puedes administrar aplicaciones que necesitan mantener la identidad del `Pod`, persistir datos y exponer esas aplicaciones al mundo exterior.
 
 Espero que hayas disfrutado del contenido de hoy y recuerda hacer la tarea. La práctica es fundamental para consolidar todo este conocimiento y realmente marca la diferencia.
diff --git a/es/day-7/files/headless-service.yaml b/es/day-7/files/headless-service.yaml
index 01518f0a..2c142a4b 100644
--- a/es/day-7/files/headless-service.yaml
+++ b/es/day-7/files/headless-service.yaml
@@ -8,6 +8,6 @@ spec:
   ports:
   - port: 80
     name: web
-  clusterIP: None # Como estamos criando um Headless Service, não queremos que ele tenha um IP, então definimos o clusterIP como None
+  clusterIP: None # Como estamos creando un Servicio Headless, no queremos que tenga una dirección IP, por lo que definimos el clusterIP como None.
   selector:
     app: nginx
\ No newline at end of file
diff --git a/es/day-8/README.md b/es/day-8/README.md
index 71d280ad..b40d418b 100644
--- a/es/day-8/README.md
+++ b/es/day-8/README.md
@@ -88,7 +88,7 @@ Existen varios tipos de Secrets que puedes utilizar, dependiendo de tus necesida
 
 Hay algunos tipos más de Secrets, pero estos son los más comunes. Puedes encontrar una lista completa de tipos de Secrets en la documentación de Kubernetes.
 
-Cada tipo de Secret tiene un formato diferente. Por ejemplo, los `Opaque Secrets` se almacenan como un mapa de cadenas, mientras que los `Secrets TLS` se almacenan como un mapa de cadenas con claves adicionales para almacenar certificados y claves, por lo que es importante saber qué tipo de Secret estás utilizando para almacenar los datos correctamente.
+Cada tipo de Secret tiene un formato diferente. Por ejemplo, los `Opaque Secrets` se almacenan como un mapa de strings, mientras que los `Secrets TLS` se almacenan como un mapa de strings con claves adicionales para almacenar certificados y claves, por lo que es importante saber qué tipo de Secret estás utilizando para almacenar los datos correctamente.
 
 ##### Antes de crear un Secret, el Base64
 
@@ -229,7 +229,7 @@ kubectl create secret generic giropops-secret --from-literal=username=<SECRETO>
 
 Fácil, aquí estamos utilizando el parámetro `--from-literal` para definir los datos del Secret. Otras opciones son `--from-file` y `--from-env-file`, que puedes utilizar para definir los datos del Secret a partir de un archivo o variables de entorno.
 
-Si comparas las cadenas de los campos `username` y `password` del Secret creado utilizando el comando `kubectl create secret` con las cadenas de los campos `username` y `password` del Secret creado utilizando el archivo YAML, notarás que son identicas. Esto se debe porque el comando `kubectl create secret` automáticamente codifica los datos en Base64.
+Si comparas las cadenas de los campos `username` y `password` del Secret creado utilizando el comando `kubectl create secret` con las cadenas de los campos `username` y `password` del Secret creado utilizando el archivo YAML, notarás que son idénticas. Esto se debe porque el comando `kubectl create secret` automáticamente codifica los datos en Base64.
 
 &nbsp;
 
@@ -358,8 +358,8 @@ QXF1aSB0ZW0gcXVlIGVzdGFyIG8gY29udGXDumRvIGRvIHNldSBjb25maWcuanNvbiwgY29pc2EgbGlu
 apiVersion: v1
 kind: Secret
 metadata:
-  name: docker-hub-secret # nombre del Secreto
-type: kubernetes.io/dockerconfigjson # tipo de Secreto, en este caso, es un Secreto que almacena credenciales de Docker
+  name: docker-hub-secret # nombre del Secret
+type: kubernetes.io/dockerconfigjson # tipo de Secret, en este caso, es un Secret que almacena credenciales de Docker
 data:
   .dockerconfigjson: |  # reemplace este valor con el contenido de su archivo config.json codificado en base64
     QXF1aSB0ZW0gcXVlIGVzdGFyIG8gY29udGXDumRvIGRvIHNldSBjb25maWcuanNvbiwgY29pc2EgbGluZGEgZG8gSmVmaW0=
diff --git a/es/day-9/README.md b/es/day-9/README.md
index 08337d47..089a65a9 100644
--- a/es/day-9/README.md
+++ b/es/day-9/README.md
@@ -18,13 +18,13 @@
 - [¿Qué es Ingress?](#qué-es-ingress)
 - [Componentes de Ingress](#componentes-de-ingress)
   - [Componentes Clave](#componentes-clave)
-    - [Controlador de Ingress](#controlador-de-ingress)
-    - [Recursos de Ingress](#recursos-de-ingress)
+    - [Ingress Controller](#ingress-controller)
+    - [Ingress Resources](#ingress-resources)
     - [Anotaciones y Personalizaciones](#anotaciones-y-personalizaciones)
     - [Instalación del Nginx Ingress Controller](#instalación-del-nginx-ingress-controller)
-      - [Instalación del Controlador de Ingress Nginx en Kind](#instalación-del-controlador-de-ingress-nginx-en-kind)
+      - [Instalación del Ingress Controller Nginx en Kind](#instalación-del-ingress-controller-nginx-en-kind)
         - [Creación del Clúster con Configuraciones Especiales](#creación-del-clúster-con-configuraciones-especiales)
-        - [Instalación de un Controlador de Ingress](#instalación-de-un-controlador-de-ingress)
+        - [Instalación de un Ingress Controller](#instalación-de-un-ingress-controller)
     - [Instalación de Giropops-Senhas en el Cluster](#instalación-de-giropops-senhas-en-el-cluster)
     - [Creación de un Recurso de Ingress](#creación-de-un-recurso-de-ingress)
 - [TBD (Por determinar)](#tbd-por-determinar)
@@ -56,13 +56,13 @@ Ahora que ya sabemos qué es Ingress y por qué utilizarlo, es hora de sumergirn
 
 ## Componentes Clave
 
-### Controlador de Ingress
+### Ingress Controller
 
-El Controlador de Ingress es el motor detrás del objeto Ingress. Es responsable de aplicar las reglas de enrutamiento definidas en el recurso Ingress. Ejemplos populares incluyen el Controlador de Ingress de Nginx, Traefik y HAProxy Ingress.
+El Ingress Controller es el motor detrás del objeto Ingress. Es responsable de aplicar las reglas de enrutamiento definidas en el recurso Ingress. Ejemplos populares incluyen el Ingress Controller de Nginx, Traefik y HAProxy Ingress.
 
-### Recursos de Ingress
+### Ingress Resources
 
-Los Recursos de Ingress son las configuraciones que defines para indicar al Controlador de Ingress cómo debe ser enrutado el tráfico. Estas se definen en archivos YAML y se aplican en el clúster.
+Los Ingress Resources son las configuraciones que defines para indicar al Ingress Controller cómo debe ser enrutado el tráfico. Estas se definen en archivos YAML y se aplican en el clúster.
 
 ### Anotaciones y Personalizaciones
 
@@ -97,9 +97,9 @@ kubectl wait --namespace ingress-nginx \
   --timeout=90s
 ```
 
-En el comando anterior, estamos esperando que los pods del Controlador de Ingress estén listos, con la etiqueta `app.kubernetes.io/component=controller`, en el namespace `ingress-nginx`, y en caso de que no estén listos en 90 segundos, el comando fallará.
+En el comando anterior, estamos esperando que los pods del Ingress Controller estén listos, con la etiqueta `app.kubernetes.io/component=controller`, en el namespace `ingress-nginx`, y en caso de que no estén listos en 90 segundos, el comando fallará.
 
-#### Instalación del Controlador de Ingress Nginx en Kind
+#### Instalación del Ingress Controller Nginx en Kind
 
 Kind es una herramienta muy útil para realizar pruebas y desarrollo con Kubernetes. En esta sección actualizada, proporcionamos detalles específicos para asegurarnos de que Ingress funcione como se espera en un clúster Kind.
 
@@ -133,9 +133,9 @@ nodes:
 kind create cluster --config kind-config.yaml
 ```
 
-##### Instalación de un Controlador de Ingress
+##### Instalación de un Ingress Controller
 
-Continuaremos utilizando el Controlador de Ingress de Nginx como ejemplo, ya que es ampliamente adoptado y bien documentado.
+Continuaremos utilizando el Ingress Controller de Nginx como ejemplo, ya que es ampliamente adoptado y bien documentado.
 
 ```bash
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
@@ -150,7 +150,7 @@ kubectl wait --namespace ingress-nginx \
   --timeout=90s
 ```
 
-En el comando anterior, estamos esperando que los pods del Controlador de Ingress estén listos, con la etiqueta `app.kubernetes.io/component=controller`, en el espacio de nombres `ingress-nginx`, y si no están listos en 90 segundos, el comando fallará.
+En el comando anterior, estamos esperando que los pods del Ingress Controller estén listos, con la etiqueta `app.kubernetes.io/component=controller`, en el espacio de nombres `ingress-nginx`, y si no están listos en 90 segundos, el comando fallará.
 
 ### Instalación de Giropops-Senhas en el Cluster
 
@@ -163,7 +163,7 @@ apiVersion: apps/v1
 kind: Deployment
 metadata:
   labels:
-    app: giropops-senhas
+    app: giropops-senhas # No se traduce giropops-senhas
   name: giropops-senhas
 spec:
   replicas: 2
@@ -256,7 +256,7 @@ spec:
   type: ClusterIP
 ```
 
-Con los archivos mencionados anteriormente, estamos creando un Deployment y un Service para Giropops-Senhas, y un Deployment y un Service para Redis.
+Con los archivos mencionados anteriormente, estamos creando un Deployment y un Service para `Giropops-Senhas`, y un Deployment y un Service para Redis.
 
 Para aplicarlos, simplemente ejecute los siguientes comandos:
 
@@ -345,7 +345,7 @@ Si está utilizando un clúster gestionado por un proveedor de servicios en la n
 kubectl get ingress giropops-senhas -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
 ```
 
-Esto se debe a que cuando tienes un clúster EKS, AKS, GCP, etc., el controlador de Ingress creará un equilibrador de carga para ti, y la dirección IP del equilibrador de carga será la dirección IP de tu Ingress, así de simple.
+Esto se debe a que cuando tienes un clúster EKS, AKS, GCP, etc., el Ingress Controller creará un equilibrador de carga para ti, y la dirección IP del equilibrador de carga será la dirección IP de tu Ingress, así de simple.
 
 Para probarlo, puedes usar el comando curl con la dirección IP, el nombre de host o el equilibrador de carga de tu Ingress:
 

From 653cb4b39a310aef987b5797c5353a706dd54871 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sun, 28 Jan 2024 10:51:54 +0100
Subject: [PATCH 6/8] =?UTF-8?q?Actualizaci=C3=B3n=20d=C3=ADa=2012?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 es/day-12/README.md | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/es/day-12/README.md b/es/day-12/README.md
index 9f924f18..28b091a8 100644
--- a/es/day-12/README.md
+++ b/es/day-12/README.md
@@ -28,6 +28,13 @@
       - [Ejemplo 3: Mantenimiento de Nodos](#ejemplo-3-mantenimiento-de-nodos)
     - [Conclusión](#conclusión)
     - [Tareas del Día](#tareas-del-día)
+  - [DÍA 12+1: Comprendiendo y Dominando los Selectores](#día-121-comprendiendo-y-dominando-los-selectores)
+  - [Contenido del Día-12+1](#contenido-del-día-121)
+    - [Introducción 12+1](#introducción-121)
+    - [¿Qué son los Selectors?](#qué-son-los-selectors)
+    - [Tipos de Selectors](#tipos-de-selectors)
+      - [Equality-based Selectors](#equality-based-selectors)
+      - [Set-based Selectors](#set-based-selectors)
 
 ### Introducción
 
@@ -184,3 +191,37 @@ Taints y Tolerations son herramientas poderosas para un control refinado de la p
 1. Aplica un Taint en uno de tus Nodos y trata de programar un Pod sin la Toleration correspondiente.
 2. Elimina el Taint y observa el comportamiento.
 3. Agrega una Toleration al Pod y repite el proceso.
+
+## DÍA 12+1: Comprendiendo y Dominando los Selectores
+
+## Contenido del Día-12+1
+
+### Introducción 12+1
+
+¡Hola a todos! En el capítulo de hoy, profundizaremos en uno de los recursos más versátiles y fundamentales de Kubernetes: los Selectores. ¿Están listos? ¡Entonces #VAMOS!
+
+### ¿Qué son los Selectors?
+
+Los Selectors son formas de seleccionar recursos, como Pods, en función de sus etiquetas. Son el pegamento que une varios componentes de Kubernetes, como Services y RéplicaSets.
+
+### Tipos de Selectors
+
+#### Equality-based Selectors
+
+Estos son los más simples y utilizan operadores como `=`, `==` y `!=`.
+
+Ejemplo:
+
+```bash
+kubectl get pods -l environment=production
+```
+
+#### Set-based Selectors
+
+Estos son más complejos y utilizan operadores como `in`, `notin` y `exists`.
+
+Ejemplo:
+
+```bash
+kubectl get pods -l 'environment in (production, qa)'
+```
\ No newline at end of file

From a98a779cf8046786c35bdb8baf4c121a60b79075 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sun, 28 Jan 2024 11:19:27 +0100
Subject: [PATCH 7/8] =?UTF-8?q?Finalizaci=C3=B3n=20traducci=C3=B3n=20de=20?=
 =?UTF-8?q?los=20nuevos=20d=C3=ADas.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 es/SUMMARY.md       |   2 +-
 es/day-12/README.md | 109 ++++++++++++++-
 es/day-13/README.md | 332 ++++++++++++++++++++++----------------------
 3 files changed, 275 insertions(+), 168 deletions(-)

diff --git a/es/SUMMARY.md b/es/SUMMARY.md
index 84f4a6a4..629b1f51 100644
--- a/es/SUMMARY.md
+++ b/es/SUMMARY.md
@@ -24,4 +24,4 @@
 
 ## Contribuir
 
-* [Cómo ayudar](CONTRIBUTING.md)
\ No newline at end of file
+* [Cómo ayudar](CONTRIBUTING.md)
diff --git a/es/day-12/README.md b/es/day-12/README.md
index 28b091a8..23efae6c 100644
--- a/es/day-12/README.md
+++ b/es/day-12/README.md
@@ -35,6 +35,21 @@
     - [Tipos de Selectors](#tipos-de-selectors)
       - [Equality-based Selectors](#equality-based-selectors)
       - [Set-based Selectors](#set-based-selectors)
+    - [Selectors en acción](#selectors-en-acción)
+      - [En Services](#en-services)
+      - [En ReplicaSets](#en-replicasets)
+      - [En Jobs y CronJobs](#en-jobs-y-cronjobs)
+    - [Selectores y Namespaces](#selectores-y-namespaces)
+    - [Escenarios de uso](#escenarios-de-uso-1)
+      - [Enrutamiento de tráfico](#enrutamiento-de-tráfico)
+      - [Escalado horizontal](#escalado-horizontal)
+      - [Desastre y recuperación](#desastre-y-recuperación)
+    - [Consejos y trampas](#consejos-y-trampas)
+    - [Ejemplos prácticos](#ejemplos-prácticos-1)
+      - [Ejemplo 1: Selector en un Service](#ejemplo-1-selector-en-un-service)
+      - [Ejemplo 2: Selector en un ReplicaSet](#ejemplo-2-selector-en-un-replicaset)
+      - [Ejemplo 3: Selectors avanzados](#ejemplo-3-selectors-avanzados)
+    - [Conclusión 12+1](#conclusión-121)
 
 ### Introducción
 
@@ -224,4 +239,96 @@ Ejemplo:
 
 ```bash
 kubectl get pods -l 'environment in (production, qa)'
-```
\ No newline at end of file
+```
+
+### Selectors en acción
+
+#### En Services
+
+Los Services utilizan selectores para dirigir el tráfico hacia Pods específicos.
+
+Ejemplo:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+```
+
+#### En ReplicaSets
+
+Los ReplicaSets utilizan selectores para saber qué Pods gestionar.
+
+Ejemplo:
+
+```yaml
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+  name: my-replicaset
+spec:
+  selector:
+    matchLabels:
+      app: MyApp
+```
+
+#### En Jobs y CronJobs
+
+Los Jobs y CronJobs también pueden utilizar selectores para ejecutar tareas en Pods específicos.
+
+### Selectores y Namespaces
+
+Es crucial entender que los selectores no atraviesan namespaces; son efectivos solo dentro del namespace actual a menos que se especifique de otra manera.
+
+### Escenarios de uso
+
+#### Enrutamiento de tráfico
+
+Utilice Selectors en los Services para dirigir el tráfico hacia versiones específicas de una aplicación.
+
+#### Escalado horizontal
+
+Utilice selectores en Horizontal Pod Autoscalers para escalar solo los Pods que cumplan con criterios específicos.
+
+#### Desastre y recuperación
+
+En casos de conmutación por error, puede utilizar selectores para dirigir el tráfico hacia Pods en un clúster secundario.
+
+### Consejos y trampas
+
+- No cambie las etiquetas de los Pods que son objetivos de Services sin actualizar el selector del Service.
+- Utilice selectores de manera consistente para evitar confusiones.
+
+### Ejemplos prácticos
+
+#### Ejemplo 1: Selector en un Service
+
+Vamos a crear un Service que seleccione todos los Pods con la etiqueta `frontend`.
+
+```bash
+kubectl apply -f frontend-service.yaml
+```
+
+#### Ejemplo 2: Selector en un ReplicaSet
+
+Vamos a crear un ReplicaSet que gestione todos los Pods con la etiqueta `backend`.
+
+```bash
+kubectl apply -f backend-replicaset.yaml
+```
+
+#### Ejemplo 3: Selectors avanzados
+
+Vamos a realizar una consulta compleja para seleccionar Pods basados en múltiples etiquetas.
+
+```bash
+kubectl get pods -l 'release-version in (v1, v2),environment!=debug'
+```
+
+### Conclusión 12+1
+
+Los selectores son una herramienta poderosa y flexible en Kubernetes, que permite un control preciso sobre cómo interactúan los recursos. Dominar este concepto es fundamental para cualquiera que trabaje con Kubernetes.
diff --git a/es/day-13/README.md b/es/day-13/README.md
index 73b6512a..f61a0dc7 100644
--- a/es/day-13/README.md
+++ b/es/day-13/README.md
@@ -1,148 +1,148 @@
-# Descomplicando o Kubernetes
-## DAY-13: Descomplicando Kyverno e as Policies no Kubernetes
-
-## Conteúdo do Day-13
-
-- [Descomplicando o Kubernetes](#descomplicando-o-kubernetes)
-  - [DAY-13: Descomplicando Kyverno e as Policies no Kubernetes](#day-13-descomplicando-kyverno-e-as-policies-no-kubernetes)
-  - [Conteúdo do Day-13](#conteúdo-do-day-13)
-  - [O que iremos ver hoje?](#o-que-iremos-ver-hoje)
-  - [Inicio do Day-13](#inicio-do-day-13)
-    - [Introdução ao Kyverno](#introdução-ao-kyverno)
-    - [Instalando o Kyverno](#instalando-o-kyverno)
-      - [Utilizando Helm](#utilizando-helm)
-    - [Verificando a Instalação](#verificando-a-instalação)
-    - [Criando a nossa primeira Policy](#criando-a-nossa-primeira-policy)
-    - [Mais exemplos de Policies](#mais-exemplos-de-policies)
-      - [Exemplo de Política: Adicionar Label ao Namespace](#exemplo-de-política-adicionar-label-ao-namespace)
-        - [Detalhes da Política](#detalhes-da-política)
-        - [Arquivo de Política: `add-label-namespace.yaml`](#arquivo-de-política-add-label-namespaceyaml)
-        - [Utilização da Política](#utilização-da-política)
-      - [Exemplo de Política: Proibir Usuário Root](#exemplo-de-política-proibir-usuário-root)
-        - [Detalhes da Política](#detalhes-da-política-1)
-        - [Arquivo de Política: `disallow-root-user.yaml`](#arquivo-de-política-disallow-root-useryaml)
-        - [Implementação e Efeito](#implementação-e-efeito)
-      - [Exemplo de Política: Gerar ConfigMap para Namespace](#exemplo-de-política-gerar-configmap-para-namespace)
-        - [Detalhes da Política](#detalhes-da-política-2)
-        - [Arquivo de Política: `generate-configmap-for-namespace.yaml`](#arquivo-de-política-generate-configmap-for-namespaceyaml)
-        - [Implementação e Utilidade](#implementação-e-utilidade)
-      - [Exemplo de Política: Permitir Apenas Repositórios Confiáveis](#exemplo-de-política-permitir-apenas-repositórios-confiáveis)
-        - [Detalhes da Política](#detalhes-da-política-3)
-        - [Arquivo de Política: `registry-allowed.yaml`](#arquivo-de-política-registry-allowedyaml)
-        - [Implementação e Impacto](#implementação-e-impacto)
-        - [Exemplo de Política: Require Probes](#exemplo-de-política-require-probes)
-        - [Detalhes da Política](#detalhes-da-política-4)
-        - [Arquivo de Política: `require-probes.yaml`](#arquivo-de-política-require-probesyaml)
-        - [Implementação e Impacto](#implementação-e-impacto-1)
-      - [Exemplo de Política: Usando o Exclude](#exemplo-de-política-usando-o-exclude)
-        - [Detalhes da Política](#detalhes-da-política-5)
-        - [Arquivo de Política](#arquivo-de-política)
-        - [Implementação e Efeitos](#implementação-e-efeitos)
-    - [Conclusão](#conclusão)
-      - [Pontos-Chave Aprendidos](#pontos-chave-aprendidos)
-
-## O que iremos ver hoje?
-
-Hoje, exploraremos as funcionalidades e aplicações do Kyverno, uma ferramenta de gerenciamento de políticas essencial para a segurança e eficiência de clusters Kubernetes. Com uma abordagem detalhada e prática, você aprenderá a usar o Kyverno para automatizar tarefas cruciais, garantir a conformidade com normas e regras estabelecidas e melhorar a administração geral de seus ambientes Kubernetes.
-
-**Principais Tópicos Abordados:**
-
-1. **Introdução ao Kyverno:** Uma visão geral do Kyverno, destacando sua importância e as principais funções de validação, mutação e geração de recursos.
-
-2. **Instalação e Configuração:** Passo a passo para a instalação do Kyverno, incluindo métodos usando o Helm e arquivos YAML, e como verificar se a instalação foi bem-sucedida.
-
-3. **Desenvolvendo Políticas Eficientes:** Aprenda a criar políticas para diferentes cenários, desde garantir limites de CPU e memória em Pods até aplicar automaticamente labels a namespaces e restringir a execução de containers como root.
-
-4. **Exemplos Práticos:** Vários exemplos de políticas, ilustrando como o Kyverno pode ser aplicado para resolver problemas reais e melhorar a segurança e conformidade dos clusters Kubernetes.
-
-5. **Dicas de Uso e Melhores Práticas:** Orientações sobre como aproveitar ao máximo o Kyverno, incluindo dicas de segurança, eficiência e automatização de processos.
-
-Ao final deste e-book, você terá uma compreensão abrangente do Kyverno e estará equipado com o conhecimento e as habilidades para implementá-lo efetivamente em seus próprios clusters Kubernetes. Este e-book é projetado tanto para iniciantes quanto para profissionais experientes, proporcionando informações valiosas e práticas para todos os níveis de expertise.
+# Simplificando Kubernetes
+
+## Día 13: Simplificando Kyverno y las Policies en Kubernetes
+
+## Contenido del Día 13
+
+- [Simplificando Kubernetes](#simplificando-kubernetes)
+  - [Día 13: Simplificando Kyverno y las Policies en Kubernetes](#día-13-simplificando-kyverno-y-las-policies-en-kubernetes)
+  - [Contenido del Día 13](#contenido-del-día-13)
+  - [¿Qué veremos hoy?](#qué-veremos-hoy)
+  - [Comienzo del Día 13](#comienzo-del-día-13)
+    - [Introducción a Kyverno](#introducción-a-kyverno)
+    - [Instalación de Kyverno](#instalación-de-kyverno)
+      - [Usando Helm](#usando-helm)
+    - [Verificación de la Instalación](#verificación-de-la-instalación)
+    - [Creación de nuestra primera política](#creación-de-nuestra-primera-política)
+      - [Ejemplo de Política: Agregar Etiqueta al Namespace](#ejemplo-de-política-agregar-etiqueta-al-namespace)
+        - [Detalles de la Política: Agregar Etiqueta al Namespace](#detalles-de-la-política-agregar-etiqueta-al-namespace)
+        - [Archivo de Política: `add-label-namespace.yaml`](#archivo-de-política-add-label-namespaceyaml)
+        - [Uso de la Política: Agregar Etiqueta al Namespace](#uso-de-la-política-agregar-etiqueta-al-namespace)
+      - [Ejemplo de Política: Prohibir Usuario Root](#ejemplo-de-política-prohibir-usuario-root)
+        - [Detalles de la Política: Prohibir Usuario Root](#detalles-de-la-política-prohibir-usuario-root)
+        - [Archivo de la Política: `disallow-root-user.yaml`](#archivo-de-la-política-disallow-root-useryaml)
+        - [Implementación y Efecto](#implementación-y-efecto)
+      - [Ejemplo de Política: Generar ConfigMap para Namespace](#ejemplo-de-política-generar-configmap-para-namespace)
+        - [Detalles de la Política: Generar ConfigMap para Namespace](#detalles-de-la-política-generar-configmap-para-namespace)
+        - [Archivo de Política: `generar-configmap-para-namespace.yaml`](#archivo-de-política-generar-configmap-para-namespaceyaml)
+        - [Implementación y Utilidad](#implementación-y-utilidad)
+      - [Ejemplo de Política: Permitir Solo Repositorios de Confianza](#ejemplo-de-política-permitir-solo-repositorios-de-confianza)
+        - [Detalles de la Política: Permitir Solo Repositorios de Confianza](#detalles-de-la-política-permitir-solo-repositorios-de-confianza)
+        - [Archivo de Política: `repositorio-permitido.yaml`](#archivo-de-política-repositorio-permitidoyaml)
+        - [Implementación e Impacto](#implementación-e-impacto)
+        - [Ejemplo de Política: Require Probes](#ejemplo-de-política-require-probes)
+        - [Detalles de la Política: Require Probes](#detalles-de-la-política-require-probes)
+        - [Archivo de Política: `require-probes.yaml`](#archivo-de-política-require-probesyaml)
+        - [Implementación e Impacto: Require Probes](#implementación-e-impacto-require-probes)
+      - [Ejemplo de Política: Uso del Exclude](#ejemplo-de-política-uso-del-exclude)
+        - [Detalles de la Política: Uso del Exclude](#detalles-de-la-política-uso-del-exclude)
+        - [Archivo de Política](#archivo-de-política)
+        - [Implementación y Efectos: Uso del Exclude](#implementación-y-efectos-uso-del-exclude)
+    - [Conclusión](#conclusión)
+      - [Puntos Clave Aprendidos](#puntos-clave-aprendidos)
+
+## ¿Qué veremos hoy?
+
+Hoy, exploraremos las funcionalidades y aplicaciones de Kyverno, una herramienta de gestión de políticas esencial para la seguridad y eficiencia de los clústeres Kubernetes. Con un enfoque detallado y práctico, aprenderás a utilizar Kyverno para automatizar tareas críticas, garantizar el cumplimiento de normativas y reglas establecidas, y mejorar la administración general de tus entornos Kubernetes.
+
+**Principales temas tratados:**
+
+1. **Introducción a Kyverno:** Una visión general de Kyverno, destacando su importancia y las principales funciones de validación, mutación y generación de recursos.
+
+2. **Instalación y configuración:** Un paso a paso para la instalación de Kyverno, incluyendo métodos que utilizan Helm y archivos YAML, y cómo verificar si la instalación se realizó con éxito.
+
+3. **Desarrollo de políticas eficientes:** Aprenderás a crear políticas para diferentes escenarios, desde la garantía de límites de CPU y memoria en los Pods hasta la aplicación automática de etiquetas en espacios de nombres y la restricción de la ejecución de contenedores como root.
+
+4. **Ejemplos prácticos:** Varios ejemplos de políticas que ilustran cómo Kyverno se puede aplicar para resolver problemas reales y mejorar la seguridad y el cumplimiento en los clústeres Kubernetes.
+
+5. **Consejos de uso y mejores prácticas:** Orientaciones sobre cómo aprovechar al máximo Kyverno, incluyendo consejos de seguridad, eficiencia y automatización de procesos.
+
+Al final de este libro electrónico, tendrás una comprensión completa de Kyverno y estarás preparado con el conocimiento y las habilidades necesarias para implementarlo de manera efectiva en tus propios clústeres Kubernetes. Este libro electrónico está diseñado tanto para principiantes como para profesionales experimentados, proporcionando información valiosa y práctica para todos los niveles de experiencia.
 
 ---
 
-## Inicio do Day-13
+## Comienzo del Día 13
 
-### Introdução ao Kyverno
+### Introducción a Kyverno
 
-Kyverno é uma ferramenta de gerenciamento de políticas para Kubernetes, focada na automação de várias tarefas relacionadas à segurança e configuração dos clusters de Kubernetes. Ele permite que você defina, gerencie e aplique políticas de forma declarativa para garantir que os clusters e suas cargas de trabalho estejam em conformidade com as regras e normas definidas.
+Kyverno es una herramienta de gestión de políticas para Kubernetes que se enfoca en la automatización de diversas tareas relacionadas con la seguridad y configuración de los clústeres de Kubernetes. Permite definir, administrar y aplicar políticas de manera declarativa para garantizar que los clústeres y sus cargas de trabajo cumplan con las reglas y normativas establecidas.
 
-**Principais Funções do Kyverno:**
+**Principales funciones de Kyverno:**
 
-1. **Validação de Recursos:** Verifica se os recursos do Kubernetes estão em conformidade com as políticas definidas. Por exemplo, pode garantir que todos os Pods tenham limites de CPU e memória definidos.
+1. **Validación de recursos:** Verifica si los recursos de Kubernetes cumplen con las políticas definidas. Por ejemplo, puede asegurarse de que todos los Pods tengan límites de CPU y memoria definidos.
 
-2. **Mutação de Recursos:** Modifica automaticamente os recursos do Kubernetes para atender às políticas definidas. Por exemplo, pode adicionar automaticamente labels específicos a todos os novos Pods.
+2. **Mutación de recursos:** Modifica automáticamente los recursos de Kubernetes para cumplir con las políticas definidas. Por ejemplo, puede agregar automáticamente etiquetas específicas a todos los nuevos Pods.
 
-3. **Geração de Recursos:** Cria recursos adicionais do Kubernetes com base nas políticas definidas. Por exemplo, pode gerar NetworkPolicies para cada novo Namespace criado.
+3. **Generación de recursos:** Crea recursos adicionales de Kubernetes en función de las políticas definidas. Por ejemplo, puede generar NetworkPolicies para cada nuevo espacio de nombres creado.
 
 ---
 
-### Instalando o Kyverno
-  
-A instalação do Kyverno em um cluster Kubernetes pode ser feita de várias maneiras, incluindo a utilização de um gerenciador de pacotes como o Helm, ou diretamente através de arquivos YAML. Aqui estão os passos básicos para instalar o Kyverno:
+### Instalación de Kyverno
 
-#### Utilizando Helm
+La instalación de Kyverno en un clúster Kubernetes se puede realizar de varias maneras, incluyendo el uso de un gestor de paquetes como Helm o directamente a través de archivos YAML. Aquí están los pasos básicos para instalar Kyverno:
 
-O Helm é um gerenciador de pacotes para Kubernetes, que facilita a instalação e gerenciamento de aplicações. Para instalar o Kyverno com Helm, siga estes passos:
+#### Usando Helm
+
+Helm es un gestor de paquetes para Kubernetes que facilita la instalación y gestión de aplicaciones. Para instalar Kyverno con Helm, siga estos pasos:
+
+1. **Agregar el Repositorio de Kyverno:**
 
-1. **Adicione o Repositório do Kyverno:**
-   
    ```shell
    helm repo add kyverno https://kyverno.github.io/kyverno/
    helm repo update
    ```
 
-2. **Instale o Kyverno:**
-   
-   Você pode instalar o Kyverno no namespace `kyverno` usando o seguinte comando:
+2. **Instalar Kyverno:**
+
+   Puede instalar Kyverno en el espacio de nombres `kyverno` utilizando el siguiente comando:
 
    ```shell
    helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
    ```
 
-### Verificando a Instalação
+### Verificación de la Instalación
 
-Após a instalação, é importante verificar se o Kyverno foi instalado corretamente e está funcionando como esperado.
+Después de la instalación, es importante verificar si Kyverno se ha instalado correctamente y está funcionando según lo esperado.
 
-- **Verifique os Pods:**
+- **Verificar los Pods:**
 
   ```shell
   kubectl get pods -n kyverno
   ```
 
-  Este comando deve mostrar os pods do Kyverno em execução no namespace especificado.
+  Este comando debería mostrar los Pods de Kyverno en ejecución en el espacio de nombres especificado.
 
-- **Verifique os CRDs:**
+- **Verificar los CRDs:**
 
   ```shell
   kubectl get crd | grep kyverno
   ```
 
-  Este comando deve listar os CRDs relacionados ao Kyverno, indicando que foram criados corretamente.
+  Este comando debería listar los CRDs relacionados con Kyverno, indicando que se han creado correctamente.
 
-Lembrando que é sempre importante consultar a documentação oficial para obter as instruções mais atualizadas e detalhadas, especialmente se estiver trabalhando com uma configuração específica ou uma versão mais recente do Kyverno ou do Kubernetes.
+Recuerde que siempre es importante consultar la documentación oficial para obtener las instrucciones más actualizadas y detalladas, especialmente si está trabajando con una configuración específica o una versión más reciente de Kyverno o Kubernetes.
 
 ---
 
-### Criando a nossa primeira Policy
+### Creación de nuestra primera política
 
-Kyverno permite que você defina, gerencie e aplique políticas de forma declarativa para garantir que os clusters e suas cargas de trabalho estejam em conformidade com as regras e normas definidas.
+Kyverno permite definir, administrar y aplicar políticas de manera declarativa para garantizar que los clústeres y sus cargas de trabajo cumplan con las reglas y normas establecidas.
 
-As políticas, ou as policies em inglês, do Kyverno podem ser aplicadas de duas maneiras principais: a nível de cluster (`ClusterPolicy`) ou a nível de namespace específico (`Policy`).
+Las políticas, o "policies" en inglés, de Kyverno se pueden aplicar de dos formas principales: a nivel de clúster (`ClusterPolicy`) o a nivel de un namespace específico (`Policy`).
 
-1. **ClusterPolicy**: Quando você define uma política como `ClusterPolicy`, ela é aplicada a todos os namespaces no cluster. Ou seja, as regras definidas em uma `ClusterPolicy` são automaticamente aplicadas a todos os recursos correspondentes em todos os namespaces, a menos que especificamente excluídos.
+1. **ClusterPolicy**: Cuando se define una política como `ClusterPolicy`, se aplica a todos los namespaces en el clúster. Esto significa que las reglas definidas en una `ClusterPolicy` se aplican automáticamente a todos los recursos correspondientes en todos los namespaces, a menos que se excluyan específicamente.
 
-2. **Policy**: Se você deseja aplicar políticas a um namespace específico, você usaria o tipo `Policy`. As políticas definidas como `Policy` são aplicadas apenas dentro do namespace onde são criadas.
+2. **Policy**: Si desea aplicar políticas a un namespace específico, debe utilizar el tipo `Policy`. Las políticas definidas como `Policy` se aplican solo dentro del namespace en el que se crean.
 
-Se você não especificar nenhum namespace na política ou usar `ClusterPolicy`, o Kyverno assumirá que a política deve ser aplicada globalmente, ou seja, em todos os namespaces.
+Si no especifica ningún namespace en la política o utiliza `ClusterPolicy`, Kyverno asumirá que la política debe aplicarse de forma global, es decir, en todos los namespaces.
 
 ---
 
-**Exemplo de Políticas do Kyverno:**
+**Ejemplo de Política de Kyverno:**
 
-1. **Política de Limites de Recursos:** Garantir que todos os containers em um Pod tenham limites de CPU e memória definidos. Isso pode ser importante para evitar o uso excessivo de recursos em um cluster compartilhado.
+1. **Política de Límites de Recursos:** Asegurar que todos los contenedores en un Pod tengan límites de CPU y memoria definidos. Esto puede ser importante para evitar el uso excesivo de recursos en un clúster compartido.
 
-**Arquivo `require-resources-limits.yaml`:**
+**Archivo `require-resources-limits.yaml`:**
    ```yaml
    apiVersion: kyverno.io/v1
    kind: ClusterPolicy
@@ -168,48 +168,50 @@ Se você não especificar nenhum namespace na política ou usar `ClusterPolicy`,
                    cpu: "?*"
    ```
 
-
-Depois do arquivo criado, agora bastar realizar o deploy em nosso cluster Kubernetes.
+Después de crear el archivo, ahora solo tienes que implementarlo en tu clúster de Kubernetes.
 
 ```bash
 kubectl apply -f require-resources-limits.yaml
 ```
 
-Agora, tenta realizar o deploy de um simples Nginx sem definir o limite para os recursos.
+Ahora, intenta implementar un simple Nginx sin definir límites para los recursos.
+
+**Archivo `pod.yaml`:**
 
-**Arquivo `pod.yaml`:**
 ```bash
 apiVersion: v1
 kind: Pod
 metadata:
-  name: exemplo-pod
+  name: ejemplo-pod
 spec:
   containers:
-  - name: exemplo-container
+  - name: ejemplo-container
     image: nginx
 ```
 
 ```bash
 kubectl apply -f pod.yaml
 ```
+
 ---
 
-### Mais exemplos de Policies
-Continuando com a explicação e exemplos de políticas do Kyverno para gerenciamento de clusters Kubernetes:
+**Más ejemplos de políticas**
+
+Continuando con la explicación y ejemplos de políticas de Kyverno para la gestión de clústeres de Kubernetes:
 
-Entendi, vou formatar o texto para que esteja pronto para ser copiado para o Google Docs:
+Entiendo, voy a formatear el texto para que esté listo para copiar en Google Docs:
 
 ---
 
-#### Exemplo de Política: Adicionar Label ao Namespace
+#### Ejemplo de Política: Agregar Etiqueta al Namespace
 
-A política `add-label-namespace` é projetada para automatizar a adição de um label específico a todos os Namespaces em um cluster Kubernetes. Esta abordagem é essencial para a organização, monitoramento e controle de acesso em ambientes complexos.
+La política `add-label-namespace` está diseñada para automatizar la adición de una etiqueta específica a todos los Namespaces en un clúster de Kubernetes. Este enfoque es fundamental para la organización, monitorización y control de acceso en entornos complejos.
 
-##### Detalhes da Política
+##### Detalles de la Política: Agregar Etiqueta al Namespace
 
-O label adicionado por esta política é `Jeferson: "Lindo_Demais"`. A aplicação deste label a todos os Namespaces facilita a identificação e a categorização dos mesmos, permitindo uma gestão mais eficiente e uma padronização no uso de labels.
+La etiqueta agregada por esta política es `Jeferson: "Lindo_Demais"`. La aplicación de esta etiqueta a todos los Namespaces facilita la identificación y categorización de los mismos, permitiendo una gestión más eficiente y una estandarización en el uso de etiquetas.
 
-##### Arquivo de Política: `add-label-namespace.yaml`
+##### Archivo de Política: `add-label-namespace.yaml`
 
 ```yaml
 apiVersion: kyverno.io/v1
@@ -230,21 +232,21 @@ spec:
             Jeferson: "Lindo_Demais"
 ```
 
-##### Utilização da Política
+##### Uso de la Política: Agregar Etiqueta al Namespace
 
-Esta política garante que cada Namespace no cluster seja automaticamente etiquetado com `Jeferson: "Lindo_Demais"`. Isso é particularmente útil para garantir a conformidade e a uniformidade na atribuição de labels, facilitando operações como filtragem e busca de Namespaces com base em critérios específicos.
+Esta política garantiza que cada Namespace en el clúster sea etiquetado automáticamente con `Jeferson: "Lindo_Demais"`. Esto es especialmente útil para garantizar la conformidad y uniformidad en la asignación de etiquetas, facilitando operaciones como la filtración y búsqueda de Namespaces basados en criterios específicos.
 
 ---
 
-#### Exemplo de Política: Proibir Usuário Root
+#### Ejemplo de Política: Prohibir Usuario Root
 
-A política `disallow-root-user` é uma regra de segurança crítica no gerenciamento de clusters Kubernetes. Ela proíbe a execução de containers como usuário root dentro de Pods. Este controle ajuda a prevenir possíveis vulnerabilidades de segurança e a reforçar as melhores práticas no ambiente de contêineres.
+La política `disallow-root-user` es una regla de seguridad crítica en la gestión de clústeres de Kubernetes. Prohíbe la ejecución de contenedores como usuario root dentro de Pods. Este control ayuda a prevenir posibles vulnerabilidades de seguridad y refuerza las mejores prácticas en el entorno de contenedores.
 
-##### Detalhes da Política
+##### Detalles de la Política: Prohibir Usuario Root
 
-O principal objetivo desta política é garantir que nenhum Pod no cluster execute containers como o usuário root. A execução de containers como root pode expor o sistema a riscos de segurança, incluindo acessos não autorizados e potenciais danos ao sistema host.
+El principal objetivo de esta política es garantizar que ningún Pod en el clúster ejecute contenedores como usuario root. La ejecución de contenedores como root puede exponer el sistema a riesgos de seguridad, incluyendo accesos no autorizados y posibles daños al sistema host.
 
-##### Arquivo de Política: `disallow-root-user.yaml`
+##### Archivo de la Política: `disallow-root-user.yaml`
 
 ```yaml
 apiVersion: kyverno.io/v1
@@ -252,7 +254,7 @@ kind: ClusterPolicy
 metadata:
   name: disallow-root-user
 spec:
-  validationFailureAction: Enforce
+  validationFailureAction: enforce
   rules:
   - name: check-runAsNonRoot
     match:
@@ -268,59 +270,59 @@ spec:
               runAsNonRoot: true
 ```
 
-##### Implementação e Efeito
+##### Implementación y Efecto
 
-Ao aplicar esta política, todos os Pods que tentarem executar containers como usuário root serão impedidos, com a exibição de uma mensagem de erro indicando que a execução como root não é permitida. Isso assegura uma camada adicional de segurança no ambiente Kubernetes, evitando práticas que possam comprometer a integridade e a segurança do cluster.
+Al aplicar esta política, se bloqueará la ejecución de todos los Pods que intenten ejecutar contenedores como usuario root. Se mostrará un mensaje de error que indica que no se permite la ejecución como root. Esto asegura una capa adicional de seguridad en el entorno de Kubernetes, evitando prácticas que puedan comprometer la integridad y la seguridad del clúster.
 
 ---
 
-#### Exemplo de Política: Gerar ConfigMap para Namespace
+#### Ejemplo de Política: Generar ConfigMap para Namespace
 
-A política `generate-configmap-for-namespace` é uma estratégia prática no gerenciamento de Kubernetes para automatizar a criação de ConfigMaps em Namespaces. Esta política simplifica a configuração e a gestão de múltiplos ambientes dentro de um cluster.
+La política `generar-configmap-para-namespace` es una estrategia práctica en la gestión de Kubernetes para automatizar la creación de ConfigMaps en Namespaces. Esta política simplifica la configuración y administración de múltiples entornos dentro de un clúster.
 
-##### Detalhes da Política
+##### Detalles de la Política: Generar ConfigMap para Namespace
 
-Esta política é projetada para criar automaticamente um ConfigMap em cada Namespace recém-criado. O ConfigMap gerado, denominado `default-configmap`, inclui um conjunto padrão de chaves e valores, facilitando a configuração inicial e a padronização dos Namespaces.
+Esta política está diseñada para crear automáticamente un ConfigMap en cada Namespace recién creado. El ConfigMap generado, denominado `configmap-por-defecto`, incluye un conjunto estándar de claves y valores, lo que facilita la configuración inicial y la estandarización de los Namespaces.
 
-##### Arquivo de Política: `generate-configmap-for-namespace.yaml`
+##### Archivo de Política: `generar-configmap-para-namespace.yaml`
 
 ```yaml
 apiVersion: kyverno.io/v1
 kind: ClusterPolicy
 metadata:
-  name: generate-configmap-for-namespace
+  name: generar-configmap-para-namespace
 spec:
   rules:
-    - name: generate-namespace-configmap
+    - name: generar-configmap-namespace
       match:
         resources:
           kinds:
             - Namespace
       generate:
         kind: ConfigMap
-        name: default-configmap
+        name: configmap-por-defecto
         namespace: "{{request.object.metadata.name}}"
         data:
-          data:
-            key1: "value1"
-            key2: "value2"
+          datos:
+            clave1: "valor1"
+            clave2: "valor2"
 ```
 
-##### Implementação e Utilidade
+##### Implementación y Utilidad
 
-A aplicação desta política resulta na criação automática de um ConfigMap padrão em cada Namespace novo, proporcionando uma forma rápida e eficiente de distribuir configurações comuns e informações essenciais. Isso é particularmente útil em cenários onde a consistência e a automatização de configurações são cruciais.
+La aplicación de esta política resulta en la creación automática de un ConfigMap por defecto en cada Namespace nuevo, lo que proporciona una forma rápida y eficiente de distribuir configuraciones comunes e información esencial. Esto es particularmente útil en escenarios donde la consistencia y la automatización de las configuraciones son cruciales.
 
 ---
 
-#### Exemplo de Política: Permitir Apenas Repositórios Confiáveis
+#### Ejemplo de Política: Permitir Solo Repositorios de Confianza
 
-A política `ensure-images-from-trusted-repo` é essencial para a segurança dos clusters Kubernetes, garantindo que todos os Pods utilizem imagens provenientes apenas de repositórios confiáveis. Esta política ajuda a prevenir a execução de imagens não verificadas ou potencialmente mal-intencionadas.
+La política `asegurar-imagenes-de-repositorio-confiable` es esencial para la seguridad de los clústeres de Kubernetes, garantizando que todos los Pods utilicen imágenes solo de repositorios de confianza. Esta política ayuda a prevenir la ejecución de imágenes no verificadas o potencialmente maliciosas.
 
-##### Detalhes da Política
+##### Detalles de la Política: Permitir Solo Repositorios de Confianza
 
-Esta política impõe que todas as imagens de containers usadas nos Pods devem ser originárias de repositórios especificados e confiáveis. A estratégia é crucial para manter a integridade e a segurança do ambiente de containers, evitando riscos associados a imagens desconhecidas ou não autorizadas.
+Esta política impone que todas las imágenes de contenedores utilizadas en los Pods deben provenir de repositorios especificados y de confianza. Esta estrategia es crucial para mantener la integridad y la seguridad del entorno de contenedores, evitando riesgos asociados con imágenes desconocidas o no autorizadas.
 
-##### Arquivo de Política: `registry-allowed.yaml`
+##### Archivo de Política: `repositorio-permitido.yaml`
 
 ```yaml
 apiVersion: kyverno.io/v1
@@ -344,21 +346,21 @@ spec:
             image: "trustedrepo.com/*"
 ```
 
-##### Implementação e Impacto
+##### Implementación e Impacto
 
-Com a implementação desta política, qualquer tentativa de implantar um Pod com uma imagem de um repositório não confiável será bloqueada. A política assegura que apenas imagens de fontes aprovadas sejam usadas, fortalecendo a segurança do cluster contra vulnerabilidades e ataques externos.
+Con la implementación de esta política, cualquier intento de implementar un Pod con una imagen de un repositorio no confiable será bloqueado. La política garantiza que solo se utilicen imágenes de fuentes aprobadas, fortaleciendo la seguridad del clúster contra vulnerabilidades y ataques externos.
 
 ---
 
-##### Exemplo de Política: Require Probes
+##### Ejemplo de Política: Require Probes
 
-A política `require-readinessprobe` desempenha um papel crucial no gerenciamento de tráfego e na garantia da disponibilidade de serviços em um cluster Kubernetes. Ela exige que todos os Pods tenham uma sonda de prontidão (readiness probe) configurada, assegurando que o tráfego seja direcionado para os Pods apenas quando estiverem prontos para processar solicitações.
+La política `require-readinessprobe` desempeña un papel crucial en la gestión del tráfico y garantiza la disponibilidad de los servicios en un clúster de Kubernetes. Exige que todos los Pods tengan una sonda de preparación (readiness probe) configurada, asegurando que el tráfico se dirija a los Pods solo cuando estén listos para procesar solicitudes.
 
-##### Detalhes da Política
+##### Detalles de la Política: Require Probes
 
-Esta política visa melhorar a confiabilidade e eficiência dos serviços executados no cluster, garantindo que os Pods estejam prontos para receber tráfego antes de serem expostos a solicitações externas. A sonda de prontidão verifica se o Pod está pronto para atender às solicitações, ajudando a evitar interrupções e problemas de desempenho.
+Esta política tiene como objetivo mejorar la confiabilidad y eficiencia de los servicios que se ejecutan en el clúster, garantizando que los Pods estén listos para recibir tráfico antes de exponerse a solicitudes externas. La sonda de preparación verifica si el Pod está listo para atender las solicitudes, lo que ayuda a evitar interrupciones y problemas de rendimiento.
 
-##### Arquivo de Política: `require-probes.yaml`
+##### Archivo de Política: `require-probes.yaml`
 
 ```yaml
 apiVersion: kyverno.io/v1
@@ -384,31 +386,31 @@ spec:
                     port: 8080
 ```
 
-##### Implementação e Impacto
+##### Implementación e Impacto: Require Probes
 
-Com a aplicação desta política, todos os novos Pods ou Pods atualizados devem incluir uma configuração de sonda de prontidão, que normalmente envolve a especificação de um caminho e porta para checagem HTTP. Isso assegura que o serviço só receba tráfego quando estiver totalmente operacional, melhorando a confiabilidade e a experiência do usuário.
+Con la aplicación de esta política, todos los nuevos Pods o Pods actualizados deben incluir una configuración de sonda de preparación, que normalmente implica especificar una ruta y un puerto para la verificación HTTP. Esto asegura que el servicio solo reciba tráfico cuando esté completamente operativo, mejorando la confiabilidad y la experiencia del usuario.
 
 ---
 
-#### Exemplo de Política: Usando o Exclude
+#### Ejemplo de Política: Uso del Exclude
 
-A política `require-resources-limits` é uma abordagem proativa para gerenciar a utilização de recursos em um cluster Kubernetes. Ela garante que todos os Pods tenham limites de recursos definidos, como CPU e memória, mas com uma exceção específica para um namespace.
+La política `require-resources-limits` es un enfoque proactivo para administrar el uso de recursos en un clúster de Kubernetes. Asegura que todos los Pods tengan límites de recursos definidos, como CPU y memoria, pero con una excepción específica para un namespace.
 
-##### Detalhes da Política
+##### Detalles de la Política: Uso del Exclude
 
-Essa política impõe que cada Pod no cluster tenha limites explícitos de CPU e memória configurados. Isso é crucial para evitar o consumo excessivo de recursos, que pode afetar outros Pods e a estabilidade geral do cluster. No entanto, esta política exclui especificamente o namespace `giropops` desta regra.
+Esta política impone que cada Pod en el clúster tenga límites explícitos de CPU y memoria configurados. Esto es fundamental para evitar el uso excesivo de recursos, que puede afectar a otros Pods y la estabilidad general del clúster. Sin embargo, esta política excluye específicamente el namespace `giropops` de esta regla.
 
-##### Arquivo de Política
+##### Archivo de Política
 
 ```yaml
 apiVersion: kyverno.io/v1
 kind: ClusterPolicy
 metadata:
-  name: require-resources-limits
+  name: requerir-recursos-limites
 spec:
   validationFailureAction: Enforce
   rules:
-  - name: validate-limits
+  - name: validar-limites
     match:
       resources:
         kinds:
@@ -418,7 +420,7 @@ spec:
         namespaces:
         - giropops
     validate:
-      message: "Precisa definir o limites de recursos"
+      message: "Debe definir límites de recursos"
       pattern:
         spec:
           containers:
@@ -429,30 +431,28 @@ spec:
                 memory: "?*"
 ```
 
-##### Implementação e Efeitos
+##### Implementación y Efectos: Uso del Exclude
 
-Ao aplicar esta política, todos os Pods novos ou atualizados precisam ter limites de recursos claramente definidos, exceto aqueles no namespace `giropops`. Isso assegura uma melhor gestão de recursos e evita situações onde alguns Pods possam monopolizar recursos em detrimento de outros.
+Al aplicar esta política, todos los Pods nuevos o actualizados deben tener límites de recursos claramente definidos, excepto aquellos en el namespace `giropops`. Esto asegura una mejor gestión de recursos y evita situaciones en las que algunos Pods puedan monopolizar recursos en detrimento de otros.
 
 ---
 
-### Conclusão
-
-Ao longo deste artigo, exploramos as capacidades e funcionalidades do Kyverno, uma ferramenta inovadora e essencial para o gerenciamento de políticas em clusters Kubernetes. Compreendemos como o Kyverno simplifica e automatiza tarefas críticas relacionadas à segurança, conformidade e configuração, tornando-se um componente indispensável na administração de ambientes Kubernetes.
+### Conclusión
 
-#### Pontos-Chave Aprendidos
+A lo largo de este artículo, hemos explorado las capacidades y funcionalidades de Kyverno, una herramienta innovadora e imprescindible para la gestión de políticas en clústeres de Kubernetes. Hemos comprendido cómo Kyverno simplifica y automatiza tareas críticas relacionadas con la seguridad, el cumplimiento y la configuración, convirtiéndose en un componente indispensable en la administración de entornos Kubernetes.
 
-1. **Automação e Conformidade:** Vimos como o Kyverno permite definir, gerenciar e aplicar políticas de forma declarativa, garantindo que os recursos do Kubernetes estejam sempre em conformidade com as regras e normas estabelecidas. Esta abordagem reduz significativamente o esforço manual, minimiza erros e assegura uma maior consistência em todo o ambiente.
+#### Puntos Clave Aprendidos
 
-2. **Validação, Mutação e Geração de Recursos:** Aprendemos sobre as três funções principais do Kyverno – validação, mutação e geração de recursos – e como cada uma delas desempenha um papel vital na gestão eficaz do cluster. Estas funções proporcionam um controle granular sobre os recursos, desde a garantia de limites de CPU e memória até a aplicação automática de labels e a criação dinâmica de ConfigMaps.
+1. **Automatización y Cumplimiento:** Hemos visto cómo Kyverno permite definir, gestionar y aplicar políticas de manera declarativa, garantizando que los recursos de Kubernetes estén siempre en cumplimiento con las reglas y normativas establecidas. Este enfoque reduce significativamente el esfuerzo manual, minimiza los errores y asegura una mayor consistencia en todo el entorno.
 
-3. **Flexibilidade de Políticas:** Discutimos a diferença entre `ClusterPolicy` e `Policy`, destacando como o Kyverno oferece flexibilidade para aplicar políticas em todo o cluster ou em namespaces específicos. Isso permite uma gestão personalizada e adaptada às necessidades de diferentes partes do cluster.
+2. **Validación, Mutación y Generación de Recursos:** Aprendimos sobre las tres funciones principales de Kyverno: validación, mutación y generación de recursos, y cómo cada una de ellas desempeña un papel vital en la gestión efectiva del clúster. Estas funciones proporcionan un control detallado sobre los recursos, desde garantizar límites de CPU y memoria hasta la aplicación automática de etiquetas y la creación dinámica de ConfigMaps.
 
-4. **Instalação e Verificação:** Abordamos as várias maneiras de instalar o Kyverno, com foco especial no uso do Helm, um gerenciador de pacotes popular para Kubernetes. Também exploramos como verificar a instalação correta do Kyverno, assegurando que tudo esteja funcionando conforme esperado.
+3. **Flexibilidad de Políticas:** Discutimos la diferencia entre `ClusterPolicy` y `Policy`, destacando cómo Kyverno ofrece flexibilidad para aplicar políticas en todo el clúster o en espacios de nombres específicos. Esto permite una gestión personalizada y adaptada a las necesidades de diferentes partes del clúster.
 
-5. **Práticas de Segurança:** O artigo enfatizou a importância da segurança em Kubernetes, demonstrada por políticas como a proibição de execução de containers como usuário root e a exigência de imagens provenientes de repositórios confiáveis. Essas políticas ajudam a prevenir vulnerabilidades e garantir a integridade do cluster.
+4. **Instalación y Verificación:** Abordamos las diversas formas de instalar Kyverno, con un enfoque especial en el uso de Helm, un popular gestor de paquetes para Kubernetes. También exploramos cómo verificar la instalación correcta de Kyverno, asegurando que todo funcione según lo esperado.
 
-6. **Automatização e Eficiência:** Por fim, aprendemos como o Kyverno facilita a automatização e a eficiência operacional. As políticas do Kyverno reduzem a necessidade de intervenção manual, aumentam a segurança e ajudam na conformidade regulatória, tornando a administração do Kubernetes mais simples e confiável.
+5. **Prácticas de Seguridad:** El artículo enfatizó la importancia de la seguridad en Kubernetes, demostrada a través de políticas como la prohibición de ejecutar contenedores como usuario root y la exigencia de imágenes provenientes de repositorios de confianza. Estas políticas ayudan a prevenir vulnerabilidades y garantizar la integridad del clúster.
 
-Em resumo, o Kyverno é uma ferramenta poderosa que transforma a maneira como as políticas são gerenciadas em Kubernetes. Seu enfoque na automação, flexibilidade e segurança o torna um componente essencial para qualquer administrador de Kubernetes que deseja otimizar a gestão de clusters, assegurar a conformidade e reforçar a segurança. Com o Kyverno, podemos atingir um nível mais alto de eficiência e confiança nos nossos ambientes Kubernetes, preparando-nos para enfrentar os desafios de um ecossistema em constante evolução.
+6. **Automatización y Eficiencia:** Por último, aprendimos cómo Kyverno facilita la automatización y la eficiencia operativa. Las políticas de Kyverno reducen la necesidad de intervención manual, aumentan la seguridad y ayudan en el cumplimiento normativo, haciendo que la administración de Kubernetes sea más sencilla y confiable.
 
----
\ No newline at end of file
+En resumen, Kyverno es una herramienta poderosa que transforma la forma en que se gestionan las políticas en Kubernetes. Su enfoque en la automatización, la flexibilidad y la seguridad lo convierte en un componente esencial para cualquier administrador de Kubernetes que desee optimizar la gestión de clústeres, garantizar el cumplimiento y fortalecer la seguridad. Con Kyverno, podemos alcanzar un nivel más alto de eficiencia y confiabilidad en nuestros entornos Kubernetes, preparándonos para enfrentar los desafíos de un ecosistema en constante evolución.

From 9b95f13ee2bc3acae8ecf73c4c03d4e65d1e6700 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pedro=20Jorge=20Viana=20de=20Bragan=C3=A7a=20Menezes?=
 <25741145+pedrojorgeviana@users.noreply.github.com>
Date: Sun, 28 Jan 2024 11:24:16 +0100
Subject: [PATCH 8/8] Update Spanish translation Fixes #196

---
 es/day-12/README.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/es/day-12/README.md b/es/day-12/README.md
index 23efae6c..8f7d5716 100644
--- a/es/day-12/README.md
+++ b/es/day-12/README.md
@@ -29,7 +29,6 @@
     - [Conclusión](#conclusión)
     - [Tareas del Día](#tareas-del-día)
   - [DÍA 12+1: Comprendiendo y Dominando los Selectores](#día-121-comprendiendo-y-dominando-los-selectores)
-  - [Contenido del Día-12+1](#contenido-del-día-121)
     - [Introducción 12+1](#introducción-121)
     - [¿Qué son los Selectors?](#qué-son-los-selectors)
     - [Tipos de Selectors](#tipos-de-selectors)
@@ -209,8 +208,6 @@ Taints y Tolerations son herramientas poderosas para un control refinado de la p
 
 ## DÍA 12+1: Comprendiendo y Dominando los Selectores
 
-## Contenido del Día-12+1
-
 ### Introducción 12+1
 
 ¡Hola a todos! En el capítulo de hoy, profundizaremos en uno de los recursos más versátiles y fundamentales de Kubernetes: los Selectores. ¿Están listos? ¡Entonces #VAMOS!