Conexiones VLAN para nodos de trabajador

Todos los nodos de trabajo deben estar conectados a una VLAN privada para que cada nodo de trabajador pueda enviar y recibir información de otros nodos de trabajo. La VLAN privada proporciona subredes privadas que se utilizan para asignar direcciones IP privadas a los nodos trabajadores y a los servicios de app privados. Puede crear un clúster con nodos trabajadores que también estén conectados a una VLAN pública. La VLAN pública proporciona subredes públicas que se utilizan para asignar direcciones IP públicas a los nodos trabajadores y a los servicios de apps públicas. Sin embargo, si necesita proteger sus aplicaciones desde la interfaz de red pública, existen varias opciones para proteger su clúster, como crear políticas de red d Calico idad o aislar las cargas de trabajo de la red externa a los nodos de los trabajadores periféricos.

La primera vez que creas un clúster en una zona, se te aprovisionan automáticamente una VLAN pública y una VLAN privada en esa zona en tu cuenta de infraestructura de IBM Cloud. Si especifica que los nodos trabajadores deben estar conectados únicamente a una VLAN privada, se suministrará automáticamente una VLAN privada en dicha zona. Para los demás clústeres que cree en dicha zona, puede especificar el par de VLAN que desee utilizar. Puede reutilizar las mismas VLAN pública y privada que se han creado porque varios clústeres pueden compartir las VLAN.

Para obtener más información sobre las VLAN, las subredes y las direcciones IP, consulte Visión general de la red en IBM Cloud Kubernetes Service.

¿Necesita crear el clúster con subredes personalizadas? Consulte el apartado sobre Utilización de subredes existentes para crear un clúster.

Comunicación de nodo de trabajador entre subredes y VLAN

En varias situaciones, se debe permitir que los componentes del clúster se comuniquen entre varias VLAN privadas. Por ejemplo, si desea crear un clúster multizona, si tiene varias VLAN para un clúster, o si tiene varias subredes en la misma VLAN, los nodos de trabajador en distintas subredes de la misma VLAN o en distintas VLAN no se pueden comunicar automáticamente entre sí. Debe habilitar VRF (Virtual Routing and Forwarding) o la distribución de VLAN para su cuenta de infraestructura de IBM Cloud.

• Virtual Routing and Forwarding (VRF): VRF permite que todas las VLAN y subredes privadas de la cuenta de la infraestructura se comuniquen entre sí. Además, se necesita VRF para permitir que los nodos trabajadores y el nodo maestro se comuniquen sobre el punto final de servicio en la nube privado y se comuniquen con otras instancias de IBM Cloud que dan soporte a puntos finales de servicio en la nube privados. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show. Para habilitar VRF, ejecute ibmcloud account update --service-endpoint-enable true. La salida de este mandato le solicita que abra un caso de soporte para habilitar la cuenta para que utilice VRF y puntos finales de servicio. VRF elimina la opción de distribución de VLAN para la cuenta, ya que todas las VLAN se pueden comunicar. Cuando VRF está habilitado, cualquier sistema que esté conectado a cualquiera de las VLAN privadas de la misma cuenta de IBM Cloud se puede comunicar con los nodos trabajadores del clúster. Puede aislar el clúster de otros sistemas de la red privada aplicando Políticas de red privada de Calico.
• VLAN spanning: No puede habilitar el punto final del servicio de nube privada si elige habilitar VLAN spanning en lugar de VRF. Habilite el VLAN spanning cuando no pueda o no quiera habilitar el VRF, como cuando no necesite que el maestro sea accesible en la red privada o si utiliza un dispositivo de puerta de enlace para acceder al maestro a través de la VLAN pública. Tenga en cuenta que, por ejemplo, si tiene un dispositivo de puerta de enlace existente y luego agrega un clúster, las nuevas subredes portátiles que se solicitan para el clúster no se configuran en el dispositivo de puerta de enlace, pero la extensión de VLAN permite el enrutamiento entre las subredes.

Solo punto final de servicio público

