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 para configurar clústeres que se pueden aplicar a la mayoría de los clústeres de GKE. Antes de crear los clústeres de GKE, te recomendamos que revises todas las secciones de este documento para comprender las opciones de herramientas de redes que admite GKE y sus implicaciones.
Las opciones de herramientas de redes que elijas afectan la arquitectura de tus clústeres de GKE. Algunas de estas opciones no se pueden cambiar una vez configuradas sin volver a crear el clúster.
Antes de leer este documento, asegúrate de estar familiarizado con los conceptos y la terminología de las herramientas de redes de Kubernetes, algunos conceptos generales de las herramientas de redes y 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, ten en cuenta lo siguiente:
- Cómo planeas exponer las cargas de trabajo de forma interna a tu red de nube privada virtual (VPC), otras cargas de trabajo en el clúster, otros clústeres de GKE o de forma externa a Internet.
- Cómo planeas escalar tus cargas de trabajo.
- Qué tipos de servicios de Google deseas consumir.
Para obtener una lista resumida de todas las prácticas recomendadas, consulta la Lista de tareas resumida.
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
Te recomendamos usar clústeres nativos de la VPC. Los clústeres nativos de la VPC usan rangos de alias de direcciones IP en los nodos de GKE y son necesarios para los clústeres de GKE privados y para crear clústeres en VPC compartidas y ofrecen muchos otros beneficios. 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.
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 equipo de administración 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 VPC. Puedes crear clústeres de GKE en un proyecto de servicio y usar las subredes compartidas desde la VPC compartida en el proyecto host. El componente de la dirección IP permanece en el proyecto host y los demás componentes del clúster se encuentran en el proyecto de servicio.
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. También puedes usar las VPC compartidas para administrar las funciones operativas. Por ejemplo, puedes tener un equipo de red que trabaje solo en componentes y confiabilidad de red, y otro equipo que trabaje en GKE.
Estrategias de administración de direcciones IP
Todos los clústeres de Kubernetes, incluidos los clústeres de GKE, requieren una dirección IP única para cada Pod.
Para obtener más información, consulta el modelo de red de GKE.En GKE, todas estas direcciones IP 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 internas 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.
Recomendaciones:
Planifica la asignación de la dirección IP requeridaUsa un espacio que no sea RFC 1918 si es necesario.
Usa el modo de subred personalizado.
Planifica la densidad del Pod por nodo.
Evita las superposiciones con direcciones IP que se usan en otros entornos.
Crea una subred de balanceador de cargas.
Reserva espacio de direcciones IP suficiente para el escalador automático del clúster.
Comparte direcciones IP entre clústeres.
Comparte direcciones IP para Services LoadBalancer internos.
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 los siguientes rangos de direcciones IP:
- Rango de direcciones IP del plano de control: Usa una subred /28 dentro de los rangos privados de direcciones IP incluidos en RFC 1918. Debes asegurarte de que esta subred no se superponga con ningún otro enrutamiento entre dominios sin clases (CIDR) en la red de VPC.
- Subred del nodo: la subred con el rango principal de direcciones IP que deseas asignar a todos los nodos del clúster. Los servicios con el tipo
LoadBalancerque usan la anotacióncloud.google.com/load-balancer-type: "Internal"también usan esta subred de forma predeterminada. También puedes usar una subred dedicada para balanceadores de cargas internos. - Rango de direcciones IP del Pod: El rango de IP que asignas a todos los Pods del clúster. GKE aprovisiona este rango como un alias de la subred. Si deseas obtener más información, consulta Rangos de IP para clústeres nativos de la VPC
- Rango de direcciones IP de Services: el rango de direcciones IP que asignas a todos los Services en tu clúster. GKE aprovisiona este rango como un alias de la subred.
Para los clústeres privados, debes definir una subred de nodo, un rango de direcciones IP de Pod y un rango de direcciones IP de Services.
Si deseas usar el espacio de direcciones IP de manera más eficiente, consulta Reduce el uso de direcciones IP internas en GKE.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 porque GKE importa esta ruta a tu proyecto. Esto significa que, si tienes rutas al mismo CIDR, es posible que experimentes problemas de enrutamiento.
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, así como las direcciones IP del balanceador de cargas interno en el clúster que usa la subred.
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 IP lo suficientemente amplios a fin de que se adapten a todos los nodos, Pods y Services del clúster.
Ten en cuenta las siguientes limitaciones:
- Puedes expandir los rangos de direcciones IP principales, pero no puedes reducirlos. Estos rangos de direcciones IP deben ser contiguos.
- Puedes expandir el rango de Pod si agregas rangos de pods adicionales al clúster o creas grupos de nodos nuevos con otros rangos de pods secundarios.
- El rango de direcciones IP secundario para objetos Service no se puede expandir ni cambiar durante la vida útil del clúster.
- Revisa las limitaciones del rango de direcciones IP secundario para Pods y Services.
Usa más que las direcciones IP RFC 1918 privadas
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 la parte 100.64.0.0/10 del espacio de direcciones RFC porque el espacio de direcciones de clase E puede presentar problemas de interoperabilidad con el hardware local. Puedes usar IP públicas reutilizadas de forma privada (PUPI).
No debes usar la traducción de direcciones de red de origen (SNAT) en un clúster con tráfico de Pod a Pod y de Pod a Service. Esto interrumpe el modelo de red de Kubernetes.
Kubernetes supone que todas las direcciones IP que no son RFC 1918 son direcciones IP públicas reutilizadas de forma privada y usa SNAT para todo el tráfico que se origina en estas direcciones.
Si usas una dirección IP que no es RFC 1918 para tu clúster de GKE, en el caso de los clústeres estándar, deberás inhabilitar SNAT de forma explícita o configurar el agente de enmascaramiento de IP para excluir las direcciones IP del Pod de tu clúster y los rangos de direcciones IP secundarios para los objetos Service de SNAT. En el caso de los clústeres de Autopilot, esto no requiere ningún paso adicional.
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 Pods en la subred y admiten hasta 110 Pods por nodo. Sin embargo, puedes configurar un clúster estándar para admitir hasta 256 Pods por nodo, con un rango /23 reservado para cada 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.
Si esperas ejecutar más de los 110 Pods predeterminados por nodo, puedes aumentar el máximo de pods por nodo a 256, con /23 reservado para cada nodo. Con este tipo de configuración de densidad de pod alta, recomendamos usar instancias con 16 núcleos de CPU o más para garantizar la escalabilidad y el rendimiento del clúster.
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 agregar y quitar nodos de forma dinámica en el clúster para 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.
Considera usar el aprovisionamiento automático de nodos, con el escalador automático del clúster, en especial si usas clústeres nativos de la VPC. Para obtener más información, consulta Rangos de límite de nodos.
Comparte direcciones IP en clústeres
Es posible que debas compartir direcciones IP entre los clústeres si tienes un equipo centralizado que administra la infraestructura para los clústeres. Para compartir direcciones IP entre clústeres de GKE, consulta Comparte rangos de direcciones IP entre clústeres de GKE. Puedes reducir la sobrecarga si creas tres rangos para Pods, Services y nodos, y los vuelves a usar o los compartes, en especial en un modelo de VPC compartida. Esta configuración también puede facilitar la administración de direcciones IP que realizan los administradores de red, ya que no es necesario que creen subredes específicas para cada clúster.
Ten en cuenta lo siguiente:
- Como práctica recomendada, usa subredes y rangos de direcciones IP independientes para todos los clústeres.
- Puedes compartir el rango de direcciones IP del Pod secundario, pero no se recomienda, ya que un clúster puede usar todas las direcciones IP.
- Puedes compartir rangos secundarios de direcciones IP de Services, pero esta característica no funciona con Cloud DNS con permiso de VPC para GKE.
Si te quedas sin direcciones IP de Pods, puedes crear rangos de direcciones IP de Pods adicionales mediante el CIDR de varios Pods no contiguos.
Comparte direcciones IP para Services LoadBalancer internos
Puedes compartir una sola dirección IP con hasta 50 backends mediante diferentes puertos. Esto te permite reducir la cantidad de direcciones IP que necesitas para los objetos Service LoadBalancer internos.
Para obtener más información, consulta IP compartida.
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.
Recomendaciones:
Usa GKE Dataplane V2.Elige un tipo de clúster privado
Minimiza la exposición del plano de control del clúster.
Autoriza acceso al plano de control.
Permite la conectividad del plano de control.
Implementa proxies para el acceso al plano de control desde redes con intercambio de tráfico.
Restringe el tráfico del clúster mediante políticas de red.
Habilita las políticas de seguridad de Google Cloud Armor para Ingress.
Usa Identity-Aware Proxy para proporcionar autenticación a las aplicaciones con usuarios de IAM.
Usa restricciones de las políticas de la organización para mejorar aún más la seguridad.
Usa GKE Dataplane V2
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 del servicio, la aplicación de las políticas de red y el registro. Habilita el plano de datos nuevo con la opción --enable-dataplane-v2 de Google Cloud CLI 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. Recomendamos crear clústeres con GKE Dataplane V2 para aprovechar al máximo las características integradas, como el registro de políticas de red.
Elige un tipo de clúster privado
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 internas en los nodos y tienen extremos privados o 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 APIs de Google con el Acceso privado a Google. Recomendamos elegir clústeres privados.
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:
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 internas.
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:
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 APIs 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.
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 Kubernetes. 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 Kubernetes se aplican a nivel de Pod para aplicar las rutas de tráfico de Pod a Pod.
Si implementas firewalls de VPC, puede interrumpir la comunicación predeterminada del plano de control requerida, por ejemplo, la comunicación de 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 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.
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 balanceadores de cargas de aplicaciones externos 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 balanceadores de cargas de aplicaciones externos 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 postura 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.
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.
Recomendaciones:
Usa Cloud DNS para GKE.Habilita NodeLocal DNSCache.
Usa Cloud NAT para acceder a Internet desde clústeres privados.
Usa el Acceso privado a Google para acceder a los servicios de Google.
Usa Cloud DNS para GKE
Puedes usar Cloud DNS para GKE a fin de proporcionar resolución de DNS de Pods y Services con DNS administrado sin un proveedor de DNS alojado en clústeres. Cloud DNS quita la sobrecarga de administrar un servidor DNS alojado en clústeres y no requiere escalamiento, supervisión ni administración de instancias de DNS, ya que es un servicio alojado de Google.
Habilitar 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 Google Cloud CLI 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.
Usa las siguientes prácticas recomendadas de configuración de la puerta de enlace de Cloud NAT mientras usas Cloud NAT para clústeres privados:
- Cuando crees la puerta de enlace de Cloud NAT, habilítala solo para los rangos de subred que usan tus clústeres. Si cuentas todos los nodos en todos los clústeres, puedes determinar cuántas VMs de consumidor de NAT tienes en el proyecto.
Usa la asignación dinámica de puertos para asignar diferentes cantidades de puertos por VM, según el uso de la VM. Comienza con puertos mínimos de 64 y puertos máximos de 2,048.
Si necesitas administrar muchas conexiones simultáneas al mismo tuplado de 3 destinos, reduce el tiempo de espera de
TIME_WAITde TCP de su valor predeterminado de120sa5s. Para obtener más información, consulta Especifica diferentes tiempos de espera para NAT.Habilita el registro de errores de Cloud NAT para verificar los registros relacionados.
Verifica los registros de la puerta de enlace de Cloud NAT después de configurar la puerta de enlace. Para disminuir los problemas de estado de asignación, es posible que debas aumentar la cantidad máxima de 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 direcciones 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 APIs de Google. El Acceso privado a Google permite que los recursos privados de Google Cloud lleguen a los servicios de Google.
El Acceso privado a Google está habilitado de forma predeterminada en los clústeres privados, excepto en los clústeres de VPC compartida.
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.
Recomendaciones:
Usa el balanceo de cargas nativo del contenedor.Elige el recurso de GKE correcto para exponer tu aplicación.
Crea verificaciones de estado basadas en BackendConfig.
Usa la política de tráfico local para conservar las direcciones IP originales.
Usa Private Service Connect.
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 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 balanceador de cargas de aplicaciones externo. 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 red de transferencia 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.
Usa Private Service Connect
Puedes usar Private Service Connect para compartir servicios de balanceador de cargas de red de transferencia interno en otras redes de VPC. Esto es útil para los servicios alojados en clústeres de GKE, pero que entregan clientes que se ejecutan en diferentes proyectos y VPC.
Puedes usar Private Service Connect para reducir el consumo de direcciones IP si proporcionas conectividad entre las VPC con direcciones IP superpuestas.
Operaciones y administración
Recomendaciones:
Usa permisos de IAM para GKE a fin de controlar las políticas en redes de VPC compartidas.Usa clústeres regionales y distribuye tus cargas de trabajo para obtener una alta disponibilidad.
Usa Cloud Logging y Cloud Monitoring y habilita el registro de políticas de red.
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 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 reglas de firewall de forma manual, asigna un rol personalizado con privilegios mínimos 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.
El rol personalizado que crees debe tener los siguientes permisos:
compute.firewalls.createcompute.firewalls.getcompute.firewalls.listcompute.firewalls.delete
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, para 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.También puedes usar 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 sobre cómo 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 Cloud Logging y Cloud Monitoring y habilita el registro de políticas de red
Si bien cada organización tiene requisitos diferentes para la visibilidad y la auditoría, recomendamos habilitar el registro de políticas de red. Esta función solo está disponible en GKE Dataplane V2. 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, Logging y Monitoring están habilitados de forma predeterminada. Monitoring proporciona un panel para tus clústeres de GKE. Logging también habilita las anotaciones de GKE para los registros de flujo de VPC. De forma predeterminada, Logging recopila 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 GKE para observar y configurar alertas. En el caso de los clústeres creados en el modo Autopilot, la supervisión y el registro están habilitados de forma automática y no se pueden configurar.
Ten en cuenta que hay costos involucrados en Google Cloud Observability.