En esta página se describen las prácticas recomendadas para configurar las opciones de redes de los clústeres de Google Kubernetes Engine (GKE). Se trata de una guía de planificación de la arquitectura para arquitectos de la nube e ingenieros de redes con recomendaciones de configuración de clústeres que se pueden aplicar a la mayoría de los clústeres de GKE. Antes de crear tus clústeres de GKE, te recomendamos que leas todas las secciones de esta página para conocer las opciones de red que admite GKE y sus implicaciones.
Las opciones de red que elijas influyen en 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 esta página, asegúrate de que conoces los conceptos y la terminología de las redes de Kubernetes, así como algunos conceptos generales de redes y las redes de Kubernetes. Para obtener más información, consulta la descripción general de la red de GKE.
Al revisar estas prácticas recomendadas, ten en cuenta lo siguiente:
- Cómo tienes previsto exponer las cargas de trabajo internamente a tu red de nube privada virtual (VPC), a otras cargas de trabajo del clúster, a otros clústeres de GKE o externamente a Internet.
- Cómo piensas escalar tus cargas de trabajo.
- Qué tipos de servicios de Google quieres consumir.
Para ver una lista de comprobación resumida de todas las prácticas recomendadas, consulta el resumen de la lista de comprobación.
Prácticas recomendadas para diseñar una VPC
Cuando diseñes tus redes de VPC, sigue las prácticas recomendadas para el diseño de VPCs.
En la siguiente sección se ofrecen algunas recomendaciones específicas de GKE para el diseño de redes de VPC.
Usar clústeres nativos de VPC
Te recomendamos que uses clústeres nativos de VPC. Los clústeres nativos de VPC usan intervalos de direcciones IP con alias en los nodos de GKE y son obligatorios para los clústeres basados en el emparejamiento entre redes de VPC, para los clústeres de VPC compartidas y tienen muchas otras ventajas. En el caso de los clústeres creados en el modo Autopilot, el modo nativo de VPC está siempre activado y no se puede desactivar.
Los clústeres nativos de VPC se escalan más fácilmente que los clústeres basados en rutas sin consumir rutas, por lo que son menos susceptibles de alcanzar los límites de enrutamiento. Google Cloud
Las ventajas de usar clústeres nativos de VPC van de la mano con la compatibilidad con IPs de alias. Por ejemplo, los grupos de puntos finales de red (NEGs) solo se pueden usar con direcciones IP secundarias, por lo que solo se admiten en clústeres nativos de VPC.
Usar redes de VPC compartidas
Los clústeres de GKE requieren una planificación de direcciones IP cuidadosa. La mayoría de las organizaciones suelen tener una estructura de gestión centralizada con un equipo de administración de redes que puede asignar espacio de direcciones IP a los clústeres y un administrador de plataforma para 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 red de VPC compartida, un administrador de red puede crear subredes y compartirlas con VPCs. Puedes crear clústeres de GKE en un proyecto de servicio y usar las subredes compartidas de la VPC compartida en el proyecto host. El componente de dirección IP permanece en el proyecto host y los demás componentes del clúster se encuentran en el proyecto de servicio.
Por lo general, una red de VPC compartida es una arquitectura que se usa con frecuencia y que es adecuada para la mayoría de las organizaciones con un equipo de gestión centralizado. Te recomendamos que uses redes de VPC compartidas para crear las subredes de tus clústeres de GKE y evitar conflictos de direcciones IP en tu organización. También puedes usar las VPCs compartidas para gestionar las funciones operativas. Por ejemplo, puedes tener un equipo de redes que solo trabaje en componentes de red y fiabilidad, y otro equipo que trabaje en GKE.
Estrategias de gestión de direcciones IP
Todos los clústeres de Kubernetes, incluidos los de GKE, requieren una dirección IP única para cada pod. Para obtener más información, consulta el modelo de redes de GKE.
En GKE, se puede enrutar todas estas direcciones IP en toda la red de VPC. Por lo tanto, es necesario planificar las direcciones IP, ya que no pueden solaparse con el espacio de direcciones IP internas que se utiliza en las instalaciones o en otros entornos conectados. En las siguientes secciones se sugieren estrategias para gestionar las direcciones IP con GKE.
Prácticas recomendadas:
Planifica la asignación de direcciones IP necesarias.Usa un espacio no incluido en RFC 1918 si es necesario.
Usa el modo de subred personalizado.
Plan de densidad de pods por nodo.
Evita que se solapen con las direcciones IP que se usan en otros entornos.
Crea una subred de balanceador de carga.
Reserva suficiente espacio de direcciones IP para la herramienta de adaptación dinámica de clústeres.
Compartir direcciones IP entre clústeres.
Compartir direcciones IP para servicios LoadBalancer internos.
Planificar la asignación de direcciones IP necesaria
Te recomendamos que uses clústeres nativos de VPC con Private Service Connect (PSC). Los clústeres que usan el emparejamiento entre redes de VPC deben ser clústeres nativos de VPC.
Los clústeres nativos de VPC requieren los siguientes intervalos de direcciones IP:
- Intervalo de direcciones IP del plano de control: usa una subred /28 dentro de los intervalos privados de direcciones IP incluidos en la RFC 1918. Debes asegurarte de que esta subred no se solape con ningún otro enrutamiento entre dominios sin clases (CIDR) de la red VPC.
- Subred de nodos: la subred con el intervalo de direcciones IP principal que quieras asignar a todos los nodos de tu clúster. Los servicios de 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 los balanceadores de carga internos. - Intervalo de direcciones IP de pods: el intervalo de IP que asignas a todos los pods de tu clúster. GKE aprovisiona este intervalo como un alias de la subred. Para obtener más información, consulta Intervalos de direcciones IP de clústeres nativos de VPC.
- Intervalo de direcciones IP de servicio: intervalo de direcciones IP que asignas a todos los servicios de tu clúster. GKE aprovisiona este intervalo como un alias de la subred.
Al configurar la red del clúster, debes definir una subred de nodos, un intervalo de direcciones IP de pods y un intervalo de direcciones IP de servicios.
Si quieres usar el espacio de direcciones IP de forma más eficiente, consulta Reducir el uso de direcciones IP internas en GKE.
El intervalo de direcciones IP del plano de control se dedica al plano de control gestionado por GKE que reside en un proyecto de inquilino gestionado por Google emparejado con tu VPC. Este intervalo de direcciones IP no debe solaparse con ninguna dirección IP de tu grupo de emparejamiento de VPCs, ya que GKE importa esta ruta a tu proyecto. Esto significa que, si tienes alguna ruta a la misma CIDR en tu proyecto, es posible que tengas problemas de enrutamiento.
Al crear un clúster, la subred tiene un intervalo principal para los nodos del clúster y debe existir antes de la creación del clúster. La subred debe admitir el número máximo de nodos que esperas del clúster y las direcciones IP del balanceador de carga interno en todo el clúster mediante la subred.
Puedes usar la herramienta de adaptación dinámica de clústeres para limitar el número máximo de nodos.
Los intervalos de direcciones IP de pods y servicios se representan como intervalos secundarios distintos de tu subred, implementados como direcciones IP de alias en clústeres nativos de VPC.
Elige intervalos de direcciones IP lo suficientemente amplios para dar cabida a todos los nodos, pods y servicios del clúster.
Ten en cuenta las siguientes limitaciones:
- Puedes ampliar los intervalos de direcciones IP principales, pero no reducirlos. Estos intervalos de direcciones IP no pueden ser discontinuos.
- Puedes ampliar el intervalo de pods añadiendo intervalos de pods adicionales al clúster o creando grupos de nodos con otros intervalos de pods secundarios.
- El intervalo de direcciones IP secundario de los servicios no se puede ampliar ni cambiar durante la vida útil del clúster.
- Consulta las limitaciones del intervalo de direcciones IP secundario para pods y servicios.
Usar más de una dirección IP privada RFC 1918
En algunos entornos, es posible que el espacio RFC 1918 en grandes bloques CIDR contiguos ya se haya asignado en una organización. Puedes usar espacio no RFC 1918 para añadir CIDRs a los clústeres de GKE, siempre que no se solapen con las direcciones IP públicas propiedad de Google. Te recomendamos que utilices la parte 100.64.0.0/10 del espacio de direcciones RFC, ya que el espacio de direcciones de clase E puede presentar problemas de interoperabilidad con el hardware local. Puedes usar IPs públicas reutilizadas de forma privada (PUPI).
Cuando utilices direcciones IP públicas usadas de forma privada, hazlo con precaución y considera la posibilidad de controlar los anuncios de rutas en redes locales a Internet al elegir esta opción.
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 servicio. Esto rompe el modelo de red de Kubernetes.
Kubernetes da por hecho 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 procede de estas direcciones.
Si usas una dirección IP que no sea RFC 1918 para tu clúster de GKE, en el caso de los clústeres estándar, tendrás que inhabilitar explícitamente SNAT o configurar el agente de enmascaramiento de IP para excluir de SNAT las direcciones IP de los pods de tu clúster y los intervalos de direcciones IP secundarias de los servicios. En los clústeres de Autopilot, no es necesario seguir ningún paso adicional.
Usar el modo de subred personalizada
Cuando configures la red, también tendrás que seleccionar el modo de subred: auto (predeterminado) o custom (recomendado). El modo auto deja la asignación de subredes en manos de Google y es una buena opción para empezar sin tener que planificar las direcciones IP. Sin embargo, te recomendamos que selecciones el modo custom, ya que te permite elegir intervalos de direcciones IP que no se solapen con otros intervalos de tu entorno. Si usas una VPC compartida, puede seleccionar este modo un administrador de la organización o un administrador de la red.
En el siguiente ejemplo se crea una red llamada my-net-1 con el modo de subred personalizado:
gcloud compute networks create my-net-1 --subnet-mode custom
Plan de densidad de pods por nodo
De forma predeterminada, los clústeres estándar reservan un intervalo /24 para cada nodo del espacio de direcciones de los pods en la subred y permiten hasta 110 pods por nodo. Sin embargo, puedes configurar un clúster estándar para que admita hasta 256 pods por nodo, con un intervalo /23 reservado para cada nodo. En función del tamaño de los nodos y del perfil de aplicación de los pods, es posible que ejecutes muchos menos pods en cada nodo.
Si no tienes previsto ejecutar más de 64 pods por nodo, te recomendamos que ajustes el número máximo de pods por nodo para conservar el espacio de direcciones IP en tu subred de pods.
Si tienes previsto ejecutar más de 110 pods por nodo (el valor predeterminado), puedes aumentar el número máximo de pods por nodo hasta 256, con /23 reservado para cada nodo. Con este tipo de configuración de alta densidad de pods, te recomendamos que uses instancias con 16 o más núcleos de CPU para asegurar la escalabilidad y el rendimiento de tu clúster.
En los clústeres Autopilot, el número máximo de pods por nodo es 32, y se reserva un intervalo /26 para cada nodo. Este ajuste no se puede configurar en los clústeres de Autopilot.
Evitar solapamientos con direcciones IP usadas en otros entornos
Puedes conectar tu red de VPC a un entorno on-premise u otros proveedores de servicios en la nube a través de Cloud VPN o Cloud Interconnect. Estos entornos pueden compartir rutas, por lo que el esquema de gestión de direcciones IP locales es importante en la planificación de direcciones IP para GKE. Te recomendamos que te asegures de que las direcciones IP no se solapen con las direcciones IP utilizadas en otros entornos.
Crear una subred de balanceador de carga
Crea una subred de balanceador de carga independiente para exponer servicios con el balanceo de carga TCP/UDP interno. Si no se usa una subred de balanceador de carga independiente, estos servicios se exponen mediante una dirección IP de la subred de nodos, lo que puede provocar que se utilice todo el espacio asignado en esa subred antes de lo esperado e impedir que escales tu clúster de GKE al número de nodos esperado.
Si usas una subred de balanceador de carga independiente, también puedes filtrar el tráfico hacia y desde los nodos de GKE por separado de los servicios expuestos por el balanceo de carga TCP/UDP interno, lo que te permite definir límites de seguridad más estrictos.
Reservar suficiente espacio de direcciones IP para el escalado automático de clústeres
Puedes usar el escalador automático de clústeres para añadir y quitar nodos de forma dinámica en el clúster, de modo que puedas controlar los costes y mejorar la utilización. Sin embargo, si usas el autoescalador de clústeres, 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, así como su propio conjunto asignable de direcciones IP de Pods en función de los Pods configurados por nodo. El número de pods por nodo se puede configurar de forma diferente a lo que se haya configurado a nivel de clúster. No puedes cambiar el número de pods por nodo después de crear el clúster o el grupo de nodos. Deberías tener en cuenta los tipos de cargas de trabajo y asignarlos a grupos de nodos distintos para optimizar la asignación de direcciones IP.
Te recomendamos que uses el aprovisionamiento automático de nodos con la herramienta de adaptación dinámica de clústeres, sobre todo si utilizas clústeres nativos de VPC. Para obtener más información, consulta Intervalos de limitación de nodos.
Compartir direcciones IP entre clústeres
Es posible que tengas que compartir direcciones IP entre clústeres si tienes un equipo centralizado que gestiona la infraestructura de los clústeres. Para compartir direcciones IP entre clústeres de GKE, consulta Compartir intervalos de direcciones IP entre clústeres de GKE. Puedes reducir el agotamiento de las IPs creando tres intervalos para pods, servicios y nodos, y reutilizándolos o compartiéndolos, sobre todo en un modelo de VPC compartida. Esta configuración también puede facilitar a los administradores de redes la gestión de las direcciones IP, ya que no tendrán que crear subredes específicas para cada clúster.
Ten en cuenta lo siguiente:
- Como práctica recomendada, usa subredes e intervalos de direcciones IP independientes para todos los clústeres.
- Puedes compartir el intervalo de direcciones IP secundarias de los pods, pero no es recomendable porque un clúster podría usar todas las direcciones IP.
- Puedes compartir intervalos de direcciones IP de servicio secundarias, pero esta función no funciona con Cloud DNS con ámbito de VPC para GKE.
Si te quedas sin direcciones IP, puedes crear intervalos de direcciones IP de pods adicionales con CIDR de varios pods no contiguos.
Compartir direcciones IP para servicios LoadBalancer internos
Puedes compartir una sola dirección IP con hasta 50 back-ends usando diferentes puertos. De esta forma, puedes reducir el número de direcciones IP que necesitas para los servicios LoadBalancer internos.
Para obtener más información, consulta IP compartida.
Prácticas recomendadas de seguridad de redes
En esta sección se describen algunas recomendaciones clave para el aislamiento de clústeres. La seguridad de la red de los clústeres de GKE es una responsabilidad compartida entre Google y los administradores de tus clústeres.
Prácticas recomendadas:
Usa GKE Dataplane V2.Minimiza la exposición de los nodos.
Minimiza la exposición del plano de control del clúster.
Autoriza el acceso al plano de control.
Permitir la conectividad del plano de control.
Implementar proxies para acceder al plano de control desde redes emparejadas.
Restringe el tráfico del clúster mediante políticas de red.
Habilita las políticas de seguridad de Google Cloud Armor para el tráfico de entrada.
Usa Identity-Aware Proxy para proporcionar autenticación a las aplicaciones con usuarios de gestión de identidades y accesos.
Usa restricciones de políticas de organización para mejorar aún más la seguridad.
Usar GKE Dataplane V2
GKE Dataplane V2 se basa en eBPF y proporciona una experiencia integrada de seguridad y visibilidad de la red. Cuando creas un clúster con GKE Dataplane V2, no tienes que habilitar explícitamente las políticas de red, ya que GKE Dataplane V2 gestiona el enrutamiento de servicios, la aplicación de políticas de red y el registro. Habilita el nuevo plano de datos con la opción --enable-dataplane-v2de Google Cloud CLI al crear un clúster. Una vez configuradas las políticas de red, se puede configurar un objeto CRD NetworkLogging predeterminado para registrar las conexiones de red permitidas y denegadas. Te recomendamos que crees clústeres con GKE Dataplane V2 para aprovechar al máximo las funciones integradas, como el registro de políticas de red.
Minimizar la exposición de los nodos
En un clúster que solo tiene nodos privados, los pods están aislados de la comunicación entrante y saliente (el perímetro del clúster). Puedes controlar estos flujos direccionales exponiendo servicios mediante el balanceo de carga y Cloud NAT, como se explica en la sección Conectividad de clústeres 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 con nodos privados. Los clientes locales pueden conectarse al clúster con el cliente kubectl. El acceso a los servicios de Google se proporciona a través de Acceso privado de Google, y la comunicación con Internet solo está disponible mediante Cloud NAT.
Minimizar la exposición del plano de control del clúster
El plano de control tiene dos tipos de endpoints para acceder al clúster:
- Endpoint basado en DNS
- Endpoints basados en IP
Usa solo el endpoint basado en DNS para acceder a tu plano de control y disfrutar de una configuración simplificada y de una capa de seguridad flexible basada en políticas.
Se puede acceder al endpoint DNS desde cualquier red a la que puedan acceder las APIs, incluidas las redes locales u otras redes en la nube. Google Cloud Para habilitar el endpoint basado en DNS, usa la marca --enable-dns-access.
El servidor de la API de GKE también se puede exponer como un endpoint público o privado basado en IP. Puedes decidir qué endpoint usar cuando crees el clúster. Puedes controlar el acceso con redes autorizadas, donde los endpoints públicos y privados permiten de forma predeterminada toda la comunicación entre las direcciones IP de los pods y los nodos del clúster. Para habilitar un endpoint privado al crear un clúster, usa la marca --enable-private-endpoint.
Autorizar el acceso al plano de control
Las redes autorizadas pueden ayudar a determinar qué subredes de direcciones IP pueden acceder a los nodos del plano de control de GKE. Después de habilitar estas redes, puede restringir el acceso a intervalos de direcciones IP de origen específicos. Si el endpoint público está inhabilitado, estos intervalos de direcciones IP de origen deben ser privados. Si un endpoint público está habilitado, puedes permitir intervalos de direcciones IP públicas o internas.
Configura anuncios de rutas personalizadas
para que se pueda acceder al punto final privado del plano de control del clúster desde un entorno on-premise. Puedes hacer que el endpoint de la API privada de GKE sea accesible a nivel mundial mediante la opción --enable-master-global-access al crear un clúster.
En el siguiente diagrama se muestra la conectividad del plano de control habitual mediante redes autorizadas:
En este diagrama se muestra cómo los usuarios de confianza pueden comunicarse con el plano de control de GKE a través del endpoint público, ya que forman parte de redes autorizadas, mientras que se bloquea el acceso de los actores que no son de confianza. La comunicación con el clúster de GKE se realiza a través del endpoint privado del plano de control.
Permitir la conectividad del plano de control
Algunos pods del sistema de cada nodo de trabajo deberán acceder a servicios como el servidor de la API de Kubernetes (kube-apiserver), las APIs de Google o el servidor de metadatos.
El kube-apiservertambién debe comunicarse con algunos pods del sistema, como event-exporter. Esta comunicación está permitida de forma predeterminada. Si implementas reglas de cortafuegos de VPC en los proyectos (consulta más detalles en la sección Restringir el tráfico del clúster), asegúrate de que esos pods puedan seguir comunicándose con kube-apiserver y con las APIs de Google.
Desplegar proxies para acceder al plano de control desde redes emparejadas
Si tu clúster usa emparejamiento entre redes de VPC, no puedes acceder al plano de control del clúster desde otra red emparejada.
Si quieres tener acceso directo desde otra red emparejada o desde una red local cuando uses una arquitectura de concentrador y radios, implementa proxies para el tráfico del plano de control.
Restringir 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 los clústeres: reglas de cortafuegos de VPC, políticas de cortafuegos jerárquicas y políticas de red de Kubernetes. Las reglas de cortafuegos de VPC y las políticas de cortafuegos de jerarquía se aplican a nivel de máquina virtual (VM), es decir, a los nodos de trabajador 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 reforzar las rutas de tráfico entre pods.
Si implementas cortafuegos de VPC, se puede interrumpir la comunicación predeterminada y obligatoria del plano de control, como la comunicación de kubelet con el plano de control. GKE crea reglas de firewall obligatorias de forma predeterminada, pero se pueden sobrescribir. En algunas implementaciones, es posible que el plano de control tenga que acceder al clúster en el servicio. Puedes usar cortafuegos de VPC para configurar una política de entrada que permita acceder al servicio.
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 de los pods de un clúster. Puedes habilitar las políticas de red al crear un clúster mediante la opción gcloud container
clusters create--enable-network-policy. Para restringir el tráfico mediante políticas de red, puedes seguir la guía de implementación de la blueprint de restricción del tráfico de Anthos.
Habilitar 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 carga de aplicaciones externos frente a ataques DDoS y otros ataques web bloqueando ese tráfico en el perímetro de la red. En GKE, habilita las políticas de seguridad de Google Cloud Armor para las aplicaciones mediante Ingress para balanceadores de carga de aplicaciones externos y añadiendo una política de seguridad al objeto BackendConfig adjunto al objeto Ingress.
Usar Identity-Aware Proxy para autenticar aplicaciones con usuarios de gestión de identidades y accesos
Si quieres implementar servicios a los que solo puedan acceder los usuarios de la organización, pero sin necesidad de estar en la red corporativa, puedes usar Identity-Aware Proxy para crear una capa de autenticación para estas aplicaciones. Para habilitar Identity-Aware Proxy en GKE, sigue los pasos de configuración para añadir Identity-Aware Proxy como parte de BackendConfig para tu Ingress de servicio. Identity-Aware Proxy se puede combinar con Google Cloud Armor.
Usar restricciones de política de organización para mejorar aún más la seguridad
Con las restricciones de políticas de organización, puedes definir políticas para mejorar aún más tu postura de seguridad. Por ejemplo, puedes usar restricciones para limitar la creación de balanceadores de carga a determinados tipos, como los balanceadores de carga internos.
Escalado de la conectividad de clústeres
En esta sección se describen las opciones escalables de DNS y conectividad saliente de tus clústeres a Internet y a los servicios de Google.
Prácticas recomendadas:
Usa Cloud DNS para GKE.Habilita NodeLocal DNSCache.
Usa Cloud NAT para acceder a Internet desde los clústeres.
Usa el acceso privado a Google para acceder a los servicios de Google.
Usar Cloud DNS para GKE
Puedes usar Cloud DNS para GKE para proporcionar resolución de DNS de pods y servicios con DNS gestionado sin un proveedor de DNS alojado en el clúster. Cloud DNS elimina la sobrecarga de gestionar un servidor DNS alojado en un clúster y no requiere escalado, monitorización ni gestión de instancias DNS, ya que es un servicio de Google alojado.
Habilitar NodeLocal DNSCache
GKE usa kube-dns para proporcionar el servicio DNS local del clúster como complemento predeterminado del clúster. kube-dns se replica en todo el clúster
en función del número total de núcleos y nodos del clúster.
Puedes mejorar el rendimiento del DNS con NodeLocal DNSCache. NodeLocal DNSCache es un complemento que se implementa como un DaemonSet y no requiere ningún cambio en la configuración de los pods. Las búsquedas de DNS en el servicio de pods local no crean conexiones abiertas que deban monitorizarse en el nodo, lo que permite una mayor escalabilidad. 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 que los tiempos de búsqueda de consultas de DNS sean más coherentes y se mejore la escalabilidad del clúster. En 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 formas de mejorar el escalado de DNS. Por ejemplo, usa un FQDN (termina el nombre de host con un punto) o inhabilita la expansión de la ruta de búsqueda mediante la opción Pod.dnsConfig del manifiesto.
Usar Cloud NAT para acceder a Internet desde clústeres
De forma predeterminada, los clústeres con nodos privados habilitados no tienen acceso a Internet. Para permitir que los pods accedan a Internet, habilita Cloud NAT en cada región. Como mínimo, habilita Cloud NAT para los intervalos principal y secundario de la subred de GKE. Asegúrate de asignar suficientes direcciones IP para Cloud NAT y puertos por VM.
Sigue estas prácticas recomendadas de configuración de pasarelas Cloud NAT al usar Cloud NAT en clústeres:
- Cuando crees tu pasarela Cloud NAT, habilítala solo para los intervalos de subredes que usen tus clústeres. Si cuentas todos los nodos de todos los clústeres, puedes determinar cuántas VMs consumidoras de NAT tienes en el proyecto.
Usa la asignación dinámica de puertos para asignar diferentes números de puertos por VM en función del uso de la VM. Empieza con un mínimo de 64 puertos y un máximo de 2048.
Si necesitas gestionar muchas conexiones simultáneas a la misma tupla de 3 elementos de destino, reduce el tiempo de espera de TCP
TIME_WAITde su valor predeterminado de120sa5s. Para obtener más información, consulta Especificar diferentes tiempos de espera para NAT.Habilita el registro de errores de Cloud NAT para consultar los registros relacionados.
Consulta los registros de la pasarela de Cloud NAT después de configurarla. Para reducir los problemas de asignación, puede que tengas que aumentar el número máximo de puertos por VM.
Debes evitar la doble SNAT para el tráfico de los pods (SNAT primero en el nodo de GKE y, después, otra vez con Cloud NAT). A menos que necesites SNAT para ocultar las direcciones IP de los pods en las redes on-premise conectadas mediante Cloud VPN o Cloud Interconnect, disable-default-snat
y delegar el seguimiento de SNAT en Cloud NAT para mejorar la escalabilidad. Esta solución funciona con todos los intervalos 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 usar Cloud NAT para acceder a los servicios de Google.
Usar Acceso privado de Google para acceder a servicios de Google
En los clústeres con nodos privados, los pods no tienen direcciones IP públicas para acceder a servicios públicos, incluidas las APIs y los servicios de Google. Acceso privado de Google permite que los recursos privadosGoogle Cloud accedan a los servicios de Google.
La función Acceso privado de Google está habilitada de forma predeterminada en los clústeres con nodos privados, excepto en los clústeres de VPC compartida.
Prácticas recomendadas para el escalado de aplicaciones
Cuando crees aplicaciones a las que se pueda acceder desde fuera o desde dentro de tu organización, asegúrate de usar el tipo y las opciones de balanceador de carga adecuados. En esta sección se ofrecen algunas recomendaciones sobre cómo exponer y escalar aplicaciones con Cloud Load Balancing.
Prácticas recomendadas:
Usa el balanceo de carga nativo de contenedores.Elige el recurso de GKE correcto para exponer tu aplicación.
Crea comprobaciones del estado basadas en BackendConfig.
Usa la política de tráfico local para conservar las direcciones IP originales.
Usa Private Service Connect.
Usar el balanceo de carga nativo de contenedores
Usa el balanceo de carga nativo de contenedores cuando expongas servicios mediante HTTP(S) de forma externa. El balanceo de carga nativo de contenedores permite que haya menos saltos de red, una latencia más baja y una distribución del tráfico más exacta. También aumenta la visibilidad del tiempo de ida y vuelta y te permite usar funciones de balanceo de carga, como Google Cloud Armor.
Elige el recurso de GKE correcto para exponer tu aplicación
En función del ámbito de tus clientes (internos, externos o incluso internos del clúster), la regionalidad de tu aplicación y los protocolos que utilices, puedes elegir entre diferentes recursos de GKE para exponer tu aplicación. En el resumen de la red de servicios se explican estas opciones y se te ayuda a elegir el mejor recurso para exponer cada parte de tu aplicación mediante las Google Cloud opciones de balanceo de carga.
Crear comprobaciones del estado basadas en BackendConfig
Si usas un objeto Ingress para exponer servicios, utiliza una configuración de comprobación del estado en un CRD BackendConfig para usar la función de comprobación del estado del balanceador de carga de aplicaciones externo. Puedes dirigir la comprobación de estado al endpoint adecuado y definir tus propios umbrales. Si no hay un CRD BackendConfig, las comprobaciones del estado se infieren a partir de los parámetros de la comprobación de disponibilidad o se usan los parámetros predeterminados.
Usar la política de tráfico local para conservar las direcciones IP originales
Cuando uses un balanceador de carga de red de paso a través interno con GKE, define la opción externalTrafficPolicy en Local para conservar la dirección IP de origen de las solicitudes. Usa esta opción si tu aplicación requiere la dirección IP de origen original. Sin embargo, la opción externalTrafficPolicy local puede provocar una distribución de la carga menos óptima, por lo que solo debes usar esta función cuando sea necesario. En el caso de los servicios HTTP(S), puedes usar controladores Ingress y obtener la dirección IP original leyendo el encabezado X-Forwarded-For en la solicitud HTTP.
Usar Private Service Connect
Puedes usar Private Service Connect para compartir servicios de balanceador de carga de red de pases internos entre otras redes de VPC. Esto es útil para los servicios alojados en clústeres de GKE, pero que atienden a clientes que se ejecutan en diferentes proyectos y VPCs.
Puedes usar Private Service Connect para reducir el consumo de direcciones IP proporcionando conectividad entre VPCs con direcciones IP superpuestas.
Prácticas recomendadas operativas
Prácticas recomendadas:
Usa IAM para los permisos de GKE y controla las políticas en redes de VPC compartidas.Usa clústeres regionales y distribuye tus cargas de trabajo para conseguir una alta disponibilidad.
Utiliza Cloud Logging y Cloud Monitoring y habilita el registro de políticas de red.
En las siguientes secciones se incluyen prácticas recomendadas operativas que le ayudarán a asegurarse de que sus cargas de trabajo tengan opciones de autorización granulares. Para evitar crear reglas de firewall manuales, sigue las prácticas recomendadas que se indican en esta sección. También incluye recomendaciones para distribuir tus cargas de trabajo y para monitorizar y registrar en GKE.
Usar IAM para los permisos de GKE y controlar las políticas en redes de VPC compartidas
Cuando se usan redes de VPC compartidas, las reglas de cortafuegos de los balanceadores de carga se crean automáticamente en el proyecto host.
Para no tener que crear reglas de cortafuegos manualmente, asigna un rol personalizado con el mínimo de privilegios a la cuenta de servicio de GKE del proyecto host, que se llama service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.
Sustituye HOST_PROJECT_NUMBER por el número del proyecto host de 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 cortafuegos creadas por GKE siempre tienen la prioridad predeterminada de 1000, por lo que puedes impedir que fluya tráfico específico creando reglas de cortafuegos con una prioridad más alta.
Si quieres restringir la creación de determinados tipos de balanceadores de carga, usa políticas de organización para restringir la creación de balanceadores de carga.
Usar clústeres regionales y distribuir las cargas de trabajo para conseguir una alta disponibilidad
Los clústeres regionales pueden aumentar la disponibilidad de las aplicaciones de un clúster, ya que el plano de control y los nodos del clúster se distribuyen en varias zonas.
Sin embargo, para ofrecer la mejor experiencia de usuario posible en caso de que falle una zona, utiliza el autoscalador de clústeres para asegurarte de que tu clúster pueda gestionar la carga necesaria en cualquier momento.
También puedes usar la antiafinidad de pods para asegurarte de que los pods de un servicio determinado se programen en varias zonas.
Para obtener más información sobre cómo configurar estos ajustes para conseguir una alta disponibilidad y optimizar los costes, consulta las prácticas recomendadas para los clústeres de GKE de alta disponibilidad.
Usar Cloud Logging y Cloud Monitoring, y habilitar el registro de políticas de red
Aunque cada organización tiene requisitos diferentes en cuanto a visibilidad y auditoría, te recomendamos que habilites el registro de políticas de red. Esta función solo está disponible con GKE Dataplane V2. El registro de políticas de red proporciona visibilidad sobre la aplicación de las políticas y los patrones de tráfico de los pods. Ten en cuenta que registrar las políticas de red tiene un coste.
En los clústeres de GKE que usan la versión 1.14 o posterior, Logging y Monitoring están habilitados de forma predeterminada. Monitoring proporciona un panel de control para tus clústeres de GKE. El registro también habilita las anotaciones de GKE para los registros de flujo de VPC. De forma predeterminada, Logging recoge registros de todas las cargas de trabajo desplegadas en el clúster, pero también existe la opción de registros solo del sistema. Usa el panel de control de GKE para observar y configurar alertas. En el caso de los clústeres creados en el modo Autopilot, la monitorización y el registro se habilitan automáticamente y no se pueden configurar.
Ten en cuenta que Google Cloud Observability tiene costes asociados.
Resumen de la lista de comprobación
Siguientes pasos
- Información valiosa sobre las prácticas recomendadas de GKE
- Prácticas recomendadas para empresas sobre clústeres con varios propietarios