ServiceNow Australia-release: Action Fabric en MCP-server uitgelegd
Ontdek hoe de ServiceNow MCP-server AI-agenten verbindt met beheerde ITSM-workflows, Action Fabric en veilige bedrijfsautomatisering, plus stappen voor 2026.
Read more →Cloud-CMDB · AWS · Azure · Google Cloud
Geautomatiseerde cloud-CMDB en dependency mapping voor Kubernetes-omgevingen
Uw Kubernetes- en cloudomgeving verandert elke dag, en een CMDB die u met de hand bijhoudt, is verouderd bij de volgende deployment. SMC Consulting zet automatische dependency mapping op: open-source discovery brengt uw clusters op AWS, Azure of Google Cloud in kaart, een graaf toont wat van wat afhangt, en de HaloITSM-CMDB blijft actueel zonder handmatige invoer.
180ITSM-implementaties
40+ITSM-migraties
20jaar ervaring in IT-servicemanagement
Zij vertrouwen ons hun ITSM-projecten toe
Waarom de cloud de handmatige CMDB breekt
In een Kubernetes-omgeving worden pods bij elke deployment vervangen, schalen nodes op en af, en volgen load balancers en DNS-records. Een CMDB die met de hand gevuld wordt, beschrijft het platform van vorige maand: de configuratie-items (CI's) zijn verouderd, de relaties ontbreken en de impactanalyse waarop uw incident- en changeteams rekenen, geeft het verkeerde antwoord.
Een cloud-CMDB moet door de cloud zelf gevoed worden. Dependency mapping leest uw accounts en clusters, legt elke resource vast als CI en bewaart de koppelingen ertussen, van de pod naar zijn namespace, zijn cluster en de nodes waarop hij draait. Valt er iets uit, dan ziet u welke diensten erop steunen; staat er een change gepland, dan ziet u wat die raakt.
Voor de CMDB zelf, het datamodel en de ITIL-practice erachter, zie CMDB en configuratiebeheer in HaloITSM. Deze pagina behandelt het cloud- en Kubernetes-deel.
De cloud-CMDB is een onderdeel van IT-servicemanagement (ITSM): de configuratiedata waarop incidenten en changes steunen. Verhuist u workloads naar de cloud? Ons projectmanagement voor IT-infrastructuur houdt de CMDB gelijk met de migratie.
Wat een geautomatiseerde cloud-CMDB u oplevert
Een CMDB die overeenkomt met wat draait
CI's en relaties worden door discovery geschreven, niet ingetypt: nieuwe resources verschijnen, verwijderde verdwijnen, bij elke synchronisatie.
Impactanalyse voor changes en incidenten
Agents en changemanagers zien de diensten achter een node of namespace voordat ze ingrijpen, in HaloITSM.
Assetbewijs voor NIS2
Een inventaris van cloudassets met hun afhankelijkheden, klaar wanneer een auditor of toezichthouder erom vraagt.
Minder handwerk
Niemand werkt CI-records bij na elke deployment; het team bekijkt uitzonderingen in plaats van data in te typen.
Bekijk het op uw eigen cloudaccount
Een live demo op een van uw clusters: wij draaien de discovery en tonen de graaf en de CI's die hij in HaloITSM aanmaakt.
Wat er ontdekt wordt: van clusters tot pods
De discovery gebruikt Cartography, een open-sourceproject van de Cloud Native Computing Foundation (CNCF). Het leest uw cloudaccounts en clusters met alleen-lezen toegang en legt vast wat het vindt.
Kubernetes-clusters
EKS-, AKS- en GKE-clusters, met hun versie, regio en het account of de subscription waartoe ze behoren.
Nodes en node pools
De machines waarop elke cluster draait, zodat een falende node de workloads toont die hij draagt.
Namespaces, pods en workloads
Namespaces, pods, services, deployments en ingress, gelezen via de kubeconfig van de cluster.
Virtuele machines
Compute-instances buiten Kubernetes, in dezelfde graaf als de clusters.
Netwerken
VPC's en virtuele netwerken, zodat u ziet welke resources een netwerkgrens delen.
Load balancers en DNS-records
De toegangspunten van uw diensten, gekoppeld aan wat erachter zit.
AWS, Azure en Google Cloud: Ă©Ă©n methode, drie clouds
- AWS: EKS-clusters en hun nodes, EC2-virtuele machines, VPC's, load balancers en DNS-records.
- Microsoft Azure: AKS-clusters, virtuele machines en netwerken.
- Google Cloud: GKE-clusters, compute-instances en netwerken.
- Binnen elke cluster: de Kubernetes-module van Cartography leest elke cluster via zijn kubeconfig (namespaces, pods, services, nodes, workloads, ingress), zodat de binnenkant van een AKS- of GKE-cluster net als EKS in kaart komt.
Wij draaien deze opzet zelf op AWS. Op Azure en Google Cloud maken dezelfde modules deel uit van de code van Cartography; wij valideren de scope op uw account tijdens de live demo.
Bekijk de afhankelijkheidsgraaf: Neo4j en HaloITSM
Een graaf waarop u klikt
Neo4j, een grafendatabase, bevat de hele omgeving. Klik op een cluster, een node of een load balancer en u ziet alles wat ervan afhangt, zonder Ă©Ă©n tabel te lezen.
Relaties in de HaloITSM-CMDB
De connector schrijft de CI's en hun relaties (pod → namespace → cluster → nodes) naar HaloITSM, waar agents en changemanagers al werken.
Alerts op de juiste CI
Uw monitoringtool (Zabbix, Prometheus…) opent een HaloITSM-ticket gekoppeld aan de getroffen CI, met de logs.
Zo werkt het in 4 stappen: ontdekken, in kaart brengen, synchroniseren, handelen
Vier stappen die volgens een planning lopen. De eerste run gebeurt tijdens de live demo, op een cluster naar keuze.
Ontdekken
Cartography scant het cloudaccount: Kubernetes-clusters (EKS, AKS, GKE), nodes, VPC's, namespaces, pods, virtuele machines, load balancers en DNS-records.
In kaart brengen
De data gaat naar Neo4j, een grafendatabase. U ziet de hele omgeving als graaf en klikt op elk element om te zien wat ervan afhangt.
Synchroniseren
Een connector schrijft CI's en hun relaties naar de HaloITSM-CMDB en houdt ze actueel: nieuwe resources verschijnen, verwijderde verdwijnen.
Handelen
Alerts uit uw monitoringtool (Zabbix, Prometheus…) openen HaloITSM-tickets gekoppeld aan de CI, met logs. Een korte alert die vanzelf verdwijnt, sluit zijn ticket; alleen echte problemen blijven open.
Wij gebruiken het zelf
- Onze eigen AWS-omgeving: de opzet draait sinds 1 september 2026 op onze infrastructuur.
- Ongeveer 295 CI's in onze HaloITSM-CMDB komen uit discovery, met hun relaties, niet uit handmatige invoer.
- Vier keer per dag gesynchroniseerd: nieuwe pods, nodes en services verschijnen zonder dat iemand de CMDB aanraakt.
- Alerts worden tickets op de juiste CI: korte alerts die vanzelf verdwijnen, sluiten vanzelf.
Voor wie
Platform- en cloudteams op Kubernetes
Die willen dat de servicedesk dezelfde omgeving ziet die zij beheren, zonder een tweede inventaris bij te houden.
IT-managers met HaloITSM
Wier CMDB laptops en servers dekt, maar stopt waar de cloud begint.
Organisaties die zich voorbereiden op NIS2
Die moeten tonen welke cloudassets welke diensten ondersteunen, en wie de eigenaar is.
Werkt samen met Lansweeper en NetBox
Cloud en Kubernetes zijn Ă©Ă©n bron naast andere. Toestellen op uw netwerk komen uit Lansweeper, dat HaloITSM voedt via de HaloITSM- en Lansweeper-integratie; datacenter- en IP-adresdata kunnen uit NetBox komen (DCIM en IPAM). Elke bron sluit op dezelfde manier aan op dezelfde configuratiedatabase, met Ă©Ă©n gezaghebbende bron per CI-klasse. Onze dienst IT asset management brengt ze samen.
Cloud-CMDB en dependency mapping: veelgestelde vragen
Wat is dependency mapping in een CMDB?
Dependency mapping legt vast hoe configuratie-items van elkaar afhangen: welke pods in welke namespace draaien, op welke cluster en welke nodes, achter welke load balancer. Met die relaties in de CMDB toont een incident de getroffen diensten en een change wat hij raakt.
Kan een CMDB zichzelf bijwerken vanuit Kubernetes?
Ja, wanneer discovery haar voedt. Cartography leest de clusters en cloudaccounts volgens een planning, en de connector schrijft het resultaat naar de HaloITSM-CMDB: nieuwe resources worden toegevoegd, verwijderde uit gebruik genomen. Het team bekijkt uitzonderingen in plaats van data in te voeren.
Wat is Cartography en wat kost het?
Cartography is een open-sourceproject van de CNCF dat cloud- en Kubernetes-resources in een graaf in kaart brengt. De software is gratis te gebruiken. De kost zit in de opzet en het draaien van de discovery, die wij met u afbakenen.
Waarom Neo4j gebruiken voor een CMDB?
Een grafendatabase bewaart relaties als volwaardige data, precies wat dependency mapping nodig heeft: vragen wat van een node afhangt, is Ă©Ă©n query, geen reeks tabeljoins. Neo4j bevat de ontdekte graaf; HaloITSM blijft de CMDB waarin uw agents en changemanagers werken.
Werkt het ook op Azure AKS en Google GKE, niet alleen op AWS?
Ja. Cartography heeft modules voor Azure (AKS-clusters, virtuele machines en netwerken) en Google Cloud (GKE-clusters, compute-instances en netwerken), en de Kubernetes-module leest elke cluster via zijn kubeconfig. Wij draaien de opzet zelf op AWS en valideren de scope op uw account tijdens de demo.
Kunnen monitoringalerts automatisch HaloITSM-tickets aanmaken?
Ja. Uw monitoringtool (Zabbix, Prometheus…) stuurt zijn alerts naar HaloITSM, dat een ticket opent gekoppeld aan de getroffen CI, met de logs erbij. Een korte alert die vanzelf verdwijnt, sluit zijn eigen ticket, zodat alleen echte problemen open blijven. Zie ITSM-automatisering en -orkestratie.
Breng uw cloud in kaart in HaloITSM
Boek een live demo op uw eigen cloudaccount: wij draaien de discovery op een cluster naar keuze en tonen de CI's en relaties die hij aanmaakt.
Recente artikelen
De HaloITSM CMDB automatisch vullen met Lansweeper discovery-data
Ontdek hoe een HaloITSM Lansweeper-integratie discovery-data koppelt aan HaloITSM voor zuiverdere CMDB-records, snellere triage en betere change-beslissingen.
Read more →
ServiceNow migratie cutover-plan: data, integraties en risicobeheer
Een praktisch ServiceNow migratie cutover-plan helpt risico's te beperken, de servicecontinuĂŻteit te beschermen en een zelfverzekerde ITSM-modernisering te ondersteunen.
Read more →