Throwing bricks and attracting jade
environment
- centos 7 amd64 two
- Governors 1.10
With the release of the k8s 1.10 version, the k8s stand-alone cluster was built on a machine the day before yesterday, that is, it is both a master and a node. According to experience, the kubeadm init
prompts are kubeadm join
recorded to facilitate the addition of cluster set working nodes (machines) in the future. , you can reuse it directly, and then deploy dashboard、heapster、ElasticSearch、Redis、dotnet
microservices, etc., in one go, the cluster is in good condition, because k8s has been used in the test environment before, huh... . Two days later, the second server purchased by the company arrived, so the kubeadm join
script , and the result is as follows:
Seeing this prompt message, I am 100% convinced that the node has joined the cluster, and as long as you wait for a while, kubectl get nodes
you node is ready
, hey
, after a while, after a while, after a while... , but
Learning from the West, going through ninety-nine-eighty-one hardships
Then, turn on the retry mode to carry forward the traditional spirit of programmers' perseverance:
kubectl reset
kubectl join ......
kubectl get nodes
Entering the retry loop N times, patience is really good, haha. It clearly reminds This node has joined the cluster
why the actual situation is like this, is this the gap between ideal and reality, in fact, this is a pit , out. I thought and thought, looked and looked, but there was no error, warning or other information, so I had no idea what to do with the swelling. Finally, I focused my attention on kubelet, so I started to check the log of kuberlet:
see it
error: failed to run Kubelet: failed to create kubelet:
misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
It turned out to be a small problem, hey. . . . . . , I believed this k8s prompt again, and then started to fix the bug
Believe in your evil, why is kubelet cgroup driver
it docker cgroup driver
exactly the same, just now, kubelet
it's not in the log. . . Obviously. . . but. . . , calm, this may be a hallucination, okay. In the end what is true and what is false, can you give an accurate prompt information, since it is not a problem of kubelet, it is the latest version, and there is no information to check, there is really no way, then go to kubernets#62776 Let me mention Issues
it , so I got off work like this. . . .
The next day, the first thing I did was to check whether the question asked yesterday had been answered, and it turned out to be closed by an Indian Asan.
Hey, looking at the results I expected yesterday, it seems a little Zhuge, hehe, it's up to you, I thought and thought, looked and looked, I really didn't have a little bit of defense, I checked kubeadm
, kubectl
, kubelet
, and also Check all kinds of configurations; I also wondered if some things installed by the master in advance were affected, because it used to be kubeadm init
after , and then immediately kubeadm join
; I also wondered if it was a problem with the environment, because the previous test environment has always been Ubuntu 16.4
, now The host environment is CentOS 7
. I thought that this morning, I couldn't figure it out, so I followed the steps of the test environment and started all over again. Then, I still refused to give up (I was born to be a programmer, but my head was a little cold, huh, huh), so I started from another angle. Think about it and wonder if it is the recorded 'kube join token=.... ', there is a problem (why I didn't doubt it before, because I copied and kubeadm init
printed , and there is no problem in the test environment.), So I started to follow the vines, check the first parameter token
, and execute the command kubeadm token list
:
Cultivation and success, become a Buddha
It's really not easy to see the morning without the clouds and fog. I searched for her thousands of times in the crowd, and it turned out that she was in a dimly lit place. . . . . Hey, it's a pity not to engage in literature, huh, huh.
So, I kubeadm create token
recreated token
, and then, re-executed kubeadm join
, and checked again kubectl get nodes
:
I succeeded, I finally succeeded. This is the most confusing pit I have stepped on kubernetes
since I started. In the end, I answered my own kubernets#62776 , and I gave some suggestions casually kubernetes
. I hope the prompt information can be more accurate, their small step , is a big step for us. . . . .
Pratt & Whitney
By default, through the kubeadm create token
creation token
, the expiration time is 24 hours, which is why the kube join
native , and it can also be run kubeadm token create --ttl 0
to generate a never-expiring one token
. For details, please refer to: kubeadm-token , understand The reason can be inferred from one another. Learning k8s with thinking will not be boring. I hope to share this pit with everyone. If you have any questions or want to communicate, please leave a message in the comment area, and the landlord will reply one by one.