Missing CPU and Memory Resource Requests in deployment/k8s/helm-chart/templates/seq-proxy/deployment.yaml
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- helm, kubernetes
- Domain
- infrastructure
Research direction
Start in deployment/k8s/helm-chart/templates/seq-proxy/deployment.yaml around line 37, in the seq-proxy container block, and inspect how resource values are supplied by the chart. Render or validate the Helm deployment to confirm the resulting container includes CPU and memory requests with the intended defaults.
Written by the indexing model from the issue text.
Description
Location: deployment/k8s/helm-chart/templates/seq-proxy/deployment.yaml (line 37, block containers)
Description:
In the Deployment manifest for the seq-proxy component, the resources.requests section is not defined (neither for CPU nor for memory).
In Kubernetes, resource requests specify the minimum guaranteed amount of compute resources that the scheduler reserves for a container when placing it on a node. Without these values, Kubernetes cannot guarantee that the Pod will receive sufficient resources to operate normally under resource contention on the node, resulting in either a BestEffort QoS class or an incorrectly classified Burstable QoS.
Impact:
-
Reduced Availability (Availability/DoS risk): seq-db-proxy is a critical infrastructure component (handling log/request routing). Under high node load, a container without requests becomes the prime candidate for CPU throttling or forcible eviction. This leads to loss of logs and metrics, directly affecting incident detection and investigation capabilities.
-
Non‑compliance: The absence of resource requests violates industry‑standard secure configuration requirements, specifically the CIS Kubernetes Benchmark (section 5.4.x – "Ensure CPU and memory resource requests are defined for all containers").
-
Noisy Neighbor effect: A malicious or misconfigured Pod running on the same node can consume all available resources, effectively crippling the proxy server.
Remediation:
Add a resources.requests block to the container specification.
Example fix (template):
containers:
- name: {{ .Chart.Name }}
# ... other settings ...
resources:
requests:
cpu: {{ .Values.resources.requests.cpu | default "100m" }}
memory: {{ .Values.resources.requests.memory | default "128Mi" }}
- Dominant language
- Go
- Stars
- 131
- Forks
- 16
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 11
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ozontech/seq-db
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
performance
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
feature
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Add store adapter Openfeature
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100