面试-2024年9月13号

提示：以下答案均为我个人的一些粗浅拙见，非正确答案，如果有考虑不足之处，欢迎诸位补充。

地点：北上广深
薪资范围：18k~19k

接收到告警后该怎么做（常规步骤）？

1. 接收到告警后，明确具体问题，评定风险等级。
2. 若对现网造成影响，优先保障现网稳定，第一时间向上通知。
3. 否则，分析定位问题根因，制定解决方案，向领导说明问题。
4. 解决方案需要考虑服务的安全性、可用性、可扩展性和性能。

---

生产环境K8S正在运行的一个node节点出现硬件层(比如硬盘)故障，应如何在不影响业务的情况下分析和解决？

1. 参考 接收到告警后该怎么做（常规步骤）？
2. 登录目标主机，执行cat /proc/mdstat命令（查看当前磁盘阵列组成情况），判断RAID级别（或判断有没有其他类似的磁盘冗余配置）。
3. 根据RAID级别，确定磁盘损坏能否修复。若能修复，则直接修复。
4. 若该工作节点不存在RAID阵列，且必须更换磁盘才能解决问题(并不需要移除工作节点)。
   • 使用 kubectl get pods -A -owide | grep <node-name> 命令，确认该工作节点上存在的pod有哪些。
   • 使用 kubectl describe pod <pod-name> -n <name-space> | grep “Container ID” 或使用 kubectl get pods <pod-name> -n <name-space> -o yaml | grep containerID， 获取目标 pod 的 Container ID。
   • 使用 df -hT | grep containerID，获取pod绑定到该工作节点的挂载目录有哪些。
   • kubectl describe pod <pod-name> -n <name-space> | grep -A 3 HostPath，获取pod挂载的宿主机目录有哪些。
   • kubectl describe pod <pod-name> | grep -A3 PersistentVolumeClaim，获取pod使用的pvc资源，通过pvc资源找到pv资源，通过kubectl describe pv | grep HostPath命令，确认pod是否有pv资源在该工作节点。
   • 通过上述三种方式，可以找到pod与工作节点的目录挂载关系，如果挂载目录与磁盘损坏目录重叠，则考虑驱逐pod后更换磁盘。
5. 若硬件故障严重，必须移除该工作节点。
   • 使用 kubectl cordon k8snode1 命令禁止新pod调度到该工作节点。
   • 如果 pod 副本只有一个，则先修改增加副本数。
   • 使用 kubectl drain <node-name> --ignore-daemonsets --delete-local-data --pod-selector=<selector>，驱逐指定标签的pod。若不指定标签时，则驱逐全部pod。
   • 对于有pv挂载到该工作节点的pod，也应该通过转移pod的方式来转移pv挂载的位置。pv支持通过 nodeAffinity 字段设置亲和性规则，指定PV可以或不可以被调度到哪些节点上；pv使用 nodeSelector 字段来指定节点标签，只有具有相应标签的节点才能使用该PV。

建议针对存储资源的使用，优先使用类似nfs、ceph等存储服务或产品，避免直接挂载与宿主机相关的目录，保持良好的解耦习惯。

---

在k8s集群中，某一个工作节点上，存在内存消耗特别高的Pod的，该如何处理？

1. 参考 接收到告警后该怎么做（常规步骤）？
2. 查看监控及服务器当前状态，若工作节点的资源已经到达风险值，考虑使用 kubectl cordon k8snode1 命令禁止新pod调度到该工作节点，防止服务器资源耗尽。
3. 查看监控历史记录，确认pod的资源消耗是否在合理范围内，若不合理，则需分析程序资源损耗异常的原因。
4. 导出yaml文件，分析yaml文件，确认nodeName、nodeSelector、nodeAffinity等设置是否合理。
5. 确认pod的 requests 和 limits 设置是否合理，这将影响 schedule 优选函数的执行结果，最好使用统一的资源计算策略确定要设置的值。
6. 合理的使用Horizontal Pod Autoscaler，通过增加pod的副本数量，可以降低单个pod的资源使用压力。
7. 若内存消耗高的pod必须转移走，则先对pod副本数进行扩容，然后使用 kubectl drain <node-name> --ignore-daemonsets --delete-local-data --pod-selector=<selector> 驱逐指定标签的pod。
8. （有一个思路：增加pod副本数，然后修改内存高的pod删除自身标签，这样该pod就不会被svc统计到，然后再delete删除pod，这样不知道可以吗。。）

