本文章是自己依照博客文章：《002.应用kubeadm装置kubernetes 1.17.0》https://www.cnblogs.com/zyxnh... 以及《Kubernetes权威指南》等材料进行部署实现后进行的记录和总结。

本文分三个局部，（上）记录了基础设施环境的后期筹备和Master的部署，以及网络插件Flannel的部署。（中）记录了node的部署过程，以及一些必要的容器的部署。（下）介绍一些监控和DevOps的相干内容。

三。部署node

此处当然倡议通过ansible等配置管理工具对立进行部署。我的文档只拿一台node来举例子。

1. 退出集群：kubeadm join命令
[root@k8s-master opt]# kubeadm join 192.168.56.99:6443 --token abcdef.0123456789abcdef     --discovery-token-ca-cert-hash sha256:ef543a59aac99e4f86e6661a7eb04d05b8a03269c7784378418ff3ff2a2d2d3c
2. 看后果：

胜利了的话屏幕的回显应该是这样的，如果失败了，检查一下起因。

我这边就失败了，通过两个终端查看的方法终于发现，还是老问题，镜像拉取卡住。我本来认为镜像只在master上拉取过就够了，事实上每台node都应该有雷同的镜像。起初想明确了，镜像是通过文件系统的形式，对象存储来体现，一台机器上有这个文件对象不代表另一台机器上也有，另外不论K8S还是Docker都没有镜像同步的机制。

[root@k8s-master opt]# docker pull kubeimage/kube-proxy-amd64:v1.19.3[root@k8s-master opt]# docker pull kubeimage/pause-amd64:3.2

这就看进去了，下面说的容器镜像该当封装到操作系统镜像中比拟好。公有云的Openstack或者VMVware vSphere，私有云的阿里云等等都反对自定义镜像的，一下子快好多。不光是镜像本地化，那些通用的配置也都不须要重复地配置了，节俭了很多生产力。

3. 部署Node时遇到的问题。

（1）kubelet无奈启动。通过查看零碎服务状态发现该服务始终处于Activating 状态，而不是running. 查看了message 后发现kubelet.service 启动时会查看swap分区，分区存在的话无奈启动。手动敞开。
日志写得很分明：

