Mejores prácticas de Kubernetes. Organización de Kubernetes con espacio de nombres

Mejores prácticas de Kubernetes. Creación de contenedores pequeños

A medida que comienza a crear más y más servicios de Kubernetes, las tareas fáciles de comenzar se vuelven más complicadas. Por ejemplo, los equipos de desarrollo no pueden crear servicios o implementaciones con el mismo nombre. Si tiene miles de hogares, una simple lista de ellos llevará mucho tiempo, sin mencionar que les proporcionará una gestión normal. Y esto es solo la punta del iceberg.

Echemos un vistazo a cómo el espacio de nombres hace que la gestión de recursos de Kubernetes sea más fácil. Entonces, ¿qué es exactamente un espacio de nombres? El espacio de nombres puede considerarse como un clúster virtual dentro de su clúster de Kubernetes. Puede tener múltiples espacios de nombres aislados entre sí dentro del mismo clúster de Kubernetes. Realmente pueden ayudarlo a usted y a sus 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 está "listo para usar" con un espacio de nombres llamado "predeterminado". En realidad, hay tres espacios de nombres con los que se ocupa Kubernetes: default, kube-system y kube-public. Actualmente, Kube-public no se usa con mucha frecuencia.



No tocar el espacio de nombres de Kube es una buena idea, especialmente en un sistema administrado como Google Kubernetes Engine. Utiliza el espacio de nombres predeterminado como el lugar donde se crean sus servicios y aplicaciones. No tiene absolutamente nada de especial, excepto que Kubernetes está listo para usar y no puede eliminarlo. Esto es excelente para comenzar y sistemas con poco rendimiento, pero no recomendaría usar el espacio de nombres predeterminado en sistemas de producción grandes. En el último caso, un equipo de desarrollo puede reescribir fácilmente el código de otra persona e interrumpir el trabajo de otro equipo sin siquiera darse cuenta.

Por lo tanto, debe crear varios espacios de nombres y usarlos para segmentar sus servicios en enlaces manejables. Se puede crear un espacio de nombres con un solo comando. Si desea crear un espacio de nombres llamado prueba, use el comando $ kubectl create namespace test o simplemente cree un archivo YAML y úselo como cualquier otro recurso de Kubernetes.



Puede ver todos los espacios de nombres utilizando el comando $ kubectl get namespace.



Después de su ejecución, verá tres espacios de nombres integrados y un nuevo espacio de nombres llamado "prueba". Veamos un archivo YAML simple para crear pods. Puede notar que no hay mención de un espacio de nombres en él.



Si usa kubectl para ejecutar este archivo, creará el módulo mypod en el espacio de nombres activo actual. Este será el espacio de nombres predeterminado hasta que lo cambie. Hay 2 formas de decirle a Kubernetes en qué espacio de nombres desea crear su recurso. La primera forma es usar el indicador de espacio de nombres al crear el recurso.



La segunda forma es especificar el espacio de nombres en la declaración YAML.



Si especifica un espacio de nombres en YAML, el recurso siempre se creará en este espacio. Si intenta usar un espacio de nombres diferente cuando usa el indicador de espacio de nombres, el comando fallará. Ahora, si intentas encontrar tu pod, no puedes hacerlo.



Esto se debe a que todos los comandos se ejecutan fuera del espacio de nombres activo actual. Para encontrar su pod, debe usar el indicador de espacio de nombres, pero esto es rápidamente aburrido, especialmente si trabaja como desarrollador en un grupo que usa su propio espacio de nombres y no quiere usar dicho indicador para cada comando individual. Veamos cómo se puede solucionar esto.



Fuera de la caja, su espacio de nombres activo se llama predeterminado. Si no especifica el espacio de nombres en el YAML del recurso, todos los comandos de Kubernetes utilizarán este espacio de nombres predeterminado activo. Desafortunadamente, un intento de administrar el espacio de nombres activo usando kubectl puede fallar. Sin embargo, existe una muy buena herramienta llamada Kubens, que simplifica enormemente 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 al espacio de nombres de prueba, simplemente ejecute el comando de prueba $ kubens. Si después de esto ingresa el comando $ kubens nuevamente, puede ver que ahora se asigna un nuevo espacio de nombres activo: prueba.



Esto significa que no necesita un indicador de espacio de nombres para ver el pod en el espacio de nombres de prueba.



Por lo tanto, los espacios de nombres están ocultos entre sí, pero no están aislados entre sí. Un servicio de un espacio de nombres puede comunicarse fácilmente con un servicio en otro espacio de nombres, que a menudo es muy útil. La capacidad de comunicarse entre diferentes espacios de nombres significa que el servicio de sus desarrolladores puede interactuar con el servicio de otro comando dev en un espacio de nombres diferente.

Por lo general, cuando su aplicación desea acceder al servicio Kubernetes, utiliza el servicio de descubrimiento de DNS incorporado y simplemente le da a su aplicación el nombre del servicio. Sin embargo, puede crear un servicio con el mismo nombre en varios espacios de nombres, que no es válido.



Afortunadamente, esto se evita fácilmente 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 parece a esto: por



regla general, solo necesita el nombre del servicio y DNS determinará automáticamente la dirección completa.



Sin embargo, si necesita acceder al servicio en un espacio de nombres diferente, simplemente use el nombre del servicio más el nombre del espacio de nombres:



por ejemplo, si desea conectarse a la base de datos del servicio en el espacio de nombres de prueba, puede usar la base de datos de direcciones de la base de datos. Prueba



Si desea conectarse a la base de datos de servicio en el espacio de nombres de prod, está utilizando database.prod.



Si realmente desea aislar y restringir el acceso al espacio de nombres, Kubernetes le permite hacerlo utilizando las Políticas de red de Kubernetes. Hablaré sobre esto en la próxima serie.

A menudo me preguntan cuántos espacios de nombres deben crearse y con qué fines. ¿Qué es un dato administrado?

Si crea demasiados espacios de nombres, simplemente se interponen en su camino. Si hay muy pocos de ellos, perderá todas las ventajas de tal solución. Creo que hay cuatro etapas principales por las que pasa cada empresa en el proceso de crear su propia estructura organizativa. Dependiendo de la etapa de desarrollo en la que se encuentre su proyecto o empresa, puede adoptar la estrategia adecuada para crear un espacio de nombres.

Imagine que forma parte de un pequeño equipo que trabaja en el desarrollo de 5-10 microservicios y puede reunir fácilmente a todos los desarrolladores en una habitación. En esta situación, tiene sentido ejecutar todos los servicios de productos en el espacio de nombres predeterminado. Por supuesto, para un mayor alcance de acción, puede usar 2 espacios de nombres, por separado para prod y dev. Y lo más probable es que esté probando su desarrollo en una computadora local utilizando algo como Minikube.

Suponga que las condiciones han cambiado y ahora tiene un equipo en rápido crecimiento que trabaja simultáneamente en más de 10 microservicios. Llega un momento en que necesita usar múltiples clústeres o espacios de nombres, por separado para prod y dev. Puede dividir un equipo en varios subgrupos para que cada uno de ellos 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 lanzamiento de software.



A medida que cada miembro del equipo tiene una idea de cómo funciona el sistema en su conjunto, coordinar cada cambio con todos los demás desarrolladores se vuelve cada vez más difícil. Intentar hacer girar una pila completa en su computadora local es cada día más difícil.

En las grandes empresas, los desarrolladores no saben en absoluto quién está trabajando exactamente en qué. Los equipos se comunican mediante contratos de servicio o utilizan la tecnología de malla de servicios, que agrega una capa de abstracción a través de la red, como la herramienta de configuración Istio. Intentar ejecutar toda la pila localmente simplemente no es posible. Recomiendo utilizar una plataforma de entrega continua (CD) como Spinnaker en Kubernetes. Entonces, llega el momento en que cada equipo definitivamente necesita su propio espacio de nombres. Cada comando puede incluso seleccionar múltiples espacios de nombres para el entorno de desarrollo y el entorno de producción.

Finalmente, hay grandes empresas emprendedoras en las que un grupo de desarrollo ni siquiera es consciente de la existencia de otros grupos. Dicha empresa generalmente puede contratar desarrolladores externos que interactúen a través de API bien documentadas. En cada uno de estos grupos hay varios equipos y varios microservicios. En este caso, debe usar todas las herramientas que mencioné anteriormente.



Los programadores no deben implementar servicios manualmente y no deben tener acceso a espacios de nombres que no les conciernen. En esta etapa, es aconsejable tener varios grupos para reducir el "radio de explosión" de las aplicaciones mal configuradas, para simplificar los procesos de facturación y gestión de recursos.

Por lo tanto, el uso correcto de los espacios de nombres de su organización hace que Kubernetes sea más manejable, manejable, seguro y flexible.

Mejores prácticas de Kubernetes. Prueba de viabilidad de Kubernetes con pruebas de preparación y vitalidad

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? ¡Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?