DevOps desde Cero: Fundamentos de Kubernetes

Introduccion

Bienvenido al articulo once de la serie DevOps from Zero to Hero. En el articulo ocho desplegamos nuestra API TypeScript en AWS ECS con Fargate. ECS es un buen orquestador de contenedores, pero es especifico de AWS. Si queres algo que funcione en cualquier proveedor cloud, en bare metal, o incluso en tu laptop, Kubernetes es la respuesta.

Kubernetes (abreviado como K8s) es el estandar de la industria para orquestacion de contenedores. Es lo que la mayoria de los equipos termina usando cuando necesitan correr contenedores a escala. Tambien es una de esas tecnologias que parecen intimidantes desde afuera, pero tienen mucho sentido una vez que entendes los conceptos principales.

En este articulo vamos a cubrir que es Kubernetes y por que existe, recorrer la arquitectura, aprender cada objeto principal que vas a usar todos los dias, levantar un cluster local con kind, y desplegar un workload real paso a paso. Al final vas a poder leer manifiestos de Kubernetes, ejecutar comandos de kubectl y entender que esta pasando dentro de un cluster.

Vamos a meternos de lleno.

Que es Kubernetes y por que existe?

Imaginate que tenes diez contenedores que necesitan correr en cinco servidores. Algunos necesitan comunicarse entre si. Algunos necesitan mas CPU que otros. Si uno se cae, queres que se reinicie automaticamente. Si el trafico aumenta, queres levantar mas copias. Y queres que todo esto pase sin que te despierten a las 3 AM.

Eso es orquestacion de contenedores, y eso es lo que hace Kubernetes. Toma un conjunto de maquinas, agrupa sus recursos, y te deja declarar que queres corriendo. Kubernetes despues se encarga de decidir donde ubicar cada contenedor, mantener todo saludable, y manejar la red para que los contenedores se encuentren entre si.

Las capacidades principales son:

• Scheduling: Kubernetes decide en que nodo (servidor) corre cada contenedor segun los recursos disponibles.
• Escalado: Le decis a Kubernetes cuantas copias de un contenedor queres. Lo hace. Tambien podes configurar auto-escalado basado en CPU, memoria o metricas custom.
• Auto-recuperacion: Si un contenedor se cae, Kubernetes lo reinicia. Si un nodo se muere, Kubernetes reprograma los contenedores que estaban corriendo ahi en nodos saludables.
• Descubrimiento de servicios y balanceo de carga: Kubernetes le da a cada conjunto de contenedores una identidad de red estable y balancea el trafico entre ellos automaticamente.
• Rolling updates y rollbacks: Podes actualizar tu aplicacion con cero downtime. Si algo sale mal, podes volver a la version anterior con un solo comando.
• Configuracion declarativa: Describis lo que queres en archivos YAML, y Kubernetes trabaja continuamente para que la realidad coincida con tu descripcion. Esto se llama el modelo de “estado deseado”.

Kubernetes fue disenado originalmente por Google, basado en su sistema interno llamado Borg. Fue liberado como open source en 2014 y ahora lo mantiene la Cloud Native Computing Foundation (CNCF). Todos los proveedores cloud importantes ofrecen un servicio de Kubernetes gestionado: EKS en AWS, GKE en Google Cloud, AKS en Azure.

Vision general de la arquitectura

Un cluster de Kubernetes tiene dos tipos de componentes: el plano de control (el cerebro) y los nodos worker (el musculo). Asi encajan:

+-----------------------------------------------------------+
|                     Cluster Kubernetes                     |
|                                                           |
|  +-----------------------------------------------------+  |
|  |                  Plano de Control                    |  |
|  |                                                     |  |
|  |  +--------------+  +-------+  +-----------+         |  |
|  |  |  API Server  |  | etcd  |  | Scheduler |         |  |
|  |  +--------------+  +-------+  +-----------+         |  |
|  |  +--------------------+                             |  |
|  |  | Controller Manager |                             |  |
|  |  +--------------------+                             |  |
|  +-----------------------------------------------------+  |
|                                                           |
|  +------------------------+  +------------------------+   |
|  |     Nodo Worker 1      |  |     Nodo Worker 2      |   |
|  |                        |  |                        |   |
|  |  +--------+ +-------+ |  |  +--------+ +-------+  |   |
|  |  | kubelet| | proxy | |  |  | kubelet| | proxy |  |   |
|  |  +--------+ +-------+ |  |  +--------+ +-------+  |   |
|  |  +------+ +------+    |  |  +------+ +------+     |   |
|  |  | Pod  | | Pod  |    |  |  | Pod  | | Pod  |     |   |
|  |  +------+ +------+    |  |  +------+ +------+     |   |
|  +------------------------+  +------------------------+   |
+-----------------------------------------------------------+

Desglosemos cada componente:

Componentes del plano de control

• API Server (kube-apiserver): La puerta de entrada a tu cluster. Cada comando que ejecutas con kubectl pasa por el API server. Valida requests, actualiza el estado del cluster, y es el unico componente que habla directamente con etcd. Pensalo como la recepcion que maneja todos los pedidos entrantes.
• etcd: Un almacen distribuido de clave-valor que contiene todo el estado de tu cluster. Cada objeto que creas, cada configuracion, cada secreto se guarda aca. Si se pierde etcd y no tenes backup, se pierde el estado de tu cluster. Es la unica fuente de verdad.
• Scheduler (kube-scheduler): Cuando creas un Pod nuevo y todavia no tiene un nodo asignado, el scheduler elige uno. Analiza los requerimientos de recursos, restricciones y capacidad disponible para tomar la mejor decision de ubicacion.
• Controller Manager (kube-controller-manager): Ejecuta un conjunto de controllers que observan el estado del cluster y trabajan para que la realidad coincida con el estado deseado. Por ejemplo, el controller de ReplicaSet asegura que la cantidad correcta de replicas de Pods este corriendo. Si pediste tres replicas y solo hay dos corriendo, crea otra.

Componentes de los nodos worker

• kubelet: Un agente que corre en cada nodo worker. Recibe especificaciones de Pods del API server y se asegura de que los contenedores descritos en esas especificaciones esten corriendo y saludables. Si un contenedor se cae, kubelet lo reinicia.
• kube-proxy: Gestiona reglas de red en cada nodo. Maneja la magia de networking que te permite alcanzar cualquier Pod desde cualquier nodo usando un Service. Configura reglas de iptables (o IPVS, dependiendo de la configuracion) para rutear trafico correctamente.
• Container runtime: El software que realmente corre los contenedores. Kubernetes soporta cualquier runtime que implemente la Container Runtime Interface (CRI). Los mas comunes son containerd y CRI-O. Docker solia ser el default, pero Kubernetes elimino el soporte directo a Docker en la version 1.24 (containerd, que Docker usa internamente, sigue siendo completamente soportado).

Objetos principales: Pods

Un Pod es la unidad desplegable mas chica en Kubernetes. No es un contenedor. Es un wrapper alrededor de uno o mas contenedores que comparten el mismo namespace de red y volumenes de almacenamiento.

La mayoria de las veces un Pod corre un solo contenedor. Pero a veces necesitas un contenedor auxiliar al lado del principal (para logging, proxy o inyeccion de configuracion). Esos se llaman contenedores sidecar, y viven en el mismo Pod.

Los contenedores en el mismo Pod:

• Comparten la misma direccion IP y pueden comunicarse entre si via localhost
• Comparten volumenes de almacenamiento montados en el Pod
• Se programan juntos en el mismo nodo
• Se inician y detienen juntos como una unidad

Aca tenes una definicion simple de Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

