若上面命令结果的STATUS字段为“Healthy”，则表示组件处于健康运行状态，否则需要检查其错误所在，必要时可使用“kubeadm reset”命令重置之后重新进行集群初始化。
另外，使用“kubectl get nodes”命令能够获取集群节点的相关状态信息,显示了Master节点的状态为“NotReady”（未就绪），这是因为集群中尚未安装网络插件所致，执行完后面的其他步骤后它即自行转为“Ready”：
注: 此处为已经安装fannel网络插件后的结果
[root@master ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION master Ready master 21h v1.13.1 node1 Ready <none> 63m v1.13.1 master节点部署网络插件fannel基于kubeadm部署时，flannel同样运行为Kubernetes集群的附件，以Pod的形式部署运行于每个集群节点上以接受Kubernetes集群管理。
事实上，也可以直接将flannel程序包安装并以守护进程的方式运行于集群节点上，即以非托管的方式运行。部署方式既可以是获取其资源配置清单于本地而后部署于集群中，也可以直接在线进行应用部署。
部署命令是“kubectlapply”或“kubectlcreate”，例如，下面的命令将直接使用在线的配置清单进行flannel部署：
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml参考 https://github.com/coreos/flannel
至此master节点就完成了！
node节点加入Master各组件运行正常后即可将各Node添加至集群中。配置节点时，需要事先参考前面“设置容器运行环境”和“设定Kubernetes集群节点”两节中的配置过程设置好Node主机，而后即可在Node主机上使用“kubeadmjoin”命令将其加入集群中。
kubeadm join 192.168.18.64:6443 --token 4mvox7.5l6fgyyqo761yxyf --discovery-token-ca-cert-hash sha256:1cd687ae5837b85a48f9ca93873aa67b30d29b1584db3b1f2ede946506735035提供给APIServer的bootstraptoken认证完成后，kubeadmjoin命令会为后续Master与Node组件间的双向ssl/tls认证生成私钥及证书签署请求，并由Node在首次加入集群时提交给Master端的CA进行签署。
默认情况下，kubeadm配置kube-apiserver启用了bootstrapTLS功能，并支持证书的自动签署。于是，kubelet及kube-proxy等组件的相关私钥和证书文件在命令执行结束后便可自动生成，它们默认保存于/var/lib/kubelet/pki目录中。
在每个节点上重复上述步骤就能够将其加入集群中。所有节点加入完成后，即可使用“kubectlgetnodes”命令验证集群的节点状态，包括各节点的名称、状态就绪与否、角色（是否为节点Master）、加入集群的时长以及程序的版本等信息：
[root@master ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION master Ready master 21h v1.13.1 node1 Ready <none> 79m v1.13.1 重新生成用于节点加入集群的认证命令如果忘记了节点加入集群的认证命令，需要在master节点通过kubeadm tokem list获取认证令牌，再生成验证CA公钥的哈希值
[root@master ~]# kubeadm token list TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS 4mvox7.5l6fgyyqo761yxyf 12m 2019-01-11T18:08:33+08:00 authentication,signing The default bootstrap token generated by 'kubeadm init'. system:bootstrappers:kubeadm:default-node-token [root@master ~]# openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //' 1cd687ae5837b85a48f9ca93873aa67b30d29b1584db3b1f2ede946506735035将上述命令生成的值合为如下命令：
kubeadm join 192.168.18.64:6443 --token TOKEN --discover-token-ca-cert-hash sha256:HASH即为
kubeadm join 192.168.18.64:6443 --token 4mvox7.5l6fgyyqo761yxyf --discover-token-ca-cert-hash sha256:1cd687ae5837b85a48f9ca93873aa67b30d29b1584db3b1f2ede946506735035 一些坑 [root@node2 ~]# kubeadm join 192.168.18.64:6443 --token 4mvox7.5l6fgyyqo761yxyf --discovery-token-ca-cert-hash sha256:1cd687ae5837b85a48f9ca93873aa67b30d29b1584db3b1f2ede946506735035 [preflight] Running pre-flight checks [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.0. Latest validated version: 18.06 [WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service' [preflight] Some fatal errors occurred: [ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1 [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=...`node节点加入集群时
第一个warnning是版本验证问题，不用管
第二个warnning前面说到过，kubectl开机自启动是kubeadm的强制要求