Comunicación de trabajador a trabajador mediante subredes VPC

Antes de crear un clúster de VPC por primera vez, debes crear una subred de VPC en cada zona en la que desees implementar nodos de trabajo. Una subred de VPC es un rango específico de direcciones IP privadas (bloque de CIDR) y configura un grupo de nodos trabajadores y pods como si estuvieran conectados a la misma conexión física.

Cuando se crea un clúster, se especifica una subred de VPC existente para cada zona. Cada nodo trabajador que añada en un clúster se despliega con una dirección IP privada de la subred de VPC en dicha zona. Una vez suministrado el nodo trabajador, la dirección IP del nodo trabajador persiste tras una operación reboot, pero la dirección IP del nodo trabajador cambia después de las operaciones replace y update.

Las subredes proporcionan un canal para la conectividad entre los nodos trabajadores dentro del clúster. Además, cualquier sistema que esté conectado a cualquiera de las subredes privadas en la misma VPC puede comunicarse con los nodos trabajadores. Por ejemplo, todas las subredes de una VPC se pueden comunicar a través del direccionamiento de capa 3 privado con un direccionador de VPC incorporado. Si tiene varios clústeres que deben comunicarse entre sí, puede crear los clústeres en la misma VPC. Sin embargo, si los clústeres no necesitan comunicarse, puede lograr una mejor segmentación de la red creando los clústeres en VPC independientes. También puede crear listas de control de accesos (ACL) para las subredes de VPC para que medien en el tráfico en la red privada. Las ACL constan de reglas de entrada y de salida que definen las entradas y salidas permitidas para cada subred de VPC.

Cuando crea un clúster de VPC y habilita los puntos finales de servicio de nube pública y privada durante la creación del clúster, el punto final de servicio de nube pública se utiliza de forma predeterminada para acceder a componentes como la consola web de Red Hat OpenShift para el clúster. Para que los pods de consola establezcan una conexión pública segura sobre Internet a través del punto final de servicio público, debe habilitar una pasarela pública en cada subred de VPC en la que se despliegan los nodos trabajadores.

Cuando se crea un clúster de VPC y solo se habilita el punto final de servicio de nube privada durante la creación del clúster, el punto final de servicio de nube privada se utiliza de forma predeterminada para acceder a los componentes de Red Hat OpenShift, como la consola web de Red Hat OpenShift u OperatorHub. Debe estar conectado a la red privada de VPC, por ejemplo a través de una conexión VPN, para acceder a estos componentes o ejecutar mandatos kubectl en el clúster.

El rango predeterminado de direcciones IP para subredes de VPC es 10.0.0.0 – 10.255.255.255. Para ver una lista de rangos de direcciones IP por zona de VPC, consulte los prefijos de dirección predeterminados de VPC.

Si habilita el acceso clásico al crear la VPC, los prefijos de dirección predeterminados de acceso clásico determinan automáticamente los rangos de IP de las subredes que cree. Sin embargo, los rangos de IP predeterminados para las subredes de VPC de acceso clásico entran en conflicto con las subredes para el plano de control de Red Hat OpenShift on IBM Cloud. En su lugar, debes crear la VPC sin los prefijos de dirección predeterminados automáticos y, a continuación, crear tus propios prefijos de dirección y subredes dentro de esos rangos para tu clúster.

¿Necesita crear el clúster con subredes con un rango personalizado? Consulte esta guía sobre prefijos de direcciones personalizados. Si se usan subredes de rango personalizado para los nodos trabajadores, hay que asegurarse de que las subredes de nodos trabajadores no se solapen con la subred de pods del clúster.

No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

Cuando cree subredes de VPC para los clústeres, tenga en cuenta las siguientes características y limitaciones. Para obtener más información acerca de las subredes de VPC, consulte Características de las subredes en la VPC.

• El tamaño de CIDR predeterminado de cada subred de VPC es /24, que puede dar soporte a un máximo de 253 nodos trabajadores. Si tiene intención de desplegar más de 250 nodos trabajadores por zona en un clúster, tenga en cuenta la posibilidad de crear una subred de mayor tamaño.
• Después de crear una subred de VPC, no puede cambiarse el tamaño ni su rango de IP.
• Varios clústeres de la misma VPC pueden compartir subredes.
• Las subredes de VPC están vinculadas a una única zona o región y no pueden abarcar varias zonas o regiones.
• Después de crear una subred, no puede moverla a otra zona, región o VPC.
• Si tiene nodos de trabajador conectados a una subred existente en una zona, no puede cambiar la subred de esa zona en el clúster.
• Los rangos 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16 están prohibidos.

Comunicación de trabajador a maestro y de usuario a maestro utilizando puntos finales privados virtuales o puntos finales de servicio de nube

