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

En este documento, se describe cómo incorporar tus cargas de trabajo alojadas en contenedores de forma 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.

Arquitectura de muestra

En el siguiente diagrama, se muestra un ejemplo de una estructura flexible y con alta disponibilidad para implementar un clúster de GKE.

Estructura de proyectos, redes y clústeres

Proyectos

Google Cloud crea todos sus recursos dentro de una entidad de proyecto.

Puedes usar los proyectos para representar tus diversos entornos operativos. Por ejemplo, puedes tener proyectos de production y staging para equipos de operaciones y un proyecto de development para desarrolladores. 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. Luego, puedes aplicar políticas más permisivas y flexibles para los desarrolladores en el entorno development a fin de experimentar.

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 único 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 zonales y regionales

Puedes crear clústeres estándar y de Autopilot. Los clústeres de Autopilot son clústeres regionales. Los clústeres estándar son clústeres regionales o zonales. Los clústeres zonales pueden ser de una única zona o múltiples. Los clústeres multizonales y regionales distribuyen recursos en varias zonas dentro de una región, lo que puede mejorar la disponibilidad y resiliencia de tus clústeres.

Los clústeres zonales tienen las siguientes propiedades:

  • Crea una sola réplica del plano de control que se ejecute en una sola zona.
  • Si son multizonales, ejecuta nodos en varias zonas.

Los clústeres regionales tienen las siguientes propiedades:

  • Replicar los planos de control en tres zonas
  • Puede ejecutar nodos en varias zonas o en una sola zona según las ubicaciones de los nodos configuradas.

Puedes optar por crear clústeres zonales o regionales en el momento de la creación del clúster. Puedes agregar zonas nuevas a un clúster existente para que sea zonal. Sin embargo, no puedes cambiar un clúster zonal existente a fin de que sea regional y tampoco puedes cambiar un clúster regional para que sea zonal.

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.

Para obtener más información sobre los clústeres zonales y regionales, consulta la documentación de GKE.

Administra la identidad y el acceso

Funciones y grupos de administración de identidades y accesos (IAM)

Además de otorgar funciones de IAM 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 cuatro grupos de usuarios dentro de la organización con niveles diferentes de permisos, otorgados mediante las funciones de IAM en los dos proyectos:

Equipo Función de IAM Proyecto Permisos
Desarrolladores roles/container.developer dev Pueden crear recursos de Kubernetes para los clústeres existentes en el proyecto; no está permitido crear o borrar clústeres.
Operations roles/container.admin prod Tienen acceso total de administrador a los clústeres y recursos de Kubernetes que se ejecutan en el proyecto.
Seguridad roles/container.viewer
roles/compute.securityAdmin
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 roles/compute.networkAdmin prod Crea, modifica y borra recursos de red, excepto reglas de firewall y certificados SSL.

Además de los tres 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. Para obtener más información sobre el uso de espacios de nombres, consulta Prácticas recomendadas de Kubernetes: Especifica espacios de nombres en YAML.

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

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 RBAC 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 se almacenan en Cloud Storage.

En esta sección, se analizan las siguientes formas de compartir imágenes:

  • Haz públicas las imágenes.
  • Comparte imágenes entre proyectos.

Es importante usar Artifact Registry si habilitas clústeres privados. En los clústeres privados, el entorno de ejecución del contenedor de tu clúster no puede extraer imágenes de contenedor directamente desde un registro de contenedores externo, a menos que configures Cloud NAT. El entorno de ejecución del contenedor puede extraer imágenes de Artifact Registry en un clúster privado, sin Cloud NAT ni Acceso privado a Google. Debes colocar los nodos en una subred que tenga el Acceso privado a Google habilitado si los nodos deben comunicarse directamente con Artifact Registry (por ejemplo, los nodos deben crear artefactos nuevos y almacenarlos en Artifact Registry). Para obtener más información, consulta Extrae imágenes de contenedor desde un registro de imágenes.

Haz públicas las imágenes en Artifact Registry

Puedes hacer públicas las imágenes si haces públicos sus objetos y buckets en Artifact Registry. Para ver instrucciones más detalladas, consulta la documentación de control de acceso de Container Registry.

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).

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

Puedes compartir imágenes de contenedor entre proyectos si te aseguras de que los nodos de Kubernetes usan una cuenta de servicio. Puedes otorgar acceso a la cuenta de servicio como un storage.viewer en los proyectos en los que desees usar Artifact 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 cuando crees el clúster o el grupo de nodos mediante la marca --service- account.

