DevOps面试题

DevOps
留言

https://www.v2ex.com/t/895119#reply75


  • 1 、都说 linux 下一切皆文件，你是怎么理解的？
  • 2 、都说 socket 在 linux 实际是一个文件，是通过什么技术将 socket 变成一个文件的？
  • 3 、linux 下软 /硬连接是什么，他们有什么区别？
  • 4 、linux 下一个用户登录以下文件加载顺序是？~/.bash_profile, ~/.bash_login, ~/.profile, ~/.bashrc, /etc/profile
  • 5 、都说 systemd 他可以并行启动，他的实现原理是？ 僵尸进程 /孤儿进程他们是？区别是啥？为什么说 ssh 很安全？具体原理是？如何保证的
  • 6 、shell 相关 [[]] [] (()) () 他们区别是？
  • 7 、shell fuction 如何返回字符串
  • 8 、shell $# $* 是什么意思
  • 9 、如何使用 shell 实现一个爬虫，你描述下整个过程，会用到哪些命令？
  • 10 、redis 哨兵机制主从是如何切换的？
  • 11 、网络 mtu 是什么？他发生在那一层，如果 2 个设备 mtu 值不同，以谁为准，那么 2 个设备是如何协商的？详细协商流程是？
  • 12 、0.0.0.0 255.255.255.255 这 2 个 ip 地址是什么意思？他们的适用场景是？ VIP 如何漂移的？他的底层原理是？
  • 13 、tunnel VPN 翻墙他实现的原理是，他是怎么绕过防火墙的，数据包传输流程，他在那一层欺骗了防火墙等
  • 14 、nginx 相关 正向 /反向代理是什么意思？他们区别是？
  • 15 、一般架构 nginx 集群 –反向代理–> tomcat ，为什么不能反过来部署呢？高并发 /动静分离等，这些我程序也可以做
  • 16 、都说 nginx 轻量级，比如对比 tomcat ，epoll 是操作系统机制，与 nginx 无关，我自己开发也可以调用，内存占用小 /启动快这不是特点，模块化这也不是特点，我自己开发程序也可以实现。。。
  • 17 、都说 docker 轻量级，他轻量在哪里，从技术角度分析，咱们都是搞技术，不需要从产品角度分析他为什么轻量？
  • 18 、docker volume bind mount 他们区别是什么？ 如何构建最小的镜像，说说你的思路？
  • 19 、docker -p/P 他的实现原理是什么？
  • 20 、Infrastructure as code 思想，你是怎么理解的？
  • 21 、资产管理 /配置管理他们分别是？区别是？
  • 22 、持续部署 /持续交付他们是？区别是？
  • 23 、ci/cd 带来的好处是？蓝绿发布是？他的优缺点？
  • 24 、jenkins 如何通过原生方式备份配置 /job 等（不通过 jenkins 提供导入导出 /及拷贝整个目录）
  • 25 、pipeline 是什么，他有什么优势？
  • 26 、jenkins 我要在其他环境重放 job 如何实现？
  • 27 、shift-left 你是怎么理解的？
  • 28 、git 相关 svn/git 分别是？他们有什么区别？
  • 29 、git 中 index/local/remote/workspace 他们是？比如 git add xxx 他发生了什么？
  • 30 、都说 git 管理 /切分支等轻量，他们轻量在哪里，具体原理是？
  • 31 、git rebase xxx 发送冲突时，他的根本原因是？不要说具体场景； git fetch/git pull 他们区别是？
  • 32 、你平时开发使用一套分支流程是？为什么要这么做？他的优缺点是？
  • 33 、kafka 相关 broker partition segment 他们是？他们关系是？
  • 34 、kafka 如何保证数据可靠？ ISR 是什么？他的工作机制是？
  • 35 、python 相关 GIL 是什么，为什么需要它？
  • 36 、python decoration(装饰器) 他的场景是？他的原理是？
  • 37 、如果要你实现一个 sidecar ，说说你的思路？
  • 38 、线上一个服务响应很慢，你如何排查，排查流程是？

上面大家说了很多的运维，一般跟业务开发比较紧密的是三种类型的运维：
一是业务运维，俗称 SRE ，在服务开发完毕提测后，或者是提测结束后，业务运维就开始介入，后续服务的业务问题基本是他们负责，当然在标准的流程里业务流程介入更早，项目需求评审的时候就参与了。
第二种与第三种都是运维开发，但是面对不同的场景，第二种俗称 DevOps ，做流水线开发的，还有叫 CICD
第三种就是运维开发，做监控系统，一般搞的监控面板与告警。

他们各自的技术栈是这么划分的，首先是业务运维，业务运维一般会 Shell 就足够了，不强求其他高级语言能力，业务运维是一个可以划水但需要一直 oncall 的岗位，虽然他们叫 SRE ，在谷歌的最佳实践里，SRE 有很高的定位，比如 SRE 首先是一个标准的业务开发，显然在国内的情况，此 SRE 非彼 SRE ，就像下面说的 DevOps 一样，本来只是一个最佳实践，在国内却是一类岗位。
运维开发，简单来说是开发系统给业务运维使用提升效率的，一般业务运维的上升通道都是往这两个方向走，没有孰优孰劣，但是要说在运维层面来说，流水线是需要根据基础架构定制的，而监控系统一般是适用基础架构，所以现在运维基本都卷在 DevOps 这块，有更高的自由度，最主要的可以制定规则，terraform 、tekton 、argocd 、kubernetes 这些工具与系统，gitlab flow 、gitops 、aiops 这些耳熟能详的最佳实践，都是在 DevOps 这块，目前 DevOps 的技术栈，基本都在 golang 这块。
监控告警运维开发，打交道的就是常见的工具或系统了，prometheus 、loki 、grafana 、elk ，对接开发各种告警平台，收集与告警的一般可以粗略分为业务服务基础状态、metrics 、logs 、apm 等等，针对指标、阈值做被动的告警，还有主动监控类。高级语言能力一般 python 比较多。

https://www.v2ex.com/t/850507#reply78

我在面试运维工程师，帮我详细且正确准备以下问题的答案： 1. 熟悉基础名词及其含义：container 、pod 、deployment/stateulset…

  1. 熟悉 container 和 pod 之间的区别

  2. 熟悉 pod 的常见故障及其解决方法

  3. 熟悉 k8s 架构组成

  4. 熟悉 k8s 的服务发现原理

  5. 熟悉 ingress 及其基本原理

  6. 熟悉 pod 在 node 间的基本调度原理

  7. 熟悉 k8s 网络架构以及常见的 cni 组件选型方案

  8. 熟悉 pod 日志的几种采集方案及其优缺点

  9. 熟悉 etcd 和其在 K8s 中的作用，以及其备份恢复方案

  10. 熟悉 k8s 的几种监控方案

  11. 熟悉调试 Kubernetes 中的性能问题

  12. 熟悉大型 k8s 集群的常见性能问题及其解决方案

  13. 熟悉多集群的需求背景、搭建和管理方案

  14. 熟悉 Service Mesh 和其在 k8s 中的应用

以下是针对运维工程师面试中Kubernetes相关问题的详细解答，内容结构化且涵盖关键点：

1. 基础名词及含义

  • Container
    • 轻量级、可移植的运行时环境，包含应用代码及其依赖，提供隔离的运行空间（如Docker容器）。
  • Pod
    • Kubernetes的最小调度单元，由一个或多个共享网络/存储的容器组成，生命周期短暂。
  • Deployment
    • 管理无状态应用，支持滚动更新、回滚和副本数扩缩容，确保Pod的高可用。
  • StatefulSet
    • 管理有状态应用（如数据库），提供稳定的Pod名称、持久化存储和顺序部署/扩展。

2. Container与Pod的区别

  • Container
    • 独立进程，隔离的运行时环境，无IP或持久存储。
  • Pod
    • 逻辑主机，包含共享网络命名空间（同一IP）和存储卷的多个容器，是调度的基本单位。

3. Pod常见故障及解决

  • 镜像拉取失败
    • 检查镜像名称、权限、仓库可达性；使用kubectl describe pod查看事件。
  • 资源不足（OOMKilled）
    • 调整Pod的requests/limits；监控节点资源分配。
  • 健康检查失败
    • 验证livenessProbe/readinessProbe配置；检查应用响应延迟。
  • 存储挂载失败
    • 确认PVC/PV配置正确；存储插件状态正常。

4. Kubernetes架构

  • Master节点
    • API Server：集群操作的入口，RESTful接口。
    • Scheduler：调度Pod到Node。
    • Controller Manager：执行扩缩、滚动更新等控制循环。
    • etcd：分布式键值存储，保存集群状态。
  • Worker节点
    • kubelet：管理Pod生命周期。
    • kube-proxy：维护Service的IP转发规则。
    • 容器运行时：如containerd、Docker。

