Servicios en Kubernetes: Configuración y Ejemplos Prácticos. Bloque 3. Tema 3.2 del CKA.

 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