Se sei come la maggior parte delle persone, probabilmente utilizzi risorse che funzionano al di fuori del tuo cluster. Potresti utilizzare l'API Taleo per inviare messaggi di testo o analizzare le immagini utilizzando l'API Google Cloud Vision.
Se utilizzi lo stesso endpoint — il punto di ricezione delle richieste sul server in tutti i tuoi ambienti e non hai in programma di spostare i tuoi server in Kubernetes, è del tutto normale avere l'endpoint del servizio direttamente nel tuo codice. Tuttavia, ci sono molti altri scenari. In questa serie di "Migliori pratiche Kubernetes" imparerai a utilizzare i meccanismi integrati di Kubernetes per la scoperta dei servizi sia all'interno che all'esterno del cluster.
Un esempio comune di servizio esterno è un database che funziona al di fuori del cluster Kubernetes. A differenza di database cloud come Google Cloud Data Store o Google Cloud Spanner, che utilizzano un unico endpoint per ogni tipo di accesso, la maggior parte dei database ha endpoint separati per diverse circostanze.
Una prassi consolidata nell'uso di database tradizionali come MySQL e MongoDB prevede che tu ti connetta a diversi componenti per ogni diverso ambiente. Potresti avere una macchina più grande per i dati di produzione e una macchina più piccola per l'ambiente di test. Ognuna di esse avrà il proprio indirizzo IP o nome di dominio, ma sicuramente non vorrai modificare il tuo codice passando da un ambiente all'altro. Pertanto, invece di codificare rigidamente questi indirizzi, puoi utilizzare il servizio integrato di Kubernetes per scoprire servizi esterni basati su DNS proprio come fai per i servizi nativi di Kubernetes.
Supponiamo che tu stia eseguendo un database MongoDB su Google Compute Engine. Rimarrai bloccato in questo mondo ibrido fino a quando non riuscirai a trasferirlo nel cluster.
Fortunatamente, puoi utilizzare i servizi statici di Kubernetes per semplificarti un po' la vita. In questo esempio ho creato un server MongoDB utilizzando Google Cloud Launcher. Poiché è creato nella stessa rete (o VPC del cluster Kubernetes), l'accesso avviene tramite un indirizzo IP interno ad alte prestazioni.
In Google Cloud, questa è l'impostazione predefinita, quindi non è necessario configurare nulla. Ora che hai un indirizzo IP, il primo passo è creare un servizio. Puoi notare che per questo servizio non ci sono selettori dei pod. In altre parole, abbiamo creato un servizio che non saprà dove inviare il traffico. Questo permetterà di creare manualmente un oggetto endpoint, che riceverà il traffico da questo servizio.
Il prossimo esempio di codice mostra che gli endpoint definiscono l'indirizzo IP per il database, utilizzando lo stesso nome mongo che ha il servizio.
Kubernetes utilizzerà tutti gli indirizzi IP per trovare gli endpoint, come se fossero normali pod di Kubernetes, quindi ora puoi accedere al database utilizzando una semplice stringa di connessione al nome sopra indicato mongodb://mongo. Non è affatto necessario utilizzare indirizzi IP nel tuo codice.
Se in futuro gli indirizzi IP dovessero cambiare, puoi semplicemente aggiornare gli endpoint con il nuovo indirizzo IP, e le tue applicazioni non dovranno essere modificate in alcun modo.
Se stai utilizzando un database ospitato da un provider esterno, è probabile che i proprietari dell'hosting ti abbiano fornito un identificatore di risorsa unificato URI per la connessione. Quindi, se ti è stato fornito un indirizzo IP, puoi semplicemente utilizzare il metodo precedente. Questo esempio mostra che ho due database MongoDB ospitati su mLab.
Uno di essi è il database degli sviluppatori, mentre l'altro è il database di produzione. Le stringhe di connessione per questi database sono le seguenti: mLab ti fornisce un URI dinamico e una porta dinamica. Come puoi vedere, sono diversi.
Per astrarre da questo, utilizziamo Kubernetes e ci connettiamo al database degli sviluppatori. Puoi creare un nome di servizio esterno in Kubernetes, che ti fornirà un servizio statico che reindirizzerà il traffico a un servizio esterno.
Questo servizio eseguirà un semplice reindirizzamento CNAME a livello di core, riducendo al minimo l'impatto sulle prestazioni. Grazie a questo potrai utilizzare una stringa di connessione più semplice.
Ma poiché il nome esterno utilizza il reindirizzamento CNAME, non è possibile eseguire la riscrittura delle porte. Pertanto, questa soluzione è applicabile solo per le porte statiche e non può essere utilizzata con porte dinamiche. Tuttavia, il piano gratuito mLab Free Tier fornisce per default all'utente un numero di porta dinamico, e non puoi cambiarlo. Questo significa che per dev e prod hai bisogno di diverse stringhe di connessione. Purtroppo, ciò richiederà di codificare rigidamente il numero di porta. Come si può quindi far funzionare la riscrittura delle porte?
Il primo passo è ottenere l'indirizzo IP dall'URI. Eseguendo il comando nslookup, hostname o pingando l'URI, è possibile ottenere l'indirizzo IP del database. Se il servizio ti restituisce più indirizzi IP, tutti questi indirizzi possono essere utilizzati nei punti finali dell'oggetto.
È importante ricordare che gli indirizzi IP dell'URI possono cambiare senza preavviso, quindi è piuttosto rischioso utilizzarli in prod. Con un indirizzo IP di questo tipo, è possibile connettersi a un database remoto senza specificare una porta. In questo modo, il servizio Kubernetes esegue in modo trasparente la riscrittura delle porte.
Il mapping, o la correlazione delle risorse esterne con quelle interne, ti consente di utilizzare queste risorse all'interno del cluster in futuro, minimizzando gli sforzi di refactoring. Facilita anche la gestione e offre una comprensione di quali servizi esterni sta utilizzando la tua azienda.
Il seguito arriverà molto presto…
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Leggi di
Fonte: habr.com
