Si es como la mayoría de las personas, probablemente esté utilizando recursos que se ejecutan fuera de su clúster. Quizás utilice la API de Taleo para enviar mensajes de texto o analizar imágenes utilizando la API de Google Cloud Vision.
Si utiliza el mismo punto final de solicitud del lado del servidor en todos sus entornos y no planea migrar sus servidores a Kubernetes, entonces está perfectamente bien tener un punto final de servicio directamente en su código. Sin embargo, existen muchos otros escenarios para el desarrollo de los eventos. En esta serie de mejores prácticas de Kubernetes, aprenderá cómo utilizar los mecanismos integrados de Kubernetes para descubrir servicios tanto dentro como fuera del clúster.
Un ejemplo de un servicio externo común es una base de datos que se ejecuta fuera de un clúster de Kubernetes. A diferencia de las bases de datos en la nube como Google Cloud Data Store o Google Cloud Spanner, que utilizan un único punto final para todos los accesos, la mayoría de las bases de datos tienen puntos finales separados para diferentes circunstancias.
Las mejores prácticas para el uso de bases de datos tradicionales como MySQL y MongoDB generalmente implican conectarse a diferentes componentes para diferentes entornos. Puede tener una máquina grande para los datos de producción y una máquina más pequeña para el entorno de prueba. Cada uno de ellos tendrá su propia dirección IP o nombre de dominio, pero probablemente no querrás cambiar tu código cuando pases de un entorno a otro. Entonces, en lugar de codificar estas direcciones, puede utilizar el descubrimiento de servicios externos integrado basado en DNS de Kubernetes de la misma manera que los servicios nativos de Kubernetes.
Supongamos que está ejecutando una base de datos MongoDB en Google Compute Engine. Estarás atrapado en este mundo híbrido hasta que logres transferirlo al clúster.
Afortunadamente, puedes utilizar los servicios estáticos de Kubernetes para hacerte la vida un poco más fácil. En este ejemplo, creé un servidor MongoDB usando Google Cloud Launcher. Dado que se crea en la misma red (o VPC del clúster de Kubernetes), se accede a él mediante una dirección IP interna de alto rendimiento.
Esta es la configuración predeterminada en Google Cloud, por lo que no es necesario configurar nada. Ahora que tienes una dirección IP, el primer paso es crear un servicio. Es posible que observe que no hay selectores de pods para este servicio. Es decir, creamos un servicio que no sabrá dónde enviar el tráfico. Esto le permitirá crear manualmente un objeto de punto final que recibirá tráfico de este servicio.
El siguiente ejemplo de código muestra que los puntos finales determinan la dirección IP de la base de datos utilizando el mismo nombre de mongo que el servicio.
Kubernetes utilizará todas las direcciones IP para encontrar puntos finales como si fueran Pods de Kubernetes normales, por lo que ahora puede acceder a la base de datos con una simple cadena de conexión con el nombre anterior mongodb://mongo. No es necesario utilizar direcciones IP en su código en absoluto.
Si las direcciones IP cambian en el futuro, simplemente puede actualizar sus puntos finales con la nueva dirección IP y no será necesario modificar sus aplicaciones de ninguna manera adicional.
Si está utilizando una base de datos alojada en un host de terceros, es probable que los propietarios del host le hayan proporcionado un URI de identificador uniforme de recursos para conectarse. Entonces, si le han proporcionado una dirección IP, simplemente puede utilizar el método anterior. Este ejemplo muestra que tengo dos bases de datos MongoDB alojadas en un host mLab.
Una es la base de datos del desarrollador y la otra es la base de datos de producción. Las cadenas de conexión para estas bases de datos tienen este aspecto: mLab le proporciona un URI dinámico y un puerto dinámico. Como puedes ver, son diferentes.
Para abstraer esto, usemos Kubernetes y conectémonos a la base de datos del desarrollador. Puede crear un nombre de servicio externo de Kubernetes, que le brindará un servicio estático que reenviará el tráfico al servicio externo.
Este servicio realizará un reenvío CNAME simple a nivel del kernel con un impacto mínimo en el rendimiento. Gracias a esto puedes utilizar una cadena de conexión más simple.
Pero debido a que el nombre externo utiliza el reenvío CNAME, no puede realizar el reenvío de puertos. Por lo tanto, esta solución sólo es aplicable para puertos estáticos y no se puede utilizar con puertos dinámicos. Pero mLab Free Tier le brinda al usuario un número de puerto dinámico de forma predeterminada y no puede cambiarlo. Esto significa que necesita diferentes líneas de comando de conexión para desarrollo y producción. Lo malo es que esto requerirá que codifiques el número de puerto. Entonces, ¿cómo se consigue que funcione el reenvío de puertos?
El primer paso es obtener la dirección IP del URI. Si ejecuta nslookup, hostname o hace ping al URI, puede obtener la dirección IP de la base de datos. Si el servicio le devuelve varias direcciones IP, todas estas direcciones se pueden utilizar en los puntos finales del objeto.
Una cosa a tener en cuenta es que los URI de IP pueden cambiar sin previo aviso, lo que hace que su uso en producción sea bastante riesgoso. Con esta dirección IP, puede conectarse a una base de datos remota sin especificar un puerto. Por tanto, el servicio Kubernetes realiza el reenvío de puertos de forma bastante transparente.
Mapear, o asignar recursos externos a recursos internos, le brinda la flexibilidad de utilizar estos servicios dentro del clúster en el futuro y, al mismo tiempo, minimizar los esfuerzos de refactorización. También facilita la gestión y proporciona información sobre los servicios externos que utiliza su empresa.
Continuará muy pronto...
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com