GuillaumeHemmen-k8s/coder-sindri-deployment

Fork 0

#0000 - Size workspace pods and put them in the platform-critical tier #1

Open

claude-bot wants to merge 1 commit from feat/resource-sizing-and-priority into master

claude-bot commented

2026-08-06 20:15:27 +00:00

Member

What

Adds resource requests, limits and priorityClassName: platform-critical to the workspace pods this template creates.

Why critical

Coder is the emergency entry point into the cluster when there is no local machine and no VPN. A workspace you cannot start is as bad as no Coder at all, so the workspace pods share the server's tier rather than sitting below it. At anything lower they would be preempted before app-standard workloads like Mastodon, which is exactly backwards when you are trying to get back in.

The resource wiring

Field	Source
`requests.cpu`	fixed `750m` (measured p95 over 14 days)
`requests.memory`	the `memory` parameter
`requests.ephemeral-storage`	fixed `8Gi`
`limits.cpu`	the `cpu` parameter
`limits.memory`	the `memory` parameter
`limits.ephemeral-storage`	fixed `32Gi`

Three deliberate asymmetries, all commented in the file:

Memory is symmetric (request equals limit). The picker then means what it says: you asked for 8 GB, the workspace reserves 8 GB and is capped at 8 GB. It also gives the memory dimension Guaranteed-style treatment, which is what you want for the workspace someone is relying on to get back into the cluster. As a bonus it means every option in the picker is valid by construction, since a limit can never fall below the request.

CPU is asymmetric: a fixed 750m reservation with the user's pick as the ceiling. Workspaces idle, then compile. Reserving the full pick would strand cores cluster-wide for no benefit.

A CPU limit at all is an exception to the no-CPU-limits rule used everywhere else in this exercise. That rule exists because throttling a stalled server makes it hold its memory longer. A ceiling the user chose themselves on a shared dev workspace is a different thing: it stops one workspace starving a node.

Ephemeral storage is fixed because there is no parameter for disk. The observed 5.4 MiB is meaningless (the workspace was idle when sampled); people clone repos and build in these, so it gets real headroom.

Parameters

Every original option is preserved. Only defaults changed.

Parameter	Options	Default	Change
CPU	2 / 4 / 6 cores	4	unchanged, byte-identical to original
Memory	4 / 8 / 16 / 24 GB	16 (was 8)	options unchanged; default raised

The default moves from 8 GB to 16 GB for the same reason: measured p95 is about 6.7 GiB, and this template runs a desktop.

README.md is updated to match: the "at least 4 cores and 8 GB" recommendation is kept, with a note that memory is both the reservation and the cap, and that CPU is only a ceiling above a fixed 750m reservation.

Validation

terraform validate from the hashicorp/terraform:1.9 container image (Terraform is not installed on this host, and nothing was installed system-wide), run on a copy so no .terraform/ directory landed in the repo:

Success! The configuration is valid, but there were some validation warnings
as shown above.
exit=0

The warnings are pre-existing and unrelated to these edits (deprecated kubernetes_* resource names, and coder_agent.dir). No new ones appeared. validate type-checks against the provider schema, which is what confirms priority_class_name is a real attribute of template.spec.

terraform fmt -check still exits 3, exactly as it did on the pristine file before any of these edits, so this PR does not change that either way.

Prerequisite

