AKS managed Container Insights extension conflict recurs despite terminal metadata

Question

AKS managed Container Insights extension conflict recurs despite terminal metadata

joao neves 0

In a nonproduction AKS cluster, a start operation failed with CreateOrUpdateExtensionFailed for aks-managed-azure-monitor-logs (microsoft.azuremonitor.containers), reporting a conflicting operation in progress. In a later separately controlled attempt, two extension observations a minute apart showed Succeeded with empty statuses and the latest cluster operation was terminal. Startup succeeded, but a subsequent cluster configuration update failed with the same extension conflict; normal stop then refused while the cluster was Failed. A separately reviewed no-configuration-change reconciliation eventually allowed stop. The cluster is now intentionally stopped.

What supported read-only observations can identify the actual conflicting backend operation, and what data-preserving recovery direction should be reviewed before another start? We have not edited the managed core extension, toggled monitoring, aborted an operation, removed policies/locks or repaired managed nodes. We want to preserve monitoring, identities, network restrictions and persistent data. Basic support is active; purchasing technical support is outside the project's spending policy. Please provide general guidance without asking us to post private resource IDs or workload logs publicly.

joao neves 0 Reputation points

2026-10-17T09:38:17.3633333+00:00

Update: a later AKS start and stop both completed successfully, but a subsequent read while the cluster was stopped reported the managed Container Insights extension as Failed / InstallationFailed, with an agent-response timeout. We therefore refused another start and left monitoring configuration unchanged. The managed-cluster operation history returned 50 terminal operations with no continuation link, and the failed update detail repeats the extension-conflict error without identifying its conflicting operation. The latest operation is the successful stop. Is this stopped-cluster extension failure expected after startup/stop, and what read-only evidence or supported recovery can distinguish an offline agent timeout from an actual unresolved core-extension operation?
kagiyama yutaka 5,655 Reputation points

2026-10-17T12:10:40.4266667+00:00

Thanks for the update.InstallationFailed while stopped doesn't distinguish an offline agent from an unresolved extension issue.

The 50 terminal operations didn't identify the conflict. Run az aks operation list -g <rg> -n <aks> --active-only and compare timestamps with Activity Log. An empty result doesn't rule out an extension issue. Keep the cluster stopped and monitoring unchanged.

2 answers

Your answer

joao neves 0 Reputation points

2026-10-17T09:38:17.3633333+00:00

Update: a later AKS start and stop both completed successfully, but a subsequent read while the cluster was stopped reported the managed Container Insights extension as Failed / InstallationFailed, with an agent-response timeout. We therefore refused another start and left monitoring configuration unchanged. The managed-cluster operation history returned 50 terminal operations with no continuation link, and the failed update detail repeats the extension-conflict error without identifying its conflicting operation. The latest operation is the successful stop. Is this stopped-cluster extension failure expected after startup/stop, and what read-only evidence or supported recovery can distinguish an offline agent timeout from an actual unresolved core-extension operation?
kagiyama yutaka 5,655 Reputation points

2026-10-17T12:10:40.4266667+00:00

Thanks for the update.InstallationFailed while stopped doesn't distinguish an offline agent from an unresolved extension issue.

The 50 terminal operations didn't identify the conflict. Run az aks operation list -g <rg> -n <aks> --active-only and compare timestamps with Activity Log. An empty result doesn't rule out an extension issue. Keep the cluster stopped and monitoring unchanged.

Answer 1

I think Succeeded on the managed extension and a terminal AKS operation still don't identify the conflicting operation.

Before another start, run az aks operation list -g <rg> -n <aks> and inspect the failed update with az aks operation show -g <rg> -n <aks> --operation-id <id>. Compare UTC timestamps, errors and correlation IDs with Activity Log.

If those records don't expose the blocker, leave the cluster stopped and monitoring unchanged rather than repeating reconciliation or resetting the add-on. Basic support doesn't cover technical cases, so deeper investigation would require an eligible support plan.

Answer 2

Supported read-only observations to review before another start:

Check the AKS cluster activity log for the failed and later successful operations.
- In Azure portal, open Activity log.
- Find entries for Start Managed Cluster and the later cluster configuration update.
- Expand failed operations and inspect the suboperations.
- Review the JSON field for the failed suboperations, because it usually contains the most helpful error details.
- This is the supported place in the provided guidance to identify what operation actually failed and whether policy-related suboperations were involved.
Verify the monitoring extensions state without attempting any modification.
- In Azure portal, go to the AKS cluster.
- Open Settings > Extensions + applications.
- Confirm the monitoring extensions are listed.
- Confirm each extension shows Provisioning State = Succeeded.
- For the managed Container Insights extension, direct editing is not supported even if the cluster reports extension-related failures.
Check for resource locks as a read-only validation.
- Locks at subscription, resource group, or cluster scope can block monitoring add-on management operations.
- In Azure portal, review Settings > Locks at the cluster, resource group, and subscription scopes.
- With Azure CLI, read-only checks are:
```
     az lock list --resource-group <resource-group> \
       --resource-name <cluster-name> \
       --resource-type Microsoft.ContainerService/managedClusters
     
     az lock list --resource-group <resource-group>
     
     az lock list
```
- This preserves the current state and helps determine whether a lock is blocking extension management behind the cluster operation.
Check whether Azure Policy is blocking extension operations.
- The documented cause for monitoring add-on enable or deployment failures includes deny policies, allowed-extension allowlists, naming policies, and tag enforcement.
- In Azure portal, open Policy > Assignments and compare any assignment names shown in the activity log error details.
- This is especially relevant when the extension itself later appears as Succeeded but a cluster operation still reports CreateOrUpdateExtensionFailed.
Use Azure Monitor and AKS diagnostic tooling only for correlation, not for changing state.
- Azure Monitor can help compare the failure time with cluster or workload changes.
- If deeper node or workload context is needed, az aks kollect can collect diagnostic information through AKS Periscope.

Data-preserving recovery direction to review before another start:

Do not try to update or edit aks-managed-azure-monitor-logs directly. Managed monitoring extensions are controlled by the AKS resource provider, and direct write operations are expected to be denied.
Prefer read-only validation first: activity log details, extension provisioning state, locks, and policy assignments.
If a blocking lock or policy is confirmed, review temporary removal or exemption only for the minimum scope and duration needed, then reapply protection afterward. Removing locks changes protection state, so this should be coordinated carefully.
If monitoring configuration is suspected to be inconsistent, the documented recovery path is to disable and then re-enable the monitoring add-on on the AKS cluster. That is the supported recovery direction in the provided guidance, but it is a configuration change and should be reviewed carefully because the goal is to preserve monitoring configuration and protections.
Since the cluster is intentionally stopped and a no-configuration-change reconciliation eventually cleared the stop path, the safest next step from the provided guidance is evidence collection from Activity log and policy/lock review before any new start attempt.

If the extension remains Succeeded and the cluster still reports recurring extension conflicts on later operations, the provided guidance supports treating this as an AKS-managed monitoring add-on management issue rather than a direct extension-edit issue. The documented escalation path in the provided material is to open a support ticket with the respective service for extension issues.