Helm Charts Within NS8- Beyond Simple containers

Development
1

I Have noticed that a great Deal of Complex software systems are implementing Kubernetes based deployment, MAking USe significantly of Helm Charts

Akin to what NS8 is doing with containers, and podman, Kubernetes also manages containers.
I stumbled Upon this github issue on Using Podman to run Helm Charts.

After and While Building mutliple Apps for NS8, and in the Quest for Doing more with NS8, A question was posed.

Can we Do More with NS8, and go beyond Smple Containerized Application Deployment.?

These Articles Sprung to the Scene.
Running Kubernetes Yaml files with Podman

Running Kubernetes Workloads in systemd with POdman

Reading ABout Podman-play-kube and podman generate kube here

it Technically is possible to Create Kubernetes Yaml from podman, as well as Run kubernetes with Podman,

it seven on the podman Website Homepage

image
image1399×851 103 KB

My Question then becomes:

  1. IS it possible, to Make use of Helm charts, to build, create manage and Run NS8 App, or generally to package it into NS8 App?
  2. How Would/ cloud we go about Achieving and making this possible.?
  3. What Are the complexities involved at this juncture, in relation to how NS8 has been implemented and Designed?

Edit:

Am Looking at these 3 comonents

  1. Managing and Running kubernetes apps within NS8 with podman

  2. Helm for Chart Management, Podman and Systemd for Deployment:

  • Use Helm to manage charts: Define your applications using Helm charts.
  • Generate Kubernetes manifests: Use helm template to generate Kubernetes manifests from charts.
  • Convert manifests to systemd units: Use podman-kube to convert Kubernetes manifests into systemd unit files.
  • Manage with systemd: Use systemctl to start, stop, or restart your applications.

3) Helm for Chart Management, Kubernetes-like Orchestration:

  • Use Helm to manage charts: Define your applications using Helm charts.
  • Generate Kubernetes manifests: Use helm template to generate Kubernetes manifests from charts.
  • Use a Kubernetes-like orchestrator: Employ a tool like k3s or minikube in a limited scope to manage the generated manifests.
  • Run the orchestrator in a Podman container: Isolate the Kubernetes environment within a Podman container.

My knowledge on Kubernetes and Helm charts is extremely Limited as of writing this post.

1 Like
2

just off my head…(just trying to wrap it all in my head > not sure)
So exploring Packaging Kubernetes and helm isndie the created pods, either using kubeadm or k3s

3

If I understand correctly, the issue is running an application on NS8 that is originally designed for Kubernetes.

Podman offers a tool to translate Kubernetes manifests into a format it can partially understand. In my opinion, this seems more like a solution for developers to build an NS8 application rather than a method for running Kubernetes apps directly on NS8.

4

this is the solution i am inquiring about

5

In this case, category Development is more appropriate than Feature.

6

probably, considering we are curently packaging apps meant for Docker into Podman on NS8, maybe having means to run apps designed or meant for Kubernetes as another way to package NS8 Apps.

7

Podman was created to be an easy replacement for Docker. In contrast, NS8 was developed with completely different goals compared to Kubernetes.

8

Due to the complexity and overhead of something such as Kubernetes (not even mentioning the difference in scope of the project) it will be unlikely that such a feature ever gets developed.

Also, if some app has a Helm chart as a deployment option, probably deploying it on something else than Kubernetes is fine. However if there is only a Helm chart for deploy, that probably must run on Kubernetes, it’s unlikely that you’ll need it somewhere else

EDIT: something like this was actively developed on TrueNAS, which now discontinued for the complexity of the project.

1 Like
9

No, it was discontinued because iXSystems (the TrueNAS devs) pulled out the rug out from under their feet by announcing that they were removing Kubernetes from TrueNAS with the next release (expected in October). TrueCharts is very much alive and well[1], but they aren’t publishing charts for TrueNAS any more (but they are working on a migration path for those who are currently running their apps under TrueNAS, and it looks like that’s coming along nicely).

iX claimed Helm charts were too complex for them, but for some reason TrueCharts were able to build a catalog of them that was ~7x larger, more up-to-date, and more featureful than what iX ever delivered, despite having no full-time staff, or indeed employees of any kind. Based on comments Kris Moore has made, I suspect the reason for this discrepancy is that iX was never committed to the k3s ecosystem in the first place.

Not that any of this is really relevant to NS8 or even NS9…

  1. though they’ve pissed off a lot of users, which I’m sure affects how many users they still have–their interpersonal skills aren’t the best ↩︎

1 Like
10

I wasn’t talking about the charts per se! They did an ENORMOUS job, I’ve looked into it in the past and it’s really complex covering everything.

The underlying issue is maintaining a working kubernetes cluster while not having a clue on what is going on underneath! (Well, most of their users, debugging must have been a nightmare)

I understand the issues and the challenges, I agree that pulling the plug might be a not the happiest idea, however I can understand the why :smiling_face_with_tear:

1 Like
11

So far I know nothing is impossible that pertains to code. We’ve come a long way as a species.

If pod an can manage kubernetes, same way it can manage docker. I wonder why it’s not possible to be implemented as a NS8 app.

12

Containers within containers? It’s

1995×1500 209 KB

13

that movie got me thinking