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

En esta solución, se proporciona un modelo y una metodología para la integración de las cargas de trabajo de manera más segura, confiable y rentable a Google Kubernetes Engine. 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. A fin de ayudarte a decidir, considera las prácticas recomendadasen Elige el tamaño y el alcance de un clúster de GKE.

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 y el 99.95% para los 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 de instancia principal. Esta función bloquea el acceso al servidor de la API desde los rangos de CIDR que especificas y garantiza que solo los equipos de tu red puedan administrar tu clúster.

Cuando habilites esta función, ten en cuenta lo siguiente:

  • Solo se permiten 50 rangos de CIDR.
  • Si usas una canalización de CI/CD, debes asegurarte de que tus herramientas de CI/CD tengan acceso al servidor de la API del clúster. Para ello, permite (incluye en la lista blanca) su rango de CIDR o direcciones IP.

También puedes usar esta función junto 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 práctica recomendada es crear clústeres privados, que solo otorguen a todos los nodos trabajadores una dirección IP RFC 1918 privada. Los clústeres privados aplican el aislamiento de red, lo que reduce la superficie de exposición al riesgo de los 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 de instancia principal. Cuando habilitas redes autorizadas de instancia principal, el extremo de la instancia principal del clúster obtiene 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 o proveniente de una dirección IP o un rango de CIDR permitidos puede usar la dirección IP pública de la instancia principal. Los nodos privados no tienen direcciones IP externas y, de forma predeterminada, no tienen acceso de salida 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 de 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 con el Acceso privado a Google. Como alternativa, puedes usar Cloud NAT o implementar una puerta de enlace de 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 acceder a estos servicios. Puedes otorgar a las aplicaciones que se ejecutan en tus clústeres de GKE acceso a estos servicios administrados si configuras 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 a 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 para que los desarrolladores desarrollen y prueben sus próximas funciones y correcciones de 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 Puedes crear recursos de Kubernetes para los clústeres existentes en el proyecto, no está permitido crear o borrar clústeres.
Operaciones container.admin prod Acceso de administrador total a los clústeres y recursos de Kubernetes que se ejecutan en el proyecto.
Security container.viewer
security.admin
prod Crea, modifica y borra reglas de firewall y certificados SSL. También visualiza 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 a clústeres completos y a sus recursos, pero el Control de acceso según la función 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 gcloud, lo que permite a los administradores de clústeres asignar 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 RBAC de Kubernetes. Para usar esta función, debes configurar Grupos de Google de G Suite, crear un clúster con la función habilitada y usar RoleBindings para asociar tus Grupos con las funciones a las que deseas vincularlos. Para obtener más información, consulta Control de acceso según la función.

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

Autorización de RBAC

Como otro ejemplo, existen funciones de IAM a nivel de proyecto de Google Cloud que permiten a ciertos usuarios acceder 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 tus necesidades organizativas. La siguiente función de ejemplo permite a los usuarios 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 los 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 en todos los proyectos de 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 se encuentra en 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 comando:

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 correcta

La propiedad imagePullPolicy determina si Kubelet intentará extraer una imagen mientras inicia un pod. Debes considerar usar 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 recuperará una copia de la imagen solo si esta no está disponible en la caché del nodo.

Para obtener más información sobre las políticas de extracción de imágenes posibles que puedes especificar, consulta 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 API. Los webhooks de admisión son una herramienta potente que puede ayudarte a aplicar políticas personalizadas específicas de la empresa en tus clústeres de GKE.

Kubernetes admite dos tipos de webhooks de admisión: webhooks 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. Estos webhooks pueden rechazar las solicitudes para garantizar que cumplan con las políticas definidas en el webhook.

Por ejemplo, puedes aplicar una política de extracción de imágenes con 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

