Man mano che inizi a creare sempre più servizi Kubernetes, le attività inizialmente semplici iniziano a diventare più complesse. Ad esempio, i team di sviluppo non possono creare servizi o distribuzioni con lo stesso nome. Se disponi di migliaia di pod, elencarli semplicemente richiederà molto tempo, per non parlare della loro corretta gestione. E questa è solo la punta dell’iceberg.
Diamo un'occhiata a come lo spazio dei nomi semplifica la gestione delle risorse Kubernetes. Allora, cos'è uno spazio dei nomi? Lo spazio dei nomi può essere considerato come un cluster virtuale all'interno del tuo cluster Kubernetes. Puoi avere più spazi dei nomi isolati tra loro all'interno di un singolo cluster Kubernetes. Possono davvero aiutare te e i tuoi team con l'organizzazione, la sicurezza e persino le prestazioni del sistema.
Sulla maggior parte delle distribuzioni Kubernetes, il cluster viene fornito con uno spazio dei nomi chiamato "predefinito". In realtà ci sono tre spazi dei nomi di cui si occupa Kubernetes: default, kube-system e kube-public. Attualmente Kube-public non viene utilizzato molto spesso.
Lasciare da solo lo spazio dei nomi kube è una buona idea, soprattutto su un sistema gestito come Google Kubernetes Engine. Utilizza lo spazio dei nomi "predefinito" come luogo in cui vengono creati i servizi e le applicazioni. Non c'è assolutamente nulla di speciale, tranne che Kubernetes è configurato immediatamente per usarlo e non puoi rimuoverlo. Questo è ottimo per i principianti e per i sistemi a basse prestazioni, ma non consiglierei di utilizzare lo spazio dei nomi predefinito su sistemi di produzione di grandi dimensioni. In quest'ultimo caso, un team di sviluppo può facilmente riscrivere il codice di qualcun altro e interrompere il lavoro di un altro team senza nemmeno rendersene conto.
Pertanto, dovresti creare più spazi dei nomi e utilizzarli per segmentare i tuoi servizi in unità gestibili. Uno spazio dei nomi può essere creato con un singolo comando. Se desideri creare uno spazio dei nomi denominato test, utilizza il comando $ kubectl create namespace test o crea semplicemente un file YAML e utilizzalo come qualsiasi altra risorsa Kubernetes.
Puoi visualizzare tutti gli spazi dei nomi utilizzando il comando $ kubectl get namespace.
Una volta terminato, vedrai tre spazi dei nomi integrati e un nuovo spazio dei nomi chiamato "test". Diamo un'occhiata a un semplice file YAML per creare un pod. Noterai che non viene menzionato lo spazio dei nomi.
Se usi kubectl per eseguire questo file, creerà il modulo mypod nello spazio dei nomi attualmente attivo. Questo sarà lo spazio dei nomi predefinito finché non lo cambierai. Esistono 2 modi per indicare a Kubernetes in quale spazio dei nomi vuoi creare la tua risorsa. Il primo modo è utilizzare un flag dello spazio dei nomi durante la creazione di una risorsa.
Il secondo modo è specificare lo spazio dei nomi nella dichiarazione YAML.
Se specifichi uno spazio dei nomi in YAML, la risorsa verrà sempre creata in quello spazio dei nomi. Se provi a utilizzare uno spazio dei nomi diverso mentre usi il flag dello spazio dei nomi, il comando fallirà. Ora, se provi a trovare il tuo pod, non sarai in grado di farlo.
Ciò si verifica perché tutti i comandi vengono eseguiti all'esterno dello spazio dei nomi attualmente attivo. Per trovare il tuo pod, devi utilizzare un flag dello spazio dei nomi, ma questo diventa presto noioso, soprattutto se sei uno sviluppatore di un team che utilizza il proprio spazio dei nomi e non vuole utilizzare quel flag per ogni singolo comando. Vediamo come possiamo risolvere questo problema.
Per impostazione predefinita, lo spazio dei nomi attivo è chiamato predefinito. Se non specifichi uno spazio dei nomi nella risorsa YAML, tutti i comandi Kubernetes utilizzeranno questo spazio dei nomi predefinito attivo. Sfortunatamente, provare a gestire lo spazio dei nomi attivo utilizzando kubectl può fallire. Tuttavia, esiste un ottimo strumento chiamato Kubens che rende questo processo molto più semplice. Quando esegui il comando kubens, vedi tutti gli spazi dei nomi con lo spazio dei nomi attivo evidenziato.
Per cambiare lo spazio dei nomi attivo nello spazio dei nomi di test, esegui semplicemente il comando $kubens test. Se esegui nuovamente il comando $kubens, vedrai che ora è allocato un nuovo spazio dei nomi attivo: test.
Ciò significa che non hai bisogno del flag dello spazio dei nomi per vedere il pod nello spazio dei nomi del test.
In questo modo gli spazi dei nomi sono nascosti l'uno dall'altro, ma non isolati l'uno dall'altro. Un servizio in un namespace può comunicare abbastanza facilmente con un servizio in un altro namespace, il che spesso è molto utile. La capacità di comunicare tra spazi dei nomi diversi significa che il servizio dei tuoi sviluppatori può comunicare con il servizio di un altro team di sviluppo in uno spazio dei nomi diverso.
In genere, quando la tua applicazione desidera accedere a un servizio Kubernetes, utilizzi il servizio di rilevamento DNS integrato e fornisci semplicemente alla tua applicazione il nome del servizio. Tuttavia, così facendo, puoi creare un servizio con lo stesso nome in più spazi dei nomi, il che non è accettabile.
Fortunatamente, è facile aggirare questo problema utilizzando la forma estesa dell’indirizzo DNS. I servizi in Kubernetes espongono i propri endpoint utilizzando un modello DNS comune. Sembra qualcosa del genere:
In genere, è sufficiente il nome del servizio e il DNS determinerà automaticamente l'indirizzo completo.
Tuttavia, se devi accedere a un servizio in uno spazio dei nomi diverso, utilizza semplicemente il nome del servizio più il nome dello spazio dei nomi:
Ad esempio, se desideri connetterti a un database di servizio in uno spazio dei nomi di test, puoi utilizzare il database degli indirizzi database.test
Se desideri connetterti al database del servizio nello spazio dei nomi prod, utilizza database.prod.
Se vuoi davvero isolare e limitare l'accesso allo spazio dei nomi, Kubernetes ti consente di farlo utilizzando le policy di rete Kubernetes. Di questo parlerò nella prossima puntata.
Spesso mi viene posta la domanda: quanti spazi dei nomi dovrei creare e per quali scopi? Cos'è un dato gestito?
Se crei troppi spazi dei nomi, questi ti ostacoleranno. Se ce ne sono troppo pochi, perderai tutti i vantaggi di tale soluzione. Penso che ci siano quattro fasi principali che ogni azienda attraversa quando crea la propria struttura organizzativa. A seconda della fase di sviluppo in cui si trova il tuo progetto o la tua azienda, potresti voler adottare una strategia di spazio dei nomi appropriata.
Immagina di far parte di un piccolo team che sta lavorando allo sviluppo di 5-10 microservizi e di poter riunire facilmente tutti gli sviluppatori in un'unica stanza. In questa situazione, ha senso eseguire tutti i servizi di produzione nello spazio dei nomi predefinito. Naturalmente, per una maggiore flessibilità, puoi utilizzare 2 spazi dei nomi, separatamente per prod e dev. E molto probabilmente, testerai il tuo sviluppo sul tuo computer locale usando qualcosa come Minikube.
Diciamo che le cose cambiano e ora hai un team in rapida crescita che lavora su più di 10 microservizi alla volta. Arriva un momento in cui è necessario utilizzare diversi cluster o spazi dei nomi, separatamente per prod e dev. È possibile suddividere il team in diversi sottoteam in modo che ognuno di essi abbia i propri microservizi e ciascuno di questi team possa scegliere il proprio spazio dei nomi per facilitare il processo di gestione dello sviluppo e del rilascio del software.
Man mano che ciascun membro del team acquisisce informazioni su come funziona il sistema nel suo insieme, diventa sempre più difficile coordinare ogni modifica con tutti gli altri sviluppatori. Cercare di avviare uno stack completo sul tuo computer locale diventa ogni giorno più difficile.
Nelle grandi aziende, gli sviluppatori generalmente non sanno chi sta lavorando esattamente su cosa. I team comunicano tramite contratti di servizio o utilizzano la tecnologia service mesh, che aggiunge un livello di astrazione sulla rete, come lo strumento di configurazione Istio. Provare a eseguire un intero stack localmente non è semplicemente possibile. Consiglio vivamente di utilizzare una piattaforma di distribuzione continua (CD) come Spinnaker su Kubernetes. Quindi, arriva un punto in cui ogni comando ha sicuramente 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.
Infine, ci sono grandi aziende imprenditoriali in cui un gruppo di sviluppatori non sa nemmeno dell'esistenza di altri gruppi. Una società di questo tipo può generalmente assumere sviluppatori di terze parti che interagiscono con essa tramite API ben documentate. Ciascuno di questi gruppi contiene diversi team e diversi microservizi. In questo caso è necessario utilizzare tutti gli strumenti di cui ho parlato prima.
I programmatori non dovrebbero distribuire manualmente i servizi e non dovrebbero avere accesso a spazi dei nomi che non li riguardano. In questa fase è consigliabile disporre di più cluster per ridurre il “raggio di esplosione” delle applicazioni mal configurate, per semplificare i processi di fatturazione e la gestione delle risorse.
Pertanto, l'uso corretto degli spazi dei nomi da parte della tua organizzazione consente di rendere Kubernetes più gestibile, controllabile, sicuro e flessibile.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com