Casi nunca creas Pods directamente en produccion. En su lugar, usas un Deployment (que vamos a cubrir a continuacion) que gestiona los Pods por vos. Si creas un Pod directamente y se cae, nada lo va a reiniciar. Un Deployment asegura que los Pods caidos se reemplacen automaticamente.

Objetos principales: Deployments

Un Deployment es la forma mas comun de correr workloads en Kubernetes. Envuelve un template de Pod y agrega funcionalidades de gestion poderosas encima.

Cuando creas un Deployment, le decis a Kubernetes: “Quiero tres replicas de este contenedor, siempre corriendo, y asi es como actualizarlas.” Kubernetes entonces crea un ReplicaSet detras de escena, y el ReplicaSet crea los Pods. La cadena se ve asi:

Deployment
  └── ReplicaSet
        ├── Pod 1
        ├── Pod 2
        └── Pod 3

Aca tenes un manifiesto de Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "250m"

Caracteristicas principales de los Deployments:

• Estado deseado: Declaras cuantas replicas queres. Si un Pod muere, el Deployment crea uno nuevo. Si hay de mas, termina los extras.
• Rolling updates: Cuando cambias la imagen del contenedor, el Deployment reemplaza gradualmente los Pods viejos con nuevos, asegurando cero downtime. Por defecto da de baja como maximo el 25% de los Pods a la vez mientras levanta nuevos.
• Rollback: Cada cambio a un Deployment crea una nueva revision. Si una version nueva esta rota, podes volver a cualquier revision anterior con kubectl rollout undo.
• Escalado: Cambia la cantidad de replicas y Kubernetes se encarga del resto. Escala para arriba o para abajo en cualquier momento.

Objetos principales: Services

Los Pods son efimeros. Se crean, se destruyen y se mueven constantemente. Cada vez que un Pod se recrea, obtiene una nueva direccion IP. Entonces, como hacen otros Pods para encontrar y hablar con tu aplicacion?

Eso es lo que resuelven los Services. Un Service provee un endpoint de red estable (una IP fija y un nombre DNS) que rutea trafico a un conjunto de Pods. Incluso mientras los Pods van y vienen, el Service sigue apuntando a los saludables.

Hay tres tipos principales:

• ClusterIP (default): Crea una direccion IP interna que solo es alcanzable desde dentro del cluster. Esto es lo que usas para comunicacion servicio-a-servicio. Por ejemplo, tu API hablando con tu base de datos.
• NodePort: Expone el servicio en un puerto estatico en cada nodo del cluster. Podes accederlo desde afuera apuntando a la IP de cualquier nodo en ese puerto. Util para desarrollo, pero no ideal para produccion.
• LoadBalancer: Provisiona un balanceador de carga externo (en proveedores cloud). Esta es la forma estandar de exponer un servicio a internet en produccion. En AWS crea un ELB, en GCP un Cloud Load Balancer, y asi.

Aca tenes un Service que expone nuestro Deployment de nginx:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

El campo selector es lo que conecta un Service con sus Pods. El Service busca todos los Pods con la etiqueta app: nginx y rutea trafico hacia ellos. Este es el mecanismo de label-selector y es fundamental para como Kubernetes conecta objetos entre si.

Objetos principales: ConfigMaps y Secrets

Las aplicaciones necesitan configuracion: URLs de bases de datos, feature flags, API keys. Hardcodear estos valores en tu imagen de contenedor es mala idea porque tendrias que reconstruir la imagen para cada entorno.

Kubernetes resuelve esto con ConfigMaps y Secrets:

• ConfigMap: Almacena configuracion no sensible como pares clave-valor. Cosas como nombres de entorno, niveles de log y feature flags.
• Secret: Almacena datos sensibles como passwords, tokens y certificados. Los Secrets estan codificados en base64 (no encriptados por defecto, pero podes habilitar encriptacion en reposo). En produccion, usa un gestor de secretos como HashiCorp Vault o AWS Secrets Manager y sincroniza secretos en Kubernetes con un operator.

