DEV Community: Antariksh Verma

What I Learned From Building a Datree Policy

Antariksh Verma — Wed, 19 Jan 2022 17:20:57 +0000

History

Kubernetes is lovely! I have built and shipped many applications to production using Kubernetes. The one thing I could not wrap my head around was the configuration. Each time I built a project, I would just copy repetitive configuration from my previous projects, and if I was trying something new, I would have to scour the internet till I came across a piece of configuration that matched what I was looking for. This was a terrible developer experience, and that is when I found Datree, a magical tool for preventing Kubernetes misconfigurations from reaching production.

Introduction

I have written a configuration policy for Datree. In this post, I will be sharing my experience about building a policy for Datree and reflecting upon the policy I built along with my final thoughts about Datree. The name of my policy is Horizontal Pod Autoscaler, and the policy can be found here.

About the Policy

My policy is about the Kubernetes component Horizontal Podautoscaler. If you're unfamiliar with what Horizontal Podautoscaler is, it is a Kubernetes component that automatically updates resources like a Deployment or StatefulSet. It does this horizontally, by increasing the number of pods, in response to the load. Coming back to my policy, my policy provides safety around building a Kubernetes configuration which aims to use Horizontal Podautoscaler to scale the application. Now, one could make a policy for absolutely any use case, but I chose to build a policy for the Horizontal Podautoscaler because this policy allows Kubernetes engineers to actually work on reducing costs and scaling their pods rather than ensuring correct configuration.

Policy Rules

Each Datree policy has a bunch of rules. A rule is, essentially, something for which you want to check some piece of configuration for. My policy has 4 rules, indicating that it checks 4 pieces of configuration. The rules in my policy have been laid out as follows:

Ensure target CPU utilization is set: This rule checks for the field targetCPUUtilizationPercentage which defines the target for when the pods are to be scaled. CPU Utilization is the average CPU usage of all pods in a deployment divided by the requested CPU of the deployment. If the mean of CPU utilization is higher than the target, then the pod replicas will be readjusted.
Ensure max replicas are set and valid: This rule checks for the field maxReplicas which is vital because it sets the maximum number of Pod replicas for the autoscaler. It is a value between 1 and 10.
Ensure min replicas are set and valid: This rule checks for the field minReplicas which defines the minimum number of replicas of a resource. As a best practice, it should be set to two, hence the minimum minReplicas one can set it to would be 2.
Ensure scale target ref is configured properly: This rule checks for the configuration of the field scaleRefTarget. The rule also checks for subfields like kind and apiVersion.

Testing the Policy

Getting started with Datree is fairly simple. You can read about it here. I won't get into it right now, but rather focus on just testing my policy in a sample Kubernetes project. To start off, you need the Datree CLI installed. After that, just test the policy using datree test manifest.yaml. Here is how the output looks:

As you can see in the above image, the Datree CLI provides you with a complete summary of the policy. In our case, all of the rules were passed.

Conclusion

Overall, I'd say I learned a lot while building this policy. Not only did I experiment with configuration policies and Datree, but I also learned a great ton about YAML and Kubernetes. Finally, Datree is brilliant to use in production; it really enhances your productivity and boosts your workflow. After building a few policies and pushing some code to production, it really does the work and prevents K8s misconfigurations from reaching production.

Tech Stack for DEV X DO Hackathon Project

Antariksh Verma — Tue, 15 Dec 2020 14:35:37 +0000

Right To The Point

The tech stack for my project is very unique. I will be going with MongoDB as my database and yeah this is a MERN stack project but it isn't. Express JS is not my backend web server but Neuron JS is. If you have seen my post where I introduce Neuron JS then you know what it is but if you don't then Neuron JS is my own web server framework and this project will prove how awesome my framework is. Next up is frontend where I am using my favorite, your favorite REACT JS!!!! Not a big surprise there though. This is the main tech stack for the project. And please check out Neuron JS because if you won't then when I will show you the final product you will be racing to use it.

My DEV X DO Hackathon Idea (Dont Copy)

Antariksh Verma — Mon, 14 Dec 2020 09:45:42 +0000

Right To The Point

So I thought what project would excite me the most and what project would I need as a user. I thought and pondered for like, 2 minutes when I got the idea ⚡. A portfolio maker. A portfolio builder/maker which allows you to host it right there and then as well kind of like wix or weebly.

Advice

The main thing in ideating over a project for an event or hackathon is that what are your strengths. Make something realistic yet wonderful and this can only be made if you have knowledge of many different technologies/frameworks/languages. Plus, don't fret in copying code from someone or using a template, remember they are created for you and if you face imposter syndrome like me then just deal with it.

Well, goodbye, I need to complete it now!

P.S - I will be posting another post about the tech stack I used and why and of course another one which will show the final product and a bit about it.

DEV Badge

Antariksh Verma — Thu, 03 Dec 2020 18:10:03 +0000

I got my first DEV badge on dev.to, which is the hacktoberfest badge! Whoo hoo.

Neuron JS - BYE BYE EXPRESS!

Antariksh Verma — Fri, 06 Nov 2020 14:00:37 +0000

I recently made this small, open source framework called Neuron JS which is heavily inspired by Express, but just much much better. Neuron JS is much faster and much more lightweight than Express.js being only 5kb in size. It supports 4 different request methods, GET, POST, PUT and DELETE. For CRUD functionality and APIs you would only need these methods. I mean, come on who really uses HEAD and COPY and LINK. Neuron JS also supports all Express middlewares, which means that existing libraries and modules will work just fine. Neuron is also under development for Deno.js since Express is not made for Deno yet. Neuron comes with in-built template engine support. And last but not the least, it is MVC-based. Right now, I am also working on integrating native MongoDB just like Django has integrated SQLite support.

Go to NPM to install Neuron.
Go to Neuron Docs to see how to work with it.
Go to Neuron JS GitHub to check out the source code and file issues.

I Completed Hacktoberfest 2020

Antariksh Verma — Sat, 17 Oct 2020 11:51:52 +0000

What I Learned From Hacktoberfest

I learned many important skills from Hacktoberfest this year, and not only that I also made my first open source contribution becuase of Hacktoberfest. I just completed the challenge and have now ordered the limited edition tee. I made 5 successful pull requests and had a blast. The learning was immense since I collaborated with many developers on projects and learnt the importance of good documentation.