Se es como a maioría da xente, probablemente estea a usar recursos que se executan fóra do seu clúster. Quizais utilices a API de Taleo para enviar mensaxes de texto ou analizar imaxes mediante a API de Google Cloud Vision.
Se usas o mesmo punto final de solicitude do lado do servidor en todos os teus ambientes e non pensas migrar os teus servidores a Kubernetes, entón está perfectamente ter un punto final de servizo no teu código. Non obstante, hai moitos outros escenarios para o desenvolvemento dos eventos. Nesta serie de prácticas recomendadas de Kubernetes, aprenderás a utilizar os mecanismos integrados de Kubernetes para descubrir servizos tanto dentro como fóra do clúster.
Un exemplo de servizo externo común é unha base de datos que se executa fóra dun clúster de Kubernetes. A diferenza das bases de datos na nube como Google Cloud Data Store ou Google Cloud Spanner, que usan un único punto final para todos os accesos, a maioría das bases de datos teñen puntos finais separados para diferentes circunstancias.
As mellores prácticas para usar bases de datos tradicionais como MySQL e MongoDB adoitan significar que se conecta a diferentes compoñentes para diferentes ambientes. Podes ter unha máquina grande para os datos de produción e unha máquina máis pequena para o ambiente de proba. Cada un deles terá o seu propio enderezo IP ou nome de dominio, pero probablemente non quererá cambiar o seu código cando pase dun ambiente a outro. Polo tanto, en lugar de codificar estes enderezos, podes usar o descubrimento de servizos externos baseado en DNS integrado de Kubernetes do mesmo xeito que os servizos nativos de Kubernetes.
Digamos que estás executando unha base de datos MongoDB en Google Compute Engine. Estarás atrapado neste mundo híbrido ata que consigas transferilo ao clúster.
Afortunadamente, podes usar os servizos estáticos de Kubernetes para facilitarche un pouco a vida. Neste exemplo, creei un servidor MongoDB usando Google Cloud Launcher. Dado que se crea na mesma rede (ou VPC do clúster de Kubernetes), accédese a el mediante un enderezo IP interno de alto rendemento.
Esta é a configuración predeterminada en Google Cloud, polo que non tes que configurar nada. Agora que tes un enderezo IP, o primeiro paso é crear un servizo. Podes observar que non hai selectores de pods para este servizo. É dicir, creamos un servizo que non saberá onde enviar tráfico. Isto permitirache crear manualmente un obxecto de punto final que recibirá tráfico deste servizo.
O seguinte exemplo de código mostra que os puntos finais determinan o enderezo IP da base de datos usando o mesmo nome mongo que o servizo.
Kubernetes usará todos os enderezos IP para atopar puntos finais coma se fosen Pods Kubernetes habituais, polo que agora podes acceder á base de datos cunha cadea de conexión sinxela co nome anterior mongodb://mongo. Non é necesario usar enderezos IP no teu código en absoluto.
Se os enderezos IP cambian no futuro, pode simplemente actualizar os seus extremos co novo enderezo IP e as súas aplicacións non terán que modificarse de ningún xeito adicional.
Se estás a usar unha base de datos aloxada nun host de terceiros, é probable que os propietarios do host che proporcionaran un URI de identificador de recursos uniforme para conectarte. Polo tanto, se se lle deu un enderezo IP, simplemente pode usar o método anterior. Este exemplo mostra que teño dúas bases de datos MongoDB aloxadas nun servidor mLab.
Un é a base de datos de desenvolvedores e o outro é a base de datos de produción. As cadeas de conexión para estas bases de datos teñen o seguinte aspecto: mLab ofrécelle un URI dinámico e un porto dinámico. Como podes ver, son diferentes.
Para abstraer isto, usemos Kubernetes e conectemos á base de datos do programador. Podes crear un nome de servizo de Kubernetes externo, que che proporcionará un servizo estático que reenviará o tráfico ao servizo externo.
Este servizo realizará un reenvío CNAME sinxelo a nivel do núcleo cun impacto mínimo no rendemento. Grazas a isto podes usar unha cadea de conexión máis sinxela.
Pero como o nome externo usa o reenvío CNAME, non pode realizar o reenvío de portos. Polo tanto, esta solución só é aplicable para portos estáticos e non se pode usar con portos dinámicos. Pero mLab Free Tier dálle ao usuario un número de porto dinámico por defecto e non podes cambialo. Isto significa que necesitas liñas de comandos de conexión diferentes para dev e prod. O malo é que isto requirirá que codifique o número de porto. Entón, como fai que o reenvío de portos funcione?
O primeiro paso é obter o enderezo IP do URI. Se executas nslookup, hostname ou fai ping ao URI, podes obter o enderezo IP da base de datos. Se o servizo devolveche varios enderezos IP, todos estes enderezos pódense usar nos extremos do obxecto.
Unha cousa a ter en conta é que os URI IP poden cambiar sen previo aviso, o que fai que o seu uso sexa bastante arriscado. Usando este enderezo IP, pode conectarse a unha base de datos remota sen especificar un porto. Así, o servizo Kubernetes realiza o reenvío de portos de forma bastante transparente.
A asignación ou asignación de recursos externos a internos ofrécelle a flexibilidade de utilizar estes servizos dentro do clúster no futuro, mentres minimizan os esforzos de refactorización. Tamén facilita a xestión e a información sobre os servizos externos que utiliza a túa empresa.
Para continuar moi pronto...
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com