What I Learned From Building a Datree Policy
Tags: datree, kubernetes, yaml
Published: 2022-01-19 17:20:57

# 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](https://github.com/datreeio/datree/tree/main/examples/horizontal-pod-autoscaler-policy).

# 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.](https://datree.io?utm_source=blog&utm_medium=influencer&utm_campaign=nishant) 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:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1c40wmb95mnh3hozl8k8.png)

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.