[WIP][+docs] Autogenerate YAML examples with ksonnet

[jesscodez]

@ncdc @skriss This isn't 100% done but would appreciate your eyes (specifically on cloud-provider-specifics.md since that will give you the best sense of what's changed).

I think it's slightly smoother than having multiple directories for all the possible use cases, but feel free to let me know if this still feels convoluted. Unfortunately the IAM roles/kubectl create secret setup part breaks the flow, but other than writing scripts for those, I don't know how else to smooth the process over.

I still need to check the diffs of my YAML against master (since I think you guys changed some files), run some tests, and remove the 1.7 requirement if all goes well.

Ping me or comment if you have any questions, thanks!

[jrnt30]

Flow:
I think having the common set of files is easier, however there is another layer of abstraction now that makes it difficult to look and intuit the deployment without having to make an effort. I understand there are too many permutations, but if we made an assumption RBAC was enabled and PV was enabled, would it make sense to have provider specific versions of the generated yaml available for quick perusal?

Credentials:
For the create secret part, could the credentials-ark file (which seems common across all your examples) be volume mounter or base64 encoded in the Makefile and passed in as an argument to the Ksonnet call? Then you could create the secret via KSonnet and use the encoded var as the value as part of the generated files.

The drawback is that there is something sensitive there then, however having someone create the credentials-ark file in the first place is essentially already doing that.

Future:
There is some discussion around #52 to install these things. Perhaps we add in a --dry-run option and integrate a lot of what you have here to make it a bit easier to get started.

[jrnt30]

Another option for structure and cohesion, while a bit more work to setup, may be to keep the folder numbering linear. Instead of going "back" to the common folder for the deployment, perhaps we give the example folders an offset themselves with the provider namespaced so you just "go down the list" for your chose provider.

Setting this up locally I did something like:

├── 00-common/
│   ├── 00-heptio-preq.yaml
│   └── README.md
├── 02-aws/
│   ├── 00-ark-config.yaml
│   └── 10-ark-aws-creds.yaml
├── 02-azure/
│   ├── 00-ark-deployment.yaml
│   └── 10-ark-config.yaml
├── 02-gcp/
│   └── 00-ark-config.yaml
├── 03-deployment/
│   └── 10-deployment.yaml
├── 04-nginx-app/
│   ├── README.md
│   ├── base.yaml
│   └── ns2.yaml
├── README.md

The fact that some of the provider bootstrapping is explicitly looking for env variables while others don't make it a bit more difficult to do properly. It isn't a HUGE amount of duplication to simply provide a specific dir per provider either, in which case the documentation on the cloud-provider-specifics could just be linking to individual subfolders per provider that have all they need in order.

[jesscodez]

@jrnt30 thank you for the comments--they're much appreciated! I am going to close this first because an upcoming version of ksonnet will help us better organize these files---I'll keep your feedback in mind and cc you on that PR when it comes out.