Re:The Horrors of Upgrading Etcd Beneath Kubernetes
by outworlder on Friday July 06, 2018 @09:18PM
(#17476301)
Indeed.
But I think that doesn't go far enough: I want to provide K8s with a YAML file and have Kubernetes itself go and create and provision a VM for me. I.e, I want to "kill" Terraform. I don't care about a 'fabric' network (although that could be convenient), just give me an IP that I can reach even it if is external to the cluster. VMs could be just one more resource that can be created or destroyed by k8s, just like network-based storage today.
I haven't found this exact use-case implemented yet. If noone else builds it in the coming months I'll probably start doing it.
Re:The Horrors of Upgrading Etcd Beneath Kubernetes
by smarterclayton on Friday July 06, 2018 @11:55PM
(#17476890)
We did something simple for GCP and CI jobs, when we needed to have VMs in a certain project to launch Kubernetes single node testing - https://github.com/openshift/ci-vm-operator/
The base pattern should be pretty easy to modify, although the use case here is very specific.
One of the cooler innovations we've seen, and I think we're going to see more of, is the ability to take a non-k8s VM and expose it to the cluster as-if it were just another pod. This would let you schedule and expose RDBMs and other specialized servers through kubernetes while keeping them on a standard VM.
I think that's the win/win approach to bridge the gap.