开发小伙伴反应，发布应用失败。检查后发现有个虚拟机挂掉了
启动后先重启服务：（一般是自启动，自动拉起pod服务）
service docker restart
docker ps |grep kube-apiserver|grep -v pause|awk ‘{print $1}’|xargs -i docker restart {}
docker ps |grep kube-controller-manage|grep -v pause|awk ‘{print $1}’|xargs -i docker restart {}
docker ps |grep kube-scheduler|grep -v pause|awk ‘{print $1}’|xargs -i docker restart {}
以上重启之后，还没有恢复。
通过describe node,发现有其他报错。
Warning ContainerGCFailed 35s (x7 over 6m55s) kubelet, worker2k8s rpc error: code = ResourceExhausted desc = grpc: trying to send message larger than max (16777879 vs. 16777216)
暴力操作：（一般不建议）
• 目标：先控制不可调度，然后将原来的 Pod 驱逐、排干• 首先，将原来的 Pod 驱逐到其他节点重新创建运行• 然后，将节点标识为 SchedulingDisabled 状态，也就是禁止调度• 具体命令：
kubectl drain [node name] --force --ignore-daemonsets --delete-local-data
–force: 就算 Pod 不被 ReplicationController、ReplicaSet、Job、DaemonSet、StatefulSet 等控制器管理，也直接处理；不加 force 参数只会删除该Node 节点上前面提到的几个控制器类型的 Pod，加上之后所有的 Pod 都将删除
–ignore-daemonsets: 忽略 DeamonSet 管理的 Pod，否则 DaemonSet 被删除后，仍会自动重建
–delete-local-data: 删除本地数据，即使 emptyDir 也将删除
• 恢复调度命令：
kubectl uncordon [node name]
• drain 执行的方式是比较安全的，它会等到 Pod 容器应用程序优雅的停止之后再删除• 详细的过程：先在当前节点删除 Pod，然后再在其他节点创建对应的 Pod。因此为了保证 Drain 驱逐过程中不中断服务，必须保证要驱逐的 Pod 副本的数量大于 1,并且采用“反亲和”策略将这些 Pod 调度到不同的节点。这样子可以保证驱逐过程对服务没有影响。
好吧，资源都看不到了。
踢出pod没用的话，那就把node也先踢出，再加入。
node2:
kubeadm reset
rm -rf * /etc/kubernetes/
master:
kubeadm token create --print-join-command
分析：
node2,pod太多，导致内存溢出。驱逐pod node，重新分配
