Enhance README.md with commands for creating resources

[robmorgan]

Hi Yori,

I was trying to use Kubergrunt to deploy Helm to a GKE cluster. Would it make sense to add a few lines to the README.md file to illustrate how to create a dedicated ServiceAccount and namespace for Helm.

e.g:

❯ kubectl create namespace tiller-world
namespace "tiller-world" created

❯ kubectl create serviceaccount tiller --namespace tiller-world
serviceaccount "tiller" created

That way the user can get started quicker and avoid errors like: ERROR: namespaces "tiller-world" not found if they then run:

kubergrunt helm deploy \
    --tiller-namespace tiller-world \
    --resource-namespace dev \
    --service-account tiller \
    --tls-common-name tiller \
    --tls-org Gruntwork \
    --tls-org-unit IT \
    --tls-city Phoenix \
    --tls-state AZ \
    --tls-country US \
    --rbac-group admin \
    --client-tls-common-name admin \
    --client-tls-org Gruntwork

It also removes the ambiguity from the following statement:

Note: This command does not create Namespaces or ServiceAccounts, delegating that responsibility to other systems.

[yorinasub17]

Makes sense! It's on my radar, but I haven't gotten around to it. There are a few reasons for deprioritizing:

• I wasn't sure what are the issues we will run into on EKS and GKE. I wanted to make sure we had examples that worked.
• The tricky bit is making namespaces and service accounts that fit the security model. This includes creating the RBAC roles and bindings. It is probably useful to have several scenarios as well (e.g if they want a clusterwide Tiller but kubergrunt TLS management).
• Most of our customers are likely to use the Terraform wrappers we provide in GKE, EKS, and terraform-kubernetes-helm, which means this won't be an issue.

I think once all the code is working in the GKE and EKS modules, we can come back and revisit the dedicated docs in kubergrunt.