说明：以下为「面试口径」参考答案，尽量用“概念 + 关键点 + 排障路径 + 命令/指标”来回答。不同公司技术栈不同（CNI、日志、CI/CD、存储），面试时可替换成你实际用过的方案。

1. 介绍 K8s

• Kubernetes 是一套容器编排平台，核心目标：声明式地管理应用的部署、扩缩容、发布、服务发现、配置/密钥、存储、健康检查与自愈。
• 架构：控制面（kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager）+ 节点侧（kubelet、kube-proxy、容器运行时 containerd/CRI-O、CNI、CSI）。
• 关键对象：Pod、Deployment/ReplicaSet、StatefulSet、DaemonSet、Job/CronJob、Service/Ingress、ConfigMap/Secret、Namespace、RBAC、PV/PVC、HPA/VPA、NetworkPolicy。

2. 创建一个 Deployment，生成两个 Pod 的流程

• 编写 YAML（replicas: 2，镜像、端口、探针、资源、环境变量等），执行 kubectl apply -f deploy.yaml。
• apiserver 做认证/鉴权/准入（Admission），写入 etcd。
• deployment-controller 观察到期望副本数=2，创建/更新对应 ReplicaSet。
• replicaset-controller 创建 2 个 Pod 对象（仅“期望”，未落到节点）。
• scheduler 为每个 Pending Pod 选节点并写入 spec.nodeName。
• 目标节点 kubelet 通过 CRI 拉镜像、创建容器、挂载卷、执行 CNI 加网卡/分配 IP；探针通过后进入 Ready。
• 常用检查：kubectl get deploy,rs,pod -o wide、kubectl describe pod <pod>、kubectl get events --sort-by=.lastTimestamp。

3. 调度器调度的流程

• 触发：新 Pod（Pending 且未绑定节点）进入调度队列。
• 过滤（Filter）：基于硬约束筛掉不满足的节点（资源、NodeSelector/NodeAffinity required、Taints/Tolerations、Volume 绑定、端口冲突、NodeUnschedulable 等）。
• 打分（Score）：对剩余节点按策略打分（资源均衡、亲和/反亲和 preferred、拓扑分布等）。
• 绑定（Bind）：选择最高分节点，写回 Pod.spec.nodeName（绑定），并产生事件。
• 失败与回退：无可用节点会进入 backoff；Preemption 可能驱逐低优先级 Pod（取决于 priorityClass 和策略）。

4. Pod 的 DNS 流程

• Pod 启动时生成 /etc/resolv.conf（通常指向集群 DNS：CoreDNS Service 的 ClusterIP）。
• 应用查询域名：先走 libc 的解析流程（/etc/nsswitch.conf），再向 nameserver 发 UDP/TCP 53。
• CoreDNS：根据配置（kubernetes 插件）解析 *.svc.cluster.local（Service/Pod 记录），其他域名走 forward 到上游（节点 /etc/resolv.conf 或自定义 DNS）。
• 常见搜索域（search）：<ns>.svc.cluster.local、svc.cluster.local、cluster.local。

5. Pod 提示连接超时，DNS 如何排查

• 先区分：是 DNS 解析超时（nslookup/dig 卡住）还是解析成功但连接超时（网络/服务问题）。
• Pod 内检查：cat /etc/resolv.conf、nslookup kubernetes.default、dig +time=1 +tries=1。
• CoreDNS 侧：kubectl -n kube-system get pod -l k8s-app=kube-dns -o wide，看 CoreDNS 日志/指标、是否重启/CPU 飙高、是否被 NetworkPolicy 拦截。
• 网络路径：Pod 到 CoreDNS Service（ClusterIP）是否通：nc -u -vz <coredns-svc-ip> 53；确认 kube-proxy/IPVS/iptables 规则与 CNI。
• 上游 DNS：若外网域名超时，排 CoreDNS forward 上游、节点 DNS、出网（NAT/防火墙）。
• 常见坑：MTU 不一致、conntrack 表满、CoreDNS 被限流（CPU throttling）、节点 DNS 配置错误、ndots 导致大量无效查询。

6. Linux 进程的状态

• 典型状态（ps -o stat）：
  • R Running：运行/就绪队列中。
  • S Sleeping：可中断睡眠（等待事件/定时器）。
  • D Uninterruptible sleep：不可中断睡眠（常见于 IO/存储/驱动等待）。
  • T Stopped：被 SIGSTOP/调试器停止。
  • Z Zombie：已退出但父进程未回收（等待 wait()）。
