Architectuur van Azure Kubernetes Service microservices (AKS)

Application Gateway

Container Registry

Kubernetes-service

Virtual Network

Deze referentiearchitectuur bespreekt verschillende configuraties die u kunt overwegen bij het uitvoeren van microservices in Azure Kubernetes Services. Onderwerpen omvatten 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 AKS-basislijn bevat informatie over infrastructuurfuncties zoals Azure Active Directory -podidentiteit (Azure AD), beperkingen voor in- en uitvoeren, resourcelimieten en andere beveiligde AKS-infrastructuurconfiguraties. Deze infrastructurele details worden niet in dit document behandeld. U wordt aangeraden vertrouwd te raken met de AKS-basislijn voordat u doorgaat met de inhoud van microservices.

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

Netwerkdiagram met het hub-spoke-netwerk met twee peered virtuele netwerken en de Azure-resources die door deze implementatie worden gebruikt.

Zie Microservicesarchitectuur op AKS als u liever wilt beginnen met een meer eenvoudig voorbeeld van microservices in AKS

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 gebruikers-knooppuntgroep en het Azure Application Gateway subnet.

Azure Private Link worden specifieke privé-IP-adressen toegewezen voor toegang tot Azure Container Registry en Key Vault privé-eindpunten binnen het AKS-systeem en het subnet van de gebruikers-knooppuntgroep.

Azure Application Gateway WAF (Web Application Firewall) maakt HTTP(S)-routes naar het AKS-cluster weer en wordt webverkeer naar de webtoepassing geseed. In deze architectuur wordt Azure Application Gateway Ingress Controller (AGIC) gebruikt als de Kubernetes-controller voor ingressen.

Azure Bastion biedt beveiligde Remote Desktop Protocol (RDP) en SSH-toegang (Secure Shell) tot VM's in de virtuele netwerken met behulp van een Secure Socket Layer (SSL), zonder dat de VM's toegankelijk moeten zijn via openbare IP-adressen.

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

Externe opslag en andere onderdelen:

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

Azure Container Registry privécontainer-afbeeldingen op die kunnen worden uitgevoerd in het AKS-cluster. AKS verifieert met Container Registry met behulp van de beheerde Azure AD-identiteit. U kunt ook andere containerregisters gebruiken, zoals Docker Hub.

Azure Cosmos DB slaat gegevens op met behulp van de open-source Azure Cosmos DB API voor MongoDB. Microservices zijn doorgaans staatloos en schrijven hun status naar externe gegevensopslag. 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 ondersteunt asynchrone berichtpatronen die gebruikelijk zijn bij microservicestoepassingen.

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

Azure Monitor verzamelt en slaat metrische gegevens en logboeken op, waaronder telemetrie van toepassingen en metrische gegevens van het Azure-platform en -service. U kunt deze gegevens gebruiken om de toepassing te bewaken, waarschuwingen en dashboards in te stellen en een hoofdoorzaakanalyse van fouten uit te voeren.

Andere onderdelen van het operations-ondersteuningssysteem (OSS) ondersteunen:

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

Azure Key Vault Secret Store CSI-provider haalt geheimen op die zijn opgeslagen in Azure Key Vault en gebruikt de stuurprogrammainterface van Secret Store CSI om ze te monteren in Kubernetes-pods.

Flux, een open en extensible continue leveringsoplossing voor Kubernetes, powered by GitOps-Toolkit.

Aanvraagstroom

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 drones. 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 ophaalplanning maakt, wijst het back-endsysteem een drone toe en waarschuwt het de gebruiker met een geschatte leveringstijd. Terwijl de levering wordt uitgevoerd, kan de klant de locatie van de drone volgen met een continu bijgewerkte ETA.

Deze aanvraagstroom implementeert de ontwerppatronen Publisher-subscriber, concurrerende consumentenen gatewayroutering in de cloud. De berichtenstroom verloopt als volgt:

Er wordt een HTTPS-aanvraag verzonden om het ophalen van een drone te plannen. De aanvragen worden via Azure Application Gateway in de opnamewebtoepassing, die wordt uitgevoerd als een in-cluster microservice in AKS.
De opnamewebtoepassing produceert een bericht en verzendt dit naar de Service Bus berichtenwachtrij.
Het back-endsysteem wijst een drone toe en waarschuwt de gebruiker. De werkstroom:
- Verbruikt berichtgegevens uit de Service Bus berichtenwachtrij.
- Verzendt een HTTPS-aanvraag naar de Delivery-microservice, die gegevens doorst Azure Cache voor Redis externe gegevensopslag.
- Verzendt een HTTPS-aanvraag naar de Drone Scheduler-microservice.
- Hiermee wordt een HTTPS-aanvraag naar de pakketmicroservice verzendt, waarmee gegevens worden door geven aan de externe MongoDB-gegevensopslag.
Een HTTPS GET-aanvraag wordt gebruikt om de leveringsstatus te retourneren. Deze aanvraag wordt via de Application Gateway in de Delivery-microservice.
De leveringsmicroservice leest gegevens uit Azure Cache voor Redis.

Aanbevelingen

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

Application Gateway Controller voor ingress (AGIC)

API Gateway-routering is een algemeen ontwerppatroon voor microservices. Een API-gateway fungeert als een omgekeerde proxy die aanvragen van clients naar microservices routeert. De Kubernetes-ingangsresource en de ingangscontroller verwerken de meeste API-gatewayfunctionaliteit door:

Clientaanvragen routeren naar de juiste back-endservices biedt één eindpunt voor clients en helpt clients los tekoppelen van services.

Het samenvoegen van meerdere aanvragen in één aanvraag om de chat tussen de client en de back-end te verminderen.
Offloading-functionaliteit, zoals SSL-beëindiging, verificatie, IP-beperkingen en clientfrequentiebeperking of beperking van de back-endservices.

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

Externe toegangsbeheerscontrollers vereenvoudigen de opname van verkeer in AKS-clusters, verbeteren de veiligheid en prestaties en besparen resources. Deze architectuur gebruikt de Azure Application Gateway Ingress Controller (AGIC) voor ingress control. Als Application Gateway om al het verkeer af te handelen, is er geen extra load balancer. Omdat pods directe verbindingen maken met Application Gateway, wordt het aantal vereiste hops verminderd, wat resulteert in betere prestaties.

Application Gateway beschikt over ingebouwde mogelijkheden voor automatisch schalen, in tegenstelling tot in-clusteringresscontrollers die moeten worden geschaald als ze een ongewenste hoeveelheid rekenbronnen verbruiken. Application Gateway laag-7-routering en SSL-beëindiging uitvoeren en heeft end-to-end Transport Layer Security (TLS) geïntegreerd met een ingebouwde WAF (Web Application Firewall).

Voor de optie voor agic-ingress 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. Voor workloads met meerdere tenants, of één cluster dat ondersteuning biedt voor ontwikkel- en testomgevingen, zijn mogelijk meer controllers voor binnenverkeer vereist.

Zero-trust-netwerkbeleid

Netwerkbeleid geeft aan hoe AKS-pods met elkaar en met andere netwerk eindpunten mogen communiceren. Standaard is al het verkeer naar en van pods toegestaan voor in- en uitverkeer. Bij het ontwerpen van de manier waarop uw microservices met elkaar en met andere eindpunten communiceren, kunt u overwegen een zero trust-principe te volgen waarbij toegang tot elke service, elk apparaat, elke toepassing of gegevensopslagplaats expliciete configuratie vereist.

Een strategie bij het implementeren van een zero-trust-beleid is het maken van een netwerkbeleid dat al het verkeer voor in- en uitverkeer naar alle pods binnen de doelnaamruimte afkeert. In het volgende voorbeeld ziet u een 'alles weigeren-beleid' dat van toepassing is op alle pods die zich in de naamruimte backend-dev 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, begint u met het definiëren van specifieke netwerkregels om verkeer van en naar elke pod in de microservice toe te staan. In het volgende voorbeeld wordt het netwerkbeleid toegepast op elke pod in de naamruimte backend-dev met een label dat overeenkomt met app.kubernetes.io/component: back-end. Het beleid keurt verkeer af tenzij het afkomstig is 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 Netwerkbeleid in de Kubernetes-documentatie voor meer informatie over Kubernetes-netwerkbeleiden aanvullende voorbeelden van mogelijk standaardbeleid.

Resourcequota

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

Rekenbronnen, zoals CPU en geheugen, of GPU's.
Storage resources, waaronder het aantal volumes of de hoeveelheid schijfruimte voor een bepaalde opslagklasse.
Aantal objecten, zoals het maximum aantal geheimen, services of taken dat kan worden gemaakt.

