Cloud Native Theater | Cloud Native University: Kubernetes and the Answer is… 42! - Jan Stomphorst

This talk discusses best practices for deploying applications on Kubernetes, emphasizing the need for a thorough checklist. The speaker, Jan Stomphorst, outlines 40 crucial considerations that developers should address while navigating Kubernetes deployment. Key topics include the importance of determining whether an application is stateful or stateless, ensuring minimal container images, configuring security best practices, and managing application resources efficiently. Stomphorst emphasizes the necessity for security measures such as image scanning, running as a non-root user, and using network policies. He also highlights the significance of utilizing health checks, scaling configurations, and keeping deployment strategies effective and manageable. The session aims to instill a mindset of production readiness and encourages the audience to implement these considerations in their own Kubernetes practices.

25 minutes, so it's going to be fast and and loud. Um I'm Jan Stomphorst. I'm a solutions architect working for ACCICT. We're a Dutch company and we're specialists in cloud-native solutions. So, what I wanted to talk about. You've got your ultimate application. You're building your application and you want to run it on Kubernetes. And what do you have to do then to run that on Kubernetes? I've

got 40 things to think about. that's why I'm doing this checklist. Sorry, it's going to be a bit fast. It's So, the first thing you have to do. Yeah, we're skipping this. The first thing you have to do if you is your application stateful or stateless? You have to think about that. Foremost, I want to do it stateless, of course, but you've got stateful applications. So, um

yeah, think about stateful stateless. So, do you have Oh, This is better. Do you have uh an SBOM generated for your application? Think about security. Um you can use um Swift Triffy. Everybody know the Triffy hack that happened 2 days ago. Read Read the news. It's it's really a a thing. does your application run as uh pit one and does it handle a sick term properly? Because

Kubernetes will kill your container. It will happen. Oh, by the way, don't use supervisord. Is an anybody using supervisor D? Nobody? Thank you. Oh. Oh, no. set to non-root? Do you run your application as a as a user? That's really important. Like www data for an Apache machine. Is your image minimal? Like an Alpine or distro-less application? Smaller is And you can use Kubernetes debug for debugging

your application. If you want that. Are you removing unnecessary layers in Layers are great. Um you're using your layers for faster development. And if you have a lot of layers, the the develop the the the build times are going to be much slower. And if you have no layers, it's going to be really slow to build your application. So, have enough layers, not too much. Are you

using multi-stage deployments? Who's using multi-stage deployments? Everybody, hopefully. Yeah, good. So, you don't want to have your uh um builder in your production image. That's Yeah, it's a a bigger attack factor. Is your image scanned? By Trivy, of course. With has some vulnerabilities. But is he is your image scanned before it goes to production? And also scanned in production. Is your entry point or command defined? Cuz

you've got your entry point and your command is overriding that. Who's using latest in your application? Good. Latest is not working. It's It's It's a problem. A big problem if you use latest. Is your application is running as non-root? Is that in your deployment? So, run as root don't run as root. So, is your application or your Linux uh deployment is dropping all Linux capabilities? You don't

want to have network access from your container. It's not It's not feasible. do this. Drop all. Is your image pull policy set approximately? So, you want always to pull the correct image for your application. Is the root file system read-only? Some application can't handle that, but a lot of applications don't mind. Are your volumes routed mounted mounted Sometimes you don't have to write back to your volume.

That's Yeah. Are your liveness and readiness startup probes configured? That's also thing. If you don't have that configured, your application is not running properly. Are your resources set? CPU limits on the resources? Why? You don't have to do that. Cuz What Kubernetes does for you, it sets the limits if you set the request. You don't have to use limits. Set the limits for the memory. Is your

memory request and limits almost the same or a bit lower? Cuz the memory memory is not a non-compressible resource. You want to prevent home. Always set the limit for your memory. Often forgotten. Ephemeral storage. Limit your ephemeral storage in your deployment. Most people forget that cuz if you don't cap that, your container deployment will fill up can fill up your node. Oh, yeah. Do you need need

