1.k8s各容器的磁盘空间控制和隔离方案。分别local和nfs 如何控制。 中期各容器容量监控，后期如何方便扩容。

1.1 k8s各容器的磁盘空间控制和隔离方案

如果容器使用的是本地磁盘，那么我们可以基于本地磁盘切分的方法来实现容器磁盘空间使用的控制，LVM例如：我们可以先在 node 上基于 LVM 开辟一块逻辑卷，并实现对某个目录的挂在如这里我创建一个 k8slvm 的目录，并将对应的 LVM 逻辑卷挂在至该 k8slvm 目录，然后在基于 flexvolume 的方式将其挂载至容器中，如后期存储资源不够可以实现动态扩容

1.2 local和nfs 的控制

Local隔离和控制:
a.如 IO隔离从而实现避免业务性能问题，建议每个卷使用整个磁盘。
b.如POD容量使用隔离，建议每个卷单独使用一个分区
c.基于 UUID 实现文件系统卷的挂在，可通过ls -l/dev/disk/by-uuid 命令得到UUID。以确保即使设备路径发生变化比如 /dev/sda1 在添加新磁盘时变为 /dev/sdb1，也不会因为名称变化而错误挂在。此外，这种做法将确保如果创建具有相同名称的另一个节点，则该节点上的任何卷都是唯一的，而不会误认为是具有相同名称的另一个节点上的卷。

NFS 隔离和控制：
（1）对每个不同项目的POD做单一的PV实现独立的控制和隔离
（2）中期扩容的话基于对NFS的磁盘做扩容即可

2.有关极端情况K8S 集群崩溃的 处理方案。

这个暂时没有遇到过，当然也不想遇到所以不能很好的回答，只能说一下自己的预处理方式：
如果当 K8S 集群崩溃，我们这时候可以先导出 ETCD 数据已做好最坏的准备，然后再处理对应的问题，例如查看并分析日志，查看监控系统找出对应问题是否是因为某个业务导致，并查看节点健康性检查是否是因为磁盘 IO 、资源不足等问题，然后在分析问题从而解决

3、后期各种证书过期、各种崩溃，各种情况的无法启动，网络异常的排查和处理逻辑流程。

（1）解决证书过期问题：
假如因为证书过期的话可以通过命令journalctl -xefu kubelet查看日志获取关键报错part of the existing bootstrap client certificate in /etc/kubernetes/kubelet.conf is expired: 20xx-xx-xx xx:xx:xx +0000 UTC
解决办法：
对过期证书进行备份，并删除旧证书
生成证书：
kubeadm alpha certs renew all

备份旧证书
mv /etc/kubernetes/*.conf /tmp/

生成新的配置文件
kubeadm init phase kubeconfig all

重启K8S
systemctl restart kubelet

将新的conf 文件进行替换
cp /etc/kubernetes/admin.conf ~/.kube/config

（2）网络异常：
①Pod自身的网络故障
Pod自身网络出现问题，会导致Pod中多个容器通信出现异常，具体排查网络组件Calico即可解决问题。

②Pod与Pod之间通信故障
Pod与Pod之间的通信故障是经常会出现的现象，可以去排查网络组件Calico和Kube-proxy这两个组件。
③Pod与Node节点之间通信故障
当出现此故障时，一定是Calico网络组件产生了问题，需要排查具体的日志。
④业务网络排查：
当业务之间出现了网络问题，如果前提部署了链路工具可以通过分析链路是在那一块的网络出现了问题从而优化代码。

4、异常K8S集群通过恢复etcd的方案。

方案：
ETCD 异常排查，如 ETCD leader 故障，因为消息发不出去，导致问题节点自增 term 选举，又偶尔能发出消息，导致真正的 leader 发现 term 落后自降为 follower。
这个机制会在 自增 term 前做一次预选举，保证绝大多数节点认可后才会自增 term，像这个环境出现问题时，这个节点其实是无法获得其他两个节点认可的，也就没办法自增 term，等偶尔发出消息时，term 也是和正常 leader 保持一致的，不会导致 leader 自降为 follower，从而规避 这种问题。
当问题节点自愈后，重新加入集群，也不会对现任 leader 地位有任何冲击，保证了系统更稳定的方式运行。
恢复 ETCD 之后，停止 apiserver、etcd 两个服务，然后基于 systemctl status etcd 查看 Etcd 配置参数。并做恢复备份
恢复顺序：
停止 Kube-apiserver–> 停止 Etcd–> 恢复数据 –> 启动 Etcd –> 启动 Kube-apiserver，当然这里面是没有考虑恢复 PV 等持久化数据的问题

5、有限的时间内修不好，重做集群的快速恢复方案。

方案（1）：
如果本身我们的K8S集群做了主备的模式，而且平时就通过一些K8S备份工具如(velero)对K8S数据进行持久化，并且在将自动同步主机群的数据，如果说我们在有限的时间内没有恢复K8S集群，那么就可以通过K8S集群切换的方式到备集群从而对外提供使用
方案（2）：
如果我们只有一个集群做恢复，而且前提是 ETCD 、持久化数据都做了备份，那么我们可以基于出问题的集群本版部署一个集群，并且导入 ETCD 的K8S原始数据恢复对应的 namespace、pod 等资源，然后在新集群部署开源工具velero ，然后基于 velero 对接对应的对象存储从而导入持久化数据，实现快速恢复集群