Zodra het cumulatieve totaal aan resourceaanvragen of limieten het toegewezen quotum overschrijdt, zijn er geen verdere implementaties meer geslaagd.

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

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

In het volgende voorbeeld ziet u een podspecificatie die resourcequotumaanvragen en -limieten in stelt:

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

Zie voor meer informatie over resourcequota:

Automatisch schalen

Kubernetes ondersteunt automatisch schalen om het aantal pods te verhogen dat is toegewezen aan een implementatie of om de knooppunten in het cluster te vergroten om het totale aantal beschikbare rekenbronnen te verhogen. Automatisch schalen is een zelf-corrigerend autonoom feedbacksysteem. Hoewel u pods en knooppunten handmatig kunt schalen, wordt met automatisch schalen de kans geminimaliseerd dat services minder resources krijgen bij hoge belastingen. Bij een strategie voor automatisch schalen moet rekening worden gehouden met zowel pods als knooppunten.

Automatisch schalen van clusters

De automatische schaalvergroting van clusters (CA) schaalt het aantal knooppunten. Stel dat pods niet kunnen worden gepland vanwege resourcebeperkingen; De automatische schaalverdedering van clusters voor meer knooppunten. 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 elke paar seconden op in behandeling zijnde 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"
},

Met de volgende regels in de ARM-sjabloon worden voorbeeldknooppunten voor het minimum en maximum voor de CA ingesteld:

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

Automatisch schalen van pods

Met de HpA (Horizontale automatische schaal aanpassen van pods) worden pods geschaald op basis van waargenomen CPU, geheugen of aangepaste metrische gegevens. Als u horizontale schaalbaarheid van pods wilt configureren, geeft u de metrische doelgegevens en het minimum- en maximum aantal replica's op in de specificatie van de Kubernetes-implementatiepod. 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 de CA de infrastructuur schaalt.

In het volgende voorbeeld worden metrische resourcegegevens voor HPA gebruikt:


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 kijkt naar de werkelijke verbruikte resources of andere metrische gegevens van het uitvoeren van pods, maar de CA voorziet knooppunten 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-load balancer verkeer naar pods die overeenkomen met een label-selector voor een service. Alleen pods die goed zijn gestart en in orde zijn, ontvangen verkeer. Als een container vast loopt, verwijdert Kubernetes de pod en wordt een vervanging gepland.

In Kubernetes kan een pod twee soorten statustests blootstellen:

De test laat Kubernetes weten of een pod is gestart en in orde is.
De gereedheidstest vertelt Kubernetes of een pod gereed is om aanvragen te accepteren.

De actiefheidstests verwerken pods die nog steeds worden uitgevoerd, maar die niet in orde zijn en moeten worden gerecycled. Als bijvoorbeeld een container voor HTTP-aanvragen vast loopt, loopt de container niet vast, maar stopt deze met het verwerken van aanvragen. De HTTP-liveness-test reageert niet meer, waardoor Kubernetes wordt informeren dat de pod opnieuw moet worden gestart.

Soms is een pod mogelijk niet gereed om verkeer te ontvangen, zelfs als de pod is gestart. De toepassing die in de container wordt uitgevoerd, voert bijvoorbeeld initialisatietaken uit. De gereedheidstest geeft aan of de pod klaar is om verkeer te ontvangen.

Microservices moeten eindpunten in hun code blootstellen die statuscontroles mogelijk maken, met vertraging en time-out die specifiek zijn afgestemd op de controles die ze uitvoeren. De HPA-formulesleutels liggen bijna exclusief buiten de fase Gereed voor een pod, dus het is essentieel dat statustests bestaan en nauwkeurig zijn.

Bewaking

In een microservicetoepassing 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 live toepassingen 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 matchen.
Bevat vaak aanvullende contextuele informatie in traceringen.

Als u services-telemetrie wilt contextualiseren met de Kubernetes-wereld, integreert u Azure Monitor-telemetrie met AKS voor het verzamelen van metrische gegevens van controllers, knooppunten en containers, evenals container- en knooppuntlogboeken. Als u .NET gebruikt, verrijkt de Application Insights for Kubernetes-bibliotheek Application Insights telemetrie met informatie over afbeeldingen, containers, knooppunt, pods, labels en replicasets.

In het volgende diagram ziet u een voorbeeld van de afhankelijkheidskaart van de toepassing die Application Insights genereert voor een telemetrie-trace van AKS-microservices:

Voorbeeld van een application Insights afhankelijkheidskaart voor een AKS-microservicestoepassing.

Zie Toepassingsbewaking voor Kubernetesvoor meer informatie over opties voor het instrumenteren van algemene talen voor application insights-integratie.

Schaalbaarheidsoverwegingen

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

Combineer automatische schalen en imperatieve of declaratief beheer van het aantal replica's niet. Gebruikers en een automatische schaalverdeder die 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 geïmplementeerd.
Een neveneffect van automatische schaalvergroting van pods is dat pods regelmatig kunnen worden gemaakt of onbeschafd, naarmate er in- en uitschaalgebeurtenissen plaatsvinden. U kunt deze effecten als volgende beperken:
- Gebruik gereedheidstests om Kubernetes te laten weten wanneer een nieuwe pod klaar is om verkeer te accepteren.
- Gebruik podonderbrekingsbudgetten om te beperken hoeveel pods tegelijk uit een service kunnen worden onbegrensd.
U kunt de VM-grootte niet wijzigen nadat u een cluster hebt aanmaken. Doe dus eerst de capaciteitsplanning om een geschikte VM-grootte voor de agentknooppunten te kiezen wanneer u het cluster maakt.
Voor multiten tenants of andere geavanceerde workloads gelden mogelijk isolatievereisten voor knooppuntpools die meer en waarschijnlijk kleinere subnetten nodig hebben. Zie Een knooppuntgroep toevoegen met een uniek subnet (preview)voor meer informatie over het maken van knooppuntgroepen met unieke subnetten, momenteel in openbare preview. Organisaties hebben verschillende standaarden voor hun hub-spoke-implementaties. Zorg ervoor dat u de richtlijnen van uw organisatie volgt.

Beheerbaarheidsoverwegingen

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

De AKS-clusterinfrastructuur beheren 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 bestaande virtuele netwerk en de Azure AD-configuratie. Door infrastructuur en workload afzonderlijk te implementeren, kunt u afzonderlijke levenscyclus- en operationele problemen aanpakken.
U kunt uw werkstroom beschouwen als een mechanisme om in een andere regio te implementeren als er sprake is van een regionale storing. Bouw de pijplijn zo dat u een nieuw cluster in een nieuwe regio kunt implementeren met parameter- en invoerwijzigingen.

Beveiligingsoverwegingen

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

Een AKS-pod verifieert zichzelf met behulp van een beheerde identiteit die is opgeslagen in Azure AD of een Azure AD-service-principal, samen met een clientgeheim. Het gebruik van een pod-identiteit verdient de voorkeur omdat er geen clientgeheim voor nodig is.
Met beheerde identiteiten kan het uitvoerproces snel Azure Resource Manager OAuth 2.0-tokens; er zijn geen wachtwoorden of verbindingsreeksen nodig. In AKS kunt u identiteiten toewijzen aan afzonderlijke pods met behulp van Azure Active Directory (Azure AD)-podidentiteit.
Aan elke service in de microservicetoepassing moet een unieke pod-identiteit worden toegewezen om RBAC-toewijzingen met de minste bevoegdheden mogelijk te maken. Wijs alleen identiteiten toe aan services waarvoor deze nodig zijn.
In gevallen waarin een toepassingsonderdeel toegang tot de Kubernetes-API vereist, moet u ervoor zorgen dat toepassingspods zijn geconfigureerd voor het gebruik van een serviceaccount met API-toegang met het juiste bereik. Zie Kubernetes-serviceaccounts beheren voor meer informatie over het configureren en beheren van kubernetes-servicesaccounts.
Niet alle Azure-services ondersteunen verificatie van gegevensvlak met behulp van Azure AD. Als u referenties of toepassingsgeheimen voor deze services wilt opslaan, voor services van derden of voor API-sleutels, gebruikt u Azure Key Vault. 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 een Key Vault als een volume. De pod kan vervolgens de Key Vault lezen, net als bij een normaal volume. Zie het project secrets-store-csi-driver-provider-azure op GitHub.

Prijzen

In de sectie Kosten in 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 voor de implementatie, het beheer en de bewerkingen van het Kubernetes-cluster. U betaalt alleen voor de VM-exemplaren, opslag- en netwerkbronnen die het cluster verbruikt. Automatische clusterschalen kan de kosten van het cluster aanzienlijk verlagen door lege of ongebruikte knooppunten te verwijderen.
Zie de Container Services-calculatorvoor een schatting van de kosten van de vereiste resources.