Para obtener más información, consulta Configura el control de acceso.

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

La propiedad imagePullPolicy en Kubernetes determina si el kubelet intenta extraer una imagen mientras inicia un Pod. Establece una configuración 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, el 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 controladores de admisión dinámicos para aplicar las políticas

Los controladores de admisión dinámicos son parte del plano de control de Kubernetes. Pueden interceptar solicitudes entrantes realizadas al servidor de la API. Los controladores 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 controladores de admisión: de mutación y de validación.

Los controladores 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 controladores 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 controladores en el clúster, se los invoca después de que el servidor de API haya validado la solicitud. Los controladores de admisión de validación pueden rechazar las solicitudes para garantizar que se cumplan las políticas definidas en el controlador.

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

Usa apps ya preparadas desde Google Cloud Marketplace

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.

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, como 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 permite que una cuenta de servicio de Kubernetes en tu clúster de GKE actúe como una cuenta de servicio de IAM. Los pods que usan la cuenta de servicio de Kubernetes configurada se autentican de forma automática como la cuenta de servicio de IAM cuando accedes a las API 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.

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

Artifact Registry puede analizar imágenes en busca de vulnerabilidades de seguridad conocidas. Las imágenes admitidas incluyen Ubuntu, Debian, Red Hat y otras (consulta Fuentes de vulnerabilidades para ver la lista completa). Te recomendamos que analices las imágenes que planeas usar en tus clústeres de GKE.

Si es posible, habilita Container Analysis para reducir aún más los riesgos de seguridad.

Para ver las vulnerabilidades de una imagen, consulta Analiza imágenes automáticamente.

Tu organización puede beneficiarse de automatizar el seguimiento y la recepción de notificaciones cuando se realizan cambios en tu repositorio de Artifact 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 Artifact Registry. Luego, puedes usar estos eventos para activar compilaciones o implementaciones automatizadas. Para obtener más información, consulta la documentación de Artifact 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.

Si deseas obtener información para crear un grupo de nodos con GKE habilitado, consulta Endurece el aislamiento de las cargas de trabajo con GKE Sandbox.

Registros 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 los registros de auditoría de Cloud y 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.

Políticas de seguridad de Pods

Un vector de ataque común consiste en implementar Pods con privilegios derivados para obtener acceso a un clúster de Kubernetes. Gatekeeper es un controlador de admisión que usa políticas que describen lo que un Pod puede hacer. Puedes usarla a fin de restringir el acceso sobre cómo usar los espacios de nombres, cómo usar los tipos de volúmenes y a las capacidades subyacentes del SO.

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.

  • Un clúster que usa rangos de alias de IP para enrutar el tráfico. Esto se denomina clúster nativo de VPC.
  • Un clúster que usa rutas de Google Cloud 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.

Redes autorizadas para acceder al plano de control

