Skip to content
Nyl
Kubernetes GitOpsTargets and Cluster Variation

Targets and Cluster Variation

A Cluster models one concrete Kubernetes destination and its render-time capabilities. A DeploymentTarget binds that Cluster to deployment intent and publication coordinates.

Operational models

Section titled “Operational models”

The same model supports:

  • one target with one publication revision;
  • several targets on one revision under disjoint path prefixes;
  • a revision per target; and
  • targets published to different repositories.

Multiple targets can reference one Cluster when they need different values, application selections, or publication cadences. A deployment slice for a different concrete cluster uses another Cluster and DeploymentTarget. Publication prefixes may overlap only when the repository or revision differs.

An ArgoCDInstance models the control plane separately. Several targets can deploy to separate workload Clusters while their generated catalogs are owned by the same Argo CD installation. Explicit instances require explicit DeploymentTarget.spec.argocdRef bindings.

Value overlays

Section titled “Value overlays”

Nyl merges Cluster values with target values recursively. Target values win at each conflicting leaf:

Cluster.spec.values < DeploymentTarget.spec.values

Cluster values describe facts such as region, architecture, storage class, and ingress implementation. Target values describe deployment intent such as the environment or rollout configuration.

The effective target and a sanitized Cluster are available to templates as target and cluster; Cluster.spec.live is omitted. Merged values remain available as values:

data:
  environment: '{{ target.metadata.labels.environment }}'
  region: '{{ values.region }}'
  clusterName: '{{ cluster.metadata.name }}'

Local components can declare value imports to receive selected values as chart value defaults without templating them into every invocation.

Conditional applications and resources

Section titled “Conditional applications and resources”

DeploymentTarget.spec.applicationGroupSelector.matchLabels selects groups using their static metadata labels. Nyl templating can omit individual workload resources, while the Release document remains structurally present for source discovery. Target-dependent structural templating in ApplicationGroup and AppProjectDefinition specs can vary policy and project content while their discovery envelopes remain static.

Each target renders with its Cluster’s committed Kubernetes version and API versions. This permits target-specific Helm capability checks without granting CI cluster access.

Maintaining cluster capabilities

Section titled “Maintaining cluster capabilities”

nyl get clusters shows each Cluster’s committed Kubernetes version and the kube context capture uses:

Terminal window
$ nyl get clusters
NAME     DESTINATION                       CONTEXT        VERSION  FILE
primary  https://primary.example.com:6443  admin@primary  1.32.2   config/clusters/primary.yaml#document-1
staging  https://staging.example.com:6443  -              1.31.4   config/clusters/staging.yaml#document-1

Refresh the committed capabilities from the live cluster, or check them for drift:

Terminal window
nyl capture cluster primary
nyl capture cluster primary --check

capture cluster refreshes spec.kubernetes, sorting and deduplicating API versions and recording which kinds are cluster-scoped. With CRD capture enabled it also vendors the cluster’s CustomResourceDefinitions and records only the APIs they do not serve; rendering adds the CRD-served API versions back from the snapshot. --check reports drift without writing. The explicit --context wins over Cluster.spec.live.context; without either, Nyl uses the current kubeconfig context.

Review and commit capability changes like any other platform configuration change because they can alter rendered output. See the get and update command reference for live-context checks.

Next steps

Section titled “Next steps”