Infra person here, this is such the wrong take.

> Do I really need a separate solution for deployment, rolling updates, rollbacks, and scaling.

Yes it's called an ASG.

> Inevitably, you find a reason to expand to a second server.

ALB, target group, ASG, done.

> Who will know about those undocumented sysctl edits you made on the VM

You put all your modifications and CIS benchmark tweaks in a repo and build a new AMI off it every night. Patching is switching the AMI and triggering a rolling update.

> The inscrutable iptables rules

These are security groups, lord have mercy on anyone who thinks k8s network policy is simple.

> One of your team members suggests connecting the servers with Tailscale: an overlay network with service discovery

Nobody does this, you're in AWS. If you use separate VPCs you can peer them but generally it's just editing some security groups and target groups. k8s is forced into needing to overlay on an already virtual network because they need to address pods rather than VMs, when VMs are your unit you're just doing basic networking.

You reach for k8s when you need control loops beyond what ASGs can provide. The magic of k8s is "continuous terraform," you will know when you need it and you likely never will. If your infra moves from one static config to another static config on deploy (by far the usual case) then no k8s is fine.

You’d be swapping an open-source vendor independent API for a cloud-specific vendor locked one. And paying more for the “privilege”

Another reason to use k8s is the original:

When you deploy on physical hardware, not VMs, or have to otherwise optimize maximum utilization out of gear you have.

Especially since sometimes Cloud just means hemorrhaging money in comparison to something else, especially with ASGs

You don't need to use an overlay network. Calico works just fine without an overlay.

I'm sure the American Sewing Guild is fantastic, but how do they help here?