Using Kubernetes Manifests With Nuon

We're excited to introduce a new component type in Nuon: Kubernetes Manifests. This addition gives vendors the flexibility to deploy Kubernetes manifests directly into customer environments, complementing existing Terraform and Helm Container Image components with a lightweight, direct approach to Kubernetes deployments.

What Exactly Is a Kubernetes Manifest?

Kubernetes manifests are YAML or JSON files that serve as the blueprint for your application's infrastructure, from deployments and services to configmaps and secrets. They tell Kubernetes exactly what resources to create, how they should be configured, and how they should behave. Unlike imperative commands that tell Kubernetes what to do step-by-step, manifests describe the desired end state and let Kubernetes figure out how to get there. They're the native language of Kubernetes infrastructure-as-code, and every kubectl apply command, Helm chart, and operator ultimately translates down to these fundamental building blocks.

Every Kubernetes manifest will need some basic parameters:

apiVersion: Specifies the API version of the Kubernetes object.
kind: Specifies the type of Kubernetes object (e.g., Pod, Deployment, Service).
metadata: Contains data that uniquely identifies the object, such as name, labels, and annotations.
spec: Defines the desired state of the object. This can vary significantly based on the kind of resource.

Here’s a sample config:

text
text

There are various tools which can be used to interact with Kube manifests. For example, one of the Kube native tools is kubectl.

text
text

Why Use Kubernetes Manifest Components?

The Simplicity Advantage

Sometimes, you already have perfectly crafted Kubernetes manifests that you want to deploy exactly as they are. Using Kubernetes manifest components provides this direct path.

While Terraform components excel at infrastructure provisioning and Helm components provide sophisticated application packaging, using Kubernetes manifest components fills a crucial gap for vendors who need granular control over their Kubernetes resources or simply want to deploy existing manifest files without additional layers of abstraction.

A Complementary Component Ecosystem

With the addition of Kubernetes manifest components, Nuon's component ecosystem now offers vendors three options to suit their specific needs. Each option has unique strengths:

Terraform Components Best for infrastructure provisioning, cloud resources, and complex multi-cloud deployments.
Helm Components Ideal for packaged applications, complex configuration management, and templated deployments.
Kubernetes Manifest Components Perfect for direct Kubernetes resource deployment, existing manifest reuse, and fine-grained control.
Container Images Container images act as a secure, immutable layer — isolating code and preventing unauthorized access or extraction, even in shared cloud environments.

Configuration Guide: Setting Up Kubernetes Manifest Components

Basic Configuration

Setting up a Kubernetes manifest component is straightforward. Here's a basic configuration:

text
text

Advanced Configuration with Dependencies and Nuon State Variables

Kubernetes manifest components, like all Nuon components, support the full suite of component configuration features including dependencies, templating, and cross-component variable passing:

text
text

Security and Permissions

Kubernetes manifest components operate within Nuon's standard security model. As the vendor, you have permissions to interact with Kubernetes manifest components in different ways depending on what mode the application is in:

Provision Mode: Create new Kubernetes resources and namespaces.
Maintenance Mode: Update/delete existing resources or create new Kubernetes manifest components within defined boundaries.
Deprovision Mode: Delete resources within defined boundaries.

Change Management

Kubernetes manifest components also support approval-based change rollouts. When an app configuration manifest is changed and synchronized, a new build is created. Upon deployment, the system compares the new manifest with the live one, and if resource changes are detected, approval is required before deployment can proceed. More details on approvals are available in our documentation.