Azure Container Apps deployment: resolving "Maximum Allowed Cores exceeded for the Managed Environment" - Stac

admin管理员组

文章数量:1384646

I'm in the process of setting up a deployment pipeline for an Azure Container App (ACA) within an Azure Container Environment (ACE). My ACE is configured with a "D4" workload profile (4 vCPU, 16Gi memory), as detailed in the documentation here. The ACA application is monolithic and fully utilizes the available resources of 4 CPUs and 16Gi memory. It is designed to run as a single instance/replica (min 1; max 2; no scaling rules). The maximum is set to 2 instances to allow running two instances simultaneously during a rolling update.

Here is a snippet of the ACA deployment yaml:

  template:
    containers:
    - image: private.registry.name/image-name:1.2.3
      name: some-name
      resources:
        cpu: 4
        ephemeralStorage: 4Gi
        memory: 16Gi
...
    scale:
      maxReplicas: 2
      minReplicas: 1
      rules: null

Upon deployment, I encounter the error Maximum Allowed Cores exceeded for the Managed Environment. I'm curious about the reasons for this:

• Is it because the ACA cannot exactly use the maximum CPU or memory provided by the ACE, requiring some CPU and memory to be reserved as "overhead"?

• Or is it due to the inability to temporarily run two revisions (old + new) simultaneously during deployment, as their combined requirements (2x4 CPU + 2x16Gi memory) exceed the ACE's limit?

Additionally, I seek advice on the best approach to perform a rolling update without reserving ( / paying for) 8 CPUs and 32Gi memory, considering this double amount is only necessary during a weekly deployment lasting 5 minutes. Or do I only pay for the resources actually used by the ACA, rather than the reserved space in the ACE?

Any insights would be greatly appreciated.

I'm in the process of setting up a deployment pipeline for an Azure Container App (ACA) within an Azure Container Environment (ACE). My ACE is configured with a "D4" workload profile (4 vCPU, 16Gi memory), as detailed in the documentation here. The ACA application is monolithic and fully utilizes the available resources of 4 CPUs and 16Gi memory. It is designed to run as a single instance/replica (min 1; max 2; no scaling rules). The maximum is set to 2 instances to allow running two instances simultaneously during a rolling update.

Here is a snippet of the ACA deployment yaml:

  template:
    containers:
    - image: private.registry.name/image-name:1.2.3
      name: some-name
      resources:
        cpu: 4
        ephemeralStorage: 4Gi
        memory: 16Gi
...
    scale:
      maxReplicas: 2
      minReplicas: 1
      rules: null

Upon deployment, I encounter the error Maximum Allowed Cores exceeded for the Managed Environment. I'm curious about the reasons for this:

• Is it because the ACA cannot exactly use the maximum CPU or memory provided by the ACE, requiring some CPU and memory to be reserved as "overhead"?

• Or is it due to the inability to temporarily run two revisions (old + new) simultaneously during deployment, as their combined requirements (2x4 CPU + 2x16Gi memory) exceed the ACE's limit?

Additionally, I seek advice on the best approach to perform a rolling update without reserving ( / paying for) 8 CPUs and 32Gi memory, considering this double amount is only necessary during a weekly deployment lasting 5 minutes. Or do I only pay for the resources actually used by the ACA, rather than the reserved space in the ACE?

Any insights would be greatly appreciated.

• azure
• azure-container-apps

Share Improve this question Follow asked Mar 17 at 19:47 MichielMichiel 3,53222 gold badges3030 silver badges4242 bronze badges 2

• 1 you allocate 4cpu to your container so 2 replicas will mean you need 8cpu. I imagine using the consumption workload profile would work for you as it allows 4 vcpus + 8ggi per instance. – Thomas Commented Mar 18 at 4:27
• 1 If your Azure Container Apps Environment (ACE) uses a "D4" workload profile, each instance can have up to 4 vCPUs and 16 GiB memory, but not for multiple instances simultaneously due to quota limits. To stay within limits, update one instance at a time or request a quota increase via the portal. Example config: 3 vCPU, 12 GiB memory per container with max 2 replicas. @michiel – Vinay B Commented Apr 7 at 13:52

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

I'll do agree with Thomas on his insights that he provided thank you for guiding on right direction.

The Best Approach for rolling update use the consumption workload profile that allows you to pay only for the resources of your apps, this profile supports up to 4 vCPUs and 8gi memory per instance, better deploy updates in smaller batches to avoid exceeding resource limits.

You can temporarily increase your workload profile to support higher resource limits during the update and switch back afterward.

Example of how you might adjust your YAML to accommodate these strategies:

template:
  containers:
    - image: private.registry.name/image-name:1.2.3
      name: some-name
      resources:
        cpu: 4
        memory: 16Gi
        ephemeralStorage: 4Gi
  scale:
    minReplicas: 1
    maxReplicas: 2
    rules: null

For more Details in Azure Container Apps.

本文标签：