Developer Guardrails with Custom Kubernetes Resource Validators
If your organization is starting to adopt cloud native technology, you’re probably still working out exactly how to internalize and distribute Kubernetes knowledge to the rest of your team. That’s not a knock on your team — it’s so much of a common concern that the Cloud Native Computing Foundation has developed the Cloud Native Maturity Model, which helps organizations understand how effectively they’re tackling their wobbly first steps into new tools and different cultural needs.
But the need is clear: To work efficiently and produce high-quality deployments, your organization’s entire technical team needs to broaden its Kubernetes know-how.
This is even more prescient as DevOps culture and GitOps processes dictate that more work and cognitive load should be “shifted left” and incorporated earlier into the software development life cycle. Developers are now being asked to incorporate security and IT operations best practices from their first lines of code. They’re responsible for more aspects of a system they often don’t fully understand.
In another branch of the technology organizational chart is platform engineering, which is overloaded with the task of keeping developers from deploying new applications and resources that crash, cause cascading issues or overutilize expensive cloud resources. It’s a platform engineer’s job, after all, to establish automation and processes that drive the infrastructure toward the coveted state of zero errors.
But with new technology and developing Kubernetes knowledge, platform engineers need a viable strategy, based on automation, that unblocks developers and educates them while maintaining high-quality code.
Documentation is great, but platform engineers shouldn’t spend their time codifying knowledge that way — and the likeliness of the target audience actually reading it (not to mention complying with it) is, as many of us know from our own experience, pretty low.
What platform engineering really should be doing is providing guardrails for developers in their organization that can easily be applied, enforced and automated as part of ongoing predeployment developer workflows. One surprisingly easy way to provide these guardrails is by creating custom policies using an easily deployable validation framework for your Kubernetes application configurations.
The answer is simple: Developers shouldn’t be allowed to commit code or configurations that violate your organization’s policy.
Validators enforce policy at the commit stage, either directly in the integrated development environment (IDE) your developers use, or as an initial check in your CI/CD pipeline (or, ideally, in both stages). Simple errors, like invalid YAML syntax, get caught and rejected by the validator before your CI/CD pipeline spends precious time and cloud resources deploying code that will inevitably fail.
By enforcing standards at the commit stage, you build quality early in your software development life cycle and streamline your processes along the way.
And you can establish a culture of validation by following two relatively simple rules:
- If your organization makes the same error twice, it’s time for platform engineers to codify it into a rule for your validator to flag and block.
- Your organization’s policy should be unique and bespoke to your needs, goals and culture, not something you copy-paste from StackOverflow or GitHub.
The Power of Custom Validators
But the policy bundled into these tools — or the ones developers can integrate from major organizations like Airbnb — doesn’t cover most of the ways developers can take a Kubernetes deployment in the wrong direction.
They don’t answer the need to make a new policy when your organization makes the same error twice, and they’re not designed for the unique technology stack and cultural impulses of your organization.
A custom validator seamlessly solves both these problems through automation. Your platform engineers codify their deep knowledge and strong opinions about Kubernetes into that organization-specific policy. Instead of constant manual interventions, like requesting changes in pull requests (PR) after PR, platform engineers passively prevent misconfigurations.
From a developer’s perspective, a custom validator doesn’t change much about their day-to-day. As they develop Kubernetes applications and resources, their IDE notifies them of policy misconfigurations at the warning or error stage, the guardrails set up by platform engineering, which stops them from committing code that violates your organization’s policy from the very beginning.
Your custom validator is now passively improving the quality of your codebase without adding any additional cognitive load for developers, which keeps them shipping quickly. Platform engineers automate their way toward zero errors and developers start learning Kubernetes best practices with every new line of code.
Going Beyond Validation as Mistakes
Most organizations might be lucky to have one platform engineer for every 10 developers, which means they need to focus on automation and GitOps, not manual intervention, to remove themselves as a bottleneck to deploying to production.
Remember the main responsibilities and goals of any platform engineering team:
- Focus on paved roads and process improvements, like choosing the right tools or implementing automation, that provide value to their “customers,” their application development peers.
- Prevent developer teams from reinventing the wheel again and again because they have to worry about configuring and provisioning infrastructure.
- Automate the way they bridge the knowledge gap between developers and their wealth of Kubernetes-specific best practices.
- Creating the “glue” and guardrails that help developers build and deploy high-quality applications without having to understand the entire toolchain or requiring manual intervention from DevOps engineers.
If they can pull off any of those, they’re doing solid work to keep everyone on task, productive and deploying successfully to the cluster.
Custom validators don’t just help platform engineers achieve these goals from a technical perspective. They also help teams embrace a culture of education and continuous improvements. We like to say that a custom validator’s policy isn’t punishment but rather resources that help developers learn the nuances of Kubernetes every single day.
Platform engineers contribute to that culture by writing new rules, which include valuable context that automates how they distribute what they know. As developers work, they can hover over error/warning icons in their IDE and read descriptions of what policy the rule enforces and what steps they can take to remedy it.
Monokle Is the ‘Pocket Platform Engineer’
If you have platform engineers in your organization, they’ve undoubtedly heard of or already tried custom validators. But many of these tools require a unique domain-specific language, and when writing a rule is too difficult, it never happens. Platform engineers waste time writing documentation or gently reminding their developer peers, once again, how to stop introducing so many errors into the cluster.
If this is something your organization struggles with, or you clearly see the value in bridging the gap between platform engineers and developers, you should put Monokle’s open source validation framework on your radar.
Monokle is a suite of tools that helps developers, DevOps engineers and platform engineers deploy with confidence by unifying the way they author, validate and push their Kubernetes configurations into production.
Monokle recently introduced a TypeScript-based custom validation framework that makes adding new rules remarkably simple. Validation rules can be applied using a command-line interface, a GitHub Action, the Monokle Desktop tool and Monokle Cloud. There’s even a local development server, which communicates with Monokle Cloud, to help you test your new rules before you apply them across your organizations.
As developers write new resources in Monokle, all the complexity behind Kubernetes policy and the shift-left revolution is abstracted to a red or green light — no more cognitive load. And thanks to Monokle’s built-in contextual information, developers can start turning every misconfiguration into an educational opportunity.
Want to see custom validation in action first? Check out our pair of videos on developing your first policy and deploying the custom validator through Monokle’s IDE.