It's not ideal having to ssh into your server every time you want to do something. To access this cluster remotely, we need to do two things:
Copy the cluster access configuration that k3s generated to your development machine.
Install the kubernetes control tool (kubectl)
Depending on if your development machine is Linux, Mac or Windows, there are instructions to install it here.
From the doc:
/etc/rancher/k3s/k3s.yamlon your machine located outside the cluster as
~/.kube/config. Then replace “localhost” with the IP or name of your K3s server.
kubectlcan now manage your K3s cluster.
Now let's run that same command we did before to see if the node is working:
[email protected]:~ $ kubectl get nodesNAME STATUS ROLES AGE VERSIONcpi6 Ready control-plane,master 51s v1.21.3+k3s1
Winner! So much nicer than sshing to the machine every time
❗Concept: Kubernetes Objects What is really awesome about Kubernetes is that you can code up a desired state that you want it to do, then "apply" those configuration files (call Kubernetes Objects) and it will try to do set up that state (called ". As your cluster grows over time, you want to keep your configuration in static files so you can refer back, make changes as needed, and use them as references for other things you want to deploy.
Since the configuration files that we ask Kubernetes to "apply" are just yaml files, you can organize them however you like. Personally, I like to group them by the purpose for each deployment. It looks like this (I didn't include everything to not clutter everything)
todo.txtREADME.mdshared/smarthome/├─ home-assistant/├─ (other stuff)/rss-reader/media/├─ jellyfin/├─ (other stuff)/network/├─ healthcheck/├─ adguard/
Each folder contains a few Kubernetes Object files. Let's start simple and create a new directory somewhere on your machine:
$ mkdir homelab-code$ cd homelab-code
Let's also create a git repo for that dir:
$ git init .
Let's get rolling
Official k3s doc on this process