Man mano che inizi a creare sempre più servizi Kubernetes, compiti che inizialmente sembrano 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 diventa estremamente lungo, senza contare la necessità di una gestione adeguata. E questo è solo la punta dell'iceberg.
Esaminiamo come gli spazi dei nomi rendano più semplice la gestione delle risorse Kubernetes. Cos'è esattamente uno spazio dei nomi? Uno spazio dei nomi può essere visto come un cluster virtuale all'interno del tuo cluster Kubernetes. Puoi avere più spazi dei nomi isolati all'interno dello stesso cluster Kubernetes. Questi possono realmente aiutare te e i tuoi team a organizzare, garantire la sicurezza e migliorare le prestazioni del sistema.
Nella maggior parte delle distribuzioni Kubernetes, il cluster "esce dalla scatola" con uno spazio dei nomi chiamato "default". In realtà, ci sono tre spazi dei nomi con cui Kubernetes interagisce: default, kube-system e kube-public. Al momento, kube-public non è utilizzato molto frequentemente.
Evitare di 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 il luogo in cui vengono creati i tuoi servizi e applicazioni. Non c'è nulla di particolare a riguardo, se non che Kubernetes è configurato per utilizzarlo "out of the box", e non puoi eliminarlo. È perfetto per iniziare e per sistemi a bassa carico, ma non consiglierei di usare 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, senza nemmeno rendersene conto.
Perciò, è opportuno creare più spazi dei nomi e usarli per segmentare i tuoi servizi in sezioni gestite. Puoi creare uno spazio dei nomi con un solo comando. Se desideri creare uno spazio dei nomi chiamato test, usa il comando $ kubectl create namespace test o semplicemente crea un file YAML e usalo come qualsiasi altra risorsa Kubernetes.
Puoi visualizzare tutti gli spazi dei nomi con il comando $ kubectl get namespace.
Dopo aver eseguito questo comando, vedrai i tre spazi dei nomi predefiniti e un nuovo spazio dei nomi chiamato "test". Esaminiamo un semplice file YAML destinato alla creazione di un pod. Puoi notare che non c'è alcun riferimento allo spazio dei nomi.
Se applichi kubectl per avviare questo file, creerà il modulo mypod nello spazio dei nomi attivo corrente. Questo sarà lo spazio dei nomi default, a meno che tu non lo cambi. Ci sono 2 modi per comunicare a Kubernetes in quale spazio dei nomi desideri creare la tua risorsa. Il primo modo è utilizzare il flag dello spazio dei nomi durante la creazione della risorsa.
Il secondo modo è specificare lo spazio dei nomi nella dichiarazione YAML.
Se specifichi lo spazio dei nomi nel YAML, la risorsa sarà sempre creata in quello spazio. Se provi a utilizzare un altro spazio dei nomi specificando un flag dello spazio dei nomi, la command line restituirà un errore. Ora, se provi a cercare il tuo pod, non potrai trovarlo.
Questo accade perché tutti i comandi vengono eseguiti al di fuori dello spazio dei nomi attivo corrente. Per trovare il tuo pod, dovrai utilizzare il flag dello spazio dei nomi, ma questo può diventare rapidamente noioso, specialmente se lavori in un gruppo che utilizza il proprio spazio dei nomi e non desidera usare quel flag per ogni singolo comando. Vediamo come questo può essere risolto.
Di default, il tuo spazio dei nomi attivo è chiamato default. Se non specifichi uno spazio dei nomi nel YAML della risorsa, tutti i comandi Kubernetes utilizzeranno questo spazio dei nomi attivo default. Sfortunatamente, tentare di gestire lo spazio dei nomi attivo con kubectl può risultare problematico. Tuttavia, esiste uno strumento molto utile chiamato Kubens che semplifica notevolmente questo processo. Quando esegui il comando kubens, vedrai tutti gli spazi dei nomi, con l'attuale spazio dei nomi attivo evidenziato.
Per cambiare lo spazio dei nomi attivo in test, esegui semplicemente il comando $ kubens test. Se poi reinserisci il comando $ kubens, puoi vedere che ora è stato selezionato un nuovo spazio dei nomi attivo: test.
Questo significa che non hai bisogno del flag dello spazio dei nomi per vedere i pod nello spazio dei nomi test.
In questo modo, gli spazi dei nomi sono nascosti l'uno dall'altro, ma non isolati. Un servizio in uno spazio dei nomi può comunicare facilmente con un servizio in un altro spazio dei nomi, il che spesso si rivela molto utile. La possibilità di comunicazione tra spazi dei nomi diversi significa che il servizio dei tuoi sviluppatori può interagire con il servizio di un'altra squadra di sviluppo in un altro spazio dei nomi.
Di solito, quando la tua applicazione desidera accedere a un servizio Kubernetes, utilizzi il servizio di scoperta DNS integrato e semplicemente indichi alla tua applicazione il nome del servizio. Tuttavia, in questo modo puoi creare un servizio con lo stesso nome in più spazi dei nomi, il che non è consentito.
Fortunatamente, questo è facile da aggirare utilizzando la forma espansa dell'indirizzo DNS. I servizi in Kubernetes espongono i loro endpoint utilizzando un modello DNS comune. Questo appare pressappoco così:
In generale, ti basta il nome del servizio e il DNS determina automaticamente l'indirizzo completo.
Tuttavia, se hai bisogno di accedere a un servizio in un altro spazio dei nomi, usa semplicemente il nome del servizio seguito dal nome dello spazio dei nomi:
Ad esempio, se desideri connetterti al database del servizio nello spazio dei nomi di test, puoi utilizzare l'indirizzo database.test.
Se invece desideri connetterti al database del servizio nello spazio dei nomi di produzione, utilizzi database.prod.
Se desideri davvero isolare e limitare l'accesso a uno spazio dei nomi, Kubernetes consente di farlo utilizzando le politiche di rete di Kubernetes Network Policies. Ne parlerò nella prossima serie.
Spesso mi viene chiesto quanti spazi dei nomi sia necessario creare e a quali scopi. Cos'è esattamente un frammento di dati gestito?
Se crei troppi spazi dei nomi, questi ti ostacoleranno. Se invece ce ne sono troppo pochi, perderai tutti i vantaggi di una tale 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 una strategia adeguata per la creazione degli spazi dei nomi.
Immagina di far parte di un piccolo team che sta sviluppando 5-10 microservizi e puoi facilmente riunire tutti gli sviluppatori in una stanza. In questa situazione, ha senso eseguire tutti i servizi di produzione nello spazio dei nomi predefinito. Certamente, per avere maggiore flessibilità, puoi utilizzare 2 spazi dei nomi, uno per la produzione e l'altro per lo sviluppo. È molto probabile che tu stia testando il tuo sviluppo sul computer locale utilizzando qualcosa come Minikube.
Supponiamo che le condizioni siano cambiate e ora hai un team in rapida crescita che sta lavorando contemporaneamente su più di 10 microservizi. Arriva un momento in cui è necessario utilizzare più cluster o spazi dei nomi, separatamente per produzione e sviluppo. Puoi suddividere il team in sottogruppi in modo che ciascuno di essi abbia i propri microservizi e che ciascuno di questi team possa scegliere il proprio spazio dei nomi per semplificare la gestione dello sviluppo e del rilascio del software.
Man mano che ogni membro del team acquisisce familiarità con il funzionamento del sistema globale, coordinare ciascuna modifica con 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 spesso non sanno chi sta lavorando a cosa in particolare. I team comunicano attraverso contratti di servizio o utilizzano tecnologie come Service mesh, che aggiungono un livello di astrazione sulla rete, come il tool di configurazione Istio. Cercare di eseguire l'intero stack localmente è semplicemente impossibile. Ti consiglio vivamente di utilizzare in Kubernetes una piattaforma di distribuzione continua (CD) come Spinnaker. Pertanto, arriva un momento in cui ogni team ha decisamente bisogno del proprio spazio dei nomi. Ogni team può anche scegliere più spazi dei nomi per l'ambiente di sviluppo e l'ambiente di produzione.
Finalmente, ci sono grandi aziende imprenditoriali in cui un gruppo di sviluppatori non sa nemmeno dell'esistenza di altri gruppi. Queste aziende possono addirittura assumere sviluppatori esterni che interagiscono tramite API ben documentate. In ogni gruppo c'è un certo numero di team e di microservizi. In questo caso, è necessario utilizzare tutti gli strumenti di cui ho parlato in precedenza.
Gli programmatori non devono distribuire i servizi manualmente e non devono avere accesso a spazi dei nomi che non li riguardano. A questo punto, è utile avere diversi cluster per ridurre il "raggio d'esplosione" di applicazioni mal configurate, semplificando i processi di fatturazione e gestione delle risorse.
Pertanto, 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 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
