This is truly interesting to me. Why?

I am not the person you asked this question to, but I would probably do the same so I will answer:

Once you get used to it, it just makes managing things simple if you always use it for everything. I have a personal harbor service that I run on my local cluster that has all my helm charts and images, and i can run a single script that sets up my one node cluster, then run a helm install that installs cert-manager and my external-dns, and now I can deploy my app with whatever subdomain I want and I immediately get DNS set up and certs automatically provisioned and rotated. It will just work.

1. Assuming managed service, it frees me from host OS management. So basically the same proposition, as good old "PHP+MySQL" hosters. You upload your website, they make sure it works. But without limitations and with much better independence.

2. It allows me to configure everything using standard manifests. I need to provision the cluster itself initially, then everything could be done with gitops of various automation levels. I don't need to upload my pages via FTP. My CI will build OCI image, publish it to some registry, then I'll change image tag of my deployment and it'll be updated.

3. It allows to start simple, and extend seamlessly in the future. I can add new services. I can add new servers. I can add new replicas of existing services. I can add centralized logging, metrics, alerts. It'll get more complicated but I can manage the complexity and stop where I feel comfotable.

4. One big thing that's solved even with the simplest Kubernetes deployment is new version deployment with zero downtime. When I'll update image tag of my deployment, by default kubernetes will start new pod, will wait for it to answer to liveness checks, then redirect traffic to new pod, let old pod to gracefully stop and then remove it. With every alternative technology, configuring the same requires quite a bit of friction. Which naturally restricts you to deploy new versions only at blessed times. With Kubernetes, I started to trust it enough, I don't care about deployment time, I can deploy new version of heavily loaded service in the middle of the day and nobody notices.

5. There are various "add-ons" to Kubernetes which solve typical issues. For example Ingress Controller allows the developer to describe Ingress of the application. It's a set of declarative HTTP routes which will be visible outside and which will be reverse-proxied to the service inside. Simplest route is https://www.example.com/ -> http://exampleservice:8080, but there's a lot more to it, basically you can think about it as nginx config done differently. Another example is certificate manager, you install it, you configure it once to work with letsencrypt and you forget about TLS, it just works. Another example is various database controllers, for example cloudnativepg allows you to declaratively describe postgres. Controller will create pod for database, will initialize it, will create second pod, will configure it as replica, will perform continuous backup to S3, will monitor its availability and switch master to replica if necessary, will handle database upgrades. A lot of moving parts (which might be scary, tbh), all driven by a simple declarative configuration. Another example is monitoring solutions, which allow to install prometheus instance and configure it to capture all metrics from everything in cluster along with some useful charts in grafana, all with very little configuration.

6. There are various "packages" for Kubernetes which essentially package some useful software, usually in a helm charts. You can think about `apt-get` but for a more complicated set of services, mostly pre-configured and typically useful for web applications. The examples above are all installable with helm, but they add new kubernetes manifest types, which is why I called them "add-ons", but there are also simpler applications.

Just for the record, I don't suggest that to everyone. I spent quite a bit of time tinkering with Kubernetes. It definitely brings a lot of gotchas for a new user and it also requires quite a bit of self-restrictions for experienced users to not implement every devops good practice in the world. Sometimes maybe you don't even want to start with ingress, I saw cluster which used manually configured nginx reverse proxy instead and it worked for them. You can be very simple with Kubernetes.