Using Cluster

See the Cluster resource reference for the API, example, and field definitions.

Exactly one of destination.server and destination.name is required. Values such as region, architecture, storage class, and ingress implementation belong on the Cluster. Deployment intent such as environment belongs on a DeploymentTarget.

The capability fields can be absent while scaffolding and updating a Cluster, but target rendering requires kubeVersion and at least one apiVersions entry.

clusterScopedKinds records which kinds are cluster-scoped, as group/Kind with core for the core API group; every other kind in apiVersions is namespaced. When vendoredCrds is true, the API versions and scopes of CustomResourceDefinitions come from the Cluster’s vendored CRD snapshot instead of these lists, and rendering fails while that snapshot is missing or stale.

Rendering behavior

Cluster values are recursively overlaid by target values. Templates receive a sanitized Cluster as cluster; the live block is omitted. Kubernetes capabilities are committed so CI can render deterministically without cluster access.

live.context does not participate in render hashes and is never exposed to templates or generated manifests.

Live context resolution

Live commands resolve a context in this order:

1. the command’s --context option;
2. spec.live.context; and
3. the current kubeconfig context.

When possible, Nyl verifies the selected context’s API server against a server-based destination. The conventional https://kubernetes.default.svc in-cluster alias cannot be compared with a local kubeconfig endpoint.

nyl capture cluster primary
nyl capture cluster primary --check

See the get and update command reference for details.