Getting Difficulties with Demo-Setup Lab-VirtualBox

Kubernetes
#1

Hello Team,
I am getting the below errors when i am trying to create 3 machines for provisioning cluster using kubeadm.
please find below the attachment of the error:

chinkleet@UbuntuServer-VirtualBox:~$ cd kubeadm/
chinkleet@UbuntuServer-VirtualBox:~/kubeadm$ ls
certified-kubernetes-administrator-course
chinkleet@UbuntuServer-VirtualBox:~/kubeadm$ cd certified-kubernetes-administrator-course/
chinkleet@UbuntuServer-VirtualBox:~/kubeadm/certified-kubernetes-administrator-course$ ls
docs README.md ubuntu-bionic-18.04-cloudimg-console.log
images ubuntu Vagrantfile
chinkleet@UbuntuServer-VirtualBox:~/kubeadm/certified-kubernetes-administrator-course$ vagrant status
Current machine states:

kubemaster not created (virtualbox)
kubenode01 not created (virtualbox)
kubenode02 not created (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run vagrant status NAME.
chinkleet@UbuntuServer-VirtualBox:~/kubeadm/certified-kubernetes-administrator-course$ vagrant up
Bringing machine ‘kubemaster’ up with ‘virtualbox’ provider…
Bringing machine ‘kubenode01’ up with ‘virtualbox’ provider…
Bringing machine ‘kubenode02’ up with ‘virtualbox’ provider…
==> kubemaster: Importing base box ‘ubuntu/bionic64’…
==> kubemaster: Matching MAC address for NAT networking…
==> kubemaster: Setting the name of the VM: kubemaster
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 2711 is already in use
on the host machine.

To fix this, modify your current project’s Vagrantfile to use another
port. Example, where ‘1234’ would be replaced by a unique host port:

** config.vm.network :forwarded_port, guest: 22, host: 1234**

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn’t allow modifying port forwarding. You could
try ‘vagrant reload’ (equivalent of running a halt followed by an up)
so vagrant can attempt to auto-correct this upon booting. Be warned
that any unsaved work might be lost.
chinkleet@UbuntuServer-VirtualBox:~/kubeadm/certified-kubernetes-administrator-course$ vagrant reload
==> kubemaster: Clearing any previously set network interfaces…
==> kubemaster: Preparing network interfaces based on configuration…
** kubemaster: Adapter 1: nat**
** kubemaster: Adapter 2: hostonly**
==> kubemaster: Forwarding ports…
** kubemaster: 22 (guest) => 2711 (host) (adapter 1)**
** kubemaster: 22 (guest) => 2222 (host) (adapter 1)**
==> kubemaster: Running ‘pre-boot’ VM customizations…
==> kubemaster: Booting VM…
==> kubemaster: Waiting for machine to boot. This may take a few minutes…
** kubemaster: SSH address: 127.0.0.1:2222**
** kubemaster: SSH username: vagrant**
** kubemaster: SSH auth method: private key**
** kubemaster: Warning: Connection reset. Retrying…**
** kubemaster: Warning: Remote connection disconnect. Retrying…**
** kubemaster: Warning: Connection reset. Retrying…**
** kubemaster: Warning: Remote connection disconnect. Retrying…**
** kubemaster: Warning: Connection reset. Retrying…**
** kubemaster: Warning: Remote connection disconnect. Retrying…**
** kubemaster: Warning: Connection reset. Retrying…**
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured (“config.vm.boot_timeout” value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you’re using a custom box, make sure that networking is properly
working and you’re able to connect to the machine. It is a common
problem that networking isn’t setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout (“config.vm.boot_timeout”) value.

I have gone through all the steps as discussed in the lecture, didn’t change anything in the Vagrant configuration file however still stuck with the error.
Any help will be appreciated.

Regards,
Chinkleet

#2

I think it’s failing because it’s exceeding timeout seconds which is mentioned in the vagrant configuration file. Go into that file and add
config.vm.boot_timeout=600
then start again.

#3

I have timeout set as 900 still I am facing same issue mentioned above. Can anyone help. @chinkleet how did you resolved this issue?

#4

I have timeout set as 900 still I am facing same issue mentioned above

#5

@anshuprof2607 You may or may not have the same problem; probably the best place to start here is to make sure you’re using the best instructions for setting up a kubeadm cluster. I’ll point you to the CKA course repo, which has a really good tutorial for a virtualbox kubeadm install.

#6

Thank you Rob for you comments. I am already following same course and using same Vagrantfile mentioned in repo. step by step I followed the instruction but blocked while running vagrant up command . I am still trying to figure out why there is connection reset with my private keys.

==> kubemaster: Waiting for machine to boot. This may take a few minutes…
kubemaster: SSH address: 127.0.0.1:2222
kubemaster: SSH username: vagrant
kubemaster: SSH auth method: private key
kubemaster: Warning: Connection reset. Retrying…

@rob_kodekloud

#7

I assume you’re just doing vagrant up. So a few questions about your set-up:

  1. What OS and version?
  2. What version of VirtualBox?
  3. Try running vagrant up --debug and see if you get some more useful error so we can figure this out.

If it isn’t clear what’s wrong, try:

  1. vagrant destroy
  2. vagrant up --debug

I’d also recommend taking a look at the page on debugging on Hashicorp’s site. If you think the error log is useful, post it as Gist, as the debugging page suggests, and link to the Gist here.

#8

Version of VirtualBox- 7.0.8
Version of Vagrant- Vagrant 2.4.1
MacOS- 14.1.1 (23B81)

I tried running vagrant up with debug and captured below error.

" DEBUG ssh: D, [2024-02-05T12:27:05.951241 #23457] DEBUG – net.ssh.transport.session[b2c]: establishing connection to 127.0.0.1:2222

D, [2024-02-05T12:27:05.951546 #23457] DEBUG – net.ssh.transport.session[b2c]: connection established

I, [2024-02-05T12:27:05.951573 #23457] INFO – net.ssh.transport.server_version[b40]: negotiating protocol version

D, [2024-02-05T12:27:05.951580 #23457] DEBUG – net.ssh.transport.server_version[b40]: local is `SSH-2.0-Ruby/Net::SSH_7.2.1 arm64-darwin’

DEBUG ssh: == Net-SSH connection debug-level log END ==

INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.

The error message is shown below. In many cases, errors from this

library are caused by ssh-agent issues. Try disabling your SSH

agent or removing some keys and try again. "

However I tried to capture the logs from GUI virtualBox too and found below issue, however I am not sure how relevant this line is for this issue.

*Date/Time: 2024-02-05 10:15:04.4808 +0530
*OS Version: macOS 14.1.1 (23B81)
*Report Version: 12
*Anonymous UUID: 9187242C-D082-4E1B-6243-F0223D75E122

*Sleep/Wake UUID: 46064D85-C113-4D3C-A6F7-44AE4E48EFB4

*Time Awake Since Boot: 93000 seconds
*Time Since Wake: 2844 seconds

*System Integrity Protection: enabled

*Crashed Thread: 12 EMT-1

*Exception Type: EXC_CRASH (SIGABRT)
*Exception Codes: 0x0000000000000000, 0x0000000000000000

*Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
*Terminating Process: VirtualBoxVM [14144]

Also I captured the whole log in a file. Below is the public Github repo link for same

#9

@rob_kodekloud Gist link- Getting ssl connection reset while running Vagrant up · GitHub

#10

That’s MacOS Sonoma. Are you running an Intel based Mac (only a very few models of those support Sonoma), or are you running an Apple Silicon Mac (M1, M2, etc.)? If you’re using the latter, then VirtualBox support is likely poor. I’m not even sure that VirtualBox supports Sonoma for Intel Macs particularly well.

#11

@rob_kodekloud Its chip is Apple M2 Pro

#12

That would be your problem; Virtualbox really doesn’t work on Apple Silicon macs. You might want to try Multipass instead, which does work with AS systems. There’s a tutorial in the same repo you’re using for Virtualbox.

#13

Thanks Rob , I will check on that and also I can use Docker Engine also ? correct me If I am wrong.

#14

It depends on how you want to use the cluster. I have an M2 Mac Mini and have set up multipass, minikube using qemu with socket_vnet, and colima (which uses K3s for K8s). If you just want to practice various things for the K4AB course, minikube or colima is fine. If you want to learn how the pieces fit together for learning architecture in CKA, it’s worth doing a multi-host cluster, as you’d do with multipass. Colima is easiest to set up; minikube with qemu and socket_vnet is a bit tricky, and multipass takes the most care to do right. Good reasons to do any of these 3 things.

I tend to use minikube for support mostly nowadays, myself.

#15

Thanks Rob ! I will try your suggestion.

update- @rob_kodekloud I tried with multipass and it’s all working now. Thanks for your guidance.