Bewerken

Delen via

Microservicesarchitectuur in Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

Deze referentiearchitectuur toont een microservicestoepassing die is geïmplementeerd in Azure Kubernetes Service (AKS). Hierin wordt een eenvoudige AKS-configuratie beschreven die het startpunt kan zijn voor de meeste implementaties. In dit artikel wordt ervan uitgegaan dat u basiskennis van Kubernetes hebt. Het artikel richt zich voornamelijk op de infrastructuur en DevOps-overwegingen voor het uitvoeren van een microservicearchitectuur op AKS. Zie Microservices bouwen in Azure voor hulp bij het ontwerpen van microservices.

GitHub-logo Er is een referentie-implementatie van deze architectuur beschikbaar op GitHub.

Architectuur

Diagram met de AKS-referentiearchitectuur.

Een Visio-bestand van deze architectuur downloaden.

Als u liever een geavanceerder voorbeeld van microservices wilt zien dat is gebaseerd op de AKS-basislijnarchitectuur, raadpleegt u De architectuur van geavanceerde AKS-microservices (Azure Kubernetes Service)

Workflow

De architectuur bestaat uit de volgende onderdelen.

Azure Kubernetes Service (AKS). AKS is een beheerd Kubernetes-cluster dat wordt gehost in de Azure-cloud. Azure beheert de Kubernetes API-service en u hoeft alleen de agentknooppunten te beheren.

Virtueel netwerk. AKS maakt standaard een virtueel netwerk waarin agentknooppunten zijn verbonden. U kunt het virtuele netwerk eerst maken voor meer geavanceerde scenario's, waarmee u zaken zoals subnetconfiguratie, on-premises connectiviteit en IP-adressering kunt beheren. Zie Geavanceerde netwerken configureren in Azure Kubernetes Service (AKS) voor meer informatie.

Inkomend verkeer. Een toegangsbeheerobjectserver biedt HTTP(S)-routes naar services in het cluster. Zie de sectie API Gateway hieronder voor meer informatie.

Azure Load Balancer. Nadat u een AKS-cluster hebt gemaakt, is het cluster klaar om de load balancer te gebruiken. Zodra de NGINX-service is geïmplementeerd, wordt de load balancer geconfigureerd met een nieuw openbaar IP-adres dat voor uw ingangscontroller wordt geplaatst. Op deze manier stuurt de load balancer internetverkeer naar het inkomend verkeer.

Externe gegevensarchieven. Microservices zijn doorgaans staatloos en schrijven naar externe gegevensarchieven, zoals Azure SQL Database of Azure Cosmos DB.

Microsoft Entra-id. AKS maakt gebruik van een Microsoft Entra-identiteit voor het maken en beheren van andere Azure-resources, zoals Azure Load Balancers. Microsoft Entra-id wordt ook aanbevolen voor gebruikersverificatie in clienttoepassingen.

Azure Container Registry. Gebruik Container Registry om persoonlijke Docker-installatiekopieën op te slaan die zijn geïmplementeerd in het cluster. AKS kan worden geverifieerd met Container Registry met behulp van de Microsoft Entra-identiteit. AKS vereist geen Azure Container Registry. U kunt andere containerregisters gebruiken, zoals Docker Hub. Zorg ervoor dat uw containerregister overeenkomt met of de SLA (Service Level Agreement) voor uw workload overschrijdt.

Azure Pipelines. Azure Pipelines maken deel uit van de Azure DevOps Services en voeren geautomatiseerde builds, tests en implementaties uit. U kunt ook CI/CD-oplossingen van derden gebruiken, zoals Jenkins.

Helm. Helm is een pakketbeheerder voor Kubernetes, een manier om Kubernetes-objecten te bundelen en te generaliseren in één eenheid die kan worden gepubliceerd, geïmplementeerd, geversied en bijgewerkt.

