Let me start saying that I love Kubernetes, I even have a personal one for my things but I'm an experienced DevOps and it is in my spare time.
Usually, you want the complexity of the technical solutions your company uses to increase on complexity accordingly to your needs.
You may think: whoa! I need to have autodiscovery between my microservices, a load balancer for the HTTP API and everything must be declared as a code to be maintainable without a shady guy from Ops
And of course, you need that, especially the last part, but is really Kubernetes the only thing that can give you that?
Its a tool written in Python that let you define environments using YAML.
The good things about this are that you can use this to make and maintain the developer's local environment and If you have only one production server (very little startup) you can even use the same YAML files used to develop your solution to deploy it into the server.
The bad thing is that it is not really designed to run on a cluster so you are limited to a one and only production machine.
It's a solution that comes with Docker and allows to manage several machines with Docker as one cluster.
In essence, Swarm and Kubernetes do the same but are not the same. The good thing about Swarm is that you can reuse the same YAML files that you were using with docker-compose and, in the pipeline, add the scaling stuff they need on Swarm.
You can use things like Traefik to manage the access and you can reuse it if you switch to Kubernetes later on.
The only problem is that it lacks good observability when reaching a good size.
Kubernetes is a generalist container orchestrator, therefore it doesn't deal with Docker concepts but with abstractions that represent concepts inside the ecosystem, like Pods.
The good thing about Kubernetes is that is really easy to manage deploys and release cycles using either Kubernetes definitions (YAML or JSON) or Helm charts (a kind of deploy config on repositories) and you can even, with some tinkering around, use docker-compose files to do the deploys. It is also absurdly robust once correctly set up.
The cons are that it is not an easy piece of software to manage (the internals) and deploy, thus needing a DevOps team taking care of it.
The key here is to understand where you are, if you are still preparing an MVP to launch and the only thing in your infrastructure is a webserver then you are better off with docker-compose and progressively go up.
Also, if your Kubernetes will have more orchestrator services than services is orchestrating then you may be better off with Swarm.
All I wanted with this is to make people think about the technologies they choose to use, accidental complexity carries a cost and it should not be taken lightly so don't let the hype get you.