Nov  6 09:04:24 k8s-node01 kubelet: F1106 09:04:24.680751    2635 server.go:265] failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: [Filename#011#011#011#011Type#011#011Size#011Used#011Priority /dev/dm-1                               partition#011839676#0110#011-2]
4. 部署node实现
[root@k8s-master opt]# kubectl  get nodesNAME            STATUS     ROLES    AGE     VERSION192.168.56.99   Ready      master   4d22h   v1.19.3k8s-node01      NotReady   <none>   4d22h   v1.19.3

四。部署必要容器

1. kubernetes-dashboard是整个集群的web治理界面，对于日后治理集群来说是必备的。
[root@k8s-master opt]# wget https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended.yaml

咱们先用标准配置去apply，有什么问题再去批改。

[root@k8s-master opt]# kubectl apply -f recommand.ymlamespace/kubernetes-dashboard createdserviceaccount/kubernetes-dashboard createdservice/kubernetes-dashboard createdsecret/kubernetes-dashboard-certs createdsecret/kubernetes-dashboard-csrf createdsecret/kubernetes-dashboard-key-holder createdconfigmap/kubernetes-dashboard-settings createdrole.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrole.rbac.authorization.k8s.io/kubernetes-dashboard createdrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createddeployment.apps/kubernetes-dashboard createdservice/dashboard-metrics-scraper createddeployment.apps/dashboard-metrics-scraper created

如果有问题，屏显会通知你哪一个资源没有创立胜利，再去批改和解决。

kubectl get pods -n kubernetes-dashboardNAME                                         READY   STATUS    RESTARTS   AGEdashboard-metrics-scraper-76585494d8-5jtvw   1/1     Running   0          86skubernetes-dashboard-b7ffbc8cb-4xcdp         1/1     Running   0          86s
2. 端口裸露：

这时有一个问题，如何把dashboard封装一下供我的电脑去拜访呢？这个dashboard只有一个虚构的ClusterIP（既无奈间接拜访，也无奈PING通），还有一个podIP，也一样是无奈间接拜访。最终的答案实际上是在dashboard.yml文件中减少一些配置，将Service的ClusterIP 转换到虚拟机的NodeIP上来，通过NodeIP:NodePort的形式来拜访这个服务。

[root@k8s-master opt]# vim recommended.yaml kind: ServiceapiVersion: v1metadata:  labels:    k8s-app: kubernetes-dashboard  name: kubernetes-dashboard  namespace: kubernetes-dashboardspec:  type: NodePort # 此处减少一行，拜访形式为NodePort  ports:    - port: 443      targetPort: 8443      nodePort: 32443 # 此处减少一行，指定NodePort的具体值  selector:    k8s-app: kubernetes-dashboard

把原来的一套dashboard资源全砸了，从新建。

[root@k8s-master opt]# kubectl delete -f recommended.yaml namespace "kubernetes-dashboard" deletedserviceaccount "kubernetes-dashboard" deletedservice "kubernetes-dashboard" deletedsecret "kubernetes-dashboard-certs" deletedsecret "kubernetes-dashboard-csrf" deletedsecret "kubernetes-dashboard-key-holder" deletedconfigmap "kubernetes-dashboard-settings" deletedrole.rbac.authorization.k8s.io "kubernetes-dashboard" deletedclusterrole.rbac.authorization.k8s.io "kubernetes-dashboard" deletedrolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deletedclusterrolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deleteddeployment.apps "kubernetes-dashboard" deletedservice "dashboard-metrics-scraper" deleteddeployment.apps "dashboard-metrics-scraper" deleted[root@k8s-master opt]# kubectl apple -f recommended.yaml

这样就能够拜访了：https://192.168.56.99:32443

3. dashboard的token和权限

关上页面后会问你是通过token还是kubeconfig来验证身份。选kubeconfig的话相当于你本地有一套kubeadmin-config 的配置文件，通过浏览器上传去做验证，这个很简略。

token的形式按如下形式去取，打印进去的后果粘贴到浏览器中：

[root@k8s-master opt]# kubectl describe secret -n kubernetes-dashboard $(kubectl get secret -n kubernetes-dashboard |grep  kubernetes-dashboard-token | awk '{print $1}') |grep token | awk '{print $2}'

登陆进来发现很多货色都看不到，那是因为dashboard默认权限较低。

[root@k8s-master opt]# vim  recommended.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: kubernetes-dashboardroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-admin  #name: kubernetes-dashboardsubjects:  - kind: ServiceAccount    name: kubernetes-dashboard    namespace: kubernetes-dashboard

砸了，再重新部署dashboard，当然登录时token肯定是变了的。

3. 部署kubernetes-dashboard时遇到的问题，以及值得提到的一些点。

（1）我在apply的时候发现kubernetes-dashboard 容器始终在重复的解体，处于CrashLoopBackOff 这个状态。
通过各种形式去查看和排查，例如 kubectl describe pod kubernetes-dashboard-b7ffbc8cb-4xcdp -n kubernetes-dashboard 能够查看容器的运行状况，例如到node下来docker logs $CONTAINERID，在例如去看kubelet的message，最初发现是网络通信方面的问题，容器无奈和Service的ClusterIP 10.96.0.1的网络通信。

Nov  3 23:48:54 k8s-node01 journal: panic: Get "https://10.96.0.1:443/api/v1/namespaces/kubernetes-dashboard/secrets/kubernetes-dashboard-csrf": dial tcp 10.96.0.1:443: connect: no route to host

看了看路由确实是有的，但报错也是提醒里有相干的问题。起初发现firewalld.service 的服务没无关。敞开后容器创立就胜利了。

（2）dashboard的作者单建了一个namespace，区别于旧版本的对立应用kube-system

（3）quay.io镜像能够用，而且拉取十分快。