Kubernetes Workload Ownership

Pods, deployments, and application responsibilities in Assistance-managed clusters

Pods and deployments are where application ownership meets the Kubernetes platform. Assistance can operate the cluster and shared add-ons, but each workload still needs a named owner, safe configuration, health behavior, resource expectations, and a rollback path.

Workload readiness expectations#

Requirement	Customer/application owner	Assistance/platform owner
Image and tag	Build, test, approve, and promote the image	Provide registry access pattern and image policy guidance where scoped
Health checks	Define readiness, liveness, startup behavior, and graceful shutdown	Validate platform compatibility and alerting integration
Resources	Estimate CPU, memory, storage, and scaling behavior	Review requests/limits, capacity impact, and node fit
Configuration	Own environment values, feature flags, and application secret consumption	Provide secret delivery and namespace conventions where scoped
Rollback	Approve rollback criteria and application compatibility	Provide deployment rollback workflow and platform support
Data	Own migrations, data correctness, and recovery acceptance	Operate storage class or backup integration if included

What Assistance operates#

Area	Assistance responsibility
Namespace baseline	namespace creation, labels, RBAC binding, network policy starting point, and quota guidance
Deployment workflow	GitOps or CI/CD path, template conventions, promotion controls, and rollback mechanics
Platform health	scheduler, nodes, ingress, DNS, TLS, metrics, logging, and cluster add-ons
Guardrails	resource quota, pod security defaults, image policy, and secret integration where scoped
Incident triage	distinguish platform failures from workload defects and route escalation accordingly

What the customer owns#

Area	Customer responsibility
Workload behavior	code, dependencies, startup, shutdown, probes, migrations, and runtime errors
Release approval	tag promotion, rollout timing, feature flags, and customer-impact decisions
Scaling semantics	whether replicas are safe, whether jobs are idempotent, and how queues drain
Business metrics	service-level objectives, customer impact, and product-specific alert meaning
Compliance	data classification, access approvals, and evidence needs for the application

A pod restart is evidence, not a root cause

Assistance investigates whether restarts come from nodes, resource limits, probes, image pulls, or application behavior. Application defects remain with the workload owner unless a broader support agreement includes application engineering.

Normal onboarding workflow#

Owner mapping — name the team, support contact, repository, and deployment approver.
Manifest review — validate namespace, service account, resources, probes, volumes, secrets, and ingress needs.
Pilot deployment — deploy to a non-production namespace and confirm logs, metrics, and rollback.
Production readiness — confirm alerts, runbooks, data migration plan, and maintenance window.
Operate — track incidents, capacity, failed deploys, and recurring workload risks.

Change requests#

Use planned requests for new namespaces, ingress routes, environment variables, secrets delivery, resource increases, persistent volumes, cron jobs, autoscaling, or policy exceptions. Emergency requests are appropriate for unavailable workloads only when platform support is needed; application teams remain involved for release defects or data issues.

Not included by default#

rewriting manifests or Helm charts for every application release
debugging application code inside healthy platform infrastructure
approving production data migrations
guaranteeing workload performance without reviewed resources and capacity
accepting workloads with no owner or rollback path

Getting started#

Prepare the workload repository, image path, manifests, expected traffic, data dependencies, and owner contact. Assistance will review readiness before production onboarding.

Request workload onboarding →