Consideraciones de organización de recursos para AKS (opcional)

La consideración de la organización de recursos se administra principalmente mediante la base de la plataforma; sin embargo, estas son algunas de las formas en que la base de la plataforma puede afectar al acelerador de zonas de aterrizaje de AKS.

El diseño general del grupo de recursos y suscripciones determinado por las recomendaciones genéricas de la zona de aterrizaje de escala empresarial desempeñará un papel fundamental en la forma en que se administra la organización de recursos de AKS. Como se describe en Organización de grupos de administración y suscripciones, los grupos de administración y las suscripciones se usan para asignar directivas a los recursos que se encuentran por debajo de ellos y las suscripciones son el límite de administración para la gobernanza y el aislamiento de los recursos.

Por ejemplo, si tiene aplicaciones públicas y privadas, sepárelas en distintas suscripciones, denominadas Corp y Online, y asigne distintas directivas a cada suscripción. Las suscripciones Corp tendrán directivas que impidan la creación de direcciones IP públicas. Las suscripciones Online permitirán la conectividad a Internet. Para más información sobre las directivas que se aplican a cada nivel en un diseño de zona de aterrizaje a escala empresarial, incluidas las directivas específicas de AKS, consulte Directivas incluidas en las implementaciones de referencia de zonas de aterrizaje de escala empresarial.

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 zonas de aterrizaje y requerir a los desarrolladores que sigan procesos definidos para implementar los hosts y usar paneles y alertas compartidos para las operaciones de nivel de carga de trabajo.

  • Si los equipos de carga de trabajo administran los hosts, necesitará más instancias de zonas de aterrizaje para segmentar los entornos de host y permitir que los equipos de carga de trabajo controlen sus implementaciones.

  • En ambos casos, debe ampliar esta consideración a recursos adyacentes y relacionados, como firewalls de aplicaciones web, almacenes de claves, agentes de compilación de canalizaciones y posibles jumpboxes.

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

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

  • Hosts multiinquilino, con administración centralizada: 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 entornos de zonas de aterrizaje compartidos. Esta 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.

    Es posible que se requieran zonas de aterrizaje adicionales si se necesita una segmentación para separar en función de la región, la unidad de negocio, el entorno, la importancia crítica u otras restricciones externas.

  • Inquilino único, con administración centralizada: en el caso de las cargas de trabajo hostiles o reguladas que se siguen administrando de forma centralizada, es habitual tener hosts dedicados para ellas. 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:

  • 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.
  • 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.
  • 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é topología del registro de contenedor va a utilizar para la distribución de artefactos de 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. Debería incluir como mínimo:
  • Nombres de carga de trabajo: identifique la carga o cargas de trabajo admitidas por cada clúster.
    • Recursos de clúster: identifique la elevación de la alineación de recursos de clúster en las consideraciones anteriores.
    • Operador de host: identifique 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.