Apply manifests directly

Use HelmSharp.Kube when your application already has multi-document Kubernetes YAML and needs lower-level apply, delete, identity, or readiness behavior. It does not create Helm release history; that is the responsibility of the higher-level release workflow.

dotnet add package HelmSharp.Kube --version 1.3.2

Apply rendered YAML

using HelmSharp.Kube;
using k8s;

var config = KubernetesClientConfiguration.BuildConfigFromConfigFile();
using var kubernetes = new Kubernetes(config);

var applier = new KubernetesManifestApplier(
    kubernetes,
    fieldManager: "my-deployment-service");

await foreach (var resource in applier.ApplyAsync(
    manifest,
    defaultNamespace: "platform",
    cancellationToken))
{
    Console.WriteLine($"Applied {resource}");
}

The applier splits YAML documents, derives each resource identity, and applies it through the Kubernetes .NET client. The field-manager value is currently sent only on dynamically discovered resource paths, such as custom resources; use a stable name there to make server-side ownership and troubleshooting more intelligible. Common typed resources, including Deployments and Services, do not currently receive this field-manager value.

Know what the namespace argument does

The namespace argument supplies a default for namespaced documents that do not declare metadata.namespace. An explicit namespace in the manifest wins. Cluster-scoped resources are not given a namespace.

The client resolves common resource kinds directly and discovers other API resources from the target cluster. Apply requires the manifest's declared API version. Delete and deletion waiting can route an obsolete custom-resource version through another served version in the same API group when that version exposes the same kind. Direct deletion reports the manifest identity if no version exposes the kind; deletion waiting treats a kind removed from the entire group as absent.

Delete rendered YAML deterministically

await foreach (var resource in applier.DeleteAsync(
    manifest,
    defaultNamespace: "platform",
    propagationPolicy: "Foreground",
    cancellationToken))
{
    Console.WriteLine($"Deleted {resource}");
}

Delete processes documents in reverse manifest order. The overload without a propagation value uses Background; explicit values are Background, Foreground, and Orphan, and the selected value is sent to typed and dynamically discovered delete endpoints. A Kubernetes object 404 is an idempotent success. A removed dynamic API-version endpoint first triggers same-group served-version discovery; authorization, transport, unsupported core kinds, exhausted direct-delete discovery, and other non-404 API failures stop the operation with the affected API version, kind, namespace, and name. Cancellation stops before the next request.

The direct applier deletes every valid resource document it receives. It does not interpret Helm lifecycle annotations. HelmClient filters helm.sh/resource-policy: keep before uninstall and rollback cleanup, which suppresses a direct delete request but cannot prevent namespace or owner cascading deletion by Kubernetes.

Wait only for the readiness you need

KubernetesResourceWaiter observes common workload kinds: Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, Pods, PVCs, Endpoints, and v2 HPAs. Jobs are only waited on when the caller requests it. Objects outside this set are accepted as applied; they are not proof that an operator-managed resource is ready.

For a full Helm-style lifecycle, including hooks and stored revisions, use Install and upgrade releases. Keep direct delete operations behind the same authorization and approval path as apply.