Prácticas recomendadas para las herramientas de redes de GKE

En este documento, se describen las prácticas recomendadas para configurar las opciones de herramientas de redes de los clústeres de Google Kubernetes Engine (GKE). Está diseñado como una guía de planificación de la arquitectura para ingenieros de redes y arquitectos de nube con recomendaciones que se pueden aplicar a la mayoría de los clústeres de GKE. Antes de crear clústeres, te recomendamos que revises todas las secciones para obtener información sobre las opciones y las implicaciones de las herramientas de redes. El objetivo de este documento no es presentar los conceptos o la terminología de las herramientas de redes de Kubernetes. Además, suponemos que ya tienes conocimientos sobre las herramientas de redes de Kubernetes. Para obtener más información, consulta la Descripción general de la red de GKE.

Mientras revisas este documento, considera el nivel de exposición de tu clúster y tipo de clúster, cómo planeas exponer las cargas de trabajo internamente a tu red de nube privada virtual (VPC) o externamente a Internet, cómo planeas escalar tus cargas de trabajo y qué tipos de servicios de Google se consumirán.

Diseño de VPC

Cuando diseñes tus redes de VPC, sigue las prácticas recomendadas para el diseño de VPC. En la siguiente sección, se proporcionan algunas recomendaciones específicas de GKE para el diseño de red de VPC.

Usa clústeres nativos de la VPC

Antes de crear un clúster, debes elegir un clúster basado en rutas o clúster nativo de la VPC. Recomendamos elegir un clúster nativo de la VPC porque usa rangos de direcciones IP de alias en los nodos de GKE y escala con mayor facilidad que los clústeres basados en rutas. Los clústeres nativos de la VPC son necesarios para los clústeres de GKE privados y a fin de crear en las VPC compartidas. En el caso de los clústeres creados en modo Autopilot, el modo nativo de la VPC siempre está activado y no se puede desactivar.

Los clústeres nativos de la VPC escalan con mayor facilidad que los clústeres basados en rutas sin consumir rutas de Google Cloud y, por lo tanto, son menos susceptibles de los límites de enrutamiento. Las ventajas de usar clústeres nativos de la VPC van de la mano con la compatibilidad de alias de IP. Por ejemplo, los grupos de extremos de red (NEG) solo se pueden usar con direcciones IP secundarias, por lo que solo se admiten en clústeres nativos de la VPC.

Usa redes de VPC compartidas

Los clústeres de GKE requieren una planificación cuidadosa de direcciones IP. La mayoría de las organizaciones suelen tener una estructura de administración centralizada con un administrador de red que puede asignar espacio de direcciones IP para los clústeres y un administrador de plataformas a fin de operar los clústeres. Este tipo de estructura de organización funciona bien con la arquitectura de red de VPC compartida de Google Cloud. En la arquitectura de la red de VPC compartida, un administrador de red puede crear subredes y compartirlas con principales en particular. Luego, puedes crear clústeres de GKE en proyectos de servicio de esas subredes.

En general, una red de VPC compartida es una arquitectura de uso frecuente que es adecuada para la mayoría de las organizaciones con un equipo de administración centralizada. Recomendamos usar redes de VPC compartida a fin de crear las subredes para los clústeres de GKE y evitar conflictos de direcciones IP en la organización.

Estrategias de administración de direcciones IP

Los clústeres de Kubernetes requieren una dirección IP única para cada Pod. En GKE, todas estas direcciones se pueden enrutar en toda la red de VPC. Por lo tanto, la planificación de direcciones IP es necesaria porque las direcciones no pueden superponerse con el espacio de direcciones IP privadas que se usa de forma local o en otros entornos conectados. En las siguientes secciones, se sugieren estrategias para la administración de direcciones IP con GKE.

Planifica la asignación de la dirección IP requerida

