Ir al contenido principal

Implementar Cargas de Trabajo, Servicios e Ingress en Kubernetes.

 

En esta guía, vamos a desplegar aplicaciones en Kubernetes y a exponerlas a través de un controlador de Ingress NGINX, permitiendo así que las aplicaciones sean accesibles desde fuera del clúster de una forma controlada. Este es un paso esencial para cualquier administrador de Kubernetes, ya que permite gestionar el tráfico entrante de forma segura y organizada.


1. Crear Namespaces de Trabajo

Los namespaces en Kubernetes permiten separar recursos en diferentes espacios lógicos, lo que facilita la organización y el control de acceso. Aquí crearemos dos namespaces, workload-a y workload-b, para alojar nuestras aplicaciones.

$ kubectl create ns workload-a namespace/workload-a created $ kubectl create ns workload-b namespace/workload-b created

2. Crear e Implementar los Despliegues y Servicios

A continuación, vamos a desplegar dos aplicaciones básicas (una con httpd y otra con nginx) y a exponerlas mediante servicios de tipo ClusterIP.

Desplegar las aplicaciones y exponerlas como servicios:

$ kubectl create deployment workload-httpd --image=httpd --port=80 -n workload-a deployment.apps/workload-httpd created $ kubectl expose deployment workload-httpd --name service-a --port 6330 --target-port 80 -n workload-a service/service-a exposed $ kubectl create deployment workload-nginx --image=nginx --port=80 -n workload-b deployment.apps/workload-nginx created $ kubectl expose deployment workload-nginx --name service-b --port 6331 --target-port 80 -n workload-b service/service-b exposed
  • Deployment: Define cómo se desplegará una aplicación, especificando la imagen del contenedor y el número de réplicas.
  • Service: Proporciona una forma estable de acceder a los pods, permitiendo el balanceo de carga y la exposición de aplicaciones en el clúster.

Verificar los recursos:

Para asegurarnos de que los despliegues y servicios se han creado correctamente, ejecutamos:

$ kubectl get all -n workload-a $ kubectl get all -n workload-b

Deberías ver que los pods están en estado Running y que los servicios están expuestos en cada namespace. Esto indica que las aplicaciones están listas para recibir tráfico interno.


3. Configurar Recursos Ingress para cada Servicio

Ahora, configuraremos Ingress para que nuestras aplicaciones sean accesibles desde fuera del clúster a través de rutas específicas. Los Ingress en Kubernetes permiten definir reglas de enrutamiento para gestionar el tráfico HTTP/HTTPS de manera centralizada.

1. Crear un recurso Ingress para workload-a:

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-a namespace: workload-a spec: ingressClassName: nginx rules: - http: paths: - path: /base/path-a pathType: Prefix backend: service: name: service-a port: number: 80

Este manifiesto dirige el tráfico que llega al controlador de Ingress con la ruta /base/path-a hacia el servicio service-a en el puerto 80.

Aplicar el manifiesto:

$ kubectl apply -f ingress-a.yaml

2. Crear un recurso Ingress para workload-b:

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-b namespace: workload-b spec: ingressClassName: nginx rules: - http: paths: - path: / pathType: Prefix backend: service: name: service-b port: number: 80

Este manifiesto dirige el tráfico que llega al controlador de Ingress en la raíz (/) hacia el servicio service-b en el puerto 80.

Aplicar el manifiesto:

$ kubectl apply -f ingress-b.yaml

Explicación Adicional:

  • Ingress: Permite exponer varios servicios mediante un único punto de acceso, facilitando la gestión del tráfico HTTP/HTTPS.
  • Ingress Controller: Es el componente que interpreta las reglas del recurso Ingress y gestiona las peticiones entrantes. En este caso, usamos el NGINX Ingress Controller.
  • ingressClassName: Especifica el controlador de Ingress que gestionará las reglas definidas en el recurso.

Importante: Si el recurso Ingress no especifica un ingressClassName o no hay un controlador configurado para manejar las reglas, Kubernetes ignorará el Ingress.


Validar la Configuración del Ingress

Después de configurar los recursos Ingress, es importante verificar que el tráfico se enruta correctamente:

  1. Verificar el estado de los Ingress:

    $ kubectl get ingress -n workload-a $ kubectl get ingress -n workload-b

    Esto debería mostrar que los recursos Ingress están configurados y tienen una dirección IP asignada por el controlador de NGINX.

  2. Probar el acceso a los servicios:

    Si el controlador de Ingress está correctamente configurado, deberías poder acceder a las aplicaciones a través de las siguientes URLs:

    • http://<EXTERNAL-IP>/base/path-a para workload-a
    • http://<EXTERNAL-IP>/ para workload-b

    Reemplaza <EXTERNAL-IP> con la dirección asignada por el controlador de Ingress.