Si no desea o no puede habilitar VRF para su cuenta, los nodos de trabajador pueden conectarse automáticamente al maestro de Kubernetes a través de la VLAN pública a través del punto final de servicio de nube pública.

• La comunicación entre los nodos trabajadores y el maestro se establece de forma segura sobre la red pública a través del punto final de servicio en la nube público.
• Los usuarios autorizados del clúster pueden acceder de forma pública al nodo maestro solo a través del punto final de servicio en la nube público. Los usuarios del clúster pueden acceder de forma segura al nodo maestro de Kubernetes sobre internet, por ejemplo para ejecutar mandatos kubectl.
• Opcionalmente, puede proteger el acceso a los puntos finales de los servicios públicos y privados de su clúster mediante restricciones basadas en el contexto.

Puntos finales de servicio de nube pública y privada

Para que los usuarios del clúster puedan acceder al nodo maestro de forma pública o privada, puede habilitar los puntos finales de servicio en la nube públicos y privados. Se necesita VRF en la cuenta de IBM Cloud y debe habilitar la cuenta para que utilice puntos finales de servicio. Para habilitar VRF y los puntos finales de servicio, ejecute ibmcloud account update --service-endpoint-enable true.

• Si los nodos trabajadores están conectados a las VLAN pública y privada, la comunicación entre los nodos trabajadores y el nodo maestro se establece tanto sobre la red privada a través del punto final de servicio en la nube privado como sobre la red pública a través del punto final de servicio en la nube público. Direccionando la mitad del tráfico de trabajador a maestro por el punto final público y la otra mitad por el punto final privado, la comunicación de maestro a trabajador está protegida de posibles interrupciones en la red pública o privada. Si los nodos trabajadores solo están conectados a las VLAN privadas, la comunicación entre los nodos trabajadores y el nodo maestro se establece sobre la red privada solo a través del punto final de servicio en la nube privado.
• Los usuarios autorizados del clúster pueden acceder de forma pública al nodo maestro a través del punto final de servicio en la nube público. Se puede acceder de forma privada al nodo maestro a través del punto final de servicio en la nube privado si los usuarios autorizados del clúster están en la red privada de IBM Cloud o están conectados a la red privada a través de una conexión VPN o IBM Cloud Direct Link. Tenga en cuenta que debe exponer el punto final maestro a través de un equilibrador de carga privado para que los usuarios puedan acceder al nodo maestro a través de una conexión VPN o IBM Cloud Direct Link.
• Opcionalmente, puede proteger el acceso a los puntos finales de los servicios públicos y privados de su clúster mediante restricciones basadas en el contexto.

Solo punto final de servicio privado

Para solo se pueda acceder al nodo maestro de forma privada, puede habilitar el punto final de servicio en la nube privado. Se necesita VRF en la cuenta de IBM Cloud y debe habilitar la cuenta para que utilice puntos finales de servicio. Para habilitar VRF y los puntos finales de servicio, ejecute ibmcloud account update --service-endpoint-enable true. Tenga en cuenta que el uso únicamente de un punto final de servicio en la nube privado no incurre en cargos facturados ni de ancho de banda según medición.

• La comunicación entre los nodos trabajadores y el nodo maestro se establece sobre la red privada a través del punto final de servicio en la nube privado.
• Se accede de forma privada al nodo maestro si los usuarios autorizados del clúster están en la red privada de IBM Cloud o están conectados a la red privada a través de una conexión VPN o DirectLink. Tenga en cuenta que debe exponer el punto final maestro a través de un equilibrador de carga privado para que los usuarios puedan acceder al nodo maestro a través de una conexión VPN o DirectLink.
• Opcionalmente, puede proteger el acceso a los puntos finales de los servicios públicos y privados de su clúster mediante restricciones basadas en el contexto.

Comunicación con otros servicios de IBM Cloud a través de la red privada o pública

Los nodos trabajadores se pueden comunicar de forma automática y segura con otros servicios de IBM Cloud que dan soporte a puntos finales de servicio en la nube privados, como por ejemplo IBM Cloud® Container Registry, en su red privada de infraestructura de IBM Cloud. Si un servicio de IBM Cloud no da soporte a puntos finales de servicio en la nube privados, los nodos trabajadores deben estar conectados a una VLAN pública para que se puedan comunicar de forma segura con los servicios a través de la red pública.