Azure Monitor. Met Azure Monitor worden metrische gegevens en logboeken, toepassingstelemetrie en metrische platformgegevens voor de Azure-services verzameld en opgeslagen. Gebruik deze gegevens om de toepassing te bewaken, waarschuwingen, dashboards in te stellen en hoofdoorzaakanalyse van fouten uit te voeren. Azure Monitor kan worden geïntegreerd met AKS voor het verzamelen van metrische gegevens van controllers, knooppunten en containers.

Overwegingen

Ontwerpen

Deze referentiearchitectuur is gericht op microservicesarchitecturen, hoewel veel van de aanbevolen procedures van toepassing zijn op andere workloads die worden uitgevoerd op AKS.

Microservices

Een microservice is een losjes gekoppelde, onafhankelijk te implementeren code-eenheid. Microservices communiceren doorgaans via goed gedefinieerde API's en kunnen worden gedetecteerd via een vorm van servicedetectie. De service moet altijd bereikbaar zijn, zelfs wanneer de pods zich verplaatsen. Het Kubernetes Service-object is een natuurlijke manier om microservices in Kubernetes te modelleren.

API-gateway

API-gateways zijn een algemeen ontwerppatroon voor microservices. Een API-gateway bevindt zich tussen externe clients en de microservices. Het fungeert als een omgekeerde proxy, routeringsaanvragen van clients naar microservices. Het kan ook verschillende kruislingse taken uitvoeren, zoals verificatie, SSL-beëindiging en snelheidsbeperking. Zie voor meer informatie:

In Kubernetes wordt de functionaliteit van een API-gateway voornamelijk verwerkt door een ingangscontroller. De overwegingen worden beschreven in de sectie Inkomend verkeer.

Gegevensopslag

In een microservicesarchitectuur mogen services geen oplossingen voor gegevensopslag delen. Elke service moet een eigen gegevensset beheren om verborgen afhankelijkheden tussen services te voorkomen. Gegevensscheiding helpt onbedoelde koppeling tussen services te voorkomen, wat kan gebeuren wanneer services dezelfde onderliggende gegevensschema's delen. Wanneer services hun eigen gegevensarchieven beheren, kunnen ze ook het juiste gegevensarchief gebruiken voor hun specifieke vereisten.

Zie Microservices ontwerpen voor meer informatie : Overwegingen voor gegevens.

Vermijd het opslaan van permanente gegevens in lokale clusteropslag omdat deze de gegevens aan het knooppunt koppelt. Gebruik in plaats daarvan een externe service, zoals Azure SQL Database of Azure Cosmos DB. Een andere optie is om een permanent gegevensvolume te koppelen aan een oplossing met behulp van Azure Disks of Azure Files.

Zie Opslagopties voor toepassingen in Azure Kubernetes Service voor meer informatie.

Serviceobject

Het Kubernetes Service-object biedt een set mogelijkheden die overeenkomen met de microservicesvereisten voor de detectie van services:

  • IP-adres. Het serviceobject biedt een statisch intern IP-adres voor een groep pods (ReplicaSet). Wanneer pods worden gemaakt of verplaatst, is de service altijd bereikbaar op dit interne IP-adres.

  • Taakverdeling. Verkeer dat naar het IP-adres van de service wordt verzonden, wordt verdeeld over de pods.

  • Servicedetectie. Services worden interne DNS-vermeldingen toegewezen door de Kubernetes DNS-service. Dat betekent dat de API-gateway een back-endservice kan aanroepen met behulp van de DNS-naam. Hetzelfde mechanisme kan worden gebruikt voor service-naar-service-communicatie. De DNS-vermeldingen zijn ingedeeld op naamruimte, dus als uw naamruimten overeenkomen met gebonden contexten, wordt de DNS-naam voor een service natuurlijk toegewezen aan het toepassingsdomein.

In het volgende diagram ziet u de conceptuele relatie tussen services en pods. De werkelijke toewijzing aan EINDPUNT-IP-adressen en -poorten wordt uitgevoerd door kube-proxy, de Kubernetes-netwerkproxy.