Consideraciones y Mejores Prácticas

  • Usar NGINX Ingress Controller: Es una de las opciones más populares y permite un alto grado de personalización mediante anotaciones.
  • TLS y Seguridad: Es recomendable configurar certificados TLS para el Ingress, lo cual permite cifrar el tráfico HTTP/HTTPS. Esto se puede hacer añadiendo la sección tls al manifiesto del Ingress.
  • Monitorización del Tráfico: Utiliza herramientas como Prometheus y Grafana para visualizar el tráfico que pasa a través de tu controlador de Ingress y asegurar que los servicios están respondiendo correctamente.
  • Pruebas Continuas: Siempre realiza pruebas después de aplicar cambios en las reglas de Ingress para asegurarte de que la configuración cumple con las expectativas.

Conclusión

En este artículo, hemos cubierto cómo crear cargas de trabajo, exponerlas mediante servicios y configurar recursos Ingress para que las aplicaciones sean accesibles desde fuera del clúster. Entender y dominar estos conceptos es fundamental para cualquier administrador de Kubernetes y es clave para quienes se preparan para el examen CKA.

¡Esperamos que este walkthrough te haya sido útil y que te animes a probarlo en tu propio clúster! En los próximos artículos, exploraremos cómo optimizar estas configuraciones para entornos de producción y cómo mejorar la seguridad de tu clúster de Kubernetes.

Comentarios

Entradas populares de este blog

Ubicación, Estructura y Manejo básico de certificados.

                                                     Kubernetes utiliza certificados TLS (X.509) para cifrar la comunicación entre sus componentes y autenticar identidades (usuarios, nodos, API Server, etc.). Estos certificados son generados y gestionados automáticamente cuando se instala un clúster con kubeadm . En este artículo, veremos dónde se almacenan los certificados , cuál es su estructura y cómo inspeccionarlos fácilmente, una habilidad muy útil para el examen CKA. Cuando creas un clúster con kubeadm , los certificados se generan por defecto en el directorio: /etc/ kubernetes /pki/ Puedes ver su contenido con: ls -l /etc/kubernetes/pki/ También hay certificados en: /etc/kubernetes/ (ahí verás admin.conf , kubelet.conf , etc., que incluyen certificados embebidos, como veremos más abajo). 🧱 Estructura de los ce...

🔁 Renovación y Rotación de Certificados en Kubernetes (kubeadm certs)

  🎯 Introducción En un clúster de Kubernetes, la mayoría de los certificados generados por kubeadm tienen una validez de un año . Para evitar interrupciones en los componentes críticos, es fundamental revisar periódicamente su vigencia y saber cómo renovarlos correctamente. En este artículo aprenderás: Cómo comprobar la expiración de los certificados Cómo renovarlos automáticamente con kubeadm Cómo simular una renovación manual con openssl Cómo aplicar los cambios reiniciando los componentes afectados 🕵️‍♂️ Comprobación del estado de los certificados Kubernetes ofrece una herramienta integrada para revisar los certificados del clúster: kubeadm certs check-expiration Este comando muestra información clave: Fecha de expiración Tipo de certificado Ruta en el sistema 📌 Salida de ejemplo: CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY apiserver Jan 06 , 2026 19 :56 UTC 330d ...

TLS Bootstrapping en Kubernetes: Qué es, cómo funciona y por qué importa en el examen CKA

                                                       Uno de los conceptos que a menudo pasan desapercibidos en la administración de Kubernetes —pero que resultan clave tanto en entornos reales como en el examen CKA— es el TLS Bootstrapping . En este artículo entenderás qué es, cómo funciona, qué lo diferencia del kubeadm join tradicional y cómo puede aparecer en el examen. ¿Qué es TLS Bootstrapping? TLS Bootstrapping es el proceso por el cual el kubelet , el agente que corre en cada nodo, obtiene automáticamente un certificado TLS firmado por el clúster para autenticarse con el kube-apiserver . En otras palabras: permite que un nuevo nodo se una de forma segura al clúster sin necesidad de copiar manualmente los certificados. ¿Por qué es necesario? Cuando añades un nuevo nodo worker, su kubelet necesita autentic...