Si utiliza políticas de Calico o un dispositivo de pasarela para controlar las redes públicas o privadas de los nodos trabajadores, debe permitir el acceso a las direcciones IP públicas de los servicios que dan soporte a puntos finales de servicio en la nube públicos y, opcionalmente, a las direcciones IP privadas de los servicios que dan soporte a puntos finales de servicio en la nube privados.

• Permitir el acceso a las direcciones IP públicas de los servicios en las políticas de Calico
• Permitir el acceso a las direcciones IP privadas de servicios que dan soporte a puntos finales de servicio en la nube privados en políticas de Calico
• Permitir el acceso a las direcciones IP públicas de los servicios y a las direcciones IP privadas de los servicios que dan soporte a puntos finales de servicio en la nube privados en un cortafuegos de dispositivo de pasarela

IBM Cloud® Direct Link para la comunicación a través de la red privada con recursos en centros de datos locales

Para conectar el clúster con el centro de datos local, como por ejemplo con IBM Cloud Private, puede configurar IBM Cloud Direct Link. Con IBM Cloud Direct Link, puede crear una conexión directa y privada entre los entornos de red remotos y IBM Cloud Kubernetes Service sin direccionamiento a través de Internet público.

Conexión strongSwan IPSec VPN para la comunicación a través de la red pública con recursos en centros de datos locales

• Nodos de trabajo que están conectados a VLAN públicas y privadas: Configure un servicio strongSwan IPSec VPN directamente en su clúster. El servicio VPN IPSec de strongSwan proporciona un canal de comunicaciones de extremo a extremo seguro sobre Internet que está basado en la suite de protocolos Internet Protocol Security (IPSec) estándar del sector. Para configurar una conexión segura entre el clúster y una red local, configure y despliegue el servicio VPN IPSec strongSwan directamente en un pod del clúster.

• Solo nodos trabajadores conectados a una VLAN privada: Configure un punto final de VPN IPSec en un dispositivo de pasarela, como por ejemplo Virtual Router Appliance (Vyatta). A continuación, configure el servicio VPN IPSec de strongSwan en el clúster de modo que utilice el punto final de VPN en la pasarela. Si no desea utilizar strongSwan, puede configurar la conectividad VPN directamente con VRA.

Si tiene previsto conectar el clúster a las redes locales, consulte la siguiente información útil:

• Es posible que tenga conflictos de subred con el rango predeterminado proporcionado por IBM 172.30.0.0/16 para los pods y el rango 172.21.0.0/16 para los servicios. Puede evitar conflictos de subredes cuando cree un clúster desde la CLI especificando una subred CIDR personalizada para los pods en la opción " --pod-subnet " y una subred CIDR personalizada para los servicios en la opción " --service-subnet ".
• Si la solución VPN conserva las direcciones IP de origen de las solicitudes, puede crear rutas estáticas personalizadas para asegurarse de que los nodos trabajadores pueden direccionar las respuestas del clúster de nuevo a la red local.
• Tenga en cuenta que los rangos de subred 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16 están prohibidos porque están reservados para la funcionalidad de plano de control de IBM Cloud Kubernetes Service.

Tráfico privado a aplicaciones de clúster

Al desplegar una aplicación en el clúster, es posible que desee que solo puedan acceder a la aplicación los usuarios y servicios que estén en la misma red privada que el clúster. El equilibrio de carga privado es ideal para hacer que la app esté disponible para las solicitudes desde fuera del clúster sin exponer la app al público en general. También puede utilizar el equilibrio de carga privado para probar el acceso, el direccionamiento de solicitudes y otras configuraciones para la app antes de exponer su app al público con los servicios de red públicos. Para permitir solicitudes de tráfico privadas desde fuera del clúster a las apps, puede crear servicios de red privados de Kubernetes, como por ejemplo nodos privados, NLB y ALB de Ingress. Luego puede utilizar políticas pre-DNAT de Calico para bloquear el tráfico destinado a NodePorts públicos de servicios de red privados. Para obtener más información, consulte Planificación del equilibrio de carga externo privado.

Tráfico público a aplicaciones de clúster

Para hacer que se pueda acceder a las aplicaciones externamente desde el Internet público, puede crear NodePorts públicos, equilibradores de carga de red (NLB) y equilibradores de carga de aplicaciones (ALB) de Ingress. Los servicios de red públicos se conectan a esta interfaz de red pública proporcionando a su app una dirección IP pública y, en función del servicio, un URL público. Cuando se expone públicamente una app, cualquiera que tenga la dirección IP pública del servicio o el URL que haya establecido para la app puede enviar una solicitud a la app. A continuación, puede utilizar las políticas pre-DNAT de Calico para controlar el tráfico a los servicios de red públicos; por ejemplo, puede permitir el tráfico procedente solo de determinadas direcciones IP de origen o CIDR y bloquear el resto del tráfico. Para obtener más información, consulte Planificación del equilibrio de carga externo público.

Para mayor seguridad, puede aislar las cargas de trabajo de red en nodos de trabajadores periféricos.

Los nodos trabajadores de extremo pueden mejorar la seguridad de su clúster al permitir el acceso externo a un número inferior de nodos trabajadores conectados a las VLAN públicas y aislar la carga de trabajo en red. Cuando se etiquetan nodos trabajadores como nodos de extremo, los pods de ALB y NLB se despliegan solo en los nodos trabajadores especificados. Además, para evitar que otras cargas de trabajo se ejecuten en nodos perimetrales, puede contaminar los nodos perimetrales. A continuación, puede desplegar los NLB públicos y privados y los ALB en los nodos de extremo. Por ejemplo, si los nodos trabajadores están conectados únicamente a una VLAN privada, pero tiene que permitir el acceso público a una app en el clúster, puede crear una agrupación de nodos trabajadores de extremo en la que los nodos de extremo se conecten a las VLAN públicas y privadas. Puede desplegar NLB públicos y ALB en estos nodos de extremo para asegurarse de que solo los nodos trabajadores manejen las conexiones públicas.

Comunicación de trabajador a trabajador en clústeres clásicos con cargas de trabajo orientadas a Internet

Para lograr esta configuración, cree un clúster conectando los nodos trabajadores a las VLAN públicas y privadas.

Si crea el clúster con VLAN públicas y privadas, más adelante no podrá eliminar todas las VLAN públicas de dicho clúster. La eliminación de todas las VLAN públicas de un clúster hace que varios componentes del clúster dejen de funcionar. En su lugar, cree una nueva agrupación de nodos trabajadores que esté conectada únicamente a una VLAN privada.

Comunicación de trabajador a maestro y de usuario a maestro en clústeres clásicos con cargas de trabajo orientadas a Internet

Puede optar por permitir la comunicación entre nodo trabajador y nodo maestro y entre usuario y nodo maestro a través de las redes pública y privada o solo a través de la red pública.

• Puntos finales de servicio en la nube públicos y privados: su cuenta debe estar habilitada con VRF y habilitada para utilizar puntos finales de servicio. La comunicación entre nodos trabajadores y nodo maestro se establece tanto sobre la red privada a través del punto final de servicio en la nube privado como sobre la red pública a través del punto final de servicio en la nube público. Los usuarios autorizados del clúster pueden acceder de forma pública al nodo maestro a través del punto final de servicio en la nube público.
• Punto final de servicio público: si no desea o no puede habilitar VRF para su cuenta, los nodos de trabajador y los usuarios de clúster autorizados pueden conectarse automáticamente al maestro de Kubernetes a través de la red pública a través del punto final de servicio de nube pública.

Comunicación de trabajador a otros servicios o redes con cargas de trabajo orientadas a Internet

Los nodos trabajadores se comunican automáticamente y de forma segura con otros servicios de IBM Cloud que dan soporte a puntos finales de servicio en la nube privados a través de la red privada de infraestructura de IBM Cloud. Si un servicio de IBM Cloud no da soporte a puntos finales de servicio en la nube privados, los nodos trabajadores pueden comunicarse de forma segura con los servicios a través de la red pública. Puede bloquear las interfaces públicas o privadas de los nodos trabajadores mediante políticas de red de Calico para el aislamiento de red pública o de red privada. Es posible que tenga que permitir el acceso a las direcciones IP públicas y privadas de los servicios que desea utilizar en estas políticas de aislamiento de Calico.

Si los nodos trabajadores necesitan acceder a servicios en redes privadas fuera de su cuenta de IBM Cloud, puede configurar y desplegar el servicio VPN IPSec de strongSwan en el clúster o aprovechar los servicios IBM Cloud IBM Cloud Direct Link para conectar con estas redes.

Comunicación externa con aplicaciones que se ejecutan en nodos de trabajador con cargas de trabajo orientadas a Internet

Para exponer una app del clúster en Internet, puede crear un servicio equilibrador de carga de red (NLB) público o un servicio equilibrador de carga de aplicación (ALB) de Ingress. Puede mejorar la seguridad del clúster mediante la creación de una agrupación de nodos trabajadores etiquetados como nodos de extremo. Los pods correspondientes a los servicios de red públicos se despliegan en los nodos de extremo de modo que las cargas de trabajo de tráfico externas estén aisladas solo a unos pocos nodos trabajadores del clúster. Puede controlar más el tráfico público a los servicios de red que exponen sus apps mediante la creación de políticas pre-DNAT de Calico, como por ejemplo políticas de lista de elementos permitidos y de lista de elementos bloqueados.

¿Está listo para empezar a trabajar con un clúster en este caso práctico? Después de planificar su configuración de alta disponibilidad, consulte Creación de clústeres.

Comunicación de trabajador a trabajador, de trabajador a maestro y de usuario a maestro con un dispositivo de pasarela

Si configura los nodos de trabajador en una VLAN privada únicamente y no desea o no puede habilitar VRF para su cuenta, debe configurar un dispositivo de pasarela para proporcionar conectividad de red entre los nodos de trabajador y el maestro a través de la red pública. Por ejemplo, puede optar por configurar un Virtual Router Appliance.

Puede configurar un dispositivo de pasarela con políticas de red personalizadas para proporcionar seguridad de red dedicada para el clúster y para detectar y solucionar problemas de intrusión en la red. Cuando configure un cortafuegos en la red pública, debe abrir los puertos y las direcciones IP necesarios para cada región de modo que el nodo maestro y los nodos trabajadores se puedan comunicar. Si también configura este cortafuegos para la red privada, también debe abrir los puertos y las direcciones IP privadas necesarios para permitir la comunicación entre los nodos trabajadores y dejar que el clúster acceda a los recursos de la infraestructura a través de la red privada. También debe habilitar la distribución de VLAN para la cuenta de modo que las subredes puedan direccionar en la misma VLAN y entre varias VLAN.

Comunicación de nodos de trabajador con otros servicios o redes mediante un dispositivo de pasarela

Para conectar de forma segura los nodos trabajadores y las apps a una red local o a servicios fuera de IBM Cloud, configure un punto final de VPN IPSec en el dispositivo de pasarela y el servicio VPN IPSec de strongSwan en el clúster de modo que utilicen el punto final de VPN de pasarela. Si no desea utilizar strongSwan, puede configurar la conectividad VPN directamente con VRA.

Los nodos trabajadores pueden comunicarse de forma segura con otros servicios de IBM Cloud y con servicios públicos externos a IBM Cloud a través del dispositivo de pasarela. Puede configurar el cortafuegos de modo que permita el acceso a las direcciones IP públicas y privadas solo de los servicios que desea utilizar.

Comunicación externa con aplicaciones que se ejecutan en nodos de trabajador con un dispositivo de pasarela

