DevOps & 工程化 - 面试题库

一、基础题 ⭐

Q1. CI/CD 中持续集成和持续部署的区别是什么？

答案：持续集成（CI）是指开发人员频繁将代码合并到主干，每次合并后自动触发构建和测试，目的是尽早发现集成错误。持续部署（CD）是在 CI 通过所有测试后，自动将代码发布到生产环境，无需人工干预。两者的核心区别在于：CI 关注代码合并后的自动化验证，CD 关注通过验证后的自动化发布。持续交付与持续部署的区别在于，持续交付需要人工确认后才发布，而持续部署完全自动化。 关联知识点：CI/CD 流程、自动化测试、发布策略

Q2. Docker 镜像和容器的关系是什么？

答案：Docker 镜像是一个只读模板，包含了运行应用所需的代码、运行时、库和配置，类似于面向对象编程中的”类”。容器是镜像的运行实例，具有可写层和独立的运行环境，类似于”对象实例”。一个镜像可以启动多个容器，每个容器之间相互隔离。镜像通过分层存储，共享相同的基础层可以节省磁盘空间。容器的生命周期是临时的，删除容器不会改变镜像，对容器的修改需要重新构建镜像才能持久化。 关联知识点：Docker 架构、镜像分层、容器生命周期

Q3. Kubernetes 中 Pod 和 Node 的区别是什么？

答案：Node 是 Kubernetes 集群中的工作节点，可以是物理机或虚拟机，每个 Node 上运行着 Kubelet 和容器运行时，负责实际的容器运行。Pod 是 Kubernetes 最小的调度单元，一个 Pod 包含一个或多个紧密耦合的容器，这些容器共享网络命名空间和存储卷，始终调度到同一个 Node 上运行。Node 是基础设施层面的概念，Pod 是应用层面的抽象。Kubernetes 通过调度器将 Pod 分配到合适的 Node 上，实现资源的统一管理。 关联知识点：K8s 架构、Pod 调度、节点管理

Q4. Prometheus 和 Grafana 分别是什么？它们如何配合使用？

答案：Prometheus 是一个开源的时序数据库和监控系统，负责采集、存储和查询指标数据。它通过 Pull 模型从目标服务拉取指标，支持强大的 PromQL 查询语言。Grafana 是一个可视化工具，用于创建仪表盘和告警面板，本身不存储数据，而是从 Prometheus 等数据源读取数据进行展示。两者的配合方式是：Prometheus 负责数据采集和存储，Grafana 连接 Prometheus 作为数据源，通过 PromQL 查询数据并渲染成图表。这种组合构成了云原生领域最流行的监控方案。 关联知识点：监控架构、时序数据库、数据可视化

Q5. Git 中 rebase 和 merge 的区别是什么？

答案：merge 会将两个分支的修改合并在一起，并创建一个合并提交，保留完整的历史记录，包括分支的创建和合并时间点。rebase 会将当前分支的提交”重新播放”到目标分支的最新位置，形成线性的提交历史，使历史记录更清晰但会修改提交哈希。merge 的优势是保留完整历史，适合公共分支；rebase 的优势是历史整洁，适合本地分支整理。在实际协作中，建议对公共分支使用 merge，对本地特性分支使用 rebase 保持整洁后再合并。 关联知识点：Git 工作流、分支管理、提交历史

二、进阶题 ⭐⭐

Q6. Jenkins Pipeline 中声明式和脚本式管道有什么区别？

答案：声明式管道使用结构化的语法，以 pipeline 块为核心，包含 agent、stages、steps 等固定结构，语法更简洁易读，适合大多数场景，且内置了错误处理和语法校验。脚本式管道基于 Groovy 语言，提供更灵活的编程能力，可以使用条件判断、循环等复杂逻辑，但语法更复杂且容易出错。声明式管道是 Jenkins 推荐的方式，因为它更安全、更易维护；脚本式管道适合需要复杂逻辑的高级场景。两者可以混合使用，在声明式管道的 script 块中嵌入脚本式代码。 关联知识点：Jenkins、CI/CD 流水线、Groovy

