Prácticas recomendadas para empresas sobre clústeres con varios propietarios

La multitenencia en Google Kubernetes Engine (GKE) hace referencia a uno o varios clústeres que se comparten entre los inquilinos. En Kubernetes, un inquilino se puede definir de las siguientes formas:

• Un equipo responsable de desarrollar y operar una o varias cargas de trabajo.
• Conjunto de cargas de trabajo relacionadas, tanto si las gestiona un equipo como si las gestionan varios.
• Una sola carga de trabajo, como un Deployment.

La propiedad múltiple de clústeres se suele implementar para reducir los costes o para aplicar de forma coherente las políticas de administración en todos los propietarios. Sin embargo, si se configura incorrectamente un clúster de GKE o sus recursos de GKE asociados, no se podrán conseguir los ahorros de costes previstos, se aplicarán políticas incorrectas o se producirán interacciones destructivas entre las cargas de trabajo de diferentes inquilinos.

En esta guía se ofrecen prácticas recomendadas para configurar de forma segura y eficiente varios clústeres multiinquilino para una empresa.

Supuestos y requisitos

Las prácticas recomendadas de esta guía se basan en un caso práctico de multitenencia para un entorno empresarial, que tiene los siguientes supuestos y requisitos:

• La organización es una sola empresa que tiene muchos inquilinos (dos o más equipos de aplicaciones o servicios) que usan Kubernetes y quieren compartir recursos informáticos y administrativos.
• Cada inquilino es un solo equipo que desarrolla una sola carga de trabajo.
• Además de los equipos de aplicaciones o servicios, hay otros equipos que también utilizan y gestionan clústeres, como los miembros del equipo de la plataforma, los administradores de clústeres, los auditores, etc.
• El equipo de la plataforma es el propietario de los clústeres y define la cantidad de recursos que puede usar cada equipo de cliente. Cada cliente puede solicitar más.
• Cada equipo de inquilino debe poder implementar su aplicación a través de la API de Kubernetes sin tener que comunicarse con el equipo de la plataforma.
• Ningún arrendatario debería poder afectar a otros arrendatarios del clúster compartido, excepto mediante decisiones de diseño explícitas, como llamadas a la API, fuentes de datos compartidas, etc.

Esta configuración servirá como modelo para mostrar las prácticas recomendadas de multitenencia. Aunque esta configuración no describa perfectamente todas las organizaciones empresariales, se puede ampliar fácilmente para cubrir situaciones similares.

Configurar carpetas, proyectos y clústeres

En las empresas que implementan clústeres multiinquilino en GKE, se necesita una configuración adicional en otros sistemas deTrusted Cloud para gestionar la complejidad, que no existe en las implementaciones de Kubernetes más sencillas de una sola aplicación y un solo equipo. Esto incluye tanto la configuración de proyectos para aislar las cuestiones administrativas como la asignación de la estructura de la organización a identidades y cuentas en la nube, así como la gestión de Trusted Cloud recursos adicionales, como bases de datos, registro y monitorización, almacenamiento y redes.

Establecer una jerarquía de carpetas y proyectos

Para registrar cómo gestiona tu organización los Trusted Cloud recursos y para aplicar una separación de responsabilidades, usa carpetas y proyectos. Las carpetas permiten que diferentes equipos definan políticas que se apliquen en cascada a varios proyectos, mientras que los proyectos se pueden usar para separar entornos (por ejemplo, producción y staging) y equipos entre sí. Por ejemplo, la mayoría de las organizaciones tienen un equipo para gestionar la infraestructura de red y otro para gestionar los clústeres. Cada tecnología se considera una parte independiente de la pila, que requiere su propio nivel de experiencia, solución de problemas y acceso.

Una carpeta superior puede contener hasta 300 carpetas y puedes anidar carpetas hasta en 10 niveles de profundidad. Si tiene más de 300 inquilinos, puede organizarlos en jerarquías anidadas para no superar el límite. Para obtener más información sobre las carpetas, consulta el artículo Crear y gestionar carpetas.

Asignar roles con gestión de identidades y accesos

Puedes controlar el acceso a los Trusted Cloud recursos mediante políticas de IAM. Empieza por identificar los grupos que necesita tu organización y su ámbito de operaciones. Después, asigna el rol de gestión de identidades y accesos adecuado al grupo.