• 状态扩展：< 高优先级、N 低优先级、L 有页锁、s session leader、+ 前台组等。

7. top 命令

• 实时查看系统/进程资源：CPU（用户/系统/IOwait/软中断等）、内存、负载、进程列表。
• 关键字段：%CPU、%MEM、RES（常驻）、VIRT、SHR、TIME+、S（状态）。
• 常用交互：P 按 CPU 排序、M 按内存、1 展开每核、H 显示线程、k 杀进程、c 显示完整命令、f 自定义列。

8. 什么是平均负载（Load Average）

• Load Average 是一段时间内（1/5/15 分钟）处于可运行队列（R）+ 不可中断睡眠（D）的平均数量。
• 经验判断：和 CPU 核数对比（例如 8 核机器 LA 长期 16 说明明显排队），但需要结合是否大量 D（IO 堵塞）。
• 配合指标：top/uptime、vmstat 1、sar -q、iostat -x 1。

9. 什么情况下进程处于不可中断状态（D）

• 进程在等待某些内核态资源且不响应信号，最常见是块设备/网络存储 IO（磁盘、NFS、Ceph/RBD、iSCSI）、驱动或文件系统锁等待。
• 排查思路：
  • ps -eo pid,stat,wchan:32,cmd | rg ' D' 看 wchan 卡在哪。
  • cat /proc/<pid>/stack 看内核栈。
  • 结合 iostat -x、dmesg、存储/网络告警判断底层是否抖动。

10. 怎么看进程 IO（iotop / pidstat）

• iotop -oPa：看实时读写速率与 IO 占用（需 root/权限）。
• pidstat -d 1：按进程输出 IO（kB_rd/s、kB_wr/s、iodelay）。
• 配合：iostat -x 1 看磁盘队列/延迟；lsof -p <pid> 看打开文件；容器内需映射到宿主机 PID/CGroups。

11. 僵尸进程

• 进程退出后保留一条 PCB/退出码，等待父进程 wait() 回收；此时状态 Z。
• 危害：数量多会耗尽 PID/进程表；本身不占用 CPU/内存（除少量内核结构）。
• 处理：找到父进程（ps -o ppid= -p <pid>），让父进程修复/重启；或让父进程处理 SIGCHLD 并正确 wait；极端情况下杀父进程让 init/systemd 接管回收。

12. 亲和、反亲和和污点（Taints/Tolerations）

• 节点亲和（NodeAffinity）：把 Pod 放到满足 label 的节点（替代/增强 nodeSelector）。
• Pod 亲和/反亲和（PodAffinity/AntiAffinity）：根据“同节点/同拓扑域（zone/hostname）上是否已有某类 Pod”来决定同置/分散。
• 污点/容忍（Taint/Toleration）：节点打 taint 表示“默认拒绝”，只有带相应 toleration 的 Pod 才能调度/继续运行；常用来隔离专用节点（GPU/infra）或驱逐问题节点。
• 典型组合：关键组件 toleration master/control-plane 污点；业务用 anti-affinity 或 topologySpread 分散。

13. requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution

• required...：硬约束，调度时必须满足；不满足则永远 Pending。
• preferred...：软约束，尽量满足；不满足也能调度，只是打分更低。
• IgnoredDuringExecution：只在调度时生效，Pod 运行后即使节点 label 变化也不会强制迁移（除非你用其他机制做驱逐/重调度）。

14. 监控内存用哪个指标（container_memory_working_set_bytes）

• container_memory_working_set_bytes：工作集内存（大致=最近使用的匿名页/文件页，不含易回收的 page cache），更贴近“实际压力”。
• 对比：container_memory_usage_bytes 往往包含 cache，容易“看着很高但可回收”；OOM 风险还要结合 cgroup limit 与 OOM 事件。
• 告警建议：优先用 working_set/limit；定位泄漏再看 rss/heap（配合应用指标）。

15. docker 和 containerd 的区别