Q7. Dockerfile 中 COPY 和 ADD 指令的区别是什么？

答案：COPY 和 ADD 都可以将文件从构建上下文复制到镜像中，但 ADD 具有额外的功能：支持 URL 作为源（自动下载）、支持自动解压 tar 压缩包。COPY 功能更单一，仅支持本地文件复制。官方推荐使用 COPY，因为它的行为更可预测，避免了 ADD 的隐式解压和下载带来的意外行为。只有在明确需要自动解压 tar 包时才使用 ADD。使用 COPY 时，如果源是 tar 文件，它会被原样复制而不是解压。保持指令的单一性有助于提高 Dockerfile 的可读性和可维护性。 关联知识点：Dockerfile 最佳实践、镜像构建、层缓存

Q8. Kubernetes 中 Deployment 和 StatefulSet 的区别是什么？

答案：Deployment 适用于无状态应用，所有 Pod 实例是等价的，可以随意替换和重新调度，不保证 Pod 的启动顺序和网络标识。StatefulSet 适用于有状态应用，保证每个 Pod 有唯一的标识（如 pod-name-0、pod-name-1），按序启动和停止，并且每个 Pod 关联独立的持久存储。Deployment 的 Pod 名称是随机生成的，而 StatefulSet 的 Pod 名称是固定的。数据库、消息队列等有状态服务适合使用 StatefulSet，而 Web 服务、API 网关等无状态服务适合使用 Deployment。 关联知识点：K8s 工作负载、有状态应用、无状态应用

Q9. 如何设计一个高可用的 Kubernetes 集群？

答案：高可用 K8s 集群需要从多个层面设计：控制平面层面，部署多个 etcd 节点（奇数个，通常 3 或 5），多个 API Server 通过负载均衡器对外提供服务，Controller Manager 和 Scheduler 通过选举机制保证只有一个活跃实例。工作节点层面，至少部署 3 个 Worker Node，避免单点故障。网络层面，使用负载均衡器分发流量到多个 API Server。存储层面，使用分布式存储或云存储保证数据持久性。此外，还需配置多可用区部署，避免单个可用区故障导致整个集群不可用。 关联知识点：K8s 高可用、etcd 集群、负载均衡、多可用区

Q10. ELK 日志栈中各组件的作用是什么？

答案：ELK 由三个组件组成：Elasticsearch 是分布式搜索引擎，负责存储和检索日志数据，提供全文搜索和聚合分析能力。Logstash 是数据处理管道，负责从各种数据源采集日志，进行过滤、转换和格式化后输出到 Elasticsearch。Kibana 是可视化平台，连接 Elasticsearch 提供日志查询、仪表盘和告警功能。实际应用中，常使用 Filebeat 作为轻量级日志采集器部署在应用服务器上，将日志发送到 Logstash 或直接发送到 Elasticsearch，形成 Beats + ELK 的完整日志解决方案。 关联知识点：日志管理、搜索引擎、数据采集

Q11. Docker 网络模式有哪些？各自适用什么场景？

答案：Docker 提供多种网络模式：bridge（桥接）是默认模式，容器通过虚拟网桥连接，适合单机容器间通信。host 模式容器直接使用宿主机网络，性能最好但端口可能冲突，适合对网络性能要求高的场景。none 模式容器没有网络，需要手动配置，适合隔离场景。container 模式共享另一个容器的网络命名空间，适合 sidecar 代理模式。overlay 网络用于跨主机的容器通信，是 Swarm 和 K8s 的基础。macvlan 模式为容器分配独立的 MAC 地址，适合需要直接连接物理网络的场景。 关联知识点：Docker 网络、容器通信、网络隔离

Q12. Kubernetes 中 Service 的类型有哪些？区别是什么？