Se recomiendan los clústeres privados y se analizan con más detalle en la sección Seguridad de red. En el contexto de clústeres privados, solo se admiten clústeres nativos de la VPC y se requieren que se definan los siguientes rangos de IP:

  • Rango de direcciones IP del plano de control: una subred de RFC 1918/28 que no debe sobrepasar cualquier otro enrutamiento entre dominios sin clases (CIDR) en la red de VPC
  • Subred del nodo: la subred con el rango de IP principal que deseas asignar a todos los nodos del clúster. Los servicios con el tipo LoadBalancer que usan la anotación cloud.google.com/load-balancer-type: "Internal" también usan esta subred.
  • Rango de direcciones IP del Pod: El rango de IP que asignas a todos los Pods del clúster, también conocido como CIDR del clúster.
  • Rango de direcciones IP de servicio: El rango de direcciones IP que asignas a todos los servicios en el clúster, también conocido como CIDR de servicios.

El rango de direcciones IP del plano de control está destinado al plano de control administrado por GKE que reside en un proyecto de usuario administrado por Google que intercambia tráfico con tu VPC. Este rango de direcciones IP no debe superponerse con ninguna dirección IP en el grupo de intercambio de tráfico de VPC.

Cuando creas un clúster, la subred tiene un rango principal para los nodos del clúster y debe existir antes de que se cree. La subred debe admitir la cantidad máxima de nodos que esperas en el clúster. Puedes usar el escalador automático del clúster para limitar la cantidad máxima de nodos.

Los rangos de direcciones IP de Pods y servicios se representan como rangos secundarios distintos de tu subred y se implementan como direcciones IP de alias en clústeres nativos de la VPC.

Elige rangos de direcciones lo suficientemente amplios a fin de que se adapten a todos los nodos, Pods y servicios del clúster.

Usa un espacio que no sea RFC 1918 si es necesario

Para algunos entornos, es posible que el espacio RFC 1918 en grandes bloques de CIDR contiguos ya esté asignado en una organización. Puedes usar un espacio que no sea RFC 1918 para CIDR adicionales en clústeres de GKE, si no se superponen a las direcciones IP públicas de Google. Recomendamos usar parte del espacio de direcciones RFC 6598 (100.64.0.0/10) porque el espacio de direcciones de Clase E puede presentar problemas de interoperabilidad con el hardware local. Además, cuando uses IP públicas reutilizadas de forma privada, úsalas con precaución y considera controlar los anuncios de ruta en las redes locales a Internet cuando elijas esta opción.

Evita el uso de SNAT en el Pod del clúster al Pod y del Pod al tráfico de servicios. Cuando se usan IP públicas reutilizadas de forma privada con clústeres privados, el comportamiento predeterminado adopta SNAT para todo el espacio de direcciones que no sea RFC 1918. Para solucionar este problema, configura el agente de enmascaramiento de IP de forma correcta. Tus nonMasqueradeCIDRs deben contener al menos el CIDR del clúster y el CIDR de los servicios.

Usa el modo de subred personalizado

Cuando configuras la red, también debes seleccionar el modo de subred: auto (predeterminado) o custom (recomendado). El modo auto deja la asignación de subred a Google y es una buena opción para comenzar sin planificar la dirección IP. Sin embargo, te recomendamos seleccionar el modo custom porque este modo te permite elegir rangos de direcciones IP que no se superpongan con otros rangos en tu entorno. Si usas una VPC compartida, un administrador de la organización o administrador de la red puede seleccionar este modo.

En el siguiente ejemplo, se crea una red llamada my-net-1 con modo de subred personalizado:

gcloud compute networks create my-net-1 --subnet-mode custom

Planifica la densidad del pod por nodo

De forma predeterminada, los clústeres estándar reservan un rango /24 para cada nodo fuera del espacio de direcciones de pod en la subred y admiten hasta 110 pods por nodo. Según el tamaño de tus nodos y el perfil de aplicación de tus Pods, puedes ejecutar una cantidad considerablemente menor de Pods en cada nodo.

Si no esperas ejecutar más de 64 pods por nodo, te recomendamos ajustar el máximo de pods por nodo para conservar el espacio de direcciones IP en la subred de tu pod.

Para los clústeres de Autopilot, la cantidad máxima de pods por nodo se establece en 32 y conserva un rango de /26 para cada nodo. Esta configuración no es configurable en clústeres de Autopilot.

Evita las superposiciones con direcciones IP que se usan en otros entornos

Puedes conectar tu red de VPC a un entorno local o a otros proveedores de servicios en la nube a través de Cloud VPN o Cloud Interconnect. Estos entornos pueden compartir rutas, lo que hace que el esquema de administración de direcciones IP locales sea importante en la planificación de direcciones IP para GKE. Te recomendamos asegurarte de que las direcciones IP no se superpongan con las direcciones IP usadas en otros entornos.

Crea una subred de balanceador de cargas

Crea una subred del balanceador de cargas independiente para exponer servicios con el balanceo de cargas TCP/UDP interno. Si no se usa una subred de balanceador de cargas independiente, estos servicios se exponen mediante una dirección IP de la subred de nodo, lo que puede provocar el uso de todo el espacio asignado en esa subred antes de lo esperado y pueden impedir que escales el clúster de GKE hasta la cantidad esperada de nodos.

El uso de una subred de balanceador de cargas por separado también significa que puedes filtrar el tráfico desde y hacia los nodos de GKE por separado en servicios expuestos por el balanceo de cargas TCP/UDP interno, lo que te permite establecer límites de seguridad más estrictos.

Reserva espacio de direcciones IP suficiente para el escalador automático del clúster

Puedes usar el escalador automático del clúster para iniciar y reducir los nodos del clúster de forma dinámica a fin de controlar los costos y mejorar la utilización. Sin embargo, cuando uses el escalador automático del clúster, asegúrate de que tu planificación de direcciones IP tenga en cuenta el tamaño máximo de todos los grupos de nodos. Cada nodo nuevo requiere su propia dirección IP de nodo y su propio conjunto asignable de direcciones IP de Pod según los Pods configurados por nodo. La cantidad de Pods por nodo se puede configurar de manera diferente a la que se configura a nivel de clúster. No puedes cambiar la cantidad de Pods por nodo después de crear el clúster o grupo de nodos. Debes considerar los tipos de cargas de trabajo y asignarlos a distintos grupos de nodos para lograr una asignación óptima de las direcciones IP.

Opciones de seguridad de red

En esta sección, se describen algunas recomendaciones clave para el aislamiento del clúster. La seguridad de la red para los clústeres de GKE es una responsabilidad compartida entre Google y los administradores de los clústeres.

Elige un tipo de clúster privado

Existen dos tipos de aislamiento de red para los clústeres: públicos y privados. Los clústeres públicos tienen direcciones IP privadas y públicas en los nodos y solo un extremo público para los nodos del plano de control. Los clústeres privados proporcionan más aislamiento porque solo tienen direcciones IP privadas en los nodos y tienen extremos privados y públicos para los nodos del plano de control (que se pueden aislar aún más y se analizan en la sección Minimiza la exposición del plano de control del clúster). En los clústeres privados, aún puedes acceder a las API de Google con el Acceso privado a Google. Recomendamos elegir clústeres privados para el aislamiento de red.

En un clúster privado, los Pods se aíslan de la comunicación entrante y saliente (el perímetro del clúster). Puedes controlar estos flujos direccionales mediante la exposición de servicios mediante el balanceo de cargas y Cloud NAT, que se analiza en la sección Conectividad del clúster de este documento. En el siguiente diagrama, se muestra este tipo de configuración:

Comunicación de clúster privado
Diagrama 1: Comunicación de clúster privado

En este diagrama, se muestra cómo puede comunicarse un clúster privado. Los clientes locales pueden conectarse al clúster con el cliente kubectl. El acceso a los servicios de Google se proporciona a través del acceso privado a Google, y la comunicación a Internet solo está disponible mediante Cloud NAT.

Para obtener más información, revisa los requisitos, restricciones y limitaciones de los clústeres privados.

Minimiza la exposición del plano de control del clúster

