Prepara un entorno de Google Kubernetes Engine para la producción

En esta solución, se proporciona un modelo y una metodología para integrar las cargas de trabajo de manera más segura, confiable y rentable a Google Kubernetes Engine (GKE). Se proporciona orientación para configurar el acceso administrativo y de red a los clústeres. En este artículo, se supone que ya comprendes la administración de clústeres y recursos de Kubernetes, y que estás familiarizado con las funciones de herramientas de redes de Google Cloud.

Estructura proyectos, redes de nube privada virtual (VPC) y clústeres

En el siguiente diagrama, se muestra un ejemplo de una estructura flexible y con alta disponibilidad para proyectos, redes de VPC, regiones, subredes, zonas y clústeres.

Estructura de proyectos, redes y clústeres

Proyectos

Google Cloud crea todos sus recursos dentro de una entidad de proyecto. Los proyectos son la unidad de facturación y permiten a los administradores asociar las funciones de administración de identidades y accesos (IAM) con los usuarios. Cuando las funciones se aplican a nivel de proyecto, también se aplican a todos los recursos encapsulados en el proyecto.

Debes usar proyectos para encapsular todos los entornos operativos. Por ejemplo, puedes tener proyectos de production y staging para equipos de operaciones y un proyecto de test-dev para desarrolladores. Si quieres experimentar, puedes aplicar políticas más estrictas y detalladas a los proyectos que conservan las cargas de trabajo y los datos más esenciales y sensibles, mientras aplicas políticas permisivas y flexibles para los desarrolladores en el entorno test-dev.

Clústeres

Un proyecto puede contener varios clústeres. Si tienes varias cargas de trabajo que implementar, puedes optar por usar un clúster compartido o clústeres independientes para estas cargas de trabajo.

Redes y subredes

En cada proyecto, puedes tener una o más redes de VPC, que son versiones virtuales de redes físicas. Cada red de VPC es un recurso global que contiene otros recursos relacionados con las herramientas de redes, como subredes, direcciones IP externas, reglas de firewall, rutas, tu VPN y Cloud Router. En una red de VPC, puedes usar subredes, que son recursos regionales, para aislar y controlar el tráfico que entra o sale de cada región entre los clústeres de GKE.

Cada proyecto viene con una sola red predeterminada. Puedes crear y configurar una red adicional para asignarla a la convención de administración de direcciones IP (IPAM) existente. A continuación, puedes aplicar Reglas de firewall a esta red para filtrar el tráfico desde y hacia los nodos de GKE. De forma predeterminada, se rechaza todo el tráfico de Internet a los nodos de GKE.

Para controlar la comunicación entre las subredes, debes crear reglas de firewall que permitan el paso del tráfico entre las subredes. Usa la marca --tags durante la creación del clúster o el grupo de nodos para etiquetar de forma correcta los nodos de GKE a fin de que se apliquen las reglas de firewall. También puedes usar etiquetas para crear rutas entre las subredes si es necesario.

Clústeres multizona y regionales

Según la configuración predeterminada, un clúster crea su instancia principal de clúster y sus nodos en una zona única que especificas en el momento de la creación. Puedes mejorar la disponibilidad y resiliencia de los clústeres mediante la creación de clústeres multizona o regionales. Los clústeres multizona y regionales distribuyen los recursos de Kubernetes en varias zonas dentro de una región.

Clústeres multizona:

  • Crean una instancia principal de clúster única en una zona.
  • Crean nodos en varias zonas.

Clústeres regionales:

  • Crean tres instancias principales de clúster en tres zonas.
  • Según la configuración predeterminada, crean nodos en tres zonas o en tantas zonas como desees.

La diferencia principal entre los clústeres regionales y multizona es que los primeros crean tres instancias principales y los segundos crean solo una. Ten en cuenta que en ambos casos se te cobra por el tráfico de nodo a nodo en las zonas.

Puedes optar por crear clústeres multizona o regionales en el momento de la creación del clúster. Puedes agregar zonas nuevas a un clúster existente para que sea multizona. Sin embargo, no puedes modificar un clúster existente para que sea regional. Tampoco puedes hacer que un clúster regional ya no lo sea.

La disponibilidad de servicios de los nodos de tus clústeres administrados por GKE se incluye en el Acuerdo de Nivel de Servicio (ANS) de Compute Engine. Además, el ANS de GKE garantiza un tiempo de actividad mensual del 99.5% para las instancias principales del clúster de Kubernetes en clústeres zonales y del 99.95% en clústeres regionales.

A partir del 6 de junio de 2020, GKE cobra una tarifa de administración de clústeres de $0.10 por clúster por hora. Para obtener más detalles, consulta la página de precios.

Para obtener información sobre clústeres multizona y regionales, consulta la documentación de GKE.

Redes autorizadas principales

Una medida de seguridad adicional que puedes aplicar en tu clúster es habilitar redes autorizadas principales. Esta función bloquea el acceso al servidor de la API desde los rangos de CIDR que especifiques y garantiza que solo los equipos dentro de tu red puedan administrar el clúster.

Cuando habilites esta función, recuerda lo siguiente:

  • Solo se permiten 50 rangos de CIDR.
  • Si usas una canalización de CI/CD, asegúrate de que tus herramientas de CI/CD tengan acceso al servidor de API del clúster mediante la inclusión (en la lista blanca) de sus direcciones IP o de rango de CIDR.

También puedes usar esta función en conjunto con Cloud Interconnect o Cloud VPN para habilitar el acceso al nodo principal solo desde tu centro de datos privado.

Clústeres privados

De forma predeterminada, todos los nodos de un clúster de GKE tienen direcciones IP públicas. Una buena práctica es crear clústeres privados, que solo otorgan direcciones IP RFC 1918 privadas a todos los nodos trabajadores. Los clústeres privados aplican el aislamiento de red, lo que reduce exposición al riesgo para tus clústeres. Usar clústeres privados significa que, de forma predeterminada, solo los clientes dentro de tu red pueden acceder a los servicios en el clúster. Para permitir que los servicios externos lleguen a los servicios en tu clúster, puedes usar un balanceador de cargas de HTTP(S) o un balanceador de cargas de red.

Cuando quieras abrir el acceso al nodo principal fuera de tu red de VPC, puedes usar clústeres privados con redes autorizadas principales. Cuando habilitas las redes autorizadas principales, el extremo de la instancia principal del clúster recibe dos direcciones IP: una interna (privada) y una pública. Cualquier elemento interno de tu red que se encuentre dentro de la misma región puede usar la dirección IP interna. Cualquier usuario o proceso externo a tu red y que pertenezca a un rango CIDR o una dirección IP permitidos puede usar la dirección IP pública de la instancia principal. Los nodos privados no tienen direcciones IP externas y, según la configuración predeterminada, no tienen acceso saliente a Internet. Esto también implica que, de forma predeterminada, el entorno de ejecución del contenedor de tu clúster no puede extraer imágenes de contenedor desde un registro de contenedores externo, ya que esto requiere conectividad de salida (saliente). Puedes considerar alojar tus imágenes de contenedor en Container Registry y acceder a estas imágenes mediante el Acceso privado a Google. Como alternativa, puedes usar Cloud NAT o implementar una puerta de enlace NAT a fin de proporcionar acceso saliente a tus nodos privados.

