k8s常见面试题1
k8s常见面试题1
- Kubernetes 基础知识
- 核心组件及作用
- Pod、Deployment、Service的区别
- 保证Pod高可用
- ConfigMap vs Secret
- 网络模型与Pod通信
- Ingress 与 Service 的主要区别
- 什么是 Ingress
- k8s中为什么要做Service
- Ingress 与 Service 的区别
- 资源配额
- Kubernetes 实践
- 如何监控 Kubernetes 集群的健康状态?
- 如何实现应用的自动扩缩容(HPA)?
- 如何备份和恢复 etcd 数据?
- 如何管理节点的调度和污点(Taint/Toleration)?
- 集群升级
- Pod无法启动排查
- 滚动更新与回滚
- 故障排查
- 如何查看 Pod 的日志?
- 如何诊断 Kubernetes 集群的网络问题?
- 如何排查节点资源不足的问题?
- 如何分析集群性能瓶颈?
- Pod处于Pending状态
- CrashLoopBackOff原因
Kubernetes 基础知识
核心组件及作用
Kubernetes 的核心组件有哪些?各自的作用是什么?
- API Server:集群的入口,处理REST请求,校验并更新资源到etcd。
- etcd:分布式键值存储,保存集群状态和配置。
- Controller Manager:运行控制器(如Deployment、Node控制器),确保集群状态符合预期。
- Scheduler:将Pod调度到合适的节点。
- kubelet:在节点上管理Pod生命周期,与API Server通信。
- kube-proxy:维护节点网络规则,实现Service的负载均衡。
Pod、Deployment、Service的区别
Pod、Deployment、Service 的区别是什么?
- Pod:最小调度单元,包含一个或多个容器,共享网络/存储。
- Deployment:管理Pod的副本数和滚动更新。
- Service:定义一组Pod的访问策略(固定IP/DNS),提供负载均衡。
保证Pod高可用
如何保证 Pod 的高可用性?
- 使用Deployment设置
replicas > 1
。 - 配置Pod反亲和性(Anti-Affinity),分散Pod到不同节点。
- 结合HPA(Horizontal Pod Autoscaler)自动扩缩容。
ConfigMap vs Secret
ConfigMap 和 Secret 的区别及使用场景?
- ConfigMap:存储非敏感配置(如环境变量、配置文件)。
- Secret:存储敏感信息(如密码、密钥),以Base64编码(非加密)。
- 使用场景:ConfigMap用于应用配置,Secret用于安全凭证。
网络模型与Pod通信
Kubernetes 的网络模型是什么?如何实现 Pod 间通信?
- 每个Pod有独立IP,可直接跨节点通信。
- CNI插件(如Calico、Flannel)实现Pod网络。
- Service通过
kube-proxy
的iptables/IPVS规则转发流量。
Ingress 与 Service 的主要区别
什么是 Ingress
- Ingress 是 Kubernetes 中的一种 API 资源,用于管理外部 HTTP(S) 访问集群内部服务的流量。
- 它通过定义一组路由规则,将来自外部的请求转发到 Kubernetes 集群中的相应 Service,并且通常依赖 Ingress Controller(如 Nginx Ingress Controller, Traefik, Istio)来实际处理流量。
k8s中为什么要做Service
- Pod 漂移问题,可以理解成Pod IP是变化的
- Kubernetes具有强大的副本控制能力,能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的,还可以动态扩容等。通俗地说,这个Pod可能在任何时刻出现在任何节点上,也可能在任何时刻死在任何节点上;那么自然随着Pod的创建和销毁,Pod IP 肯定会动态变化;
- 这里借助于Kubernetes的 Service 机制,Service可以以标签的形式选定一组带有指定标签的Pod,并监控和自动负载他们的Pod IP,那么我们向外暴露只暴露Service IP就行了;这就是NodePort模式:即在每个节点上开起一个端口,然后转发到内部Pod IP 上。
- Service是一组Pod的逻辑集合,这一组Pod能够被Service访问到。可以通过Label Selector找到它所关联的Pod。但是属于四层代理,只能基于IP和端口代理。
Ingress 与 Service 的区别
Ingress 与 Service 的主要区别:
对比项 | Ingress | Service |
---|---|---|
作用 | 管理 HTTP/HTTPS 入口流量 | 在集群内部或外部暴露 Pod |
使用场景 | 主要用于 Web 入口流量 | 内部通信或直接暴露服务 |
协议支持 | 主要支持 HTTP/HTTPS | 支持 TCP、UDP、HTTP、HTTPS |
负载均衡 | 依赖 Ingress Controller 进行 L7 负载均衡 | ClusterIP 仅限内部,LoadBalancer & NodePort 提供 L4 负载均衡 |
使用方式 | 需要单独定义 Ingress 资源,并配置 Controller | 通过 kubectl expose 创建 Service 资源 |
扩展能力 | 可以使用 TLS、Rewrite、Path-Based Routing | 仅提供基础的流量转发 |
- Ingress 依赖 Service,但 Service 可以独立使用。
- Ingress 适用于管理 HTTP/HTTPS 流量,而 Service 适用于各种网络通信需求。
- 一般情况下,Service(如 ClusterIP 或 NodePort)为 Ingress 提供后端服务。
资源配额
如何管理 Kubernetes 的资源配额(Resource Quota)?
- 在 Kubernetes 中,资源配额(Resource Quota)用于限制命名空间中的资源使用,确保资源分配的公平性和可控性。
- 我们可以通过创建 ResourceQuota 对象来定义配额,限制 CPU、内存、存储等资源的使用量,以及 Pod、Service 等对象的数量。
- 例如,在一个多团队共享的集群中,可以为每个团队创建独立的命名空间,并配置 ResourceQuota 来限制每个团队的资源使用。这样可以防止某个团队占用过多资源,影响其他团队的应用。
在命名空间中创建 ResourceQuota 对象,定义资源限制。
apiVersion: v1
kind: ResourceQuota
metadata:
name: example-quota
namespace: my-namespace
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
pods: "10"
services: "5"
persistentvolumeclaims: "4"
Kubernetes 实践
如何监控 Kubernetes 集群的健康状态?
集群级监控
- 检查控制平面组件状态(如 etcd、scheduler)
kubectl get componentstatuses
监测节点状态。
kubectl get nodes
资源监控
- 监控 CPU、内存使用情况(需 Metrics Server)
- Prometheus + Grafana 采集和可视化集群指标。
kubectl top nodes/pods
日志监控
- 查看 Pod 日志
- ELK(Elasticsearch + Logstash + Kibana)或 Loki + Grafana 进行集中日志管理
kubectl logs <pod>
告警机制
- Alertmanager 结合 Prometheus 进行自动告警
- 监测集群异常事件。
kubectl get events
如何实现应用的自动扩缩容(HPA)?
HPA(Horizontal Pod Autoscaler)作用: 根据 CPU、内存 或 自定义指标 自动调整 Pod 数量
- HPA 通过 Metrics Server 监测 CPU/内存等指标,动态调整 Pod 副本数。
- 例如,可以设置 kubectl autoscale deployment my-app --cpu-percent=50 --min=2 --max=10,当 CPU 使用率超过 50% 时,HPA 会自动扩展 Pod 数量。
如何备份和恢复 etcd 数据?
etcd 作用: Kubernetes 存储所有集群状态,如 Pod、Service、ConfigMap、Secrets 等。
- etcd 存储 Kubernetes 的所有数据,备份可以使用 etcdctl snapshot save 生成快照,恢复时用 etcdctl snapshot restore。在生产环境,建议定期备份 etcd,并存储到安全的远程存储。
如何管理节点的调度和污点(Taint/Toleration)?
Taint(污点)作用: 防止特定 Pod 被调度到某个节点,适用于 专用节点(如 GPU、高优先级应用)。
- Taint 用于限制 Pod 调度,例如 kubectl taint nodes node1 key=value:NoSchedule,防止 Pod 被调度到该节点。Pod 需要 tolerations 才能匹配该节点。另外,可以使用 Node Affinity 进一步控制 Pod 运行在哪些节点上。
集群升级
如何升级 Kubernetes 集群?
- 使用
kubeadm upgrade
逐步升级控制平面和节点。 - 先升级Master节点,再逐个升级Worker节点。
- 通过
kubectl drain
排空节点,升级后uncordon
。
Pod无法启动排查
如何排查 Pod 无法启动的问题?
- 检查事件:
kubectl describe pod <pod-name>
。 - 常见原因:
- 镜像拉取失败(镜像不存在或权限问题)。
- 资源不足(CPU/内存请求过高)。
- 配置错误(如错误的挂载卷、环境变量)。
- 查看日志:
kubectl logs <pod-name> --previous
(若容器已崩溃)。
滚动更新与回滚
如何实现滚动更新和回滚?
- 滚动更新:Deployment通过逐步替换旧Pod实现无宕机更新。
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
- 回滚:
kubectl rollout undo deployment/<name> --to-revision=<number>
故障排查
如何查看 Pod 的日志?
使用 kubectl logs 查看 Pod 日志
- 可以使用 kubectl logs 查看 Pod 日志,-f 选项用于实时监控。
- 对于多容器 Pod,使用 -c 指定容器。
- 生产环境推荐 ELK 或 Loki + Grafana 进行集中式日志管理。
kubectl logs <pod-name>
kubectl logs --previous <pod-name> #查看历史日志(适用于崩溃的容器)
kubectl logs -f <pod-name> #实时监控日志
如何诊断 Kubernetes 集群的网络问题?
- 首先检查 Pod 是否能 ping 通,kubectl exec 进行 DNS 解析测试;
- 然后查看 kubectl describe pod 是否有网络错误;
- 如果问题仍未解决,可检查 CNI 插件、kube-proxy 规则或使用 tcpdump 抓包分析。
kubectl exec -it <pod-name> -- ping <target-ip> #检查 Pod 网络连通性
kubectl exec -it <pod-name> -- nslookup <service-name> #检查 Service 是否正常解析
kubectl describe pod <pod-name> # 查看 Pod 事件是否有网络错误
kubectl get pods -n kube-system | grep calico # 检查 CNI 网络插件 适用于 Calico
kubectl port-forward svc/my-service 8080:80 #使用 kubectl port-forward 进行测试
kubectl exec -it <pod> -- tcpdump -i eth0 #抓包分析(tcpdump)
iptables -L -t nat | grep KUBE #检查 kube-proxy 和 iptables 规则
如何排查节点资源不足的问题?
- 首先使用 kubectl top nodes/pods 检查 CPU/内存占用情况
- 然后 kubectl describe node 查看资源限制。
- 若有 OOM 现象,可 dmesg | grep -i oom 检查是否发生内存溢出。
- 此外,还需检查磁盘空间是否不足,以及节点是否有 Taint 影响调度。
kubectl top nodes #查看节点资源使用情况
kubectl top pods --all-namespaces #查看 Pod 资源占用
kubectl describe node <node-name> #描述节点,检查资源限制
dmesg | grep -i "oom" #查看 OOM 相关事件
df -h #检查节点磁盘使用
kubectl describe node <node-name> | grep Taint #检查节点是否有污点(Taint)导致调度失败
kubectl describe pod <pod-name> #查看调度失败的事件
如何分析集群性能瓶颈?
- 首先 kubectl top nodes/pods 查看资源瓶颈
- 结合 Prometheus + Grafana 监控 CPU、内存、网络等指标;
- 其次,检查 Service 和 Ingress 的延迟,tcpdump 抓包分析网络流量;
- 如果是存储问题,可以使用 iostat 分析磁盘 IO;
- 对于应用层,可结合 pprof 进行代码级性能优化。
iostat -xm 1 #检查 PV/PVC 读写速率
go tool pprof http://localhost:6060/debug/pprof/profile #适用于 Golang / Java / Python 业务代码的性能分析
Pod处于Pending状态
Pod 处于 Pending 状态的可能原因?
- 资源不足(节点CPU/内存不足)。
- 无匹配节点(节点Selector/Taint未匹配)。
- 持久卷声明(PVC)未绑定PV。
CrashLoopBackOff原因
Pod 处于 CrashLoopBackOff 状态的可能原因?
- 应用启动失败(如配置错误、依赖服务不可用)。
- 容器启动后立即退出(检查日志)。
- 资源限制过小(如内存不足导致OOMKilled)。