En un clúster privado, el servidor de la API de GKE se puede exponer como un extremo público o privado. Puedes decidir qué extremo usar cuando creas el clúster. Puedes controlar el acceso con redes autorizadas, en las que los extremos público y privado permiten de forma predeterminada toda la comunicación entre el Pod y las direcciones IP del nodo en el clúster. Para habilitar un extremo privado cuando creas un clúster, usa la marca --enable-private-endpoint.

Autoriza acceso al plano de control

Las redes autorizadas pueden ayudar a determinar qué subredes de dirección IP pueden acceder a los nodos del plano de control de GKE. Después de habilitar estas redes, puedes restringir el acceso a rangos de direcciones IP de origen específicos. Si el extremo público está inhabilitado, estos rangos de direcciones IP de origen deben ser privados. Si un extremo público está habilitado, puedes permitir rangos de direcciones IP públicas o privadas. Configura los anuncios de ruta personalizados para permitir que se pueda acceder al extremo privado del plano de control del clúster desde un entorno local. Puedes hacer que el extremo de la API de GKE privada sea accesible de forma global mediante la opción --enable-master-global-access cuando creas un clúster.

En el siguiente diagrama, se muestra la conectividad típica del plano de control mediante redes autorizadas:

Conectividad del plano de control mediante redes autorizadas
Diagrama 2: Conectividad del plano de control mediante redes autorizadas

En este diagrama, se muestra que los usuarios de confianza pueden comunicarse con el plano de control de GKE a través del extremo público, ya que son parte de redes autorizadas, mientras que el acceso de actores no confiables está bloqueado. La comunicación hacia el clúster de GKE y desde este se realiza a través del extremo privado del plano de control.

Permite la conectividad del plano de control

Ciertos Pods del sistema en cada nodo trabajador deberán llegar a servicios como el servidor de la API de Kubernetes (kube-apiserver), las API de Google o el servidor de metadatos. kube-apiserver también necesita comunicarse con algunos Pods del sistema, como event-exporter. De forma predeterminada, esta comunicación está habilitada. Si implementas reglas de firewall de VPC dentro de los proyectos (obtén más detalles en la sección Restringe el tráfico del clúster), asegúrate de que los Pods también se sigan comunicando a kube-apiserver y a las API de Google.

Implementa proxies para el acceso al plano de control desde redes con intercambio de tráfico

El acceso al plano de control de los clústeres de GKE privados se realiza mediante el Intercambio de tráfico entre redes de VPC. El intercambio de tráfico entre redes de VPC no es transitivo, por lo que no puedes acceder al plano de control del clúster desde otra red con intercambio de tráfico.

Si deseas acceso directo desde otra red de intercambio de tráfico o desde una ubicación local cuando usas una arquitectura de concentrador y radio, implementa proxies para el tráfico del plano de control. Si quieres obtener más información, consulta Crea clústeres privados de Kubernetes con proxies de red para acceder al plano de control.

Restringe el tráfico del clúster mediante políticas de red

Se pueden combinar varios niveles de seguridad de red para las cargas de trabajo de clúster que se pueden combinar: reglas de firewall de VPC, políticas jerárquicas de firewall y políticas de red de GKE. Las reglas de firewall de VPC y las políticas jerárquicas de firewall se aplican a nivel de máquina virtual (VM), que son los nodos trabajadores en los que residen los Pods del clúster de GKE. Las políticas de red de GKE se aplican a nivel de Pod para aplicar las rutas de tráfico de Pods. Para obtener más información, consulta el plano de seguridad de Anthos: restricción del tráfico.

Si implementas firewalls de VPC, puede interrumpir la comunicación predeterminada del plano de control requerida, por ejemplo, la comunicación kubelet con el plano de control. GKE crea las reglas de firewall necesarias de forma predeterminada, pero se pueden reemplazar. Algunas implementaciones pueden requerir que el plano de control llegue al clúster en el servicio. Puedes usar firewalls de VPC para configurar una política de entrada que haga que el servicio sea accesible.

Las políticas de red de GKE se configuran a través de la API de políticas de red de Kubernetes para aplicar la comunicación del Pod y del servicio de un clúster. Puedes habilitar las políticas de red cuando creas un clúster mediante gcloud container clusters create con la opción --enable-network-policy. Para restringir el tráfico mediante políticas de red, puedes seguir la guía de implementación de la restricción de planos de tráfico de Anthos.

