Considerações sobre a organização de recursos para o AKS (opcional)

A consideração da organização de recursos é gerida principalmente pela base da plataforma. No entanto, eis algumas das formas como a base da plataforma pode afetar o acelerador de zonas de destino do AKS.

A estrutura geral da subscrição e do grupo de recursos determinada por recomendações genéricas de zona de destino à escala empresarial desempenhará um papel fundamental na forma como a organização de recursos do AKS é gerida. Conforme descrito em Grupo de gestão e organização de subscrição, os grupos de gestão e as subscrições são utilizados para atribuir políticas aos recursos abaixo dos mesmos e as subscrições são o limite de gestão para governação e isolamento de recursos.

Por exemplo, se tiver aplicações públicas e privadas, separe-as em diferentes subscrições, nomeadas Corp e Online, e atribua políticas diferentes a cada subscrição. As Corp subscrições têm políticas que impedem a criação de endereços IP públicos. As Online subscrições permitem a conectividade à Internet. Para obter mais informações sobre que políticas são aplicadas em que nível numa estrutura de zona de destino à escala empresarial, incluindo políticas específicas do AKS, veja Políticas incluídas em implementações de referência de zonas de destino à escala empresarial.

Considerações de design

• Decida quem irá gerir os anfitriões de contentores:

  • Se os anfitriões forem geridos centralmente, pode reduzir o número de instâncias de zona de destino e exigir que os programadores sigam os processos definidos para implementar os anfitriões e utilizar dashboards e alertas partilhados para operações ao nível da carga de trabalho.

  • Se as equipas de carga de trabalho gerirem os anfitriões, precisará de mais instâncias de zona de destino para segmentar ambientes anfitriões e permitir que as equipas de cargas de trabalho controlem as respetivas implementações.

  • Em ambos os casos, expande esta consideração para recursos adjacentes e relacionados, como firewalls de aplicações Web, cofres de chaves, agentes de compilação de pipelines e caixas potencialmente rápidas.

• Escolha um modelo de inquilinos para clusters:

  • Carga de trabalho operada, inquilino único: Um anfitrião de cluster único que suporte uma única carga de trabalho irá provavelmente precisar de uma zona de destino dedicada para permitir a segmentação e o controlo da equipa de cargas de trabalho.

  • Anfitriões multi-inquilinos operados centralmente: Quando os anfitriões são geridos centralmente, a eficiência operacional provém da consolidação de vários anfitriões e de várias cargas de trabalho em ambientes de zona de destino partilhados. Esta consolidação reduz o número de zonas de destino e anfitriões dedicados ao suporte de um único cluster ou carga de trabalho.

    Poderão ser necessárias zonas de destino adicionais se a segmentação for necessária para se separar com base na região, unidade de negócio, ambiente, criticidade ou outras restrições externas.

  • Operado centralmente, inquilino único para cargas de trabalho hostis ou reguladas que ainda são operadas centralmente, é comum ter anfitriões dedicados para essas cargas de trabalho. Poderá continuar a ter eficiência operacional ao consolidar as zonas de destino de suporte.

• Escolha uma hierarquia de grupo de gestão com base no dimensionamento geral e alinhamento de ambientes e anfitriões necessários para suportar os requisitos gerais de portefólio:

  • A estrutura simples para suportar muitos anfitriões dedicados em ambientes dedicados para operações descentralizadas é executada por cada equipa de carga de trabalho.
  • Estrutura segmentada para criar um grupo de gestão para anfitriões geridos centralmente e um grupo de gestão separado para operações descentralizadas.
  • Estrutura hierárquica mais ambientes de segmentação para refletir os requisitos operacionais, de faturação ou de governação.

• Decida qual a topologia do registo de contentor a utilizar para a distribuição de artefactos OCI:

  • Um registo por carga de trabalho.
  • Um registo por cluster com várias cargas de trabalho no registo.
  • Um registo por todos os clusters na zona de destino com várias cargas de trabalho e clusters no mesmo registo.
  • Um registo por todos os clusters em várias zonas de destino com várias cargas de trabalho e clusters no mesmo registo.

• Decida o âmbito das políticas de registo de contentor no Azure Policy:

  • Defina uma política ao nível da subscrição que exija que todos os anfitriões na zona de destino utilizem o registo definido.
  • Defina uma política mais granular ao nível do grupo de recursos.
  • Defina uma política mais ampla ao nível do grupo de gestão.

Recomendações de conceção

• Defina um padrão de nomenclatura e identificação a aplicar a todos os recursos de contentor implementados no Azure. No mínimo, deve incluir:
  • Nomes das cargas de trabalho: Identifique a carga de trabalho ou as cargas de trabalho suportadas por cada cluster.
    • Recursos do cluster: Identifique a elevação do alinhamento de recursos do cluster das considerações anteriores.
    • Operador anfitrião: Identifique que equipa é responsável pelas operações do anfitrião.
• Implemente uma política para exigir um registo de artefactos OCI específico com base na topologia do registo de contentor da sua organização.