Centralizar el control de la red

Para mantener un control centralizado sobre los recursos de red, como subredes, rutas y cortafuegos, usa redes de VPC compartidas. Los recursos de una VPC compartida pueden comunicarse entre sí de forma segura y eficiente entre proyectos mediante IPs internas. Cada red de VPC compartida se define y es propiedad de un proyecto del host centralizado, y la pueden usar uno o varios proyectos de servicio.

Con las VPC compartidas y Gestión de Identidades y Accesos, puedes separar la administración de la red de la administración del proyecto. Esta separación te ayuda a implementar el principio de mínimos accesos. Por ejemplo, un equipo de red centralizado puede administrar la red sin tener permisos en los proyectos participantes. Del mismo modo, los administradores del proyecto pueden gestionar los recursos de su proyecto sin tener permisos para manipular la red compartida.

Cuando configuras una VPC compartida, debes configurar las subredes y sus intervalos de IP secundarios en la VPC. Para determinar el tamaño de la subred, debes saber el número esperado de inquilinos, el número de pods y servicios que se espera que ejecuten, y el tamaño máximo y medio de los pods. Calcular la capacidad total del clúster necesaria te permitirá conocer el tamaño de instancia que quieres y, por lo tanto, el número total de nodos. Con el número total de nodos, se puede calcular el espacio de IP total consumido, lo que puede proporcionar el tamaño de subred deseado.

A continuación, te indicamos algunos factores que también debes tener en cuenta al configurar tu red:

• El número máximo de proyectos de servicio que se pueden vincular a un proyecto del host es 1000, y el número máximo de proyectos del host de VPC compartida en una organización es 100.
• Los intervalos de IP de los nodos, los pods y los servicios deben ser únicos. No puedes crear una subred cuyos intervalos de direcciones IP principales y secundarias se solapen.
• El número máximo de pods y servicios de un clúster de GKE determinado está limitado por el tamaño de los intervalos secundarios del clúster.
• El número máximo de nodos del clúster está limitado por el tamaño del intervalo de direcciones IP principal de la subred del clúster y por el intervalo de direcciones de los pods del clúster.
• Para tener más flexibilidad y control sobre la gestión de direcciones IP, puedes configurar el número máximo de pods que se pueden ejecutar en un nodo. Si reduces el número de pods por nodo, también se reduce el intervalo CIDR asignado por nodo, por lo que se necesitan menos direcciones IP.

Para obtener información sobre los intervalos de red de un clúster de VPC, consulta Crear un clúster nativo de VPC.

Los clientes que necesiten un mayor aislamiento para los recursos que se ejecutan fuera de los clústeres compartidos (como las VMs de Compute Engine dedicadas) pueden usar su propia VPC, que está emparejada con la VPC compartida que gestiona el equipo de redes. Esto proporciona seguridad adicional a costa de una mayor complejidad y muchas otras limitaciones. Para obtener más información sobre el emparejamiento, consulta el artículo Usar el emparejamiento entre redes de VPC. En el ejemplo de abajo, todos los arrendatarios han elegido compartir una única VPC de arrendatario (por entorno).

Crear clústeres fiables y de alta disponibilidad

Diseña la arquitectura de tu clúster para que tenga alta disponibilidad y fiabilidad siguiendo estas recomendaciones:

• Crea un proyecto de administrador de clúster por clúster para reducir el riesgo de que las configuraciones a nivel de proyecto (por ejemplo, las vinculaciones de gestión de identidades y accesos) afecten negativamente a muchos clústeres y para ayudar a separar la cuota y la facturación. Los proyectos de administrador de clústeres están separados de los proyectos de inquilino, que los inquilinos individuales usan para gestionar, por ejemplo, sus recursos de Trusted Cloud .
• Configura el aislamiento de tu red para inhabilitar el acceso a los nodos y gestionar el acceso al plano de control. También te recomendamos que configures el aislamiento de la red para los entornos de desarrollo y de preproducción.
• Asegúrate de que el plano de control del clúster sea regional para ofrecer una alta disponibilidad en la propiedad múltiple. Cualquier interrupción del plano de control afectará a los propietarios. Ten en cuenta que ejecutar clústeres regionales tiene implicaciones en los costes. Los clústeres de Autopilot están preconfigurados como clústeres regionales.
• Asegúrate de que los nodos de tu clúster abarquen al menos tres zonas para conseguir fiabilidad zonal. Para obtener información sobre el coste de la salida entre zonas de la misma región, consulta la documentación sobre los precios de red.