GKE Dataplane V2 se basa en eBPF y proporciona una experiencia integrada de seguridad y visibilidad de red. Cuando creas un clúster con GKE Dataplane V2, no necesitas habilitar de forma explícita las políticas de red porque GKE Dataplane V2 administra el enrutamiento, la aplicación y el registro de las políticas de red. Habilita el plano de datos nuevo con la opción --enable-dataplane-v2 de gcloud cuando crees un clúster. Después de configurar las políticas de red, se puede configurar un objeto CRD de NetworkLogging predeterminado para registrar conexiones de red permitidas y rechazadas.

Habilita las políticas de seguridad de Google Cloud Armor para Ingress

Con las políticas de seguridad de Google Cloud Armor, puedes proteger las aplicaciones que usan el balanceo de cargas de HTTP(S) externo contra ataques de DSD y otros ataques basados en la Web mediante el bloqueo de ese tráfico en la red perimetral. En GKE, habilita las políticas de seguridad de Google Cloud Armor para las aplicaciones mediante Ingress para balanceo de cargas HTTP(S) externo y agrega una política de seguridad al BackendConfig que se adjunta al objeto Ingress.

Usa Identity-Aware Proxy para proporcionar autenticación a las aplicaciones con usuarios de IAM

Si deseas implementar servicios a los que solo puedan acceder los usuarios dentro de la organización, pero sin necesidad de estar en la red corporativa, puedes usar Identity-Aware Proxy a fin de crear una capa de autenticación para estas aplicaciones. Si deseas habilitar Identity-Aware Proxy para GKE, sigue los pasos de configuración a fin de agregar Identity-Aware Proxy como parte de BackendConfig para el Ingress de tu servicio. Identity-Aware Proxy se puede combinar con Google Cloud Armor.

Usa restricciones de las políticas de la organización para mejorar aún más la seguridad

Con las restricciones de políticas de la organización, puedes establecer políticas para mejorar aún más tu posición de seguridad. Por ejemplo, puedes usar restricciones para restringir la creación de balanceadores de cargas a ciertos tipos, como solo balanceadores de cargas internos o restringir el uso de direcciones IP externas.

Escala la conectividad del clúster

En esta sección, se describen las opciones escalables para la conectividad de salida y DNS de tus clústeres hacia Internet y los servicios de Google.

Habilita NodeLocal DNSCache

GKE usa kube-dns para proporcionar el servicio DNS local del clúster como un complemento de clúster predeterminado. kube-dns se replica en todo el clúster como una función de la cantidad total de núcleos y nodos en el clúster.

Puedes mejorar el rendimiento de DNS con NodeLocal DNSCache. NodeLocal DNSCache es un complemento que se implementa como un DaemonSet y no requiere ningún cambio de configuración de Pod. Las búsquedas de DNS para el servicio de Pod local no crean conexiones abiertas a las que se deba realizar un seguimiento en el nodo, lo que permite una mayor escala. Las búsquedas de nombres de host externos se reenvían a Cloud DNS, mientras que todas las demás consultas de DNS se dirigen a kube-dns.

Habilita NodeLocal DNSCache para obtener tiempos de consulta de DNS más coherentes y una escala de clúster mejorada. En el caso de los clústeres de Autopilot, NodeLocal DNSCache está habilitado de forma predeterminada y no se puede anular.

La siguiente opción de herramienta de línea de comandos de gcloud habilita NodeLocal DNSCache cuando creas un clúster: --addons NodeLocalDNS.

Si tienes control sobre el nombre que las aplicaciones buscan resolver, hay maneras de mejorar el escalamiento de DNS. Por ejemplo, usa un FQDN (finaliza el nombre de host con un punto) o inhabilita la expansión de la ruta de búsqueda a través de la opción de manifiesto Pod.dnsConfig.

Usa Cloud NAT para acceder a Internet desde clústeres privados

De forma predeterminada, los clústeres privados no tienen acceso a Internet. Para permitir que los Pods lleguen a Internet, habilita Cloud NAT en cada región. Como mínimo, habilita Cloud NAT para los rangos primarios y secundarios en la subred de GKE. Asegúrate de asignar direcciones IP suficientes para Cloud NAT y puertos por VM.

Debes evitar la SNAT doble para el tráfico de Pods (primero SNAT en el nodo de GKE y, luego, con Cloud NAT). A menos que necesites SNAT a fin de ocultar las IP del Pod hacia redes locales conectadas por Cloud VPN o Cloud Interconnect, disable-default-snat y descarga el seguimiento de SNAT a Cloud NAT para la escalabilidad. Esta solución funciona para todos los rangos de IP de subred principales y secundarios. Usa políticas de red para restringir el tráfico externo después de habilitar Cloud NAT. No es necesario que este servicio acceda a los servicios de Google.

Usa el Acceso privado a Google para acceder a los servicios de Google

En los clústeres privados, los pods no tienen direcciones IP públicas para comunicarse con servicios públicos, incluidos los servicios y las API de Google. El Acceso privado a Google permite que los recursos privados de Google Cloud lleguen a los servicios de Google. Los servicios típicos de Google compatibles con el Acceso privado a Google incluyen BigQuery, autorización binaria, Container Registry y mucho más.

Esta opción está desactivada de forma predeterminada y debe habilitarse en la subred asociada con el clúster durante la creación de la subred.

La opción de la herramienta de línea de comandos de gcloud --enable-private-ip-google-access habilita el Acceso privado a Google cuando creas la subred.

Entrega aplicaciones

Cuando crees aplicaciones a las que se pueda acceder de forma externa o interna para tu organización, asegúrate de usar el tipo de balanceador de cargas y las opciones correctos. En esta sección, se brindan algunas recomendaciones sobre cómo exponer y escalar aplicaciones con Cloud Load Balancing.

Usa el balanceo de cargas nativo del contenedor

Usa el balanceo de cargas nativo del contenedor cuando expongas servicios mediante HTTP(S) de forma externa. El balanceo de cargas nativo del contenedor permite menos saltos de red, menor latencia y distribución de tráfico más exacta. También aumenta la visibilidad en el tiempo de ida y vuelta y te permite usar funciones de balanceo de cargas, como Cloud CDN y Google Cloud Armor.

Elige el recurso de GKE correcto para exponer tu aplicación

Según el alcance de tus clientes (internos, externos o incluso internos del clúster), la regionalidad de tu aplicación y los protocolos que uses, existen diferentes recursos de GKE que puedes elegir usar para exponer tu aplicación. En la descripción general de Service Networking, se explican estas opciones y pueden ayudarte a elegir el mejor recurso para exponer cada parte de tu aplicación mediante las opciones de balanceo de cargas de Google Cloud.

Crea verificaciones de estado basadas en BackendConfig

Si usas un Ingress para exponer servicios, usa una configuración de verificación de estado en una CRD de BackendConfig a fin de usar la funcionalidad de verificación de estado del balanceo de cargas de HTTP(S). Puedes dirigir la verificación de estado al extremo adecuado y configurar tus propios umbrales. Sin una CRD de BackendConfig, las verificaciones de estado se infieren de los parámetros de prueba de disponibilidad o usan parámetros predeterminados.

Usa la política de tráfico local para conservar las direcciones IP originales

Cuando uses un balanceador de cargas de TCP/UDP interno con GKE, establece la opción externalTrafficPolicy en Local para conservar la dirección IP de fuente de las solicitudes. Usa esta opción si tu aplicación requiere la dirección IP fuente original. Sin embargo, la opción externalTrafficPolicy local puede generar una distribución de cargas menos óptima, por lo que solo debes usar esta función cuando sea necesario. Para los servicios HTTP(S), puedes usar los controladores de Ingress y obtener la dirección IP original si lees el encabezado X-Forwarded-For en la solicitud HTTP.

Operaciones y administración

