[TT-3697] Explicitly specify context/profile when manipulating local sandbox Kube cluster(s)

[jlucktay]

trafficstars

The Makefile and local dev instructions and other bits look like they are dealing with local sandbox cluster(s) via tools like kubectl and kind and helm.

I hit a snag with an oversight like this on another project just recently, where an unrelated and unintended cluster became the target of one of that project's helm install calls.

I think some flags should be set to specify a context/cluster name, to prevent overrunning into other contexts/clusters that the user may already have set up and make sure that these commands are executing against the tyk-operator sandbox cluster.

Flags like so:

• kubectl --context="..."
• kind create cluster --name="..."
• helm --kube-context="..."

From memory, the order of operations would start with kind create cluster --name="..." and then this name value would be the context name to feed forward into kubectl, helm, et al.

[asoorm]

so where do you store the cluster name? in an env var? would you be able to put together a sample PR to illustrate the suggestion - not sure i quite get it yet.

[gernest]

We are already doing something similar to some extent. We have env var CLUSTER_NAME I'm not so sure about minikube profiles though because we don't do anything that is minikube specific.

@jlucktay can you maybe add more details here so I can update #253 to address this too? In the linked PR we move away kind stuff, which will only be used when we detect you are using kind. And we support minikube too.

Minikube/kind specific stuff are only needed because of development. We want to load locally built images into the cluster without requiring you to push to dockerhub.