Autoescalar nodos y recursos de clústeres

Para satisfacer las demandas de tus inquilinos, escala automáticamente los nodos de tu clúster habilitando el autoescalado.

El escalado automático ayuda a que los sistemas parezcan receptivos y en buen estado cuando varios inquilinos implementan cargas de trabajo pesadas en sus espacios de nombres o para responder a interrupciones zonales.

En los clústeres Autopilot, los grupos de nodos se escalan automáticamente para satisfacer los requisitos de tus cargas de trabajo.

Cuando habilitas el autoescalado, especificas el número mínimo y máximo de nodos de un clúster en función del tamaño de la carga de trabajo prevista. Si especificas el número máximo de nodos, puedes asegurarte de que haya suficiente espacio para todos los pods del clúster, independientemente del espacio de nombres en el que se ejecuten. El autoescalado de clústeres cambia la escala de los grupos de nodos en función de los límites mínimo y máximo, lo que ayuda a reducir los costes operativos cuando disminuye la carga del sistema y a evitar que los pods pasen a un estado pendiente cuando no haya suficientes recursos de clúster disponibles. Para determinar el número máximo de nodos, identifica la cantidad máxima de CPU y memoria que requiere cada inquilino y suma esas cantidades para obtener la capacidad total que debería poder gestionar el clúster si todos los inquilinos estuvieran al límite. Con el número máximo de nodos, puedes elegir el tamaño y el número de instancias, teniendo en cuenta el espacio de subred IP disponible para el clúster.

Usa el autoescalado de pods para escalar automáticamente los pods en función de la demanda de recursos. Autoescalador horizontal de pods (HPA) escala el número de réplicas de pods en función del uso de CPU o memoria, o de métricas personalizadas. El autoescalado vertical de pods (VPA) se puede usar para escalar automáticamente las demandas de recursos de los pods. No se debe usar con HPA a menos que haya métricas personalizadas disponibles, ya que los dos autoescaladores pueden competir entre sí. Por este motivo, empieza con HPA y solo después con VPA cuando sea necesario.

Determinar el tamaño del clúster

A la hora de determinar el tamaño de tu clúster, debes tener en cuenta los siguientes factores:

• El tamaño de tu clúster depende del tipo de cargas de trabajo que tengas previsto ejecutar. Si tus cargas de trabajo tienen una mayor densidad, la eficiencia de los costes será mayor, pero también habrá más probabilidades de que se produzca una contención de recursos.
• El tamaño mínimo de un clúster se define por el número de zonas que abarca: un nodo para un clúster zonal y tres nodos para un clúster regional.
• Por proyecto, hay un máximo de 50 clústeres por zona, más 50 clústeres regionales por región.

• Por clúster, se aplican los siguientes valores máximos a los nodos:

  • 1000 nodos por grupo de nodos
  • 1000 nodos por clúster (si usas el controlador Ingress de GKE)
  • 5000 nodos por clúster de forma predeterminada. Puedes aumentar este límite a 15.000 o 65.000 nodos. Para obtener más información, consulta Clústeres con más de 5000 nodos.
  • 256 pods por nodo
  • 150.000 pods por clúster y 300.000 contenedores por clúster

  Consulta la página de cuotas y límites para obtener más información.

Programar ventanas de mantenimiento

Para reducir los tiempos de inactividad durante las actualizaciones y el mantenimiento de clústeres o nodos, programa ventanas de mantenimiento para que se produzcan en horas de menor actividad. Durante las actualizaciones, puede haber interrupciones temporales cuando las cargas de trabajo se mueven para recrear los nodos. Para minimizar el impacto de estas interrupciones, programa las actualizaciones para las horas de menor actividad y diseña las implementaciones de tus aplicaciones de forma que puedan gestionar las interrupciones parciales sin problemas, si es posible.

Configurar un balanceador de carga de aplicación externo con Ingress

