En este artículo, exploraremos cómo configurar servicios en Kubernetes para facilitar la comunicación interna dentro de un clúster. Los servicios permiten a los pods comunicarse entre sí y son una parte fundamental en la arquitectura de microservicios. A continuación, veremos cómo crear y exponer servicios, validar su conectividad y utilizar políticas de red para controlar el tráfico.
Creando y Exponiendo Servicios ClusterIP
1. Creación y Exposición de Deployments como Servicios
Para exponer aplicaciones internas, primero creamos los Deployments y luego los convertimos en servicios de tipo ClusterIP, lo cual permite la comunicación interna entre pods:
$ kubectl apply -f cka-netpol-deployments.yaml deployment.apps/cka-netpol-app created deployment.apps/cka-netpol-cache created
Una vez creados los Deployments, los exponemos como servicios ClusterIP:
$ kubectl expose deployment cka-netpol-app -n netpol --port 8080 --target-port 80 service/cka-netpol-app exposed $ kubectl expose deployment cka-netpol-cache -n netpol --port 8080 --target-port 80 service/cka-netpol-cache exposed
Ahora ambos servicios están disponibles en el puerto 8080, redirigiendo el tráfico hacia el puerto 80 de los pods.
2. Verificación de los Servicios
Para asegurarnos de que los servicios se han creado correctamente, utilizamos:
$ kubectl get all -n netpol
Esto debería mostrar que los servicios tienen asignadas ClusterIPs únicas:
NAME READY STATUS IP PORT(S) service/cka-netpol-app ClusterIP 10.111.41.114 8080/TCP service/cka-netpol-cache ClusterIP 10.100.78.122 8080/TCP
3. Consulta de Endpoints
Para verificar a qué pods están asociados los servicios, usamos:
$ kubectl get endpoints -n netpol
Esto mostrará:
NAME ENDPOINTS PORT(S)
cka-netpol-app 192.168.1.3:80 80
cka-netpol-cache 192.168.1.4:80 80
Esto indica que el servicio cka-netpol-app redirige al pod con IP 192.168.1.3, mientras que cka-netpol-cache se conecta a 192.168.1.4.
Validando la Conectividad de los Servicios
1. Pruebas de Conectividad DNS
Podemos usar un pod de prueba para verificar la resolución de nombres DNS:
$ kubectl run test-client -it --restart=Never --rm --image busybox -- /bin/sh
# nslookup cka-netpol-app.netpol.svc.cluster.local
La respuesta debería ser algo como:
Name: cka-netpol-app.netpol.svc.cluster.local
Address: 10.111.41.114
Esto confirma que los nombres de los servicios se resuelven correctamente a las ClusterIP asignadas.
2. Acceso a los Servicios por Nombre
También podemos hacer una petición HTTP para verificar que los servicios responden correctamente:
# wget -O- http://cka-netpol-app.netpol.svc.cluster.local:8080
# wget -O- http://cka-netpol-cache.netpol.svc.cluster.local:8080
Si los servicios están configurados correctamente, deberían devolver respuestas HTML.
Conectividad entre Pods en Kubernetes
Entendiendo la Conectividad entre Pods
En Kubernetes, los contenedores dentro de un mismo pod comparten:
- Dirección IP y Espacio de Nombres de Red: Todos los contenedores de un pod pueden comunicarse entre sí usando
localhost(127.0.0.1). - Espacio de Comunicaciones Inter-Procesos (IPC): Esto facilita la comunicación directa entre los contenedores de un pod.
Conectividad Predeterminada sin Políticas de Red
Por defecto, todos los pods en un clúster de Kubernetes pueden comunicarse entre sí. Esto puede ser útil para pruebas iniciales, pero generalmente no es deseado en entornos de producción.
Controlando el Acceso con Network Policies
Las Network Policies permiten controlar la comunicación entre los pods, definiendo qué tráfico es permitido.
- Ingress: Regula las conexiones entrantes.
- Egress: Regula las conexiones salientes.
Ejemplo de una Política de Denegación Total
Este manifiesto bloquea todo el tráfico de entrada y salida para los pods en el namespace netpol:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cka-netpol-deny-all
namespace: netpol
spec:
podSelector: {} # Afecta a todos los pods
policyTypes:
- Ingress
- Egress
Después de aplicar esta política, ningún pod podrá recibir ni enviar tráfico hasta que se agreguen reglas para permitir conexiones específicas.
Descubrimiento de Servicios en Kubernetes
Entendiendo el Descubrimiento de Servicios
Kubernetes proporciona una forma estable de acceder a los pods a través de Services, que actúan como un punto de acceso usando nombres DNS y una ClusterIP.
- VIPs (Virtual IPs): Cada servicio obtiene una IP virtual estable que redirige el tráfico a los pods.
- kube-proxy: Redirige el tráfico de los servicios a los pods utilizando reglas de iptables o ipvs.
Ejemplo Completo de Network Policies y Control de Acceso
Aplicación de una Política para Permitir Acceso
Después de aplicar una política deny-all, puedes crear una política específica para permitir acceso:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cka-netpol-allow-app
namespace: netpol
spec:
podSelector:
matchLabels:
netpol: app
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: default
ports:
- protocol: TCP
port: 80
Esto permite el tráfico desde el namespace default hacia los pods etiquetados como app.
Verificación de la Política
Usa un pod de prueba para verificar la conectividad:
$ kubectl run test-client -it --restart=Never --rm --image busybox -- /bin/sh
# wget -O- http://cka-netpol-app.netpol.svc.cluster.local:8080
Si la política está bien configurada, el test-client debería poder acceder a cka-netpol-app pero no a otros pods restringidos.
Conclusión
Este artículo ha cubierto cómo exponer aplicaciones internas mediante servicios ClusterIP, validar su conectividad y utilizar Network Policies para gestionar el tráfico. Entender estos conceptos es esencial para administrar de forma efectiva la red en Kubernetes y estar preparado para el examen CKA. ¡No olvides practicar estos ejemplos para afianzar tu conocimiento!
Comentarios
Publicar un comentario