I'm running a three node cluster on Hetzner Cloud for less than $10 a month. Comprehensive guide and automated provisioning available here: https://github.com/hobby-kube/guide
One of the things about Kubernetes I like most is the likelihood that it reduces the barrier to entry for "PaaS land" (and resultingly "cloud land") for providers like Hetzner (see OVH's recently announced k8s offering[0]).
Once these "baremetal" providers get in the managed (by k8s) game, I'm certain companies will start to spring up and offer/chip away at cloud provider offerings like S3/RDS/etc -- they'll just connect to your k8s infrastructure, and bring their kubernetes-compatible know-how. This is going to cause prices to plummet, as it will make the tiers of value added services more distinct -- i.e. "a platform to run things" on vs. "really good managed databases".
10 from failures (2 or 3 of which directly affected me),
10 emails stating when planned maintenance of certain resources will occur
1 email to let me know of the spectre and meltdown vulnerabilities.
So far i'm pretty happy customer, and sending business their way and migrating client's sites to their cloud offerings.
I've been using Hetzner for roughly 2 years and am a pretty happy customer.
I can say though that the latency is pretty bad when compared to local options -- their server are pretty geographically far from where I and others who use some of my apps access from, and I get ~200ms of latency that I can't do much about. I've looked a traceroute and it's not their network but rather some points in between.
With these shared core machines, I wonder what the performance reliability guarantees available and how it compares to the dedicated core machines.
If you're hosting a website (or a database backing one) there is going to be a natural kind of ebb and flow as traffic comes in, gets processed, and answered. Since you're not utilizing a large amount of CPU consistently this actually fits really well into the shared core model - that's exactly why they can offer it. Even if a subset of requests take twice as long to fulfill this is usually not even noticeable to the user.
On the other hand if you're routinely running a large ETL process, resizing video or images, or any of dozens of other things I'm sure you can think of that are using a lot of CPU for prolonged periods you're going to notice it.
Specifically I have two situations I've run into: My TeamCity build agent will be unpredictable for longer builds - one might finish in 5 minutes, the next might take 10 - and when I had a Windows Server running as an Amazon Workspace alternative (RDP in, run Visual Studio, etc.) things like building and debugging an app were noticeably slower than if I did it locally or on my dedicated server (even with similar specs).
So if CPU usage isn't normally your bottleneck or you're scaling horizontally and CPU performance isn't as important it's a great option that will save you quite a bit. If your workload is very CPU sensitive you probably shouldn't be using a VM anyway and should look into a more dedicated infrastructure, but obviously there is also a middle ground to be had...
The interesting question comes when people start implementing hardware hypervisors and what is the risk profile there.
Security, at the end of the day, isn't about what is secure and what isn't. If you want to be secure, don't get on the internet. Everything else is a exercise in risk tradeoffs and mitigation.
If I was doing anything with PII, cc#'s or any other data I never want to touch I wouldn't use shared hardware without hard thought on it.
For example, they'll typically be on secret mailing lists and aware of security vulnerabilities weeks before you know about them.
Most of the smaller cloud providers seem to run a similar model, I guess it's worth it unless you need predictability.