答案：Kubernetes Service 有四种类型：ClusterIP 是默认类型，仅在集群内部可访问，用于服务间通信。NodePort 在每个节点上开放一个端口，外部可通过 NodeIP:NodePort 访问，适合简单的对外暴露。LoadBalancer 通过云提供商创建外部负载均衡器，将流量转发到 Service，适合生产环境的对外服务。ExternalName 通过 CNAME 记录将 Service 映射到外部域名，用于访问集群外服务。Ingress 不是 Service 类型，而是七层路由规则，配合 Ingress Controller 实现基于域名和路径的路由。 关联知识点：K8s 网络、服务发现、负载均衡

三、高级题 ⭐⭐⭐

Q13. 如何实现 CI/CD 流水线的安全管控？

答案：CI/CD 安全管控需要从多个维度实施：凭证管理方面，使用 Vault 或 K8s Secrets 存储敏感信息，避免硬编码，Jenkins 中使用 Credential 插件管理密钥。代码安全方面，集成 SAST 工具（如 SonarQube）进行静态代码扫描，集成依赖扫描工具（如 Snyk）检测第三方库漏洞。构建安全方面，使用可信基础镜像，定期更新构建环境，限制构建容器的权限。发布管控方面，设置审批流程，实施蓝绿部署或金丝雀发布降低风险。审计方面，记录所有流水线操作日志，定期审查权限分配和访问记录。 关联知识点：DevSecOps、凭证管理、安全扫描、发布策略

Q14. Docker 镜像构建如何优化大小和构建速度？

答案：优化镜像大小：使用精简基础镜像（如 alpine、distroless），采用多阶段构建将编译和运行环境分离，只保留运行时所需文件，合并 RUN 指令减少层数，清理构建缓存和临时文件，使用 .dockerignore 排除不必要的文件。优化构建速度：合理利用层缓存，将不常变化的指令放在前面，使用 BuildKit 并行构建，配置镜像加速器拉取基础镜像，使用共享缓存（如 Buildx cache）。此外，定期清理无用镜像和构建缓存，避免磁盘空间浪费。多阶段构建是目前最有效的优化手段，可将镜像大小减少 90% 以上。 关联知识点：多阶段构建、镜像优化、BuildKit、层缓存

Q15. Kubernetes 中 HPA 自动扩缩容的原理是什么？

答案：HPA（Horizontal Pod Autoscaler）通过监控指标自动调整 Pod 副本数量。其工作流程是：HPA 控制器定期（默认 15 秒）从 Metrics Server 或自定义指标 API 获取目标 Pod 的资源使用情况，与设定的目标值进行比较，根据公式 期望副本数 = 当前副本数 * (当前指标值 / 目标指标值) 计算新的副本数。支持基于 CPU、内存等内置指标，也支持基于 QPS、队列长度等自定义指标。扩缩容有冷却期限制，避免频繁波动（默认扩容冷却 3 分钟，缩容冷却 5 分钟）。配置时需要指定最小和最大副本数，确保在合理范围内弹性伸缩。 关联知识点：K8s 自动扩缩容、Metrics Server、弹性伸缩

Q16. 如何设计一个跨集群的 Kubernetes 灾备方案？

答案：跨集群灾备方案需要解决数据同步和流量切换两个核心问题。数据层面：使用 etcd 备份工具（如 Velero）定期备份集群状态到对象存储，数据库使用主从复制或分布式方案保证数据一致性，持久卷通过存储层的异步复制保持同步。应用层面：使用多集群管理工具（如 Karmada、Cluster API）统一管理多个集群，配置全局负载均衡器（如 DNS 智能解析、Anycast）将流量分发到健康集群。故障切换层面：配置健康检查和自动故障转移，当主集群不可用时自动将流量切换到备集群。恢复层面，定期演练灾备流程，确保 RTO 和 RPO 满足业务要求。 关联知识点：多集群管理、灾备、Velero、全局负载均衡

