A medida que comienzas a crear cada vez más servicios de Kubernetes, las tareas que al principio parecen simples se vuelven más complejas. Por ejemplo, los equipos de desarrollo no pueden crear servicios o despliegues con el mismo nombre. Si tienes miles de pods, simplemente enumerarlos tomará mucho tiempo, sin mencionar garantizar una gestión adecuada. Y eso es solo la punta del iceberg.
Veamos cómo el espacio de nombres facilita la gestión de los recursos de Kubernetes. Entonces, ¿qué es un espacio de nombres? Se puede considerar un espacio de nombres como un clúster virtual dentro de tu clúster de Kubernetes. Puedes tener varios espacios de nombres aislados entre sí dentro de un solo clúster de Kubernetes. Realmente pueden ayudarte a ti y a tus equipos con la organización, la seguridad e incluso el rendimiento del sistema.
En la mayoría de las distribuciones de Kubernetes, el clúster "viene por defecto" con un espacio de nombres denominado "default". En realidad, hay tres espacios de nombres con los que Kubernetes trabaja: default, kube-system y kube-public. En la actualidad, kube-public no se utiliza con mucha frecuencia.
No tocar el espacio de nombres kube es una buena idea, especialmente en un sistema gestionado como Google Kubernetes Engine. Utiliza el espacio de nombres "default" como el lugar donde se crean tus servicios y aplicaciones. No hay nada particularmente especial en él, excepto que Kubernetes está configurado "por defecto" para usarlo, y no puedes eliminarlo. Es perfecto para comenzar y para sistemas con poco rendimiento, pero no recomendaría usar el espacio de nombres default en sistemas de producción grandes. En ese último caso, un equipo de desarrollo podría fácilmente sobrescribir el código de otro y romper el trabajo de otro equipo, sin siquiera darse cuenta.
Por lo tanto, es recomendable crear varios espacios de nombres y utilizarlos para segmentar tus servicios en unidades gestionadas. Puedes crear un espacio de nombres con un solo comando. Si deseas crear un espacio de nombres llamado test, utiliza el comando $ kubectl create namespace test o simplemente crea un archivo YAML y utilízalo como cualquier otro recurso de Kubernetes.
Puede ver todos los espacios de nombres mediante el comando $ kubectl get namespace.
Después de ejecutarlo, verá tres espacios de nombres incorporados y un nuevo espacio de nombres llamado «test». Vamos a revisar un archivo YAML simple destinado a crear un pod. Puede notar que no hay ninguna mención al espacio de nombres.
Si aplica kubectl para ejecutar este archivo, creará un módulo mypod en el espacio de nombres activo actual. Este será el espacio de nombres predeterminado hasta que lo cambie. Hay 2 maneras de indicarle a Kubernetes en qué espacio de nombres desea crear su recurso. La primera manera es usar la bandera de espacio de nombres al crear el recurso.
La segunda manera es especificar el espacio de nombres en la declaración YAML.
Si especifica el espacio de nombres en YAML, el recurso siempre se creará en ese espacio. Si intenta usar otro espacio de nombres al usar la bandera de espacio de nombres, el comando generará un error. Ahora, si intenta buscar su pod, no podrá hacerlo.
Esto es porque todos los comandos se ejecutan fuera del espacio de nombres activo actual. Para encontrar su pod, necesita usar la bandera de espacio de nombres, sin embargo, esto puede volverse tedioso, especialmente si trabaja como desarrollador en un grupo que utiliza su propio espacio de nombres y no desea usar esta bandera para cada comando individual. Veamos cómo se puede solucionar esto.
De forma predeterminada, su espacio de nombres activo se llama default. Si no especifica un espacio de nombres en el recurso YAML, todos los comandos de Kubernetes utilizarán este espacio de nombres activo por defecto. Desafortunadamente, intentar gestionar el espacio de nombres activo con kubectl puede fallar. Sin embargo, hay una herramienta muy buena llamada Kubens que simplifica mucho este proceso. Cuando ejecuta el comando kubens, ve todos los espacios de nombres con el espacio de nombres activo resaltado.
Para cambiar el espacio de nombres activo a test, simplemente ejecute el comando $ kubens test. Si luego vuelve a introducir el comando $ kubens, puede ver que ahora se ha destacado un nuevo espacio de nombres activo: test.
Esto significa que no necesitas una etiqueta de espacio de nombres para ver el pod en el espacio de nombres test.
Así, los espacios de nombres están ocultos entre sí, pero no están aislados uno del otro. Un servicio de un namespace puede comunicarse bastante fácilmente con un servicio en otro espacio de nombres, lo cual es a menudo muy útil. La posibilidad de comunicación entre diferentes espacios de nombres significa que el servicio de tus desarrolladores puede interactuar con el servicio de otro equipo de desarrollo en otro namespace.
Generalmente, cuando tu aplicación quiere acceder a un servicio de Kubernetes, usas el servicio de descubrimiento DNS integrado y simplemente le indicas a tu aplicación el nombre del servicio. Sin embargo, puedes crear un servicio con el mismo nombre en varios espacios de nombres, lo cual no es permitido.
Afortunadamente, esto es fácil de evitar utilizando la forma expandida de la dirección DNS. Los servicios en Kubernetes exponen sus puntos finales utilizando un patrón DNS común. Se ve algo así:
Por lo general, solo necesitas el nombre del servicio, y DNS automáticamente resolverá la dirección completa.
Sin embargo, si necesitas acceder a un servicio en otro espacio de nombres, simplemente usa el nombre del servicio más el nombre del espacio de nombres:
Por ejemplo, si quieres conectarte a la base de datos del servicio en el espacio de nombres de prueba, puedes usar la dirección database.test.
Si deseas conectarte a la base de datos del servicio en el espacio de nombres de producción, usas database.prod.
Si realmente deseas aislar y restringir el acceso al espacio de nombres, Kubernetes permite hacerlo utilizando políticas de red de Kubernetes Network Policies. De esto hablaré en la siguiente serie.
A menudo me preguntan cuántos espacios de nombres deben crearse y con qué propósitos. ¿Qué es, entonces, un fragmento de datos administrado?
Si crea demasiados espacios de nombres, simplemente se interpondrán en su camino. Si hay muy pocos, perderá todas las ventajas de tal solución. Creo que hay cuatro etapas principales que cada empresa atraviesa en el proceso de crear su estructura organizativa. Dependiendo de la etapa de desarrollo en la que se encuentre su proyecto o empresa, puede adoptar la estrategia adecuada para la creación del espacio de nombres.
Imagina que eres parte de un pequeño equipo que trabaja en el desarrollo de entre 5 y 10 microservicios y puedes reunir a todos los desarrolladores en una sola sala. En esta situación, tiene sentido ejecutar todos los servicios de producción en el espacio de nombres predeterminado. Por supuesto, para tener más espacio de maniobra, puede utilizar 2 espacios de nombres: uno para producción y otro para desarrollo. Y es muy probable que esté probando su desarrollo en su computadora local utilizando algo como Minikube.
Supongamos que las condiciones han cambiado y ahora tiene un equipo de rápida expansión que trabaja simultáneamente en más de 10 microservicios. Llega un momento en que es necesario utilizar varios clústeres o espacios de nombres, separados para producción y desarrollo. Puede dividir el equipo en varios subgrupos para que cada uno tenga sus propios microservicios y cada uno de estos equipos pueda elegir su propio espacio de nombres para facilitar el proceso de gestión del desarrollo y la entrega de software.
A medida que cada miembro del equipo comprende cómo funciona el sistema en su conjunto, coordinar cada cambio con los demás desarrolladores se vuelve cada vez más difícil. Intentar ejecutar la pila completa en su computadora local se vuelve más complejo día a día.
En las grandes empresas, los desarrolladores a menudo no saben quién está trabajando en qué. Los equipos se comunican a través de contratos de servicio o utilizan la tecnología Service mesh, que añade un nivel de abstracción sobre la red, como la herramienta de configuración Istio. Intentar ejecutar toda la pila localmente es simplemente imposible. Recomiendo encarecidamente utilizar una plataforma de entrega continua (CD) como Spinnaker en Kubernetes. Así que llega un momento en el que cada equipo definitivamente necesita su propio espacio de nombres. Cada equipo incluso puede elegir varios espacios de nombres para el entorno de desarrollo (dev) y el entorno de producción (prod).
Finalmente, existen grandes empresas donde un grupo de desarrolladores ni siquiera sabe de la existencia de otros grupos. Esta empresa puede incluso contratar desarrolladores externos que interactúan a través de API bien documentadas. Dentro de cada uno de estos grupos, hay varios equipos y varios microservicios. En este caso, es necesario utilizar todas las herramientas que mencioné anteriormente.
Los programadores no deben implementar servicios manualmente y no deberían tener acceso a los espacios de nombres que no les conciernen. En esta etapa, es sensato tener varios clústeres para reducir el "radio de explosión" de aplicaciones mal configuradas, para simplificar los procesos de facturación y la gestión de recursos.
Así, el uso adecuado de los espacios de nombres por parte de su organización permite que Kubernetes sea más manejable, controlable, seguro y flexible.
Un poco de publicidad 🙂
Gracias por permanecer con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendando a tus conocidos, , un análogo único de servidores entry-level que hemos diseñado para Ti: (disponibles opciones con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
¿Dell R730xd a mitad de precio en el centro de datos Equinix Tier IV en Ámsterdam? Solo aquí ¡en los Países Bajos! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ¡desde $99! Lee sobre cómo
Fuente: habr.com
