feat: grade sidecars as Workload vocabulary - #11
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sidecarsstops being a proposed field.The decision (0064): a sidecar carries what a container carries. Kubernetes already draws the line —
nodeSelectorand affinity are pod-level,resourcesandsecurityContextare container-level — so the node dimensions stay on the Workload andmemory,cpuandhardeninggo on the sidecar. The split follows the target instead of inventing a rule.Eligibility sums.
postgresat 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-postgresdeclaresprovides: {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 underRecreate.probesstaying 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.