• Docker（广义）包含：镜像构建/分发、CLI、守护进程、网络/存储管理等；早期通过 dockershim 接入 K8s。
• containerd：更底层的容器运行时，负责镜像拉取、容器生命周期、snapshotter（overlayfs），通过 CRI 插件直接对接 kubelet。
• 现状：K8s 已移除 dockershim，推荐 containerd/CRI-O；Docker 仍常用于本机构建与调试。

16. 压缩和不可压缩资源

• 可压缩（Compressible）：CPU（超用会被 CFS throttling 限流，不一定杀进程）。
• 不可压缩（Incompressible）：内存（超用会触发 OOMKill）、本地磁盘（写满导致异常）、PID 数等。
• 资源管理：requests 影响调度，limits 影响运行时限制（CPU quota / memory limit）。

17. namespace、cgroup、ufs（Union FS）

• Namespace：做“视图隔离”（PID、NET、MNT、UTS、IPC、USER），让容器看到的是自己的进程树/网络栈/挂载点等。
• Cgroups：做“资源限制与计量”（CPU、memory、io、pids 等），实现 requests/limits 的落地与统计。
• Union FS（常见 overlayfs/aufs）：把只读镜像层与可写层叠加，容器写入落在上层，便于镜像复用与快速启动。

18. Pod 达到 limit 时会出现什么现象

• CPU 超过 limit：容器不会被杀，而是被限流（throttling），表现为响应变慢、container_cpu_cfs_throttled_seconds_total 增长。
• 内存超过 limit：触发 cgroup OOM，内核 OOMKill 容器进程，Pod 可能 OOMKilled 并重启（取决于控制器/重启策略）。
• 排查要点：kubectl describe pod 看 Last State；节点 dmesg/journalctl -k 的 OOM 记录；Prometheus 看 throttling/OOM 指标。

19. TIME_WAIT 的原因、排查与解决

• 原因：主动关闭连接的一方进入 TIME_WAIT（TCP 四次挥手），保留一段时间以处理迟到报文/避免端口复用冲突。
• 排查：ss -ant state time-wait | wc -l，按源/目的聚合；判断是否短连接过多、连接复用缺失、探活策略导致。
• 解决思路：
  • 业务侧优先：开启 keepalive/连接池/HTTP2，减少短连接。
  • 系统侧（谨慎）：扩大 ip_local_port_range，调整 somaxconn/backlog；结合内核版本评估 tcp_tw_reuse 等参数。
  • 架构侧：在 LB/网关层复用连接，或改变关闭方向（让服务端主动关）减少客户端 TIME_WAIT。

20. 进程、线程和协程的区别

• 进程：资源隔离单位（地址空间、fd 表等），切换开销大，隔离强。
• 线程：同进程内执行单元，共享地址空间，切换较轻但需同步（锁/竞态）。
• 协程：用户态调度（如 Go goroutine、async/await），创建/切换更轻；阻塞 IO 需配合运行时/异步模型。

21. 了解过哪些网络内核参数（举例）

• 连接队列：net.core.somaxconn、net.ipv4.tcp_max_syn_backlog。
• 端口范围/复用：net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_reuse。
• keepalive：net.ipv4.tcp_keepalive_time/tcp_keepalive_intvl/tcp_keepalive_probes。
• 缓冲：net.core.rmem_max/wmem_max、net.ipv4.tcp_rmem/tcp_wmem。
• 路由/转发：net.ipv4.ip_forward、rp_filter。
• conntrack：net.netfilter.nf_conntrack_max、nf_conntrack_buckets（K8s 场景常见）。

22. K8s 默认提供哪些业务负载类型（与 Deployment 并列）

• 无状态：Deployment（底层 ReplicaSet，滚动发布/回滚）。
• 有状态：StatefulSet（稳定网络标识、有序发布、配合 PVC）。
• 每节点一份：DaemonSet（node-exporter、log agent）。
• 批处理：Job（一次性/并行任务）、CronJob（定时任务）。

23. ds 控制器是干什么的

• 让某个 Pod 在每个符合条件的节点上都运行一份（或指定节点集）。
• 典型用途：日志采集（fluent-bit）、监控采集（node-exporter）、CNI/存储插件、节点守护进程。
• 关键点：新增节点会自动补一份；可配合 tolerations 运行在 master/control-plane。

24. 如何自定义 K8s 资源

