Skip to content

feat: grade sidecars as Workload vocabulary - #11

Merged
ExtraToast merged 2 commits into
mainfrom
feat/grade-sidecars
Sep 7, 2026
Merged

feat: grade sidecars as Workload vocabulary#11
ExtraToast merged 2 commits into
mainfrom
feat/grade-sidecars

Conversation

@ExtraToast

Copy link
Copy Markdown
Contributor

sidecars stops being a proposed field.

The decision (0064): a sidecar carries what a container carries. Kubernetes already draws the line — nodeSelector and affinity are pod-level, resources and securityContext are container-level — so the node dimensions stay on the Workload and memory, cpu and hardening go on the sidecar. The split follows the target instead of inventing a rule.

Eligibility sums. postgres at 2Gi with a 64Mi exporter needs a node with 2112Mi free, not 2Gi. On the 4096Mi Pis that difference is a fifth of what is left after the reserve, and getting it wrong places a pod that cannot fit.

Why it earned a decision rather than a note: three live cases — postgres+postgres-exporter, stalwart+stalwart-apply, agent-runner+agent-gateway. The last is in the accepted-drift ledger as "a sidecar jar inside agent-runner pods, not a workload of its own" — a real container excused from attribution because the model could not name it. That entry can now close. Worse, platform-postgres declares provides: {metrics: 9187} and the container that actually serves 9187 had no declaration at all.

Deliberately left open, and recorded as such rather than papered over: a sidecar has no identity of its own (0024 puts the ServiceAccount on the Workload, and a pod has one), so a grant scoped "to the exporter" is in practice held by the database container beside it. And rotation: {tolerates: restart} derives a Workload-scoped restart target, so rotating a read-only connection string takes the datastore down under Recreate.

probes staying on the Workload is a decision, not a gap: a failing exporter must not hold its Workload out of service.

51 ADRs lint clean · 17/17 tests · every example YAML parses.

0064: a Workload may hold sidecars, and a sidecar carries what a container
carries. The node dimensions stay on the Workload because nodeSelector is
pod-level; memory, cpu and hardening go on the sidecar because resources and
securityContext are container-level. The split follows the target rather
than inventing a rule.

Eligibility sums: postgres at 2Gi with a 64Mi exporter needs 2112Mi free,
and on the 4096Mi Pis that is a fifth of what the reserve leaves.

Three live cases forced it - postgres plus postgres-exporter, stalwart plus
stalwart-apply, agent-runner plus the agent-gateway jar. The last sits in
the accepted-drift ledger as a container the model could not name, and can
now close.
Chapter 10 drops it from 'Still to be graded', chapter 00 narrows open item
5 to minAvailable alone, and the postgres example declares the exporter's
own memory, cpu and hardening.

The data render gap shrinks to what 0064 deliberately leaves open: a sidecar
has no identity of its own, so a grant scoped to the exporter is held by the
database container beside it, and a rotation restart target cannot be
sidecar-scoped.
@ExtraToast ExtraToast added type: feature New user-facing or operator-facing capability. area: platform Platform, deployment, cluster, or runtime concern. labels Sep 7, 2026
@ExtraToast
ExtraToast merged commit 57dd98e into main Sep 7, 2026
3 checks passed
@ExtraToast
ExtraToast deleted the feat/grade-sidecars branch September 7, 2026 13:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: platform Platform, deployment, cluster, or runtime concern. type: feature New user-facing or operator-facing capability.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant