Most things will work fine with Ubuntu Server, but the course is really geared towards the desktop and you wont' be able to use Graphical interfaces, so I would recommend Server. It doesn't take that much space. You can proabably get the same result as a fresh install by doing ./ready-for.sh --install LFS201 (using the script mentioned in the doucments or at https://training.linuxfoundation.org/cm/prep)
The "SOLUTIONS" file contains a few scripts or configuration files used in the class, it is better to use these than try to cut and paste from the screen as that is error prone. You will be told where they occur as they go.
The "RESOURCES" file contains some small system images (.iso) files used in the virtualization chapters much later in the course. You can download them as well from the original sources-- you'll be told later.
But I don't recomment "server" as we haven't really tested on that as it is a small subsection of users.
Did you complete Lab exercise 5.1? The .pem files are reused from there.
For the Dashboard, if you are using the node-port value from the manual, it will clearly not work. That value is for illustration purposes. You are required to use your own node-port value, displayed in a previous step.
I am not sure there is such an image ngix available in the Docker Hub registry, so it makes sense that there is no such pod in your Kubernetes cluster either.
Try double-checking the spelling of the image name. This is just the result of a simple typo in your command.
Error messages are typically prefixed with "error" or "E". The message you are showing is just informational.
Did you notice any unexpected behavior as a result of this message?
We are aware of the issue and we are working to restore the service. Thank you for your patience while we fix this.
Correct. That is informational output, not an error.
In the bash shell, for almost every command, the options can be given in any order. Thus -it is parsed by the shell in the same manner as -ti.
I suggest you download a few different "live" versions that you can run from a USB drive and try them out without actually installing them. Find the one that you like the most, and then install and try it out for real. With that hardware, most modern distros will do very well
Hi David / @dcarrascal75,
Any reason why you chose to run a master reset and an init after restart?
The behavior you observe is expected when running a reset and init on master. In doing so, you wipe clean the configuration of the master and create new credentials for the cluster. Hence, the old worker is not able to join the cluster. An easy fix would be a reset and a join on the worker with the new token and hash values produced by the latest init of the master.
But why run reset at all? Assuming your nodes keep their IP addresses, and you permanently disabled swap on your nodes, a simple start of each node should bring up the k8s cluster as well.