Q17. 分布式链路追踪的原理是什么？如何实现？

答案：分布式链路追踪用于跟踪请求在微服务间的完整调用路径。核心概念包括：Trace 表示一次完整请求，由多个 Span 组成；Span 表示单个服务内的操作，包含开始时间、结束时间、操作名称和标签；Span 之间存在父子关系，形成调用树。实现原理是：请求入口生成唯一的 Trace ID，在每个服务间传递，服务创建 Span 并记录上下文信息，异步上报到收集器（如 Jaeger、Zipkin）。常用方案是使用 OpenTelemetry SDK 集成到应用中，自动拦截 HTTP/gRPC 调用注入追踪头，采集指标后通过 OTLP 协议发送到后端存储和可视化。 关联知识点：可观测性、OpenTelemetry、Jaeger、微服务追踪

Q18. Kubernetes 中如何实现细粒度的权限控制（RBAC）？

答案：Kubernetes RBAC 通过四个核心资源实现权限控制：Role/ClusterRole 定义权限规则，指定允许的操作（如 get、list、create）和资源类型（如 pods、deployments），Role 作用于特定命名空间，ClusterRole 作用于整个集群。RoleBinding/ClusterRoleBinding 将角色绑定到主体（用户、组或服务账号），限定作用范围。最佳实践包括：遵循最小权限原则，避免使用 cluster-admin；为每个应用创建独立的服务账号并绑定最小权限角色；定期审计权限配置，清理未使用的绑定；使用工具（如 kubectl-who-can）验证权限分配。 关联知识点：K8s 安全、RBAC、服务账号、最小权限原则

Q19. 如何设计一个支持灰度发布的 CI/CD 流程？

答案：灰度发布（金丝雀发布）的 CI/CD 流程设计：构建阶段，CI 流水线构建新版本镜像并推送到镜像仓库，运行自动化测试确保质量。部署阶段，使用 K8s Deployment 创建新版本 Pod，通过 Service 的 label 选择器控制流量比例。流量控制阶段，使用 Ingress Controller（如 Nginx）或 Service Mesh（如 Istio）按权重分配流量，初始阶段将 5%-10% 流量导入新版本。验证阶段，通过监控指标（错误率、延迟、资源使用）自动或人工评估新版本表现。决策阶段，如果指标正常则逐步增加流量比例直至全量，如果异常则自动回滚到旧版本。整个过程可通过 Argo Rollouts 或 Flagger 等工具自动化实现。 关联知识点：灰度发布、Istio、Argo Rollouts、流量管理

Q20. Prometheus 的 Pull 模型和 Push 模型各有什么优缺点？

答案：Pull 模型是 Prometheus 主动从目标服务拉取指标，优点是：Prometheus 控制采集节奏，可以统一处理超时和重试；目标服务只需暴露 HTTP 端点，无需知道 Prometheus 的存在；更容易监控目标服务的存活状态。缺点是：无法监控短生命周期任务（如批处理作业），因为这些任务可能在下次拉取前就结束了。Push 模型是目标服务主动推送指标到 Pushgateway，优点是：适合短任务场景，任务结束前将指标推送到网关暂存。缺点是：Pushgateway 成为单点，且丢失了 Pull 模型的健康检测能力。最佳实践是：长期运行的服务使用 Pull 模型，短任务使用 Push 模型作为补充。 关联知识点：Prometheus 架构、指标采集、Pushgateway

Q21. Kubernetes 中 ConfigMap 和 Secret 的使用场景和区别是什么？