合理的使用podAntiAffinity，这将提高服务的可用性.
根据服务类型（如cpu密集型、内存型）归类服务，通过恰当的标签，令pod运行在匹配的工作节点上。

---

calico有哪几种网络模式？各自有什么特点？使用场景如何？性能哪个更好？

calico基础

---

keepalive的工作原理是什么？

keepalive基础

---

service连不上了怎么排查问题

1. 使用 kubectl get svc -n <name-space> 命令，确认svc资源本身还在不在。若无则重新创建。
2. ping <service-ip> ，测试宿主机到svc的网络是不是通的。
3. telnet <service-ip> 8620 ，测试宿主机到svc的端口是否正常。
4. ipvsadm -Ln | grep -A 4 10.96.142.169 ，确认ipvs规则是否存在，若无则分析ipvs是否异常，或kube-proxy是否异常。
5. 使用 kubelet get pod -n <name-space> -owide 命令获取pod的IP地址，通过ping、telnet测试pod能否被直接访问。
6. 分析pod使用的yaml，确认端口是否配置正确。

---

两个服务不想让它连接怎么设置？

配置应用 NetworkPolicy 资源即可。
NetworkPolicy 支持对出(Egress)、入(Ingress)流量的限制。
NetworkPolicy 支持podSelector、namespaceSelector、ipBlock等方式进行流量管理。

---

自动化安装集群方面

• rancher
• k3s
• kubesphere
• kubeadm
• shell

---

pods的创建过程

pod生命周期

---

常用的命令

kubectl get 资源对象
kubectl describe pod
kubectl logs
kubectl exec -it <pod-name> -n <name-space> – sh
…

---

在负责的K8S项目上，例举几个出现的常见问题，是如何排查的；

…
自己想自己的，嘿嘿。
…

---

K8S一个node节点突然访问不到了，应该如何排查和解决?

1. 向上通知 。
2. 使用 kubectl get nodes 命令，获取k8s集群信息。
3. 使用 kubectl describe node <node-name> 命令，查看node节点当前状态是否为未就绪（NotReady）以及node节点未就绪的日志信息。
4. 确认 master 节点与 node 节点之间网络和端口是否正常
   • 在master能否远程node节点。
   • nc -zv <master-ip-address> 6443，端口测试。
   • 若不正常，则先解决网络问题。
5. 查看node节点的监控，确认资源使用是否异常。
   • 如果是资源不足，则扩充资源。
   • 如果是资源异常。则尝试重启kubelet解决，并分析kubelet日志 /var/log/message。
   • 如果是网络插件异常，查看分析网络插件日志（位于calico-system空间下），尝试重新安装网络插件解决。
6. 也可以顺便看下kube-proxy日志、containerd或docker日志、

---

如何批量删除未运行的pod节点所有副本？

kubectl get pods --field-selector=status.phase=Terminating -n <namespace> | grep -v NAME | awk '{print $1}' | xargs -r kubectl delete pod -n <namespace> --grace-period=0 --force

kubectl get pods --field-selector 'status.phase!=Running' -o name | xargs kubectl delete

---

说一下负责的K8S项目的规模及设计方案，如何投产、管理和监控的?

规模：…
…之前的一篇面试题中写过了，这就不写了…
监控：
日志监控：EFK、Loki
基础设施监控: Prometheus、n9e、DeepFlow
性能监控：SkyWalking、Jaeger、Kali
…