Además, puedes usar los Controles del servicio de VPC para ayudar a mitigar el riesgo de robo de datos. Los Controles del servicio de VPC te ayudan a proteger los servicios administrados de Google Cloud en uno o más proyectos, ya que te permiten definir un perímetro de servicio para el acceso a estos servicios. Puedes permitir que las aplicaciones que se ejecutan en tus clústeres de GKE tengan acceso a estos servicios administrados mediante la configuración de niveles de acceso adecuados. También puedes usar los Controles del servicio de VPC para proteger el plano de control de creación de clústeres de GKE.

Administra la identidad y el acceso

Acceso a nivel de proyecto

En la sección anterior, se indicó que puedes vincular Funciones de IAM a usuarios en el nivel de proyecto. Además de otorgar funciones a usuarios individuales, puedes usar grupos para simplificar la aplicación de funciones.

En la siguiente ilustración de un diseño de política de IAM, se muestra el principio de privilegio mínimo para un proyecto dev configurado a fin de que los desarrolladores desarrollen y prueben sus próximas funciones y corrijan errores, así como un proyecto prod para el tráfico de producción:

Administración de identidades y accesos.

Como se muestra en la siguiente tabla, hay 4 grupos de usuarios dentro de la organización con niveles diferentes de permisos, otorgados mediante las funciones de IAM en los 2 proyectos:

Equipo Función de IAM Proyecto Permisos
Desarrolladores container.developer dev Pueden crear recursos de Kubernetes para los clústeres existentes en el proyecto; no está permitido crear o borrar clústeres.
Operaciones container.admin prod Tienen acceso total de administrador a los clústeres y recursos de Kubernetes que se ejecutan en el proyecto.
Seguridad container.viewer
security.admin
prod Pueden crear, modificar y borrar reglas de firewall y certificados SSL. También visualizan los recursos que se crearon dentro de cada clúster, incluidos los registros de los Pods en ejecución.
Red network.admin prod Crea, modifica y borra recursos de red, excepto reglas de firewall y certificados SSL.

Además de los 3 equipos con acceso al proyecto de prod, se otorga a una cuenta de servicio adicional la función de container.developer para prod, lo que le permite crear, enumerar y borrar recursos dentro del clúster. Las cuentas de servicio se pueden usar con el fin de que las secuencias de comandos de automatización o los frameworks de implementación puedan actuar en tu nombre. Las implementaciones en tu proyecto de producción y en los clústeres deben pasar por una canalización automatizada.

En el proyecto de dev, hay varios desarrolladores que trabajan en la misma aplicación dentro del mismo clúster. Los espacios de nombres, que el usuario del clúster puede crear, facilitan esto. Cada desarrollador puede crear recursos dentro de su propio espacio de nombres, lo que evita conflictos de nombre. También pueden usar de nuevo los mismos archivos de configuración YAML para sus implementaciones, de modo que sus configuraciones se mantengan lo más similares posible durante las iteraciones de desarrollo. Los espacios de nombres también se pueden usar para crear cuotas en el uso de CPU, memoria y almacenamiento dentro del clúster, lo que garantiza que un desarrollador no use demasiados recursos en el clúster. En la siguiente sección, se analiza la restricción de usuarios para operar dentro de ciertos espacios de nombres.

Control de acceso según la función (RBAC)

Los clústeres de GKE que ejecutan Kubernetes 1.6 y versiones posteriores pueden aprovechar las restricciones adicionales a lo que los usuarios están autorizados a hacer en clústeres individuales. IAM puede proporcionar a los usuarios acceso completo a clústeres y a sus recursos internos, pero el Control de acceso basado en funciones de Kubernetes (RBAC) te permite usar la API de Kubernetes para restringir aún más las acciones que los usuarios puedan realizar dentro de los clústeres.

Con RBAC, los administradores de clústeres aplican políticas detalladas a espacios de nombres individuales dentro de sus clústeres o al clúster en su totalidad. La herramienta de kubectl de Kubernetes usa las credenciales activas de la herramienta de gcloud, lo que permite a los administradores de clústeres mapear funciones a las identidades de Google Cloud (usuarios, cuentas de servicio y Grupos de Google) como sujetos en RoleBindings.

Grupos de Google para GKE (Beta) te permite usar grupos con el RBAC de Kubernetes. Para usar esta característica, debes configurar Grupos de Google en Google Workspace, crear un clúster con la función habilitada y usar objetos RoleBindings para asociar tus grupos con las funciones a las que deseas vincularlos. Para obtener más información, consulta Control de acceso basado en funciones.

Por ejemplo, en la siguiente figura, hay dos usuarios, user-a y user-b, a los que se les otorgaron las funciones de config-reader y pod-reader en el espacio de nombres app-a.

Autorización RBAC.

Como otro ejemplo, existen funciones de IAM a nivel de proyecto de Google Cloud que permiten que ciertos usuarios accedan a todos los clústeres de un proyecto. Además, a través de RBAC, se agregan vinculaciones de funciones individuales a nivel de espacio de nombres y de clúster para brindar acceso detallado a los recursos en los clústeres o espacios de nombres particulares.

RoleBindings de IAM.

Kubernetes incluye algunas funciones predeterminadas, pero, como administrador de clústeres, puedes crear las tuyas para que se ajusten mejor a las necesidades de tu organización. Mediante la siguiente función de ejemplo, los usuarios pueden ver, editar y actualizar ConfigMaps, pero no borrarlos, ya que el verbo delete no está incluido:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Una vez que hayas definido las funciones, puedes aplicarlas al clúster o al espacio de nombres mediante las vinculaciones. Estas asocian funciones a sus usuarios, grupos o cuentas de servicio. En el siguiente ejemplo, se muestra cómo vincular una función ya creada (config-editor) al usuario bob@example.org y al espacio de nombres development.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

Para obtener más información sobre el RBAC, consulta la documentación de GKE.

Acceso a imágenes y uso compartido

Las imágenes de Container Registry o Artifact Registry (Beta) se almacenan en Cloud Storage. En esta sección, se analizan dos formas de compartir imágenes. Una es hacerlas públicas; la otra es compartir imágenes entre proyectos.

Haz públicas las imágenes en Container Registry

Puedes hacer públicas las imágenes si haces públicos los objetos y depósitos que les crean copias de seguridad. Para ver instrucciones más detalladas, consulta la documentación de control de acceso de Container Registry.

