Skip to content
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

Bring in newer cryptnono version #3569

Merged
merged 2 commits into from
Jan 4, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion helm-charts/support/Chart.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,6 @@ dependencies:
# cryptnono, counters crypto mining
# Source code: https://github.com/yuvipanda/cryptnono/
- name: cryptnono
version: "0.0.1-0.dev.git.27.h01b4f25"
version: "0.3.1-0.dev.git.107.heb504bc"
repository: https://yuvipanda.github.io/cryptnono/
condition: cryptnono.enabled
53 changes: 34 additions & 19 deletions helm-charts/support/values.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -396,30 +396,45 @@ cryptnono:
# resources for cryptnono was set after inspecting cpu and memory use via
# prometheus and grafana.
#
# cryptnono has an init container (kubectl-trace-init) and another container
# (trace). The init container has been found using up to 1.6Gi and up to about
# 600m for 4 minutes. The main container has been found using up to 150Mi but
# typically below 100Mi, and miniscule amounts of CPU (0-3m).
# cryptnono has an init container (fetch-kernel-headers) and one container per
# detector. We currently only use one detector (monero).
#
# In the past, the init container init container has been found using up to 1.6Gi and up to about
# 600m for 4 minutes. However, recent changes seem to have made this much faster,
# and there's no record of the initcontainer because our prometheus scrape interval
# is 1minute, and the init container seems to complete by then. We retain the older
# measured metrics until we can make new measurements.
#
# Since cryptnono is a non-critical service, we are at the moment allowing it
# to be evicted during node memory pressure by providing a low memory request
# compared to the limit. We are also not requesting significant amounts of CPU
# so that it doesn't compete well with others initially.
#
# Note that as of now 2023-03-31 (8367fa5 in yuvipanda/cryptnono), the
# resources configuration configure both containers.
#
# PromQL queries for CPU and memory use:
# - CPU: sum(rate(container_cpu_usage_seconds_total{container="kube-trace-init", namespace="support"}[5m])) by (pod)
# - Memory: sum(container_memory_usage_bytes{container="kube-trace-init", namespace="support"}) by (pod)
#
resources:
limits:
cpu: 800m
memory: 2Gi
requests:
cpu: 5m
memory: 100Mi
fetchKernelHeaders:
resources:
limits:
cpu: 800m
memory: 2Gi
requests:
cpu: 5m
memory: 100Mi

detectors:
# Disable the execwhacker detector for now, as it matures by being deployed on mybinder.org
execwhacker:
enabled: false
monero:
enabled: true
resources:
# Measured with the following prometheus queries:
# Memory: sum(container_memory_usage_bytes{container="monero", namespace="support"}) by (instance)
# CPU: sum(rate(container_cpu_usage_seconds_total{container="trace", namespace="support"}[5m])) by (instance)
# Seems to hover mostly around the 60Mi mark for memory, and generally less than 0.0002 in CPU
limits:
memory: 128Mi
cpu: 0.005
requests:
memory: 64Mi
cpu: 0.0001
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the lowest resolution is 1/1024 of a CPU, and I recall that 2m was the practical minimum value for dockerd and containerd. I'm not sure if there are any enforcement to prevent specification of 0.1m or extremely low values, but I'd be inclined to not optimize this extreme and go for a value of at least 1m to avoid issues.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, @consideRatio. Based on the 'note' in https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu, I switched to using m units and specified 1m - 0.0001 is definitely not enforceable.


# Configuration of templates provided directly by this chart
# -------------------------------------------------------------------------------
Expand Down