Add functional tests

[Cryptophobia]

From @krancour on March 9, 2016 5:42

The main barrier to this from the onset is that router requires a k8s apiserver to talk to...

I'm thinking of using a containerized, single node k8s to fulfill that requirement. See http://kubernetes.github.io/docs/getting-started-guides/docker/

Router config is driven off of annotations on the router rc, application services, and secrets. It's probably possible to see the containerized k8s with some of these things and then assert that router-generated nginx config appears as expected.

The obvious sticky point here might be that the containerized k8s needs to run privileged.

Copied from original issue: deis/router#140

[Cryptophobia]

From @krancour on March 14, 2016 21:9

Just a quick update on this. This turns out to not be at all as easy as it looks at first glance.

So far, I have encountered two major issues:

1. From the k8s docs referenced in the OP:

   Many of these containers run under the management of the kubelet binary, which attempts to keep containers running, even if they fail. So, in order to turn down the cluster, you need to first kill the kubelet container, and then any other containers.

   You may use docker kill $(docker ps -aq), note this removes all containers running under Docker, so use with caution.

   This means there isn't a reliable way to shut down the containerized test-cluster without possible adverse affects on the other containers running on the same host.

2. Running a k8s cluster via docker as documented in the link in the OP will have the apiserver binding to the host machine's localhost:8080. This is somewhat problematic because folks using docker-machine won't be able to connect to the test cluster using kubectl from their Mac. Fixing this would require making the apiserver bind to 0.0.0.0:8080 on the host machine (docker-machine), and that in turn would require customizations to the hyperkube image. Alternatively, kubectl could be included in the deis/go-dev image used for Deis component development, and then containerized processes could be used to manipulate the test cluster from within the docker host-- e.g. to submit a test manifest for the router. I'll open a separate issue against deis/docker-go-dev to propose this.

Ultimately, I think this needs to be deferred for a bit until we have improved capabilities with regard to bringing up (and bringing down) a fully containerized k8s cluster. Perhaps there is room for a new tool that makes short work of this and can be re-used across projects to enable k8s clusters for functional testing. (I'm imagining something in the same vein as micro-kube... perhaps "nano-kube".)

[Cryptophobia]

From @jgmize on March 15, 2016 2:48

https://github.com/mikedanese/k8s-on-k8s or https://github.com/polvi/monokube might be helpful for this.

[Cryptophobia]

From @krancour on March 15, 2016 3:2

@jgmize thanks for this. I'll definitely be giving those a look.