Lab 3.2 #7: Create and use a Discovery Token CA Cert Hash

cziaul

error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1
[preflight] If you know what you are doing, you can make a check non-fatal with --ignore-preflight-errors=...
To see the stack trace of this error execute with --v=5 or higher

Attached herewith screenshots

serewicz

Hello,

Did you ensure your VPC allows all traffic? Double check that if using GCE you have created a rule to allow all traffic.

I take it you are using crio instead of Docker. If so there are two things to be aware of,

You need to do many of the same steps on the worker as you did on the master to use crio. Ensure the declared steps were completed. I have seen a similar error when I accidentally missed a step.

Also, later steps in the course will not work correctly, yet. If you are new to Kubernetes you may want to use docker until you are familiar. Then build a crio cluster.

Regards,

cziaul

@serewicz Yes, I allowed traffic and also completed all the steps yesterday. I am interested to learn and go with crio, hope you will help me to learn. Attached here details. Please let me know, if you want to see anything else.

cziaul

Just one info on above doc, I inadvertently added 10.2.0.3 in worker hosts file. should be 10.2.0.2, which I corrected and still having same problem

cziaul

Here is updated doc

chrispokorni

Hi @cziaul,

In your latest kubeadm join attempt, you missed sudo from your command. Any kubeadm command needs to be run by root, or run with sudo from the student account. This is also reflected in the ERROR message of your screenshot.

Regards,
-Chris

cziaul

@chrispokorni if you see my latest doc above, i already corrected that.

chrispokorni

Also, running kubeadm join several times in a row will cause more ERRORS.

After an unsuccessful join, it is recommended to run kubeadm reset on the worker node, then attempt the kubeadm join again.

Keep in mind however that a reset will not fully "clean-up" the environment configured by the prior join, so there is a chance that it may still not allow for a successful join.

cziaul

I figured out where was the problem. I missed one of the crio command. Thanks.

serewicz

Glad you found it!

Regards,

cziaul

@serewicz Last one ;-) please take a look attached screen shot. Any idea why 10.88.0.7:80 and 10.88.0.8:80 showing error but 10.88.0.5:80 is showing html? Just wondering what I am missing. Thanks.

serewicz

Hello,

I would guess that the other pods are not running on that machine, and are on the worker node. As if the OS route tables probably don't know to send the packets over there.

Myself I have not had this issue, so I would also look to see if you really cleared out all the firewall rules and the nodes are in the same VPC.

Regards,