共计 5319 个字符，预计需要花费 14 分钟才能阅读完成。
本文章是自己依照博客文章：《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:ef543a59aac99e4f86e6661a7eb04d05b8a03269c7784378418ff3ff2a2d2d3c2. 看后果：
胜利了的话屏幕的回显应该是这样的，如果失败了，检查一下起因。
我这边就失败了，通过两个终端查看的方法终于发现，还是老问题，镜像拉取卡住。我本来认为镜像只在 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 nodes
NAME STATUS ROLES AGE VERSION
192.168.56.99 Ready master 4d22h v1.19.3
k8s-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.yml
amespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created如果有问题，屏显会通知你哪一个资源没有创立胜利，再去批改和解决。
kubectl get pods -n kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-76585494d8-5jtvw 1/1 Running 0 86s
kubernetes-dashboard-b7ffbc8cb-4xcdp 1/1 Running 0 86s2. 端口裸露：
这时有一个问题，如何把 dashboard 封装一下供我的电脑去拜访呢？这个 dashboard 只有一个虚构的 ClusterIP（既无奈间接拜访，也无奈 PING 通），还有一个 podIP，也一样是无奈间接拜访。最终的答案实际上是在 dashboard.yml 文件中减少一些配置，将 Service 的 ClusterIP 转换到虚拟机的 NodeIP 上来，通过 NodeIP:NodePort 的形式来拜访这个服务。
[root@k8s-master opt]# vim recommended.yaml
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
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" deleted
serviceaccount "kubernetes-dashboard" deleted
service "kubernetes-dashboard" deleted
secret "kubernetes-dashboard-certs" deleted
secret "kubernetes-dashboard-csrf" deleted
secret "kubernetes-dashboard-key-holder" deleted
configmap "kubernetes-dashboard-settings" deleted
role.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
clusterrole.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
rolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
clusterrolebinding.rbac.authorization.k8s.io "kubernetes-dashboard" deleted
deployment.apps "kubernetes-dashboard" deleted
service "dashboard-metrics-scraper" deleted
deployment.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.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
#name: kubernetes-dashboard
subjects:
- 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 镜像能够用，而且拉取十分快。
