nanocl
nanocl copied to clipboard
next-hat
Feature: Kubernetes-Compatible Resource Schema and API
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.
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.
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.
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
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.
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!