<p>Is there a way you can run kubectl in a 'session' such that it gets its kubeconfig from a local directory rather then from <code>~/.kubeconfig</code>?</p>

<h2>Example Use Case</h2>

<p>Given the abstract nature of the question, it's worth describing why this may be valuable in an example.  If someone had an application, call it 'a', and they had 4 kubernetes clusters, each running a, they may have a simple script which did some <code>kubectl</code> actions in each cluster to smoke test a new deployment of A, for example, they may want to deploy the app, and see how many copies of it were autoscaled in each cluster afterward. </p>

<h2>Example Solution</h2>

<p>As in git, maybe there could be a "try to use a local kubeconfig file if you can find one" as a git-style global setting:</p>

<pre><code>kubectl global set-precedence local-kubectl
</code></pre>

<p>Then, in one terminal:</p>

<pre><code>cd firstcluster
cat &lt;&lt; EOF &gt; kubeconfig
firstcluster
...
EOF
kubectl get pods
p4
</code></pre>

<p>Then, in another terminal:</p>

<pre><code>cd secondcluster/
cat &lt;&lt; EOF &gt; kubeconfig
secondcluster
...
EOF
kubectl get pods
p1
p2
p3
</code></pre>

<p>Thus, the exact same kubectl commands (without having to set context) actually run against new clusters depending on the directory you are in.</p>

<h2>Some ideas for solutions</h2>

<ul>
<li><p>One idea I had for this, was to write a kubectl-context plugin which somehow made kubectl always check for local kubeconfig, setting context behind the scenes if it could before running, to a context in a global config that matched the directory name.</p></li>
<li><p>Another idea I've had along these lines would be to create different users which each had different kubeconfig home files.</p></li>
<li><p>And of course, using something like virtualenv, you might be able to do something where kubeconfig files had their own different value.</p></li>
</ul>

<h1>Final thought</h1>

<p>Ultimately I think the goal here is to subvert the idea that a ~/.kubeconfig file has any particular meaning, and instead look at ways that many kubeconfig files can be used in the same machine, however, not just using the <code>--kubeconfig</code> option but rather, in such a way that state is still maintained in a directory local manner.</p>

<p>AFAIK, the config file is under <code>~/.kube/config</code> and not <code>~/.kubeconfig</code>. I suppose you are looking at an opinion on your answer, so you gave me the great idea about creating <a href="https://github.com/raravena80/kubevm" rel="nofollow noreferrer"><code>kubevm</code></a>, inspired by <a href="https://github.com/raravena80/awsvm" rel="nofollow noreferrer"><code>awsvm</code></a> for the <a href="https://aws.amazon.com/cli/" rel="nofollow noreferrer">AWS CLI</a>, <a href="https://github.com/trobrock/chefvm" rel="nofollow noreferrer"><code>chefvm</code></a> for managing multiple Chef servers and <a href="https://github.com/rvm/rvm" rel="nofollow noreferrer"><code>rvm</code></a> for managing multiple Ruby versions.</p>

<p>So, in essence, you could have a <code>kubevm</code> setup that switches between different <code>~/.kube</code> configs. You can use a CLI like this:</p>

<pre><code># Use a specific config
kubevm use {YOUR_KUBE_CONFIG|default}
# or
kubevm YOUR_KUBE_CONFIG

# Set your default config
kubevm default YOUR_KUBE_CONFIG

# List your configurations, including current and default
kubevm list

# Create a new config
kubevm create YOUR_KUBE_CONFIG

# Delete a config
kubevm delete YOUR_KUBE_CONFIG

# Copy a config
kubevm copy SRC_CONFIG DEST_CONFIG

# Rename a config
kubevm rename OLD_CONFIG NEW_CONFIG

# Open a config directory in $EDITOR
kubevm edit YOUR_KUBE_CONFIG

# Update kubevm to the latest
kubevm update
</code></pre>

<p>Let me know if it's useful!</p>