Aca tenes un ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  APP_ENV: "production"
  MAX_CONNECTIONS: "100"

Y un Secret:

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DATABASE_URL: cG9zdGdyZXM6Ly91c2VyOnBhc3NAaG9zdDo1NDMyL2Ri
  API_KEY: c3VwZXItc2VjcmV0LWtleQ==

Podes inyectar estos en Pods como variables de entorno o montarlos como archivos. Asi es como usar ambos en un Deployment:

spec:
  containers:
    - name: app
      image: my-app:1.0
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets

Objetos principales: Namespaces

Los Namespaces proveen aislamiento logico dentro de un cluster. Son como carpetas para tus objetos de Kubernetes. Diferentes equipos, entornos o aplicaciones pueden tener cada uno su propio namespace.

Cada cluster arranca con algunos namespaces por defecto:

• default: Donde van los objetos si no especificas un namespace.
• kube-system: Donde corren los componentes del sistema de Kubernetes (API server, scheduler, CoreDNS, etc.).
• kube-public: Legible por todos los usuarios, usado para informacion publica del cluster.
• kube-node-lease: Contiene objetos de lease para heartbeats de nodos.

Crear un namespace es simple:

kubectl create namespace staging

O con YAML:

apiVersion: v1
kind: Namespace
metadata:
  name: staging

Despues desplegamos recursos en ese namespace:

kubectl apply -f deployment.yaml -n staging

Los Namespaces tambien son el limite para resource quotas y network policies. Podes limitar cuanta CPU y memoria puede consumir un namespace, y podes controlar que namespaces pueden comunicarse entre si.

Labels y selectors

Los labels son pares clave-valor que se adjuntan a cualquier objeto de Kubernetes. Son el pegamento que conecta diferentes objetos entre si.

metadata:
  labels:
    app: nginx
    environment: production
    team: platform
    version: "1.27"

Los selectors filtran objetos basandose en sus labels. Asi es como un Service encuentra sus Pods, como un Deployment sabe que Pods le pertenecen, y como podes consultar objetos especificos con kubectl:

# Obtener todos los pods con un label especifico
kubectl get pods -l app=nginx

# Obtener pods que coincidan con multiples labels
kubectl get pods -l app=nginx,environment=production

# Obtener pods donde un label exista (cualquier valor)
kubectl get pods -l team

# Obtener pods donde un label NO exista
kubectl get pods -l '!team'

Los labels y selectors no son solo algo bonito. Son como Kubernetes funciona internamente. Si el selector de tu Service no coincide con los labels de tus Pods, el trafico no va a fluir. Si el selector de tu Deployment no coincide con los labels del template de Pod, el Deployment va a rechazar la configuracion.

Requests y limits de recursos

Cada contenedor deberia declarar cuanta CPU y memoria necesita. Sin esto, Kubernetes no tiene idea de como programar Pods eficientemente y corres riesgo de sobrecargar nodos.

Hay dos configuraciones:

• Requests: La cantidad minima de recursos garantizada al contenedor. El scheduler usa los requests para decidir que nodo tiene suficiente lugar para el Pod. Si pedis 256Mi de memoria, Kubernetes va a ubicar el Pod en un nodo que tenga al menos esa cantidad disponible.
• Limits: La cantidad maxima de recursos que un contenedor puede usar. Si un contenedor excede su limite de memoria, Kubernetes lo mata (OOMKilled). Si excede su limite de CPU, se le aplica throttling (se ralentiza pero no se mata).

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "500m"

La CPU se mide en milicores. 100m significa 0.1 nucleos de CPU. 1000m (o simplemente 1) significa un nucleo completo. La memoria usa unidades estandar: Mi (mebibytes), Gi (gibibytes).

Algunas reglas generales:

• Siempre configura requests. Sin ellos, el scheduler esta adivinando.
• Configura limits de memoria para prevenir que contenedores descontrolados crasheen el nodo.
• Cuidado con los limits de CPU. Limits de CPU agresivos causan throttling incluso cuando el nodo tiene CPU libre. Algunos equipos configuran requests de CPU pero no ponen limits de CPU para evitar throttling innecesario.
• Monitoea el uso real y ajusta requests/limits basandote en datos reales, no en suposiciones.

Levantando un cluster local con kind

kind (Kubernetes in Docker) es la forma mas rapida de tener un cluster de Kubernetes local corriendo. Crea un cluster ejecutando nodos de Kubernetes como contenedores Docker. Necesitas Docker instalado y nada mas.

Instalar kind:

# En Linux
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# En macOS (Homebrew)
brew install kind

Crear un cluster:

kind create cluster --name my-cluster

Eso es todo. kind crea un cluster de un solo nodo y configura kubectl para usarlo. Verifica que este corriendo:

kubectl cluster-info --context kind-my-cluster
kubectl get nodes

Deberias ver una salida como esta:

NAME                       STATUS   ROLES           AGE   VERSION
my-cluster-control-plane   Ready    control-plane   45s   v1.32.2

Cuando termines, borra el cluster:

kind delete cluster --name my-cluster

Basicos de kubectl

kubectl es la herramienta de linea de comandos para interactuar con Kubernetes. Aca estan los comandos que vas a usar todos los dias:

# Obtener recursos
kubectl get pods                     # Listar todos los pods en el namespace actual
kubectl get pods -A                  # Listar pods en TODOS los namespaces
kubectl get deployments              # Listar deployments
kubectl get services                 # Listar services
kubectl get all                      # Listar tipos de recursos comunes

# Informacion detallada sobre un recurso
kubectl describe pod my-nginx        # Mostrar eventos, condiciones, contenedores
kubectl describe deployment nginx-deployment

# Ver logs
kubectl logs my-nginx                # Logs de un pod
kubectl logs my-nginx -f             # Transmitir logs (follow)
kubectl logs my-nginx --previous     # Logs del contenedor anterior (despues de un crash)

# Ejecutar comandos dentro de un contenedor
kubectl exec -it my-nginx -- /bin/bash   # Shell interactiva
kubectl exec my-nginx -- cat /etc/nginx/nginx.conf  # Ejecutar un solo comando

# Aplicar y borrar recursos desde archivos
kubectl apply -f deployment.yaml     # Crear o actualizar recursos desde un archivo
kubectl apply -f ./manifests/        # Aplicar todos los archivos de un directorio
kubectl delete -f deployment.yaml    # Borrar recursos definidos en un archivo
kubectl delete pod my-nginx          # Borrar un pod especifico

Algunos tips que te van a ahorrar tiempo:

• Usa -o wide para ver columnas extra como nombre de nodo e IP: kubectl get pods -o wide
• Usa -o yaml para ver la definicion completa del objeto: kubectl get pod my-nginx -o yaml
• Configura un namespace por defecto asi no tenes que escribir -n cada vez: kubectl config set-context --current --namespace=staging
• Usa aliases. La mayoria de los usuarios de Kubernetes aliasen kubectl a k: alias k=kubectl

Ejercicio practico: desplegar, exponer, escalar, actualizar

Pongamos todo junto con un ejercicio practico. Asegurate de tener un cluster kind corriendo.

Paso 1: Crear un Deployment

Crea un archivo llamado nginx-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "50m"
            limits:
              memory: "128Mi"
              cpu: "100m"

Aplicalo:

kubectl apply -f nginx-deployment.yaml

Verifica los resultados:

kubectl get deployments
kubectl get pods

Deberias ver dos Pods corriendo:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-5d8f4d7b9c-abc12   1/1     Running   0          15s
nginx-deployment-5d8f4d7b9c-def34   1/1     Running   0          15s

Paso 2: Exponerlo con un Service

Crea un archivo llamado nginx-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080

Aplicalo:

kubectl apply -f nginx-service.yaml

Verifica el Service:

kubectl get services

NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
nginx-service   NodePort   10.96.45.123   <none>        80:30080/TCP   5s
kubernetes      ClusterIP  10.96.0.1      <none>        443/TCP        10m

Prueba que funcione. Como estamos usando kind, podemos hacer port-forward para acceder al servicio localmente:

kubectl port-forward service/nginx-service 8080:80

Ahora abri otra terminal y hacele un request:

curl http://localhost:8080

Deberias ver el HTML de la pagina de bienvenida de nginx.

Paso 3: Escalar el Deployment

Pasemos de dos replicas a cinco:

kubectl scale deployment nginx-deployment --replicas=5

Mira como se levantan los Pods:

kubectl get pods -w

En segundos vas a tener cinco Pods corriendo. Escalemos para abajo:

kubectl scale deployment nginx-deployment --replicas=2

Kubernetes va a terminar tres Pods de forma graceful.

Paso 4: Hacer un rolling update

Actualicemos de nginx 1.27 a 1.28. Podes editar el archivo YAML y re-aplicar, o hacerlo inline:

kubectl set image deployment/nginx-deployment nginx=nginx:1.28

Mira como pasa el rolling update:

kubectl rollout status deployment/nginx-deployment

Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

Kubernetes creo Pods nuevos con nginx 1.28 y termino los viejos, uno a la vez, con cero downtime.

Revisa el historial de rollout:

kubectl rollout history deployment/nginx-deployment

Si algo sale mal, hace rollback:

kubectl rollout undo deployment/nginx-deployment

Esto revierte a la revision anterior inmediatamente.

Paso 5: Inspeccionar y debuggear

Obtene informacion detallada sobre un Pod:

kubectl describe pod nginx-deployment-<completa-el-nombre-con-tab>

Revisa los logs del contenedor:

kubectl logs deployment/nginx-deployment

Abri una shell dentro de un contenedor corriendo:

kubectl exec -it deployment/nginx-deployment -- /bin/bash

Dentro del contenedor podes inspeccionar archivos, probar conectividad y debuggear problemas directamente.

Paso 6: Limpiar

kubectl delete -f nginx-service.yaml
kubectl delete -f nginx-deployment.yaml

O borra el cluster kind completo:

kind delete cluster --name my-cluster

Notas finales

Kubernetes tiene fama de ser complejo, y es verdad que el ecosistema es masivo. Pero los conceptos principales son directos. Tenes Pods que corren contenedores, Deployments que gestionan Pods, Services que rutean trafico, ConfigMaps y Secrets para configuracion, y Namespaces para aislamiento. Todo se conecta a traves de labels y selectors.

La idea clave es que Kubernetes es un sistema declarativo. Le decis lo que queres, y el trabaja continuamente para que eso pase. No le decis “inicia tres contenedores.” Le decis “quiero tres replicas” y el se encarga de como llegar ahi, ya sea creando Pods nuevos, reiniciando los que se cayeron, o reprogramandolos en otros nodos.

Cubrimos mucho terreno en este articulo. Levanta un cluster kind y jugá. Rompe cosas a proposito. Borra un Pod y mira como el Deployment lo recrea. Cambia los resource limits y ve que pasa. La mejor forma de aprender Kubernetes es usandolo.

En los proximos articulos vamos a construir sobre esta base: desplegando aplicaciones reales a Kubernetes, configurando networking con Ingress controllers, y gestionando todo con Helm charts.

Espero que te haya resultado util y lo hayas disfrutado! Hasta la proxima!

Errata

Si encontras algun error o tenes alguna sugerencia, por favor mandame un mensaje para que se corrija.

Tambien podes revisar el codigo fuente y los cambios en las fuentes aca