Seguí la guía en el siguiente enlace: http://blog.kubernetes.io/2017/01/running-mongodb-on-kubernetes-with-statefulsets.html
y configure un conjunto de réplicas de mongo DB en Kubernetes con StatefulSets. Hasta ahora todo bien, pero ¿cómo expongo esos nombres de host estáticos fuera del clúster para poder acceder a ellos desde una instancia de Google, por ejemplo?
Si uso las direcciones IP de los nodos, funcionará bien, pero pueden cambiar en cualquier momento (en caso de falla del módulo y reinicio con una dirección IP diferente, etc.)...
¡Gracias por adelantado!
Parece que la respuesta está presente en la sección de documentación de StatefulSet Basics Uso de identidades de red estables :
Los ordinales, los nombres de host, los registros SRV y los nombres de registros A de los pods no han cambiado, pero las direcciones IP asociadas con los pods pueden haber cambiado. En el clúster utilizado para este tutorial, tienen. Por eso es importante no configurar otras aplicaciones para conectarse a Pods en un StatefulSet por dirección IP.
Si necesita encontrar y conectarse a los miembros activos de un StatefulSet, debe consultar el CNAME del Headless Service
(nginx.default.svc.cluster.local). Los registros SRV asociados con el CNAME contendrán solo los pods en StatefulSet que se están ejecutando y listos.Si su aplicación ya implementa una lógica de conexión que prueba la actividad y la preparación, puede usar los registros SRV de los Pods
( web-> 0.nginx.default.svc.cluster.local, web-1.nginx.default.svc.cluster.local), ya que son estables y su aplicación podrá descubrir las direcciones de los Pods cuando pasen a En ejecución y Listo.
Recomiendo encarecidamente echar un vistazo a los documentos de servicio para asegurarse de que está familiarizado con lo que está sucediendo:
https://kubernetes.io/docs/concepts/services-networking/service/
Un servicio de Kubernetes es una abstracción que define un conjunto lógico de pods y una política mediante la cual acceder a ellos, a veces denominado microservicio.
Con eso en mente y la guía que está utilizando, tenga en cuenta lo siguiente:
Puede decir que este es un servicio sin cabeza porque el clusterIP está configurado en "Ninguno". Aparte de eso, se ve exactamente igual que cualquier servicio normal de Kubernetes.
Entonces, lo que ha creado es un servicio sin cabeza (sin equilibrador de carga ni IP expuestas)
Entonces, en lugar de la configuración dada para un servicio sin cabeza:
apiVersion: v1 kind: Service metadata: name: mongo labels: name: mongo spec: ports: - port: 27017 targetPort: 27017 clusterIP: None selector: role: mongoLo que realmente quieres es:
apiVersion: v1 kind: Service metadata: name: mongo labels: name: mongo spec: ports: - protocol: TCP port: 27017 targetPort: 27017 selector: role: mongo Muy sutil, pero notará que la propiedad clusterIP ya no existe.
También prefiero especificar el protocolo, para completar, aunque TCP es el valor predeterminado.
Debe exponer el servicio (svc). El pod, por definición, como dijiste, tendría diferentes IP.
En el ejemplo mencionado en https://kubernetes.io/docs/user-guide/petset/ , notará la definición del servicio.
foo.default.svc.cluster.local |service| / \ | pod-asdf | | pod-zxcv |Esto es en lo que debe concentrarse. El servicio, una vez vinculado a DNS, le brindaría una búsqueda estable. Por cierto, StatefulSets es la maduración de Pet Sets anteriores.