Tipos de servicios: ClusterIP, NodePort, LoadBalancer y ExternalName
Clase 10 de 24 • Curso de Kubernetes
Contenido del curso
Clase 10 de 24 • Curso de Kubernetes
Contenido del curso
Jesus Martinez
Jeisson Alejandro Fuquene Buitrago
Juan Moya
Yor Jaggy Castaño Pino
Victor Hugo Paco Flores
Yor Jaggy Castaño Pino
Eduardo Ramírez
Yor Jaggy Castaño Pino
Alvaro Hernandez
José Eduardo Ormeño Meneses
Yor Jaggy Castaño Pino
Luis Boivar
Alex Henrry Naupay Ferrer
Los tipos de servicios en Kubernetes tienen diferentes casos de uso en la nube:
ClusterIP: Ideal para comunicar servicios internos en un clúster. Por ejemplo, microservicios que se comunican entre sí sin exponer tráfico externo.
NodePort: Útil para acceder a un servicio desde fuera del clúster utilizando el puerto de un nodo. Puede ser usado para pruebas rápidas de aplicaciones.
LoadBalancer: Se usa en entornos de producción en la nube (como AWS, GCP, Azure) para distribuir tráfico a múltiples instancias de un servicio. Permite que aplicaciones estén disponibles públicamente.
ExternalName: Facilita la integración con servicios externos, como bases de datos o APIs, al permitir que se utilice un nombre DNS en lugar de una URL directa, simplificando la configuración.
Cada uno de estos servicios optimiza la comunicación y disponibilidad de aplicaciones en la nube.
Cual es la diferencia entre usar un external name o un configmap? Ya que según la explicación, ambos funcionarían para almacenar mi variable de apuntamiento a una base de datos.
Nice Catch Jeisson!
En este caso, un ExternalName no es un servicio que almacene un valor, sino más bien un mecanismo de resolución DNS interna de Kubernetes. Permite crear un alias dentro del clúster que apunta a un nombre de dominio externo, lo cual facilita la integración con servicios fuera del clúster como bases de datos, colas de mensajes o caches.
Aunque Kubernetes no hace caching total del DNS explícitamente, usar ExternalName puede ayudar a centralizar nombres externos y simplificar la gestión de dependencias externas.
Por otro lado, un ConfigMap sí está diseñado para almacenar valores de configuración no sensibles, como nombres de host, puertos o flags de la aplicación.
💡 Mi recomendación:
Usá ExternalName para mapear nombres de servicios internos a recursos externos (como DB, RabbitMQ, ElastiCache, etc.).
Usá ConfigMap para referenciar esos nombres (por ejemplo, el nombre del servicio my-database-service que en realidad es un ExternalName). Así mantenés flexibilidad y separación de responsabilidades.
Esto te ayuda a hacer frente a estos escenarios!
- Si mañana cambiás my-db para que apunte a otro host, lo cambiás solo en el ExternalName.
- Si querés cambiar el nombre de referencia en tu app, lo hacés desde el ConfigMap.
-Esta separación facilita cambios sin necesidad de redesplegar toda la aplicación.
Podrias explicar mejor el uso del EXTERNAL-IP ya sea en el CLUSTER-IP, con casos de ejemplo?
Hola Víctor, claro que si!
El campo EXTERNAL-IP que vemos en la consola (kubectl get svc) cambia según el tipo de servicio que estés usando:
<none>, sí podés acceder externamente usando la IP del nodo (por ejemplo, la IP de Minikube si estás en local). Una forma rápida de abrir el acceso es con minikube service, que realiza un port forwarding hacia el puerto del NodePort.<pending> si todavía no se asignó una IP externa. Si usás minikube tunnel, se asignará una IP real (generalmente de tu red local, como 192.168.x.x o 127.0.0.1) que hace que el servicio sea accesible externamente dentro de tu red o tu equipo.Cuál sería la diferencia entre usar minikube service y minikube tunnel?
Hey Eduardo, excelente pregunta! Para efectos prácticos, ambos comandos permiten exponer servicios localmente, pero lo hacen de formas distintas.
minikube service expone un servicio de manera rápida, ideal para pruebas locales. Funciona con servicios de tipo NodePort y LoadBalancer, y lo logra mediante un port forwarding temporal entre tu computador y la máquina virtual del clúster.
Por otro lado, minikube tunnel permite simular un entorno más parecido al de la nube. Es especialmente útil con servicios de tipo LoadBalancer, ya que les asigna una IP externa "real" (o de tu segmento de red local). Además, también es necesario si estás usando recursos como Ingress, ya que estos suelen depender de un LoadBalancer para que funcione correctamente.
Peroooo, en resumen, ambos son válidos para exponer aplicaciones en local: uno es rápido y directo, el otro es más realista y completo.
Saludos!
En mi caso luego de aplicar el comando minikube service hello-service-clusterip no se inicio el tunel para el servicio. Que pasos deberia hacer para resolver este problema y continuar?
Quizás ya te lo está creando internamente al ser un clusterIp 🤔
En ocasiones minikube puede presentar algunas diferencias entre versiones, nos puedes confirmar que version de minikube tienes instalada porfa 💪
O agregando un flag extra al comando tipo:
minikube service hello-service-clusterip --url
Tambien puedes intentarlo con el port-forward, ejemplo:
kubectl port-forward svc/hello-service-clusterip :80
Me cuentas como te fue 🙏
Excelente clase, esto es fundamental para exponer servicios en la vida real
Si no pueden acceder a la imagen de los ejemplos, pueden usar: image: alexnaupay/nginx-hostname:latest
image: alexnaupay/nginx-hostname:latest