Bart Farrell: First things first, who are you, what's your role and where do you work?
Lennart Jern: My name is Lennart Jern. I work with Ericsson Software Technology. I basically maintain the MetalCube project and participate in many other open source projects. I'm a maintainer also for Cluster API provider for OpenStack.
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.
Lennart Jern: I would say that it's better that you control the timing for when that issue happens, so you apply the fix and you know when you do it so you can catch the issue, rather than just wait and see when it blows up at the worst possible.
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?
Lennart Jern: The very first thing would be just to make sure that there are readiness probes and liveness probes defined. So you can have policy for that. Then if they are actually good, I guess for that you would need some kind of actual real tests, load tests or whatever, chaos, something like that.
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?
Lennart Jern: that's a tricky one. I'm not sure actually what to say. I mean, you need to go through it before launch, I think, and maybe have the whole team together discuss what scenarios are we prepared for? Are there other things that we are not? Something like that.
Bart Farrell: Last night at dinner, we were talking about some aspects of Kubernetes that are relevant for beginners and aren't for others. If we're talking about cluster API, when is it relevant? How much do people need to know? What's the essential knowledge that everybody should have about it? About cluster API?
Lennart Jern: So cluster API is really when you want to manage your Kubernetes clusters the same way you manage other Kubernetes workloads. So you want to have that nice Kubernetes API style, you can handle your clusters in the same way. That's it.
Bart Farrell: And MetalCube, for people that are unfamiliar with it, what problem is it solving?
Lennart Jern: So MetalCube solves a number of problems, but let's say that at the very basic level, MetalCube provides an API, Kubernetes-style API, for managing your bare metal servers, right? And then we tie into cluster API, so you can use cluster API if you want to have those servers as Kubernetes clusters. There are some other use cases, you can do other things, but That's the gist.
