Ok, actualmente tengo kubernetes master funcionando en la instancia de AWS EC2, y un solo trabajador ejecutándose en mi computadora portátil:
$ kubectl get nodes NAME STATUS ROLES AGE VERSION master Ready master 34d v1.9.2 worker Ready <none> 20d v1.9.2He creado un Deployment usando la siguiente configuración:
apiVersion: apps/v1 kind: Deployment metadata: name: hostnames labels: app: hostnames-deployment spec: selector: matchLabels: app: hostnames replicas: 1 template: metadata: labels: app: hostnames spec: containers: - name: hostnames image: k8s.gcr.io/serve_hostname ports: - containerPort: 9376 protocol: TCPLa implementación se está ejecutando:
$ kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE hostnames 1 1 1 1 1mSe ha creado un solo pod en el nodo trabajador:
$ kubectl get pods NAME READY STATUS RESTARTS AGE hostnames-86b6bcdfbc-v8s8l 1/1 Running 0 2mDesde el nodo trabajador, puedo curvar el pod y obtener la información:
$ curl 10.244.8.5:9376 hostnames-86b6bcdfbc-v8s8lHe creado un servicio usando la siguiente configuración:
kind: Service apiVersion: v1 metadata: name: hostnames-service spec: selector: app: hostnames ports: - port: 80 targetPort: 9376El servicio está en funcionamiento:
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hostnames-service ClusterIP 10.97.21.18 <none> 80/TCP 1m kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 34dSegún tengo entendido, el servicio debería exponer el módulo en todo el clúster y debería poder usar la IP del servicio para obtener la información que el módulo está sirviendo desde cualquier nodo del clúster.
Si curvo el servicio desde el nodo trabajador, funciona como se esperaba:
$ curl 10.97.21.18:80 hostnames-86b6bcdfbc-v8s8lPero si intento curvar el servicio desde el nodo maestro ubicado en la instancia de AWS EC2, la solicitud se bloquea y finalmente se agota el tiempo de espera:
$ curl -v 10.97.21.18:80 * Rebuilt URL to: 10.97.21.18:80/ * Trying 10.97.21.18... * connect to 10.97.21.18 port 80 failed: Connection timed out * Failed to connect to 10.97.21.18 port 80: Connection timed out * Closing connection 0 curl: (7) Failed to connect to 10.97.21.18 port 80: Connection timed out¿Por qué la solicitud del nodo principal no puede llegar al pod en el nodo trabajador mediante el servicio Cluster-IP?
He leído bastantes artículos sobre las redes de kubernetes y la documentación oficial de los servicios de kubernetes y no pude encontrar una solución.
Depende de qué modo lo use, funciona de manera diferente en detalles, pero conceptualmente igual.
Intenta conectarse a 2 tipos diferentes de direcciones: la dirección IP del módulo, a la que se puede acceder desde el nodo, y la dirección IP virtual, a la que se puede acceder desde los módulos en el clúster de Kubernetes.
La dirección IP del servicio no es una dirección IP en algún pod o cualquier otro tema, es una dirección virtual que se asignó a la dirección IP de los pods según las reglas que defina en el servicio y administrada por el demonio kube-proxy , que es parte de Kubernetes.
Esa dirección especialmente deseada para la comunicación dentro de un clúster para poder acceder a los pods detrás de un servicio sin importar cuántas réplicas del pod tiene y dónde funciona realmente, porque la IP del servicio es estática, a diferencia de la IP del pod.
Por lo tanto, la dirección IP del servicio deseaba estar disponible desde otro pod, no desde los nodos.
Puede leer en la documentación oficial sobre cómo funciona el Servicio de IP virtuales.
kube-proxy es responsable de configurar las reglas de IPTables (de forma predeterminada) que enrutan las direcciones IP del clúster. La IP del clúster del Servicio debe poder enrutarse desde cualquier lugar que ejecute kube-proxy . Mi primera suposición sería que kube-proxy no se está ejecutando en el maestro.