Skip to main content
logoTetrate Patch ServiceVersion: alpha

Managed Upgrades

With managed upgrades, Tetrate Patch Service keeps the Tetrate products you run up to date for you. Whenever Tetrate releases a new version, Patch Service proposes the change as a pull request in the Git repository your clusters are deployed from. You review it and merge it, and the tool that deploys from that repository rolls it out. Nothing changes in a cluster until you merge.

This page explains how that works. You do not need to know anything about it beforehand.

The Repository Is Where Upgrades Arrive​

Managed upgrades work through a GitOps repository: a GitHub repository whose contents describe what runs in your clusters. A tool watches it and applies what is merged: Argo CD, Flux, or a pipeline running Terraform. Patch Service never touches your clusters. It only proposes changes to the repository.

There are two ways to have one:

Your own repositoryA repository Tetrate provisions
Who creates itYou already have it. You connect it from the console.Tetrate creates it for your organization, with your products already in it.
What deploys itYour Argo CD, Flux or Terraform, as today.Argo CD, installed by Tetrate's onboarding.
How you release an upgradeMerge the pull request on GitHub, under your repository's own rules.Comment /approve, or approve it from the console.

Everything else is the same. Both kinds of repository hold the same files, receive the same pull requests, and show them in the same Upgrades view.

What Patch Service Adds to the Repository​

Patch Service reads a few files from a directory named .tetrate/ at the root of the repository, and runs one workflow:

  • The manifest, .tetrate/patch-service.yaml. It names your Patch Service account and the Tetrate products the repository deploys, in each of their environments.
  • One versions file per product and environment, such as .tetrate/teg/envs/prod/values-versions.yaml. It pins the exact images that environment runs. Your deploy tool passes it to the product's Helm chart as a values file, so the pins are what gets deployed.
  • The upgrade workflow, .github/workflows/tetrate-upgrades.yaml. It runs daily in GitHub Actions and opens the pull requests.

Your own configuration stays where it is today. A pull request from Patch Service only ever changes versions: the pins in one versions file, and the chart version where your deploy tool reads it. Your Repository's Files shows each file and how to read it.

How an Upgrade Reaches Your Clusters​

  1. Tetrate publishes a release in its release catalog.
  2. The next run of the upgrade workflow compares the catalog with every versions file the manifest names. For each environment that is behind, it opens one upgrade pull request.
  3. The request appears on GitHub and in the console's Upgrades view, with the clusters it would reach.
  4. You review and merge it. Each environment has its own request, so you can merge dev, watch it, and merge prod later.
  5. Argo CD, Flux or your pipeline deploys the new versions.
  6. The agent reports the new images running. Only then does the console show the cluster on the new version.

An upgrade is done when the agent sees the new images, not when the pull request merges. A rollout that is stuck stays visible as the old version.

Receiving and Viewing Upgrades covers what a request looks like and where to find it.

Which Clusters Patch Service Upgrades​

The agent reports which products each cluster runs, and the Clusters view shows them as chips such as teg · prod. Patch Service upgrades a product when your repository's manifest declares it, and the agent sees it deployed from that repository.

A product deployed some other way, from another repository, or by hand, still gets a chip, but an outlined one: hover over it to see why Patch Service does not upgrade it. A cluster where Patch Service upgrades nothing shows Manual upgrades. Its CVE findings and Upgrade available markers still tell you what to update; you just apply the updates yourself. See Seeing Which Products a Cluster Runs.

Security Model​

  • Tetrate holds no access to your clusters. Git is the only path a change takes, and nothing changes until someone in your organization merges it.
  • Patch Service never writes to your repository. It reads it through a read-only GitHub App. The pull requests are opened by the workflow inside your repository, with that repository's own token.
  • A repository is yours only once it says so. Anyone can type a repository name, so Patch Service treats a repository as yours only after its manifest names your account. Only someone who can push to the repository can write that.
  • Nothing secret is stored in Git. The agent's credentials are created in each cluster when you connect it.

Next Steps​