Kubernetes: workload lifecycle and status

[ArshSSandhu]

Parent: #441

Depends on: Kubernetes workload provisioning

Summary

Implement lifecycle operations and live status for Kubernetes-backed Manager containers.

Manager should be able to discover its Deployments and start, stop, inspect, and delete them through the Kubernetes API.

Scope

Implement:

• workload discovery
• live status
• start
• stop
• delete
• readiness/operation waiting
• lifecycle error handling

Workload discovery

Implement Kubernetes clusterResources() or an equivalent provider method.

Only return workloads managed by Manager using ownership labels.

Map each Deployment into Manager's existing resource snapshot shape.

The stable resource identifier should match the value stored in Container.containerId.

Status mapping

Map Kubernetes Deployment state into Manager status values.

Expected behavior:

• desired replicas = 0 → offline
• desired replicas > 0 and required replica available → running
• Deployment exists but is still becoming ready → creating/not-running using the closest existing Manager status
• Deployment missing → missing
• Kubernetes API unavailable → unknown
• failed Deployment condition → failed where detectable

Start

Starting a Kubernetes workload should:

1. Scale its Deployment to 1.
2. Wait for the Deployment to become available.

Starting an already-running workload should remain safe.

Stop

Stopping a Kubernetes workload should:

1. Scale its Deployment to 0.
2. Wait until workload Pods are stopped.

The Deployment must remain present so the same provider ID can be started again.

Delete

Deleting a Kubernetes workload should delete its Deployment.

Use Kubernetes cascading ownership so ReplicaSets and Pods are cleaned up correctly.

Handle already-missing Deployments safely where appropriate.

Error handling

Handle:

• Deployment not found
• unauthorized
• forbidden
• API unavailable
• rollout/readiness timeout
• invalid provider ID
• Kubernetes conflict responses

Do not expose authentication secrets.

Acceptance criteria

• Manager can discover Manager-owned Kubernetes Deployments.
• Live status uses Kubernetes Deployment state.
• Running workloads report running.
• Stopped workloads report offline.
• Missing Deployments report missing.
• Start scales a Deployment to 1.
• Start waits for readiness.
• Stop scales a Deployment to 0.
• Delete removes the Deployment.
• ReplicaSets/Pods are cleaned up through Kubernetes ownership.
• Operations use bounded timeouts.
• Kubernetes errors are sanitized.
• Tests cover status/start/stop/delete.
• Existing provider lifecycle behavior remains functional.

Out of scope

• Workload reconfiguration
• Stable networking
• Services
• Ingress
• Persistent storage
• arbitrary replica counts