Skip to main content
logoTetrate Patch ServiceVersion: alpha

Installing Across Your Fleet

A connected cloud account lists every Kubernetes cluster it holds; installing across the fleet is picking clusters, picking what each should run, and one click. Each install runs as its own job, so one unreachable cluster never blocks the rest of the fleet.

Reviewing Discovered Clusters​

Expand a connected account in Cloud Accounts to see its discovered clusters. The table shows each cluster's name, its Region, its Kubernetes Version, and its Status, with anything that needs your attention spelled out under Details:

  • A cluster that is already reporting is marked as onboarded, so you cannot install over it by accident.
  • A cluster whose API endpoint is private carries a warning that the Patch Service may not be able to reach it; the CLI path below covers those.
  • After an install attempt, the status shows how it went, from Installing through Onboarded or Install failed with the failure's reason.

Discovered clusters are matched against already-connected ones by their cloud identity, not their name, so a cluster you connected earlier with the CLI shows up as onboarded rather than as a stranger to install over.

Choosing What Each Cluster Gets​

Every selected cluster carries its own install target in the Target column: Agent only, or one of your products with an environment, shown as pairs like teg (dev).

A managed target installs the agent alongside the product, not instead of it. Agent only means visibility: the cluster reports what it runs. A product target additionally installs that product's managed data plane in the cluster. The products offered are the ones your repository was seeded with, not a catalog to browse.

Nothing is preselected, because installing is a change to a cluster: you tick the clusters to include. To set many rows at once, use Set the target for the selected clusters above the table and click Apply to N selected; any row can still be changed on its own afterwards.

An expanded cloud connection showing its discovered fleet: two clusters selected with their targets set to agent only, a private-endpoint cluster flagged in the details column, and the Install on 2 clusters button beneath the table.

Installing​

  1. Tick the clusters to install on, and set each row's Target.
  2. Click Install on N cluster(s). The count in the label is the commitment: exactly those clusters are touched, one job per cluster.
  3. Watch each row's status move. A finished row reads Onboarded, and the cluster starts appearing in the Clusters view with its first report.

Installation takes cluster administration in the target cluster immediately before the work and gives it back immediately after, as described in Connecting an AWS Account. A row that fails shows Install failed with the reason and offers a retry on that row alone; retrying is safe because onboarding is idempotent end to end.

Each installed cluster is registered under the name its cloud account knows it by, reduced to a DNS-1123 label. Names stay unique within your organization, so a discovered cluster whose name is already held is registered under a name derived from it; its source line in the Clusters view names the account and region it came from.

Labeling Workloads on Agent-Only Clusters​

Once agent-only installs finish, the fleet table shows a tip to label your workloads, and it is the step between a connected cluster and a useful one: the agent reports only Deployments and DaemonSets carrying your customer label.

kubectl label deployment <name> dataplane.tetrate.io=<customer-id>
kubectl label daemonset <name> dataplane.tetrate.io=<customer-id>

Clusters that took a product target need no labeling: a managed product labels the workloads it installs.

Clusters That Cannot Be Reached​

A cluster whose API endpoint is private cannot be reached from Tetrate at all. The failure says so plainly, a routing problem rather than an authorization one, and the fix is to connect that cluster with the tetrate CLI from inside your network, as described in Connecting Clusters. Once it reports, discovery recognizes it by its cloud identity and marks it onboarded like any other.

Next Steps​