How do you make updates to customer-managed Kubernetes clusters unattended?

For customer-owned clusters, it helps to make sure the customer can operate the system themselves instead of assuming your team will always be present. Set expectations during sales, identify the people responsible for Kubernetes, networking, backups, and recovery, and provide a minimal quickstart that works on a simple initial deployment. After that, cluster-specific concerns such as scaling, ingress, and network policy should be clearly owned by the customer.

One practical model is to obtain controlled access to each cluster and perform upgrades on a regular schedule. If permanent access is not acceptable, use temporary credentials for the initial setup and for each upgrade window. Operators and a small automation framework can make this manageable across multiple clusters, but keeping an engineer involved is still sensible when an SLA is involved—unattended upgrades can create significant risk if something fails in a customer-specific environment.

GitOps is often the simplest answer: publish the desired configuration and release version, then let the customer’s Argo CD or Flux installation pull and reconcile it. It keeps the customer in control and avoids requiring inbound access, but you should invest in health reporting, upgrade status, and failure alerts so your team is not blind when reconciliation stops.

A self-updating operator can reduce the amount of manual work, but it does not really make upgrades unattended if the customer still has to approve every version. GitOps usually fits better when the customer already operates Argo CD or Flux: your release repository becomes another source they reconcile. The downside is visibility—if their sync fails, you may not know until they open a support ticket. An outbound agent can offer a good balance when the customer’s security team permits it, but that is often the biggest hurdle.