51–60 of 89 posts
This is awesome! One of my problems with showing clients the ability of GKE is having to pay a lot of money to demonstrate. How complete is this? Can I do the usual ingress/LB annotations for GKE and apply them to an on-prem instance?
Since this runs on vSphere presumably it will cost far far more than public GKE.
Earlier quoted context omitted.
What is the value prop then, for someone who already runs open source Kubernetes on-prem? Why should he pay extra for GKE on-prem?
Excellent question. GKE On-Prem is a Google provided, validated and supported distribution of Kubernetes and extensions that offer a GKE-like experience in your on-premise datacenter. It makes it easy to install and upgrade Kubernetes and provides access to GCP services such as monitoring, logging, metrics, security and auditing for your on-premise installation. It is the foundational component of the Cloud Services…
Basically, this is yet another paid packaged Kubernetes distribution, that has the explicit goal to do "Hybrid clustering" so that it is easier to lure the customer back to GKE. Do I get that right ?
Does it need some special hardware to run on?
Quick note though - We are exploring additional options, such as bare metal support, based on customer demand.
Very excited to test this out, we have lots of use cases that will benefit from it.
Hey Weston here from the GKE On-Prem team. Wifi is spotty at the conference but I'll try to answer questions as they come in.
Earlier quoted context omitted.
Excellent question. GKE On-Prem is a Google provided, validated and supported distribution of Kubernetes and extensions that offer a GKE-like experience in your on-premise datacenter. It makes it easy to install and upgrade Kubernetes and provides access to GCP services such as monitoring, logging, metrics, security and auditing for your on-premise installation. It is the foundational component of the Cloud Services…
What is the benefit, if you get the same output from "kubectl" as regular GKE, or from any other distro. Basically, this is yet another paid packaged Kubernetes distribution, that has the explicit goal to do "Hybrid clustering" so that it is easier to lure the customer back to GKE. Do I get that right ?
Now, the benefit of upstream K8s is that your dev team can build apps and containers without proprietary APIs; so when you are ready to move to the cloud you are not locked-in.
Earlier quoted context omitted.
What is the benefit, if you get the same output from "kubectl" as regular GKE, or from any other distro. Basically, this is yet another paid packaged Kubernetes distribution, that has the explicit goal to do "Hybrid clustering" so that it is easier to lure the customer back to GKE. Do I get that right ?
What we have found out is that most on-prem customers are eager to move to the cloud. Practically it's not easy to just lift-and-shift. So think of this is a ramp to the cloud. Now, the benefit of upstream K8s is that your dev team can build apps and containers without proprietary APIs; so when you are ready to move to the cloud you are not locked-in.
That being said, why would I not use the actual free upstream Kubernetes for my on-prem distribution ? (with the help of one of the thousands installer out there like kube-adm, kubespray, etc).
What I have seen working with Kubernetes for quite a while, is that the lowest common demominator is the YAML definitions for your workloads (what you want to run on your Kubernetes cluster). Those should be portable accross any Kubernetes distribution, on-prem or on the cloud. As far as I can tell, today this is already the case.
Is the benefit in this case that you can use the Google ecosystem for logs etc ?
So the big question is... Can we point this at aws and get Google to manage our aws kubernetes Installs... Given the massive shambles eks turned out to be, that would be great.
Earlier quoted context omitted.
What we have found out is that most on-prem customers are eager to move to the cloud. Practically it's not easy to just lift-and-shift. So think of this is a ramp to the cloud. Now, the benefit of upstream K8s is that your dev team can build apps and containers without proprietary APIs; so when you are ready to move to the cloud you are not locked-in.
Thanks. I agree that lift and shift never happens easily in real life. That being said, why would I not use the actual free upstream Kubernetes for my on-prem distribution ? (with the help of one of the thousands installer out there like kube-adm, kubespray, etc). What I have seen working with Kubernetes for quite a while, is that the lowest common demominator is the YAML definitions for your workloads (what you want…
None of them actually provision your infra for you (VMs, LB rules etc). GKE On-Prem will.
Earlier quoted context omitted.
The master node is on-prem? Does that mean that this requires that Google has permanent access to my intranet ?
Google K8s specialist here. The entire cluster is on-prem. At the moment, you can optionally leverage a secured tether to manage your cluster in GCP with the same management features you've come to expect with GKE proper. If the connection is lost, your cluster is still fully functional, so no there is no requirement for permanent access to your intranet. The access, when it exists, is also secured to only permit spe…