It takes ur standard docker compose file and runs it transparently in kubernetes (k3s actually). So ur devs don't have cognitive dissonance between testing ur stack locally on ur laptop and making it work on kubernetes in production.
It is primarily meant as a dev tool on ur laptop, and as a replacement for docker compose.
NOTE: kubedock has some automatic compatibility with compose, this is not their goal - https://github.com/joyrex2001/kubedock/blob/e4c8540f63d65e33...
If you are not on the compose ecosystem, this is isnt useful to you.
Just fyi - the hottest thing in the world right now is OpenClaw. This is OpenClaw docker compose yml - https://github.com/openclaw/openclaw/blob/main/docker-compos...
even if you dont do docker compose....everyone else does it anyway.
In my ideal world everyone would use kubernetes, it is the hammer and everything is a nail, but we must recognize that it is difficult for a lot of people to pick up.
That being said, if you’re deploying on kube in production, use kube locally. But if you’re not, dont
if you ever wanna try it again - use kappal. you will get a full k8s but with the UX of docker compose.
Start a privileged pod with the dind image, copy or mount your compose.yaml inside and you should be able to docker compose up and down, all without mounting a socket (that won't exist anyway on containerd CRI nodes)
To go even further, kubevirt runs on kind, launch a VM with your compose file passed in via cloud-init.
At no point, have I invented a new/better method. Perhaps your way is better.
I just recognise that Docker Compose is loved by most open source developers. And invariably any project you touch will have a docker compose setup by default. And it isnt going away, no matter hard anyone tries to kill. Some things are just too well designed. Docker Compose is one of those things.
I'm just making it possible to run those on kubernetes seamlessly.
the standard does not make it mandatory that underlying system should be docker compose (the reference server). it can be anything.
IMHO - kappal is the first project that takes your compose yml file and transparently/drop-in runs it on kubernetes. there is nothing extra you need. It is useful for people who want to maintain their stack as close to production as possible (kubernetes).
If that's not a big goal for you, then this is not very useful for you. But I'd argue ...why do you care if the compose yml is the only think you are using. you get all of kubernetes.
So is any of this tested?
I was just telling some ex coworker friends that there was a great need for a compose frontend to more powerful infra backends, and this feels like the answer.
Once I get working on it I’ll try to add health check support. That is crucial for a lot of what we’re working on.
just curious - i actually didnt focus on healthcheck because i wasnt sure if anyone was using it. are you using it for local dev ?
docker compose is just as heavy. there's not a significant difference between k3s and docker compose.
