Kubernetes Target

vortos-deploy-k8s is a separate, optional package that implements the same DeployTargetInterface port Deploy defines — it exists to prove the Ops Kit driver pattern actually works for an out-of-tree target, and to give clusters a real alternative to ssh-compose.

composer require vortos/vortos-deploy-k8s

No manual wiring is needed beyond installing it — KubernetesTarget is registered with #[AsDriver('k8s')] and setAutoconfigured(true), so Deploy's compiler pass picks it up automatically the moment the package is present.

$config->environment('production')
    ->target('k8s')
    ->strategy('rolling');

What ships in this package

Why a separate package, not a match in core

This is the same reasoning Ops Kit documents generally, made concrete: vortos-deploy has zero dependency on a Kubernetes client library. If you never deploy to Kubernetes, you never install this package, and none of its code or dependencies are part of your application. If you do, composer require is the entire integration step.

$container->register(KubernetesTarget::class, KubernetesTarget::class)
    ->setArgument('$planner', new Reference(DeployPlanner::class))
    ->setArgument('$kubeApi', new Reference(KubeApiInterface::class))
    ->setArgument('$rollbackGuard', new Reference(RollbackGuard::class, ContainerBuilder::NULL_ON_INVALID_REFERENCE))
    ->setAutoconfigured(true)
    ->setPublic(false);

KubernetesTarget takes the same DeployPlanner and RollbackGuard that ssh-compose does — planning, phase ordering, and rollback legality are target-agnostic. Only the execution step (turning a planned DeployStep into a real action) differs by target.

Testing without a real cluster

KubeApiInterface exists specifically so tests don't need a real cluster. A FakeKubeApi test double implements the same interface and records what would have been sent to kubectl, letting the full target conformance suite — the same TCK every Deploy target inherits — run without any cluster connectivity.