Mejores prácticas de Kubernetes. Mapeo de servicios externos

Mejores prácticas de Kubernetes. Creación de contenedores pequeños
Las mejores prácticas de Kubernetes. Organización de Kubernetes con el espacio de
nombres de mejores prácticas de Kubernetes . Prueba de viabilidad de Kubernetes con pruebas de preparación y vitalidad
Mejores prácticas de Kubernetes . Establecer consultas y límites de
recursos Mejores prácticas de Kubernetes. Desconexión correcta de Terminate

Si es como la mayoría de las personas, lo más probable es que utilice recursos que operan fuera de su clúster. Es posible que esté utilizando la API de Taleo para enviar mensajes de texto o analizar imágenes con la API de Google Cloud Vision.

Si usa el mismo punto final: el punto de recepción de solicitud del lado del servidor en todos sus entornos y no planea transferir sus servidores a Kubernetes, entonces es perfectamente normal tener un servicio de punto final directamente en su código. Sin embargo, hay muchos otros escenarios. En esta serie de mejores prácticas de Kubernetes, aprenderá a usar los mecanismos integrados de Kubernetes para descubrir servicios tanto dentro como fuera del clúster.

Un ejemplo de un servicio externo generalizado 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 punto final para todos los tipos de acceso, la mayoría de las bases de datos tienen puntos finales separados para diferentes circunstancias.
Las mejores prácticas para usar bases de datos tradicionales, como MySQL y MongoDB, generalmente requieren que se conecte a diferentes componentes para diferentes entornos. Puede tener una máquina grande para datos de producción y una máquina más pequeña para un entorno de prueba. Cada uno de ellos tendrá su propia dirección IP o nombre de dominio, pero probablemente no querrá cambiar su código cuando se mueva de un entorno a otro. Por lo tanto, en lugar de codificar estas direcciones, puede usar el servicio integrado de Kubernetes para descubrir servicios externos basados ​​en DNS de la misma manera que para los servicios nativos de Kubernetes.



Suponga que ejecuta la base de datos MongoDB en Google Compute Engine. Se quedará atrapado en este mundo híbrido hasta que logre transferirlo a un clúster.

Afortunadamente, puede usar los servicios estáticos de Kubernetes para hacer su vida un poco más fácil. En este ejemplo, creé un servidor MongoDB usando Google Cloud Launcher. Dado que se creó en la misma red (o clúster Kubernetes VPC), se accede a ella mediante una dirección IP interna de alto rendimiento.



Esta es la configuración predeterminada en Google Cloud, por lo que no tiene que configurar nada. Ahora que tiene una dirección IP, el primer paso es crear un servicio. Puede notar que no hay selectores de hogar para este servicio. Es decir, creamos un servicio que no sabrá a dónde enviar 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 mongo que el servicio.



Kubernetes usará todas las direcciones IP para encontrar los puntos finales como si fueran pods regulares de Kubernetes, por lo que ahora puede acceder a la base de datos utilizando una cadena de conexión simple con el nombre anterior mongodb: // mongo. Sin embargo, no hay necesidad de usar direcciones IP en su código.

Si las direcciones IP cambian en el futuro, simplemente puede actualizar los puntos finales con la nueva dirección IP, y no será necesario cambiar sus aplicaciones de ninguna manera adicional.

Si utiliza una base de datos alojada en un host de terceros, lo más probable es que los propietarios del host le hayan proporcionado un identificador de recursos unificado para el URI. Entonces, si le dieron una dirección IP, simplemente puede usar el método anterior. Este ejemplo muestra que tengo dos bases de datos MongoDB alojadas en el host mLab.



Uno de ellos es una base de datos de desarrolladores, y el otro es una base de datos de producción. Las cadenas de conexión para estas bases de datos son las siguientes: mLab le proporciona un URI dinámico y un puerto dinámico. Como puede ver, son diferentes.



Para ignorar esto, usamos Kubernetes y nos conectamos a la base de datos de desarrolladores. Puede crear un nombre de servicio externo de Kubernetes, que le proporcionará un servicio estático que redirigirá el tráfico al servicio externo.



Este servicio realizará una simple redirección CNAME a nivel de kernel, que tendrá un impacto mínimo en el rendimiento. Gracias a esto, puede usar una cadena de conexión más simple.



Pero como el nombre externo usa la redirección CNAME, no puede realizar el reenvío de puertos. Por lo tanto, esta solución es aplicable solo para puertos estáticos y no se puede usar con puertos dinámicos. Pero el nivel gratuito mLab Free, por defecto, proporciona al usuario un número de puerto dinámico, y no puede cambiarlo. Esto significa que para desarrolladores y productos necesita diferentes líneas de comando de conexión. La mala noticia es que deberá codificar el número de puerto. Entonces, ¿cómo hacer que el reenvío de puertos funcione?

El primer paso es obtener la dirección IP del URI. Si ejecuta el comando nslookup, hostname o hace ping al URI, puede obtener la dirección IP de la base de datos. Si al mismo tiempo el servicio le devuelve varias direcciones IP, todas estas direcciones pueden usarse en los puntos finales del objeto.



Tenga en cuenta que las IP de URI pueden cambiar sin previo aviso, por lo que es bastante riesgoso usarlas en productos. Con esta dirección IP, puede conectarse a una base de datos remota sin especificar un puerto. Por lo tanto, el servicio Kubernetes realiza el reenvío de puertos de manera bastante transparente.



El mapeo, o mapeo de recursos externos a recursos internos, le brinda la capacidad de utilizar de manera flexible estos servicios dentro del clúster en el futuro mientras minimiza 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 ...

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles 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 tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos.Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?