Mejores prácticas de arrendamiento múltiple

Mejores prácticas: uso del responsable de autorización de RBAC para un acceso detallado adicional

Recomendamos que utilice el responsable de autorización de Kubernetes RBAC para aplicar control de acceso detallado para usuarios en clusters específicos mediante clusters y roles de Kubernetes RBAC.

Un Role de Kubernetes RBAC es una recopilación de permisos. Por ejemplo, un Role puede incluir permisos de lectura en pods y permisos de lista para pods. Un ClusterRole de Kubernetes RBAC es como un Role, pero se puede utilizar en cualquier lugar del cluster. Un enlace de roles RBAC de Kubernetes asigna un rol a un usuario o grupo, otorgando los permisos de ese rol al usuario o grupo para los recursos de ese espacio de nombres. Del mismo modo, un enlace de cluster RBAC de Kubernetes asigna un rol de cluster a un usuario o grupo, otorgando los permisos de ese rol de cluster al usuario o grupo en todo el cluster.

Consulte Acerca de Access Control y Kubernetes Engine (OKE).

Mejores prácticas: utilice espacios de nombres si varios clusters no son una opción

Le recomendamos que cree espacios de nombres independientes para cada equipo si un cluster de Kubernetes es grande (con cientos de nodos) y hay varios equipos trabajando en el cluster. Por ejemplo, normalmente creará diferentes espacios de nombres para los equipos de desarrollo, prueba y producción.

Un cluster de Kubernetes se puede organizar en espacios de nombre para dividir los recursos del cluster entre varios usuarios. Inicialmente, un cluster tiene los siguientes espacios de nombre:

• default, para recursos sin otro espacio de nombre
• kube-system, para los recursos creados por el sistema Kubernetes
• kube-node-lease, para un objeto de leasing por nodo para ayudar a determinar la disponibilidad del nodo
• kube-public, normalmente se utiliza para los recursos que tienen que estar accesibles en el cluster

Los espacios de nombres desempeñan un papel importante para mantener un cluster seguro cuando varios usuarios y equipos trabajan en el mismo cluster.

Consulte Espacios de nombres en la documentación de Kubernetes.

Mejores prácticas: utilice una convención de nomenclatura de espacios de nombres para facilitar el despliegue en varios entornos

Le recomendamos que establezca y utilice una convención de nomenclatura de espacio de nombres que facilite la creación de despliegues en varios entornos y alojados en diferentes clusters.

Por ejemplo, evite incluir nombres de entorno en nombres de espacios de nombres. En su lugar, utilice el mismo nombre de espacio de nombres en todos los entornos. Al utilizar el mismo nombre de espacio de nombres, puede utilizar los mismos archivos de configuración en todos los entornos y evitar tener que crear un archivo de configuración específico para cada entorno.

Consulte Espacios de nombres en la documentación de Kubernetes.

Mejores prácticas: aislamiento de cargas de trabajo en pools de nodos dedicados

Recomendamos implantar un aislamiento sólido de la infraestructura mediante pools de nodos dedicados para aislar a los inquilinos. Por ejemplo, para una aplicación multi-inquilino que ejecuta cada inquilino en un recurso informático dedicado, separado por pools de nodos.

Muchas aplicaciones SaaS multi-inquilino requieren que los inquilinos se ejecuten en recursos informáticos dedicados y requieren la capacidad de controlar el tráfico de red a través de listas de seguridad por inquilino. Las dos estrategias más comunes para un modelo de arrendamiento de aplicación SaaS son:

• Aproveche los espacios de nombres y las políticas de red para aislar a los inquilinos.
• Aproveche las listas de recursos informáticos/seguridad dedicadas para aislar a los inquilinos.

Mejores prácticas: aplicación de cuotas de recursos

Le recomendamos que cree y aplique cuotas de recursos de Kubernetes para garantizar que todos los inquilinos que comparten un cluster tengan acceso justo a los recursos del cluster.

Cree una cuota de recursos para cada espacio de nombres, según el número de pods desplegados por cada inquilino y la cantidad de memoria y CPU que necesita cada pod.

Por ejemplo, la siguiente configuración ResourceQuota:

• permite a los pods del espacio de nombres tenant-a solicitar hasta 16 CPU y hasta 64 GB de memoria
• limita el número máximo de CPU a 32 y la memoria máxima a 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

Consulte Cuotas de recursos en la documentación de Kubernetes.

Mejores prácticas: nodos y pod de trabajador de escala automática

Recomendamos que active la escala automática para satisfacer la demanda de los inquilinos mediante la ampliación automática de los pools de nodos y los pods en un cluster.

La escala automática garantiza que el sistema siga siendo sensible y en buen estado, incluso cuando los distintos inquilinos desplieguen cargas de trabajo importantes en sus propios espacios de nombres. La escala automática también ayuda al sistema a responder a las interrupciones.

Consulte Uso de la escala automática de pod de cluster de Kubernetes, Uso de la escala automática de pod horizontales de Kubernetes.

Mejores Prácticas: Utilizar un Equilibrador de Carga Flexible

Recomendamos que especifique una unidad flexible para los equilibradores de carga de Oracle Cloud Infrastructure a fin de satisfacer la demanda de inquilinos.

El uso de una unidad flexible para equilibradores de carga de OCI que Kubernetes Engine aprovisiona para servicios de Kubernetes de tipo LoadBalancer le permite:

• Evite las restricciones asociadas a las unidades del equilibrador de carga de ancho de banda fijo, ya que puede especificar los valores mínimos y máximos para crear un rango de tamaño superior e inferior para la unidad del ancho de banda del equilibrador de carga.
• Evite las limitaciones asociadas con el escalado en función solo de los patrones de tráfico generales.

Consulte Especificación de unidades de equilibrador de carga flexibles.

Mejores prácticas: centralización del control de red (opcional)

Recomendamos que mantenga un control centralizado sobre los recursos de red mediante un gateway de enrutamiento dinámico (DRG) y (opcionalmente) una VCN de hub.

El uso de un DRG le permite enrutar el tráfico a través de un dispositivo virtual de red centralizada.

Opcionalmente, la creación de una VCN de hub permite configurar el enrutamiento principal y los firewalls. Los recursos de una VCN de hub se pueden comunicar con otras redes virtuales en la nube de forma segura y eficaz mediante el uso de IP internas. El uso de una VCN de hub e IAM garantiza que solo los administradores de red tengan acceso a la VCN centralizada. Esta separación le ayuda a implementar el principio de privilegio mínimo.

Por ejemplo:

• El equipo de red centralizada puede administrar la red sin tener permisos para acceder a los clusters de Kubernetes (que residen en VCN radiales).
• Los administradores del motor de Kubernetes pueden gestionar clusters sin tener ningún permiso para manipular la red compartida.

Consulte Enrutamiento del tráfico mediante un dispositivo virtual de red central.