platform-critical already exists in the cluster (merged and applied via core#2):

$ kubectl get priorityclass platform-critical
platform-critical   900000   false   PreemptLowerPriority

Without it, workspace pods would be rejected at admission.

See RESOURCE-SIZING-PLAN.md at the workspace root for the full sequencing.

🤖 Generated with Claude Code

## What Adds resource requests, limits and `priorityClassName: platform-critical` to the workspace pods this template creates. ## Why critical Coder is the emergency entry point into the cluster when there is no local machine and no VPN. A workspace you cannot start is as bad as no Coder at all, so the workspace pods share the server's tier rather than sitting below it. At anything lower they would be preempted before `app-standard` workloads like Mastodon, which is exactly backwards when you are trying to get back in. ## The resource wiring | Field | Source | |---|---| | `requests.cpu` | fixed `750m` (measured p95 over 14 days) | | `requests.memory` | the `memory` parameter | | `requests.ephemeral-storage` | fixed `8Gi` | | `limits.cpu` | the `cpu` parameter | | `limits.memory` | the `memory` parameter | | `limits.ephemeral-storage` | fixed `32Gi` | Three deliberate asymmetries, all commented in the file: **Memory is symmetric** (request equals limit). The picker then means what it says: you asked for 8 GB, the workspace reserves 8 GB and is capped at 8 GB. It also gives the memory dimension Guaranteed-style treatment, which is what you want for the workspace someone is relying on to get back into the cluster. As a bonus it means every option in the picker is valid by construction, since a limit can never fall below the request. **CPU is asymmetric**: a fixed `750m` reservation with the user's pick as the ceiling. Workspaces idle, then compile. Reserving the full pick would strand cores cluster-wide for no benefit. **A CPU limit at all is an exception** to the no-CPU-limits rule used everywhere else in this exercise. That rule exists because throttling a stalled *server* makes it hold its memory longer. A ceiling the user chose themselves on a shared dev workspace is a different thing: it stops one workspace starving a node. **Ephemeral storage is fixed** because there is no parameter for disk. The observed 5.4 MiB is meaningless (the workspace was idle when sampled); people clone repos and build in these, so it gets real headroom. ## Parameters Every original option is preserved. Only defaults changed. | Parameter | Options | Default | Change | |---|---|---|---| | CPU | 2 / 4 / 6 cores | 4 | unchanged, byte-identical to original | | Memory | 4 / 8 / 16 / 24 GB | **16** (was 8) | options unchanged; default raised | The default moves from 8 GB to 16 GB for the same reason: measured p95 is about 6.7 GiB, and this template runs a desktop. `README.md` is updated to match: the "at least 4 cores and 8 GB" recommendation is kept, with a note that memory is both the reservation and the cap, and that CPU is only a ceiling above a fixed 750m reservation. ## Validation `terraform validate` from the `hashicorp/terraform:1.9` container image (Terraform is not installed on this host, and nothing was installed system-wide), run on a copy so no `.terraform/` directory landed in the repo: ``` Success! The configuration is valid, but there were some validation warnings as shown above. exit=0 ``` The warnings are pre-existing and unrelated to these edits (deprecated `kubernetes_*` resource names, and `coder_agent.dir`). No new ones appeared. `validate` type-checks against the provider schema, which is what confirms `priority_class_name` is a real attribute of `template.spec`. `terraform fmt -check` still exits 3, exactly as it did on the pristine file before any of these edits, so this PR does not change that either way. ## Prerequisite `platform-critical` already exists in the cluster (merged and applied via `core#2`): ``` $ kubectl get priorityclass platform-critical platform-critical 900000 false PreemptLowerPriority ``` Without it, workspace pods would be rejected at admission. See `RESOURCE-SIZING-PLAN.md` at the workspace root for the full sequencing. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-08-06 20:15:27 +00:00

#0000 - Size workspace pods and put them in the platform-critical tier 41a31014e7

Adds resource requests, limits and priorityClassName platform-critical to
the workspace pods this template creates.

Coder is the emergency entry point into the cluster when there is no local
machine and no VPN, and a workspace you cannot start is as bad as no Coder
at all, so workspace pods share the server's tier. At anything lower they
would be preempted before app-standard workloads.

Memory request now equals the limit and both come from the memory
parameter: the picker means what it says, the workspace gets
Guaranteed-style treatment on the dimension that gets you OOMKilled, and
every option stays valid by construction. CPU keeps a fixed 750m request
(the measured p95) with the user's pick as the ceiling, because workspaces
idle then compile and reserving the full pick would strand cores.

Keeping a CPU limit here is a deliberate exception to the no-CPU-limits
rule used elsewhere: that rule exists because throttling a stalled server
makes it hold memory longer, which is not the same as a ceiling a user
chose for their own dev workspace.

Every original parameter option is preserved. Only the memory default
moves, since the measured p95 for a real workspace is about 6.7 GiB and
the old default would OOMKill anyone doing real work now that the value is
also the reservation.

Validated with terraform validate from the hashicorp/terraform:1.9 image.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin feat/resource-sizing-and-priority:feat/resource-sizing-and-priority

git switch feat/resource-sizing-and-priority

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

GuillaumeHemmen-k8s/coder-sindri-deployment!1

No description provided.

Rows
Columns