Se recomienda usar un registro de contenedores privado, como Container Registry, para almacenar el conjunto de imágenes seleccionado de tu organización. Esto ayuda a reducir el riesgo de ingresar vulnerabilidades en la canalización de implementación (y, finalmente, en las cargas de trabajo de la aplicación). Si es posible, también deberías habilitar el análisis de contenedores, 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 considerar la implementación de apps de Kubernetes ya empaquetadas desde Google Cloud Marketplace. Google prueba y verifica las apps de Kubernetes que se enumeran en Google Cloud Marketplace, incluido el análisis de vulnerabilidades y los acuerdos de socios, para realizar mantenimiento y brindar 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 que abarcan servicios en la nube: servicios administrados por la nube y servicios alojados. Es común que las aplicaciones o los servicios de GKE tengan que comunicarse con los servicios administrados de Google Cloud, como Cloud Storage y BigQuery. Por ejemplo, es posible que tengas que almacenar los registros de los clientes una vez que se procesen por trabajos por lotes en GKE 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 que es 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 envían a él y buscar vulnerabilidades de seguridad conocidas para imágenes basadas en Ubuntu, Alpine, Debian, CentOS y RedHat. 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 actualmente 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 alojadas en 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 para 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 crea una imagen nueva o se borra una. 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 publican 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 cuándo una imagen debe considerarse válida para la implementación en tu clúster. Para esta tarea, puedes usar la autorización binaria. Esta es una construcción en el momento de la implementación que te permite definir un flujo de trabajo que aplica las firmas (certificaciones) que una imagen debe tener para poder implementarla en tu clúster.

El flujo de trabajo se define en términos de políticas. A medida que mueves 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 para cada una de estas etapas, según se define en la política de autorización binaria. Estas certificaciones validan que una imagen haya pasado 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 la imagen que tiene todas las certificaciones necesarias. Los intentos de implementación fallidos se registran automáticamente y los administradores de clústeres pueden revisarlos y auditarlos.

Para obtener un instructivo sobre cómo implementar la autorización binaria para GKE con Cloud Build, consulta Implementa la autorización binaria con Cloud Build y GKE.

Acceso seguro con gVisor en GKE Sandbox

Un contenedor proporciona una capa de seguridad y aislamiento de kernel, pero aún puede ser vulnerable a los incumplimientos que permiten que los atacantes obtengan acceso al sistema operativo (SO) del host. Un enfoque más resiliente para el aislamiento de seguridad entre un contenedor y su SO de host es crear otra capa de separación. Un enfoque es usar GKE Sandbox.

GKE Sandbox usa gVisor, un entorno de ejecución de contenedores de código abierto creado por 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 del host. Además, aplica 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 generar memoria adicional y sobrecarga de CPU. Antes de usar GKE Sandbox, debes considerar qué cargas de trabajo necesitan este nivel elevado de seguridad. Por lo general, los buenos candidatos son servicios que se basan en imágenes externas.

El siguiente comando de gcloud 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 aplicaciones 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: Protege tus pods en profundidad 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.

Audit Logging

El registro de auditoría de Kubernetes registra todas las solicitudes a la API que se realizan al servidor de la API de Kubernetes. Este registro es útil para detectar anomalías y patrones inusuales de acceso y configuración. Estos son ejemplos de lo que deberías revisar e informar:

  • Eliminación de una implementación
  • Inclusión o uso 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 que accedes a los registros de los recursos que se ejecutan en tu proyecto de Cloud. Se pueden registrar las solicitudes a la API realizadas al servidor de la API de Kubernetes y puedes usarlas para revisar los patrones de actividad de la API.

Cada solicitud (evento) que captura el servidor de la API de Kubernetes se procesa mediante una o más políticas que definas. Estas 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 la habilitación del 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 elevados para obtener acceso a un clúster de Kubernetes. Las PodSecurityPolicies definen un conjunto de reglas en la especificación del pod que describen lo que puede hacer un pod. Implementas una PodSecurityPolicy en Kubernetes como un recurso de controlador de admisión. Puedes usarlo para restringir el acceso a los espacios de nombres, los tipos de volúmenes y las capacidades del SO subyacentes.

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 deseas agregar una PodSecurityPolicy.

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

En el siguiente ejemplo, se muestra una PodSecurityPollicy que restringe la capacidad de crear pods privilegiados.

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 de los servicios de Kubernetes es el contenedor. Esto hace que la seguridad del contenedor sea un factor clave cuando planeas la seguridad y las políticas del clúster. Analiza lo siguiente con cuidado:

  • Las imágenes a partir de las que compilas tus contenedores
  • Los privilegios que asignas a los contenedores
  • Cómo interactúan los contenedores con el SO host y otros servicios
  • Cómo los contenedores acceden a la información sensible y 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 proporciona una abstracción de servicio que incluye balanceo de cargas y descubrimiento de servicios en conjuntos de pods dentro de un clúster, así como en sistemas heredados que se ejecutan fuera del clúster. En las secciones siguientes, se describen las recomendaciones 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

