Welcome to the Linux Foundation Forum!

Having issues at Lab 3.3. Finish Cluster Setup

NondualIT
NondualIT Posts: 2
edited May 2024 in LFS258 Class Forum

Hi there,

I recently started the LFS258 course and successfully completed Labs 3.1 and 3.2 without any issues. I'm conducting the labs on two AWS EC2 instances, which I shut down after each session for cost management. Today, I started my CP and WORKER instances (where I completed Lab 3.2), but now the cluster is not functioning properly.

The first command of Lab 3.3 gives me an error after restarting both EC2 servers:

kubectl get node
E0530 18:51:05.593093 3090 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0530 18:51:05.593463 3090 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0530 18:51:05.594928 3090 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0530 18:51:05.596499 3090 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0530 18:51:05.598026 3090 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
The connection to the server localhost:8080 was refused - did you specify the right host or port?

What is happening here? there is nothing on the class regarding stopping or starting the servers.

Please help!

Comments

  • chrispokorni
    chrispokorni Posts: 2,605

    Hi @NondualIT,

    There are a few concerning behaviors here.

    Firstly, the fact that GET is issued against the localhost, instead of the control plane node IP address that is hosting the API server.

    Second, the port is incorrect. It targets port 8080, when the API server typically is exposed on ports such as 6443 or 8443.

    On both EC2 VMs, please check that the kubelet and containerd services are running respectively:

    sudo systemctl status kubelet
    sudo systemctl status containerd

    Please validate that the ~/.kube directory and the config file generated in step 22 of lab exercise 3.1 still exist in the home directory of the regular (non-root) user issuing the kubectl commands. By closely following the lab guide, the commands should be issued by a regular user from the control plane node, that is the control plane EC2 VM.

    Regards,
    -Chris

  • NondualIT
    NondualIT Posts: 2

    Hi @chrispokorni

    Thank you for your reply. I believe I have identified the problem, and I have a suggestion for the LAB and the Linux Foundation to address this.

    When I started the lab, I launched both EC2 instances simultaneously on AWS. I think you should start the Control Plane (CP) first and then the worker node; otherwise, things might get messed up. I followed this order, and now everything is working correctly.

    Additionally, all the required resources were present. I can now continue with the lab.

Categories

Upcoming Training