The connection to the server localhost:8080 was refused - did you specify the right host or port?

[MaestroJurko]

https://rancher.com/docs/k3s/latest/en/quick-start/

Following the instructions from above return the error The connection to the server localhost:8080 was refused - did you specify the right host or port?. I have it setup on GCP.

It allows me to use kubectl when I copy/paste the /etc/rancher/k3s/k3s.yaml from master into worker ~/.kube/config with updated ip but this I believe is not really creating any resources on a worker node but on master node.

[brandond]

It sounds like you have your own kubectl binary that is not looking at /etc/rancher/k3s/k3s.yaml. If you use the kubectl that comes with K3s, it has been modified to look in that location. If you are using your own kubectl then you need to set KUBECONFIG appropriately.

[MaestroJurko]

No kubectl is installed, the only package installed on the VM is k3s and on the worker machine there is no /etc/rancher/k3s/k3s.yaml

[brandond]

on the worker machine there is no /etc/rancher/k3s/k3s.yaml

That is correct. Only servers have the admin kubeconfig file present. Agents are less privileged and do not have any of the server's keys or other confidential materials. Note that the quick-start has you running kubectl commands on the just-installed server node, not on agents.

[MaestroJurko]

Ok. how does it work creating clusters and namespaces on worker instead on master?

[brandond]

You don't generally do anything on the agents (workers). Agents just do what the servers tell them to do. Info about the agents can be retrieved using kubectl on the server, or on a workstation that you've copied the admin kubeconfig over to. Why are you hoping to run commands on the agents?

I believe is not really creating any resources on a worker node but on master node

Only the server (apiserver) actually holds Kubernetes resources. All kinds of nodes (agents or servers) may schedule and run pods, but it's up to the Kubernetes scheduler to decide what nodes the pods run on - depending attributes defined on the pods themselves.

You can use kubectl get node to see the nodes, and kubectl get pod -A -o wide to see which nodes the pods are running on.

[MaestroJurko]

Thank you for that, quite new to k3s.

Can you help me with error: unable to recognize "issuer2.yaml": no matches for kind "ClusterIssuer" in version "certmanager.k8s.io/v1alpha1". I keep getting errors trying to run yaml config files that normally work on k8s.

[brandond]

That sounds like a CertManager thing? Either CertManager isn't installed, or its the wrong version, or you forgot to enable the CRDs when installing the chart.

[ChristianCiach]

Disclaimer: I am not a maintainer of k3s.

Your issue actually has nothing to do with k3s. You are wrong when you say that these files "normally work on k8s".

You are trying to deploy CustomResource of type ClusterIssuer. For that to work you have to install CertManager (https://cert-manager.io) to your cluster first, including its CustomResourceDefinitions (CRDs).

It's also possible that you already have CertManager installed, but you are using a newer version of it. Your custom resource is referencing an older version that is not compatible with the current versions of CertManager. See https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/

Edit: I am too late :D