Feature: Kubernetes-Compatible Resource Schema and API

[dtsulik]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
For starters nanocl should be able to consume existing k8s yaml schemas for resources without need for external tool. In the long term, achieving feature parity with k8s will significantly ease adoption. This extends to API as well, it should have same response/request models as k8s. This would allow nanocl to take advantage of existing tools like ArgoCD, OPA and many more.

Describe alternatives you've considered
Alternative to natively supporting processing k8s compatible schemas would be to have some converter tool, which makes migration much more complex process.

Additional context
K8s has incredibly rich ecosystem, nanocl being compatible with them would be huge benefit for the project.

[leon3s]

Hey @dtsulik, thanks for your interest in the project !

The main idea behind nanocl is to be a developer tools first and make things simpler than kubernetes.
This is why we don't have the same spec.
Currently maintaining 2 specs will be huge work as i'm alone.
I'll keep the issue open, if the community chooses to follow the kubernetes API, we will, as nanocl is also a community tool.
But i'll prefer to see a rewrite of argoCD for nanocl to be honest, with his virtual machine capability it shouldn't be a big deal.
I wanted to make something similar as github workflows but that run on nanocl.

[waqasraz]

I agree with @dtsulik to keep the same specs as k8s if we want nanocl adoption. Because we know naming is hard in computer science, if we come up with our APIs, most likely, we will make things complex rather than simpler.

[anonkey]

I think converter tool is the best agreement, but maintain it could be a mess so should be done by someone using k8s and nanocl regularly

[ivanovaleksandar]

This does not have to be a direct implementation, but a separate opt-in component that and does translations for kubernetes API objects to the nanocl API objects.

[leon3s]

A translations tools like we did for docker compose is the solution i would prefer, if anyone with good knowledge of the Kubernetes spec would like to work with me on this, feel free to reach me out on discord or using mail!