Implementación de Red Hat OpenShift Service on AWS

Muchas empresas eligen Red Hat OpenShift como la plataforma común para desarrollar y ejecutar todas sus aplicaciones. Al hacerlo, evitan un entorno heterogéneo que puede generar mucha complejidad. No solo diseñan y ejecutan nuevas aplicaciones desarrolladas en la nube en Red Hat OpenShift, sino que también pueden migrar las heredadas a esta plataforma.

Una de las principales ventajas de usar OpenShift es que los desarrolladores solo deben aprender a manejar una interfaz, mientras que se abstraen los detalles fundamentales de la plataforma. Esto puede aumentar la productividad de manera considerable.

Red Hat OpenShift Service on AWS (ROSA)

Algunos de los clientes que deciden adoptar OpenShift quieren dar un paso más en la simplificación. Prefieren no tener que preocuparse por brindar la infraestructura para sus clústeres ni gestionarlos. Desean que sus equipos sean productivos desde el primer día y que solo se dediquen a desarrollar aplicaciones. Una opción para ellos es Red Hat OpenShift Service on AWS (ROSA).

ROSA se aloja por completo en la nube pública de Amazon Web Services (AWS). AWS y Red Hat se encargan de su mantenimiento de forma conjunta, lo que significa que los nodos de plano de control e informáticos están totalmente gestionados por un equipo de ingenieros de confiabilidad del sitio (SRE) de Red Hat con el soporte conjunto de Red Hat y Amazon. Esto abarca la instalación, la administración, el mantenimiento y las actualizaciones de todos los nodos.

Opciones para la implementación de ROSA

Hay dos formas principales de implementar ROSA: en un clúster público y en uno de enlace privado. En ambos casos, recomendamos implementarlos en varias zonas para obtener resistencia y alta disponibilidad. 

Los clústeres públicos se usan sobre todo para las cargas de trabajo sin requisitos de seguridad estrictos. El clúster se implementa en una nube privada virtual (VPC) dentro de una subred privada que contiene los nodos de plano de control, de infraestructura y de trabajo donde se ejecutan las aplicaciones. Sin embargo, aún se puede acceder a él desde Internet, por lo que se necesita una subred pública además de la nube privada virtual. 

Los equilibradores de carga de AWS (equilibradores de carga elásticos y de red) implementados en esta subred pública permiten que se conecten tanto el equipo de SRE como los usuarios que acceden a las aplicaciones (es decir, el tráfico de entrada al clúster). En el caso de los usuarios, un equilibrador de carga redirige el tráfico al servicio del enrutador que se ejecuta en los nodos de infraestructura, y desde allí se reenvía a la aplicación deseada que se ejecuta en uno de los nodos de trabajo. El equipo de SRE usa una cuenta de AWS exclusiva para conectarse a los nodos de control e infraestructura a través de diferentes equilibradores de carga. 

Imagen 1: Clúster público de ROSA

Para las cargas de trabajo de producción con necesidades de seguridad más estrictas, recomendamos implementar un clúster de PrivateLink. En este caso, la VPC dentro de la cual se encuentra el clúster tiene solo una subred privada, lo que significa que no se puede acceder a ella desde el Internet público. 

El equipo de SRE usa una cuenta de AWS exclusiva que se conecta a un equilibrador de carga de AWS a través de un extremo de AWS PrivateLink. El equilibrador de carga redirige el tráfico a los nodos de control o infraestructura según sea necesario, (una vez que se crea AWS PrivateLink, el cliente debe aprobar el acceso desde la cuenta de AWS del equipo de SRE). Los usuarios se conectan a un equilibrador de carga de AWS que los redirige al servicio del enrutador en los nodos de infraestructura. Desde allí, se los envía al nodo de trabajo donde se ejecuta la aplicación a la que desean acceder.

En las implementaciones de clústeres de PrivateLink, es común que los clientes quieran redirigir el tráfico de salida del clúster a su infraestructura local o a otras VPC en la nube de AWS. Para ello, pueden usar AWS Transit Gateway o AWS Direct Connect para que no haga falta implementar una subred pública en la VPC donde se encuentra el clúster. Incluso si necesitan dirigir el tráfico de salida a Internet, pueden conectarse (a través de AWS Transit Gateway) a una VPC que tenga una subred pública con una AWS NAT Gateway y una AWS Internet Gateway.

Imagen 2: Clúster privado de ROSA con PrivateLink

Tanto en las implementaciones públicas como en las de PrivateLink, el clúster puede interactuar con otros servicios de AWS mediante el uso de extremos de AWS VPC para comunicarse con la VPC donde se encuentra el clúster con los servicios deseados.

Conexión al clúster

La forma recomendada para que el equipo de SRE inicie sesión en los clústeres de ROSA y lleve a cabo las tareas de administración es usar AWS Security Token Service (STS). Debe aplicarse el concepto de privilegio mínimo para que solo se asignen las funciones que sean estrictamente necesarias para completar una tarea. El token es temporal y de un solo uso, por lo que deberá solicitarse un token nuevo si debe volver a realizarse una tarea similar después de que haya vencido.

El uso de STS se extiende a la conexión del clúster de ROSA a otros servicios de AWS, como EC2 (por ejemplo, si deben activarse servidores nuevos para el clúster) o EBS (cuando se necesita almacenamiento permanente).

Resumen

La adopción de las metodologías de DevOps y la modernización de la forma en que se implementan las aplicaciones con una plataforma empresarial de Kubernetes como OpenShift pueden aplicarse a todos los tipos de clientes. Pueden optar por alojarla en las instalaciones y gestionarla ellos mismos, pero ROSA es una opción si prefieren no hacerlo. La gran cantidad de servicios de AWS que pueden interactuar con los clústeres de ROSA permite que los clientes aprovechen al máximo la plataforma.

Más información

• Implementación de Red Hat OpenShift Service on AWS