DI and actions

The facade is the shortest route and the recommended default, but it is only sugar over RoundlyConsulting\KubernetesApi\KubernetesManager — the facade root, bound as a container singleton. Inject the manager for the same API with an explicit dependency and no static calls:

use RoundlyConsulting\KubernetesApi\DataTransferObjects\Scale;
use RoundlyConsulting\KubernetesApi\KubernetesManager;

final class ScaleCheckout
{
    public function __construct(private KubernetesManager $kubernetes) {}

    public function __invoke(int $replicas): Scale
    {
        return $this->kubernetes->cluster('production')
            ->deployments()
            ->setName('checkout')
            ->scale($replicas);
    }
}

Resource objects instead of actions

This package is a remote-API client, so there are no action classes: the use cases are the resource objects themselves. Build one directly and bind it to a cluster from the manager — it goes through the same transport, and the same fake:

use RoundlyConsulting\KubernetesApi\Resources\ConfigMap;

ConfigMap::make()
    ->setCluster($kubernetes->cluster('production'))
    ->setNamespace('shop')
    ->setName('settings')
    ->setData(['FEATURE_X' => 'on'])
    ->create();

Three entry points, one transport

• Kubernetes::fake() swaps the manager behind the facade and in the container, so an injected KubernetesManager receives the fake too.
• Resources bound to a cluster the manager handed out — named, default, ad-hoc or namespace-scoped — use that cluster’s transport, so they are faked as well.
• A cluster built without the manager (new Cluster, Cluster::make()) uses the real HTTP transport and bypasses the fake — resolve clusters through the facade or the manager.