Kubernetes Testing: Using GKE instead of Minikube

Problems With Current Solution

It takes a long time to build

Building minikube from scratch every time takes the lionshare of our travis testing time. If we can just connect to GKE and launch a cluster in a few seconds, we'll get much faster feedback for whether our changes are working or not.

It doesn't really mimic real world kubernetes

We've run into a few bugs in the wild where our minikube-based testing worked fine but we found issues when performing on a multi-node cluster. Many in the k8s community are even moving away from minikube because of these differences in behavior.3. It makes local testing a pain


Proposal: Create GKE testing that committers can turn on

When users submit PRs to kubernetes, there seems to be a buildbot setting that allows the committers to turn on integration testing on the CloudNative clusters. I'm thinking if all k8s testing is reformatted to assume kubernetes rather than minikube, then users can test as much as they want on their own local/GKE clusters and then we can turn on GKEbefore merging.

Google had spoken with us a while back about giving a GKE account for airflow integration, and I wanted to open this up to the community if anyone had strong feelings either way.

Steps:

• Allow users to submit custom airflow images to k8s integration testing
• Make all travis-based setup steps optional
• Remove TOX dependencies from kubernetes builds
• Get a GKE key from google
• Create build option for committers to optionally turn on kubernetes testing.