k8s常见面试题1

Kubernetes 基础知识

核心组件及作用

Kubernetes 的核心组件有哪些？各自的作用是什么？

• API Server：集群的入口，处理REST请求，校验并更新资源到etcd。
• etcd：分布式键值存储，保存集群状态和配置。
• Controller Manager：运行控制器（如Deployment、Node控制器），确保集群状态符合预期。
• Scheduler：将Pod调度到合适的节点。
• kubelet：在节点上管理Pod生命周期，与API Server通信。
• kube-proxy：维护节点网络规则，实现Service的负载均衡。

K8S生成pod过程

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 。
• 常见原因：
  • 镜像拉取失败（镜像不存在或权限问题）。
  • 资源不足（CPU/内存请求过高）。
  • 配置错误（如错误的挂载卷、环境变量）。
• 查看日志：kubectl logs --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）。