Giters

ElasticBox / elastickube

ElasticKube is an open source management platform for Kubernetes.

Home Page:https://elastickube.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add cpu/memory request for mongo component of deployment

mdbishop opened this issue · comments

commented

Unlike the other components in the elastickube manifest, mongo seems to not have any resource asks defined for it. Not sure if this was a design decision, but it would seem prudent to at least ask for some floor for a few reasons:

  • folks may not watch the kube-system namespace as closely, considering it a bit the wizard behind the curtain.
  • Related, as a (quasi?) system service, a resource guarantee at some base level would seem appropriate.
commented

@mdbishop it makes total sense. For now, we don't have enough metrics about the usage of Mongo so we decided to not add limit for now but we should for sure.

Do you have any suggestions?

commented

@arnaud-elasticbox
I assumed that it was a design decision (even if a temporary one). I'm not a huge Mongo user so would really be talking out my rear if I made a hard number suggestion.

The database components in K8S as a whole (speaking very broadly nothing specific to this use case) strike me as little un-tuned icebergs we're leaving for our future selves unless we allow for some self tuning based on telemetry. It's so easy to deploy redis, mongo, even DB2 these days and forget about it until it blows up -- sometimes not even realizing you just HELM installed some clustered database for WordPress or whatever. 💣

Sorry, gotten way off topic, apologies.

In order of ideal to still fine:

  1. ElasticKube monitors the resource usage of Mongo and adjusts both Mongo's config files and it's resource asks according to reality, preferably with some kind of consent from the cluster admin.
  2. Same as previous except the remediation is left to the cluster admin and is just a courtesy alert.
  3. Use some ongoing best guess at the minimum (Mongo's stated minimums + some wiggle room) and update the manifest as you release new versions and have collected some more intel on what the 'right' size is.

3 May be the easiest and most practical to get kicked off with as you may not hit mongo tuning issues right off the bat (unless Google starts using this themselves 😄 ) so could be deferred.

I'll keep an eye on mongo's metrics and can update this with such once I have a stable installation running.