Clúster de instancias múltiples

En esta página, se explica el clúster de instancias múltiples en Google Kubernetes Engine. Esto incluye clústeres compartidos por usuarios diferentes en una sola organización y clústeres compartidos por instancias por cliente de una aplicación de software como servicio (SaaS). El clúster de instancias múltiples es una alternativa para la administración de varios clústeres de instancias individuales.

En esta página, también se resumen las características de Kubernetes y GKE que se pueden usar para administrar los clústeres de instancias múltiples.

¿Qué significa “instancias múltiples”?

Un clúster de instancias múltiples se comparte por muchos usuarios o cargas de trabajo a las que nos referimos como “instancias”. Los operadores de clústeres de instancias múltiples deben aislar a las instancias para minimizar el daño que una instancia malintencionada o vulnerada pueda causar al clúster y a otras instancias. Además, los recursos de clúster se deben asignar entre las instancias.

Cuando planeas una arquitectura de instancias múltiples debes considerar las capas de aislamiento de recursos en Kubernetes: clúster, espacio de nombres, nodo, pod y contenedor. También debes considerar las implicaciones de seguridad cuando se comparten tipos diferentes de recursos entre instancias. Por ejemplo, si programas pods de instancias diferentes en el mismo nodo, se puede reducir la cantidad de máquinas necesarias en el clúster. Por otro lado, puede ser necesario evitar que se coloquen algunas cargas de trabajo. Por ejemplo, no debes permitir que se ejecuten códigos no confiables externos a tu organización en el mismo nodo que los contenedores que procesan información sensible.

A pesar de que Kubernetes no puede garantizar un aislamiento del todo seguro entre las instancias, ofrece características que pueden ser suficientes para casos prácticos específicos. Puedes separar cada instancia y sus recursos de Kubernetes en sus propios espacios de nombres. Puedes usar políticas para aplicar un aislamiento de instancias. En general, el espacio de nombres alcanza las políticas y estas se pueden usar para restringir el acceso a la API, el uso de los recursos y los permisos de los contenedores.

Las instancias de un clúster de instancias múltiples comparten lo siguiente:

Operar un clúster de instancias múltiples tiene varias ventajas sobre operar múltiples clústeres de instancias individuales:

  • Se reduce la sobrecarga de administración.
  • Se reduce la fragmentación de recursos.
  • No hay necesidad de crear clústeres para instancias nuevas.

Casos prácticos de instancias múltiples

En esta sección, se describe cómo puedes configurar un clúster para varios casos prácticos de instancias múltiples.

Instancias múltiples para empresas

En un entorno empresarial, las instancias de un clúster son equipos distintos dentro de la organización. En general, cada instancia tiene un espacio de nombres correspondiente. Los modelos alternativos de instancias múltiples con una instancia por clúster o una instancia por proyecto de GCP son más difíciles de administrar. El tráfico de red dentro de un espacio de nombres no tiene restricción. El tráfico de red entre espacios de nombres se debe incluir en la lista blanca de manera explícita. Estas políticas se pueden aplicar mediante la política de red de Kubernetes.

Los usuarios del clúster se dividen en tres funciones diferentes, según su privilegio:

Administrador del clúster
Esta función es para los administradores la totalidad del clúster, que administran todas las instancias. Los administradores de clúster pueden crear, leer, actualizar y borrar cualquier objeto de política. Pueden crear espacios de nombres y asignarlos a administradores de espacio de nombres.
Administrador de espacio de nombres
Esta función es para administradores de instancias individuales específicas. Un administrador de espacio de nombres puede administrar a los usuarios en su espacio de nombres.
Desarrollador
Los miembros de esta función pueden crear, leer, actualizar y borrar objetos de política de espacio de nombres como Jobs, Ingresses y Pods. Los desarrolladores solo tienen estos privilegios en los espacios de nombres a los que tienen acceso.

Proveedor SaaS de instancias múltiples

Las instancias de un clúster de proveedor SaaS son las instancias por cliente de la aplicación y el plano de control de SaaS. Para aprovechar las políticas de alcance de espacio de nombres, las instancias de la aplicación se deben organizar en sus propios espacios de nombres, como los componentes del plano de control de SaaS. Los usuarios finales no pueden interactuar con el plano de control directamente, deben usar la interfaz de SaaS, que, a su vez, interactúa con el plano de control de Kubernetes.

Por ejemplo, una plataforma de blog se puede ejecutar en un clúster de instancias múltiples. En este caso, las instancias son cada una de las instancias de blog del cliente y el plano de control de la plataforma. El plano de control de la plataforma y cada blog alojado se ejecutan todos en espacios de nombres separados. Los clientes crean y borran blogs, actualizan las versiones del software del blog a través de la interfaz de la plataforma sin poder ver cómo opera el clúster.

Aplicación de la política de instancias múltiples

GKE y Kubernetes proporcionan varias características que se pueden usar para administrar clústeres de instancias múltiples. En las secciones siguientes puedes encontrar una descripción general de esas características.

Control de acceso

GKE tiene dos sistemas de control de acceso: Cloud Identity & Access Management (Cloud IAM) y control de acceso según funciones (RBAC, por sus siglas en inglés). Cloud IAM es el sistema de control de acceso de GCP para administrar la autenticación y la autorización de los recursos de GCP. Usa Cloud IAM para otorgar a los usuarios acceso a los recursos de GKE y Kubernetes. RBAC está integrado en Kubernetes y otorga permisos detallados para recursos y operaciones específicas dentro de tus clústeres.

Consulta la descripción general del control de acceso para obtener más información sobre estas opciones y cuándo usar cada una.

Consulta la guía práctica de RBAC y la guía práctica de Cloud IAM para aprender cómo usar estos sistemas de control de acceso.

Políticas de red

Las políticas de red de clústeres te brindan control sobre la comunicación entre los Pods del clúster. Las políticas especifican los espacios de nombres, las etiquetas y los rangos de direcciones IP con los que un Pod se puede comunicar.

Consulta la guía práctica de políticas de red para obtener instrucciones sobre cómo habilitar la aplicación de la política de red en GKE.

Sigue el instructivo de políticas de red para aprender cómo escribir políticas de red.

Cuotas de recursos

Las cuotas de recursos administran la cantidad de recursos usados por los objetos en un espacio de nombres. Puedes establecer cuotas de acuerdo con el uso de memoria y de CPU o de acuerdo con los conteos de objeto. Las cuotas de recursos te aseguran que ninguna instancia use más de lo que se le asigna de los recursos de clúster.

Consulta la documentación sobre cuotas de recursos para obtener más información.

Políticas de seguridad de Pods

Las PodSecurityPolicies son un tipo de API de Kubernetes que validan solicitudes para crear y actualizar Pods. Las PodSecurityPolicies definen los valores y requisitos predeterminados para los campos sensibles a la seguridad de la especificación de Pods. Puedes crear políticas que restrinjan la implementación de Pods que acceden al sistema de archivos del host, redes, espacios de nombres PID, volúmenes, etcétera.

Consulta la guía práctica de las PodSecurityPolicies para obtener más información.

Antiafinidad del Pod

Puedes usar la antiafinidad del Pod para evitar que Pods de instancias diferentes se programen en el mismo nodo. Las restricciones de antiafinidad se basan en etiquetas de Pods. Por ejemplo, la especificación de pods siguiente describe un Pod con una etiqueta "team": "billing" y una regla antiafinidad que evita que el Pod se programe junto con Pods sin etiqueta.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

El problema con esta técnica es que los usuarios malintencionados pueden eludir la regla si aplican la etiqueta team: billing en un Pod arbitrario. La antiafinidad del Pod por sí sola no puede aplicar la política en clústeres con instancias no confiables.

Consulta la documentación de antiafinidad del Pod para obtener más información.

Nodos dedicados con taints y tolerancias

Los taints de nodo son otra manera de controlar la programación de la carga de trabajo. Puedes usar los taints de nodo para reservar nodos especializados a fin de que los usen ciertas instancias. Por ejemplo, puedes dedicar nodos equipados con GPU a instancias específicas cuyas cargas de trabajo requieran GPU.

Para dedicar un grupo de nodos a una cierta instancia, aplica un taint con effect: "NoSchedule" al grupo de nodos. Entonces, solo se pueden programar pods con una tolerancia correspondiente en nodos del grupo de nodos.

El problema con esta técnica es que los usuarios malintencionados pueden agregar una tolerancia a sus Pods para obtener acceso al grupo de nodos dedicados. Las tolerancias y taints de nodo por sí solas no pueden aplicar de manera segura una política en clústeres con instancias no confiables.

Consulta la página de instrucciones de taints de nodo para obtener más información sobre cómo controlar la programación con taints de nodo.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...