Siempre ha sido difícil alojar de forma segura una gran cantidad de usuarios en un solo clúster de Kubernetes. La razón principal es que todas las organizaciones usan Kubernetes de manera diferente, por lo que es poco probable que un único modelo multiusuario funcione para todos. En cambio, Kubernetes ofrece componentes para crear su propia solución, como el Control de acceso basado en roles (RBAC) y NetworkPolicies; cuanto mejores sean estos componentes, más fácil será crear un clúster multiusuario seguro.
Los espacios de nombres corren al rescate
Con mucho, el más importante de estos componentes son los espacios de nombres . Son la base de casi todas las políticas de uso compartido de planos de control y seguridad en Kubernetes. Por ejemplo, RBAC, NetworkPolicies y ResourceQuotas admiten espacios de nombres de forma predeterminada, mientras que objetos como Secret, ServiceAccount e Ingress están disponibles gratuitamente dentro de un espacio, pero completamente aislados de otros .
Los espacios de nombres tienen un par de características clave que los hacen ideales para la aplicación de políticas. Primero, se pueden usar para representar propiedades . La mayoría de los objetos de Kubernetes deberíanestar en cualquier espacio de nombres. Al utilizar espacios de nombres para representar la propiedad, siempre puede contar con que esos objetos tengan un propietario.
En segundo lugar, solo los usuarios con los derechos adecuados pueden crear y utilizar espacios de nombres . Necesita privilegios elevados para crear espacios de nombres, y otros usuarios necesitan permiso explícito para trabajar con ellos, es decir, para crear, ver o modificar objetos en esos espacios de nombres. Por lo tanto, primero se crea un espacio de nombres con un elaborado conjunto de políticas, y solo después de eso, los usuarios sin privilegios pueden crear objetos "regulares" como pods y servicios.
Restricciones del espacio de nombres
Desafortunadamente, en la práctica, los espacios de nombres no son lo suficientemente flexibles y no encajan bien en algunos casos de uso comunes. Por ejemplo, un determinado equipo posee varios microservicios con diferentes secretos y cuotas. Idealmente, deberían dividir estos servicios en espacios de nombres separados para aislarlos entre sí, pero esto presenta dos problemas.
Primero, estos espacios de nombres carecen de un concepto único de propiedad, a pesar de que ambos pertenecen al mismo equipo. Esto significa que no solo Kubernetes no sabe nada sobre el hecho de que estos espacios de nombres tienen un propietario, sino que también carece de la capacidad de aplicar políticas globales a todos los espacios de nombres controlados a la vez.
En segundo lugar, como saben, la autonomía es la clave para un trabajo en equipo eficaz. Dado que la creación de espacios de nombres requiere privilegios elevados, es poco probable que alguien del equipo de desarrollo tenga estos privilegios. En otras palabras, cada vez que un equipo decide crear un nuevo espacio de nombres, debe comunicarse con el administrador del clúster. Esto puede ser perfectamente aceptable para una empresa pequeña, pero a medida que crece, el efecto negativo de dicha organización se vuelve más pronunciado.
Introducción a los espacios de nombres jerárquicos
Los espacios de nombres jerárquicos son un nuevo concepto desarrollado por el grupo de trabajo de multicliente de Kubernetes ( wg-multitenancy ) para abordar estos problemas. En forma simplificada, un espacio de nombres jerárquico es un espacio de nombres de Kubernetes regular con un pequeño recurso personalizado incluido que apunta a un espacio de nombres principal (opcional). Esto extiende el concepto de propiedad a los espacios de nombres en sí mismos , no solo a los objetos dentro de ellos.
El concepto de propiedad también implementa dos tipos adicionales de relaciones:
- : namespace' . : subnamespaces, .
Esto resuelve ambos problemas de un equipo de desarrollo típico. El administrador del clúster puede crear un espacio "raíz" para él junto con las políticas necesarias y delegar la autoridad para crear subespacios a los miembros del equipo. De esta manera, los desarrolladores pueden crear subnombres para su propio uso sin violar las políticas establecidas por los administradores del clúster.
Un poco de practica
Los espacios de nombres jerárquicos se implementan mediante una extensión de Kubernetes llamada Controlador de espacio de nombres jerárquico o HNC . HNC consta de dos componentes:
- Manager opera en un clúster, administra los subespacios de nombres, distribuye los objetos de la política, asegura que las jerarquías sean válidas y administra los puntos de extensión.
- Un complemento de kubectl llamado
kubectl-hnspermite a los usuarios interactuar con el administrador.
La guía de instalación de componentes se puede encontrar en la página de lanzamientos del repositorio del proyecto.
Echemos un vistazo a cómo funciona HNC. Supongamos que no tengo el privilegio de crear espacios de nombres, pero puedo explorar el espacio de nombres
team-ay crear subespacios de nombres en él *. El complemento me permite ingresar el siguiente comando:
$ kubectl hns create svc1-team-a -n team-a
* Técnicamente hablando, creas un pequeño objeto llamado "ancla de subespacio de nombres" en el espacio principal y luego HNC crea un subespacio de nombres.
Esto creará un espacio de nombres
svc1-team-a. Tenga en cuenta que los subespacios de nombres no son diferentes de los espacios de nombres de Kubernetes normales, por lo que sus nombres deben ser únicos.
Puede ver la estructura resultante usando el comando
tree:
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
Si hay políticas en el espacio principal, se copiarán en el secundario *. Por ejemplo, suponga que
team-atiene un RBAC RoleBinding llamado sres. Este RoleBinding también aparecerá en el espacio de nombres correspondiente:
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
* De forma predeterminada, solo se redistribuyen los roles y las vinculaciones de roles en RBAC, pero puede configurar HNC para propagar cualquier objeto de Kubernetes.
Finalmente, HNC agrega etiquetas a estos espacios de nombres con información útil sobre la jerarquía. Se pueden utilizar para aplicar otras políticas. Por ejemplo, puede crear la siguiente NetworkPolicy:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
Esta política se propagará a los descendientes
team-ay también permitirá el tráfico de entrada entre todos estos espacios de nombres. Solo HNC puede asignar la etiqueta "árbol". Se garantiza que refleja la jerarquía actual.
Los detalles sobre la funcionalidad HNC se pueden encontrar en el manual del usuario .
Próximos pasos y participación en el proceso
Si cree que el espacio de nombres jerárquico es útil en su organización, la versión HNC v0.5.1 está disponible en GitHub (disponible desde el 28 de agosto para la versión v0.5.2 - ca. Perevi ..) . Nos gustaría saber qué piensa de él, qué problemas resuelve con él y qué características le gustaría agregarle. Al igual que con cualquier software en las primeras etapas de desarrollo, se debe tener cuidado al utilizar HNC en producción. Y cuantos más comentarios recibamos, más rápido podemos llegar a HNC 1.0.
También agradecemos las contribuciones de colaboradores externos, ya sean correcciones de errores / información sobre ellos o ayuda a crear prototipos de nuevas características como excepciones, monitoreo mejorado, cotización de recursos jerárquicos u optimización de configuración.
Puede contactarnos en el repositorio , boletín informativo o Slack . ¡Esperamos sus comentarios!
El anuncio original fue realizado por Adrian Ludwin , ingeniero de software y líder técnico del controlador de espacio de nombres jerárquico.
¡Prima! Hoja de ruta y problemas
Por favor, publique números: ¡cuanto más, más divertido! Los errores se analizarán primero y se priorizarán las solicitudes de funciones, después de lo cual se incluirán en el plan de trabajo o en la acumulación.
HNC aún no ha alcanzado el estado GA, así que tenga cuidado al usarlo en clústeres con objetos de configuración que no puede permitirse perder (por ejemplo, aquellos que no están almacenados en un repositorio Git).
Todos los temas de HNC están incluidos en el plan de trabajo correspondiente. Por el momento, se han implementado o planificado las siguientes etapas principales de este plan:
- v1.0: finales del I - principios del II trimestre de 2021; Se recomienda HNC para producción.
- v0.8: principios de 2021; pueden aparecer nuevas funciones críticas.
- v0.7: finales de 2020; lo más probable es que aparezca la API v1beta1.
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
PD del traductor
Lea también en nuestro blog: