How to Choose the Right Kubernetes Manifest for Deployment

When you think of your Kubernetes deployment, then by default it's not that secure or by default it's not following all the best practices. For e.g. When you run the command.

kubectl create deployment demo-deploy --image=nginx --replicas=3

It is good for getting up and running, but in production you will need much more than this. You need to set something like securityContext, probes and other best practices within your deployment manifest.

In this guide, we will describe a few deployment best practices that you should have when you're deploying any applications to your Kubernetes cluster.

Overall, if you will look at the problem statement then you'll notice a few while managing Kubernetes manifests. Suppose if you create a new release then you'll be required to update the manifest every time. On top of it, if you're versioning your manifests then it becomes even more harder. Tools like Devtron simplifies all these by providing you a unified platform. Here are few of the challenges that one regularly faces while working with manifests.

Challenges of Deployments

1. YAML Validation Error
2. Setting the Right Security Context
3. Setting appropriate probes
4. Challenges with Autoscaling

Probes

To illustrate why probes are important, say there is one service in your cluster which depends on another service to function and proceed. Let's say unfortunately service B is down, how will you detect that, and what's the next step for you in case service B is down? Should service A stop sending request to service B? If yes, when and how service B will know about it? These are the areas where probes become really useful.

There are mainly three kinds of probes in Kubernetes.

- Startup probes
- Readines Probes
- Liveness Probes

You can configure all three easily in Devtron. You can read more about probes in Kubernetes here. You can configure all three easily in Devtron.

Security Context

In this, you should check whether the container is running with privileged mode or not. If yes, then you should ask yourself why this container is needing the privileged access? If privileged is not required, then you should not give it the root privilege. You can set the right Linux Capabilities, which will ensure that your container is only running with privileges that are required by it. For e.g. If one pod is running with privileged: true and if it's not required, and it only requires CAP_SYS_ADMIN and NET_ADMIN permissions, then we can set the same in the base deployment manifest. Along with Pod SecurityContext, you can also overwrite your container security context by setting required parameters.

Autoscaling

When it comes to autoscaling, then you have to manage a lot of things together. Say you want to update the deployment and some parameters like MinReplicas so if you have 10 deployment in the cluster then you will need to update it 10 times at 10 places. This becomes really challenging if you're updating it again and again.

Autoscaling is one of the tricky part, and you're never sure about how you want to autoscale your clusters because the load is widely different every day and you need to update the autoscaling section of manifest more frequently than other sections.

Deployment with Devtron

One of the things that's very useful in Devtron is using the base deployment template. So let me illustrate what a deployment template is. The idea is to have a common deployment template and give you the flexibility in your hand to quickly whether you want to override your existing manifest or not. This eases out a lot of things, like one of the things. Apart from Kubernetes-native specs, it also supports other integrations including envoy and keda. So, next time you want to set out keda-based Autoscaling you just have to update it and under the hood the gitops engine behind the devtron will make sure that you're getting to the desired state that you've defined in the deployment template.

With Devtron, You can edit the manifest right from the Devtron dashboard and by doing so you don't have to go back to your terminal to the text editor again and again and fix the deployment manifest. If something is broken then we also need to update the manifest in the cluster.

For e.g. Let me break the indentation in the manifest on purpose and you'll notice that the dashboard will scream about it. It really helps as you save your time otherwise you will have to face the YAML rejection by Kubernetes itself and when you're working on something critical which needs to be fixed quick then you don't want those back to back validation error.

Conclusion

In this particular blog, we discussed the importance of choosing the right deployment manifest for your Kubernetes clusters. We also discussed some of the challenges faced when it comes to deploying your applications on Kubernetes and how Devtron can help you solve them!

If you like Devtron, do give us a ⭐️ on GitHub, and feel free to join the discord community for all the latest updates.