Red Hat OpenShift on IBM Cloud utiliza diferentes tipos de puntos de conexión de servicio para establecer una conexión entre los usuarios autorizados del clúster y los nodos de trabajo, por un lado, y el servidor maestro de Kubernetes, por otro. Los usuarios autorizados del clúster se comunican con el maestro de Kubernetes mediante puntos finales de servicio en la nube. En función de la versión del clúster, los nodos trabajadores se comunican con el maestro de Kubernetes a través de puntos finales de servicio en la nube o puntos finales privados virtuales de VPC.

Antes de crear un clúster, debe habilitar la cuenta para que utilice puntos finales de servicio. Para habilitar los puntos finales de servicio, ejecute ibmcloud account update --service-endpoint-enable true.

En los clústeres de VPC en Red Hat OpenShift on IBM Cloud, no puede inhabilitar el punto final de servicio de nube privada ni configurar un clúster solo con el punto final de servicio de nube pública.

El clúster de VPC se crea con un punto final de servicio en la nube público y privado de forma predeterminada. Para crear clústeres con nodos trabajadores que solo estén conectados a la red privada, solo debe habilitar el punto final de servicio privado durante la creación del clúster. No habilite el punto final de servicio público. Por ejemplo, para crear un clúster de VPC que solo cuente con un punto de conexión de servicio en la nube privada mediante la CLI, incluye la opción « --disable-public-service-endpoint ». Si incluyes esta opción, tu clúster se creará con routers y controladores Ingress que, de forma predeterminada, solo expondrán tus aplicaciones en la red privada. Si más adelante desea exponer apps en una red pública, debe crear manualmente direccionadores públicos y controladores de Ingress.

Comunicación de trabajador a maestro en clústeres de VPC

La comunicación de los nodos de trabajo con el maestro de « Kubernetes » utiliza, de forma predeterminada, el punto de conexión privado virtual(VPE)de la VPC. La puerta de enlace VPE de tu clúster utiliza uno de estos dos formatos de nombre de host, dependiendo de la región: CLUSTERID.vpe.private.REGION.containers.cloud.ibm.com o CLUSTERID.private.REGION.containers.cloud.ibm.com. Todo el tráfico entre los nodos de trabajo y el nodo maestro se canaliza a través de esta puerta de enlace VPE privada.

Si falla la conexión a la pasarela VPE y tu clúster tiene desactivada la protección del tráfico saliente, los nodos de trabajo recurren al punto de conexión del servicio en la nube pública. Esta solución alternativa solo se activa cuando no se puede acceder a la pasarela VPE, no durante el funcionamiento normal. Si la protección del tráfico saliente está activada, no se produce ningún recurso alternativo al punto final público.

Para garantizar la seguridad de las comunicaciones a través de los puntos finales de servicios en la nube pública y privada o VPE, Red Hat OpenShift on IBM Cloud configura automáticamente una conexión Konnectivity entre los nodos maestro y de trabajo de Kubernetes al crear el clúster. Los nodos de trabajo se comunican de forma segura con el nodo maestro mediante certificados de TLS, y el nodo maestro se comunica con los nodos de trabajo a través de la conexión de Konnectivity.

Comunicación de usuario a maestro en clústeres de VPC

Puede permitir que los usuarios autorizados del clúster se comuniquen con el nodo maestro de Kubernetes habilitando los puntos finales de servicio en la nube públicos y privados, o solo el punto final del servicio en la nube privado.

• Puntos finales de servicio en la nube privados y públicos: de forma predeterminada, todas las llamadas al nodo maestro iniciadas por los usuarios autorizados del clúster se direccionan a través del punto final de servicio en la nube público. Si los usuarios autorizados del clúster están en la red de VPC o se conectan a través de una conexión VPN de VPC, se puede acceder al nodo maestro de forma privada a través del punto final de servicio en la nube privado.
• Solo punto final de servicio en la nube privado: para acceder al nodo maestro a través del punto final de servicio en la nube privado, los usuarios del clúster autorizados deben estar en la red de VPC o deben estar conectados a una conexión VPN de VPC.

Puede proteger el acceso de red a los puntos finales de servicio de su clúster mediante restricciones basadas en el contexto. Solo se permiten a través de los puntos de conexión de servicio del clúster aquellas solicitudes autorizadas dirigidas al servidor maestro del clúster que procedan de subredes incluidas en la lista de permitidos. El uso de restricciones basadas en el contexto ayuda a evitar actividades de exploración no autorizadas. Para obtener más información, consulte Utilización de restricciones basadas en el contexto.

Comunicación entre nodos trabajadores y otros servicios o redes

Permita que los nodos trabajadores se comuniquen de forma segura con otros servicios de IBM Cloud, redes locales, otras VPC y recursos de la infraestructura clásica de IBM Cloud.

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 den soporte a puntos finales de servicio en la nube privados, como por ejemplo IBM Cloud® Container Registry, a través de la red privada. 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 mediante la pasarela pública de la subred.

