Compartir a través de

Consideraciones sobre la organización de recursos para Red Hat OpenShift en Azure (opcional)

  • Artículo

La organización de recursos se administra principalmente mediante la base de la plataforma. Estas son algunas formas en que la base de la plataforma podría afectar al acelerador de zonas de aterrizaje de Red Hat OpenShift en Azure.

El diseño de la suscripción y el grupo de recursos son consideraciones clave en las recomendaciones genéricas de la zona de aterrizaje de Azure. Desempeñan un papel fundamental en la administración de la organización de recursos de Red Hat OpenShift en Azure. Las suscripciones son el límite de administración para la gobernanza y el aislamiento de recursos. Como se describe en Grupo de administración y organización de suscripciones, use suscripciones y grupos de administración para asignar directivas a los recursos dentro de los límites.

Por ejemplo, si tiene aplicaciones públicas y privadas, las separa en distintas suscripciones y las coloca en los grupos de administración adecuados, denominados Corp y Online, o en otros grupos de administración debajo de las zonas de aterrizaje. Las suscripciones que residen en el grupo de administración Corp tienen directivas que impiden la creación de direcciones IP públicas. Las suscripciones que residen debajo de los grupos de administración Online permiten la conectividad a Internet y el acceso público directamente. Para más información sobre qué directivas se aplican en los distintos niveles de diseño de una zona de aterrizaje de Azure, incluidas las directivas específicas de ARO, consulte Directivas incluidas en implementaciones de referencia de zonas de aterrizaje de Azure.

Consideraciones de diseño

  • Decida quién va a administrar los hosts de contenedor:

    • Si los hosts se administran de forma centralizada, puede reducir el número de instancias de zona de aterrizaje. Requerir a los desarrolladores que sigan los procesos definidos para implementar hosts y usar paneles compartidos y alertas para las operaciones de nivel de carga de trabajo.

    • Si los equipos de carga de trabajo administran los hosts, necesita más instancias de zonas de aterrizaje para segmentar los entornos de host. Los equipos de carga de trabajo pueden controlar sus implementaciones.

    • Si los hosts se administran de forma centralizada por los equipos de carga de trabajo, amplíe esta consideración a recursos adyacentes y relacionados, como firewalls de aplicaciones web, almacenes de claves, agentes de compilación de canalización y, potencialmente, a jumpboxes.

  • Elija un modelo de inquilino para los clústeres:

    • Inquilino único, con administración de carga de trabajo de equipo: es probable que un host de clúster único que admita una sola carga de trabajo requiera una zona de aterrizaje dedicada la segmentación y el control de los equipos de carga de trabajo.

    • Plataformas tecnológicas, hosts multiinquilino: cuando los hosts se administran de forma centralizada, la eficacia operativa procede de la consolidación de varios hosts y varias cargas de trabajo en suscripciones de zonas de aterrizaje compartidas. La consolidación reduce el número de zonas de aterrizaje y hosts dedicados a la compatibilidad de un único clúster o carga de trabajo.

      Puede que tenga que añadir suscripciones a las zona de aterrizaje si se necesita una segmentación para separar las cargas de trabajo en función de la región, la unidad de negocio, el entorno, la importancia crítica u otras restricciones externas.

      Sugerencia

      Revise la sección Adaptar la arquitectura de la zona de aterrizaje de Azure para cumplir los requisitos antes de crear grupos de administración adicionales.

    • Inquilino único, con administración centralizada: en el caso de cargas de trabajo hostiles o reguladas, que se siguen administrando de forma centralizada, es habitual tener hosts dedicados para esas cargas de trabajo. Todavía puede experimentar la eficiencia operativa mediante la consolidación de zonas de aterrizaje de apoyo.

  • Elija una jerarquía de grupos de administración basada en la escala general y la alineación de los entornos y hosts necesarios para admitir los requisitos generales de la cartera:

    • Usa una estructura plana en la que se admite muchos hosts dedicados en entornos dedicados para la ejecución de operaciones descentralizadas en cada equipo de carga de trabajo.
    • Use una estructura segmentada en la que se crean un grupo de administración para hosts administrados centralmente y un grupo de administración independiente para operaciones descentralizadas.
    • Use una estructura jerárquica en la que se segmentan aún más los entornos que reflejan los requisitos operativos, de gobernanza o de facturación.

  • Decida qué registro de contenedor quiere usar:

  • Decida qué topología del registro de contenedor va a utilizar para la distribución de artefactos de Open Container Initiative (OCI):

    • Un registro por carga de trabajo.
    • Un registro por clúster con varias cargas de trabajo en el registro.
    • Un registro por todos los clústeres de la zona de aterrizaje con varias cargas de trabajo y clústeres del mismo registro.
    • Un registro por todos los clústeres de varias zonas de aterrizaje con varias cargas de trabajo y clústeres del mismo registro.

  • Decida el ámbito de las directivas del registro de contenedor en Azure Policy:

    • Establezca una directiva en el nivel de suscripción que requiera que todos los hosts de la zona de aterrizaje utilicen el registro definido.
    • Establezca una directiva más pormenorizada en el nivel de grupo de recursos.
    • Establezca una directiva más amplia en el nivel de grupo de administración.

Recomendaciones de diseño

  • Defina un estándar de nomenclatura y etiquetado que se aplique a todos los recursos de contenedor implementados en Azure. Como mínimo, el estándar debería incluir:
    • Nombres de carga de trabajo: La carga de trabajo o las cargas de trabajo que admite cada clúster.
    • Recursos de clúster: La elevación de la alineación de recursos de clúster en las consideraciones anteriores.
    • Operador de host: Qué equipo es responsable de las operaciones de host.
  • Implemente una directiva que requiera un registro de artefacto de OCI específico basado en la topología del registro de contenedor de su organización.

Pasos siguientes