Open mblaschke opened 3 years ago
Issue is still present. Please don't close this.
This issue has been automatically marked as stale because it has not had any activity for 21 days. It will be closed if no further activity occurs within 7 days of this comment.
Issue is still present. Please don't close this.
Issue is still present. Please don't close this.
We are working on a feature to help with this. Will preview it sometime later in the year.
I hope one of the maintainers of this repo can add this feature to the roadmap, and also do something so it's not auto-closed as happened to other roadmap features https://github.com/Azure/AKS/issues/3708.
This issue is raising questions about the value and hidden costs of microsoft's AKS integrated services.
There are msft managed cpu requests defined in every aks service pod manifest, which can quickly add up to 30% of your node cpu, forcing the scheduler to preserve msft's pods as oppose to the customer's.
Every scale up a customer must do to accomodate this bloat conveniently puts more money in the pocket of the company responsible for the bloat so how much incentive really is there to fix this?
This issue has been automatically marked as stale because it has not had any activity for 21 days. It will be closed if no further activity occurs within 7 days of this comment.
What's the point of these bots...?
On Wed, Jul 10, 2024, 22:06 microsoft-github-policy-service[bot] < @.***> wrote:
This issue has been automatically marked as stale because it has not had any activity for 21 days. It will be closed if no further activity occurs within 7 days of this comment.
— Reply to this email directly, view it on GitHub https://github.com/Azure/AKS/issues/2125#issuecomment-2221337137, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADI7HPBD6JBP2M4XR6V4CDZLWH5JAVCNFSM4XYYXQWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRSGEZTGNZRGM3Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Will be adding this to the Roadmap for tracking soon.
This issue has been automatically marked as stale because it has not had any activity for 21 days. It will be closed if no further activity occurs within 7 days of this comment.
Is this issue on the roadmap yet?
I'd say not Nathan. It's funny, I recently launched a D2 nodepool for some KeyVault testing for a customer, and had to launch additional worker nodes because the default AKS bloatware was consuming <= 50% of resource on each worker node....
What happened: Many AKS maintained Pods are running with memory overcommitment, eg:
for example OMS agent pods (from daemonset
omsagent
) are running with:on high load and if node memory is used eg. 99% (which is possible with Kubernetes) this might trigger an OOM Killer on the host (not on the pod!) and so might affect other Pods!
What you expected to happen:
be fair and set limit and request for memory to the same values. don't overcommit memory.
How to reproduce it (as minimally and precisely as possible):
spin up AKS in 1.18 or 1.19 w/ and w/o services (eg. omsagent, policy agent,...)
Anything else we need to know?:
Environment:
kubectl version
): 1.18.14 (also with 1.19.7)