Merge pull request 2i2c-org#3569 from yuvipanda/cryptnono-bump

Bring in newer cryptnono version

Author: yuvipanda

helm-charts/support/Chart.yaml

@@ -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

helm-charts/support/values.yaml

@@ -396,30 +396,46 @@ 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. But
+        # 1m (or 0.001) is the lowest that can be specified in kubernetes, so we use that.
+        limits:
+          memory: 128Mi
+          cpu: 5m
+        requests:
+          memory: 64Mi
+          cpu: 1m
 
 # Configuration of templates provided directly by this chart
 # -------------------------------------------------------------------------------