Bart Farrell: Who are you? What's your role and where do You work?
Dennis Marttinen: Hi, I'm Dennis Martinen. I work at Cracky and I'm a co-founder and the CTO.
Bart Farrell: A Kubernetes setting can look wrong but still feel risky to change once it's already in production. Requests, limits, autoscaling or probe. What would You tell a team that sees the problem but is nervous the fix could cause an outage?
Dennis Marttinen: you need to gain confidence in what the settings actually do when you change them. My recommendation would be to absolutely have a staging environment that mimics your production. It doesn't need to operate at the same scale, but simulate the same kind of load. So if you have a smaller staging environment, then put on that staging environment maybe some real-world or simulated users that would be using the platform that would roughly equate the scale that you would see in the production environment compared to the staging environment. And then you can play safely and test the changes before you actually deploy.
Bart Farrell: Missing readiness checks usually show up through something concrete. Traffic reaches a pod too early, autoscaling behaves strangely, or users report errors. If a team wanted to catch This before users do, what would you have them look first?
Dennis Marttinen: I highly recommend looking into OpenTelemetry and setting up at least a basic metrics and observability stack, because that is your best friend, not only in sort of load time debugging, but also while you develop your applications. If you have the ability in your application to do a simulated user that essentially just automatically clicks through a bunch of buttons and notices, okay, there's something wrong, This view doesn't load properly, then that is also a very, useful tool that allows you to notice it before users do.
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?
Dennis Marttinen: This is a process technical challenge but also a technical one. From the process side I would put into place at least a basic checklist. Look up some resources that are useful for how to make Kubernetes production ready and go through that basic checklist. You do not need to get it perfect like 100% perfect. You have runtime observability for that but at least go through that checklist and make sure that your team understands what is in there and make that checklist an actual blocker so that you do not actually shift to production before going through that and checking that everything looks green.
Bart Farrell: There's a bit of this idea traditionally that the US innovates and the EU regulates. When it comes to supply chain security and particularly here in Europe as we are in Finland, KCD Helsinki, what are your thoughts on that?
Dennis Marttinen: Especially with the rise of the supply chain attacks, I think the tables have turned a little bit because the regulation is not stifling innovation here. It is actually a very smart forecast from the EU, which is why we're also seeing the cyber resilience act now. That actually helps companies get ready for supply chain attacks and supply chain security in a way that also protects the end users in a positive way.
Bart Farrell: On the subject of Kubernetes secrets, there was recently a bit of controversy. Are Kubernetes secrets enough or there's still something else that's necessary?
Dennis Marttinen: this is a hot topic. How do you do credential management? I would like to get rid of all secrets altogether if possible. And if you need to have them, enable some kind of automatic rotation for everything. Look into SPIFFE and SPIRE. Those are really great CNCF projects that allow you to essentially shift the secrets into the identities of the actual pods so you don't need to do manual secret management at all.