Accede a las imágenes de varios proyectos en Container Registry

Puedes compartir imágenes de contenedor entre proyectos si te aseguras de que los nodos de Kubernetes usan una cuenta de servicio. La cuenta de servicio predeterminada asociada con el proyecto tiene el siguiente formato:

project-id-compute@developer.gserviceaccount.com

Una vez que tengas este identificador, puedes otorgarle acceso como un storage.viewer en los proyectos en los que desees usar Container Registry. Usa una cuenta de servicio personalizada que tenga permisos restringidos, ya que la cuenta de servicio predeterminada tiene acceso de editor en todo el proyecto.

Si deseas usar una cuenta de servicio diferente para los clústeres, debes proporcionar la cuenta de servicio mediante la marca --service-account en el momento de la creación del clúster o el grupo de nodos. Por ejemplo, para usar la cuenta de servicio gke-sa en el proyecto my-project, ejecuta lo siguiente:

gcloud container clusters create west --service-account \
    gke-sa@my-project.google.com.iam.gserviceaccount.com

Si deseas obtener información sobre cómo migrar tus imágenes de contenedor de Container Registry a Artifact Registry, consulta Transición desde Container Registry.

Determina la política de extracción de imágenes adecuada

La propiedad imagePullPolicy determina si Kubelet intenta extraer una imagen mientras inicia un pod. Debes considerar una configuración de imagePullPolicy adecuada para especificar tus imágenes de contenedor. Por ejemplo, puedes especificar la siguiente política de extracción de imágenes:

imagePullPolicy: IfNotPresent

En este caso, Kubelet recupera una copia de la imagen solo si no está disponible en la memoria caché del nodo.

Para obtener más información sobre las posibles políticas de extracción de imágenes que puedes especificar, consulta Container Images (Imágenes de contenedor) en la documentación de Kubernetes.

Usa webhooks de admisión dinámicos para aplicar las políticas

Los webhooks de admisión dinámicos son parte del plano de control de Kubernetes. Pueden interceptar solicitudes entrantes realizadas al servidor de la API. Los webhooks de admisión son una herramienta potente que puede ayudarte a aplicar políticas personalizadas específicas de tu empresa en los clústeres de GKE.

Kubernetes admite dos tipos de webhooks de admisión: de mutación y de validación.

Los webhooks de admisión de mutación interceptan las solicitudes de admisión y pueden mutar (alterar) la solicitud. La solicitud luego se pasa al servidor de la API.

Los webhooks de admisión de validación examinan una solicitud y determinan si es válida según las reglas que especifiques. Si se configuran estos webhooks en el clúster, se los invoca después de que el servidor de API haya validado la solicitud. Los webhooks de admisión de validación pueden rechazar las solicitudes para garantizar que se cumplan las políticas definidas en el webhook.

Por ejemplo, puedes aplicar una política de extracción de imágenes mediante un webhook de admisión de mutación para asegurarte de que la política se establezca en Always, sin importar la configuración de imagePullPolicy que especificaron los desarrolladores que enviaron solicitudes de creación de Pods.

Otras consideraciones para la implementación de imágenes

Una práctica recomendada consiste en usar un registro de contenedores privado, como Container Registry, para contener el conjunto seleccionado de imágenes de tu organización. Esto ayuda a reducir el riesgo de introducir vulnerabilidades en tu canalización de implementación (y, al final, en las cargas de trabajo de la aplicación). Si es posible, habilita el Container Analysis, como el análisis de vulnerabilidades, para ayudar a reducir aún más los riesgos de seguridad.

Si debes usar imágenes públicas, considera validar el conjunto de imágenes públicas que pueden implementarse en tus clústeres. (Para obtener más información, consulta la sección Autorización binaria). También puedes implementar apps de Kubernetes empaquetadas de forma previa desde Google Cloud Marketplace. Google prueba y verifica las apps de Kubernetes que se enumeran en Google Cloud Marketplace, incluidos el análisis de vulnerabilidades y los acuerdos de socios para proporcionar mantenimiento y asistencia.

Además, asegúrate de implementar buenas prácticas de control de versiones de imágenes: usa las convenciones de etiquetado adecuadas y considera usar resúmenes en lugar de etiquetas cuando corresponda.

Usa Workload Identity para interactuar con las API de servicio de Google Cloud

A menudo, las arquitecturas empresariales incluyen componentes de arquitectura que abarcan servicios en la nube: servicios administrados en la nube y servicios alojados. Es un patrón común que tus aplicaciones o servicios de GKE tengan que comunicarse con servicios administrados de Google Cloud, como Cloud Storage y BigQuery. Por ejemplo, es posible que, después de que los trabajos por lotes en GKE procesen registros de clientes, debas almacenarlos en BigQuery para su análisis posterior.

Workload Identity es una función de GKE que permite que los servicios de GKE interactúen con el ecosistema más amplio de Google Cloud sin tener que almacenar credenciales de cuenta de servicio como secretos de Kubernetes. Esta función te permite asignar una cuenta de servicio de Kubernetes a una cuenta de servicio de Google Cloud con la ayuda de una vinculación de IAM. Luego, cuando los Pods se ejecuten con la cuenta de servicio de Kubernetes, pueden tomar la identidad necesaria para acceder al servicio de Google Cloud. Ten en cuenta que esto supone que otorgaste el nivel de acceso requerido para el servicio a la cuenta de servicio de Google Cloud.

Para obtener más información sobre Workload Identity, consulta la documentación de GKE.

Administra la seguridad del clúster

La seguridad es una disciplina multifacética de suma importancia en las implementaciones empresariales de clústeres de GKE. En esta sección, se abordan varios factores que puedes usar para endurecer la seguridad de tu clúster.

Análisis de vulnerabilidades para las imágenes

Container Registry puede analizar las imágenes que se le envían y buscar vulnerabilidades de seguridad conocidas para las imágenes basadas en Ubuntu, Alpine, Debian, CentOS y Red Hat. Te recomendamos que aproveches esta función para analizar imágenes que planeas usar en tus clústeres de Kubernetes.

Puedes ver las vulnerabilidades de una imagen en Google Cloud Console o ejecutar el siguiente comando de gcloud:

gcloud beta container images describe \
    hostname/project-id/image-id:tag  \
    --show-package-vulnerability

Reemplaza lo siguiente:

  • hostname: Una de las siguientes ubicaciones de nombres de host:
    • gcr.io, que en la actualidad aloja las imágenes en los Estados Unidos
    • us.gcr.io, que aloja la imagen en los Estados Unidos en un depósito de almacenamiento independiente de las imágenes que aloja gcr.io
    • eu.gcr.io, que aloja las imágenes en la Unión Europea
    • asia.gcr.io, que aloja las imágenes en Asia
  • project-id: El ID del proyecto que contiene las imágenes
  • image-id: El ID de la imagen de la que deseas ver las vulnerabilidades
  • tag: La etiqueta de imagen sobre la que deseas obtener información

Tu organización puede beneficiarse de automatizar el seguimiento y la recepción de notificaciones cuando se realizan cambios en tu repositorio de Container Registry. Por ejemplo, puedes recibir una notificación cuando se borra una imagen o se crea una nueva. Puedes compilar una canalización en la que los objetos de escucha de la aplicación estén suscritos a un tema de Pub/Sub en el que se publiquen los eventos de Container Registry. Luego, puedes usar estos eventos para activar compilaciones o implementaciones automatizadas. Para obtener más información, consulta la documentación de Container Registry.

Autorización binaria

Con Kubernetes, debes determinar si se debe considerar que una imagen sea válida para la implementación en tu clúster y cuándo hacerlo. Para esta tarea, puedes usar la autorización binaria. Esta es una construcción de tiempo de implementación que te permite definir un flujo de trabajo que aplique las firmas (certificaciones) que una imagen debe tener para poder implementarse en el clúster.

El flujo de trabajo se define en términos de políticas. A medida que trasladas tu código y, por lo tanto, tu imagen de contenedor a través de una canalización de CI/CD, la autorización binaria registra las certificaciones de cada una de estas etapas según se define en tu política de autorización binaria. Estas certificaciones validan que una imagen haya aprobado con éxito los eventos importantes definidos.

La autorización binaria se integra en la API de implementación de GKE y puede garantizar que la implementación de una imagen esté sujeta a que esta tenga todas las certificaciones necesarias. Los intentos de implementación fallidos se registran de forma automática y los administradores de clústeres pueden revisarlos y auditarlos.

Si quieres ver un instructivo sobre cómo implementar la autorización binaria para GKE mediante Cloud Build, consulta Implementa la autorización binaria mediante Cloud Build y GKE.

Acceso seguro con gVisor en GKE Sandbox

Un contenedor proporciona una capa de aislamiento de kernel y seguridad, pero podría ser susceptible a incumplimientos que proporcionen a los atacantes acceso al sistema operativo (SO) del host. Un enfoque más resistente para el aislamiento de seguridad entre un contenedor y el SO del host es crear otra capa de separación. Un enfoque consiste en usar GKE Sandbox.

GKE Sandbox usa gVisor, un entorno de ejecución de contenedores de código abierto que lanzó Google. De forma interna, gVisor crea un kernel virtual para que los contenedores interactúen, lo que abstrae el alcance que tiene un contenedor en el kernel de host. Además, aplica un control sobre las operaciones de archivos y redes que el contenedor puede realizar.

Debido a que GKE Sandbox crea una capa adicional de aislamiento, puede incurrir en memoria adicional y sobrecarga de la CPU. Antes de usar GKE Sandbox, considera qué cargas de trabajo necesitan este nivel de seguridad elevado. Por lo general, los buenos candidatos son servicios que se basan en imágenes externas.

Con el siguiente comando de gcloud, se muestra cómo crear un grupo de nodos con GKE Sandbox habilitado:

gcloud container node-pools create node-pool-name \
    --cluster=cluster \
    --image-type=cos_containerd \
    --sandbox type=gvisor \
    --enable-autoupgrade

Reemplaza lo siguiente:

  • node-pool-name: El nombre del grupo de nodos que se creará
  • cluster: El clúster al que se agregará el grupo de nodos

Para especificar qué Pods de la aplicación se ejecutan con GKE Sandbox, incorpora gVisor en la especificación del Pod como se muestra en el siguiente ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: sample-saas-app
  labels:
    app: saas-v1
spec:
  runtimeClassName: gvisor
  containers:
    - name: sample-node-app-v1
      image: [image]

Para obtener más información sobre GKE Sandbox, consulta GKE Sandbox: Profundiza la defensa de tus Pods en el blog de Google Cloud. A fin de obtener más información sobre si tu aplicación es adecuada para GKE Sandbox, consulta la documentación de GKE.

Registro de auditoría

El registro de auditoría de Kubernetes registra todas las solicitudes a la API que se realizan en el servidor de la API de Kubernetes. Este registro es útil para ayudarte a detectar anomalías y patrones inusuales en el acceso y la configuración. A continuación, se presentan ejemplos de lo que deberías revisar y alertar:

  • Eliminación de una implementación
  • Conexión o usp de exec para acceder a un contenedor que tiene acceso privilegiado
  • Modificación de objetos ClusterRole o creación de vinculaciones de funciones para las funciones del clúster
  • Creación de cuentas de servicio en el espacio de nombres kube-system

GKE integra el registro de auditoría de Kubernetes a Cloud Logging. Puedes acceder a estos registros de la misma manera en que accedes a los registros de los recursos que se ejecutan en tu proyecto de Cloud. Las solicitudes a la API realizadas al servidor de la API de Kubernetes se pueden registrar, y puedes usarlas para revisar los patrones de actividad de la API.

Cada solicitud (evento) que captura el servidor de API de Kubernetes se procesa mediante una o más políticas que defines. Pueden ser políticas de auditoría de Kubernetes que determinan qué eventos se registran, o pueden ser políticas de auditoría de Google Kubernetes Engine que determinan si los eventos se registran en el registro de actividad del administrador o en el registro de datos. Los registros de actividad del administrador están habilitados de forma predeterminada. También puedes habilitar el registro de acceso a los datos si necesitas registrar detalles sobre qué metadatos y datos se leyeron o escribieron en los clústeres. Ten en cuenta que habilitar el registro de acceso a los datos puede generar cargos adicionales. Para obtener más información, consulta la documentación sobre precios.

PodSecurityPolicies

Un vector de ataque común consiste en implementar Pods con privilegios escalados para obtener acceso a un clúster de Kubernetes. PodSecurityPolicies define un conjunto de reglas en la especificación del Pod que describen lo que un Pod puede hacer. Implementas una PodSecurityPolicy en Kubernetes como un recurso de controlador de admisión. Puedes usarla para restringir el acceso a cómo se usan los espacios de nombres, cómo se usan los tipos de volúmenes y a las capacidades subyacentes del SO.

Para crear un clúster de GKE con una PodSecurityPolicy habilitada, usa el siguiente comando. Reemplaza cluster-name por el nombre del clúster al que agregas una PodSecurityPolicy.

gcloud beta container clusters create cluster-name \
    --enable-pod-security-policy

En el siguiente ejemplo, se muestra una PodSecurityPolicy que restringe la capacidad para crear Pods con privilegios.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: default-pod-security-policy
spec:
  privileged: false
  hostPID: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

Consideraciones de seguridad de contenedores