En función de cómo los clústeres de GKE enrutan el tráfico de un pod a otro, los clústeres se pueden clasificar en dos tipos. En el primer tipo, se incluyen los clústeres que usan rangos de IP de alias para enrutar el tráfico; se conocen como clústeres nativos de la VPC. En el segundo, se incluyen los clústeres que usan rutas de Google Cloud; se denominan clústeres basados 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 para los pods en lugar de configurar y mantener las rutas estáticas para cada nodo en el clúster de GKE. Mediante los rangos de alias de IP, puedes configurar múltiples direcciones IP internas que representen contenedores o aplicaciones alojados en una VM, sin tener que definir una interfaz de red separada. Google Cloud instala de forma automática rutas de redes de VPC para los rangos de IP principales y de alias de la subred de la interfaz de red principal. Esto simplifica de manera significativa 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 ser 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 en Google Cloud.

Debes decidir qué tipo de clúster es más adecuado para tu topología de red. Los factores clave son la disponibilidad de las direcciones IP en tu red, los planes de expansión de clústeres (nodos) de tu empresa y la conectividad con 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 tenerlo 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 y un clúster basado en rutas a un clúster nativo de la VPC, por lo que es importante comprender las implicaciones de la opción que elijas antes de implementarla.

Comunicación dentro del mismo clúster

Descubrimiento de servicios

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 la detección de servicios en Kubernetes, ve a 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 el nodo cargarán paquetes de balanceo de cargas en los Pods que estén listos y que coincidan 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 es posible que la dirección IP del pod cambie, la entrada DNS de su nombre de host se mantendrá actualizada y se podrá 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 de IP del clúster.

Para obtener más información sobre cómo se implementa ClusterIP, consulta la documentación de Kubernetes. Para profundizar más en la red de GKE, mira la próxima charla de 2017 en YouTube:

Servicios headless

A continuación, se muestra un ejemplo de la respuesta DNS y el patrón de tráfico para un servicio headless. 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 política en GKE, puedes usar la comunicación de la política de la red de Kubernetes entre los pods y los servicios del clúster para definir una API de red con el fin de crear reglas de firewall a nivel de Pod. Estas reglas de firewall determinan los pods y los servicios que pueden acceder unos a otros dentro del clúster.

Las políticas de red son un tipo de defensa minuciosa 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 instancia múltiple segura si defines un modelo de instancia 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 el exterior del clúster, pero dentro del espacio de direcciones IP privadas 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 configura para distribuir el 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 que se describen a continuación.

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 autoritativos que deben consultarse para un dominio que los Pods de Kubernetes deberán aprovechar.

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. Debes usar esto si solo tienes unos cuantos 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 el mantenimiento a largo plazo.

Para obtener más información sobre DNS, ve a la página de documentación Pods y servicios DNS de Kubernetes.