• 定义 CRD（CustomResourceDefinition），在集群中注册新的 API 资源类型。
• 写 Controller/Operator（client-go/controller-runtime），watch 自定义资源并把期望状态“翻译”为实际资源（Deployment/Service/Config 等）。
• 交付：CRD + RBAC + Controller 镜像（Deployment）+ Webhook（可选：校验/变更）。

25. 两个 Pod 网络不通如何排查

• 先定位范围：同节点不通/跨节点不通；是否受 NetworkPolicy 影响；目标端口是否监听。
• 基础信息：kubectl get pod -o wide（PodIP/Node），kubectl describe pod（事件/CNI）。
• Pod 内：ip a、ip r、ping/curl/nc，确认目标服务端口。
• 节点侧：检查 CNI（calico/flannel/cilium）Pod 状态与日志；路由/隧道；iptables/ipvs 规则；rp_filter。
• 常见坑：NetworkPolicy 默认拒绝、MTU、节点间防火墙、conntrack 表满、kube-proxy 异常。

26. nginx 可以做四层代理吗？可以做七层代理？LVS 可以做几层？

• Nginx：可以做七层（HTTP）反向代理；也可以通过 stream 模块做四层（TCP/UDP）转发。
• LVS：主要做四层（基于 IP/端口的负载均衡），不解析 HTTP 语义。

27. nginx 和 LVS 做四层代理的区别

• 转发模型：LVS 在内核态转发（性能高、延迟低）；Nginx 四层在用户态（更灵活但开销更大）。
• 能力：Nginx 更容易做连接控制/限流/日志/灰度；LVS 更适合超大吞吐、简单四层负载。
• 架构：LVS 常与 Keepalived 组成四层入口；七层能力通常交给 Nginx/Envoy。

28. nginx 访问 https 如何配置代理

• 场景 1：客户端到 Nginx HTTPS（TLS 终止），Nginx 回源 HTTP：listen 443 ssl; 配证书；proxy_pass http://upstream。
• 场景 2：Nginx 回源也是 HTTPS：proxy_pass https://upstream; 并配置 proxy_ssl_server_name on;、上游证书校验（proxy_ssl_verify on; proxy_ssl_trusted_certificate ...）。
• 常见头：proxy_set_header Host $host;、X-Forwarded-For、X-Forwarded-Proto https。

29. ceph 出现故障你的排查思路

• 先看整体健康：ceph -s、ceph health detail（是 mon/mgr/osd/pg 哪一类问题）。
• OSD：ceph osd tree、ceph osd stat，查看 down/out、磁盘满、延迟高；看节点磁盘 SMART、IO、网络。
• PG：ceph pg stat，是否 peering/incomplete/backfill_wait，结合告警判断恢复/回填压力。
• 网络与时钟：检查丢包/延迟/MTU、时钟同步（NTP）。
• 日志：/var/log/ceph/ 或 journalctl -u ceph-*。

30. GPU 利用率如何实现求和（三剑客）

nvidia-smi --query-gpu=utilization.gpu --format=csv,noheader,nounits | awk '{sum+=$1} END{print sum}'

31. 日志索引是多大的？如何规划的？日志索引是怎么分的？

• 先算量：日增日志（GB/天）= QPS * 平均日志大小 * 86400；索引占用通常 > 原始日志（取决于 mapping、字段数、压缩）。
• 规划维度：保留周期（天）、副本数、冷热分层（hot/warm/cold）、峰值写入、查询 SLA。
• 分索引策略：按时间（天/周）+ 按业务/环境（app/env/namespace）；ES 常配 ILM（滚动、迁移、删除）。
• Shard 经验：避免过多小 shard；控制单 shard 体量；压缩字段/关闭不必要的 text 分词。

32. kafka 消费数据这块是你负责吗？

• 说明你负责的范围：Topic 规划、消费组、offset 管理、堆积（lag）告警、重放、幂等/去重、吞吐与延迟调优、SLA。
• 常见问题：rebalance 抖动、消费堆积、单分区热点、消息过大、批量拉取与提交策略、故障重试与死信队列。

33. 日志的格式是如何规定的？

• 建议结构化：JSON，统一字段：timestamp（ISO8601）、level、service、env、trace_id/span_id、request_id、cost_ms、msg、error.stack。
• 规范：时区统一、字段命名统一、敏感信息脱敏、异常栈多行处理、采样策略。

34. 你们语言是用的 Java 还是 Go 还是什么？