Para gestionar los servicios publicados de tus clientes y el tráfico entrante a esos servicios, crea un balanceador de carga HTTP(s) que permita una sola entrada por clúster, donde los servicios de cada cliente se registren con el recurso Ingress del clúster. Puedes crear y configurar un balanceador de carga HTTP(S) creando un recurso Ingress de Kubernetes, que define cómo llega el tráfico a tus servicios y cómo se dirige a la aplicación de tu arrendatario. Al registrar los servicios con el recurso Ingress, la convención de nomenclatura de los servicios se vuelve coherente, mostrando un único ingreso, como tenanta.example.com y tenantb.example.com.

Proteger el clúster para la propiedad múltiple

Controlar la comunicación de los pods con políticas de red

Para controlar la comunicación de red entre los pods de cada uno de los espacios de nombres de tu clúster, crea políticas de red en función de los requisitos de tus inquilinos. Como recomendación inicial, debes bloquear el tráfico entre espacios de nombres que alojan aplicaciones de diferentes clientes. El administrador del clúster puede aplicar una deny-all política de red para denegar todo el tráfico de entrada y evitar que los pods de un espacio de nombres envíen tráfico accidentalmente a servicios o bases de datos de otros espacios de nombres.

Por ejemplo, esta es una política de red que restringe el tráfico de entrada de todos los demás espacios de nombres al espacio de nombres tenant-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Ejecutar cargas de trabajo con GKE Sandbox

Los clústeres que ejecutan cargas de trabajo no fiables están más expuestos a vulnerabilidades de seguridad que otros clústeres. Con GKE Sandbox, puedes reforzar los límites de aislamiento entre las cargas de trabajo de tu entorno multiinquilino. Para gestionar la seguridad, te recomendamos que empieces con GKE Sandbox y, después, uses controles de acceso basados en políticas para cubrir cualquier laguna.

GKE Sandbox se basa en gVisor, un proyecto de entorno aislado de contenedores de código abierto, y proporciona aislamiento adicional para cargas de trabajo multicliente añadiendo una capa extra entre los contenedores y el SO host. Los tiempos de ejecución de contenedores suelen ejecutarse como un usuario con privilegios en el nodo y tienen acceso a la mayoría de las llamadas al sistema en el kernel del host. En un clúster multiinquilino, un inquilino malintencionado puede obtener acceso al kernel del host y a los datos de otros inquilinos. GKE Sandbox mitiga estas amenazas reduciendo la necesidad de que los contenedores interactúen con el host, lo que disminuye la superficie de ataque del host y limita el alcance de las acciones malintencionadas.

GKE Sandbox proporciona dos límites de aislamiento entre el contenedor y el SO host:

• Un kernel de espacio de usuario escrito en Go que gestiona las llamadas al sistema y limita la interacción con el kernel del host. Cada pod tiene su propio kernel de espacio de usuario aislado.
• El kernel del espacio de usuario también se ejecuta en espacios de nombres y llamadas al sistema de filtrado seccomp.

Configurar controles de admisión basados en políticas

Para evitar que se ejecuten en tu clúster pods que infrinjan tus límites de seguridad, usa un controlador de admisión. Los controladores de admisión pueden comprobar las especificaciones de los pods con las políticas que definas y pueden evitar que los pods que infrinjan esas políticas se ejecuten en tu clúster.

GKE admite los siguientes tipos de control de acceso:

• Policy Controller: declara políticas predefinidas o personalizadas y aplícalas en clústeres a gran escala con flotas. Policy Controller es una implementación del agente de políticas de código abierto Gatekeeper y es una función de GKE Enterprise.

• Controlador de admisión PodSecurity: implementa políticas predefinidas que se corresponden con los estándares de seguridad de pods en clústeres concretos o en espacios de nombres específicos.

Usa Workload Identity Federation para GKE para conceder acceso a los servicios de Trusted Cloud

