Bewerken

Geavanceerde AKS-microservicesarchitectuur (Azure Kubernetes Service)

Azure Application Gateway
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Virtual Network

Deze referentiearchitectuur bevat verschillende configuraties die u moet overwegen bij het uitvoeren van microservices in Azure Kubernetes Services. Onderwerpen zijn onder andere het configureren van netwerkbeleid, automatisch schalen van pods en gedistribueerde tracering in een toepassing op basis van microservices.

Deze architectuur is gebaseerd op de AKS-basislijnarchitectuur, het aanbevolen startpunt van Microsoft voor de AKS-infrastructuur. De infrastructuurfuncties van de AKS-basislijndetails, zoals Microsoft Entra Workload-ID, beperkingen voor inkomend en uitgaand verkeer, resourcelimieten en andere beveiligde AKS-infrastructuurconfiguraties. Deze infrastructuurdetails worden niet behandeld in dit document. Het is raadzaam om vertrouwd te raken met de AKS-basislijn voordat u doorgaat met de microservices-inhoud.

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

Architectuur

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

Een Visio-bestand van deze architectuur downloaden.

Als u liever met een basisvoorbeeld voor microservices in AKS begint, raadpleegt u De microservicesarchitectuur op AKS.

Werkstroom

Met deze aanvraagstroom worden de ontwerppatronen uitgever-abonnee, concurrerende consumenten en gatewayroutering in de cloud geïmplementeerd. De berichtenstroom gaat als volgt:

  1. Er wordt een HTTPS-aanvraag ingediend om een drone af te halen. De aanvragen worden via Azure-toepassing Gateway doorgegeven aan de opnamewebtoepassing, die wordt uitgevoerd als een microservice in het cluster in AKS.

  2. De opnamewebtoepassing produceert een bericht en verzendt het naar de Service Bus-berichtenwachtrij.

  3. Het back-endsysteem wijst een drone toe en geeft de gebruiker een bericht. De werkstroom:

    • Verbruikt berichtgegevens uit de Service Bus-berichtenwachtrij.
    • Verzendt een HTTPS-aanvraag naar de Delivery-microservice, die gegevens doorgeeft aan Azure Cache voor Redis externe gegevensopslag.
    • Verzendt een HTTPS-aanvraag naar de Drone Scheduler-microservice.
    • Verzendt een HTTPS-aanvraag naar de pakketmicroservice, die gegevens doorgeeft aan externe MongoDB-gegevensopslag.

  4. Een HTTPS GET-aanvraag wordt gebruikt om de leveringsstatus te retourneren. Deze aanvraag wordt doorgegeven aan de Application Gateway in de Delivery-microservice.

  5. De leveringsmicroservice leest gegevens uit Azure Cache voor Redis.

Onderdelen

Deze architectuur maakt gebruik van de volgende Azure-onderdelen:

Azure Kubernetes Service is een Azure-aanbieding die een beheerd Kubernetes-cluster biedt. Wanneer u AKS gebruikt, wordt de Kubernetes API-server beheerd door Azure. De Kubernetes-knooppunten of -knooppuntgroepen zijn toegankelijk en kunnen worden beheerd door de clusteroperator.

De AKS-infrastructuurfuncties die in deze architectuur worden gebruikt, zijn onder andere:

Azure Virtual Networks zijn geïsoleerde en zeer veilige omgevingen voor het uitvoeren van virtuele machines (VM's) en toepassingen. Deze referentiearchitectuur maakt gebruik van een peered hub-spoke virtuele netwerktopologie. Het virtuele hubnetwerk bevat de Azure-firewall en Azure Bastion-subnetten. Het virtuele spoke-netwerk bevat de subnetten van het AKS-systeem en de gebruikersknooppuntgroep en het Azure-toepassing Gateway-subnet.

Azure Private Link wijst specifieke privé-IP-adressen toe voor toegang tot Azure Container Registry en Key Vault vanuit privé-eindpunten binnen het subnet van het AKS-systeem en de subnet van de gebruikersknooppuntgroep.

Azure-toepassing-gateway met WAF (Web Application Firewall) worden HTTP(S)-routes naar het AKS-cluster weergegeven en wordt het webverkeer naar de webtoepassing verdeeld. Deze architectuur maakt gebruik van Azure-toepassing Gateway Ingress Controller (AGIC) als de Kubernetes-controller voor inkomend verkeer.

Azure Bastion biedt beveiligde RDP-toegang (Remote Desktop Protocol) en SSH (Secure Shell) tot VM's in de virtuele netwerken met behulp van een secure socket layer (SSL), zonder dat u de VM's via openbare IP-adressen beschikbaar hoeft te maken.

Azure Firewall is een netwerkbeveiligingsservice die alle Azure Virtual Network-resources beveiligt. De firewall staat alleen goedgekeurde services en FQDN's (Fully Qualified Domain Names) toe als uitgaand verkeer.

Externe opslag en andere onderdelen:

Azure Key Vault slaat beveiligingssleutels voor AKS-services op en beheert deze.

Azure Container Registry slaat privécontainerinstallatiekopieën op die kunnen worden uitgevoerd in het AKS-cluster. AKS verifieert met Container Registry met behulp van de door Microsoft Entra beheerde identiteit. U kunt ook andere containerregisters zoals Docker Hub gebruiken.

Azure Cosmos DB slaat gegevens op met behulp van de opensource Azure Cosmos DB voor MongoDB. Microservices zijn doorgaans staatloos en schrijven hun status naar externe gegevensarchieven. Azure Cosmos DB is een NoSQL-database met opensource-API's voor MongoDB en Cassandra.

Azure Service Bus biedt betrouwbare cloudberichten als een service en eenvoudige hybride integratie. Service Bus biedt ondersteuning voor asynchrone berichtpatronen die gebruikelijk zijn voor microservicestoepassingen.

Azure Cache voor Redis voegt een cachelaag toe aan de toepassingsarchitectuur om de snelheid en prestaties voor zware verkeersbelastingen te verbeteren.

Met Azure Monitor worden metrische gegevens en logboeken verzameld en opgeslagen, waaronder toepassingstelemetrie en metrische gegevens van het Azure-platform en de service. U kunt deze gegevens gebruiken om de toepassing te bewaken, waarschuwingen en dashboards in te stellen en hoofdoorzaakanalyse van fouten uit te voeren.

Andere OSS-onderdelen (Operations Support System):

Helm, een pakketbeheerder voor Kubernetes die Kubernetes-objecten bundelt in één eenheid die u kunt publiceren, implementeren, versie en bijwerken.

Azure Key Vault Secret Store CSI-provider, haalt geheimen op die zijn opgeslagen in Azure Key Vault en gebruikt de interface voor het CSI-stuurprogramma secret store om deze te koppelen aan Kubernetes-pods.

Flux, een open en uitbreidbare oplossing voor continue levering voor Kubernetes, mogelijk gemaakt door de GitOps Toolkit.

Scenariodetails

In het voorbeeld van de Fabrikam Drone Delivery Shipping-app die in het voorgaande diagram wordt weergegeven, worden de architectuuronderdelen en procedures geïmplementeerd die in dit artikel worden besproken. In dit voorbeeld beheert Fabrikam, Inc., een fictief bedrijf, een vloot van dronevliegtuigen. Bedrijven registreren zich bij de service en gebruikers kunnen dan een aanvraag indienen om pakketjes door een drone te laten ophalen. Wanneer een klant een ophaaltijd plant, wijst het back-endsysteem een drone toe en meldt de gebruiker een geschatte levertijd. Terwijl de levering wordt uitgevoerd, kan de klant de locatie van de drone volgen met een continu bijgewerkte ETA.

Potentiële gebruikscases

Deze oplossing is ideaal voor de vliegtuig-, luchtvaart- en luchtvaartindustrie.

Aanbevelingen

Implementeer deze aanbevelingen bij het implementeren van geavanceerde AKS-microservicesarchitecturen.

Application Gateway-ingangscontroller (AGIC)

API Gateway-routering is een algemeen ontwerppatroon voor microservices. Een API-gateway fungeert als een omgekeerde proxy waarmee aanvragen van clients naar microservices worden gerouteerd. De Kubernetes-bron voor inkomend verkeer en de ingangscontroller verwerken de meeste API-gatewayfunctionaliteit door:

Clientaanvragen doorsturen naar de juiste back-endservices bieden één eindpunt voor clients en helpen clients los te koppelen van services.

  • Meerdere aanvragen samenvoegen tot één aanvraag om chatter tussen de client en de back-end te verminderen.
  • Offloading-functionaliteit zoals SSL-beëindiging, verificatie, IP-beperkingen en clientsnelheidsbeperking of beperking van de back-endservices.

De status van het AKS-cluster wordt omgezet in toepassingsspecifieke configuratie en toegepast via Azure Resource Manager.

Externe ingangscontrollers vereenvoudigen de opname van verkeer in AKS-clusters, verbeteren de veiligheid en prestaties en besparen van resources. Deze architectuur maakt gebruik van de Azure-toepassing Gateway Ingangscontroller (AGIC) voor inkomend verkeer. Als u Application Gateway gebruikt om al het verkeer af te handelen, hoeft u geen extra load balancer meer te gebruiken. Omdat pods directe verbindingen tot stand brengen met Application Gateway, wordt het aantal vereiste hops verminderd, wat resulteert in betere prestaties.

Application Gateway heeft ingebouwde mogelijkheden voor automatisch schalen, in tegenstelling tot inkomende controllers van clusters die moeten worden uitgeschaald als ze een ongewenste hoeveelheid rekenresources verbruiken. Application Gateway kan laag-7-routering en SSL-beëindiging uitvoeren en heeft end-to-end TLS (Transport Layer Security) geïntegreerd met een ingebouwde WAF (Web Application Firewall).

Voor de AGIC-optie voor inkomend verkeer moet u CNI-netwerken inschakelen wanneer u het AKS-cluster configureert, omdat Application Gateway is geïmplementeerd in een subnet van het virtuele AKS-netwerk. Workloads met meerdere tenants of één cluster dat ontwikkel- en testomgevingen ondersteunt, kunnen meer toegangsbeheerobjectcontrollers vereisen.

Zero-trust-netwerkbeleid

Netwerkbeleid geeft aan hoe AKS-pods met elkaar en met andere netwerkeindpunten mogen communiceren. Standaard is al het inkomend en uitgaand verkeer naar en van pods toegestaan. Wanneer u ontwerpt hoe uw microservices met elkaar en met andere eindpunten communiceren, kunt u overwegen om een vertrouwensprincipe te volgen waarbij toegang tot elke service, apparaat, toepassing of gegevensopslagplaats expliciete configuratie vereist.

Een strategie bij het implementeren van een beleid voor nulvertrouwen is het maken van een netwerkbeleid dat al het inkomend en uitgaand verkeer weigert naar alle pods binnen de doelnaamruimte. In het volgende voorbeeld ziet u een 'beleid weigeren' dat van toepassing is op alle pods die zich in de back-end-dev-naamruimte bevinden.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Zodra er een beperkend beleid is ingesteld, begint u specifieke netwerkregels te definiëren om verkeer naar en van elke pod in de microservice toe te staan. In het volgende voorbeeld wordt het netwerkbeleid toegepast op een pod in de back-end-dev-naamruimte met een label dat overeenkomt met app.kubernetes.io/component: back-end. Het beleid weigert verkeer, tenzij afkomstig van een pod met een label dat overeenkomt met app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Zie de Kubernetes-documentatie voor meer informatie over Kubernetes-netwerkbeleid en aanvullende voorbeelden van mogelijke standaardbeleidsregels.

Resourcequota

Resourcequota zijn een manier voor beheerders om resources te reserveren en te beperken voor een ontwikkelingsteam of project. U kunt resourcequota instellen voor een naamruimte en deze gebruiken om limieten in te stellen voor:

  • Rekenresources, zoals CPU en geheugen of GPU's.
  • Opslagbronnen, inclusief het aantal volumes of de hoeveelheid schijfruimte voor een bepaalde opslagklasse.
  • Het aantal objecten, zoals het maximum aantal geheimen, services of taken dat kan worden gemaakt.

Zodra het cumulatieve totaal van resourceaanvragen of -limieten het toegewezen quotum heeft doorgegeven, worden er geen verdere implementaties uitgevoerd.

Resourcequota zorgen ervoor dat de totale set pods die zijn toegewezen aan de naamruimte, het resourcequotum van de naamruimte niet kan overschrijden. De front-end kan de back-endservices niet verhongeren voor resources of omgekeerd.

Wanneer u resourcequota definieert, moeten alle pods die in de naamruimte zijn gemaakt, limieten of aanvragen opgeven in hun podspecificaties. Als ze deze waarden niet opgeven, wordt de implementatie geweigerd.

In het volgende voorbeeld ziet u een podspecificatie waarmee resourcequotumaanvragen en -limieten worden ingesteld:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Zie voor meer informatie over resourcequota:

Automatisch schalen

Kubernetes biedt ondersteuning voor automatisch schalen om het aantal pods te verhogen dat is toegewezen aan een implementatie of om de knooppunten in het cluster te verhogen om de totale beschikbare rekenresources te verhogen. Automatisch schalen is een zelfcorrectied autonoom feedbacksysteem. Hoewel u pods en knooppunten handmatig kunt schalen, minimaliseert automatisch schalen de kans dat services resources worden uitgehongerd bij hoge belastingen. Een strategie voor automatisch schalen moet rekening houden met zowel pods als knooppunten.

Automatische schaalaanpassing van clusters

De automatische schaalaanpassing van clusters (CA) schaalt het aantal knooppunten. Stel dat pods niet kunnen worden gepland vanwege resourcebeperkingen; de automatische schaalaanpassing van clusters richt meer knooppunten in. U definieert een minimum aantal knooppunten om het AKS-cluster en uw workloads operationeel te houden en een maximum aantal knooppunten voor intensief verkeer. De CA controleert om de paar seconden op wachtende pods of lege knooppunten en schaalt het AKS-cluster op de juiste wijze.

In het volgende voorbeeld ziet u de CA-configuratie van de ARM-sjabloon:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

De volgende regels in de ARM-sjabloonset voorbeeld van minimum- en maximumknooppunten voor de CA:

"minCount": 2,
"maxCount": 5,

Automatische schaalaanpassing van pods

Met de horizontale automatische schaalaanpassing van pods (HPA) worden pods geschaald op basis van waargenomen CPU, geheugen of aangepaste metrische gegevens. Als u horizontale schaalaanpassing van pods wilt configureren, geeft u metrische doelgegevens en het minimum en het maximum aantal replica's in de kubernetes-implementatiepodspecificatie op. Test uw services om deze getallen te bepalen.

CA en HPA werken goed samen, dus schakel beide opties voor automatisch schalen in uw AKS-cluster in. HPA schaalt de toepassing, terwijl ca de infrastructuur schaalt.

In het volgende voorbeeld worden metrische resourcegegevens ingesteld voor HPA:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA bekijkt de werkelijke verbruikte resources of andere metrische gegevens van actieve pods, maar de CA richt knooppunten in voor pods die nog niet zijn gepland. Daarom kijkt CA naar de aangevraagde resources, zoals opgegeven in de podspecificatie. Gebruik belastingstests om deze waarden af te stemmen.

Statuscontroles

Kubernetes-belasting verdeelt verkeer naar pods die overeenkomen met een labelkiezer voor een service. Alleen pods die zijn gestart en die in orde zijn, ontvangen verkeer. Als een container vastloopt, verwijdert Kubernetes de pod en plant een vervanging.

In Kubernetes kan een pod twee soorten statustest beschikbaar maken:

  • De livenesstest vertelt Kubernetes of een pod is gestart en in orde is.
  • De gereedheidstest vertelt Kubernetes of een pod gereed is voor het accepteren van aanvragen.

De liveness-tests verwerken pods die nog steeds worden uitgevoerd, maar die beschadigd zijn en moeten worden gerecycled. Als een container die HTTP-aanvragen verwerkt bijvoorbeeld vastloopt, loopt de container niet vast, maar stopt het verwerken van aanvragen. De HTTP-livenesstest reageert niet meer, waardoor Kubernetes de pod opnieuw start.

Soms is een pod mogelijk niet gereed voor het ontvangen van verkeer, ook al is de pod met succes gestart. De toepassing die in de container wordt uitgevoerd, kan bijvoorbeeld initialisatietaken uitvoeren. De gereedheidstest geeft aan of de pod gereed is voor het ontvangen van verkeer.

Microservices moeten eindpunten beschikbaar maken in hun code die statustests mogelijk maken, met vertraging en time-out die speciaal is afgestemd op de controles die ze uitvoeren. De HPA-formulesleutels zijn bijna uitsluitend uitgeschakeld in de fase Gereed op een pod, dus is het essentieel dat er statustests bestaan en nauwkeurig zijn.

Bewaking

In een microservicestoepassing is APM-bewaking (Application Performance Management) essentieel voor het detecteren van afwijkingen, het diagnosticeren van problemen en het snel begrijpen van de afhankelijkheden tussen services. Application Insights, dat deel uitmaakt van Azure Monitor, biedt APM-bewaking voor livetoepassingen die zijn geschreven in .NET Core, Node.js, Java en vele andere toepassingstalen.

Application Insights:

  • Registreert HTTP-aanvragen, inclusief latentie en resultaatcode.
  • Hiermee schakelt u standaard gedistribueerde tracering in.
  • Bevat een bewerkings-id in traceringen, zodat u alle traceringen voor een bepaalde bewerking kunt vergelijken.
  • Bevat vaak aanvullende contextuele informatie in traceringen.

Als u servicestelemetrie wilt contextualiseren met de Kubernetes-wereld, integreert u Azure Monitor-telemetrie met AKS om metrische gegevens te verzamelen van controllers, knooppunten en containers, evenals container- en knooppuntlogboeken. Als u .NET gebruikt, verrijkt de Application Insights voor Kubernetes-bibliotheek Application Insights-telemetrie met informatie over installatiekopieën, containers, knooppunten, pods, labels en replicasets.

In het volgende diagram ziet u een voorbeeld van de toepassingsafhankelijkheidstoewijzing die Application Insights genereert voor een telemetrietrace van AKS-microservices:

Example of an Application Insights dependency map for an AKS microservices application.

Zie Toepassingsbewaking voor Kubernetes voor meer informatie over opties voor het instrumenteren van veelgebruikte talen voor Application Insights-integratie.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Schaalbaarheid

Houd rekening met de volgende punten bij het plannen van schaalbaarheid.

  • Combineer automatisch schalen en imperatief of declaratief beheer van het aantal replica's niet. Gebruikers en een automatische schaalaanpassing die beide proberen het aantal replica's te wijzigen, kunnen onverwacht gedrag veroorzaken. Wanneer HPA is ingeschakeld, vermindert u het aantal replica's tot het minimale aantal dat u wilt implementeren.

  • Een neveneffect van automatische schaalaanpassing van pods is dat pods vaak kunnen worden gemaakt of verwijderd, omdat er uitschalen en inschalen gebeurtenissen plaatsvinden. U kunt deze effecten als volgt beperken:

    • Gebruik gereedheidstests om Kubernetes te laten weten wanneer een nieuwe pod gereed is om verkeer te accepteren.
    • Gebruik budgetten voor podonderbreking om te beperken hoeveel pods tegelijk uit een service kunnen worden verwijderd.

  • U kunt de VM-grootte niet wijzigen nadat u een cluster hebt gemaakt. Maak daarom de initiële capaciteitsplanning om een geschikte VM-grootte voor de agentknooppunten te kiezen wanneer u het cluster maakt.

  • Multitenant of andere geavanceerde workloads hebben mogelijk isolatievereisten voor knooppuntgroepen die meer en waarschijnlijk kleinere subnetten nodig hebben. Zie Een knooppuntgroep toevoegen met een uniek subnet voor meer informatie over het maken van knooppuntgroepen met unieke subnetten. Organisaties hebben verschillende standaarden voor hun hub-spoke-implementaties. Zorg ervoor dat u de richtlijnen van uw organisatie volgt.

Beheerbaarheid

Houd rekening met de volgende punten bij het plannen van beheerbaarheid.

  • Beheer de AKS-clusterinfrastructuur via een geautomatiseerde implementatiepijplijn. De referentie-implementatie voor deze architectuur biedt een GitHub Actions-werkstroom waarnaar u kunt verwijzen bij het bouwen van uw pijplijn.

  • Het werkstroombestand implementeert alleen de infrastructuur, niet de workload, in het al bestaande virtuele netwerk en de Microsoft Entra-configuratie. Door infrastructuur en workload afzonderlijk te implementeren, kunt u afzonderlijke levenscyclus- en operationele problemen oplossen.

  • Houd rekening met uw werkstroom als mechanisme voor implementatie in een andere regio als er een regionale fout optreedt. Bouw de pijplijn zodat u een nieuw cluster in een nieuwe regio kunt implementeren met parameter- en invoerwijzigingen.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Houd rekening met de volgende punten bij het plannen van beveiliging.

  • Een AKS-pod verifieert zichzelf met behulp van een workloadidentiteit die is opgeslagen in Microsoft Entra-id. Het gebruik van een workloadidentiteit verdient de voorkeur omdat hiervoor geen clientgeheim is vereist.

  • Met beheerde identiteiten kan het uitvoerproces snel OAuth 2.0-tokens van Azure Resource Manager ophalen; er is geen wachtwoord of verbindingsreeks nodig. In AKS kunt u identiteiten toewijzen aan afzonderlijke pods met behulp van Microsoft Entra Workload-ID.

  • Aan elke service in de microservicetoepassing moet een unieke workloadidentiteit worden toegewezen om RBAC-toewijzingen met minimale bevoegdheden te vergemakkelijken. U moet alleen identiteiten toewijzen aan services waarvoor ze zijn vereist.

  • In gevallen waarin een toepassingsonderdeel kubernetes-API-toegang vereist, moet u ervoor zorgen dat toepassingspods zijn geconfigureerd voor het gebruik van een serviceaccount met de juiste API-toegang. Zie Kubernetes-serviceaccounts beheren voor meer informatie over het configureren en beheren van een Kubernetes-serviceaccount.

  • Niet alle Azure-services ondersteunen verificatie van gegevensvlakken met behulp van Microsoft Entra-id. Gebruik Azure Key Vault om referenties of toepassingsgeheimen voor deze services op te slaan, voor services van derden of voor API-sleutels. Azure Key Vault biedt gecentraliseerd beheer, toegangsbeheer, versleuteling in rust en controle van alle sleutels en geheimen.

  • In AKS kunt u een of meer geheimen uit Key Vault koppelen als een volume. De pod kan vervolgens de Key Vault-geheimen lezen, net als een normaal volume. Zie het project secrets-store-csi-driver-provider-azure op GitHub voor meer informatie.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

  • In de sectie Kosten in het Microsoft Azure Well-Architected Framework worden kostenoverwegingen beschreven. Gebruik de Azure-prijscalculator om de kosten voor uw specifieke scenario te schatten.

  • AKS heeft geen kosten verbonden aan de implementatie, het beheer en de bewerkingen van het Kubernetes-cluster. U betaalt alleen voor de VM-exemplaren, opslag en netwerkresources die het cluster verbruikt. Automatische schaalaanpassing van clusters kan de kosten van het cluster aanzienlijk verlagen door lege of ongebruikte knooppunten te verwijderen.

  • Als u de kosten van de vereiste resources wilt schatten, raadpleegt u de Container Services-calculator.

  • Overweeg om AKS-kostenanalyse in te schakelen voor gedetailleerde kostentoewijzing van clusterinfrastructuur door kubernetes-specifieke constructies.

Volgende stappen