Design: Kubernetes both ways — run on it, and drive it, without becoming of it

Kubernetes is two first-class relationships, and keeping them separate is the design:

1. Flowstate ON k8s — deployment shape, not code

Server and workers are ordinary stateless processes over Temporal, which makes them ordinary Deployments. What "first-class" means here is the packaging done properly, once:

• Helm chart / manifests with the security posture pre-wired: workload identity via the cluster's OIDC issuer feeding the existing federation machinery (auth/), so pods authenticate to Flowstate — and Flowstate's runs to cloud providers — with no static credentials anywhere in the chart. The trust-policy story this repo already has, given its most common home.
• Worker pools as Deployments per task queue — #156's runs_on: pools map one-to-one onto "a Deployment subscribed to a queue," which is how OS/arch/GPU pools are actually operated (nodeSelector on the Deployment, queue name in its args). The isolation tiers (#156 comment) map onto runtime classes: runc pools, gVisor pools (runtimeClassName: gvisor), Kata pools.
• Probes wired to what already exists (worker health), OTel to the collector, graceful drain on SIGTERM riding worker versioning so a rollout never strands a pinned run.
• Refusal recorded: no operator/CRDs in this slice. A Workflow CRD would create a second source of truth beside the Run RPC and a second admission path beside the one policy surface — the same reason trigger plugins go through the front door (#159). Revisit only if a real GitOps demand arrives, and even then as a thin controller calling the API, never bypassing it.

2. Flowstate DRIVING k8s — a plugin, factored like the others

k8s.* tasks per the #149 discipline (precise, no lowest-common-denominator pretence): k8s.apply (server-side apply, the idempotent primitive — retry-safe by construction, which matters under Temporal), k8s.get, k8s.wait (rollout/condition — heartbeating, cancellable, the archetypal long activity), k8s.logs (bounded bytes), k8s.delete, k8s.job.run (create Job → wait → collect, bounded).

• From outside or inside: kubeconfig/exec-credential or in-cluster SA — but always through a secret reference or ambient identity, never a kubeconfig literal in a Flowfile; API-server egress governed by netpolicy like every other endpoint.
• RBAC is the scoping story: the plugin does not invent permissions — the identity it runs as carries them, per-pool SAs give per-pool blast radius, and the #151 remote-plugin model applies when the plugin should run inside a cluster the workers are outside of (one hardened in-cluster k8s-plugin service, workers invoking under policy — the enterprise shape).
• Client-go owned by the plugin module (the #148 dependency rule); informers/watches bounded by the count-the-round-trips rule.

The lego property

Nothing k8s-specific enters the core. A Flowfile that says k8s.apply means the same thing everywhere; where it can run is runs_on:; what may reach the API server is netpolicy + RBAC; who is the identity chain. Kubernetes slots in as pools + a plugin + a chart — the same three sockets everything else uses.

Sequencing: the chart rides current code and could ship anytime; k8s.* follows the #149 factoring wave; the in-cluster remote-plugin shape follows #151. Related: #95 (named k8s in the plugin list), #146, #149, #151, #156.

Start by reading the existing auth/ federation machinery and worker health behavior, then review the Helm chart or manifests and plugin factoring described in #149 and #151. Use #156 for runs_on worker-pool requirements. Done means the Kubernetes deployment packaging and k8s.* plugin shape fit the existing pools, plugin, and chart boundaries without adding core-specific behavior.