答案：ConfigMap 用于存储非敏感配置数据，如环境变量、配置文件、命令行参数等，数据以明文形式存储，适合数据库连接地址、功能开关等配置。Secret 用于存储敏感信息，如密码、Token、证书等，数据以 Base64 编码存储（注意：不是加密），适合数据库密码、API 密钥等。两者都可以作为环境变量或挂载为卷使用。区别在于：Secret 的数据会被编码，且可以通过 RBAC 限制访问权限，部分场景下可配置加密存储。最佳实践是：使用外部密钥管理工具（如 Vault）管理敏感信息，通过 CSI 驱动注入到 Pod，避免直接使用 Secret。 关联知识点：K8s 配置管理、Vault、敏感信息管理

Q22. 如何实现 Docker 容器的资源限制和隔离？

答案：Docker 通过 Linux cgroups 实现资源限制：CPU 方面，使用 --cpus 限制可用 CPU 核心数，--cpu-shares 设置 CPU 时间片权重，--cpuset-cpus 绑定特定核心。内存方面，使用 --memory 限制最大内存使用量，--memory-swap 限制交换空间，--oom-kill-disable 控制 OOM 行为。磁盘 IO 方面，使用 --device-read-bps 和 --device-write-bps 限制读写速率。进程数方面，使用 --pids-limit 防止 fork 炸弹。资源隔离通过 namespaces 实现，包括 PID、网络、挂载、UTS、IPC 和用户命名空间。Kubernetes 中通过 resources.requests 和 resources.limits 实现类似的资源管理。 关联知识点：cgroups、namespaces、资源管理、容器隔离

Q23. Kubernetes 中 Ingress 和 Gateway API 的区别是什么？

答案：Ingress 是 K8s 早期的七层路由资源，支持基于主机名和路径的路由规则，需要配合 Ingress Controller（如 Nginx、Traefik）使用。其局限性在于：功能相对简单，不支持 TCP/UDP 路由，高级功能依赖各 Controller 的注解扩展，缺乏统一标准。Gateway API 是 K8s 新一代路由标准，采用分层设计：GatewayClass 定义基础设施提供商，Gateway 定义负载均衡器实例，HTTPRoute/TCPRoute 等定义路由规则。优势在于：原生支持多种协议、更细粒度的路由控制、多租户支持、标准化的扩展机制。Gateway API 是 Ingress 的演进方向，适合复杂的路由需求。 关联知识点：K8s 网关、Ingress Controller、Gateway API、七层路由

Q24. 如何搭建和完善监控告警体系？

答案：完善的监控体系需要覆盖四个黄金信号：延迟（请求处理时间）、流量（系统吞吐量）、错误率（失败请求比例）、饱和度（资源使用程度）。架构层面，使用 Prometheus 采集指标，Grafana 展示仪表盘，Alertmanager 管理告警规则。告警设计遵循分层原则：基础设施层监控 CPU、内存、磁盘、网络；应用层监控 QPS、响应时间、错误率；业务层监控订单量、用户活跃度等核心指标。告警规则设置多级阈值（警告、严重），配置合理的静默和抑制规则避免告警风暴。通知渠道集成企业微信、钉钉、PagerDuty 等，确保及时响应。定期审查告警规则，消除无效告警。 关联知识点：监控体系、告警策略、Alertmanager、黄金信号

Q25. Kubernetes 中如何排查 Pod 一直处于 Pending 状态的问题？

答案：Pod Pending 表示调度失败，排查步骤如下：首先使用 kubectl describe pod <pod-name> 查看事件信息，常见原因包括：资源不足，节点可用资源不满足 Pod 的 requests 要求，需要扩容节点或降低资源请求；节点选择器或亲和性不匹配，检查 nodeSelector、nodeAffinity 配置是否有对应标签的节点；污点和容忍度冲突，节点设置了污点但 Pod 没有对应容忍度，使用 kubectl describe node 查看污点配置；存储卷绑定失败，PVC 未绑定或 StorageClass 不存在；镜像拉取失败，镜像名称错误或凭证配置不正确。对于资源不足问题，可以使用 kubectl top nodes 查看节点资源使用情况，针对性调整调度策略。 关联知识点：K8s 调度、故障排查、资源管理、污点与容忍度