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 immagini tramite 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 prevedi di migrare i tuoi server in Kubernetes, è perfettamente normale avere l'endpoint del servizio direttamente nel tuo codice. Tuttavia, ci sono molti altri scenari possibili. In questa serie ‘Kubernetes Best Practices’ scoprirai come utilizzare i meccanismi integrati di Kubernetes per la scoperta dei servizi sia all'interno che all'esterno del cluster.
Un esempio di un servizio esterno comunemente utilizzato è un database che opera 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 tutti i tipi di accesso, la maggior parte dei database ha endpoint separati per diverse circostanze.
Le migliori pratiche per l'uso di database tradizionali come MySQL e MongoDB prevedono generalmente che ci si connetta a diversi componenti a seconda dell'ambiente. Potresti avere una macchina più grande per i dati di produzione e una 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 hardcodare questi indirizzi, puoi utilizzare la scoperta dei servizi esterni integrata in Kubernetes basata su DNS, proprio come per i servizi nativi di Kubernetes.
Immagina di eseguire un database MongoDB su Google Compute Engine. Resterai bloccato in questo mondo ibrido fino a quando non riuscirai a migrarlo 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é è stato creato sulla stessa rete (o VPC del cluster Kubernetes), l'accesso a esso avviene tramite un indirizzo IP interno ad alte prestazioni.
In Google Cloud questa è l'impostazione predefinita, quindi non devi configurare nulla. Ora che hai l'indirizzo IP, il primo passo è creare un servizio. Si può 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 seguente esempio di codice mostra che gli endpoint definiscono l'indirizzo IP per il database, utilizzando lo stesso nome mongo che il servizio.
Kubernetes utilizzerà tutti gli indirizzi IP per trovare gli endpoint, proprio come se fossero normali pod Kubernetes, quindi ora puoi accedere al database utilizzando una semplice stringa di connessione a mongodb://mongo. In questo modo non è affatto necessario utilizzare indirizzi IP nel tuo codice.
Se in futuro gli indirizzi IP cambiano, puoi semplicemente aggiornare gli endpoint con il nuovo indirizzo IP, e le tue applicazioni non dovranno essere modificate in alcun modo ulteriore.
Se utilizzi un database ospitato presso un fornitore esterno, probabilmente i proprietari dell'host ti hanno fornito un identificatore uniforme delle risorse URI per connetterti. Quindi, se ti è stato dato 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 DB 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 diverse.
Per astraerti da questo, usiamo Kubernetes e ci connettiamo al database degli sviluppatori. Puoi creare un nome di servizio esterno in Kubernetes, fornendoti un servizio statico che reindirizzerà il traffico verso un servizio esterno.
Questo servizio eseguirà un semplice reindirizzamento CNAME a livello di core, il che avrà un impatto minimo sulle prestazioni. In questo modo puoi utilizzare una stringa di connessione più semplice.
Tuttavia, poiché il nome esterno utilizza un reindirizzamento CNAME, non è possibile effettuare una riconfigurazione delle porte. Pertanto, questa soluzione è applicabile solo per porte statiche e non può essere utilizzata con porte dinamiche. Il piano gratuito mLab Free Tier, infatti, fornisce per impostazione predefinita un numero di porta dinamico, e non è possibile modificarlo. Ciò significa che avrai bisogno di diverse stringhe di connessione per dev e prod. Purtroppo, questo richiederà di codificare rigidamente il numero della porta. Come possiamo quindi far funzionare la riconfigurazione delle porte?
Il primo passo è ottenere l'indirizzo IP dall'URI. Eseguendo il comando nslookup, pingando il nome host o l'URI, è possibile ottenere l'indirizzo IP del database. Se il servizio restituisce più indirizzi IP, tutti questi indirizzi possono essere utilizzati negli endpoint dell'oggetto.
È importante ricordare che gli indirizzi IP dell'URI possono cambiare senza preavviso, quindi è piuttosto rischioso utilizzarli in prod. Con un indirizzo IP del genere, puoi connetterti a un database remoto senza specificare la porta. In questo modo, il servizio Kubernetes esegue in modo trasparente la riconfigurazione delle porte.
Il mapping, o associazione di risorse esterne con interne, ti consente di utilizzare flessibilmente questi servizi all'interno del cluster in futuro, riducendo al minimo gli sforzi di refactoring. Facilita anche la gestione e offre una comprensione di quali servizi esterni la tua azienda sta utilizzando.
Continuazione in arrivo molto presto…
Un po' di pubblicità 🙂
Grazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, , un'alternativa unica ai server entry-level, che abbiamo creato per te: (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! Scopri di più su
Fonte: habr.com
