For products deployed into a customer's own Kubernetes cluster, how do teams handle upgrades without requiring one of their engineers to sit on a call and manually guide every release? A common process seems to be shipping a new version with a Helm chart and runbook, then having the customer run it while your team stands by in case their network, configuration, or policies cause problems.nnSome ways to reduce the manual work include a self-updating operator that watches for approved releases, GitOps where the customer's Argo CD or Flux instance pulls from a repository you publish, or an in-cluster agent that retrieves releases through an outbound connection. Each approach has tradeoffs around customer approval, security, visibility, operational burden, and control.nnWhat has worked in practice for you? Do you generally push updates, have the customer pull them, or use a hybrid process?
4 Answers
GitOps has generally worked best when the customer already runs Argo CD or Flux. Publishing a versioned repository lets their existing tooling handle reconciliation and keeps control on their side. The downside is visibility: if their sync breaks, you may not know until they report it. A self-updating operator reduces some manual work too, but customer approval usually remains a required step, so it is not truly unattended.
For customer-managed environments, I would not assume that fully unattended upgrades are safe, especially when you have an SLA. We typically arrange controlled access to the cluster, use operators where they make sense, and perform a scheduled upgrade with someone watching it. Automating the repetitive parts helps, but keeping a human involved limits the risk from unusual networking, storage, or configuration problems.
The operational process starts before deployment. Set expectations during sales, identify whether the customer has people who understand Kubernetes, networking, backups, and troubleshooting, and provide a small working quickstart environment. Customers need to own enough of the surrounding infrastructure to recover when something goes wrong; otherwise automation only makes the same support problem happen faster.
A push-style agent can be a good compromise if the customer’s security team allows an outbound connection from the cluster. It gives you better deployment visibility and avoids requiring inbound access, but some organizations will reject any agent that can update workloads automatically. In practice, the approval and permissions model matters as much as the deployment mechanism.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures