Overwegingen voor resourceorganisatie voor AKS (optioneel)

Overwegingen voor de organisatie van resources worden meestal beheerd door de platformbasis, maar hier volgen enkele manieren waarop de platformbasis van invloed kan zijn op de AKS-landingszoneversneller.

Het algemene abonnements- en resourcegroepontwerp dat wordt bepaald door algemene aanbevelingen voor landingszones op ondernemingsniveau, speelt een fundamentele rol in de manier waarop de AKS-resourceorganisatie wordt beheerd. Zoals beschreven in Beheergroep en abonnementsorganisatie, worden beheergroepen en abonnementen gebruikt om beleid toe te wijzen aan de onderliggende resources en vormen abonnementen de beheergrens voor governance en isolatie van resources.

Als u bijvoorbeeld openbare en persoonlijke toepassingen hebt, scheidt u deze in verschillende abonnementen, met de naam Corp en Online, en wijst u verschillende beleidsregels toe aan elk abonnement. De Corp abonnementen hebben beleid dat het maken van openbare IP-adressen verhindert. De Online abonnementen staan internetverbinding toe. Zie Beleidsregels die zijn opgenomen in landingszones op ondernemingsniveau voor meer informatie over welk beleid op welk niveau wordt toegepast in een landingszone op ondernemingsniveau, inclusief AKS-specifieke beleidsregels.

Overwegingen bij het ontwerpen

• Bepaal wie de containerhosts gaat beheren:

  • Als de hosts centraal worden beheerd, kunt u het aantal exemplaren van landingszones verminderen en vereisen dat ontwikkelaars gedefinieerde processen volgen voor het implementeren van de hosts en het gebruik van gedeelde dashboards en waarschuwingen voor bewerkingen op workloadniveau.

  • Als workloadteams de hosts beheren, hebt u meer landingszone-exemplaren nodig om hostomgevingen te segmenteren en workloadteams in staat te stellen hun implementaties te beheren.

  • In beide gevallen breidt u deze overweging uit naar aangrenzende en gerelateerde resources, zoals webtoepassingsfirewalls, sleutelkluizen, buildagents voor pijplijnen en mogelijk jumpboxs.

• Kies een tenancymodel voor clusters:

  • Door de workload uitgevoerd, één tenant: Voor één clusterhost die één workload ondersteunt, is waarschijnlijk een speciale landingszone vereist om segmentatie en beheer van workloadteam mogelijk te maken.

  • Centraal beheerde multitenanthosts: Wanneer hosts centraal worden beheerd, wordt de operationele efficiëntie verkregen door de consolidatie van meerdere hosts en meerdere workloads in omgevingen met gedeelde landingszones. Deze consolidatie vermindert het aantal landingszones en hosts dat is toegewezen aan de ondersteuning van één cluster of workload.

    Er kunnen extra landingszones vereist zijn als segmentatie is vereist om te scheiden op basis van regio, bedrijfseenheid, omgeving, kritiek of andere externe beperkingen.

  • Centraal beheerd, één tenant voor vijandige of gereguleerde workloads die nog steeds centraal worden beheerd, is het gebruikelijk om toegewezen hosts voor deze workloads te hebben. U kunt nog steeds operationele efficiëntie ervaren door ondersteunende landingszones te consolideren.

• Kies een beheergroephiërarchie op basis van de algemene schaal en uitlijning van omgevingen en hosts die nodig zijn om de algemene portfoliovereisten te ondersteunen:

  • Platte structuur ter ondersteuning van veel toegewezen hosts in toegewezen omgevingen voor gedecentraliseerde bewerkingen die door elk workloadteam worden uitgevoerd.
  • Gesegmenteerde structuur voor het maken van een beheergroep voor centraal beheerde hosts en een afzonderlijke beheergroep voor gedecentraliseerde bewerkingen.
  • Hiërarchische structuur om omgevingen verder te segmenteren om facturerings-, governance- of operationele vereisten weer te geven.

• Bepaal welke containerregistertopologie u wilt gebruiken voor de distributie van OCI-artefacten:

  • Eén register per workload.
  • Eén register per cluster met meerdere workloads in het register.
  • Eén register per alle clusters in de landingszone met meerdere workloads en clusters in hetzelfde register.
  • Eén register per alle clusters in meerdere landingszones met meerdere workloads en clusters in hetzelfde register.

• Bepaal het bereik voor containerregisterbeleid in Azure Policy:

  • Stel een beleid in op abonnementsniveau waarbij alle hosts in de landingszone het gedefinieerde register moeten gebruiken.
  • Stel een gedetailleerder beleid in op het niveau van de resourcegroep.
  • Stel een breder beleid in op het niveau van de beheergroep.

Ontwerpaanbeveling

• Definieer een naamgevings- en tagstandaard die moet worden toegepast op alle containerresources die in Azure zijn geïmplementeerd. Dit moet minimaal het volgende bevatten:
  • Namen van werkbelastingen: Identificeer de workload of workloads die door elk cluster worden ondersteund.
    • Clusterresources: Identificeer de uitbreiding van de uitlijning van clusterresources op basis van de voorgaande overwegingen.
    • Hostoperator: Bepaal welk team verantwoordelijk is voor de bewerkingen van de host.
• Implementeer een beleid om een specifiek OCI-artefactregister te vereisen op basis van de containerregistertopologie van uw organisatie.