Auto-Upgrade

Auto-upgrade keeps the Kubeadapt chart current without manual helm upgrade runs. Once a day (configurable), a sidecar asks Kubeadapt for the next safe version for your policy and channel, then runs a Helm upgrade Job in the kubeadapt namespace. Results appear under Clusters > Connectivity > Upgrade History. It is off by default, and the Job needs write access to the kubeadapt namespace (see Permissions).

Enable It

agent:
  autoUpgrade:
    enabled: true

Or at install time:

helm install kubeadapt kubeadapt/kubeadapt \
  --namespace kubeadapt --create-namespace \
  --set agent.config.token="<your-token>" \
  --set agent.autoUpgrade.enabled=true

Permissions

The upgrade Job runs under its own service account, created only when auto-upgrade is enabled.

• In the kubeadapt namespace, a Role grants create, update, patch and delete on Helm release Secrets and ConfigMaps, and on the chart's own Deployments, DaemonSets, Services, ServiceAccounts, Roles, RoleBindings, Jobs, NetworkPolicies and PodDisruptionBudgets. Roles and RoleBindings include escalate.
• Cluster-wide, a ClusterRole lets it create ClusterRoles and ClusterRoleBindings, and update or delete only the two that Kubeadapt owns (with escalate), plus list and watch on the resources the agent reads.

It does not modify your workloads. If you bring your own service account, give it the permissions in the Role and ClusterRole the chart generates.

The Update Model

Kubeadapt tracks every chart release and which previous versions can safely upgrade to it. Each cluster's upgrade options are filtered by your upgrade policy, channel, and detected cloud provider.

On each check, the cluster asks Kubeadapt "what should I upgrade to?", gets a target version (or nothing), and applies the update. The operation is atomic and locked; no other process can modify the chart release until the cycle completes. If the upgrade fails, Helm rolls back automatically.

Blocked versions

If a released version turns out to have a bug, it's removed from the available paths. Clusters that have not yet upgraded never see that version. Clusters already on the bad version get a path that skips over it on the next check. The fix ships as a new version that all affected clusters pick up automatically.

Multi-hop upgrades

When the gap between current and target is large, Kubeadapt returns a sequential path: 0.18.0 -> 1.0.0 -> 1.0.7. One hop is applied per check cycle, so each intermediate version's defaults are applied in order.

Platform-aware updates

Your cloud provider (EKS, AKS, GKE, or on-premise) is auto-detected at startup. Kubeadapt uses it to scope versions by environment, so your clusters only receive patches relevant to them.

Configuration

All values live under agent.autoUpgrade.

Upgrade Policy

• patch : Only patch versions. 0.17.0 can upgrade to 0.17.1 but not 0.18.0.
• minor : Minor and patch versions. 0.17.0 can upgrade to 0.18.0. This is the default.
• all : All versions including major. Use with caution since major versions may contain breaking changes.

Release Channel

• fast : Every release is published here. This is the default.
• stable : Releases that have finished additional soak time.

Monitoring

Every upgrade attempt is visible in the dashboard under Clusters > Connectivity > Upgrade History.

Full Values Reference

The sections above cover what you need for enabling auto-upgrade and choosing your policy. For other configurations, see the full values.yaml.