La opción redes autorizadas restringe el acceso al extremo del plano de control (el 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.

Esta función tiene los siguientes requisitos:

  • Solo se permiten 50 rangos de CIDR.
  • Si usas una canalización de CI/CD para permitir que tus herramientas de CI/CD tengan acceso al servidor de API del clúster, debes agregar sus direcciones IP o rango de CIDR a la lista de entidades permitidas (consulta Descripción general de las reglas de firewall de VPC).

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 plano de control fuera de tu red de VPC, puedes usar clústeres privados con redes autorizadas. Cuando habilitas las redes autorizadas, el extremo del plano de control de tu 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 y que pertenezca a un rango CIDR o una dirección IP permitidos puede usar la dirección IP pública del plano de control. También puedes usar esta función en conjunto con Cloud Interconnect o Cloud VPN para habilitar el acceso al nodo del plano de control solo desde tu centro de datos privado.

Protección contra el robo de datos

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.

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 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.

Para obtener más información sobre kube-dns, consulta Descubrimiento de servicios y DNS.

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.

Servicios headless

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 algunos agentes de resolución de DNS del cliente almacenen las respuestas DNS en caché, lo que renderiza la rotación de los registros A de manera ineficiente. Las ventajas de usar ClusterIP se muestran en la documentación de Kubernetes. Si deseas obtener más información para usar ClusterIP en GKE, consulta Expón aplicaciones mediante objetos Service.

Un caso de uso típico de los servicios sin interfaz gráfica 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.

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 mejoran la seguridad de las cargas de trabajo que se ejecutan en tu 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.

También puedes usar políticas de red para aislar cargas de trabajo que pertenezcan a usuarios diferentes. Por ejemplo, puedes proporcionar un multiusuario seguro si defines un modelo en el que haya un usuario para cada 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.

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 tres opciones, como se describe en las siguientes secciones.

OpciónDescripción
Dominios de stubEn Kubernetes 1.6 y superiores, puedes configurar el servicio DNS interno del clúster (“kube-dns”) a fin de reenviar las consultas de DNS para 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 externoLos 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 selectoresPuedes 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. A fin de obtener más información, consulta Configura Ingress para el balanceo de cargas externo.

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 direcciones IP o listas de anunciantes permitidos de CIDR 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.

Si deseas obtener más información para configurar el recurso personalizado de BackendConfig en GKE, consulta Funciones de Ingress.

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.

Si deseas obtener información del uso de una malla de servicios con Anthos, consulta Acerca de Anthos Service Mesh.

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

Puedes usar Cloud Interconnect o Cloud VPN para conectarte 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: Las opciones son las siguientes:

  • Usa la interconexión dedicada para transferir grandes cantidades de datos entre redes, con baja latencia.

  • Usa la interconexión de socio si tu centro de datos no se encuentra en una instalación de colocación de interconexión dedicada. Google tiene más de 100 puntos de presencia (PoP) que se comunican con proveedores de servicios en todo el mundo.

  • Usa 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 Google Workspace y las API de Google compatibles. 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.

  • Usa Intercambio de tráfico por proveedores si no tienes un ASN registrado o si tienes relaciones con un proveedor de servicios de tu preferencia. 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.

  • Usa Cloud VPN si se requiere encriptación IPSec o si deseas extender tu red privada a tu red privada de Compute Engine. Cloud VPN se configura a través de las opciones de interconexión y de Internet de capa 3 (1, 2 y 3).

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. Puedes elegir que tu plano de control o nodos se actualicen de forma automática o controlar las actualizaciones.

Puedes revisar las notificaciones de actualización en la consola, en los boletines de seguridad de Anthos y desde las notificaciones de actualización del clúster. Si actualizas los nodos de forma manual, te recomendamos que actives la actualización de la versión después de revisar el contenido de lanzamiento 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 plano de control de un clúster zonal se somete a una actualización, 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 plano de control, puedes hacer que el plano de control tenga alta disponibilidad mediante la implementación de clústeres de GKE regionales. Con este enfoque, puedes tener varios planos de control que se distribuyan en distintas zonas. Cuando se actualiza un plano de control, todas las solicitudes del plano de control al servidor de la API se enrutan a los otros planos de control.

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.

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.

El escalador automático del clúster reduce o aumenta la escala según las solicitudes de recursos. Si un nodo tiene poco uso y los pods en ejecución se pueden programar en otros nodos que tengan 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.

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.

Ajuste de escala automático horizontal de pod

Kubernetes te permite crear un escalador automático de Pod horizontal (HPA) que te permite configurar cómo se deben escalar los ReplicaSets o 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 del escalador automático horizontal de Pods basa las decisiones sobre el ajuste de escala automático en el uso de CPU. Sin embargo, el controlador del escalador automático horizontal de Pods 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 escalador automático horizontal de Pods 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

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 ajuste de escala automático vertical de Pods ajusta las asignaciones de recursos que se realizan en los contenedores de tu clúster. El ajuste de escala automático vertical de Pods 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 ajuste de escala automático vertical de Pods 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 realizar cambios, el ajuste de escala automático vertical de Pods expulsa el Pod. Para obtener más información, consulta la documentación de GKE y Kubernetes.

Autopilot

Autopilot significa que GKE aprovisiona y administra la infraestructura subyacente del clúster en tu nombre. Con Autopilot, se administran elementos como los siguientes:

  • Nodos y grupos de nodos

  • Aprovisionamiento de recursos

  • Tipos de imágenes de nodo

  • Funciones de Herramientas de redes, como tipos de clústeres y rangos de CIDR

  • Funciones de seguridad, como Workload Identity o VM protegida

Autopilot es útil si deseas reducir la carga operativa y no necesitas la capacidad de configurar elementos específicos para cargas de trabajo más complejas.

¿Qué sigue?

  • Obtén más información sobre las prácticas recomendadas para endurecer los clústeres.

  • 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.