Retrieve Agent Router data plane Kubernetes resources for review or GitOps
The Kubernetes resources that tare install would deploy are rendered without being applied, for manifest review, a server-side dry run, or a GitOps commit before deployment.
Prerequisites
- A data plane credential file from the Admin Console, saved locally as
data-plane-credentials.json. - The
tareCLI installed and available onPATH. helmandkubectlavailable locally. Recenttarereleases can download their own tool bundle, but most enterprise workstations manage these tools directly.
Install the CLI if needed:
curl -sSL https://tare.tetrate.ai/tools/install.sh | bash
export PATH="$PATH:$HOME/.tare/bin"
tare --version
Option 1: render the manifest
Run tare install with --print-resources, declaring the hostnames client applications call with --gateway-hostname:
tare install ./data-plane-credentials.json \
--gateway-hostname=ai-gateway.acme.example.com \
--print-resources > tare-data-plane.yaml
The command writes the rendered Kubernetes YAML to stdout. Progress and preflight messages go to stderr, so redirecting stdout produces a clean manifest file.
The rendered file contains the same Kubernetes resources tare install would deploy through Helm: namespaces, CRDs, service accounts, RBAC, secrets, config maps, services, deployments, autoscaling resources, gateway resources, and install jobs. Where the render includes the Gateway API CRDs (a cluster without them, or --force-gateway-api-crds), since 0.7.0 it also includes the ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding named safe-upgrades.gateway.networking.k8s.io, which refuse an experimental-channel Gateway API CRD applied over a standard-channel one and any Gateway API bundle older than v1.5; the data plane CRD chart installs the same pair when crds.gatewayAPI is true. A copy installed by something else, such as a managed Gateway API add-on, is left alone. To move the Gateway API CRDs below v1.5, delete the policy and its binding first. Since 0.7.0 the config maps include tars-gateway-declaration in tars-system, whose gateway-hostnames field carries the declared list, for example ["ai-gateway.acme.example.com"]. The data plane reads it and reports the hostnames to the management plane.
When several data planes share one cluster, add --post-renderer <executable> (0.3.0 and later) to pipe the rendered manifest through an executable before it is applied, which is the place to give the chart's fixedly named cluster-scoped RBAC objects distinct names. The same executable applies to --print-resources, so the rendered file matches what an install would apply. See Post-renderer in the tare install reference.
The hostname is part of the manifest, not of the Admin Console. To add or retire a hostname later, render again with the full list of --gateway-hostname flags and commit the new manifest; the flags replace the list rather than adding to it. A manifest rendered without the flag carries no gateway-hostnames field, and the data plane then keeps the address stored for it through the deprecated SetDataplaneURL admin API. An empty list (--gateway-hostname="" on its own) declares that the data plane serves no hostname and drains it. See Declare the hostnames a data plane serves.
Option 2: render with an artifact registry
When the cluster pulls from a mirrored registry, set the image registry in the rendered Helm values:
tare install ./data-plane-credentials.json \
--image-registry us-central1-docker.pkg.dev/acme-prod/tare \
--gateway-hostname=ai-gateway.acme.example.com \
--print-resources > tare-data-plane.yaml
When the registry requires an image pull secret that already exists in the target namespaces, reference it:
tare install ./data-plane-credentials.json \
--image-registry us-central1-docker.pkg.dev/acme-prod/tare \
--image-pull-secret-name tare-registry-pull \
--print-resources > tare-data-plane.yaml
To render the pull-secret object from credentials on stdin:
printf '%s\n' 'user:password' | tare install ./data-plane-credentials.json \
--image-registry us-central1-docker.pkg.dev/acme-prod/tare \
--image-pull-secret-stdin \
--print-resources > tare-data-plane.yaml
The tare install proxy wizard runs only on an interactive terminal. In CI, in pipes, and whenever stdin was consumed by --image-pull-secret-stdin, it is skipped silently, so a rendered manifest carries no proxy configuration unless the flags say otherwise. Where outbound traffic must leave through a corporate proxy, pass --http-proxy, --https-proxy, --no-proxy, and the forward-proxy flags explicitly; see Route outbound traffic through a corporate proxy.
Validate before applying
Run a server-side dry run against the target cluster:
kubectl apply --dry-run=server -f tare-data-plane.yaml
Apply once the manifest has been reviewed:
kubectl apply -f tare-data-plane.yaml
For GitOps, commit tare-data-plane.yaml to the repository managed by Argo CD, Flux, or the internal deployment system instead of applying it directly.
Common issues
Error message: tare: command not found
The installer places the binary in ~/.tare/bin by default. Add it to PATH:
export PATH="$PATH:$HOME/.tare/bin"
Error message: unknown command "cli" for "tare"
Use tare install, not tare cli:
tare install ./data-plane-credentials.json --print-resources
If an older CLI requires a URL, upgrade tare first. When an immediate upgrade is not possible, --serve-url can be included to satisfy the older CLI for rendering only:
tare install ./data-plane-credentials.json \
--serve-url https://proxy.acme.example.com \
--print-resources
Error message: Missing serve URL
Upgrade tare and retry. Current releases allow --print-resources without --serve-url:
curl -sSL https://tare.tetrate.ai/tools/install.sh | bash
tare install ./data-plane-credentials.json --print-resources
When an immediate upgrade is not possible, pass a valid planned public hostname:
tare install ./data-plane-credentials.json \
--serve-url https://proxy.acme.example.com \
--print-resources
The hostname does not need to resolve while rendering. A CLI older than 0.7.0 has no --gateway-hostname flag, so the data plane it renders keeps a stored address, set through the deprecated SetDataplaneURL admin API. Render with a current CLI to declare the hostnames in the manifest.
A Gateway API CRD apply is denied by safe-upgrades.gateway.networking.k8s.io
A cluster where the data plane installed the Gateway API CRDs on 0.7.0 or later carries that admission policy, which refuses an experimental-channel CRD over a standard-channel one and any bundle older than v1.5. A GitOps sync that applies such a bundle is denied, and the denial names the policy. The CRDs move forward only, so the usual answer is to sync the current bundle. Where an older bundle has to be applied deliberately, delete the ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding of that name first:
kubectl delete validatingadmissionpolicybinding safe-upgrades.gateway.networking.k8s.io
kubectl delete validatingadmissionpolicy safe-upgrades.gateway.networking.k8s.io
--serve-url into a live installRegistering the gateway URL is a management-plane action, and the registration API refuses a data-plane service account. On an older CLI, a live tare install run with --serve-url fails at the Register data plane URL step, before Helm runs, with permission_denied: insufficient permissions: requires scopes [dataplane_operator]; on 0.3.0 and later the flag is deprecated and ignored. The workaround above is for rendering manifests only. See the error reference.
Where to go next