-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quota Increase: 100 cores per env, 15 env per region, no app per env quota #503
Comments
how can we check, as users, if it has been rollout or not ? I saw no announcement about it yet and I don't know if we can communicate this to Cx. Thanks :) |
Hello . please let us know how much max replicas can be granted by contacting support? |
Apologies for the late communication. @lgmorand this has been rolled out. @metamultiverse the current quota of replica is 30 per revision. Each quota increase request is personalized and based on the customer's needs. I'm not aware of any specific max when it comes to replicas. Additional note: There is no longer a quota for apps per environment. This is intended to simplify the quotas for ACA 😄 |
Thanks Sophia. but then should not the issue be closed ? :) |
@lgmorand Since this is an item in the roadmap, we leave the issue open so it can be seen and tracked. It moving to different sections of the roadmap indicates its status. |
With GitHub projects (classic & new ones), you can have closed issues in the board and move them from one section to another at anytime. Totally not related to the issue's status :) It'd be less confusing for customers especially because ACA now has a big roadmap (great news :)) ie. AKS roadmap, items are closed by Jorge/Mike when rollout https://github.com/Azure/AKS/projects/1 |
Does it mean, that all existing environments have now the new quota? Or is it neccessary to recreate the environment or can I get it somehow "moved up"? |
@SophCarp thank you for update. Can container apps can large number of scale like VMSS? |
@anrub All existing environments have the quota, so you don't need to recreate an environment to access the larger quota. @metamultiverse I'm not sure where you got 100 cores per environment. The current default max is 40 cores per environment. I believe we're working to increase to 100 cores per environment, but it's not available by default yet. @torosent correct me if I missed an announcement If you have access to 100 cores/environment, your answer is a possible maximum. however, if we look at the current default maximums:
If you want 1 container app in your environment with two active revisions with 2 cores per replica, you could have: However, it's relevant to note that you can have a smaller amount of core in each replica. For example, if you choose to have 1 core per replica you could have 20 replicas in each revision. ex: If you had a half core in each replica, you'd need three revisions to max out: Quota documentation is: https://learn.microsoft.com/en-us/azure/container-apps/quotas I'm not quite sure what your question is, could you rephrase it? Container apps does have scaling options: https://learn.microsoft.com/en-us/azure/container-apps/scale-app?pivots=azure-cli |
@SophCarp Max 100 core limit is by contacting support. Thanks |
100 cores is a lot for a single app isn't it? Are there plans to continue scaling container apps beyond the current 100 core max? This seems fairly limiting. |
Hi @metamultiverse Ah I think I understand better. If you want to scale your app beyond 100 cores, you can request another increase. We are continuously working to increase our default quotas and are happy to accommodate most individual quota increases! @alhardy to clarify, the default quota is currently 40 cores per environment, not 100. @metamultiverse submitted a quota increase for themselves and now has 100 cores per environment. We are working to increase default quota, and users can always submit requests for quota increases. Additionally, I'm working to improve our quota process for customers, to automate and streamline the process. Helpful resources: |
Quick edit for clarity: The original issue mentioned a that you can request up to 100 apps per env. That was a residual from when we had an app-per-env quota. When I updated this issue in February to remove the app-per-env quota I didn't notice I needed to remove it from the note about requests as well. The only per-environment quota we have is cores. If you want to request an increase in your environment's capacity, you only need to consider cores. |
Currently, a major problem in VNet integrated environments is subnet size. If your subnet for cappenv is not big enough (more than /23) you can not scale up to a lot more than 40 cores. |
Sadly, this is wrong at the moment. capps can max. deploy 12 AKS nodes to a /23 subnet (for whatever reason). So you get roughly 40 cores. Hope this will change in the future. |
Hi @anrub and @metamultiverse Thank you for your patience! In the current system, yes, you are correct that a /23 subnet gets you roughly 40 cores. However, we have just soft launched a new option with workload profiles. https://learn.microsoft.com/en-us/azure/container-apps/workload-profiles-overview. This actually does allow for much smaller subnets to have capacity for many more cores. There's more complicated math, but approximately in the established system (consumption only) there's 1 IP per replica(with a bit reserved for ACA). In the Dedicated workload profile, there's 1 IP per node. I'll find the exact equations. @BigMorty Please correct any mistakes on my part about workload profiles! |
Okay, I procrastinated my other work and did the math: For Consumption V1: (the established system)Subnet size = S Dedicated and Consumption Hybrid Infastructure:Subnet size = s ConsumptionV2IPs = 10 minimum (As in, within the environment, at least 10 IPs are set aside for you to use for consumption. This may change! In any case, as later math shows, this is still a huge improvement in cores availability) DedicatedIPs = AvailableIPs - ConsumptionV2IPs Examples: Consumption V1, with subnet /23Subnet = 23 So in the established consumption system, when you have a subnet /23, you have access to at maximum about 45 cores. Now in the dedicated and Consumption Hybrid, with a subnet of /27:Subnet = 27 ConsumptionV2IPs = 10 Ips DedicatedIPs = 20 - 10 = 10 Ips So, in the hybrid workplan, an environment with a subnet /27 can access 30 cores for consumption work ad 30 cores for dedicated work, meaning 60 cores total, more than /23 in the consumption-only plan. That also doesn't account for having more cores/node as some dedicated workload profiles do. Please note, I'm not a dev and I'm not the PM working on the new workload profiles! Any mistakes are on me, and there is documentation explaining workload profiles far better than me here: https://learn.microsoft.com/en-us/azure/container-apps/workload-profiles-overview I just like math :) If this breakdown is useful, we could add it somewhere to the ACA docs. @sanchitmehta @vinisoto @BigMorty could you confirm my math/explanations? |
We have a doc article that covers the IP allocation - https://learn.microsoft.com/en-us/azure/container-apps/networking#subnet |
Also, it seems the (Referring to the established Consumption model) |
Reading this, I am confused as to why we get the error: I seem to read everywhere there is no limit on the amount of apps in an environment, but still we get this error |
I'm getting this same message when trying to create a dedicated workload profile to increase scalability. I really wish this limit was clear in the documentation, I was hoping that container app jobs would be a good serverless option for handling high computing workloads but if there's a hard limit on scaling in the 100's that probably isn't the case. Are there any plans to increase this? If a quota increase can be requested, what is the upper limit on that? |
We're doing some capacity planning with container apps. A couple of questions:
|
Hi All,
We are increasing the default quotas to the following:
Cores: 100 per environment.
Environments: up to 15 per region.
No quota limit of apps per env - the cores will be the only limit per environment.
Notes
The text was updated successfully, but these errors were encountered: