1、200 个节点，20 个是 GPU 节点，如何部署 GPU exporter？
我会使用 DaemonSet 的方式部署 GPU exporter，并通过标签把 Pod 精确调度到 GPU 节点上。
首先给 GPU 节点打上统一的 label，比如 gpu=true，然后在 DaemonSet 中使用 nodeSelector 或 nodeAffinity 指定只调度到这些节点。
如果 GPU 节点存在 taint，还需要配置对应的 tolerations。
同时会依赖 NVIDIA Device Plugin 来管理 GPU 资源，确保 exporter 能正确识别显卡。
这样做可以保证每个 GPU 节点只运行一个采集器，不会影响普通业务节点。
2、Node 变成 NotReady，完整排查思路是什么？
我会从下往上分层排查。
第一步是用 kubectl describe node 查看节点事件。
第二步检查 kubelet 状态，确认是否正常运行。
第三步检查容器运行时，比如 containerd 是否异常。
第四步检查节点资源，CPU、内存、磁盘是否耗尽，尤其是磁盘 inode 和 overlay 挂载。
第五步检查网络组件，比如 kube-proxy 和 CNI 插件是否正常工作。
第六步查看系统负载和内核日志。
常见原因包括 kubelet 崩溃、磁盘满、OOM、网络中断等。
3、K8s 有几种探针？Pod 频繁重启应该调整哪一类？
Kubernetes 有三种探针：
livenessProbe 用于判断容器是否存活；
readinessProbe 用于控制是否接收流量；
startupProbe 用于保护启动较慢的应用。
如果 Pod 频繁重启，通常应该调整 livenessProbe 的参数，比如 initialDelaySeconds、periodSeconds 和 failureThreshold。
对于启动时间较长的应用，一定要配合 startupProbe 使用，否则会被 livenessProbe 反复判定为不健康导致重启。
4、一个 Pod 有多个容器，如何进入指定容器？
可以使用 kubectl exec 命令并指定容器名。
命令格式是 kubectl exec -it pod名称 -c 容器名 -- /bin/bash。
如果不指定 -c，默认只会进入第一个容器。
如果容器里没有 bash，可以用 /bin/sh。
5、Service 和 Pod 靠什么标识绑定？kube-proxy 如何转发流量？
Service 是通过 label selector 和 Pod 绑定的。
Service 会选择符合标签的 Pod，并把它们写入 Endpoints 或 EndpointSlice。
kube-proxy 负责监听这些变化并更新节点上的转发规则。
常见的模式有 iptables 和 IPVS，iptables 是默认模式，IPVS 更适合大规模集群，性能和负载均衡能力更强。
6、如何检查 Service 和 Pod 是否正常绑定？
可以通过 kubectl get endpoints 查看 Service 是否有对应的 Pod IP。
也可以用 kubectl describe svc 查看 selector 是否正确匹配。
如果 Endpoints 为空，通常是 Pod 标签不匹配或者 Pod 本身不是 Ready 状态。
7、hostPath 和 emptyDir 的使用场景是什么？
emptyDir 适合临时数据存储，比如缓存、临时文件，或者同一个 Pod 内多个容器之间共享数据。
hostPath 适合需要访问节点本地资源的场景，比如日志采集、监控 Agent、DaemonSet。
在生产环境中，hostPath 要谨慎使用，因为它会直接依赖节点，存在安全风险和可移植性问题。
8、K8s 存储类型有哪些？生产环境用什么？
Kubernetes 支持多种存储类型，包括 emptyDir、hostPath、NFS、Ceph、云厂商块存储等。
生产环境通常使用 PV 和 PVC 配合 StorageClass 使用。
公有云上一般使用云盘或云厂商 CSI 插件，私有云常用 Ceph RBD 或 CephFS。
9、只想分批重启部分 Pod，比如 20 个，怎么做？
如果是 Deployment，可以直接使用 rollout restart 触发滚动重启。
也可以通过调整副本数分批重启，比如先缩容再扩容。
更规范的做法是在 Deployment 的 strategy 中配置 rollingUpdate，通过 maxSurge 和 maxUnavailable 控制每次重启的数量，确保业务不中断。
10、集群 CNI 用哪一款？Terway 有几种模式？
生产环境中常用的 CNI 包括 Calico、Flannel 和 Cilium。
Calico 功能全面，适合大多数场景；Cilium 基于 eBPF，性能更高。
Terway 主要有三种工作模式：ENI 直通模式、共享 ENI 模式和虚拟交换机模式。
在阿里云生产环境中，ENI 直通模式是最推荐的。
11、Pod Pending，提示内存不足和 taint，如何排查和解决？
首先用 kubectl describe pod 查看具体调度失败原因。
如果是 Insufficient memory，说明 Pod 的 requests 超过了节点可用资源，可以降低 requests 或扩容节点。
如果是 node has taint，说明节点被标记了 NoSchedule，可以给 Pod 配置对应的 toleration，或者去掉节点的 taint。
同时可以结合节点亲和性和污点机制，让 Pod 调度到合适的节点上。
12、不删除 Pod，如何临时把 Pod 从 Service 中摘除？
最直接的方法是修改 Pod 的 label，让 Service 的 selector 不再匹配该 Pod。
也可以临时修改 readinessProbe，让它返回失败，这样 Pod 会被标记为未就绪并从 Endpoints 中移除。
还可以调整 Service 的 selector，临时把流量切走。
这些方法都不会真正删除 Pod，只是让它暂时不接收流量，适合用于调试和问题排查。
13、requests 和 limits 的作用？只设置 limits 会怎样？
requests 决定调度时的资源分配，limits 限制容器运行时的最大资源使用。
如果只设置 limits 而不设置 requests，Kubernetes 会默认把 requests 设为和 limits 一样大。
这会导致调度器认为 Pod 需要更多资源，可能造成调度失败，同时也增加了节点资源争抢的风险。
生产环境中一定要同时设置 requests 和 limits。
14、etcd 备份和恢复流程？误删 Namespace 能恢复吗？
etcd 备份使用 etcdctl snapshot save 命令生成快照文件。
恢复时需要先停止集群，然后用 etcdctl snapshot restore 恢复数据，再重新启动 etcd 和 apiserver。
如果误删了某个 Namespace，可以通过 etcd 快照恢复到删除前的状态，但 etcd 恢复是集群级别的，不能只恢复单个 Namespace。
恢复过程中需要停机，并且要提前做好测试验证，生产环境建议结合 Velero 做应用级备份。
重构你的时间逻辑)
