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

A organização de recursos é gerenciada principalmente pela base da plataforma. No entanto, estas são algumas das maneiras em que a base da plataforma pode afetar o acelerador da zona de destino do AKS.

O design geral de assinatura e grupo de recursos determinado pelas recomendações gerais de zona de destino de escala empresarial desempenhará um papel fundamental em como a organização de recursos do AKS será gerenciada. Conforme descrito em Organização de grupo de gerenciamento e assinatura, os grupos de gerenciamento e as assinaturas são usados para atribuir políticas aos recursos abaixo deles, e as assinaturas são o limite de gerenciamento para governança e isolamento de recursos.

Por exemplo, se você tem aplicativos públicos e privados, separe-os em assinaturas diferentes, denominadas Corp e Online, e atribua políticas diferentes a cada assinatura. As assinaturas Corp têm políticas que impedem a criação de endereços IP públicos. As assinaturas Online permitem conectividade com a Internet. Para obter mais informações sobre quais políticas são aplicadas em qual nível em um design de zona de destino de escala empresarial, incluindo políticas específicas do AKS, consulte Políticas incluídas em implementações de referência de zonas de destino de escala empresarial.

Considerações sobre o design

• Decida quem gerenciará os hosts de contêiner:

  • Se os hosts forem gerenciados centralmente, você poderá reduzir o número de instâncias de zona de destino e exigir que os desenvolvedores sigam processos definidos para implantar os hosts e usar painéis e alertas compartilhados para operações no nível da carga de trabalho.

  • Se as equipes de carga de trabalho gerenciarem os hosts, você precisará de mais instâncias de zona de destino para segmentar os ambientes de host e permitir que as equipes de carga de trabalho controlem suas implantações.

  • Em ambos os casos, você estende essa consideração a recursos adjacentes e relacionados, como firewalls de aplicativos Web, cofres de chaves, agentes de build de pipeline e possíveis jump boxes.

• Escolha um modelo de locação para os clusters:

  • Operado por carga de trabalho, único locatário: um só host de cluster com suporte para uma só carga de trabalho provavelmente exigirá uma zona de destino dedicada para permitir a segmentação e o controle da equipe de carga de trabalho

  • Operado centralmente, hosts multilocatário: quando os hosts são gerenciados centralmente, a eficiência operacional vem da consolidação de vários hosts e de várias cargas de trabalho em ambientes de zona de destino compartilhados. Essa consolidação reduz o número de zonas de destino e hosts dedicados ao suporte de um só cluster ou carga de trabalho.

    Zonas de destino adicionais poderão ser necessárias se a segmentação for necessária para separar com base em região, unidade de negócios, ambiente, criticalidade ou outras restrições externas.

  • Operado centralmente, único locatário para cargas de trabalho hostis ou regulamentadas que ainda são operadas centralmente, é comum ter hosts dedicados a elas. Você ainda pode ter eficiência operacional consolidando as zonas de destino de suporte.

• Escolha uma hierarquia de grupo de gerenciamento baseada na escala geral e no alinhamento dos ambientes e hosts necessários para dar suporte aos requisitos de portfólio geral:

  • Estrutura plana para dar suporte a muitos hosts dedicados em ambientes dedicados para operações descentralizadas executadas por cada equipe de carga de trabalho.
  • Estrutura segmentada para criar um grupo de gerenciamento para hosts gerenciados centralmente e um grupo de gerenciamento separado para operações descentralizadas.
  • Estrutura hierárquica que segmenta ainda mais os ambientes para refletir requisitos de cobrança, governança ou operacionais.

• Decida qual topologia de registro de contêiner usar para distribuição de artefatos de OCI:

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

• Decida o escopo das políticas de registro de contêiner no Azure Policy:

  • Defina uma política no nível da assinatura que exija que todos os hosts na zona de destino usem o registro definido.
  • Defina uma política mais granular no nível do grupo de recursos.
  • Defina uma política mais ampla no nível do grupo de gerenciamento.

Recomendações sobre design

• Defina um padrão de nomenclatura e marcação a ser aplicado a todos os recursos de contêiner implantados no Azure. No mínimo, ele deve incluir:
  • Nomes de carga de trabalho: identifique a carga de trabalho ou as cargas de trabalho com suporte de cada cluster.
    • Recursos de cluster: identifique a elevação do alinhamento de recursos do cluster com base nas considerações anteriores.
    • Operador de host: identifique qual equipe é responsável pelas operações do host.
• Implemente uma política para exigir um registro de artefatos de OCI específico com base na topologia de registro de contêiner de sua organização.