A mesura que comenceu a crear cada cop més serveis de Kubernetes, les tasques que inicialment són senzilles comencen a ser més complexes. Per exemple, els equips de desenvolupament no poden crear serveis o desplegaments amb el mateix nom. Si teniu milers de beines, simplement enumerar-les trigarà molt de temps, i molt menys gestionar-les correctament. I això és només la punta de l'iceberg.
Vegem com l'espai de noms facilita la gestió dels recursos de Kubernetes. Aleshores, què és un espai de noms? L'espai de noms es pot considerar com un clúster virtual dins del vostre clúster de Kubernetes. Podeu tenir diversos espais de noms aïllats els uns dels altres dins d'un únic clúster de Kubernetes. Realment us poden ajudar a vosaltres i als vostres equips amb l'organització, la seguretat i fins i tot el rendiment del sistema.
A la majoria de distribucions de Kubernetes, el clúster surt de la caixa amb un espai de noms anomenat "predeterminat". En realitat, hi ha tres espais de noms amb què tracta Kubernetes: predeterminat, kube-system i kube-public. Actualment, Kube-public no s'utilitza gaire sovint.
Deixar l'espai de noms kube sol és una bona idea, especialment en un sistema gestionat com Google Kubernetes Engine. Utilitza l'espai de noms "predeterminat" com a lloc on es creen els vostres serveis i aplicacions. No hi ha absolutament res especial, excepte que Kubernetes està configurat de manera immediata per utilitzar-lo i no el podeu eliminar. Això és ideal per començar i sistemes de baix rendiment, però no recomanaria utilitzar l'espai de noms predeterminat en sistemes de productes grans. En aquest últim cas, un equip de desenvolupament pot reescriure fàcilment el codi d'una altra persona i trencar el treball d'un altre equip sense ni tan sols adonar-se'n.
Per tant, hauríeu de crear diversos espais de noms i utilitzar-los per segmentar els vostres serveis en unitats gestionables. Es pot crear un espai de noms amb una única ordre. Si voleu crear un espai de noms anomenat test, feu servir l'ordre $ kubectl create namespace test o simplement creeu un fitxer YAML i utilitzeu-lo com qualsevol altre recurs de Kubernetes.
Podeu veure tots els espais de noms mitjançant l'ordre $ kubectl get namespace.
Un cop fet, veureu tres espais de noms integrats i un espai de noms nou anomenat "prova". Vegem un fitxer YAML senzill per crear un pod. Notareu que no s'esmenta l'espai de noms.
Si utilitzeu kubectl per executar aquest fitxer, crearà el mòdul mypod a l'espai de noms actiu actualment. Aquest serà l'espai de noms predeterminat fins que el canvieu. Hi ha dues maneres de dir a Kubernetes en quin espai de noms voleu crear el vostre recurs. La primera manera és utilitzar un indicador d'espai de noms quan es crea un recurs.
La segona manera és especificar l'espai de noms a la declaració YAML.
Si especifiqueu un espai de noms a YAML, el recurs sempre es crearà en aquest espai de noms. Si intenteu utilitzar un espai de noms diferent mentre feu servir el senyalador d'espai de noms, l'ordre fallarà. Ara, si intenteu trobar el vostre pod, no ho podreu fer.
Això passa perquè totes les ordres s'executen fora de l'espai de noms actiu actualment. Per trobar el vostre pod, heu d'utilitzar un indicador d'espai de noms, però això s'avorreix ràpidament, sobretot si sou un desenvolupador d'un equip que utilitza el seu propi espai de noms i no vol utilitzar aquest indicador per a cada comanda. A veure com ho podem solucionar.
Fora de la caixa, el vostre espai de noms actiu s'anomena predeterminat. Si no especifiqueu un espai de noms al recurs YAML, totes les ordres de Kubernetes utilitzaran aquest espai de noms predeterminat actiu. Malauradament, intentar gestionar l'espai de noms actiu amb kubectl pot fallar. Tanmateix, hi ha una molt bona eina anomenada Kubens que facilita molt aquest procés. Quan executeu l'ordre kubens, veureu tots els espais de noms amb l'espai de noms actiu ressaltat.
Per canviar l'espai de noms actiu a l'espai de noms de prova, només cal que executeu l'ordre de prova $kubens. Si torneu a executar l'ordre $kubens, veureu que ara s'ha assignat un nou espai de noms actiu: prova.
Això vol dir que no necessiteu la marca de l'espai de noms per veure el pod a l'espai de noms de prova.
D'aquesta manera, els espais de noms s'oculten els uns dels altres, però no s'aïllen els uns dels altres. Un servei d'un espai de noms es pot comunicar amb força facilitat amb un servei d'un altre espai de noms, cosa que sovint és molt útil. La possibilitat de comunicar-se entre diferents espais de noms significa que el servei dels vostres desenvolupadors es pot comunicar amb el servei d'un altre equip de desenvolupament en un espai de noms diferent.
Normalment, quan la vostra aplicació vol accedir a un servei de Kubernetes, utilitzeu el servei de descoberta de DNS integrat i simplement doneu a la vostra aplicació el nom del servei. Tanmateix, fent-ho, podeu crear un servei amb el mateix nom en diversos espais de noms, cosa que no és acceptable.
Afortunadament, això és fàcil de moure mitjançant la forma ampliada de l'adreça DNS. Els serveis de Kubernetes exposen els seus punts finals mitjançant una plantilla DNS comuna. Sembla una cosa així:
Normalment, només necessiteu el nom del servei i DNS determinarà automàticament l'adreça completa.
Tanmateix, si necessiteu accedir a un servei en un espai de noms diferent, només cal que utilitzeu el nom del servei més el nom de l'espai de noms:
Per exemple, si voleu connectar-vos a una base de dades de servei en un espai de noms de prova, podeu utilitzar la base de dades d'adreces database.test
Si voleu connectar-vos a la base de dades del servei a l'espai de noms prod, feu servir database.prod.
Si realment voleu aïllar i restringir l'accés a l'espai de noms, Kubernetes us permet fer-ho mitjançant Polítiques de xarxa de Kubernetes. En parlaré en el proper episodi.
Sovint em fan la pregunta, quants espais de noms he de crear i amb quina finalitat? Què és una dada gestionada?
Si creeu massa espais de noms, només us interposaran en el camí. Si n'hi ha massa pocs, perdràs tots els avantatges d'aquesta solució. Crec que hi ha quatre etapes principals per les quals passa cada empresa a l'hora de crear la seva estructura organitzativa. Depenent de l'etapa de desenvolupament en què es trobi el vostre projecte o empresa, és possible que vulgueu adoptar una estratègia d'espai de noms adequada.
Imagineu que formeu part d'un petit equip que treballa en el desenvolupament de 5-10 microserveis i podeu reunir fàcilment tots els desenvolupadors en una habitació. En aquesta situació, té sentit executar tots els serveis de prod a l'espai de noms predeterminat. Per descomptat, per a més flexibilitat, podeu utilitzar 2 espais de noms, per separat per a prod i dev. I el més probable és que proveu el vostre desenvolupament al vostre ordinador local fent servir alguna cosa com Minikube.
Diguem que les coses canvien i ara teniu un equip que creix ràpidament que treballa en més de 10 microserveis alhora. Arriba un moment en què cal utilitzar diversos clústers o espais de noms, per separat per a prod i dev. Podeu dividir l'equip en diversos subequips de manera que cadascun d'ells tingui els seus propis microserveis i cadascun d'aquests equips pugui triar el seu propi espai de noms per facilitar el procés de gestió del desenvolupament i llançament de programari.
A mesura que cada membre de l'equip coneix com funciona el sistema en conjunt, cada vegada és més difícil coordinar tots els canvis amb la resta de desenvolupadors. Intentar fer girar una pila completa a la vostra màquina local és cada dia més difícil.
A les grans empreses, els desenvolupadors generalment no saben qui treballa exactament en què. Els equips es comuniquen mitjançant contractes de servei o utilitzen tecnologia de malla de servei, que afegeix una capa d'abstracció a la xarxa, com ara l'eina de configuració Istio. Simplement no és possible intentar executar una pila sencera localment. Recomano molt utilitzar una plataforma de lliurament continu (CD) com Spinnaker a Kubernetes. Per tant, arriba un punt en què cada comanda necessita definitivament el seu propi espai de noms. Cada equip fins i tot pot triar diversos espais de noms per a l'entorn de desenvolupament i l'entorn de producte.
Finalment, hi ha grans empreses emprenedores en les quals un grup de desenvolupadors ni tan sols coneix l'existència d'altres grups. En general, aquesta empresa pot contractar desenvolupadors de tercers que interactuïn amb ella mitjançant API ben documentades. Cada grup conté diversos equips i diversos microserveis. En aquest cas, heu d'utilitzar totes les eines de les quals he parlat anteriorment.
Els programadors no haurien de desplegar serveis manualment i no haurien de tenir accés a espais de noms que no els concerneixen. En aquesta fase, s'aconsella disposar de diversos clústers per reduir el "radi de l'explosió" d'aplicacions mal configurades, per simplificar els processos de facturació i la gestió de recursos.
Així, l'ús adequat dels espais de noms per part de la vostra organització us permet fer que Kubernetes sigui més manejable, controlable, segur i flexible.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com