in it containers? Do you need something to change before that starts? I'm I'm using in it containers to change something in my container like rights or some limits. Do you need to have the auto mount surface account token? Or do you need API access from your container? Do you need to have your every container in your cluster to have API access? Yes? Probably no. Do you have

this configured in your containers or in your deployments? Who has this? Nobody, eh? This is a attack factor. Really good one. Do you have enabled service links in It it adds some It's It's not really Yeah, you you can set this. This is not a really It's It's easier to use DNS discovery. Is your pro priority class name defined? sets the priority for your for your Think

it's a good one. This pod needs to run before your other pod. So, if you put your application higher than the other one, it works. Is the security context FS group configured? The files you need to create the files with the the best user, the same user if you're run you're running your container with. It's an easy one. Is the top It's This is a difficult one.

Top of key spread constraints. So, is your container running in different zones or Did you do that for your application? That's also things a a thing uh people forget. And are you doing anti and affinity? Do you want to have your container run on the same node? So, I'm not doing that. I want to have that spread out. Are the pod tolerations uh good configured? Do you

want to have your uh application run on an machine that's in maintenance? Yes or no? I don't think so. But you have to take care of that. Are your uh Kubernetes default uh are sufficient or do you need different ones? Do you need some more nodes? Are you Do you want to have your application run on spot nodes? Yes or no? That's something to think about. Are

your labels in unique? That's an an an an easy one. Your your labels are unique across a name space. So, you can have uh unique labels within a name space. Is the process deadline seconds It's default that's uh 600. But you don't have to have that. It's uh uh easier or s- s- smarter to do it like in 5 minutes. you want to know when your application

dies or not. Are your variables stored in a config map or a secret? A question to you and it's I think a a well-known secret. Is your secret secret in Kubernetes? No, it's base 46 encrypted um encoded. So, that's not secret. are your annotations in place? Are you using annotations like for uh Argo or Flux? So, I like to do annotations to where where my application came

from. and sometimes I'm doing annotations to keep just to keep track of my Is your revision history limit set to reasonable number? Do Does anybody roll rolls this application back? Uh nobody. I always do a roll forward, and never a roll back. But, if you if you have a lot of applications, and you have a high number of this, you will fill up the SCD. Are your

rolling update settings complain uh uh sane? So, what are you doing with with deploying? Are you Are you replacing the the complete application in once, or do you do once one uh one at a time, um five at a time? So, uh um and max availability, do you want to have uh your application running on a Is your container signed? Does anybody use con- container signing? No?

Oh, yeah. One. One. Why not? Why are you not signing your containers? Do you trust your source? Where where your container comes from? you're downloading from upstream a container containing possibly your Yeah, it's something to think about. Are your logs and metrics and traces exported? Sometimes you have to think about uh running an application in Kubernetes, it just dies. So, use um Kibana or something like Also,

export the Kubernetes events also. Who's doing that? some of them. So, is your HBA um defined and does it scale on a direct metric? I I using KEDA? Is are your HBA um is that properly defined? Can you observe sparks or not? So, and is your PDB configured? Who's using PDBs? Everybody. Nobody. Yeah, Some of them. So, it's really important keep your application alive and using a

PDB. Do you use named ports consistently in your application? I want to have my ports named and it makes it easier to have it consistency. And you can use it really good with network policies. And Istio and network policy rely on that named ports. Over network policies, are you using network policies? That's a really important thing. I think a lot of people forget that network policies and

it really acts as a firewall for your And the last one in my in my list also a lot of people think about that. Are you using certificates for your external DNS? And do you make automatic DNS updates? I think that's by the way, awesome that that works. So, and the last thing I want to say say about that, are you using something like an Keyverno to

keep all those things all those 40 things up to date? Cuz I think production readiness is really a mindset. And it's a lot of things. A lot of things to think about. Questions? I went a bit bit fast, but So many questions. Yeah. I can't hear you. Okay. Is there a way that we can get the list somehow sent to us? I've got a QR code here.

If you connect to me and just send me a a message, I will send you the list. Other people questions. So, are you going to use the all those 42 things to get your application properly running in Kubernetes? Yeah? Cool. Thank you very much. Have a nice day.