This article was written for Kubeshop.
Instead of focusing on optimizations, many Kubernetes experts are shifting toward the fundamentals of platform engineering, where the goal becomes building an infrastructure that lets developers deploy software faster.
By lowering the cognitive load required to productively push bug-free code to production, DevOps teams leverage Kubernetes to create a self-service environment around deploying code. Developers get the tools they need for high velocity and high quality, all without needing a deep understanding of operations.
But doing that successfully requires building an infrastructure for developers that reinforces confidence at every step, like every time they commit code or even save their Kubernetes manifests. Suddenly, developers stop wasting time on manual tests or costly code reviews and increase their velocity.
The good news is that DevOps teams working in Kubernetes have viable ways to build their confidence using tools, platforms, and philosophies that help them leverage validation previewing and GitOps.
What Is Validation?
Validation is the process of automatically analyzing and identifying potential problems with your code.
For example: Because of the overall popularity of JavaScript frameworks, ESLint is one of the most well-used validation tools today. It statically analyzes your code across a large scope of possible problems, as small as requiring semicolons at the end of lines of code or enforcing single quotation marks around strings. Or, if you configure it properly, ESLint can hunt for security issues like unsafe regex or using require(variable), which might allow an attacker to load and run arbitrary code.
Validation interoperability across tools is possible through the Static Analysis Results Interchange Format (SARIF), which standardizes static analysis tools’ rule and configuration syntax. SARIF decouples the tool that performs the validation from the tool that displays the results, acting like a bridge to make them interoperable.
With a single SARIF standard, you can validate everywhere your code lives and runs, from VS Code extensions, your local system’s terminal, a GitHub Action, within a webapp and more.
When you set up a validator and configure it to scan your code for any number of SARIF rules, it recognizes misconfigurations and displays them in your tool of choice as a warning or an error. In some cases, like if your validator runs as a precommit hook, it can even prevent you from committing code that doesn’t adhere to your preconfigured rules.
The @monokle/validation library is just one example of such a validator, allowing teams to enforce YAML syntax, Open Policy Agent (OPA) rules, a specific version of the Kubernetes resource schema and more. You input parsed resources into the library, and it outputs a SARIF response, helping you revalidate incrementally for faster — or even real-time — rounds of feedback.
Here’s an example from Monokle, which lets you configure your validation once and run it anywhere:
plugins:
resource-links: true
open-policy-agent: true
kubernetes-schema: true
rules:
resource-links/no-missing-links: "warn"
open-policy-agent/no-host-network: "err"
open-policy-agent/no-host-mounted-path: "err"
open-policy-agent/no-last-image: "warn"
open-policy-agent/cpu-limit: "warn"
settings:
kubernetes-schema:
schemaVersion: v1.24.2
The Power of Previews
While validators can help you catch misconfigurations in your Kubernetes resources during development, previews help you bring that power to any Kubernetes configuration tool (Helm, Kustomize and more). That’s even more value for your DevOps culture, as you can better ensure the quality of what you’re deploying to your clusters by quickly seeing the differences between any current state and the future state you’re trying to create.
With a preview, you can peek into what the to-be-deployed software contains, what access to your cluster it needs, what kind of computing resources it requires and more. Previews help you get all this knowledge and context without having to be an expert in operations, letting you work more autonomously while also reducing the change failure rate.
Let’s take a common example. You’re part of a DevOps team that needs to expand the capabilities of their cluster by deploying a third-party tool like Prometheus. The Prometheus community offers prebuilt Helm charts designed to simplify the deployment process for required storage, ConfigMaps, ingress service and more.
What we love most about Helm — it dramatically simplifies the process of deploying complex services to a Kubernetes cluster — is also what makes it risky. In theory, you can install Prometheus in three commands:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install [RELEASE_NAME] prometheus-community/prometheus
But lurking behind these three commands is a great deal of complexity that’s abstracted away from you. Previews help you understand exactly what resources Helm wants to create, which prepares you for further changes or increased costs.
With a tool like Monokle, you can compare the output of Helm before you deploy to your clusters — across Git branches and/or repositories, or between different namespaces and entire clusters. It’s perfect for understanding the implications of installing a new third-party tool like Prometheus without spending an inordinate amount of time manually testing and tweaking your configurations.
And with Monokle Cloud, a free, browser-based tool to help you explore, compare and validate Kubernetes and GitOps configurations you’re already storing on GitHub, you can start validating and previewing in just a few seconds. For example, Monokle Cloud helps you see all the resources generated by the Prometheus Helm chart in your browser. No installation is required to understand the full scope of a large change to the state of your cluster.
GitOps: Bridging Validation, Previews and More
GitOps is all about bringing the lessons learned from continuously improving the software development life cycle and applying them to deploying cloud native infrastructure. We won’t talk about every aspect of GitOps here, but there are a few relevant key principles:
- You declare your cluster declaratively, in that your manifests describe the desired state, not the steps required to achieve that state.
- This desired state is stored and versioned with git.
- You use additional tools/platforms to prevent misconfigurations and undesired states automatically.
These principles matter because DevOps and platform engineering are founded more on experience than a specific type of formal training. There isn’t a specific path, like a sequence of computer science courses or a certification, that declares you DevOps-ready. By having all the information in one place — a git repository accessible to your whole team — the GitOps approach creates transparency and builds collective knowledge that prevents big mistakes.
GitOps also closes the expensive feedback loop found in most internal development processes. If you’re waiting for a configuration to fail in staging, QA or production, you’re wasting time you could have spent developing new features or optimizing the manifests you already have. By leaving everything transparent and incorporating automated tools that detect misconfigurations, you can have the best of both worlds: quickly push fixes during incidents to keep your mean time to resolution (MTTR) low, while having all the protection, checks and reviews necessary when you’re ready to deploy a major new piece of infrastructure.
That includes automated validation and previews.
For example:
- You build Kubernetes manifests with a tool like Monokle that leverages git under the hood so you’re always working transparently.
- As you develop, Monokle’s built-in validator points out misconfigurations and gives you suggestions on how to unify and fix your code based on already-established organization standards.
- When you’re ready to push your code, Monokle creates previews of the new declared cluster state with a rich diff UI to highlight what’s going to change with your latest changes and how that might affect what else is currently running on your cluster.
- When you push to your code collaboration platform and create a pull request, you trigger a CI/CD pipeline with additional testing and code analysis layers, like deploy previews or an end-to-end testing suite.
- Once you’ve finished collaborating and making changes to your code, it’s merged into main, allowing the rest of your team to immediately build off your latest improvements.
GitOps provides the foundation for cloud native infrastructure that makes development easier and helps everyone deploy confidently.
One Tool for the Optimal State
Monokle is an open source Kubernetes configuration workbench designed to help DevOps engineers and developers leverage GitOps to power validation, previews and much more. With Monokle, you have one tool for defining, comparing and auditing the actual and desired states of your Kubernetes cluster, with all of YAML’s inherent complexity and syntax headaches abstracted away thanks to its developer-friendly interface.
And with git running behind the scenes with every operation you take on Monokle — from commits to merges to pushes to main — Monokle gives you a shortcut to the latest in code collaboration, CI/CD, GitOps and more.
We’d love to hear about your first forays into validation, previews and GitOps, or how you’ve been using them long enough to perfect your processes! Our team is always around on Discord. Be sure to jump in, say hi and help us shape the future state of DevOps itself.
