compose-on-kubernetes VS kind

enjoy the title says, https://github.com/docker/compose-on-kubernetes is no longer maintained, with no explanation why and no recommendations on what to use instead. i've briefly looked at Kompose as an alternative, but i don't like how it's a converter. i'd prefer the source of truth to exist inside a single, simple‏‏‎‏‏‎‏‏‎‏‏‎­YAML file, like a docker-compose file. what would you recommend?

https://github.com/docker/compose-on-kubernetes looks dead now, maybe for misguided political reasons while they remain in denial that swarm might compete? But it's too bad, there's no reason some k8s api/operator thing can't make this frictionless.

Still, someone already mentioned docker-desktop having some tricks for deploying straight to aws and [there is definitely a way to do this with ecs](https://aws.amazon.com/blogs/containers/deploy-applications-...). There's also tools like kompose which translate configs automatically and are suitable for use in a pipeline, so the only thing you need is a compose file in version control.

So yes, you can still basically use compose in production, even on a non-swarm cluster, and it's fine. A lot of people that push back against this are perhaps just invested in their own mad kubectl'ing and endless wrangling with esoteric templates and want to push all this on their teammates. From what I've seen, that's often to the detriment of local development experience and budgeting, because if even your dev environment always requires EKS, that gets expensive. (Using external/managed databases is always a good idea, but beside the main point here I think. You can do that or not with or without docker-compose or helm packages or whatever, and you can even do that for otherwise totally local development on a shared db cluster if you design things for multi-tenant)

At this point I'll face facts that the simple myth here (docker-compose is merely a toy) is winning out over the reality (docker-compose is partly a tool but isn't a platform, and it's just a format/description language). But consider.. pure k8s, k8s-helm, ECS cloudformation, k8s-terraforming over EKS, and docker-compose all have pretty stable schemas that require almost all the same data and any one of them could pretty reasonably be considered as a lingua-franca that you could build the other specs from (even programmatically).

From this point of view there's an argument that for lots of simple yet serious projects, docker-compose should win by default because it is at the bottom of the complexity ladder. It's almost exactly the minimal usable subset of the abstract description language we're working with, and one that's easy to onboard with and requires the least dependencies to actually run. For example: even without kompose it's trivial to automate pulling data out of the canonical docker-compose yaml and injecting that into terraform as part of CD pipeline for your containers on EKS; then you keep options for local-developer experience open and you're maintaining a central source of truth for common config so that your config/platform is not diverging more than it has to.

I'm an architect who works closely with ops, and in many ways not a huge fan of docker-compose. But I like self-service and you-ship-it-you-run it kinds of things that are essential for scaling orgs. So for simple stuff I'd rather just use compose as the main single-source-of-truth than answer endless bootstrappy questions about k8s or ECS if I'm working with others who don't have my depth of knowledge. (Obviously compose has been popular for a reason, which is that kubernetes really is still too complicated for a lot of people and use-cases.) Don't like these ready-made options for compose-on-ECS, or compose-to-k8s via kompose? Ok, just give me your working docker-compose and I'll find a way to deploy it to any other new weird platform, and if I need some pull-values/place-values/render-template song and dance with one more weird DSL for one more weird target deployment platform, then so be it. I've often found the alternative here is a lot of junior devs deciding that deployment/dev-bootstrap is just too confusing, their team doesn't help them and pushes them to an external cloud-engineering team who doesn't want to explain this again because there's docs and 10 examples that went unfollowed, so then junior devs just code without testing it all until they have to when QA is broken. Sometimes the whole org is junior devs in the sense that they have zero existing familiarity with docker, much less kubernetes! Keep things as simple as possible, no simpler.

Seen this argument a million times, and no doubt platform choices are important but even pivoting on platforms is surprisingly easy these days. When you consider that compose is not itself a platform but just basically a subset of a wider description language, this all starts to seem a bit like a json vs yaml debate. If you need comments and anchors, then you want yaml. If you need serious packaging/dependencies of a bunch of related microservices, and a bunch of nontrivial JIT value lookup/rendering, then you want helm. But beyond org/situation specific considerations like this, the difference doesn't matter much. My main take-away lately is that leadership needs to actually decide/enforce where the org will stand on topics like "local development workflows"; it's crazy to have a team divided where half is saying "we develop on laptops with docker-compose" and half is saying "we expect to deploy to EKS in the dev environment". In that circumstance you just double your footprint of junk to support and because everyone wants to be perfectly pleased, everyone is annoyed.

To get started, you'll need to install clusteradm and kubectl and start up three Kubernetes clusters. To simplify cluster administration, this article starts up three kind clusters with the following names and purposes:

Kind: is a tool for running local Kubernetes clusters using Docker container "nodes." It was primarily designed for testing Kubernetes itself but can also be used for local development or continuous integration.

Fortunately, just as projects like kind and Minikube enable developers to spin up a local Kubernetes environment in no time, CRC, also known as OpenShift Local and a recursive acronym for "CRC - Runs Containers", offers developers a local OpenShift environment by means of a pre-configured VM similar to how Minikube works under the hood.

I recently purchased a used Lenovo M900 Think Centre (i7 with 32GB RAM) from eBay to expand my mini-homelab, which was just a single Synology DS218+ plugged into my ISP's router (yuck!). Since I've been spending a big chunk of time at work playing around with Kubernetes, I figured that I'd put my skills to the test and run a k3s node on the new server. While I was familiar with k3s before starting this project, I'd never actually run it before, opting for tools like kind (and minikube before that) to run small test clusters for my local development work.

Features compared to https://kind.sigs.k8s.io/

Kind allows you to run a Kubernetes cluster inside Docker. This is incredibly useful for developing Helm charts, Operators, or even just testing out different k8s features in a safe way.

Check out KinD

If you're just messing around, just use kind (https://kind.sigs.k8s.io) or minikube if you want VMs (https://minikube.sigs.k8s.io). Both work on ARM-based platforms.

You can also use k3s; it's hella easy to get started with and it works great.

We'll install APIClarity into a Kubernetes cluster to test our API documentation. We're using a Kind cluster for demonstration purposes. Of course, if you have another Kubernetes cluster up and running elsewhere, all steps also work there.

yes I know there is lens, but it does not allow me to see logs of multiple pods at same time and what is even more important it is not friendly for ephemeral clusters - in my case with help of kind I am recreating whole cluster each time from scratch