Configura tus 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 recursos de Ingress de Kubernetes. Ingress proporciona un punto de entrada para tu clúster y te permite definir reglas de enrutamiento que enrutan las solicitudes entrantes a uno o más servicios de backend en tu clúster. En GKE, el controlador de Ingress de GKE implementa un recurso de 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 un 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 se especificó 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 la aplicación con Identity-Aware Proxy (IAP).
  • Configurar 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 los 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 la comunicación entre servicios, aplicar políticas de acceso y recopilar datos de datos de telemetría enriquecidos 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 debe enrutar y dividir el tráfico entre los servicios o entre diferentes versiones del mismo servicio. Esto facilita la implementación de implementaciones canary y azul-verde.

  • Observabilidad integrada. La malla registra las métricas de tráfico de red (capa 4 y 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. No solo proporciona canales seguros para los datos en tránsito, sino que también te ayuda a administrar la autenticación y la autorización de los servicios dentro de la malla.

En resumen, las mallas de servicio 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 automáticamente para ti. Puedes agregar tus propias etiquetas personalizadas durante la creación del grupo de nodos o el clúster con la marca --tags en la herramienta de gcloud command-line tool.

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

El ejemplo que se presenta a continuación muestra cómo etiquetar un clúster para 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 desde 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 privilegiadas, 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 que debes 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 de recursos total permitido 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 las etapas de desarrollo, puedes usar las cuotas para limitar una amplia gama de recursos, como el uso de CPU, la 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 automáticamente cuotas de recursos predeterminadas no anulables 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 de recursos mínimos y máximos 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 de pods

Los presupuestos de interrupción de pods (PDB) ayudan a protegerte contra la eliminación voluntaria o accidental de pods o implementaciones de tu equipo. Los PDB no pueden prevenir interrupciones involuntarias que pueden provocar que un nodo falle o se reinicie. Normalmente, un operador crea un PDB para una aplicación que define el número mínimo de réplicas de los pods que deben ejecutarse 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. Pero, 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 configurar un PDB.

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

Administra las actualizaciones de Kubernetes

Debes mantener 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 nuevas funciones que se lanzan y garantizar que el sistema operativo subyacente de los nodos de tu clúster esté habilitado y actualizado.

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

  • Actualizaciones de versiones principales y secundarias de Kubernetes del clúster de GKE para los nodos principales y trabajadores
  • Parches y actualizaciones de SO 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 en 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 haber revisado el contenido de la versión y, después 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 regionales de GKE en su lugar. Con este enfoque, puedes tener varios nodos principales distribuidos 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 a los nodos.

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. Para ello, habilita la actualización automática de nodos en los grupos de nodos de tu clúster de GKE.
  • Puedes actualizar tus nodos trabajadores de GKE de forma manual. Cuando hay una actualización disponible, la consola de GKE muestra una alerta. 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; se 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 característica de reparación automática de nodos de GKE administra las verificaciones de estado de tus nodos de GKE. Si se descubre que alguno de los nodos está en mal estado, GKE inicia el proceso de reparación de nodos.

El proceso de reparación de nodos administrado implica vaciar y volver a crear el nodo. Si es necesario reparar varios nodos en tu clúster de GKE al mismo tiempo, Google Cloud determina de manera 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 automáticamente. En los clústeres de GKE que creas con la herramienta de gcloud command-line tool, 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 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 variedad de carga entrante en las aplicaciones que se ejecutan en sus clústeres de Kubernetes. Para responder a estos cambios basados en la empresa, puedes habilitar tus clústeres de GKE para que respondan de forma automática y aumenten y reduzcan 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 de 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 de clúster está habilitado para grupos de nodos individuales. Para cada grupo de nodos, GKE verifica si hay pods que están por 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 la forma en que GKE decide reducir la escala. Si los pods que se ejecutan en un nodo usan menos del 50% y se pueden programar en otros nodos con capacidad, el nodo con poco uso se vacía y se finaliza.

Puedes establecer los límites para un grupo de nodos si especificas los nodos mínimos y máximos a los que 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 horizontal de pods (HPA) que te permite configurar cómo deben escalar tus implementaciones de Kubernetes o ReplicaSets y en qué métricas debe basarse la decisión de escalamiento. De forma predeterminada, el controlador de HPA toma las decisiones sobre el ajuste de escala automático en función del uso de CPU. Sin embargo, el controlador de HPA puede calcular cómo los pods deben escalarse en función de las métricas personalizadas, como el recuento de solicitudes HTTP. Para que un HPA responda a métricas personalizadas, por lo general, se requiere una 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 a 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 permite ahorrar tiempo administrativo que, de lo contrario, tendrías que invertir para 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 también puede borrar grupos de nodos aprovisionados automáticamente 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 nodos definidos en el clúster de GKE.

El aprovisionamiento automático de nodos es útil si tienes una variedad de cargas de trabajo en ejecución en tus clústeres de GKE. Por ejemplo, si tu clúster de GKE tiene una carga de trabajo que depende de GPU, puedes ejecutarlo en un grupo de nodos dedicado que se aprovisiona con nodos compatibles con GPU. Puedes definir los límites de escalamiento del grupo de nodos si especificas un tamaño mínimo y máximo de 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 con Istio en este instructivo.
  • Prueba otras características de Google Cloud. Consulta nuestros instructivos.