Considérations relatives à l’organisation des ressources pour AKS (facultatif)

L’organisation des ressources est principalement gérée par la fondation de la plateforme. Voici cependant quelques-unes des façons dont la fondation peut affecter l’accélérateur de zone d’atterrissage AKS.

La conception globale des abonnements et des groupes de ressources, déterminée par les recommandations génériques relatives aux zones d’atterrissage à l’échelle de l’entreprise, jouera un rôle fondamental dans la gestion de l’organisation des ressources AKS. Comme décrit dans Groupe d’administration et organisation d’abonnement, les groupes de gestion et les abonnements permettent d’affecter des stratégies aux ressources qui leur sont subordonnées, et les abonnements constituent la limite de gestion pour la gouvernance et l’isolation des ressources.

Par exemple, si vous avez des applications publiques et privées, séparez-les en différents abonnements, appelés Corp et Online, et attribuez différentes stratégies à chaque abonnement. Les abonnements Corp comportent des stratégies qui empêchent la création d’adresses IP publiques. Les abonnements Online autorisent la connectivité Internet. Pour plus d’informations sur les stratégies appliquées à chaque niveau de la conception de zone d’atterrissage à l’échelle de l’entreprise, y compris sur les stratégies spécifiques à AKS, consultez Stratégies incluses dans les implémentations de référence des zones d’atterrissage à l’échelle de l'entreprise.

Remarques relatives à la conception

• Déterminez qui doit gérer les hôtes de conteneur :

  • Si les hôtes sont gérés de manière centralisée, vous pouvez réduire le nombre d’instances de zone d’atterrissage et demander aux développeurs de suivre des processus définis pour déployer les ordinateurs hôtes, ainsi que d’utiliser des tableaux de bord et des alertes partagés pour les opérations au niveau de la charge de travail.

  • Si les hôtes sont gérés par les équipes de charge de travail, vous avez besoin de davantage d’instances de zone d’atterrissage pour segmenter les environnements hôtes et permettre aux équipes de charge de travail de contrôler leurs déploiements.

  • Dans les deux cas, vous étendez cette approche aux ressources adjacentes et associées, telles que les pare-feu d’applications web, les coffres de clés, les agents de build de pipeline, voire les zones de rebond.

• Choisir un modèle de location pour les clusters :

  • Client unique piloté par la charge de travail  : un hôte de cluster unique prenant en charge une charge de travail unique nécessitera probablement une zone d’atterrissage dédiée pour permettre la segmentation et le contrôle de l’équipe de charge de travail.

  • Hôtes multilocataires pilotés de manière centralisée : quand les hôtes sont gérés de manière centralisée, l’efficacité opérationnelle provient de la consolidation de plusieurs hôtes et charges de travail dans des environnements de zone d’atterrissage partagés. Cette consolidation réduit le nombre de zones d’atterrissage et d’hôtes dédiés à la prise en charge d’un cluster ou d’une charge de travail uniques.

    Des zones d’atterrissage supplémentaires peuvent être nécessaires si une segmentation est requise pour séparer en fonction de la région, de l’unité commerciale, de l’environnement, de la criticité ou d’autres contraintes externes.

  • Locataire unique piloté de manière centralisée  pour des charges de travail hostiles ou réglementées qui sont encore centralisées, il est courant d’avoir des hôtes dédiés. Vous pouvez continuer à bénéficier d’une efficacité opérationnelle en consolidant les zones d’atterrissage associées.

• Choisissez une hiérarchie de groupes d’administration en fonction de l’échelle générale et de l’alignement des environnements et hôtes requis pour prendre en charge les besoins globaux du portefeuille :

  • Structure plate pour prendre en charge de nombreux hôtes dédiés dans des environnements dédiés pour les opérations décentralisées exécutées par chaque équipe de charge de travail.
  • Structure segmentée pour créer un groupe d’administration pour les hôtes gérés de manière centralisée et un groupe d’administration distinct pour les opérations décentralisées.
  • Structure hiérarchique segmentant davantage les environnements pour refléter la facturation, la gouvernance ou les exigences opérationnelles.

• Choisissez la topologie de registre de conteneurs à utiliser pour la distribution d’artefacts OCI :

  • un registre par charge de travail ;
  • un registre par cluster avec plusieurs charges de travail dans le registre ;
  • un registre pour tous les clusters de la zone d’atterrissage avec plusieurs charges de travail et clusters dans le même registre ;
  • un registre pour tous les clusters de plusieurs zones d’atterrissage avec plusieurs charges de travail et clusters dans le même registre.

• Déterminez l’étendue des stratégies de registre de conteneurs dans Azure Policy :

  • Définissez une stratégie au niveau de l’abonnement pour que tous les ordinateurs hôtes dans la zone de destination utilisent le registre défini.
  • Définissez une stratégie plus granulaire au niveau du groupe de ressources.
  • Définissez une stratégie plus large au niveau du groupe d’administration.

Recommandations de conception

• Définissez une norme de nommage et de balisage à appliquer à toutes les ressources de conteneur déployées sur Azure. Elle doit inclure au minimum les éléments suivants :
  • Noms des charges de travail : identifiez la ou les charges de travail que chaque cluster prend en charge.
    • Ressources de cluster : identifiez l’élévation de l’alignement des ressources de cluster dans les considérations précédentes.
    • Opérateur de l’hôte : identifiez l’équipe responsable des opérations de l’hôte.
• Implémentez une stratégie pour exiger un registre d’artefacts OCI spécifique basé sur la topologie du registre de conteneurs de votre organisation.