El componente fundamental para los servicios de Kubernetes es el contenedor. Esto hace que la seguridad del contenedor sea un factor clave cuando planificas la seguridad y las políticas del clúster. Considera con detenimiento los siguientes puntos:

  • Las imágenes a partir de las cuales compilas tus contenedores
  • Los privilegios que asignas a los contenedores
  • Cómo interactúan los contenedores con el SO del host y otros servicios
  • Cómo acceden los contenedores a la información sensible y cómo la registran
  • Cómo administras el ciclo de vida de los contenedores en tus clústeres

Para obtener más información y prácticas recomendadas, consulta la documentación sobre cómo compilar y operar contenedores.

Configura Herramientas de redes

Kubernetes brinda una abstracción del servicio que incluye balanceo de cargas y descubrimiento de servicios en conjuntos de Pods dentro de un clúster, así como sistemas heredados que se ejecutan fuera del clúster. En las siguientes secciones, se describen las prácticas recomendadas para la comunicación entre los Pods de Kubernetes y con otros sistemas, incluidos otros clústeres de Kubernetes.

Comparación entre los clústeres nativos de la VPC y los clústeres basados en rutas

Según la forma en que los clústeres de GKE enrutan el tráfico de un Pod a otro, se los puede clasificar en dos tipos. La primera opción es un clúster que usa rangos de alias de IP para enrutar el tráfico. Esto se denomina clúster nativo de la VPC. La segunda opción es un clúster que usa rutas de Google Cloud, lo que se denomina clúster basado en rutas.

Los clústeres nativos de la VPC usan rangos de alias de IP para las redes de Pods. Esto significa que el plano de control administra de forma automática la configuración de enrutamiento de los Pods en lugar de configurar y mantener rutas estáticas para cada nodo en el clúster de GKE. Mediante el uso de rangos de alias de IP, puedes configurar varias direcciones IP internas que representen contenedores o aplicaciones alojadas en una VM, sin tener que definir una interfaz de red independiente. Google Cloud instala de forma automática rutas de redes de VPC para los rangos de IP de alias y principales de la subred de la interfaz de red principal. Esto simplifica en gran medida el enrutamiento del tráfico de Pod a Pod.

Además, los clústeres nativos de la VPC no están sujetos a cuotas de rutas. Aprovechar los rangos de alias de IP en la estructura del clúster proporciona acceso directo a los servicios de Google, como Cloud Storage y BigQuery. De lo contrario, este acceso solo podría proporcionarse con una puerta de enlace de NAT.

Es un patrón común que las empresas hagan que sus clústeres de GKE se comuniquen de forma segura con su ecosistema local de aplicaciones y servicios. Los rangos de alias de IP lo permiten, ya que las direcciones de alias de IP son detectables a través de Cloud VPN o Cloud Interconnect. Esto te brinda conectividad segura en tu infraestructura local y de Google Cloud.

Debes decidir qué tipo de clúster se adapta mejor a la topología de red. Los factores clave son la disponibilidad de direcciones IP en tu red, los planes de expansión de clústeres (nodos) en tu empresa y la conectividad a otras aplicaciones del ecosistema. Los clústeres nativos de la VPC tienden a consumir más direcciones IP en la red, por lo que debes tener esto en cuenta. Ten en cuenta que no puedes migrar un clúster nativo de la VPC a un clúster basado en rutas después de la creación ni un clúster basado en rutas a un clúster nativo de la VPC, por lo que es importante comprender las implicaciones de tu elección antes de implementarlo.

Comunicación dentro del mismo clúster

Service Discovery

Kubernetes te permite definir los servicios que agrupan los Pods ejecución en el clúster con base en un conjunto de etiquetas. Este grupo de Pods se puede detectar dentro del clúster mediante DNS. Para obtener más información sobre el descubrimiento de servicios en Kubernetes, consulta la documentación Conecta aplicaciones con servicios.

DNS

Un servidor DNS local del clúster, kube-dns, se implementa en cada clúster de GKE que gestiona la asignación de nombres de servicios a las IP de los Pods en buen estado. De forma predeterminada, el servidor DNS de Kubernetes muestra la dirección IP del clúster del servicio. Esta dirección IP es estática durante toda la vida útil del servicio. Cuando se envía tráfico a esta IP, los iptables en los nodos de balanceo de cargas de nodo en los pods que están listos y que coinciden con los selectores del servicio. El servicio kube-proxy que se ejecuta en cada nodo programa estos iptables automáticamente.

Si deseas realizar un descubrimiento de servicios y una supervisión de estado, pero prefieres que el servicio de DNS muestre las direcciones IP de los Pods en lugar de una dirección IP virtual, puedes aprovisionar el servicio con el campo ClusterIP configurado como “None”, lo que hace que el servicio no tenga interfaz gráfica. En este caso, el servidor DNS muestra una lista de registros A que asignan el nombre DNS del servicio a los registros A de los Pods que están listos y que coinciden con los selectores de etiquetas que el servicio define. Los registros en la respuesta se rotan para facilitar la distribución de la carga en todos los pods. Es posible que algunas resoluciones de DNS del cliente almacenen las respuestas DNS en caché, lo que procesa la rotación de los registros A de manera ineficiente. Las ventajas de usar ClusterIP se muestran en la documentación de Kubernetes.

Un caso práctico típico de los servicios headless es con StatefulSets. Los StatefulSets son adecuados para ejecutar aplicaciones con estado que requieren almacenamiento y redes estables entre sus réplicas. Este tipo de implementación aprovisiona pods que tienen una identidad de red estable, lo que significa que sus nombres de host se pueden resolver en el clúster. Aunque la dirección IP del pod puede cambiar, su entrada DNS de nombre de host se mantiene actualizada y se puede resolver.

Flujo de paquetes: ClusterIP

El siguiente diagrama muestra la respuesta DNS y el flujo de paquetes de un servicio estándar de Kubernetes. Si bien las direcciones IP de los pod se pueden enrutar desde el exterior del clúster, solo se puede acceder a la dirección IP del clúster de un servicio dentro del clúster. Estas direcciones IP virtuales se implementan mediante la traslación de direcciones de red de destino (DNAT) en cada nodo de Kubernetes. El servicio kube-proxy que se ejecuta en los nodos mantiene las reglas de reenvío actualizadas en cada nodo que asigna la dirección IP del clúster a las direcciones IP de Pods en buen estado en el clúster. Si hay un Pod del servicio que se ejecuta en el nodo local, se usa ese Pod, de lo contrario, se elige uno aleatorio en el clúster.

Servicio ClusterIP.

Para obtener más información sobre cómo se implementa ClusterIP, consulta la documentación de Kubernetes. Para obtener información más detallada sobre las herramientas de redes de GKE, mira la charla de Next 2017 en YouTube:

Servicios headless

El siguiente es un ejemplo de la respuesta DNS y el patrón de tráfico para un servicio sin interfaz gráfica. Las direcciones IP de los Pod se pueden enrutar mediante las tablas de rutas de subred predeterminadas de Google Cloud, y la aplicación accede directamente a ellas.

Ejemplo de respuesta DNS y patrón de tráfico para el servicio sin interfaz gráfica.

Políticas de red

Puedes usar la aplicación de la política de red de GKE para controlar la comunicación entre los pods y los servicios del clúster. Para definir una política de red en GKE, puedes usar la API de política de red de Kubernetes a fin de crear reglas de firewall a nivel del pod. Estas reglas de firewall determinan qué Pods y servicios pueden acceder unos a otros dentro del clúster.

Las políticas de red son un tipo de defensa en profundidad que mejora la seguridad de las cargas de trabajo que se ejecutan en el clúster. Por ejemplo, puedes crear una política de red para asegurarte de que un servicio de frontend vulnerable en la aplicación no pueda comunicarse directamente con un servicio de facturación o contabilidad en varios niveles inferiores.

Las políticas de red también se pueden usar para aislar cargas de trabajo que pertenezcan a instancias diferentes. Por ejemplo, puedes proporcionar usuarios múltiples seguros si defines un modelo de usuario por espacio de nombres. En este modelo, las reglas de la política de red pueden garantizar que los pods y los servicios en un espacio de nombres determinado no puedan acceder a otros pods o servicios en un espacio de nombres diferente.

Para obtener más información sobre las políticas de red, consulta la documentación de GKE.

Conéctate a un clúster de GKE desde Google Cloud

Para conectarte a tus servicios desde afuera del clúster, pero dentro del espacio de la dirección IP privada de la red de Google Cloud, usa el balanceo de cargas interno. Cuando se crea un servicio con type: Load Balancer y una anotación cloud.google.com/load-balancer-type: Internal en Kubernetes, se crea un balanceador de cargas de red interno en tu proyecto de Google y se lo configura para distribuir tráfico de TCP y UDP entre los Pods.

Conéctate desde un clúster a servicios externos

En muchos casos, es necesario conectar las aplicaciones que se ejecutan dentro de Kubernetes con un servicio, una base de datos o una aplicación que se encuentre fuera del clúster. Tienes 3 opciones, como se describe en las siguientes secciones.

Dominios de stub

En Kubernetes 1.6 y versiones posteriores, puedes configurar el servicio de DNS interno del clúster (kube-dns) para reenviar consultas de DNS de un dominio determinado a un servidor DNS externo. Esto es útil cuando cuentas con servidores DNS autorizados que se deben consultar para un dominio que tus pods de Kubernetes deben usar.

Servicios de nombre externo

Los servicios de nombre externo te permiten asignar un registro DNS a un nombre de servicio en el clúster. En este caso, las consultas de DNS para el servicio en el clúster muestran un registro CNAME de tu elección. Úsalas solo tienes algunos registros que deseas asignar de nuevo a los servicios DNS existentes.

Servicios sin selectores

Puedes crear servicios sin un selector y luego agregarle extremos de forma manual a fin de propagar la detección del servicio con los valores correctos. Esto te permite usar el mismo mecanismo de detección de servicios para tus servicios en el clúster mientras te aseguras de que se pueda acceder a los sistemas sin detección de servicios a través de DNS. Si bien este enfoque es el más flexible, también requiere la mayor configuración y mantenimiento a largo plazo.

Para obtener más información sobre DNS, dirígete a la página de documentación Kubernetes DNS Pods and Services (Pods y servicios de DNS de Kubernetes).

Configura servicios en Kubernetes para recibir tráfico de Internet

Los servicios de Kubernetes se pueden exponer mediante NodePort, ClusterIP y LoadBalancer.

Sin embargo, cuando tienes muchos servicios externos, puedes considerar usar los recursos Ingress de Kubernetes. Ingress proporciona un punto de entrada a tu clúster y te permite definir reglas de enrutamiento que enruten las solicitudes entrantes a uno o más servicios de backend en tu clúster. El controlador de Ingress de GKE implementa un recurso Ingress como balanceador de cargas de HTTP(S) de Google Cloud y lo configura según la información en el recurso Ingress y sus servicios asociados.

Un recurso Ingress de Kubernetes solo se puede usar cuando tus aplicaciones entregan tráfico a través de HTTP(S). Si tus servicios de backend usan protocolos TCP o UDP, debes usar un balanceador de cargas de red. Esto podría ser necesario, por ejemplo, si necesitas exponer tu base de datos como servicio.

Configuración de backend

Una BackendConfig es una definición de recursos personalizada que puede proporcionar una configuración prescriptiva adicional que usa el controlador de Ingress de Kubernetes. Cuando implementas un objeto Ingress en tu clúster de GKE, el controlador de Ingress de Kubernetes configura un balanceador de cargas de HTTP(S) que enruta las solicitudes entrantes a los servicios de backend, como especificaste en el manifiesto de Ingress.

Puedes complementar la configuración del balanceador de cargas con especificaciones como las siguientes:

  • Habilita el almacenamiento en caché con Cloud CDN.
  • Agrega listas de anunciantes permitidos de direcciones IP o CIDR (listas blancas) con Google Cloud Armor.
  • Controla el acceso a nivel de aplicación con Identity-Aware Proxy (IAP).
  • Configura tiempos de espera de servicio y tiempos de espera de vaciado de conexiones para servicios que están regidos por el objeto Ingress en un clúster.

Para obtener más información sobre cómo configurar el recurso personalizado de BackendConfig en GKE, consulta la documentación de GKE.

Usa una malla de servicios

Una malla de servicios proporciona una manera uniforme de conectar, proteger y administrar microservicios que se ejecutan en tus clústeres de Kubernetes. Por ejemplo, la malla de servicios de Istio, que puedes agregar como un complemento de GKE, puede administrar la autenticación y comunicación de servicio a servicio, aplicar políticas de acceso y recopilar datos de telemetría detallados que puedes usar para auditar y administrar tus clústeres de GKE.

Las siguientes son algunas de las funciones clave que proporciona una malla de servicios:

  • Administración del tráfico. La malla de servicios te permite definir reglas detalladas que determinan cómo se enruta y divide el tráfico entre servicios o entre diferentes versiones del mismo servicio. Esto facilita el lanzamiento de versiones canary y de implementaciones azul-verde.

  • Observabilidad integrada. La malla registra las métricas de tráfico de red (capa 4 y capa 7) de manera uniforme sin necesidad de que escribas código para instrumentar tus servicios.

  • Seguridad. La malla habilita la TLS mutua (mTLS) entre los servicios. Proporciona canales seguros para los datos en tránsito y te ayuda a administrar la autenticación y la autorización de servicios en la malla.

En resumen, las mallas de servicios como Istio te permiten delegar tareas a nivel de sistema a la infraestructura de malla. Esto mejora la agilidad general, la solidez y el acoplamiento bajo de los servicios que se ejecutan en tus clústeres de Kubernetes.

Para obtener más información, consulta Istio en Google Kubernetes Engine.

Firewall

Los nodos de GKE se aprovisionan como instancias en Compute Engine. Como tales, se adhieren al mismo mecanismo de firewall con estado que otras instancias. Estas reglas de firewall se aplican a las instancias dentro la red mediante el uso de etiquetas. Cada grupo de nodos recibe su propio conjunto de etiquetas que puedes usar en las reglas. Según la configuración predeterminada, cada instancia que pertenece a un grupo de nodos recibe una etiqueta que identifica un clúster específico de Kubernetes Engine del que forma parte este grupo de nodos. Esta etiqueta se usa en las reglas de firewall que Kubernetes Engine crea de forma automática para ti. Puedes agregar tus propias etiquetas personalizadas durante la creación del grupo de nodos o el clúster mediante la marca --tags en la herramienta de gcloud.

Por ejemplo, para permitir el acceso de un balanceador de cargas interno al puerto 8080 en todos los nodos, tendrías que usar los siguientes comandos:

gcloud compute firewall-rules create allow-8080-fwr \
    --target-tags allow-8080 \
    --allow tcp:8080 \
    --network gke \
    --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

En el ejemplo que se presenta a continuación, se muestra cómo etiquetar un clúster de modo que el tráfico de Internet pueda acceder a los nodos en el puerto 30000, mientras que el otro clúster está etiquetado para permitir el tráfico de la VPN al puerto 40000. Esto es útil cuando se expone un servicio a través de un NodePort al que solo se debe acceder mediante redes con privilegios, como una VPN a un centro de datos corporativo o desde otro clúster dentro del proyecto.

Etiqueta dos clústeres de manera diferente.

Conéctate a un centro de datos local

Hay varias opciones de Cloud Interconnect para conectarse a centros de datos locales. Estas opciones no se excluyen mutuamente, por lo que puedes tener una combinación con base en la carga de trabajo y los requisitos:

  1. Internet para las cargas de trabajo que no requieren una gran cantidad de datos ni son sensibles a la latencia. Google tiene más de 100 puntos de presencia (PoP) que se comunican con proveedores de servicios en todo el mundo.
  2. El intercambio de tráfico directo para cargas de trabajo que requieren ancho de banda dedicado, son sensibles a la latencia y necesitan acceso a todos los servicios de Google, incluido el kit completo de productos de Google Cloud. El intercambio de tráfico directo es una conexión de capa 3 que se realiza mediante el intercambio de rutas BGP y, por lo tanto, requiere un ASN registrado.
  3. El intercambio de tráfico por proveedores es igual que el intercambio de tráfico directo, pero se realiza a través de un proveedor de servicios. Esta es una excelente opción si no cuentas con un ASN registrado o si tienes relaciones con un proveedor de servicios de tu preferencia.
  4. Cloud VPN se configura a través de las opciones de interconexión y de Internet de capa 3 (1, 2 y 3), si se requiere encriptación IPsec o si deseas extender tu red privada a tu red privada de Compute Engine.

Administra la operabilidad del clúster

En esta sección, se analizan los factores clave a tener en cuenta cuando administras y operas tus clústeres de GKE.

Cuotas de recursos

Las cuotas de recursos de Kubernetes proporcionan restricciones que limitan el consumo agregado permitido de recursos para cada espacio de nombres en un clúster. Si tienes clústeres con espacios de nombres de Kubernetes que aíslan las funciones empresariales o etapas de desarrollo, puedes usar las cuotas para limitar una amplia variedad de recursos, como el uso de CPU, memoria o la cantidad de Pods y servicios que se pueden crear dentro de un espacio de nombres. Para garantizar la estabilidad del plano de control de tus clústeres de GKE, Kubernetes aplica de forma automática cuotas de recursos predeterminadas que no se pueden anular a cada espacio de nombres en cualquier clúster de GKE que tenga cinco nodos o menos.

Límites de recursos

Puedes usar el objeto LimitRange de Kubernetes para aplicar restricciones detalladas en los límites mínimos y máximos de los recursos con los que se pueden crear contenedores y Pods. En el siguiente ejemplo, se muestra cómo usar LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: sample-limits
spec:
  limits:
    - max:
        cpu: "400m"
        memory: "1Gi"
      defaultRequest:
        cpu: "200m"
        memory: "500Mi"
      type: Container

Presupuestos de interrupción del Pod

Los presupuestos de interrupción del Pod (PDB) ayudan a proteger contra la eliminación voluntaria o accidental de los Pods o las implementaciones que realiza tu equipo. Los PDB no pueden prevenir interrupciones involuntarias que puede provocar un nodo que falla o se reinicia. Por lo general, un operador crea un PDB para una aplicación que define la cantidad mínima de réplicas de los pods para la aplicación.

En una empresa en la que los desarrolladores trabajan en varias aplicaciones, se producen errores y un desarrollador o administrador podría ejecutar por accidente una secuencia de comandos que borre Pods o implementaciones; en otras palabras, que borre tus recursos de Kubernetes. Sin embargo, cuando defines un PDB, ayudas a garantizar un conjunto mínimo de recursos accesibles para tus aplicaciones de Kubernetes en todo momento.

Los PDB que configuras para tus clústeres de GKE se respetan durante las actualizaciones de GKE. Esto significa que puedes controlar la disponibilidad de tus aplicaciones durante una actualización. En el siguiente ejemplo, se muestra cómo puedes configurar un PDB.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
  spec:
    minAvailable: 4
    selector:
      matchLabels:
        app: nginx

Administra las actualizaciones de Kubernetes

Mantén tus clústeres de Kubernetes en GKE actualizados a la última versión de Kubernetes que se adapte a tus requisitos. Esto te permite aprovechar las funciones nuevas que se lanzan y garantizar que el sistema operativo subyacente de los nodos de tu clúster tenga parches y esté actualizado.

Cuando se necesite una actualización, puedes considerar los siguientes tipos:

  • Actualizaciones de versiones principales y secundarias de Kubernetes de tu clúster de GKE para los nodos principales y trabajadores
  • Parches de SO y actualizaciones de las máquinas virtuales (nodos) que constituyen tu clúster

Actualiza la versión de Kubernetes

Tienes dos opciones para actualizar tus nodos principales de GKE. La primera es permitir que Google Cloud actualice de forma automática la instancia principal del clúster de GKE. La segunda es iniciar una actualización manual cuando hay una versión más reciente disponible.

Puedes revisar las notificaciones de la consola que aparecen en tus clústeres de GKE cuando hay actualizaciones disponibles. Te recomendamos que actives la actualización de la versión después de revisar el contenido de la versión y de probar tus aplicaciones en un clúster de zona de pruebas que se ejecute en la versión a la que deseas actualizar.

