Chart-supplied workload resource allocations are insufficient

[OzoneNZ]

Apologies for reporting that chart-supplied pod resources: ... definitions aren't perfect 😄 - hopefully just my contribution to tweak these towards "good enough" for most deployers!

During k8s agent testing we initially faced a lot of pod kills due to resource limit breaches - obviously there's no 1-size-fits-all figures to be had here, but thought I'd share back our conservative minimums after gentle testing with ~2-5 parallel task executions on a single agent.

The monitor workload is very prone to getting OOMKilled with the default resource allocations - on initial pod boot it uses very little memory, but after just 1 or 2 Octopus deployments that report manifests to be tracked (e.g. Helm/Kubernetes steps) it very quickly eats up its quota.

agent:
  resources:
    requests:
      cpu: 250m
      memory: 512Mi

    limits:
      cpu: 500m
      memory: 1Gi

kubernetesMonitor:
  resources:
    requests:
      cpu: 250m
      memory: 512Mi

    limits:
      cpu: 1000m
      memory: 1Gi

scriptPods:
  podTemplate:
    enabled: True

    scriptContainerSpec:
      resources:
        requests:
          cpu: 250m
          memory: 512Mi

        limits:
          cpu: 1000m
          memory: 2Gi