Diagram met services en pods.

Inkomend verkeer

In Kubernetes kan de controller voor inkomend verkeer het API-gatewaypatroon implementeren. In dat geval werken de controller voor inkomend en inkomend verkeer samen om deze functies te bieden:

  • Routeer clientaanvragen naar de juiste back-endservices. Deze routering biedt één eindpunt voor clients en helpt om clients los te koppelen van services.

  • Voeg meerdere aanvragen samen in één aanvraag om de chattiness tussen de client en de back-end te verminderen.

  • Offloadfunctionaliteit van de back-endservices, zoals SSL-beëindiging, verificatie, IP-beperkingen of clientsnelheidsbeperking (beperking).

Met inkomend verkeer worden de configuratie-instellingen voor een proxyserver geabstraheerd. U hebt ook een toegangsbeheerobjectcontroller nodig, die de onderliggende implementatie van het toegangsbeheerobject biedt. Er zijn onder andere ingangscontrollers voor Nginx, HAProxy, Traefik en Azure-toepassing Gateway.

De toegangsbeheerobjectresource kan worden vervuld door verschillende technologieën. Als u wilt samenwerken, moeten ze worden geïmplementeerd als de ingangscontroller in het cluster. Het werkt als de edge-router of omgekeerde proxy. Een omgekeerde proxyserver is een potentieel knelpunt of single point of failure, dus implementeer altijd ten minste twee replica's voor hoge beschikbaarheid.

Voor het configureren van de proxyserver zijn vaak complexe bestanden vereist. Dit kan lastig zijn om af te stemmen als u geen expert bent. De ingangscontroller biedt dus een mooie abstractie. De controller voor inkomend verkeer heeft ook toegang tot de Kubernetes-API, zodat deze intelligente beslissingen kan nemen over routering en taakverdeling. De Nginx-ingangscontroller omzeilt bijvoorbeeld de kube-proxynetwerkproxy.

Als u echter volledige controle over de instellingen nodig hebt, kunt u deze abstractie overslaan en de proxyserver handmatig configureren. Zie Nginx of HAProxy implementeren in Kubernetes voor meer informatie.

Notitie

Voor AKS kunt u ook Azure-toepassing Gateway gebruiken met behulp van de Application Gateway-ingangscontroller (AGIC). Azure-toepassing Gateway kan laag-7-routering en SSL-beëindiging uitvoeren. Het biedt ook ingebouwde ondersteuning voor Web Application Firewall. Als uw AKS-cluster gebruikmaakt van CNI-netwerken, kan Application Gateway worden geïmplementeerd in een subnet van het virtuele netwerk van het cluster of kunnen worden geïmplementeerd in een ander virtueel netwerk dan het virtuele AKS-netwerk. De twee virtuele netwerken moeten echter worden gekoppeld. AGIC ondersteunt ook de Kubenet-netwerkinvoegtoepassing. Wanneer u de Kubenet-modus gebruikt, moet de ingangscontroller een routetabel in het subnet van Application Gateway beheren om verkeer naar pod-IP's te leiden. Zie Netwerken instellen tussen Application Gateway en AKS voor meer informatie.

Zie Overzicht van opties voor taakverdeling in Azure voor informatie over taakverdelingsservices in Azure.

TLS/SSL-versleuteling

In algemene implementaties wordt de ingangscontroller gebruikt voor SSL-beëindiging. Als onderdeel van het implementeren van de ingangscontroller moet u dus een TLS-certificaat maken. Gebruik alleen zelfondertekende certificaten voor ontwikkelings-/testdoeleinden. Zie Een HTTPS-ingangscontroller maken en uw eigen TLS-certificaten gebruiken in Azure Kubernetes Service (AKS) voor meer informatie.