Tenga en cuenta que si utiliza listas de control de accesos (ACL) para las subredes de VPC, debe crear reglas de entrada o de salida para permitir que los nodos trabajadores se comuniquen con dichos servicios.

Comunicación con recursos en centros de datos locales

Para conectar el clúster al centro de datos local, puede utilizar la VPN de IBM Cloud® Virtual Private Cloud o IBM Cloud® Direct Link.

• Para empezar con la VPN de Virtual Private Cloud, consulte Configuración de una pasarela de VPN local y Creación de una pasarela de VPN en la VPC y creación de la conexión entre la pasarela de VPN de VPC y la pasarela de VPN local. Si tiene un clúster multizona, debe crear una pasarela de VPC en una subred en cada zona en la que tenga nodos trabajadores.
• Para empezar a trabajar con Direct Link, consulte Solicitud de IBM Cloud Direct Link dedicado. En el paso 8, puede crear una conexión de red a su VPC para conectarse a la pasarela de Direct Link.

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. Puedes evitar conflictos de subredes al crear un clúster desde la CLI especificando un CIDR de subred personalizado para los pods en la opción « --pod-subnet » y un CIDR de subred personalizado 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/16y 172.20.0.0/16 están prohibidos porque están reservados para la funcionalidad de plano de control Red Hat OpenShift on IBM Cloud.

Comunicación externa a las apps que se ejecutan en nodos trabajadores

Permita las solicitudes de tráfico público o privado desde el exterior del clúster a las apps que se ejecutan en nodos trabajadores.

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 peticiones de tráfico de red privado desde fuera del clúster a las aplicaciones, hay que usar los servicios de red privados de Kubernetes como, por ejemplo, la creación de servicios LoadBalancer (equilibrador de cargas). Por ejemplo, cuando se crea un servicio LoadBalancer de Kubernetes en el clúster, se crea automáticamente un equilibrador de carga de VPC en la VPC fuera del clúster. El equilibrador de carga de VPC es multizona y direcciona las solicitudes de la app a través de los NodePorts privados que se abren automáticamente en los nodos trabajadores. Para los ALB y NLB de la VPC, se adjunta automáticamente a los equilibradores de carga un grupo de seguridad, cuyo nombre es kube-lbaas-<cluster-id>.

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 que poder acceder a sus aplicaciones desde el Internet público, puede utilizar los servicios de redes públicas. Aunque los nodos trabajadores estén conectados solo a subredes de VPC privadas, el equilibrador de carga de VPC que se crea para los servicios de red públicos puede direccionar las solicitudes públicas a la app en la red privada proporcionando a la app un URL público. Cuando se expone públicamente una app, cualquiera que tenga el URL público puede enviar una solicitud a la app.

Se pueden usar servicios de red públicos de Kubernetes como, por ejemplo, la creación de servicios LoadBalancer (equilibrador de cargas). Por ejemplo, cuando se crea un servicio LoadBalancer de Kubernetes en el clúster, se crea automáticamente un equilibrador de carga de VPC en la VPC fuera del clúster. El equilibrador de carga de VPC es multizona y direcciona las solicitudes de la app a través de los NodePorts privados que se abren automáticamente en los nodos trabajadores. Para los ALB y NLB de la VPC, se adjunta automáticamente a los equilibradores de carga un grupo de seguridad, cuyo nombre es kube-lbaas-<cluster-id>.

Casos prácticos de configuraciones de red de clúster de VPC

Ahora que se ha familiarizado con los conceptos básicos de red del clúster, consulte algunos casos prácticos en los que varias configuraciones de red de clúster de VPC pueden satisfacer las necesidades de la carga de trabajo.

Caso práctico: Ejecución de cargas de trabajo de una app de cara a Internet en un clúster de VPC

En este caso práctico, ejecutará cargas de trabajo en un clúster de VPC que resulten accesibles para las solicitudes desde Internet. El acceso público se controla mediante grupos de seguridad de modo que los usuarios finales puedan acceder a sus apps mientras se deniegan las solicitudes públicas no deseadas a sus apps. Además, los nodos trabajadores tienen acceso automático a todos los servicios de IBM Cloud que dan soporte a puntos finales de servicio en la nube privado.

Ampliar el centro de datos local a un clúster de VPC

En este caso práctico, ejecutará cargas de trabajo en un clúster de VPC. Sin embargo, desea que solo puedan acceder a estas cargas de trabajo servicios, bases de datos u otros recursos de redes privadas de un centro de datos local. Es posible que las cargas de trabajo del clúster tengan que acceder a otros servicios de IBM Cloud que dan soporte a la comunicación sobre la red privada.

Próximos pasos

Para continuar con el proceso de planificación, aprenda a proteger la información confidencial de su clúster tomando decisiones sobre el nivel de cifrado que debe configurar. Si estás listo para empezar a configurar la red, pasa a Entender la red VPC de clústeres segura por defecto.