If you're looking to standup a kubernetes server and not on AWS, take a look at kubeadm[0][1]. kubeadm does just enough to build a cluster and not much more -- it's a really light-feeling (even though what it sets up is complicated) bit of kit.
I use it to run on baremetal, and it's a wonderfully simple and robust tool (as well as officially supported) -- it's almost too good, because you should really know everything it's doing and if you use it from the start it's easy to get lost when something goes wrong (most of the time nothing will, but eventually something will).
[0]: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kub...
The difference between kubeadm and 'The Hard Way' is setting up a ton of certificates you then have to manage and manifests/config for etcd, kubelet, kube-proxy, kube-apiserver, kube-controller-manager, and core-dns. If you diff the default manifests of kubeadm and 'The Hard Way' you'll find they're not especially different.
You should still take the time to read the docs on the components and decide if you want to make changes. 'The Hard Way' doesn't explain what's going on any more than kubeadm does. It's just a set of instructions to follow (that are GCP specific).
The end results are similar but the process is vastly different. kubeadm is almost a one-shot tool, doing it the hard way is a learning process. I was trying to say that obviously when you want to just get it done (or script your cluster) then use kubeadm, but if you're learning k8s it's better to do it the hard way at least once. Building an intuition for for the system is made up of (and where to go/which logs to look at when something goes wrong) is important.
> 'The Hard Way' doesn't explain what's going on any more than kubeadm does
Even just following a guide, running the ancillary tools yourself, downloading and running the binaries, etc is way more explanation than kubeadm or other tools give you -- 90% on a fresh machine you just run kubeadm and you're "done" (for some sense of the word).
Before kubernetes the hard way[0] (which is a fantastic resource, though it's gcp specific) existed, I used the CoreOS guides[1] (this was before they started just pushing "use tectonic" and obviously before they were bought out and essentially merged into atomic/fedora/whatever) -- they were fantastic and did more of a walk through of the what and why of the pieces of k8s. Reading through these guides was essential to building my intuition about k8s (I've even written about the process[2]), and I think it's important for people to do this experimentation as well.
One of the best things about k8s is it's ability to unchain you from cloud providers -- using only managed k8s (without something like crossplane[3]) would be effectively squandering that advantage IMO. Yes most companies don't actually need to run multi-cloud, but I expect that the ability to offer k8s as a managed service interface will make it easy for anyone to become/run a cloud provider, and that's a future I want to see -- more cloud providers means more competition which means a better world for startups and those who consume hosting services.
[0]: https://github.com/kelseyhightower/kubernetes-the-hard-way
[1]: https://coreos.com/kubernetes/docs/1.2.2
[2]: https://vadosware.io/post/fresh-dedicated-server-to-single-n...