• 回答思路：以业务为准，同时说明你对不同运行时的运维关注点：JVM（GC/heap/线程）、Go（GOMAXPROCS、goroutine、pprof）、Node/Python（事件循环/协程/依赖管理）。
• 强调一致性：统一指标/日志/trace、镜像规范、资源 requests/limits、探针与优雅退出。

35. 从 CI 结束到部署到 K8s 集群中间所有的流程如何实现？

• 典型链路：代码合并 -> CI（编译/单测/扫描）-> 构建镜像 -> 推送镜像仓库 -> 生成 Helm/Kustomize/manifest -> CD（Argo CD/Flux/Jenkins/GitLab CI）-> 部署到集群。
• 控制点：镜像不可变（tag/sha）、环境隔离、灰度/回滚、变更审计（GitOps）、发布后验证（指标/日志/探针）。

36. 你们镜像的 tag 是怎么读的？如何知道部署的哪个版本？

• tag 设计：常用 app:gitsha 或 app:semver+build，生产建议可追溯且不可变。
• 追踪手段：Deployment/Pod 上写 annotation/label（app.kubernetes.io/version、git_sha）；用镜像 digest 保证唯一性。
• 查询：kubectl describe pod 看 Image/Image ID。

37. prometheus 为什么用 TSDB？TSDB 的特点？

• 监控数据是时间序列，TSDB 针对“追加写 + 按时间范围查询”优化。
• 特点：高写入吞吐、按时间分块、压缩、按 label 索引、后台 compaction。
• 风险：高基数（label 组合爆炸）会导致内存/存储压力，需要控制 label 设计。

38. prometheus 有几种数据类型？

• Counter、Gauge、Histogram、Summary。

39. 你对 Linux 系统这边的了解程度怎么样？

• 建议从维度回答：进程/调度、内存管理（page cache、OOM）、文件系统（inode）、网络栈（TCP 状态机/队列）、IO、systemd/journal、容器（ns/cgroup）。
• 再结合真实案例：线上故障如何定位与闭环。

40. Linux 系统出现负载问题（服务很卡）要怎么排查？

• 定性：CPU/IO/内存/网络哪一类瓶颈。
• 快速三板斧：top、vmstat 1、iostat -x 1；再看 pidstat、sar、ss -s。
• CPU：热点线程/上下文切换/中断；IO：await/util；内存：swap/回收/OOM；网络：丢包/RTT/重传与连接数。

41. 内核日志在哪里可以看到（OOM/磁盘等）？

• dmesg -T、journalctl -k。
• 传统：/var/log/kern.log、/var/log/messages（看发行版/rsyslog）。
• OOM 会记录 Out of memory、Killed process 等关键字；容器还要看 cgroup OOM。

42. Linux 文件系统有哪些组成？Inode 概念？

• 组成：superblock、inode 表、数据块、目录项（dentry）、日志等。
• inode：存元数据（权限/属主/时间/数据块指针），文件名在目录项里；inode 耗尽用 df -i 排查。

43. MySQL 数据备份怎么做？主从一致如何保证？

• 备份：逻辑（mysqldump + --single-transaction）、物理（XtraBackup 热备）。
• 一致性关键：记录 binlog 位点或 GTID（--master-data / xtrabackup_binlog_info），恢复后按位点/GTID 接上复制链路。
• 跨库强一致：必要时停写或锁表/全局锁，或用业务对账补偿。

44. MySQL 发现连接泄漏要怎么处理？

• 确认：show processlist;、show status like 'Threads_connected';，观察连接数是否持续上涨。
• 止血：临时扩 max_connections、杀异常连接、重启应用/实例（必要时），并对入口限流保护 DB。
• 根因：连接池配置不当、未关闭连接、慢查询/长事务占用连接。
• 预防：统一连接池、超时与最大生命周期、慢查询治理、连接数监控告警。

45. Docker 跟虚拟机有什么区别？Docker 怎么实现隔离？

• 本质：VM 虚拟硬件并运行独立 Guest OS/内核；容器共享宿主机内核，只隔离进程/网络/文件系统视图与资源。
• 隔离：Namespaces + Cgroups + Union FS（overlayfs/aufs）+ Capabilities/Seccomp/AppArmor。
• 取舍：容器启动快、开销小；VM 隔离更强、兼容性更好（不同内核/OS）。