dekube — Kubernetes devolver
dekube.io
An ecosystem that converts Kubernetes manifests into plain docker compose setups. Engine, extensions, distributions, package manager. Public domain.

Hey there, it’s me again with my cursed project. Last time is said “i basically reinvented Kubernetes”. But the voices won and I legit did.

Last time it was a cursed novelty. A random script made by some autistic dude with too much time on its hand.

Now it’s become its own project, with ecosystem and overpriced .io domain. For no reason other than : It’s cursed, but it works beautifully.

Every Kind is handled by its distinct code. Everything is pluggable, nothing is hardcoded. The next layer of hell is for someone else to write Docker Swarm extensions. Won’t be me.

I am, again, very sorry. Sorry for releasing this thing into the world as a complete, working, product.

And sorry for keeping spamming it. I will stop, i promises (the voices will never)

  • dimeslime@lemmy.caEnglish
    6·
    8 hours ago

    I hate that you hate to write this, but good work doing it. I never understood why people perceive k3s as hard and then write pages of docker compose yaml instead. Admittedly my day job got me a CKA, but running k3s at home is barely a step up from docker compose.

    • ebc@lemmy.caEnglish
      2·
      2 hours ago

      I’m one of these people. Simple answer? It’s the documentation. I’ve given k8s an honest try, but it honestly feels like the “draw the rest of the fucking owl” meme, starts way basic then gets wayy too hard without explaining anything in between.

      Meanwhile docker is 1 file, 1 command to get started.

      Edit: I just realized you were talking about k3s, not k8s. Is that something different somehow? Google says it’s a “k8s” distribution? WTF would that be?

      • dimeslime@lemmy.caEnglish
        1·
        18 minutes ago

        Yeah for reference I’d probably never run the full open source Kubernetes distribution unless I had to, and that would mean having access to millions of dollars of hardware in a datacenter.

        K3s is a lightweight Kuberbetes distribution that implements the full Kuberbetes API (full-ish? Maybe?). It’s super easy to run on Linux, I run a 3 node cluster with GPUs at home. Its only real downside is the backend is a single point of failure, but that’s ok for me cause it’s run from my storage node with all the disks, so if that disappears I have bigger problems.

        There are others like microk8s which can handle control plane failures, but it’s for that reason that I also dislike it - they wrote their own distributed sqlite instance and it failed on me, a story for another time.

        Minikube can run on your desktop, it’s also an option.

        But if you have docker desktop, you also have a built in Kuberbetes API server too, just have to enable it with one checkbox (not a full API server, but good enough for installing helm charts).

        Kind is a docker based Kubernetes server but I think that’s in the realm of testing not running. I believe K0s is in this camp too but could be wrong.

        At work the daily driver will be one of EKS, GKE, AKS, or whichever cloud providers implementation. They’re effectively free and a loss leader because you’ll pay for instances anyway (at least on EKS, I’m most familiar with that one).

        But if you’re interested in learning, start with docker desktops k8s API, or minikube, or k3s if you have a Linux host or raspberry Pi lying around.

        🌈The more you know!🌈