5. 服务发现原理

  • ClusterIP Service
    • 分配虚拟IP，通过kube-proxy配置iptables/IPVS规则，流量转发至后端Pod。
  • DNS解析
    • CoreDNS为Service提供<service>.<namespace>.svc.cluster.local域名解析。
  • Endpoints
    • 动态跟踪Pod IP变化，Service通过Endpoints列表路由流量。

6. Ingress原理

  • 作用
    • 七层（HTTP/HTTPS）流量管理，提供基于域名的路由、TLS终止。
  • 实现
    • 由Ingress Controller（如Nginx、Traefik）监听API Server，生成反向代理配置。
  • 对比Service
    • Service为四层（TCP/UDP），Ingress扩展了七层路由能力。

7. Pod调度原理

  • 调度流程
    1. 过滤（Predicates）：排除不满足资源/规则的Node。
    2. 打分（Priorities）：选择最优Node（如资源余量最多）。
  • 策略
    • 亲和性/反亲和性：控制Pod分布。
    • 污点与容忍：限制Pod调度到特定Node。
    • 资源请求：基于requests分配CPU/内存。

8. 网络架构与CNI

  • 网络模型要求
    • Pod跨Node互通，且IP唯一；Service虚拟IP可路由。
  • 常见CNI
    • Calico：基于BGP的路由，支持网络策略，适合高性能场景。
    • Flannel：Overlay网络（VXLAN），配置简单，适合中小集群。
    • Cilium：基于eBPF，提供高级网络策略和观测能力。

9. Pod日志采集方案

  • 节点级采集（Filebeat/Fluentd）
    • 优点：低资源开销。
    • 缺点：需统一日志路径，多容器日志混合。
  • Sidecar容器
    • 优点：隔离应用日志。
    • 缺点：增加资源消耗。
  • DaemonSet（Logstash）
    • 优点：集中处理。
    • 缺点：需维护额外组件。

10. etcd作用与备份恢复

  • 作用
    • 存储集群状态（Pod、Service等资源元数据）。
  • 备份命令 
    1
    2
    3
    etcdctl snapshot save /path/to/snapshot.db \
      --endpoints=https://<etcd-ip>:2379 \
      --cacert=ca.crt --cert=etcd.crt --key=etcd.key
  • 恢复步骤
    1. 停止所有kube-apiserver。
    2. 使用etcdctl snapshot restore恢复数据。
    3. 重启etcd和kube-apiserver。

11. 监控方案

  • Prometheus+Grafana
    • 采集指标，自定义告警，可视化展示。
  • cAdvisor
    • 容器资源监控（CPU/内存/文件系统）。
  • 商业方案
    • Datadog、New Relic：全栈监控，集成告警。

12. 性能问题调试

  • 资源瓶颈
    • 使用kubectl top node/pod查看CPU/内存使用。
  • 网络延迟
    • 检查CNI插件、节点间网络带宽。
  • 存储性能
    • 监控PV的IOPS/吞吐量；优化存储后端（如SSD）。
  • 工具
    • pprof分析应用性能；kubectl describe查看事件。

13. 大型集群性能问题

  • etcd瓶颈
    • 分离etcd集群与业务；启用etcd压缩/限流。
  • API Server过载
    • 分片集群（多API Server）；优化List请求（使用分页）。
  • 网络拥塞
    • 使用高性能CNI（如Calico）；优化Service的IPVS模式。

14. 多集群管理

  • 需求背景
    • 容灾、跨地域部署、环境隔离（生产/测试）。
  • 工具
    • Karmada：跨集群调度，策略管理。
    • Kubefed：联邦集群，同步资源。
  • 管理要点
    • 统一认证（RBAC）；跨集群网络互通（VPN/专线）。

15. Service Mesh应用

  • 核心功能
    • 流量管理（金丝雀发布）、安全（mTLS）、可观测性（链路追踪）。
  • 实现方式
    • Istio：通过Sidecar（Envoy）拦截流量，控制面配置策略。
  • 对比传统方案
    • 解耦应用代码与微服务治理逻辑，提供细粒度控制。

以上内容覆盖了Kubernetes运维的核心知识点，建议结合实际经验举例说明以增强回答深度。