4 ms·

100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than

100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than the equivalent K8S manifests.

esseph 10mo ago
Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.
- sceptic123 10mo ago
  I don't think that argument matches with they "just need to run a bunch of containers across a few machines"
- lnenad 10mo ago
  But that's not what anyone is arguing here, nor what (to me it seems at least) uncloud is about. It's about simpler HA multinode setup with a single/low double digit containers.
  - esseph 10mo ago
    > I’m really not sure why K8S has become the complexity boogeyman. Was what i was responding to. It's not the app management that becomes a pain, it's the cluster management, lifecycle, platform API deprecations, etc.
- nullpoint420 10mo ago
  Talos has made this super easy in my experience.
- Glemkloksdjf 10mo ago
  Which is fine because it absolutly matches the result. You would not be able to operate hundreds or thousand of any nodes without operation complexlity and k8s helps you here a lot.
this_user 10mo ago
Docker Compose is simple: You have a Compose file that just needs Docker (or Podman). With k8s you write a bunch of manifests that are 70% repetitive boilerplate. But actually, there is something you need that cannot be achieved with pure manifest, so you reach for Kustomize. But Kustomize actually doesn't do what you want, so you need to convert the entire thing to Helm. You also still need to spin up your k8s cluster, which itself consists of half a dozen pods just so you have something where you can run your service. Oh, you wanted your service to be accessible from outside the cluster? Well, you need to install an ingress controller in your cluster. Oh BTW, the nginx ingress controller is now deprecated, so you have to choose from a handful of alternatives, all of which have certain advantages and disadvantages, and none of which are ideal for all situations. Have fun choosing.
- deleted 10mo ago
  [deleted]
- quectophoton 10mo ago
  > Docker Compose is simple: You have a Compose file that just needs Docker (or Podman). And if you want to use more than one machine then you run `docker swarm init`, and you can keep using the Compose file you already have, almost unchanged. It's not a K8s replacement, but I'm guessing for some people it would be enough and less effort than a full migration to Kubernetes (e.g. hobby projects).
- horsawlarway 10mo ago
  This is some serious rose colored glasses happening here. If you have a service with a simple compose file, you can have a simple k8s manifest to do the same thing. Plenty of tools convert right between the two (incl kompose, which k8s literally hands you: https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/ https://kubernetes.io/docs/tasks/configure-pod-container/tra...) Frankly, you're messing up by including kustomize or helm at all in 80% of cases. Just write the (agreed on tedious boilerplate - the manifest format is not my cup of tea) yaml and be done with the problem. And no - you don't need an ingress. Just spin up a nodeport service, and you have the literal identical experience to exposing ports with compose - it's just a port on the machines running the cluster (any of them - magic!). You don't need to touch an ingress until you actually want external traffic using a specific hostname (and optionally tls), which is... the same as compose. And frankly - at that point you probably SHOULD be thinking about the actual tooling you're using to expose that, in the same way you would if you ran it manually in compose. And sure - arguably you could move to gateways now, but in no way is the ingress api deprecated. They very clearly state... > "The Ingress API is generally available, and is subject to the stability guarantees for generally available APIs. The Kubernetes project has no plans to remove Ingress from Kubernetes." https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/ https://kubernetes.io/docs/concepts/services-networking/ingr... --- Plenty of valid complaints for K8s (yaml config boilerplate being a solid pick) but most of the rest of your comment is basically just FUD. The complexity scale for K8s CAN get a lot higher than docker. Some organizations convince themselves it should and make it very complex (debatably for sane reasons). For personal needs... Just run k3s (or minikube, or microk8s, or k3ds, or etc...) and write some yaml. It's at exactly the same complexity as docker compose, with a slightly more verbose syntax. Honestly, it's not even as complex as configuring VMs in vsphere or citrix.
everforward 10mo ago
It's not the manifests so much as the mountain of infra underlying it. k8s is an amazing abstraction over dynamic infra resources, but if your infra is fairly static then you're introducing a lot of infra complexity for not a ton of gain. The network is complicated by the overlay network, so "normal" troubleshooting tools aren't super helpful. Storage is complicated by k8s wanting to fling pods around so you need networked storage (or to pin the pods, which removes almost all of k8s' value). Databases are annoying on k8s without networked storage, so you usually run them outside the cluster and now you have to manage bare metal and k8s resources. The manifests are largely fine, outside of some of the more abnormal resources like setting up the nginx ingress with certs.

