The Google Container Engine's (GKE) documentation says: "There’s no vendor lock-in, you’re free to take your workloads out of Container Engine and run them anywhere Kubernetes is supported, including on your own on-premise servers."
Still, GKE is a managed environment for Kubernetes and I was wondering how difficult it would be to take your workloads out of GKE after, say, 2-3 years and run them on your own premises. What do you need to pay attention to maintain maximum portability?
Your workloads will migrate out of GKE without much modification; the only things you would need to change are those tied to the cloud provider (ingress, persistent volumes, etc). Note that this is the same regardless of whether you are running in GKE or on GCE, AWS, Digital Ocean -- as you move environments you will need to make small tweaks to your workload definition if and where it is tied directly to the environment.
The larger change is migrating out of the hosted environment into a cluster that you manage yourself. You will have both the control and responsibility to configure many aspects of your system (authentication and authorization, admission controllers, flags to the various system components, base operating system, etc) that come together to make a smoothly operating cluster. You will also be in charge of managing upgrades for your cluster, which means you will need to keep up with Kubernetes releases to ensure that you are picking up patches for critical bugs and security vulnerabilities.
We build software on Kubernetes. We use GKE for development purposes, and Kubernetes on AWS for production. This works fine. (We use GKE because it's a lot easier to spin up Kubernetes clusters on-demand for developers than in AWS.)
Your primary constraint on portability is going to be your data. If you start using, say, Spanner on GKE, you're not going to be able to migrate very easily to your own Kubernetes instance. So you need to really pay attention to your use of other Google services.