Para proporcionar acceso privado a una app del clúster, puede crear un equilibrador de carga de red (NLB) privado o un equilibrador de carga de aplicación (ALB) de Ingress para exponer la app solo a la red privada. Si tiene que proporcionar un acceso público limitado a una app del clúster, puede crear un NLB o ALB públicos para exponer la app. Debido a que todo el tráfico pasa por el cortafuegos del dispositivo de pasarela, puede controlar el tráfico público y privado a los servicios de red que exponen sus apps abriendo los puertos y las direcciones IP en el servicio en el cortafuegos para permitir el tráfico de entrada a estos servicios.

¿Está listo para empezar a trabajar con un clúster en este caso práctico? Después de planificar su configuración de alta disponibilidad, consulte Creación de clústeres.

Comunicación de trabajador a trabajador para clústeres privados

Para conseguir esta configuración, crea un clúster conectando los nodos trabajadores solo a una VLAN privada. Para proporcionar conectividad entre el nodo maestro del clúster y los nodos trabajadores sobre la red privada solo a través del punto final de servicio en la nube privado, la cuenta debe estar habilitada con VRF y habilitada para utilizar puntos finales de servicio. Puesto que el clúster resulta visible para cualquier recurso de la red privada cuando VRF está habilitado, puede aislar el clúster de otros sistemas de la red privada aplicando políticas de red privada de Calico.

Tenga en cuenta que es posible que tenga conflictos de subred entre los rangos predeterminados correspondientes a nodos trabajadores, pods y servicios y a las subredes de las redes locales. Puede crear su clúster sin subredes proporcionadas por IBM, incluyendo la opción --no-subnet. Una vez creado el clúster, puede añadir subredes personalizadas al mismo. Además, puede especificar una subred CIDR personalizada para pods y servicios utilizando las opciones --pod-subnet y --service-subnet en el comando ibmcloud ks cluster create cuando cree su clúster.

Comunicación de nodo trabajador a maestro y de usuario a maestro para clústeres privados

Se puede acceder al nodo maestro de Kubernetes a través del punto final de servicio en la nube privado si usuarios de clúster autorizados están en la red privada de IBM Cloud o están conectados a la red privada, como por ejemplo a través de una conexión de VPN clásica o IBM Cloud Direct Link. Sin embargo, la comunicación con el nodo maestro de Kubernetes sobre el punto final de servicio en la nube privado debe pasar a través del rango de direcciones IP 166.X.X.X, que no se puede direccionar desde una conexión VPN clásica ni a través de IBM Cloud Direct Link. Puede exponer el punto final de servicio en la nube privado del nodo maestro para los usuarios del clúster utilizando un equilibrador de carga de red (NLB) privado. El NLB privado expone el punto final de servicio en la nube privado del nodo maestro como un rango de direcciones IP 10.X.X.X interno al que pueden acceder los usuarios con la VPN o con la conexión de IBM Cloud Direct Link. Si solo habilita el punto final de servicio en la nube privado, puede utilizar el panel de control de Kubernetes o puede habilitar temporalmente el punto final de servicio en la nube público para crear el NLB privado.

Comunicación de trabajador a otros servicios o redes para clústeres privados

Los nodos trabajadores se comunican automáticamente y de forma segura con otros servicios de IBM Cloud que dan soporte a puntos finales de servicio en la nube privados, como IBM Cloud® Container Registry, a través de la red privada de infraestructura de IBM Cloud. Por ejemplo, los entornos de hardware dedicados para todas las instancias del plan estándar de IBM Cloudant dan soporte a puntos finales de servicio en la nube privados. Si un servicio de IBM Cloud no da soporte a puntos finales de servicio de nube privada, el clúster no puede acceder a dicho servicio.

Comunicación externa a aplicaciones que se ejecutan en nodos de trabajo para clústeres privados

Para proporcionar acceso privado a una app del clúster, puede crear un equilibrador de carga de red (NLB) privado o un equilibrador de carga de aplicación (ALB) de Ingress. Estos servicios de red de Kubernetes solo exponen la app a la red privada de modo que cualquier sistema local con una conexión con la subred en la que está la IP de NLB pueda acceder a la app.

¿Está listo para empezar a trabajar con un clúster en este caso práctico? Después de planificar su configuración de alta disponibilidad, consulte Creación de clústeres.