Power by Sandeep Dinesh
A medida que comienzas a construir más y más servicios encima de Kubernetes, las tareas simples se vuelven más complicadas. Por ejemplo, los equipos no pueden crear Servicios de Kubernetes o Implementaciones con el mismo nombre.
Si tienes muchísimos pods, servicios o deployments , solo listarlos tiene un coste alto de tiempo y de gestión, ¡y mucho menos administrarlos! Y estos son solo la punta del iceberg.
Veamos cómo Kubernetes Namespaces puede facilitar la gestión de los recursos de Kubernetes.
¿Qué es Namespace?
El mejor acercamiento como concepto al Namespace es como un clúster virtual dentro de su clúster de Kubernetes. Puede tener múltiples namespaces dentro de un único clúster de Kubernetes, y todos están lógicamente aislados el uno del otro. ¡Te ayudara en la gestión de equipos con organización, seguridad e incluso rendimiento!El "default" Namespace
En la mayoría de las distribuciones de Kubernetes, el clúster de inicio por defecto esta dentro del Namespace "default". De hecho, hay tres namespaces con los que Kubernetes se crea: default, kube-system (utilizado para componentes de Kubernetes) y kube-public ( usado para recursos públicos). kube-public no se usa mucho actualmente, y generalmente es una buena idea dejar solo el kube-system, especialmente en un sistema administrado como Google Kubernetes Engine. Esto deja el namespace default como el lugar donde se crean sus servicios y aplicaciones por defecto.No hay absolutamente nada de especial en este Espacio de nombres, excepto que las herramientas de Kubernetes están configuradas de serie para usar este espacio de nombres y no puede eliminarlo. Si bien es bueno para comenzar y para sistemas de producción más pequeños, recomendaría no usarlo en sistemas de producción grandes. Esto se debe a que es muy fácil para un equipo sobrescribir accidentalmente o interrumpir otro servicio sin siquiera darse cuenta. En su lugar, cree múltiples namespaces y úselos para segmentar sus servicios en zonas mas manejables.
Creando Namespaces
No tengas miedo de crear namespaces. No penalizan el rendimiento, y en muchos casos pueden mejorar el rendimiento, ya que la API de Kubernetes tendrá un conjunto de objetos más pequeño para trabajar.Crear un espacio de nombres se puede hacer con un solo comando. Si quisiera crear un espacio de nombres llamado 'test', tendrías que ejecutar:
kubectl create namespace testO puede crear un archivo YAML y aplicarlo como cualquier otro recurso de Kubernetes.
test.yaml:
kind: Namespace
apiVersion: v1
metadata:
name: test
labels:
name: test
kubectl apply -f test.yamlVisualización de Namespaces
Puede ver todos los namespaces con el siguiente comando:kubectl get namespace$kubectl get namespace
NAME STATUS AGE
default Active 5d
kube-public Active 5d
kube-sistem Active 5d
test Active 3mPuede ver los tres namespaces basicos, así como el nuevo espacio de nombres llamado 'test'.
Crear recursos en el namespace
Echemos un vistazo a un simple YAML para crear un Pod:apiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: mypod
spec:
containers:
- name: mypod
image: nginxNormalmente en los ejemplos no se indica el namespace en ningún lado. Si ejecuta una aplicación `kubectl` en este archivo, creará el Pod en el espacio de nombres activo actual. Este será el espacio de nombres "default" a menos que lo cambie.
Hay dos formas de decirle explícitamente a Kubernetes en qué Namespace desea crear sus recursos.
Una forma es establecer el indicador de "namespace" al crear el recurso:
kubectl apply -f pod.yaml --namespace=testTambién puede especificar un espacio de nombres en la declaración YAML.
apiVersion: v1
kind: Pod
metadata:
name: mypod
namespace: test
labels:
name: mypod
spec:
containers:
- name: mypod
image: nginxSi especifica un espacio de nombre en la declaración YAML, el recurso siempre se creará en ese espacio de nombres. Si intenta utilizar el indicador "namespace" para establecer otro espacio de nombres, el comando fallará.
Visualización de recursos en el Namespace
Si intentas encontrar tus Pod, ¡es posible que notes que no los ves!$ kubectl get pods
No resources found.No se encontraron recursos. Esto se debe a que todos los comandos se ejecutan contra el namespace actualmente activo. Para encontrar su Pod, debe usar el indicador "namespace".
$ kubectl get pods --namespace=test
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 10sEsto puede ser incomdo, especialmente si es un desarrollador que trabaja en un equipo que usa su propio Espacio de nombres para todo y no desea usar el indicador de "espacio de nombre" para cada comando. Veamos un ejemplo de cómo podemos facilitar este caso.
Administrar tu namespace activo
Por defecto al iniciar el namespace es "default". A menos que especifique un Namespace en el YAML, todos los comandos de Kubernetes usarán el Namespace activo.Desafortunadamente, tratar de administrar tu espacio de nombre activo con kubectl puede ser una incomodo. Afortunadamente, hay una herramienta realmente buena llamada kubens (creada por Ahmet Alp Balkan) que hace que sea muy fácil.
Cuando ejecuta el comando 'kubens', debería ver todos los namespaces, con el espacio de nombres activo resaltado:
$ kubens
default
kube-public
kube-system
test
Para cambiar su espacio de nombres activo al espacio de nombres 'test', ejecuta:
kubens test
$ kubens
default
kube-public
kube-system
testAhora, si ejecuta los comandos kubectl, namespace será 'test' en lugar de 'default'. Esto significa que no necesita el indicador de espacio de nombres para ver el pod en el namespace de test.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 10mComunicación entre distintos Namespaces
Los namespaces están "ocultos" entre sí, pero no están completamente aislados por defecto. Un servicio en un namespaces puede hablar con un servicio en otro namespaces. Esto a menudo puede ser muy útil, por ejemplo para que el servicio de su equipo en su namespaces se comunique con el servicio de otro equipo en otro namespaces.Cuando su aplicación quiere acceder a los servicios de Kubernetes, puede usar el descubrimiento del servicio DNS integrado y simplemente apuntar su aplicación a nombre del Servicio. Sin embargo, puede crear un servicio con el mismo nombre en múltiples namespaces. Afortunadamente, es fácil evitar esto al usar la forma expandida de la dirección DNS.
Los servicios en Kubernetes exponen su punto final utilizando un patrón DNS común. Se parece a esto:
<Service Aame>.<Namespace Name>.svc.cluster.localNormalmente, solo necesita el nombre del Servicio y el DNS se resolverá automáticamente en la dirección completa. Sin embargo, si necesita acceder a un Servicio en otro Espacio de nombre simplemente use el Nombre del servicio más el nombre del namespaces.
Por ejemplo, si desea conectarse al servicio de "base de datos" en el espacio de nombres de "test", puede usar la siguiente dirección:
database.testSi desea conectarse al servicio de "base de datos" en el espacio de nombres de "production", puede usar la siguiente dirección:
database.productionAdvertencia: si crea un espacio de nombres que se asigna a un TLD como "com" u "org", y luego crea un servicio que tiene el mismo nombre que un sitio web, como "google" o "reddit", Kubernetes interceptará las solicitudes a " google.com "o" reddit.com "y envíelos a su Servicio. Esto a menudo puede ser muy útil para probar, ¡pero también puede liar las cosas fácilmente en su clúster!
Nota: Si desea aislar los namespaces, debe usar las políticas de red para lograr esto. Estén atentos para más sobre esto en un episodio futuro!
Granularidad del Namespaces
Una pregunta común que recibo es cuántos namespaces crear y con qué propósito. ¿Cuantos son necesarios para ser manejable? Si se crean demasiados namespaces se interpongan en su camino, pero haga muy pocos y se pierden los beneficios.Creo que la respuesta radica en en qué etapa se encuentra su proyecto o compañía: desde un equipo pequeño hasta una gran empresa, cada uno tiene su propia estructura organizativa. Dependiendo de su situación, puede adoptar la estrategia concrete en su namespaces.
En una empresa pequeña
En este escenario, usted es parte de un pequeño equipo que está trabajando en 5-10 microservicios y puede reunir fácilmente a todos al rededor de unas pizzas. En esta situación, tiene sentido lanzar todos los servicios de producción en el espacio de nombres "default". Es posible que desee tener un espacio de nombres de "producción" y "desarrollo" si quiere gestionar mas fino, pero probablemente esté probando su entorno de desarrollo en su máquina local usando algo como Minikube.En una empresa que se expande
En este escenario, tiene un equipo en rápido crecimiento que está trabajando en más de 10 microservicios. Está empezando a dividir el equipo en múltiples sub-equipos que cada uno posee sus propios microservicios. Si bien todos pueden saber cómo funciona el sistema completo, cada vez es más difícil coordinar cada cambio con los demás. Tratar de hacer girar la pila completa en su máquina local se vuelve más complicado cada día.En este punto, es necesario usar múltiples clusters o namespaces para producción y desarrollo. Cada equipo puede elegir tener su propio espacio de nombre para una administración más fácil.
Empresa que crece
En una gran empresa, no todos conocen a los demás. Los equipos están trabajando en funciones que otros equipos podrían no conocer. Los equipos están utilizando contratos de servicios para comunicarse con otros microservicios (por ejemplo, gRPC) y mallas de servicio para coordinar la comunicación (por ejemplo, istio). Tratar de ejecutar toda la pila localmente es imposible. Se recomienda encarecidamente utilizar un sistema de CD compatible con Kubernetes (p. Ej., Spinnaker).En este punto, cada equipo definitivamente necesita su propio namespaces. Cada equipo incluso puede optar por múltiples namespaces para ejecutar sus entornos de desarrollo y producción. Configurar RBAC y ResourceQuotas es una buena idea también. Múltiples clusters comienzan a tener mucho sentido, pero pueden no ser necesarios.
Gran empresa
En esta escala, hay grupos que ni siquiera conocen la existencia de otros grupos. Los grupos también pueden ser compañías externas, y los servicios se consumen a través de API bien documentadas. Cada grupo tiene múltiples equipos que tienen múltiples microservicios. Usar todas las herramientas que mencioné anteriormente son necesarias; las personas no deberían desplegar servicios a mano y deberían estar bloqueados fuera de los namespaces que no les pertenecen.En este punto, probablemente tenga sentido tener múltiples clusters para reducir el radio de infestación de aplicaciones mal configuradas y facilitar la administración de recursos y facturación.