Para conceder acceso de forma segura a las cargas de trabajo a los servicios de Trusted Cloud , habilita Workload Identity Federation para GKE en el clúster. Workload Identity Federation for GKE ayuda a los administradores a gestionar las cuentas de servicio de Kubernetes que usan las cargas de trabajo de Kubernetes para acceder a los Trusted Cloud servicios. Cuando creas un clúster con Workload Identity Federation for GKE habilitado, se establece un espacio de nombres de identidad para el proyecto en el que se aloja el clúster. El espacio de nombres de identidad permite que el clúster autentique automáticamente las cuentas de servicio de las aplicaciones de GKE. Para ello, asigna el nombre de la cuenta de servicio de Kubernetes a un identificador de cuenta de servicio de Google virtual, que se usa para la vinculación de gestión de identidades y accesos de las cuentas de servicio de Kubernetes de los inquilinos.

Restringir el acceso a la red del plano de control

Para proteger el plano de control, restringe el acceso a las redes autorizadas. En GKE, cuando habilitas redes autorizadas, puedes autorizar hasta 50 intervalos CIDR y permitir que solo las direcciones IP de esos intervalos accedan a tu plano de control. GKE ya usa Seguridad en la capa de transporte (TLS) y autenticación para proporcionar acceso seguro al endpoint del plano de control desde Internet. Si usas redes autorizadas, puedes restringir aún más el acceso a conjuntos de direcciones IP específicos.

Aprovisionamiento de inquilinos

Crear proyectos de clientes

Para alojar los recursos que no son de clúster de un arrendatario, crea un proyecto de servicio para cada arrendatario. Estos proyectos de servicio contienen recursos lógicos específicos de las aplicaciones del arrendatario (por ejemplo, registros, monitorización, segmentos de almacenamiento, cuentas de servicio, etc.). Todos los proyectos de servicio de inquilino están conectados a la VPC compartida del proyecto host del inquilino.

Usar RBAC para acotar el acceso de los arrendatarios

Define un acceso más detallado a los recursos del clúster para tus arrendatarios mediante el control de acceso basado en roles (RBAC) de Kubernetes. Además del acceso de solo lectura que se concede inicialmente con IAM a los grupos de arrendatarios, define roles y vinculaciones de RBAC de Kubernetes en todo el espacio de nombres para cada grupo de arrendatarios.

Antes hemos identificado dos grupos de inquilinos: administradores de inquilinos y desarrolladores de inquilinos. En esos grupos, definimos los siguientes roles y accesos de RBAC:

Además de crear roles y enlaces de RBAC que asignan varios permisos a grupos de Google Workspace o Cloud Identity dentro de su espacio de nombres, los administradores de arrendatarios suelen necesitar la capacidad de gestionar usuarios en cada uno de esos grupos. En función de los requisitos de tu organización, esto se puede gestionar delegando permisos de Google Workspace o Cloud Identity en el administrador del arrendatario para que gestione su propia pertenencia a grupos, o bien el administrador del arrendatario puede ponerse en contacto con un equipo de tu organización que tenga permisos de Google Workspace o Cloud Identity para gestionar esos cambios.

Usar Grupos de Google para vincular permisos

Para gestionar de forma eficiente los permisos de los tenants en un clúster, puedes vincular permisos de RBAC a tus grupos de Google. Los administradores de Google Workspace mantienen la pertenencia a esos grupos, por lo que los administradores de tu clúster no necesitan información detallada sobre tus usuarios.

Por ejemplo, si tenemos un grupo de Google llamado tenant-admins@mydomain.com y un usuario llamado admin1@mydomain.com que es miembro de ese grupo, el siguiente enlace proporciona al usuario acceso de administrador al espacio de nombres tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Crear espacios de nombres

Para proporcionar un aislamiento lógico entre los inquilinos que están en el mismo clúster, implementa espacios de nombres. Como parte del proceso de RBAC de Kubernetes, el administrador del clúster crea espacios de nombres para cada grupo de inquilinos. El administrador de inquilinos gestiona a los usuarios (desarrolladores de inquilinos) en su respectivo espacio de nombres de inquilino. Los desarrolladores de inquilinos pueden usar recursos específicos de clústeres e inquilinos para implementar sus aplicaciones.

Evitar alcanzar los límites de espacio de nombres

