[ Editor : Esta publicación es un extracto de nuestro completo libro electrónico, Gestión del tráfico de Kubernetes con F5 NGINX: Una guía práctica . Descárgalo gratis hoy .]
A medida que las organizaciones escalan, los flujos de trabajo de desarrollo y operativos en Kubernetes se vuelven más complejos. Generalmente es más rentable (y puede ser más seguro) que los equipos compartan clústeres y recursos de Kubernetes, en lugar de que cada equipo tenga su propio clúster. Pero sus implementaciones pueden sufrir daños críticos si los equipos no comparten esos recursos de forma segura o si los piratas informáticos explotan sus configuraciones.
Las prácticas de múltiples inquilinos y el aislamiento del espacio de nombres a nivel de red y recursos ayudan a los equipos a compartir recursos de Kubernetes de forma segura. También puede reducir significativamente la magnitud de las infracciones al aislar las aplicações por inquilino. Este método ayuda a aumentar la resiliencia porque solo se pueden comprometer subsecciones de aplicações propiedad de equipos específicos, mientras que los sistemas que proporcionan otras funcionalidades permanecen intactos.
El controlador de ingreso NGINX admite múltiples modelos de múltiples inquilinos, pero vemos dos patrones principales. El patrón de proveedor de servicios de infraestructura generalmente incluye múltiples implementaciones de NGINX Ingress Controller con aislamiento físico, mientras que el patrón empresarial generalmente utiliza una implementación de NGINX Ingress Controller compartida con aislamiento de espacio de nombres. En esta sección exploramos el patrón empresarial en profundidad; para obtener información sobre cómo ejecutar múltiples controladores de ingreso NGINX, consulte nuestra documentación .
NGINX Ingress Controller admite tanto el recurso Ingress de Kubernetes estándar como los recursos Ingress de NGINX personalizados, lo que permite una gestión del tráfico más sofisticada y la delegación del control sobre la configuración a varios equipos. Los recursos personalizados son VirtualServer, VirtualServerRoute , GlobalConfiguration , TransportServer y Policy .
Con NGINX Ingress Controller, los administradores de clúster utilizan recursos de VirtualServer para aprovisionar reglas de dominio de Ingress (nombre de host) que enrutan el tráfico externo a las aplicações backend, y recursos de VirtualServerRoute para delegar la administración de URL específicas a los propietarios de aplicação y equipos de DevOps.
Hay dos modelos que puede elegir al implementar la multitenencia en su clúster de Kubernetes: autoservicio completo y autoservicio restringido .
En un modelo de autoservicio completo, los administradores no participan en los cambios diarios en la configuración del controlador de ingreso NGINX. Son responsables únicamente de implementar el controlador de ingreso NGINX y el servicio Kubernetes que expone la implementación externamente. Luego, los desarrolladores implementan aplicações dentro de un espacio de nombres asignado sin involucrar al administrador. Los desarrolladores son responsables de administrar los secretos TLS, definir la configuración de equilibrio de carga para los nombres de dominio y exponer sus aplicações mediante la creación de servidores virtuales o recursos Ingress estándar.
Para ilustrar este modelo, replicamos la aplicação de muestra bookinfo (creada originalmente por Istio) con dos subdominios, a.bookinfo.com
y b.bookinfo.com
, como se muestra en el siguiente diagrama. Una vez que el administrador instala e implementa NGINX Ingress Controller en el espacio de nombres nginx-ingress
(resaltado en verde), los equipos DevA (rosa) y DevB (violeta) crean sus propios recursos de VirtualServer e implementan aplicações aisladas dentro de sus espacios de nombres ( A
y B
respectivamente).
Los equipos DevA y DevB establecen reglas de ingreso para sus dominios para enrutar conexiones externas a sus aplicações.
El equipo DevA aplica el siguiente objeto de recurso VirtualServer para exponer aplicações para el dominio a.bookinfo.com
en el espacio de nombres A.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: bookinfo
namespace: A
spec:
host: a.bookinfo.com
upstreams:
- name: productpageA
service: productpageA
port: 9080
routes:
- path: /
action:
pass: productpageA
De manera similar, el equipo DevB aplica el siguiente recurso VirtualServer para exponer aplicações para el dominio b.bookinfo.com
en el espacio de nombres B.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: bookinfo
namespace: B
spec:
host: b.bookinfo.com
upstreams:
- name: productpageB
service: productpageB
port: 9080
routes:
- path: /
action:
pass: productpageB
En un modelo de autoservicio restringido, los administradores configuran los recursos de VirtualServer para enrutar el tráfico que ingresa al clúster al espacio de nombres apropiado, pero delegan la configuración de las aplicações en los espacios de nombres a los equipos de desarrollo responsables. Cada uno de estos equipos es responsable únicamente de su subruta de aplicação tal como está instanciada en el recurso VirtualServer y utiliza los recursos VirtualServerRoute para definir reglas de tráfico y exponer subrutas de aplicação dentro de su espacio de nombres.
Como se ilustra en el diagrama, el administrador del clúster instala e implementa NGINX Ingress Controller en el espacio de nombres nginx-ingress
(resaltado en verde) y define un recurso VirtualServer que establece reglas basadas en rutas que hacen referencia a las definiciones de recursos VirtualServerRoute.
Esta definición de recurso VirtualServer establece dos reglas basadas en rutas que hacen referencia a las definiciones de recursos VirtualServerRoute para dos subrutas, /productpage-A
y /productpage-B
.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: example
spec:
host: bookinfo.example.com
routes:
- path: /productpage-A
route: A/ingress
- path: /productpage-B
route: B/ingress
Luego, los equipos de desarrolladores responsables de las aplicaciones en los espacios de nombres A
y B
definen recursos VirtualServerRoute para exponer subrutas de aplicação dentro de sus espacios de nombres. Los equipos están aislados por espacio de nombres y restringidos a implementar subrutas de aplicação establecidas por recursos de VirtualServer provistos por el administrador:
El equipo DevA (rosa en el diagrama) aplica el siguiente recurso VirtualServerRoute para exponer la regla de subruta de aplicação establecida por el administrador para /productpage-A
.
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: ingress
namespace: A
spec:
host: bookinfo.example.com
upstreams:
- name: productpageA
service: productpageA-svc
port: 9080
subroutes:
- path: /productpage-A
action:
pass: productpageA
El equipo DevB (violeta) aplica el siguiente recurso VirtualServerRoute para exponer la regla de subruta de aplicação establecida por el administrador para /productpage-B
.
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: ingress
namespace: B
spec:
host: bookinfo.example.com
upstreams:
- name: productpageB
service: productpageB-svc
port: 9080
subroutes:
- path: /productpage-B
action:
pass: productpageB
Para obtener más información sobre las funciones que puede configurar en los recursos VirtualServer y VirtualServerRoute, consulte la documentación del controlador de ingreso NGINX .
Nota: Puede usar tipos de Ingress fusionables para configurar el enrutamiento entre espacios de nombres, pero en un modelo de delegación de autoservicio restringido, ese enfoque tiene tres desventajas en comparación con los recursos VirtualServer y VirtualServerRoute:
Puede utilizar el control de acceso basado en roles (RBAC) de Kubernetes para regular el acceso de un usuario a los espacios de nombres y a los recursos de NGINX Ingress en función de los roles asignados al usuario.
Por ejemplo, en un modelo de autoservicio restringido, solo los administradores con privilegios especiales pueden acceder de forma segura a los recursos de VirtualServer; debido a que esos recursos definen el punto de entrada al clúster de Kubernetes, el uso indebido puede provocar interrupciones en todo el sistema.
Los desarrolladores utilizan los recursos de VirtualServerRoute para configurar las reglas de ingreso para las rutas de aplicação que poseen, por lo que los administradores establecen políticas RBAC que permiten a los desarrolladores crear solo esos recursos. Incluso pueden restringir ese permiso a espacios de nombres específicos si necesitan regular aún más el acceso de los desarrolladores.
En un modelo de autoservicio completo, se puede otorgar a los desarrolladores acceso seguro a los recursos de VirtualServer, pero nuevamente el administrador puede restringir ese permiso a espacios de nombres específicos.
Para obtener más información sobre la autorización RBAC, consulte la documentación de Kubernetes .
Los recursos de políticas de NGINX son otra herramienta que permite a los equipos distribuidos configurar Kubernetes en implementaciones de múltiples inquilinos. Los recursos de políticas habilitan funcionalidades como autenticación mediante OAuth y OpenID Connect (OIDC), limitación de velocidad y firewall de aplicação web (WAF). Los recursos de políticas se referencian en los recursos VirtualServer y VirtualServerRoute para que surtan efecto en la configuración de Ingress.
Por ejemplo, un equipo a cargo de la gestión de identidad en un clúster puede definir políticas JSON Web Token (JWT) o OIDC como la siguiente, que utiliza Okta como proveedor de identidad OIDC (IdP).
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
name: okta-oidc-policy
spec:
oidc:
clientID: <client_id>
clientSecret: okta-oidc-secret
authEndpoint: https://<your_okta_domain>/oauth2/v1/authorize
tokenEndpoint: https://<your_okta_domain>/oauth2/v1/token
jwksURI: https://<your_okta_domain>/oauth2/v1/keys
Los equipos de NetOps y DevOps pueden usar recursos VirtualServer o VirtualServerRoute para hacer referencia a esas políticas, como en este ejemplo.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: bookinfo-vs
spec:
host: bookinfo.example.com
tls:
secret: bookinfo-secret
upstreams:
- name: backend
service: productpage
port: 9080
routes:
- path: /
policies:
- name: okta-oidc-policy
action:
pass: backend
Juntos, los recursos NGINX Policy, VirtualServer y VirtualServerRoute permiten arquitecturas de configuración distribuidas, donde los administradores pueden delegar fácilmente la configuración a otros equipos. Los equipos pueden ensamblar módulos en distintos espacios de nombres y configurar el controlador de ingreso NGINX con casos de uso sofisticados de manera segura, escalable y manejable.
Para obtener más información sobre los recursos de políticas, consulte la documentación del controlador de ingreso NGINX .
Esta publicación es un extracto de nuestro completo libro electrónico, Gestión del tráfico de Kubernetes con NGINX: Una guía práctica . Descárgalo gratis hoy .
Pruebe usted mismo el controlador de ingreso NGINX basado en NGINX Plus hoy mismo con una prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.