Section 3. Advanced Scheduling:

• coredns pods in CrashLoopBackOff status when trying to recreate
• Inspect of docker container:
  "Error": "OCI runtime create failed: container_linux.go:367: starting container process caused: exec: \"/coredns\": stat /coredns: no such file or directory: unknown"
• Deployment logs:
  E0502 18:35:32.526725 1 reflector.go:307] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to watch *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?allowWatchBookmarks=true&resourceVersion=864&timeout=7m42s&timeoutSeconds=462&watch=true: dial tcp 10.96.0.1:443: connect: connection refused E0502 18:35:32.526855 1 reflector.go:307] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to watch *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?allowWatchBookmarks=true&resourceVersion=13213&timeout=5m51s&timeoutSeconds=351&watch=true: dial tcp 10.96.0.1:443: connect: connection refused E0502 18:35:32.526902 1 reflector.go:307] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to watch *v1.Service: Get https://10.96.0.1:443/api/v1/services?allowWatchBookmarks=true&resourceVersion=874&timeout=6m30s&timeoutSeconds=390&watch=true: dial tcp 10.96.0.1:443: connect: connection refused

I have upgraded packages and as workaround changed image in coredns deployment to the latest docker.io/coredns/coredns:1.8.3 which made pods to be in Ready state again

First off, I just wanted to say thank you for setting up these exercises - they're exellent! This is just a minor suggestion for broadening the hands on practise with various K8s resources plus it would make it satisfying for the participant as they'd have the means to complete the questions fully without resorting to external resources 🙂

In the first exercise, "Multi-Container Issues", question no.5 is:

Fix the pod and ensure its running.

There isn't a practical solution offered, other than "alter the default configuration".

To make this a more complete solution, the web-server pod could have the nginx container use a configmap, mounted to /etc/nginx/nginx.conf. This way, the participant would be able to edit the config map and then ensure it runs both containers.

I'm on Windows 10, latest update. Got the latest version of both VirtualBox and Vagrant installed. The scripts don't work on Windows, so I converted them to powershell:

vagrant up --provider virtualbox

echo '######################## WAITING TILL ALL NODES ARE READY ########################'
sleep 60

echo '######################## INITIALISING K8S RESOURCES ########################'
#chmod 400 certs/id_rsa
vagrant ssh cluster1-master1 -c "sudo su - root -c 'kubectl apply -f /vagrant/k8s/init.yaml'"
vagrant ssh cluster1-master1 -c "mkdir -p .kube ; sudo cp /root/.kube/config ./.kube/config ; sudo chown vagrant:vagrant .kube/config"
sleep 20

echo '######################## ALL DONE ########################'

And

vagrant destroy --force
rm -r .vagrant
rm -r tmp
mkdir tmp
New-Item tmp/.gitignore

However, the script already seems to fail at the first vagrant up --provider virtualbox command. Sometimes installing kubectl seems to fail according to the logs, sometimes the second node can't be instantiated, it's a new random bug every time. The errors are very random. Does this script store state somewhere in a way that can affect subsequent runs?

I had problems with executing ./up.sh in the stage INITIALISING K8S RESOURCES.

One solution may be to use the following instead of the ssh-keygen...:

vagrant ssh cluster1-master1 -c "sudo su - root -c 'kubectl apply -f /vagrant/k8s/init.yaml'"

Do you think this makes sense? Would a PR be accepted?

[root@k8s-master cluster1]# vagrant ssh cluster1-master1
No usable default provider could be found for your system.

Vagrant relies on interactions with 3rd party systems, known as
"providers", to provide Vagrant with resources to run development
environments. Examples are VirtualBox, VMware, Hyper-V.

The easiest solution to this message is to install VirtualBox, which
is available for free on all major platforms.

If you believe you already have a provider available, make sure it
is properly installed and configured. You can see more details about
why a particular provider isn't working by forcing usage with
vagrant up --provider=PROVIDER, which should give you a more specific
error message for that particular provider.

  1: from /usr/share/rubygems-integration/all/gems/net-scp-2.0.0/lib/net/scp.rb:369:in `block (3 levels) in start_command'

/usr/share/rubygems-integration/all/gems/net-scp-2.0.0/lib/net/scp.rb:398:in `await_response_state': \x01scp: /tmp/vagrant-shell: Read-only file system (Net::SCP::Error)
######################## WAITING TILL ALL NODES ARE READY ########################
######################## INITIALISING K8S RESOURCES ########################
error: Missing or incomplete configuration info. Please point to an existing, complete config file:

1. Via the command-line flag --kubeconfig
2. Via the KUBECONFIG environment variable
3. In your home directory as ~/.kube/config

To view or setup config directly use the 'config' command.
Connection to 127.0.0.1 closed.
cp: cannot stat '/root/.kube/config': No such file or directory
chown: cannot access '.kube/config': No such file or directory
Connection to 127.0.0.1 closed.
######################## ALL DONE ########################