Voor productieworkloads haalt u ondertekende certificaten op van vertrouwde certificeringsinstanties (CA). Zie Een ingangscontroller maken met een statisch openbaar IP-adres in Azure Kubernetes Service (AKS) voor informatie over het genereren en configureren van certificaten.

Mogelijk moet u uw certificaten ook roteren volgens het beleid van de organisatie. Zie certificaten roteren in Azure Kubernetes Service (AKS) voor meer informatie.

Naamruimten

Gebruik naamruimten om services binnen het cluster te organiseren. Elk object in een Kubernetes-cluster behoort tot een naamruimte. Wanneer u een nieuw object maakt, gaat dit standaard naar de default naamruimte. Het is echter een goede gewoonte om naamruimten te maken die beschrijvender zijn om de resources in het cluster te organiseren.

Eerst helpen naamruimten om naamconflicten te voorkomen. Wanneer meerdere teams microservices in hetzelfde cluster implementeren, met mogelijk honderden microservices, is het lastig om te beheren als ze allemaal in dezelfde naamruimte gaan. Daarnaast kunt u met naamruimten het volgende doen:

  • Pas resourcebeperkingen toe op een naamruimte, zodat de totale set pods die aan die naamruimte zijn toegewezen, het resourcequotum van de naamruimte niet kan overschrijden.

  • Beleid toepassen op naamruimteniveau, inclusief RBAC en beveiligingsbeleid.

Voor een microservicesarchitectuur kunt u de microservices ordenen in gebonden contexten en naamruimten maken voor elke gebonden context. Alle microservices met betrekking tot de context 'Order Fulfillment' kunnen bijvoorbeeld in dezelfde naamruimte worden geplaatst. U kunt ook een naamruimte maken voor elk ontwikkelteam.

Plaats nutsvoorzieningen in hun eigen afzonderlijke naamruimte. U kunt bijvoorbeeld Elasticsearch of Prometheus implementeren voor clusterbewaking of Tiller voor Helm.

Statuscontroles

Kubernetes definieert twee typen statustest die door een pod kan worden weergegeven:

  • Gereedheidstest: Geeft Kubernetes aan of de pod gereed is voor het accepteren van aanvragen.

  • Livenesstest: geeft Aan Kubernetes aan of een pod moet worden verwijderd en of een nieuw exemplaar is gestart.

Wanneer u nadenkt over tests, is het handig om te onthouden hoe een service werkt in Kubernetes. Een service heeft een labelkiezer die overeenkomt met een set pods (nul of meer). Kubernetes-belasting verdeelt verkeer naar de pods die overeenkomen met de kiezer. Alleen pods die zijn gestart en die in orde zijn, ontvangen verkeer. Als een container vastloopt, wordt de pod door Kubernetes gedood en wordt een vervanging gepland.

Soms is een pod mogelijk niet gereed om verkeer te ontvangen, ook al is de pod met succes gestart. Er kunnen bijvoorbeeld initialisatietaken zijn, waarbij de toepassing die in de container wordt uitgevoerd, dingen in het geheugen laadt of configuratiegegevens leest. Als u wilt aangeven dat een pod in orde is, maar niet gereed is voor het ontvangen van verkeer, definieert u een gereedheidstest.

Liveness-tests verwerken het geval waarin een pod nog steeds actief is, maar beschadigd is en moet worden gerecycled. Stel dat een container HTTP-aanvragen verwerkt, maar om een of andere reden vastloopt. De container loopt niet vast, maar de container heeft geen aanvragen meer verwerkt. Als u een HTTP-livenesstest definieert, reageert de test niet meer en wordt Kubernetes geïnformeerd om de pod opnieuw op te starten.

Hier volgen enkele overwegingen bij het ontwerpen van tests:

  • Als uw code een lange opstarttijd heeft, is er een gevaar dat een livenesstest een fout rapporteert voordat het opstarten is voltooid. Als u deze testfout wilt voorkomen, gebruikt u de initialDelaySeconds instelling, waardoor de test niet kan worden gestart.

  • Een livenesstest helpt niet, tenzij het opnieuw opstarten van de pod waarschijnlijk de status In orde heeft. U kunt een livenesstest gebruiken om geheugenlekken of onverwachte impasses te beperken, maar er is geen punt om een pod opnieuw te starten die onmiddellijk opnieuw mislukt.

  • Soms worden gereedheidstests gebruikt om afhankelijke services te controleren. Als een pod bijvoorbeeld afhankelijk is van een database, kan de test de databaseverbinding controleren. Deze aanpak kan echter onverwachte problemen veroorzaken. Een externe service is mogelijk tijdelijk niet beschikbaar om een of andere reden. Hierdoor mislukt de gereedheidstest voor alle pods in uw service, waardoor ze allemaal uit taakverdeling worden verwijderd en dus trapsgewijze fouten worden gemaakt. Een betere aanpak is het implementeren van verwerking van nieuwe pogingen in uw service, zodat uw service correct kan worden hersteld na tijdelijke fouten.

Resourcebeperkingen

Resourceconflicten kunnen van invloed zijn op de beschikbaarheid van een service. Definieer resourcebeperkingen voor containers, zodat één container de clusterresources (geheugen en CPU) niet kan overweldigen. Voor niet-containerbronnen, zoals threads of netwerkverbindingen, kunt u overwegen om het patroon Bulkhead te gebruiken om resources te isoleren.

Gebruik resourcequota om het totale aantal resources te beperken dat is toegestaan voor een naamruimte. Op die manier kan de front-end de back-endservices niet verhongeren voor resources of omgekeerd.

Beveiliging

Op rollen gebaseerd toegangsbeheer (RBAC)

Kubernetes en Azure hebben beide mechanismen voor op rollen gebaseerd toegangsbeheer (RBAC):

  • Azure RBAC beheert de toegang tot resources in Azure, inclusief de mogelijkheid om nieuwe Azure-resources te maken. Machtigingen kunnen worden toegewezen aan gebruikers, groepen of service-principals. (Een service-principal is een beveiligingsidentiteit die wordt gebruikt door toepassingen.)

  • Kubernetes RBAC bepaalt machtigingen voor de Kubernetes-API. Het maken van pods en het weergeven van pods zijn bijvoorbeeld acties die kunnen worden geautoriseerd (of geweigerd) aan een gebruiker via Kubernetes RBAC. Als u Kubernetes-machtigingen wilt toewijzen aan gebruikers, maakt u rollen en rolbindingen:

    • Een rol is een set machtigingen die van toepassing zijn binnen een naamruimte. Machtigingen worden gedefinieerd als werkwoorden (ophalen, bijwerken, maken, verwijderen) voor resources (pods, implementaties enzovoort).

    • Een RoleBinding wijst gebruikers of groepen toe aan een rol.

    • Er is ook een ClusterRole-object, dat vergelijkbaar is met een rol, maar van toepassing is op het hele cluster, in alle naamruimten. Als u gebruikers of groepen wilt toewijzen aan een ClusterRole, maakt u een ClusterRoleBinding.

AKS integreert deze twee RBAC-mechanismen. Wanneer u een AKS-cluster maakt, kunt u dit configureren voor het gebruik van Microsoft Entra-id voor gebruikersverificatie. Zie Microsoft Entra ID integreren met Azure Kubernetes Service voor meer informatie over het instellen hiervan.

Zodra dit is geconfigureerd, moet een gebruiker die toegang wil krijgen tot de Kubernetes-API (bijvoorbeeld via kubectl), zich aanmelden met hun Microsoft Entra-referenties.

Een Microsoft Entra-gebruiker heeft standaard geen toegang tot het cluster. Om toegang te verlenen, maakt de clusterbeheerder RoleBindings die verwijzen naar Microsoft Entra-gebruikers of -groepen. Als een gebruiker geen machtigingen heeft voor een bepaalde bewerking, mislukt deze.

Als gebruikers standaard geen toegang hebben, hoe heeft de clusterbeheerder toestemming om de rolbindingen te maken? Een AKS-cluster heeft eigenlijk twee typen referenties voor het aanroepen van de Kubernetes API-server: clustergebruiker en clusterbeheerder. De referenties van de clusterbeheerder verlenen volledige toegang tot het cluster. Met de Azure CLI-opdracht az aks get-credentials --admin worden de referenties van de clusterbeheerder gedownload en opgeslagen in uw kubeconfig-bestand. De clusterbeheerder kan deze kubeconfig gebruiken om rollen en rolbindingen te maken.

In plaats van Kubernetes-clusterrol- en RoleBinding-objecten systeemeigen te beheren in Kubernetes, heeft het de voorkeur om Azure RBAC te gebruiken voor Kubernetes-autorisatie. Dit maakt geïntegreerd beheer en toegangsbeheer mogelijk voor Azure-resources, AKS- en Kubernetes-resources. Deze Azure RBAC-roltoewijzingen kunnen het cluster of de naamruimten in het cluster richten voor meer gedetailleerd toegangsbeheer. Azure RBAC ondersteunt een beperkte set standaardmachtigingen en u kunt deze combineren met het systeemeigen Kubernetes-mechanisme voor het beheren van Rollen en RoleBindings ter ondersteuning van geavanceerde of gedetailleerdere toegangspatronen. Wanneer deze functie is ingeschakeld, worden Microsoft Entra-principals uitsluitend gevalideerd door Azure RBAC, terwijl reguliere Kubernetes-gebruikers en -serviceaccounts uitsluitend worden gevalideerd door Kubernetes RBAC.

Omdat de referenties van de clusterbeheerder zo krachtig zijn, gebruikt u Azure RBAC om de toegang tot deze referenties te beperken:

  • De rol Azure Kubernetes-serviceclusterbeheerder is gemachtigd om de referenties van de clusterbeheerder te downloaden. Alleen clusterbeheerders moeten worden toegewezen aan deze rol.

  • De gebruikersrol Azure Kubernetes Service-cluster heeft toestemming om de referenties van de clustergebruiker te downloaden. Niet-beheerders kunnen aan deze rol worden toegewezen. Deze rol geeft geen specifieke machtigingen voor Kubernetes-resources in het cluster. Hiermee kan een gebruiker alleen verbinding maken met de API-server.

Wanneer u uw RBAC-beleid definieert (zowel Kubernetes als Azure), moet u nadenken over de rollen in uw organisatie:

  • Wie kan een AKS-cluster maken of verwijderen en de beheerdersreferenties downloaden?
  • Wie kan een cluster beheren?
  • Wie kan resources binnen een naamruimte maken of bijwerken?

Het is een goede gewoonte om Kubernetes RBAC-machtigingen te bepalen op naamruimte, met behulp van Rollen en RoleBindings, in plaats van ClusterRoles en ClusterRoleBindings.

Ten slotte is er de vraag welke machtigingen het AKS-cluster heeft voor het maken en beheren van Azure-resources, zoals load balancers, netwerken of opslag. Voor het verifiëren van zichzelf met Azure-API's gebruikt het cluster een Microsoft Entra-service-principal. Als u geen service-principal opgeeft wanneer u het cluster maakt, wordt er automatisch een gemaakt. Het is echter een goede beveiligingspraktijk om eerst de service-principal te maken en de minimale RBAC-machtigingen eraan toe te wijzen. Zie Service-principals met Azure Kubernetes Service voor meer informatie.

Geheimenbeheer en toepassingsreferenties

Toepassingen en services hebben vaak referenties nodig waarmee ze verbinding kunnen maken met externe services, zoals Azure Storage of SQL Database. De uitdaging is om deze referenties veilig te houden en ze niet te lekken.

Voor Azure-resources is één optie het gebruik van beheerde identiteiten. Het idee van een beheerde identiteit is dat een toepassing of service een identiteit heeft die is opgeslagen in Microsoft Entra-id en deze identiteit gebruikt om te verifiëren met een Azure-service. Voor de toepassing of service is een service-principal gemaakt in Microsoft Entra-id en wordt geverifieerd met behulp van OAuth 2.0-tokens. De uitvoerprocescode kan transparant het token ophalen dat moet worden gebruikt. Op die manier hoeft u geen wachtwoorden of verbindingsreeks op te slaan. U kunt beheerde identiteiten in AKS gebruiken door Microsoft Entra-identiteiten toe te wijzen aan afzonderlijke pods, met behulp van Microsoft Entra Workload-ID (preview).

Momenteel ondersteunen niet alle Azure-services verificatie met behulp van beheerde identiteiten. Zie Azure-services die Ondersteuning bieden voor Microsoft Entra-verificatie voor een lijst.

Zelfs met beheerde identiteiten moet u waarschijnlijk bepaalde referenties of andere toepassingsgeheimen opslaan, of het nu gaat om Azure-services die geen ondersteuning bieden voor beheerde identiteiten, services van derden, API-sleutels, enzovoort. Hier volgen enkele opties voor het veilig opslaan van geheimen:

Het gebruik van een systeem zoals HashiCorp Vault of Azure Key Vault biedt verschillende voordelen, zoals:

  • Gecentraliseerd beheer van geheimen.
  • Ervoor zorgen dat alle geheimen at-rest worden versleuteld.
  • Gecentraliseerd sleutelbeheer.
  • Toegangsbeheer voor geheimen.
  • Controle

Container- en Orchestrator-beveiliging

Dit zijn aanbevolen procedures voor het beveiligen van uw pods en containers:

  • Bedreigingsbewaking: Bewaken op bedreigingen met behulp van Microsoft Defender for Containers (of mogelijkheden van derden). Als u containers op een virtuele machine host, gebruikt u Microsoft Defender voor servers of een mogelijkheid van derden. Daarnaast kunt u logboeken van containerbewakingsoplossing in Azure Monitor integreren met Microsoft Sentinel of een bestaande SIEM-oplossing.

  • Bewaking van beveiligingsproblemen: bewaak continu installatiekopieën en voer containers uit voor bekende beveiligingsproblemen met behulp van Microsoft Defender voor Cloud of een externe oplossing die beschikbaar is via Azure Marketplace.

  • Automatiseer patching van installatiekopieën met behulp van ACR Tasks, een functie van Azure Container Registry. Een containerinstallatiekopie is opgebouwd op basis van lagen. De basislagen omvatten de installatiekopieën van het besturingssysteem en de installatiekopieën van het toepassingsframework, zoals ASP.NET Core of Node.js. De basisinstallatiekopieën worden doorgaans upstream gemaakt van de ontwikkelaars van de toepassing en worden onderhouden door andere projectonderhouders. Wanneer deze installatiekopieën upstream worden gepatcht, is het belangrijk om uw eigen installatiekopieën bij te werken, te testen en opnieuw te implementeren, zodat u geen bekende beveiligingsproblemen achterlaat. ACR Tasks kan helpen dit proces te automatiseren.

  • Sla installatiekopieën op in een vertrouwd privéregister , zoals Azure Container Registry of Docker Trusted Registry. Gebruik een geldige toegangswebhook in Kubernetes om ervoor te zorgen dat pods alleen installatiekopieën uit het vertrouwde register kunnen ophalen.

  • Principe van minimale bevoegdheid toepassen

    • Voer containers niet uit in de modus Met bevoegdheden. De modus Bevoegd geeft een container toegang tot alle apparaten op de host.
    • Vermijd, indien mogelijk, het uitvoeren van processen als hoofdmap in containers. Containers bieden geen volledige isolatie vanuit het oogpunt van beveiliging, dus het is beter om een containerproces uit te voeren als een niet-bevoegde gebruiker.

DevOps

Deze referentiearchitectuur biedt een Azure Resource Manager-sjabloon voor het inrichten van de cloudresources en de bijbehorende afhankelijkheden. Met het gebruik van [Azure Resource Manager-sjablonen][arm-template] kunt u Azure DevOps Services gebruiken om binnen enkele minuten verschillende omgevingen in te richten, bijvoorbeeld om productiescenario's te repliceren. Hierdoor kunt u kosten besparen en de testomgeving alleen inrichten wanneer dat nodig is.

Overweeg de criteria voor isolatie van werkbelastingen te volgen om uw ARM-sjabloon te structuren. Een workload wordt doorgaans gedefinieerd als een willekeurige functionaliteitseenheid; U kunt bijvoorbeeld een afzonderlijke sjabloon voor het cluster hebben en vervolgens andere voor de afhankelijke services. Dankzij workloadisolatie kan DevOps continue integratie en continue levering (CI/CD) uitvoeren, omdat elke workload wordt gekoppeld en beheerd door het bijbehorende DevOps-team.

Overwegingen voor implementatie (CI/CD)

Hier volgen enkele doelstellingen van een robuust CI/CD-proces voor een microservicesarchitectuur:

  • Elk team kan de services bouwen en implementeren die het onafhankelijk bezit, zonder dat dit van invloed is op andere teams of deze onderbroken heeft.
  • Voordat een nieuwe versie van een service in productie wordt geïmplementeerd, wordt deze geïmplementeerd in ontwikkel-/test-/QA-omgevingen voor validatie. Kwaliteitspoorten worden in elke fase afgedwongen.
  • Een nieuwe versie van een service kan naast de vorige versie worden geïmplementeerd.
  • Er zijn voldoende beleidsregels voor toegangsbeheer aanwezig.
  • Voor workloads in containers kunt u de containerinstallatiekopieën vertrouwen die zijn geïmplementeerd in productie.

Zie CI/CD voor microservicesarchitecturen voor meer informatie over de uitdagingen.

Zie CI/CD voor microservices in Kubernetes voor specifieke aanbevelingen en aanbevolen procedures.

Kostenoptimalisatie

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Andere overwegingen worden beschreven in de sectie Kosten in Microsoft Azure Well-Architected Framework.

Hier volgen enkele punten om rekening mee te houden voor sommige van de services die in deze architectuur worden gebruikt.

Azure Kubernetes Service (AKS)

Er zijn geen kosten verbonden aan AKS in de implementatie, het beheer en de bewerkingen van het Kubernetes-cluster. U betaalt alleen voor de exemplaren van virtuele machines, opslag en netwerkresources die door uw Kubernetes-cluster worden gebruikt.

Zie de Container Services-rekenmachine om de kosten van de vereiste resources te schatten.

Azure Load Balancer

Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Binnenkomende NAT-regels zijn gratis. Er worden geen uurkosten in rekening gebracht voor de Standard Load Balancer wanneer er geen regels zijn geconfigureerd.

Zie Prijzen voor Azure Load Balancer voor meer informatie.

Azure-pipelines

Deze referentiearchitectuur maakt alleen gebruik van Azure Pipelines. Azure biedt de Azure Pipeline als een afzonderlijke service. U hebt een gratis door Microsoft gehoste taak met 1800 minuten per maand toegestaan voor CI/CD en één zelf-hostende taak met onbeperkte minuten per maand, extra taken hebben kosten. Zie Prijzen voor Azure DevOps Services voor meer informatie.

Azure Monitor

Voor Azure Monitor Log Analytics worden kosten in rekening gebracht voor gegevensopname en -retentie. Zie Prijzen voor Azure Monitor voor meer informatie.

Dit scenario implementeren

Volg de stappen in de GitHub-opslagplaats om de referentie-implementatie voor deze architectuur te implementeren.

Referentie-implementatie van AKS-microservices

Volgende stappen