Jul 3, 2026
Nate Ham, lead engineer for UpCloud's managed Kubernetes platform, shares how teams can lower that risk by using staging environments, running repeatable tests, and keeping pipelines clean every day.
In this interview:
What sovereign cloud means for Kubernetes
How to safely test risky changes before they cause outages
Common mistakes with readiness checks and autoscalers
When AI can help with triage, and when it might add risk
Bart Farrell: Who are you? What's your role? And where do you work?
Nathaniel Ham: My name is Nate. I work here at UpCloud as the lead engineer for our managed Kubernetes platform.
Bart Farrell: We hear a lot about this term sovereign cloud. What does it actually mean? And particularly in a Kubernetes context?
Nathaniel Ham: Sovereign cloud is one of those things that can mean different things to different people. But for us, sovereignty means you own your data. There's no phone home to any of the big corporations across the ocean. Your data is your data. If you have a data center in Stockholm, your Kubernetes data stays in Stockholm.
Bart Farrell: A Kubernetes setting can look wrong, but still feel risky to change once it's already in production. Requests, limits, autoscaling, or probes. What would you tell a team that sees the problem, but is nervous the fix could cause an outage?
Nathaniel Ham: One of the useful things about Kubernetes is that it lets you mirror deployments or environments. So if you have a production environment and you're nervous, do your best to replicate that in a staging or a dev environment as best as possible. And try to break it. See where that nervousness is founded. Is it real? Is it just being gun-shy? And if you do notice oopsies and sharp corners, see what you can do to mitigate those before you push those to production.
Bart Farrell: Missing readiness checks usually show up through something concrete. Traffic reaches a pod too early, auto-scaling behaves strangely, or users report errors. If a team wanted to catch this before users do, where would you have them look first?
Nathaniel Ham: That's always a tricky one because every environment is different and has its own quirks. But as I said earlier, having a staging environment and testing things, breaking them so you know where the limits are, helps. So if you're concerned about readiness checks not behaving as they should, or autoscalers creating funkiness, try to replicate that, break it, and see where you can push your limits.
Bart Farrell: Production readiness reviews can happen before launch, after incidents, during audits, or not formally at all. What would you put in place so Kubernetes readiness gets reviewed before it becomes urgent?
Nathaniel Ham: This is another place where spin-off one-time environments are part of a pipeline. Maybe have a nightly build. We have an end-to-end test that runs the full gamut of conformance tests, all the different corner cases that we've seen go wrong in the past. So, having that as part of your daily hygiene and daily pipelines helps give you confidence that things are working as they should.
Bart Farrell: We're at KCD Helsinki, and we're going to be hearing a lot about AI and Kubernetes. What does that mean in practical terms? Where are you using AI and Kubernetes? Or where are you absolutely not?
Nathaniel Ham: It's a place where it can shine in understanding and triaging. One of the places it doesn't shine is if you're not careful with the permissions you're giving an agent, and you're not aware of it. If your environment is a black box and you're just hoping to cut corners, that's where agents can feel pretty scary. But if you're using something to help sift through logs and different events and chain a root cause analysis, that's a great place for teams to get started.
