GKE On-Prem is packaged with upstream K8s. So for your team that currently uses `kubectl` to deploy or manage workloads, there won't be any differences.
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 Platform, and is how Google "brings the cloud to you".
CSP combines Kubernetes both in your on-premise datacenter (GKE On-Prem) and Google-managed Kubernetes in GCP (GKE) with Istio and other CI/CD (Cloud Build) and serverless (Knative) products. You can leverage this suite of products to both modernize your existing on-premise applications and build new applications in the cloud.
Additionally, Google will be offering phone and email support similar to the existing GCP support packages.
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.
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 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 ?
> 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).
None of them actually provision your infra for you (VMs, LB rules etc). GKE On-Prem will.
Ok, thanks I got it, you are bundling everything into a VMWare image, that boots ready to use.
Is it fair to say that this is similar to Canonical Ubuntu MAAS + Juju Kubernetes? I'm sure that Red Hat Openshift must have something similar also to install directly on a pool of managed bare metals.
GKE On-Prem is packaged with upstream K8s. So for your team that currently uses `kubectl` to deploy or manage workloads, there won't be any differences.