Jun 19, 2026
Kubernetes reliability issues often surface first due to resource settings, readiness issues, or deployments that were not fully reviewed before going live.
Gautam Raj Moktan discusses why teams should handle resource changes practically, why monitoring and staging environments are important when readiness checks fail, and how CI/CD and UAT can help spot production-readiness problems sooner.
Bart Farrell: Who are you, what's your role, and where do you work?
Gautam Raj Moktan: Hi, I'm Gautam Raj Moktan. I'm looking at the AI/ML platform services in Nokia Enterprise and Services Cloud.
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?
Gautam Raj Moktan: I would not worry too much about the fixes in those parameters, those resource changes, I would just make sure that you've followed the production guidelines for any deployments in place in the beginning itself. And then if there are some changes, most of the time Kubernetes handles it well. And then you have the load balancers and such to take care of those. Look at your metrics, the monitoring stack. That will give you a lot of ideas, that will give you more confidence on the load levels currently on your system as well. And and if things go south, then take it as a learning opportunity as well. So I would not worry too much. And it's rather better to do it and fail than not do at all.
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 users do, where would you have them look first?
Gautam Raj Moktan: Again, so these are the metrics that you if you have a good solid monitoring stack, those already give you ideas on what's happening in your deployments. If it is about deployment not coming up at all, so then that's where you would already do that test in the staging side. and during development all stays in already and then you have the UAT side of things to cover those bases. But once it's in production and then it's kind of dynamically deployments coming in, workloads coming up dynamically, then at that point your monitoring stack is your best friend.
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?
Gautam Raj Moktan: Those would be mostly covered on your CI-CD pipelines. And so in that space, you can already figure out a lot of tests to cover your bases. But again, if you are doing reviews on that one, as I said, the UAT phase is also a good place. Before that, you take it through your whole team. It's kind of like you do your UAT with your own team first before you're actually the user. You pretend to be the user yourself. The team pretends to be the user itself. So then that covers a little bit of that.
