Welcome to the Linux Foundation Forum!

Lab 3.2: Configure A Local Repo

I managed to get down to step 14 on lab 3.2, it says:

Test that the repo works after the reboot, as good admins we want to know our configuration is persistent. Be aware it can take a minute or two after reboot for the kube-apiserver to fully start. If the $repo variable isn’t set check the source statement in .bashrc.

student@cp:˜$ curl $repo/v2/_catalog

When I try the curl step I get 'curl: (3) URL using bad/illegal format or missing URL'

I checked the 'source' line in .bashrc and it says '"source <(kubectl completion bash)'

What am I missing? How do I get past this step?

Comments

  • chrispokorni
    chrispokorni Posts: 2,354

    Hi @julieheard,

    Please check that the repo variable is set after the reboot by running echo $repo
    If it is not set (no value is returned by echo ...), check the .bashrc file for the export repo=10.97.40.62:5000 entry, and ensure it is correct. The .bashrc entry should have been created by the local-repo-setup.sh script in step 4.

    Regards,
    -Chris

  • jac01
    jac01 Posts: 2

    I had a similar issue at this stage. When accessing the image from the worker node the repo variable is set but the above curl command times out.

    Any ideas why that might be?

    Cheers,
    Jac

  • chrispokorni
    chrispokorni Posts: 2,354

    Hi @jac01,

    What type of infrastructure is hosting the cluster? Cloud or local? Any firewalls left in place?

    In step 2, is the registry service available? Is the ClusterIP value the same with the IP shown in the lab guide?

    Did you reboot both nodes as instructed in step 10?

    Are curl and push/pull successful from the control plane node?

    Regards,
    -Chris

  • jac01
    jac01 Posts: 2

    I am using a local minikube multinode cluster.

    The registry service is available in step 2.

    The ClusterIP is the same value as shown in the lab guide.

    After the sudo reboot the curl/push/pull are successful from the control plane but not from the worker node.

    This is strange because the pull on the worker node previously worked in step 9 before the reboot.

    I am not sure what else to try. Would you advise abandoning minikube? It seems to have worked pretty well so far.

    Thanks for the response,

    Jac

  • chrispokorni
    chrispokorni Posts: 2,354

    Hi @jac01,

    Minikube is a decent tool for learning but there are automated aspects that are out of our control such as the node OS and certain config options.

    The course reflects the certification exam environment, where nodes run Ubuntu 20.04 LTS. All installation, configuration, and additional scripts have been designed for this OS, so I would encourage you to follow the lab guide and build your cluster with the help of the scripts provided by the SOLUTIONS tarball and the commands presented in the lab guide.

    You can still run a local cluster but ensure your VMs have adequate resources (CPU, RAM, disk), run Ubuntu 20.04 LTS, and ideally bridged network should be defined for the VMs to fully see each other and to access the public internet as well.

    Regards,
    -Chris

Categories

Upcoming Training