A medida que comezas a crear cada vez máis servizos de Kubernetes, as tarefas que inicialmente son sinxelas comezan a ser máis complexas. Por exemplo, os equipos de desenvolvemento non poden crear servizos ou despregamentos co mesmo nome. Se tes miles de pods, simplemente enumeralos levará moito tempo, e moito menos xestionalos correctamente. E esta é só a punta do iceberg.
Vexamos como o espazo de nomes facilita a xestión dos recursos de Kubernetes. Entón, que é un espazo de nomes? O espazo de nomes pódese considerar como un clúster virtual dentro do clúster de Kubernetes. Podes ter varios espazos de nomes illados entre si dentro dun único clúster de Kubernetes. Realmente poden axudarche a ti e aos teus equipos coa organización, a seguridade e mesmo o rendemento do sistema.
Na maioría das distribucións de Kubernetes, o clúster sae da caixa cun espazo de nomes chamado "predeterminado". En realidade, hai tres espazos de nomes cos que trata Kubernetes: default, kube-system e kube-public. Actualmente, Kube-public non se usa con moita frecuencia.
Deixar só o espazo de nomes de kube é unha boa idea, especialmente nun sistema xestionado como Google Kubernetes Engine. Usa o espazo de nomes "predeterminado" como o lugar onde se crean os seus servizos e aplicacións. Non hai absolutamente nada especial, excepto que Kubernetes está configurado para usalo e non podes eliminalo. Isto é excelente para comezar e sistemas de baixo rendemento, pero non recomendaría usar o espazo de nomes predeterminado en sistemas de grandes produtos. Neste último caso, un equipo de desenvolvemento pode facilmente reescribir o código doutra persoa e romper o traballo doutro equipo sen sequera darse conta.
Polo tanto, debes crear varios espazos de nomes e utilizalos para segmentar os teus servizos en unidades manexables. Pódese crear un espazo de nomes cun só comando. Se queres crear un espazo de nomes chamado test, utiliza o comando $ kubectl create namespace test ou simplemente crea un ficheiro YAML e utilízao como calquera outro recurso de Kubernetes.
Podes ver todos os espazos de nomes usando o comando $ kubectl get namespace.
Unha vez feito isto, verás tres espazos de nomes integrados e un novo espazo de nomes chamado "test". Vexamos un ficheiro YAML sinxelo para crear un pod. Notarás que non hai ningunha mención ao espazo de nomes.
Se usas kubectl para executar este ficheiro, creará o módulo mypod no espazo de nomes activo actualmente. Este será o espazo de nomes predeterminado ata que o cambies. Hai dúas formas de dicirlle a Kubernetes en que espazo de nomes queres crear o teu recurso. A primeira forma é usar unha marca de espazo de nomes ao crear un recurso.
A segunda forma é especificar o espazo de nomes na declaración YAML.
Se especificas un espazo de nomes en YAML, o recurso sempre se creará nese espazo de nomes. Se tentas usar un espazo de nomes diferente mentres usas a marca de espazo de nomes, o comando fallará. Agora, se tentas atopar a túa vaina, non poderás facelo.
Isto ocorre porque todos os comandos execútanse fóra do espazo de nomes activo actualmente. Para atopar o teu pod, cómpre usar unha marca de espazo de nomes, pero isto faise aburrido rapidamente, especialmente se es un programador dun equipo que usa o seu propio espazo de nomes e non quere usar esa marca para cada comando. A ver como podemos solucionar isto.
Fóra da caixa, o teu espazo de nomes activo chámase predeterminado. Se non especificas un espazo de nomes no recurso YAML, todos os comandos de Kubernetes utilizarán este espazo de nomes predeterminado activo. Desafortunadamente, tentar xestionar o espazo de nomes activo usando kubectl pode fallar. Non obstante, hai unha ferramenta moi boa chamada Kubens que facilita moito este proceso. Cando executas o comando kubens, verás todos os espazos de nomes co espazo de nomes activo resaltado.
Para cambiar o espazo de nomes activo ao espazo de nomes de proba, simplemente executa o comando de proba $kubens. Se volve executar o comando $kubens, verá que agora está asignado un novo espazo de nomes activo: proba.
Isto significa que non precisa a marca do espazo de nomes para ver o pod no espazo de nomes de proba.
Deste xeito, os espazos de nomes están ocultos entre si, pero non illados entre si. Un servizo nun espazo de nomes pode comunicarse con bastante facilidade cun servizo doutro espazo de nomes, o que adoita ser moi útil. A capacidade de comunicarse entre diferentes espazos de nomes significa que o servizo dos teus desenvolvedores pode comunicarse co servizo doutro equipo de desenvolvemento nun espazo de nomes diferente.
Normalmente, cando a súa aplicación quere acceder a un servizo de Kubernetes, utiliza o servizo de descubrimento de DNS integrado e simplemente dálle á aplicación o nome do servizo. Non obstante, ao facelo, pode crear un servizo co mesmo nome en varios espazos de nomes, o que non é aceptable.
Afortunadamente, isto é fácil de mover usando a forma expandida do enderezo DNS. Os servizos de Kubernetes expoñen os seus puntos finais mediante un modelo de DNS común. Parece algo así:
Normalmente, só precisa o nome do servizo e DNS determinará automaticamente o enderezo completo.
Non obstante, se precisa acceder a un servizo nun espazo de nomes diferente, simplemente use o nome do servizo máis o nome do espazo de nomes:
Por exemplo, se quere conectarse a unha base de datos de servizos nun espazo de nomes de proba, pode utilizar a base de datos de enderezos database.test
Se quere conectarse á base de datos do servizo no espazo de nomes prod, utiliza database.prod.
Se realmente queres illar e restrinxir o acceso ao espazo de nomes, Kubernetes permíteche facelo mediante as Políticas de rede de Kubernetes. Falarei disto no próximo episodio.
A miúdo me preguntan cantos espazos de nomes debo crear e con que propósito? Que é un dato xestionado?
Se creas demasiados espazos de nomes, só se meterán no teu camiño. Se hai poucos deles, perderá todos os beneficios desta solución. Creo que hai catro etapas principais polas que pasa toda empresa á hora de crear a súa estrutura organizativa. Dependendo da fase de desenvolvemento do seu proxecto ou empresa, pode querer adoptar unha estratexia de espazo de nomes adecuada.
Imaxina que formas parte dun pequeno equipo que está a traballar no desenvolvemento de 5-10 microservizos e podes reunir facilmente a todos os desenvolvedores nunha mesma sala. Nesta situación, ten sentido executar todos os servizos prod no espazo de nomes predeterminado. Por suposto, para obter máis flexibilidade, pode usar dous espazos de nomes, por separado para prod e dev. E moi probablemente, probas o teu desenvolvemento no teu ordenador local usando algo como Minikube.
Digamos que as cousas cambian e que agora tes un equipo en rápido crecemento que traballa en máis de 10 microservizos á vez. Chega un momento no que é necesario utilizar varios clústeres ou espazos de nomes, por separado para prod e dev. Pode dividir o equipo en varios subequipos para que cada un deles teña os seus propios microservizos e cada un destes equipos poida escoller o seu propio espazo de nomes para facilitar o proceso de xestión do desenvolvemento e liberación de software.
A medida que cada membro do equipo obtén información sobre como funciona o sistema no seu conxunto, faise cada vez máis difícil coordinar cada cambio con todos os demais desenvolvedores. Tentar facer xirar unha pila completa na túa máquina local é cada día máis difícil.
Nas grandes empresas, os desenvolvedores xeralmente non saben quen traballa exactamente en que. Os equipos comunícanse mediante contratos de servizo ou usan tecnoloxía de malla de servizos, que engade unha capa de abstracción á rede, como a ferramenta de configuración Istio. Tentar executar unha pila completa localmente non é posible. Recomendo encarecidamente usar unha plataforma de entrega continua (CD) como Spinnaker en Kubernetes. Entón, chega un punto no que cada comando precisa definitivamente o seu propio espazo de nomes. Cada equipo pode incluso escoller varios espazos de nomes para o ambiente de desenvolvemento e o ambiente de produción.
Por último, hai grandes empresas emprendedoras nas que un grupo de desenvolvedores nin sequera coñece a existencia doutros grupos. En xeral, unha empresa deste tipo pode contratar desenvolvedores de terceiros que interactúen con ela a través de API ben documentadas. Cada un destes grupos contén varios equipos e varios microservizos. Neste caso, cómpre utilizar todas as ferramentas das que falei anteriormente.
Os programadores non deberían despregar servizos manualmente e non deberían ter acceso a espazos de nomes que non lles incumban. Nesta fase, é recomendable dispor de varios clusters para reducir o “radio de explosión” das aplicacións mal configuradas, para simplificar os procesos de facturación e a xestión de recursos.
Así, o uso axeitado dos espazos de nomes por parte da túa organización permíteche facer que Kubernetes sexa máis manexable, controlable, seguro e flexible.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com