100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than the equivalent K8S manifests.

esseph 10mo ago

Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.

sceptic123 10mo ago
I don't think that argument matches with they "just need to run a bunch of containers across a few machines"
lnenad 10mo ago
But that's not what anyone is arguing here, nor what (to me it seems at least) uncloud is about. It's about simpler HA multinode setup with a single/low double digit containers.
- esseph 10mo ago
  > I’m really not sure why K8S has become the complexity boogeyman. Was what i was responding to. It's not the app management that becomes a pain, it's the cluster management, lifecycle, platform API deprecations, etc.
nullpoint420 10mo ago
Talos has made this super easy in my experience.
Glemkloksdjf 10mo ago
Which is fine because it absolutly matches the result. You would not be able to operate hundreds or thousand of any nodes without operation complexlity and k8s helps you here a lot.

this_user 10mo ago

Docker Compose is simple: You have a Compose file that just needs Docker (or Podman). With k8s you write a bunch of manifests that are 70% repetitive boilerplate. But actually, there is something you need that cannot be achieved with pure manifest, so you reach for Kustomize. But Kustomize actually doesn't do what you want, so you need to convert the entire thing to Helm. You also still need to spin up your k8s cluster, which itself consists of half a dozen pods just so you have something where you can run your service. Oh, you wanted your service to be accessible from outside the cluster? Well, you need to install an ingress controller in your cluster. Oh BTW, the nginx ingress controller is now deprecated, so you have to choose from a handful of alternatives, all of which have certain advantages and disadvantages, and none of which are ideal for all situations. Have fun choosing.

deleted 10mo ago
[deleted]
quectophoton 10mo ago
> Docker Compose is simple: You have a Compose file that just needs Docker (or Podman). And if you want to use more than one machine then you run `docker swarm init`, and you can keep using the Compose file you already have, almost unchanged. It's not a K8s replacement, but I'm guessing for some people it would be enough and less effort than a full migration to Kubernetes (e.g. hobby projects).
horsawlarway 10mo ago
This is some serious rose colored glasses happening here. If you have a service with a simple compose file, you can have a simple k8s manifest to do the same thing. Plenty of tools convert right between the two (incl kompose, which k8s literally hands you: https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/ https://kubernetes.io/docs/tasks/configure-pod-container/tra...) Frankly, you're messing up by including kustomize or helm at all in 80% of cases. Just write the (agreed on tedious boilerplate - the manifest format is not my cup of tea) yaml and be done with the problem. And no - you don't need an ingress. Just spin up a nodeport service, and you have the literal identical experience to exposing ports with compose - it's just a port on the machines running the cluster (any of them - magic!). You don't need to touch an ingress until you actually want external traffic using a specific hostname (and optionally tls), which is... the same as compose. And frankly - at that point you probably SHOULD be thinking about the actual tooling you're using to expose that, in the same way you would if you ran it manually in compose. And sure - arguably you could move to gateways now, but in no way is the ingress api deprecated. They very clearly state... > "The Ingress API is generally available, and is subject to the stability guarantees for generally available APIs. The Kubernetes project has no plans to remove Ingress from Kubernetes." https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/ https://kubernetes.io/docs/concepts/services-networking/ingr... --- Plenty of valid complaints for K8s (yaml config boilerplate being a solid pick) but most of the rest of your comment is basically just FUD. The complexity scale for K8s CAN get a lot higher than docker. Some organizations convince themselves it should and make it very complex (debatably for sane reasons). For personal needs... Just run k3s (or minikube, or microk8s, or k3ds, or etc...) and write some yaml. It's at exactly the same complexity as docker compose, with a slightly more verbose syntax. Honestly, it's not even as complex as configuring VMs in vsphere or citrix.

everforward 10mo ago

It's not the manifests so much as the mountain of infra underlying it. k8s is an amazing abstraction over dynamic infra resources, but if your infra is fairly static then you're introducing a lot of infra complexity for not a ton of gain. The network is complicated by the overlay network, so "normal" troubleshooting tools aren't super helpful. Storage is complicated by k8s wanting to fling pods around so you need networked storage (or to pin the pods, which removes almost all of k8s' value). Databases are annoying on k8s without networked storage, so you usually run them outside the cluster and now you have to manage bare metal and k8s resources. The manifests are largely fine, outside of some of the more abnormal resources like setting up the nginx ingress with certs.