GKE or App Engine Flex

If you look at what's provided by GCP, as well as each service's features and functionality, GKE and App Engine Flex are very similar in what they do as well as how they do it. For instance, both platforms deploy container images from Container Registry to Compute Engine Managed Instance Groups and expose workloads through a GCP load balancer.  You will also see that the configuration paradigms are very similar for each service.

This is the underlying Compute Engine Instance Group supporting an active GKE node pool:

The Compute Engine Instance Group supporting an App Engine Flex deployment would look almost exactly like this and would use the same scalability functionality to scale the number of running instances up or down.

Historically, App Engine Flex has relied more heavily on GCP for automation and configuration, whereas GKE has left that in the hands of the user. That is changing, with GKE being steadily updated with more platform support for automation and configuration.

A more concrete difference between the two platforms is the amount of functionality GKE provides around workload specification and scalability. App Engine utilizes containers underneath the covers as a means to an end. App Engine workloads are always going to scale up via containers of a single type. GKE is explicitly designed to support and embrace containerized workloads and tooling. GKE provides for a more sophisticated level of scalability, where workloads can run on multiple pods and those pods can then make up multiple containers.

Kubernetes and GKE also have a very compelling story around service discovery via a combination of workload labels and intracluster DNS. Pods can be defined by your labels and then those labeled pods can be discovered by the other pods in your cluster using DNS. This is especially useful in scenarios where you have microservices deployed that need to communicate with one another without, or maybe in addition to, being open to the outside world.