[tostaki]

Yeah but is still not as managed as I want. You still need to populate a Kubernetes cluster which is 3 node minimum. Instances show up in your instances list and you still have to be careful to pop your instances in different zones/region for availability.

In an ideal world I just want to run containers in a region with a LB in front, I don't care on which Kubernetes cluster they are. That the use case hyper.sh seems to address (but I didn't test it to be honnest).

[gtaylor]

Once you've got the GKE cluster stood up (two clicks or so), you don't need to care which cluster you are on. The gcloud CLI remembers whatever you set.

It's very hands-off. And if you ever do want to take more direct control, you've still got the option of doing more or all of it on your own.

[scprodigy]

Let's say you have two images: web and db. Web containers ask for high cpu, but small disk. DB requires big mem and disk.

With GKE, you either have different instance types for different container sizes; or you launch the BIG&TALL VMs for all.

The same story applies to public/private network as well. Point is that in GKE, there are two layers to manage: VM and Containers. In Hyper, the container is the infra.

[010a]

That's a terrible argument considering Hyper gives you no fine-grained control over instance types. You just get a linearly-increasing allocation of CPU cores and RAM.

[rounce]

> 3 node minimum

Since when?

[010a]

Yup, last I checked you can create GKE clusters as small as 1 node.