Las siguientes secciones contienen prácticas recomendadas operativas que te ayudan a garantizar opciones de autorización detalladas para tus cargas de trabajo. Para evitar crear reglas de firewall manuales, sigue las prácticas recomendadas operativas en esta sección. También incluye recomendaciones para distribuir las cargas de trabajo y supervisar y registrar en GKE.

Usa Workload Identity para autenticar las cargas de trabajo en las API de Google

Usa Workload Identity para acceder a otros servicios de Google Cloud desde el clúster de GKE. Workload Identity te permite mantener el principio de privilegio mínimo, ya que puede vincular cuentas de servicio de Kubernetes a cuentas de servicio de Google. Las cuentas de servicio de Kubernetes se pueden asignar a los Pods, lo que te permite tener permisos detallados para acceder a las API de Google por carga de trabajo. Workload Identity está habilitada de forma predeterminada en los clústeres de Autopilot.

Usa permisos de IAM para GKE a fin de controlar las políticas en redes de VPC compartida

Cuando se usan redes de VPC compartidas, las reglas de firewall para los balanceadores de cargas se crean de forma automática en el proyecto host. Para evitar tener que crear manualmente reglas de firewall, otorga la función de administrador de seguridad de Compute a la cuenta de servicio de GKE en el proyecto host llamado service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com. Reemplaza HOST_PROJECT_NUMBER por el número del proyecto host para la VPC compartida.

Además, las reglas de firewall que crea GKE siempre tienen la prioridad predeterminada de 1,000, por lo que puedes evitar el flujo de tráfico específico mediante la creación de reglas de firewall en una prioridad más alta.

Si quieres restringir la creación de ciertos tipos de balanceadores de cargas, usa políticas de la organización para restringir su creación.

Usa clústeres regionales y distribuye tus cargas de trabajo para obtener una alta disponibilidad

Los clústeres regionales pueden aumentar la disponibilidad de las aplicaciones en un clúster porque el plano de control y los nodos del clúster se distribuyen en varias zonas.

Sin embargo, a fin de tener la mejor experiencia del usuario posible en caso de una falla de zona, usa el escalador automático del clúster para asegurarte de que tu clúster pueda manejar la carga requerida en cualquier momento. Además, usa la antiafinidad del Pod para garantizar que los Pods de un servicio determinado se programen en varias zonas. Si deseas obtener más información a fin de establecer esta configuración para las optimizaciones de alta disponibilidad y costo, consulta las Prácticas recomendadas para clústeres de GKE con alta disponibilidad.

Usa las operaciones de Cloud para el registro de políticas de red y GKE

Si bien cada organización tiene requisitos diferentes para la visibilidad y la auditoría, recomendamos habilitar el registro de políticas de red (beta). Esta función solo está disponible en GKE Dataplane v2 (también beta). El registro de políticas de red proporciona visibilidad de la aplicación de las políticas y los patrones de tráfico de Pods. Ten en cuenta que hay costos relacionados con el registro de políticas de red.

En los clústeres de GKE que usan la versión 1.14 o versiones posteriores, las operaciones en la nube para GKE habilitan la supervisión y el registro de forma predeterminada, y proporcionan un panel para los clústeres de GKE. También habilita las anotaciones de GKE para los registros de flujo de VPC. De forma predeterminada, las operaciones en la nube para GKE recopilan registros de todas las cargas de trabajo implementadas en el clúster, pero también existe una opción de registros solo del sistema. Usa el panel de operaciones en la nube para GKE a fin de observar y configurar alertas. Ten en cuenta que hay costos involucrados en Google Cloud's operations suite. En el caso de los clústeres creados en modo Autopilot, las operaciones en la nube para GKE están habilitadas de forma automática y no se pueden configurar.

Resumen de la lista de tareas

En la siguiente tabla, se resumen las prácticas recomendadas para configurar las opciones de herramientas de redes de los clústeres de GKE.

Área Práctica
Diseño de VPC
Estrategias de administración de direcciones IP
Seguridad
Escalamiento
Entrega aplicaciones
Operaciones y administración

¿Qué sigue?