Skip to main content
The ImportCluster manifest is the declarative entry point for onboarding a cluster into Ankra and describing its stacks. Apply it with the CLI: 
ankra cluster apply -f cluster.yaml --cluster my-cluster
The same schema is what Ankra reads from a connected GitOps repository.

​
Full Example

apiVersion: v1
kind: ImportCluster
metadata:
  name: my-cluster
  description: Importing my Kubernetes cluster
spec:
  git_repository:
    provider: github
    credential_name: my-git-credential
    repository: my-org/my-gitops-repo
    branch: main
  stacks:
    - name: logging
      description: Stack for logging
      manifests:
        - name: namespace-fluent-bit
          parents: []
          from_file: "manifests/fluent-bit-namespace.yaml"
        - name: configmap-fluent-bit
          parents:
            - manifest: namespace-fluent-bit
          from_file: "manifests/fluent-bit-configmap.yaml"
      addons:
        - name: fluent-bit
          chart_name: fluent-bit
          chart_version: 0.49.1
          repository_url: https://fluent.github.io/helm-charts
          namespace: fluent-bit
          parents:
            - manifest: configmap-fluent-bit
          configuration:
            values: |-
              service:
                enabled: true

​
Top Level

FieldRequiredDescription
apiVersionyesAlways v1
kindyesAlways ImportCluster
metadata.nameyesCluster name — letters, digits, and hyphens only
metadata.descriptionnoFree-text description shown in the platform
specyesThe cluster specification

​
spec.git_repository

Connect a Git repository so stacks are stored and synced from Git. Omit the block entirely for a non-GitOps import.
FieldRequiredDescription
provideryesgithub, bitbucket_cloud, or bitbucket_data_center
credential_nameyesName of a Git credential registered in Ankra
repositoryyesowner/name form, e.g. my-org/my-gitops-repo
branchyesBranch Ankra reads from and pushes to

​
spec.stacks[]

Each stack groups related manifests, add-ons, and applications.
FieldRequiredDescription
nameyesStack name, unique within the cluster
descriptionnoFree-text description
description_from_filenoRead the description from a file path in the repo
variablesnoMap of stack-scoped variables, referenced as ${{ ankra.NAME }} — highest precedence in the variable hierarchy
manifestsnoList of manifest entries or - include: <path> directives
addonsnoList of add-on entries or - include: <path> directives
applicationsnoList of application entries

​
Include paths

Instead of inline entries, reference files or folders in the repository. Ankra loads every YAML file found: 
stacks:
  - name: platform-stack
    manifests:
      - include: manifests/
    addons:
      - include: addons/
      - include: addons/extra/ingress.yaml

​
spec.stacks[].manifests[]

Raw Kubernetes YAML resources.
FieldRequiredDescription
nameyesManifest name, unique within the cluster
from_fileone ofRepo-relative path to the YAML file (forward slashes, resolved from the manifest’s location)
manifest / manifest_base64one ofInline content (the CLI accepts plain YAML under manifest: and encodes it)
parentsnoDependency edges — deploy only after these succeed
encrypted_pathsnoYAML paths within the manifest that are SOPS-encrypted; see SOPS
forcenoReplace the live object on conflict instead of failing (default false)
auto_remediatenoRe-apply automatically when drift is detected (default false)
dependencies_overridenoAdvanced: override computed dependency ordering

​
spec.stacks[].addons[]

Helm releases.
FieldRequiredDescription
nameyesAdd-on name, unique within the cluster
chart_nameyesChart name in the registry
chart_versionyesExact chart version — pin it, especially in production
repository_url / registry_nameyesRegistry URL (or the name of a registry connected in Ankra)
namespaceyesTarget namespace for the release
registry_credential_namenoCredential for private registries
configuration.values / values_base64noHelm values, inline
configuration.from_filenoRepo-relative path to a values file
configuration.encrypted_pathsnoValues paths that are SOPS-encrypted
parentsnoDependency edges
settingsnoArgoCD-backed sync behaviour — see below
namespace_migration_strategynoHow to handle a namespace change on update
job_configurationnoPer-add-on job timeouts (read_job_timeout, update_job_timeout, delete_job_timeout)

​
settings defaults

Sync behaviour maps to ArgoCD and defaults to fully automated. See Add-on Settings for semantics. 
settings:
  sync_policy:
    automated: true
    auto_prune: true
    self_heal: true
    sync_options:
      - CreateNamespace=true
      - ServerSideApply=true
  retry_policy:
    limit: 5
    backoff_duration: 5s
    backoff_factor: 2
    backoff_max: 3m

​
spec.stacks[].applications[]

Deployments of Applications created in Ankra.
FieldRequiredDescription
nameyesApplication resource name
platform_application_idnoThe Ankra application to deploy
platform_application_versionnoPinned application version
namespacenoTarget namespace
parametersnoMap of application parameters
parentsnoDependency edges

​
Parents

parents are the dependency edges that control deployment order: a resource deploys only after all of its parents succeed. Two equivalent syntaxes are accepted: 
# Shorthand
parents:
  - manifest: namespace-fluent-bit
  - addon: cert-manager

# Explicit
parents:
  - name: namespace-fluent-bit
    kind: manifest
kind must be manifest or addon, and the parent must be defined somewhere in the same file. Namespace manifests must be parents of everything deployed into that namespace.

​
Validation

ankra cluster apply validates the file before sending anything: unknown fields, missing parents, and invalid parent kinds are rejected with the offending path. Use --dry-run to validate without applying.