Man mano che inizi a creare sempre più servizi Kubernetes, compiti inizialmente semplici iniziano a complicarsi. Ad esempio, i team di sviluppo non possono creare servizi o deployment con lo stesso nome. Se hai migliaia di pod, elencarli semplicemente richiederà molto tempo, per non parlare del fatto di garantire una gestione adeguata. E questo è solo la punta dell'iceberg.
Vediamo come gli spazi dei nomi (namespace) facilitano la gestione delle risorse Kubernetes. Ma cos'è esattamente uno spazio dei nomi? Può essere considerato come un cluster virtuale all'interno del tuo cluster Kubernetes. Puoi avere più spazi dei nomi isolati l'uno dall'altro all'interno di un unico cluster Kubernetes. Possono davvero aiutarti e aiutare i tuoi team nell'organizzazione, nella sicurezza e persino nelle prestazioni del sistema.
Nella maggior parte delle distribuzioni di Kubernetes, il cluster "esce dalla scatola" con uno spazio dei nomi denominato "default". In realtà, ci sono tre spazi dei nomi con cui Kubernetes ha a che fare: default, kube-system e kube-public. Attualmente, kube-public non è utilizzato molto frequentemente.
Non toccare lo spazio dei nomi kube è una buona idea, specialmente in un sistema gestito come Google Kubernetes Engine. Utilizza lo spazio dei nomi "default" come punto in cui vengono creati i tuoi servizi e applicazioni. Non c'è assolutamente nulla di speciale, tranne il fatto che Kubernetes è configurato per usarlo "out of the box", e non puoi eliminarlo. È perfetto per iniziare e per sistemi a bassa capacità, ma non consiglio di utilizzare lo spazio dei nomi default in grandi sistemi di produzione. In quest'ultimo caso, un team di sviluppo potrebbe facilmente sovrascrivere il codice di un altro team e compromettere il lavoro dell'altro, anche senza rendersene conto.
Pertanto, è consigliabile creare diversi spazi dei nomi e utilizzarli per segmentare i tuoi servizi in unità gestibili. Puoi creare uno spazio dei nomi con un solo comando. Se vuoi creare uno spazio dei nomi chiamato test, utilizza il comando $ kubectl create namespace test oppure crea semplicemente un file YAML e usalo come qualsiasi altra risorsa Kubernetes.
Puoi visualizzare tutti gli spazi dei nomi utilizzando il comando $ kubectl get namespace.
Dopo averlo completato, vedrete tre spazi dei nomi incorporati e un nuovo spazio dei nomi chiamato «test». Esaminiamo un semplice file YAML destinato alla creazione di un pod. Si può notare che non c'è alcun riferimento allo spazio dei nomi.
Se utilizzate kubectl per eseguire questo file, verrà creato un modulo mypod nello spazio dei nomi attivo corrente. Questo sarà lo spazio dei nomi predefinito, a meno che non lo modifichiate. Ci sono 2 modi per comunicare a Kubernetes in quale spazio dei nomi desiderate creare la vostra risorsa. Il primo modo è utilizzare il flag dello spazio dei nomi durante la creazione della risorsa.
Il secondo modo consiste nel specificare lo spazio dei nomi nella dichiarazione YAML.
Se si specifica lo spazio dei nomi nel YAML, la risorsa verrà sempre creata in quello spazio. Se tentate di utilizzare un altro spazio dei nomi con il flag dello spazio dei nomi, il comando restituirà un errore. Ora, se provate a trovare il vostro pod, non sarete in grado di farlo.
Questo accade perché tutti i comandi vengono eseguiti al di fuori dello spazio dei nomi attivo corrente. Per trovare il vostro pod, dovete utilizzare il flag dello spazio dei nomi, ma diventa rapidamente fastidioso, soprattutto se lavorate come sviluppatori in un gruppo che utilizza il proprio spazio dei nomi e non vuole usare quel flag per ogni singolo comando. Vediamo come possiamo risolvere questo problema.
Di default, il vostro spazio dei nomi attivo si chiama default. Se non specificate lo spazio dei nomi nel YAML della risorsa, tutti i comandi Kubernetes utilizzeranno questo spazio dei nomi attivo default. Purtroppo, cercare di gestire lo spazio dei nomi attivo tramite kubectl può risultare difficile. Tuttavia, esiste uno strumento molto utile chiamato Kubens, che semplifica notevolmente questo processo. Quando eseguite il comando kubens, vedrete tutti gli spazi dei nomi con lo spazio dei nomi attivo evidenziato.
Per cambiare lo spazio dei nomi attivo in quello di test, basta eseguire il comando $ kubens test. Se dopo questo reinserite il comando $ kubens, potrete vedere che ora è stato evidenziato un nuovo spazio dei nomi attivo: test.
Ciò significa che non hai bisogno di un flag del namespace per vedere il pod nel namespace test.
In questo modo i namespace sono nascosti l'uno dall'altro, ma non isolati. Un servizio di un namespace può comunicare abbastanza facilmente con un servizio in un altro namespace, il che è spesso molto utile. La possibilità di comunicazione tra diversi namespace significa che il servizio dei tuoi sviluppatori può interagire con il servizio di un altro team di sviluppo in un altro namespace.
Di solito, quando la tua applicazione desidera accedere a un servizio Kubernetes, utilizzi il servizio di discovery DNS integrato e semplicemente dici alla tua applicazione il nome del servizio. Tuttavia, puoi creare un servizio con lo stesso nome in più namespace, il che non è consentito.
Fortunatamente, è facile aggirare questo problema utilizzando la forma espansa dell'indirizzo DNS. I servizi in Kubernetes espongono le loro endpoint utilizzando un modello DNS comune. Questo appare più o meno così:
In genere, hai solo bisogno del nome del servizio e il DNS determinerà automaticamente l'indirizzo completo.
Tuttavia, se hai bisogno di accedere a un servizio in un altro namespace, puoi semplicemente usare il nome del servizio più il nome del namespace:
Ad esempio, se desideri connetterti al database di un servizio nel namespace di test, puoi usare l'indirizzo database.test.
Se invece desideri connetterti al database di un servizio nel namespace di produzione, utilizzi database.prod.
Se desideri davvero isolare e limitare l'accesso a un namespace, Kubernetes consente di farlo tramite le politiche di rete di Kubernetes Network Policies. Ne parlerò nella prossima serie.
Mi viene spesso chiesto quanti namespace siano necessari e a quali scopi. Cos'è quindi un frammento di dati gestito?
Se crei troppi spazi dei nomi, saranno solo d'intralcio. Se ne hai troppo pochi, perderai tutti i vantaggi di questa soluzione. Penso che ci siano quattro fasi principali che ogni azienda attraversa nel processo di creazione della propria struttura organizzativa. A seconda della fase di sviluppo in cui si trova il tuo progetto o la tua azienda, puoi adottare la strategia appropriata per la creazione degli spazi dei nomi.
Immagina di far parte di un piccolo team che lavora allo sviluppo di 5-10 microservizi e puoi facilmente riunire tutti gli sviluppatori in una sola stanza. In questa situazione ha senso avviare tutti i servizi di produzione nello spazio dei nomi predefinito. Certamente, per avere maggiori possibilità di manovra puoi utilizzare 2 spazi dei nomi: uno separato per produzione e uno per sviluppo. È probabile che tu stia testando i tuoi sviluppi sul computer locale utilizzando qualcosa come Minikube.
Supponiamo che le circostanze siano cambiate e ora hai un team in rapida crescita che lavora contemporaneamente su più di 10 microservizi. Arriva un momento in cui è necessario utilizzare più cluster o spazi dei nomi, separati per produzione e sviluppo. Puoi suddividere il team in più sottogruppi in modo che ognuno di essi abbia i propri microservizi e ciascun team possa scegliere il proprio spazio dei nomi per facilitare il processo di gestione dello sviluppo e del rilascio del software.
Man mano che ogni membro del team acquisisce una visione del funzionamento del sistema nel suo complesso, coordinare ogni modifica con tutti gli altri sviluppatori diventa sempre più difficile. Tentare di far girare l'intero stack sul tuo computer locale diventa sempre più complicato.
Nelle grandi aziende, gli sviluppatori non sanno nemmeno chi stia lavorando a cosa. I team comunicano attraverso contratti di servizio o utilizzano la tecnologia Service mesh, che aggiunge un livello di astrazione sopra la rete, simile a uno strumento di configurazione come Istio. Provare a eseguire l'intero stack in locale è praticamente impossibile. Consiglio vivamente di utilizzare una piattaforma di consegna continua (CD) come Spinnaker in Kubernetes. Pertanto, arriva il momento in cui ogni team ha sicuramente bisogno del proprio spazio dei nomi. Ogni team può anche scegliere diversi spazi dei nomi per l'ambiente dev e l'ambiente prod.
Infine, ci sono grandi aziende imprenditoriali in cui un gruppo di sviluppatori non sa nemmeno dell'esistenza degli altri gruppi. Tali aziende possono assumere sviluppatori esterni che interagiscono tramite API ben documentate. In ogni gruppo ci sono diversi team e diversi microservizi. In questo caso, è necessario utilizzare tutti gli strumenti di cui ho parlato in precedenza.
I programmatori non devono distribuire manualmente i servizi e non devono avere accesso agli spazi dei nomi che non li riguardano. A questo punto, è opportuno avere diversi cluster per ridurre il "raggio d'esplosione" delle applicazioni mal configurate, per semplificare i processi di fatturazione e la gestione delle risorse.
Quindi, un uso corretto degli spazi dei nomi da parte della vostra organizzazione rende Kubernetes più gestibile, controllabile, sicuro e flessibile.
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
