Building the home lab Kubernetes playground – Part 6
Tags: kubernetes
Published: 2021-03-06 09:51:29

---
title: Building the home lab Kubernetes playground – Part 6
published: true
date: 2021-03-05 13:32:21 UTC
tags: Kubernetes,kubernetes
canonical_url: https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-6
---

In the [last post](https://dev.to/michaelcade1/building-the-home-lab-kubernetes-playground-part-5-4eei "Building the home lab Kubernetes playground – Part 5") we covered an overview of Helm and the MinIO deployment to give us an option for testing later on workloads that require object storage. This post we are going to focus on context and how to make sure you have access from your desktop to your Kubernetes Cluster.

# Context

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe1.png)

_Image taken from Kubernetes.io_

Context is important, the ability to access your Kubernetes cluster from your desktop or laptop is required. Lots of different options out there and people use obviously different operating systems as their daily drivers.

In the post we are going to be talking about Windows but as I said there are other options out there for other operating systems. More to the point if you are managing multiple Kubernetes clusters for different projects or learning.

By default, the Kubernetes CLI client uses the C:\Users\username\.kube\config to store the Kubernetes cluster details such as endpoint and credentials. If you have deployed a cluster you will be able to see this file in that location. But if you have been using maybe the master node to run all of your kubectl commands so far via SSH or other methods then this post will hopefully help you get to grips with being able to connect with your workstation.

Once again [Kubernetes.io](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) have this documented

## Install the Kubernetes-CLI

First, we need the Kubernetes CLI installed on our Windows Machine, I used chocolatey with the following command.

choco install kubernetes-cl

We then we need to grab the kubeconfig file from the cluster, grab the contents of this file either via SCP or just open a console session to your master node and copy to the local windows machine. The location of the config is listed below.

$HOME/.kube/config

If you have taken the console approach, then you will need to get the contents of that file and paste into the config location on your Windows machine. You could go ahead and run the following command but this is going to contain redacted information so this will not work if you take a copy of this to your windows machine.

kubectl config view

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe2.png)

What we need to do is get those redacted values to copy over to our windows machine, you can achieve this by running the following commands

cd $HOME/.kube/

ls

cat config

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe3.png)

That the above starting at the apiVersion: v1 down to the bottom of the file and copy that to your .kube directory on windows. This same process is similar for other operating systems.

C:\Users\micha\.kube\config

If you want to open the file, then you will be able to compare that to what you saw on the shell of your master node.

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe4.png)

You will now be able to check in on your K8 cluster from the windows machine

kubectl cluster-info

kubectl get nodes

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe5.png)

This not only allows for connectivity and control from your windows machine, but this then also allows us to do some port forwarding to access certain services from our windows machine. We can cover them off in a later post.

## Multiple Clusters

Ok a single cluster is simple, and we are there with the above specifically on Windows. But accessing multiple clusters using contexts is really what you likely came here to see.

Again some awesome [documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) that you can easily run through.

For this post though I have my home lab cluster that we have been walking through and then I have also just deployed a new EKS cluster in AWS. The first thing to notice is that the config file is now updated with multiple clusters. Also note I do not use notepad as my usual go to for editing YAML files.

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe6.png)

Then also notice in the same screen grab that we have multiple contexts displayed.

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe7.png)

So now if I run the same commands we ran before.

kubectl cluster-info

kubectl get nodes

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe8.png)

We can see that the context has been changed over, and actually this is done automatically with the EKS commands and I am not sure if this is the same process for other cloud providers something we will get to in later posts. But now we are on the AWS cluster and can work with our cluster from our windows machine. So how do we view all of the possible contexts that we may have in our config file.

kubectl config get-contexts

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe9.png)

And if we want to flip between the clusters you simply run the following command, you will then see how we switched over to the other context and back into our home lab cluster.

kubectl config use-context Kubernetes-admin@kubernetes

![](https://vzilla.co.uk/wp-content/uploads/2021/03/030521_1320_Buildingthe10.png)

One thing to note is that I also store my .pem file in the same location as my config file, I have been reading about some best practices that if you have multiple config requirements you could start creating a folder structure with all of your test clusters, all of your development clusters and then live and so on.

Hopefully that was useful, and in the next post we will take a look at the load balancer that I am using in the home lab.

The post [Building the home lab Kubernetes playground – Part 6](https://vzilla.co.uk/vzilla-blog/building-the-home-lab-kubernetes-playground-part-6) first appeared on [vZilla](https://vzilla.co.uk).