Datree prevents Kubernetes misconfigurations from reaching production.
If you’re the organization infrastructure owner, your product’s stability is your primary concern. You need to spend your time working on toolchain engineering and architecture, but instead you find yourself constantly putting out fires configured in the development stage. Isn’t there a better way?
🚨 Preventing Outages
We’ve experienced this precise challenge, which is why we developed Datree. We wanted to delegate responsibilities to developers, but didn’t want to worry about production outages. That’s why we built a solution to help us implement an abstraction layer with automated checks (with both built-in and customizable policies) to educate developers and manage the Kubernetes configuration changes they perform.
🚀 What is Datree?
Datree is a CLI solution that supports Kubernetes owners in their roles, by preventing developers from making errors in Kubernetes configurations that can cause clusters to fail in production. Our CLI solution is open source, enabling it to be supported by the Kubernetes community.
It’s far more effective than manual processes, such as sending an email to a slew of developers, begging them to set various limits, which likely falls on deaf ears because developers are already overwhelmed.
🏆 The Whole Team Wins
Developers benefit from Datree as well. It offers them a simplified Kubernetes deployment experience so they don’t need to remember so many rules governing development. Instead of relying on human observation and memory, developers are alerted early on, as soon as a misconfiguration takes place, and educated to prevent it from recurring. This process enables them to catch mistakes before their code moves to the next stage—and to become better developers.
🔧 How It Works
The CLI integration provides a policy enforcement solution for Kubernetes to run automatic checks on every code change for rule violations and misconfigurations. When rule violations are found, Datree produces an alert which guides the developer to fix the issue inside the CI process—or even earlier as a pre-commit hook—while explaining the reason behind the rule.