Issue: On-prem Kubernetes Cluster using Virtual Box

Kubernetes-Slack Discussions
#1

Below is my software versions
Laptop Operation System : Mac OS
VirtualBox : 6.1.12
Ubuntu image : 20.06 (64-bit)
Kubenetes - Kubeadm: {Major:“1”, Minor:“19”, GitVersion:“v1.19.0”, GitCommit:“e19964183377d0ec2052d1f1fa930c4d7575bd50”, GitTreeState:“clean”, BuildDate:“2020-08-26T14:28:32Z”, GoVersion:“go1.15”, Compiler:“gc”, Platform:“linux/amd64”}
Docker : Docker version 19.03.11, build 42e35e61f3

How to reproduce:

  1. Create three Cent OS VM (1 Master Node and 2 Worker Nodes), Create two network adapters (Bridge Adapter and Host Only)
    (192...104 , 192...107 , 192...108 )
  2. Follow the procedure of docker and kubeadm installation in nodes.

Issue:
While running the “kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.56.5 --v=20”

{code}
I0827 03:44:46.274746 99523 round_trippers.go:423] curl -k -v -XGET -H “User-Agent: kubeadm/v1.19.0 (linux/amd64) kubernetes/e199641” -H “Accept: application/json, /” ‘https://192.168.56.5:6443/healthz?timeout=10s’

Unfortunately, an error has occurred:
	timed out waiting for the condition

This error is likely caused by:
	- The kubelet is not running
	- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
	- 'systemctl status kubelet'
	- 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.

Here is one example how you may list all Kubernetes containers running in docker:
	- 'docker ps -a | grep kube | grep -v pause'
	Once you have found the failing container, you can inspect its logs with:
	- 'docker logs CONTAINERID'

couldn’t initialize a Kubernetes cluster
{code}

etcd container error
{code}
W0827 07:45:18.510459 1 clientconn.go:1223] grpc: addrConn.createTransport failed to connect to {https://127.0.0.1:2379 0 }. Err :connection error: desc = “transport: Error while dialing dial tcp 127.0.0.1:2379: connect: connection refused”. Reconnecting…
{code}

Workaround
Executing with 0.0.0.0 as api advertise address
kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=0.0.0.0 --v=20

Join Node
kubeadm join 192...104:6443 --token rarv8h.m1dbhb4d9bocuh64 --discovery-token-ca-cert-hash sha256:98ffb6*************************************************6a077

Problem
When my DHCP resets my ip address i will end up doing the kube init again with that ip address.

#2

Hello @nvr,

It’s a general security practice, The certificate is signed for your old-IP and secure communication can’t then happen to your new-IP
So you can run kubeadm reset then kubeadm init again.

#3

I tried it earlier almost 10 times. Ended with same issue.

#4

As you did you can execute with 0.0.0.0 as apiserver-address but From a security perspective, you should get the correct new-IP and use it in the kubeadm init command.