How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Need help?

Contact us

Creating Custom Applications for NKP – Part 3

calendar_today January 21, 2026 person Mark Dastmalchi-Round domain nutanix

Previously in this series, we built a sample application and packaged it for deployment across Kubernetes clusters. We integrated it into the NKP application catalog so it could be deployed and managed the same as any other platform application. In this article, we’ll wrap things up by looking at configuration management and upgrades, rolling out an update with a new feature along the way.

Configure the Application

As we saw in part 1, it’s possible to set Helm values to customize the application configuration. 

As Helmify created a few values and parameters for us automatically, we can make use of them and use NKP to ensure consistent configuration across all your clusters. 

For example, to again scale our deployment up to 3 replicas, return to the workspace applications view, and select “Edit” for the Hello World application:

Type the following content into the code editor:

hello:
  replicas: 3 

This is the same format as the values.yaml file we looked at when creating the Helm chart. Your screen should now look like this:

You should then click the blue “Save” button at the bottom of the screen. 

Soon, you’ll see the configuration deployed, the HelmRelease move into an “upgraded” state, and the deployment will scale up to have 3 pods running:

kubectl get pods -A -l app=hello

NAMESPACE                     NAME                                  READY   STATUS    RESTARTS   AGE
kommander-default-workspace   hello-world-hello-nkp-hello-bd6njgd   1/1     Running   0          7m21s
kommander-default-workspace   hello-world-hello-nkp-hello-bd75nm6   1/1     Running   0          17m
kommander-default-workspace   hello-world-hello-nkp-hello-bd8thz5   1/1     Running   0          7m21s

Tip – You can also override any of the default values from the chart’s values.yaml file here – take a look at the file and see what else you can configure!

A Look Behind the Scenes

So far we’ve been using the browser UI and CLI tooling, but here’s another area that NKP really shines – everything can be managed as infrastructure-as-code. Regardless of the frontend you are using, all this is represented using standard Kubernetes resources like Custom Resource Definitions (CRDs) and ConfigMaps.  

For example, if you look at your Management Cluster, you’ll see there is a ConfigMap created in your chosen workspace namespace named hello-world-config-overrides. We can examine this and see that the contents are the configuration values for our application we entered above. For example:

kubectl -n kommander-default-workspace \
  get configmap hello-world-config-overrides \
  -o jsonpath='{ .data }'

Which shows:

{"values.yaml":"hello:\n  replicas: 3 "}

The application is deployed by an AppDeployment CRD in the same namespace called hello-world.If you examine this, you’ll see a simple format that defines which application should be deployed to which clusters, and also references the above ConfigMap as a source of configuration. It’ll look something like this:

apiVersion: apps.kommander.d2iq.io/v1alpha3
kind: AppDeployment
metadata:
  finalizers:
  - kommander.mesosphere.io/appdeployment
  name: hello-world
  namespace: kommander-default-workspace
spec:
  appRef:
    kind: App
    name: hello-world-0.1.0
  clusterSelector:
    matchExpressions:
    - key: kommander.d2iq.io/cluster-name
      operator: In
      values:
      - workload-1
  configOverrides:
    name: hello-world-config-overrides

You can see it contains:

  • The appRef which specifies what to deploy
  • The clusterSelector which selects where to deploy it
  • And the configOverrides which govern how it is configured. 

Simple! If you want to configure your application deployments and configuration in a declarative fashion, you’d simply create the Kubernetes resources as above. This makes NKP easy to manage at scale, because you’re working directly with the Kubernetes API and there are no proprietary interfaces or special protocols to learn. 

Updating the Application

You may have noticed that a lot of the NKP platform applications have their own dashboards and links to them from the cluster Applications tab.

Wouldn’t it be nice if we could add one for our application? Well, we can – let’s do this and roll out a new version of our application (0.2.0) while we’re at it.

Adding the Dashboard

As with most things in NKP, customizing or automating the platform is as easy as creating a Kubernetes object. In this case, we can use a simple ConfigMap object with appropriate annotations to create a dashboard link for our application. We can bundle this into our Helm chart so it gets deployed along with the rest of our application manifests.

Create a new file at charts/hello-nkp/templates/hello-dashboard.yaml, and copy the following content into it:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: hello-world-dashboard-info
  labels:
    kommander.d2iq.io/application: hello-world
data:
  dashboardLink: "/hello"
  name: Hello World
  version: 0.2.0

Creating a new Helm Chart

Change the version and appVersion metadata parameters to read 0.2.0 in charts/hello-nkp/Chart.yaml. Then you can package and push again:

helm package ./charts/hello-nkp
helm push ./hello-nkp-0.2.0.tgz oci://registry.example.com/helm

Updating the Application Catalog

Update the OCIRepository resource in applications/hello-world/0.1.0/helmrelease/helmrelease.yaml file to use the new package tag 0.2.0:

apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
  name: ${releaseName}-chart-source
  namespace: ${releaseNamespace}
spec:
  interval: 6h0m0s
  ref:
    tag: 0.2.0
  url: oci://registry.example.com/helm/hello-nkp

And finally rename the directory to “bump” the application version:

mv applications/hello-world/0.1.0 applications/hello-world/0.2.0

Now we can bundle the catalog repository and push the OCI package again:

nkp validate catalog-repository
nkp create catalog-bundle --output-file hello-world-0.2.0.tar
nkp push bundle --bundle hello-world-0.2.0.tar --to-registry registry.example.com/library

Note – you can have multiple applications, and multiple versions of an application stored within a catalog bundle. You can even create an air-gapped distribution which includes container images and OCI artifacts for distribution to environments without Internet access! For more information, see the built in CLI help or review the NKP documentation.

Upgrading the Application

Now we update the application catalog to point to version 0.2.0. You will need to target the Management Cluster kubectl context again, and run the following:

kubectl patch \
  --type merge \
  -n kommander \
  ocirepository nkp-hello-world-hello-world \
  --patch '{"spec": {"ref":{"tag":"0.2.0"} } }'

Note that the NKP CLI includes commands to work with these objects (such as nkp edit ocirepository), but I’m using a quick patch operation in these examples to make the instructions more succinct.

Finally we upgrade the AppDeployment object across our chosen workspace:

kubectl patch \
  --type merge \
  -n kommander-default-workspace \
  AppDeployment hello-world \
  --patch '{"spec":{"appRef":{"name":"hello-world-0.2.0"} } }'

This will trigger a Helm upgrade of our application across our selected workspace clusters. After a few moments, you’ll see our updated application complete with dashboard link appearing in the cluster’s Enabled Applications tab:

Conclusion

And there we have it! We’ve taken a simple “Hello, World” application and transformed it into a fully-fledged NKP platform application.

Let’s recap what we’ve achieved:

  • Created Kubernetes manifests and converted them into a Helm chart
  • Packaged and pushed our chart to an OCI registry
  • Built an NKP application catalog with proper metadata and versioning
  • Deployed our application across multiple clusters through the NKP interface
  • Added a custom dashboard link, just like the built-in platform applications
  • Demonstrated how to upgrade and manage versions seamlessly

The real power here is that your custom applications now behave exactly like NKP’s built-in platform applications. They appear in the same catalog, use the same deployment mechanisms, and can be managed with the same consistent workflow across your entire Kubernetes estate – whether that’s on-prem, in the cloud, virtualized, or bare-metal.

By leveraging NKP’s application framework, you’re ensuring your platform services can be consistently configured, upgraded, and managed at scale. And because it’s all built on standard Kubernetes primitives and GitOps principles, you’re never locked in. Your platform, your applications, your way!

Other Resources

The following is a list of useful documentation and resources used while creating this article.

open_in_new Read original post