El número máximo teórico de espacios de nombres en un clúster es de 10.000, aunque en la práctica hay muchos factores que podrían impedir que alcances este límite. Por ejemplo, puede alcanzar el número máximo de pods (150.000) y nodos (5000) de todo el clúster antes de alcanzar el número máximo de espacios de nombres. Otros factores (como el número de secretos) pueden reducir aún más los límites efectivos. Por lo tanto, una buena regla general inicial es intentar acercarse solo al límite teórico de una restricción a la vez y mantenerse aproximadamente a un orden de magnitud de los demás límites, a menos que los experimentos demuestren que tus casos prácticos funcionan bien. Si necesitas más recursos de los que puede admitir un solo clúster, debes crear más clústeres. Para obtener información sobre la escalabilidad de Kubernetes, consulta el artículo Umbrales de escalabilidad de Kubernetes.

Estandarizar la nomenclatura de los espacios de nombres

Para facilitar las implementaciones en varios entornos alojados en diferentes clústeres, estandarice la convención de nomenclatura de espacios de nombres que utilice. Por ejemplo, no asocies el nombre del entorno (desarrollo, staging y producción) al nombre del espacio de nombres. En su lugar, usa el mismo nombre en todos los entornos. Si usas el mismo nombre, no tendrás que cambiar los archivos de configuración en los distintos entornos.

Crear cuentas de servicio para cargas de trabajo de inquilinos

Crea una cuenta de servicio de Google específica del arrendatario para cada carga de trabajo distinta en un espacio de nombres de arrendatario. De esta forma, se proporciona una forma de seguridad que permite a los arrendatarios gestionar las cuentas de servicio de las cargas de trabajo que poseen o implementan en sus respectivos espacios de nombres. La cuenta de servicio de Kubernetes de cada espacio de nombres se asigna a una cuenta de servicio de Google mediante Workload Identity Federation for GKE.

Aplicar cuotas de recursos

Para asegurarte de que todos los arrendatarios que comparten un clúster tengan un acceso justo a los recursos del clúster, aplica cuotas de recursos. Crea una cuota de recursos para cada espacio de nombres en función del número de pods implementados por cada inquilino y de la cantidad de memoria y CPU que requiera cada pod.

En el siguiente ejemplo se define una cuota de recursos en la que los pods del espacio de nombres tenant-a pueden solicitar hasta 16 CPUs y 64 GB de memoria, y la CPU máxima es 32 y la memoria máxima es 72 GB.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Monitorización, registro y uso

Monitorizar métricas de uso

Para obtener desgloses de costes de espacios de nombres y etiquetas concretos de un clúster, puedes habilitar la asignación de costes de GKE. La asignación de costes de GKE monitoriza la información sobre las solicitudes de recursos y el uso de los recursos de las cargas de trabajo de un clúster, que puedes desglosar por espacios de nombres y etiquetas. Con la asignación de costes de GKE, puedes aproximar el desglose de costes de los departamentos o equipos que comparten un clúster, comprender los patrones de uso de aplicaciones concretas (o incluso de componentes de una sola aplicación), ayudar a los administradores de clústeres a priorizar los picos de uso y mejorar la planificación de la capacidad y la elaboración de presupuestos.

Cuando habilitas la asignación de costes de GKE, el nombre del clúster y el espacio de nombres de tus cargas de trabajo de GKE aparecen en el campo de etiquetas de la exportación de facturación a BigQuery.

Proporcionar registros específicos de un arrendatario

Para proporcionar a los inquilinos datos de registro específicos de las cargas de trabajo de sus proyectos, usa el enrutador de registros de Cloud Logging. Para crear registros específicos de un arrendatario, el administrador del clúster crea un receptor para exportar las entradas de registro a un contenedor de registro creado en el proyecto Trusted Cloud by S3NSdel arrendatario.

Para obtener información sobre cómo configurar estos tipos de registros, consulta Registro multiinquilino en GKE.

Resumen de la lista de comprobación

En la siguiente tabla se resumen las tareas recomendadas para crear clústeres multiinquilino en una organización empresarial:

Siguientes pasos

• Para obtener más información sobre la seguridad, consulta Reforzar la seguridad de tu clúster.
• Para obtener más información sobre las redes de VPC, consulta las prácticas recomendadas y las arquitecturas de referencia para el diseño de VPC.
• Para obtener más información sobre las prácticas recomendadas para empresas, consulta el Trusted Cloud by S3NS framework Well-Architected.