How the Kubernetes Visibility Agent manages lifecycle of AKS cluster resources in ITOMIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Understand how the Kubernetes Visibility Agent performs lifecycle management of AKS cluster-related configuration items (CIs), including the following: How deleted resources are detected and marked as install_status = Absent.What happens when continuous discovery is disabled and only full discovery runs periodically.How deletions and recreations are handled when events occur between discovery cycles.Whether Informer lifecycle management behaves like traditional Discovery Patterns — for example, Azure – Get Kubernetes Clusters. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All releases Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1. Continuous discovery mode When continuous discovery is enabled, the Informer continuously monitors resource changes — creation, update, and deletion — within the Kubernetes cluster. If a resource is deleted — for example, a Pod or Namespace — its CI in the CMDB is updated to: install_status = Absent A cleanup process then removes the CI from the CMDB within a few hours. 2. Periodic (full discovery) mode If continuous discovery is disabled and full discovery runs every 24 hours or at scheduled intervals: Deleted resources are not immediately marked as Absent.On the next full discovery run, the Informer detects that the resource no longer exists and marks its CI as install_status = Absent.The CI is removed during the next cleanup job, which typically runs within a few hours of being marked absent. The following table summarizes detection and cleanup timing by discovery type. Discovery TypeResource DeletedCMDB UpdateCleanup TimingContinuousImmediate detectioninstall_status = AbsentWithin hoursPeriodic (24h)Detected on next runinstall_status = AbsentFew hours post-run 3. Handling deleted and recreated namespaces If a Namespace or Pod is deleted and recreated before the next discovery run: If the new resource has a different Kubernetes UID, it is treated as a new CI.If the UID is the same, the existing CI is updated rather than recreated. The Informer reconciles resources based on the resource UID, not the resource name alone. 4. Cluster deletion and Informer agent removal If the entire cluster and its Informer agent are deleted: On the next discovery or reconciliation cycle, the cluster CI and all related components — for example, Namespaces, Pods, and Services — are updated to install_status = Absent.The cleanup process then removes these records. If Informer data becomes stale or unavailable, the cleanup logic removes orphaned CIs based on the last known state. 5. Relationship management The Informer does not rely on Discovery Pattern lifecycle logic — for example, "related CI types" in pattern-based discovery. Instead, it uses its own lifecycle engine, which governs the following: Resource hierarchy within the cluster (Cluster → Namespace → Pod → Container)CI deletion rules based on install_statusCleanup frequency via CMDB housekeeping jobs Cluster resource hierarchy The following diagram shows the resource hierarchy managed by the Informer: Kubernetes Cluster ├── Namespaces │ ├── Pods │ │ └── Containers │ └── Services └── Persistent Volumes