The Kubernetes Manifest Life Cycle Too Often Overlooked
Kubernetes has wholly changed the way applications are delivered and run. Today we build faster, ship code constantly and manage colossal workloads in ways we could never have imagined. But as more and more organizations adopt and embrace this new way of working, the deeply complex cloud native landscape is evolving so fast that it’s becoming hard to keep up.
Kubernetes is one of the key shifts that has helped increase the speed of deployment and reliability of the applications. However, little attention is paid to Kubernetes manifests.
These YAML files describe the resources — from services to deployments and pods, etc. — of the object you aim to create and how they should run in a cluster. Even here, things are not straightforward.
The growing cloud native ecosystem means more tools with more and bigger manifests to manage, alongside an explosion of code with differing syntaxes, which has become increasingly challenging for individual engineers to stay abreast of. That’s not to mention the inherent challenges of deployment across microservice architectures, where siloed teams may not be aware of up and downstream changes to services.
Kubernetes Manifest Management
Let’s have a closer look at the Kubernetes Manifest Lifecycle outlined above.
- Creation — the creation and editing phase of a manifest includes several tasks:
- Validation of your manifest(s)
- YAML syntax and target K8s schemas
- Compliance and policies (corporate, OPA, security, etc.)
- Conventions (naming, metadata, etc.)
- Integrity in regard to referenced resources
- Template validations for tools like Helm, Kustomize
- Versioning
- Versioning-related workflows; branches, reviews, etc.
- Previewing/Validate/Fix
- If you’re using a tool like Kustomize or Helm, you will probably want to preview and validate the manifests generated by those tools and possibly debug and fix any errors in the corresponding templates.
- Validation of your manifest(s)
- Application — tasks related to deploying manifests to target cluster(s)
- Generation of manifests to be deployed if you’re using Kustomize/Helm/etc.
- Validation of manifests against your target cluster in regard to object references
- Comparison of your manifests to any existing versions in your cluster to assess the impact of your changes
- Applying rollback — manually or possibly using an automated CI/CD/GitOps-based approach
- Modification — once deployed, you will commonly need to:
- Debug manifests if things are not working as expected
- Modify manifests in your cluster to fix immediate issues
- Retire (delete) manifests to remove them and their corresponding objects when they are no longer needed
Today’s ecosystem for performing all the above tasks is split into two main parts — tools/integrated development environments (IDEs) for writing and editing manifests and cluster inspection tools for monitoring manifests running in clusters. On either side, the most popular and frequently used tools are Visual Studio Code for writing and Lens for monitoring.
Visual Studio Code is a streamlined code editor developed by Microsoft that focuses on software development and may support operations like debugging and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle. It’s released as permissive free software under the MIT License.
Intellij IDEA is another popular open source IDE designed to maximize developer productivity with intelligent coding assistance and ergonomic design. There is an enterprise version available, which isn’t covered by the Apache 2.0 License.
Lens provides full situational awareness for everything that runs in Kubernetes. It aims to lower the barrier of entry for people involved in Kubernetes’ cluster operations through its UI. It’s also available under the MIT License.
Challenges with Existing Kubernetes Manifest Tooling
There is a fundamental gap between tools like Visual Studio Code or other general-purpose IDEs, which have no strong notion of YAML syntax let alone objects, clusters or other Kubernetes constructs where you can create and edit manifests, and cluster dashboards such as Lens, where you can inspect the objects created from your manifests and running in your clusters.
While VS Code and Intellij enable you to easily write manifests, they have limited capabilities to automatically find mistakes with values or syntax errors. Most importantly, none of the monitoring tools enable you to see the relationships and dependencies between resources.
Most of the current tools that address specific parts of the life cycle, outlined above, do it via extensions/plugins. Unfortunately, many different plugins will be required to cover all manifest-related tasks, and these are not built from the ground up to provide consistent and coherent support for the different tasks of the Kubernetes manifest life cycle, nor do they provide an integrated and smooth UI for these purposes.
For us, this is an important challenge to tackle — we want to make manifest creation, application and modification more straightforward and productive to save engineers valuable time and effort. And, of course, stress. We really want to help lower YAML-induced heart racing!
Where Does Monokle Fit?
When we looked closely at the landscape, we realized there were no tools available that specifically and consistently target manifest-related workflows across their entire life cycle, which makes it challenging for both beginners and experts to be as productive as they could be in their day-to-day manifest- and Kubernetes-related tasks.
Today you may have to switch between the different tool sets, such as an IDE, CLI syntax or security validators, and so forth, to fully round out manifest-related workflows.
Monokle focuses on improving the typical Kubernetes workflows that produce headaches, especially for people making their first steps into Kubernetes, but power users can benefit from it as well.
Monokle Features:
- Immediately identify and fix YAML syntax errors.
- Quick overview of Kubernetes resources and their relationships.
- Debug and validate the output of Kustomize and Helm.
- Find and fix configuration errors. Diff local vs. remote resources and deploy them.
- Easy-to-use editors and templates to ensure best practices and consistency.
- Integration of validation tools: for example, Open Policy Agent, which focuses on compliance.
Bridging the Kubernetes Manifests Gap
We want to help engineers quickly gain a high-level view of all manifests and their contained resources while coding, just like you can in Lens in a post-deployment scenario.
But like VS Code and IntelliJ IDEA, we want to also enable engineers to easily edit resources, find problems fast without having to learn YAML syntax, diff resources against your cluster, preview and debug resources generated with Kustomize or Helm, and far more.
That’s why we’re developing Monokle to sit squarely between the editing and visualizing space. It works alongside IDEs and cluster dashboards, helping engineers be productive with manifest-related workflows. It’s designed to simplify workflows significantly, enabling engineers to manage the entire Kubernetes manifest life cycle visually in a single tool.
If You Are Just Starting Your Kubernetes Journey
For engineers who like working in the command line or with IDEs, we believe you should still use your preferred method to write manifests. Monokle simply adds a supportive layer on top to help highlight YAML syntax errors with objects and issues with dependencies.
For Your Next Step
And for those who have a favorite cluster dashboard, Monokle can complement the existing ecosystem, going a step further to identify relationships between resources so you don’t have to search through the code for relationships. In addition, relationships are updated in real-time, and any broken links will be highlighted with a warning.
Part of Kubernetes Ecosystem
As a cloud native project, Monokle supports Kubernetes tools like Kustomize and Helm, which allows engineers to share resources and templates and define common values to share across multiple resources.
It also enables engineers to review Kustomize files or Helm charts without needing to deploy them to a running cluster — a huge step forward for testing because it’s currently pretty tough to debug Kustomize without reading through a sizable Kubernetes YAML file. And who really wants to read YAML all day?
Tell Us About Your Manifest-Related Challenges?
We’re really keen to hear what you think. Would something like this help with your manifest-related workflows?
Getting Started with Monokle
Download Monokle and give it a spin. And then let us know how you found it! We’re always happy to get feedback from our awesome community. Find us on our Discord channel.