Cuando el nodo principal de un clúster zonal se somete a una actualización, el plano de control no está disponible. Esto significa que no puedes interactuar con el servidor de la API para agregar o quitar recursos en tu clúster. Si no puedes permitirte el tiempo de inactividad para actualizar un nodo principal en tu clúster zonal, puedes hacer que el nodo principal tenga alta disponibilidad mediante la implementación de clústeres de GKE regionales. Con este enfoque, puedes tener varios nodos principales que se distribuyan en distintas zonas. Cuando se actualiza un nodo principal, las solicitudes del plano de control al servidor de la API se enrutan al otro nodo principal o nodos principales.

Al igual que con los nodos principales, tienes dos opciones para actualizar los nodos trabajadores de GKE a la misma versión que el nodo principal del clúster:

  • Puedes hacer que GKE administre las actualizaciones de los nodos trabajadores por ti. Si deseas hacerlo, habilita la actualización automática de nodos para los grupos de nodos en tu clúster de GKE.
  • Puedes actualizar de forma manual los nodos trabajadores de GKE. Cuando hay una actualización disponible, se muestra una alerta en la consola de GKE. Cuando veas esa alerta, puedes aplicar la actualización a tus nodos trabajadores de GKE.

En ambos casos, cuando se aplica una actualización, GKE aplica una actualización progresiva a los nodos trabajadores: de manera sistemática, desvía, desactiva y actualiza un nodo a la vez cuando un nodo de reemplazo nuevo está disponible para responder a las solicitudes entrantes.

Reparación automática de nodos

La función de reparación automática de nodos de GKE administra las verificaciones de estado de tus nodos de GKE. Si se detecta que alguno de los nodos no está en buen estado, GKE inicia el proceso de reparación de nodos.

El proceso de reparación de nodos administrado implica el desvío y la recreación del nodo. Si es necesario reparar varios nodos en tu clúster de GKE al mismo tiempo, Google Cloud determina de forma interna cuántos nodos se pueden reparar en paralelo.

Si creas clústeres en Google Cloud Console, la función de reparación automática se habilita de forma automática. En los clústeres de GKE que creas mediante la herramienta de gcloud, puedes habilitar la reparación automática de forma explícita si incluyes la marca --enable-autorepair en el comando de creación del clúster.

Si tu clúster de GKE tiene varios grupos de nodos, la función de reparación automática te brinda un control detallado sobre los grupos de nodos para los que deseas habilitar la reparación automática de nodos.

Ajuste de escala automático de clústeres de GKE

Las empresas suelen experimentar una carga entrante variable en las aplicaciones que se ejecutan en sus clústeres de Kubernetes. Para responder a estos cambios basados en el negocio, puedes habilitar tus clústeres de GKE a fin de que respondan de forma automática y aumenten y disminuyan la escala según las métricas.

El ajuste de escala automático incluye varias dimensiones, como se explica en las siguientes secciones.

Escalador automático del clúster

El escalador automático del clúster de GKE agrega y quita nodos de tu clúster de forma automática según la demanda de tus cargas de trabajo. El escalador automático del clúster está habilitado para grupos de nodos individuales. GKE verifica en cada grupo de nodos si hay Pods que están en espera para programarse debido a la falta de capacidad. Si es así, el escalador automático del clúster agrega nodos a ese grupo de nodos.

Una combinación de factores influye en cómo GKE decide disminuir la escala. Si los Pods que se ejecutan en un nodo usan menos del 50% y los Pods en ejecución se pueden programar en otros nodos que tienen capacidad, el nodo con poco uso se desviará y finalizará.

Puedes configurar los límites de un grupo de nodos si especificas los nodos mínimos y máximos hasta los cuales puede escalar el escalador automático del clúster.

Ajuste de escala automático horizontal de Pods (HPA)

Kubernetes te permite crear un escalador automático de Pod horizontal (HPA) que te permite configurar cómo se deben escalar los ReplicaSets y las implementaciones de Kubernetes, además de las métricas en las que se debe basar la decisión de escalamiento. De forma predeterminada, el controlador de HPA basa las decisiones sobre el ajuste de escala automático en el uso de CPU. Sin embargo, el controlador de HPA también puede calcular cómo se debe escalar los Pods en función de las métricas personalizadas, como un recuento de solicitudes HTTP. Para que un HPA responda a métricas personalizadas, por lo general, se requiere instrumentación de supervisión adicional.

Para obtener más información, consulta la documentación de Kubernetes y GKE.

Ajuste de escala automático vertical de Pods (VPA)

La función de ajuste de escala automático vertical de Pods (VPA) en los clústeres de GKE te permite descargar la tarea de especificar solicitudes óptimas de CPU y memoria para los contenedores. Cuando sea necesario, el VPA ajusta las asignaciones de recursos que se realizan en los contenedores de tu clúster. El VPA te permite optimizar el uso de recursos para clústeres mediante la optimización a nivel de contenedor en cada nodo. También elimina el tiempo de administración que, de lo contrario, tendrías que invertir en mantener tus recursos.

El VPA funciona en conjunto con la función de aprovisionamiento automático de nodos que se describe en la siguiente sección.

Debido a las limitaciones de Kubernetes, las solicitudes de recursos de un Pod se pueden cambiar solo cuando se reinicia un Pod. Por lo tanto, para hacer cambios, el VPA expulsa el Pod. Para obtener más información, consulta la documentación de GKE y Kubernetes.

Aprovisionamiento automático de nodos

El aprovisionamiento automático de nodos permite que el escalador automático de clústeres de GKE aprovisione de manera automática los grupos de nodos adicionales cuando el escalador automático determina que son obligatorios. El escalador automático del clúster también puede borrar grupos de nodos aprovisionados de forma automática cuando no hay nodos en esos grupos.

El escalador automático de clústeres de GKE toma decisiones de aprovisionamiento automático de nodos en función de varios factores. Esto incluye la cantidad de recursos solicitados por los Pods, las afinidades de los Pods que especificaste y las tolerancias y los taints de nodo definidos en el clúster de GKE.

El aprovisionamiento automático de nodos es útil si tienes una variedad de cargas de trabajo que se ejecutan en tus clústeres de GKE. Por ejemplo, si tu clúster de GKE tiene una carga de trabajo dependiente de la GPU, puedes ejecutarla en un grupo de nodos dedicado que se aprovisiona con nodos compatibles con la GPU. Puedes definir los límites de escalamiento del grupo de nodos si especificas un tamaño mínimo y máximo del grupo de nodos.

Para obtener más información sobre el aprovisionamiento automático de nodos y cuándo habilitarlo, consulta Usa el aprovisionamiento automático de nodos.

¿Qué sigue?

  • Obtén información sobre las prácticas recomendadas para compilar y operar contenedores.
  • Obtén información sobre cómo autenticar usuarios finales en Cloud Run en GKE mediante Istio en este instructivo.
  • Explora arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.