运维面试题

面试官，您好，我是某某，一名拥有9年经验的高级运维工程师。
我擅长Linux服务器应用搭建、中间件和数据库的部署与管理，以及公司内网系统的构建（如Jira、Confluence、域名管理系统等）。在自动化流水线部署、监控系统搭建、日志平台管理、Shell和Python脚本编写、以及系统、网络、安全和存储方面都有丰富的经验。

在我的职业历程中，我曾在aa科技有限公司负责银行智能问答和智能外呼产品的服务器管理与维护。在一个国产化双中心改造项目中，我负责基础环境搭建与应用部署，成功缩短了系统部署时间20%，并通过自动化脚本显著减少了故障排查时间。此外，我还在bb科技有限公司负责量化回测平台和SaaS平台的运维工作，优化了流水线部署流程，提升了系统稳定性，降低了30%的运维成本。

我个人对AI技术有浓厚兴趣，经常关注国内外AI大模型的发展，并且拥有Kubernetes CKA认证。我也喜欢通过技术博客分享经验，持续提升自己的技术水平。

我希望在未来的工作中，能够继续深耕运维领域，结合AI和云原生技术，推动公司技术架构的持续优化和创新。

k8s问题排查经验：https://blog.yufenglab.cn/categories/kubernetes/2024/12/05/k8s%E6%95%85%E9%9A%9C%E6%8E%92%E6%9F%A5-%E7%BD%91%E7%BB%9C%E8%BD%AC%E5%8F%91 (opens new window)

影响深刻的技术问题

1.线上mysql proxy层vip出现故障

监控出现交易量下降，业务验证问答出现超时

排查问答接口日志，出现数据库插入数据报错，联系系统组排查数据库

数据库出现锁表，数据有往主和从都有写入，排查mysql proxy节点有异常进程，杀掉恢复，结果是mysql proxy有版本bug，后续联系厂商支持解决。

2.版本程序崩溃

看日志，使用工具拿内存崩溃日志

3.录音不全

抓包拿数据到wireshark分析

4.版本问题解决

浏览器F12，根据接口服务排查对应日志

5.一般问题排查步骤

网络、系统资源、中间件、应用日志、数据库

6.k8s调度问题排查

业务反馈：在高峰期某个接口功能出现访问缓慢

同一个节点不同程序在高峰期出现资源抢夺。解决方法，将程序部署到其它节点

排查步骤：

# 1、Kubernetes应用性能问题解决步骤

# 1. 问题初步排查与资源配置优化

操作步骤：

调整资源分配
- 关键点
  requests应接近日常平均负载，limits设置需留有弹性空间避免频繁资源争抢。

修改Deployment/Pod的YAML文件，合理设置requests和limits，示例如下：

resources:
  requests:
    cpu: "500m"   # 基准需求
    memory: "512Mi"
  limits:
    cpu: "2000m"  # 峰值上限
    memory: "2048Mi"

1
2
3
4
5
6
7

检查现有资源配置

kubectl describe pod <pod-name> -n <namespace> | grep -i "requests\|limits"
kubectl get deployments -n <namespace> -o yaml | grep resources -A5

1
2

确认应用的 requests/limits 是否与真实负载匹配，是否存在明显低估（如CPU限流或OOM崩溃）。

# 2. 节点负载均衡与调度器调优

操作步骤：

调整Kubernetes调度策略
- 修改调度器权重：优化负载感知
  修改调度器配置文件（如自定义调度器Profile），增加NodeResourcesBalancedAllocation插件权重。

部署资源重平衡工具（如Descheduler）
定期清理不均衡的Pod，触发重新调度：

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  RemovePodsViolatingNodeAffinity:
    enabled: true

1
2
3
4
5

污点与容忍：为过载节点打污点，迁移非核心Pod

kubectl taint nodes <node-name> overload=true:NoSchedule

设置节点反亲和性：避免同类Pod扎堆

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values: [my-app]
        topologyKey: "kubernetes.io/hostname"

1
2
3
4
5
6
7
8
9

诊断节点资源分布

kubectl top nodes          # 查看节点实时负载
kubectl describe nodes | grep -A10 "Allocated resources" # 看资源分配占比

1
2

# 3. 解决应用间资源竞争

操作步骤：

隔离高资源消耗应用

优先级调度（PriorityClass）
为关键应用配置高优先级，抢占资源时占优：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000

1
2
3
4
5

资源配额（ResourceQuota）：限制资源的过度占用

apiVersion: v1
kind: ResourceQuota
metadata:
  name: per-ns-quota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi

1
2
3
4
5
6
7
8

基于节点分组：将关键应用调度到专用节点池

nodeSelector:
  dedicated: high-priority

1
2

# 4. 应用性能深度调优

操作步骤：

性能剖析与基准测试
- CPU/内存火焰图：使用pprof或perf抓取热点函数。
- 数据库优化：检查慢查询日志，添加索引或分库分表。
- 网络分析：通过kubectl trace或tcpdump检查跨Pod通信延迟。
调整应用参数
- Java应用优化JVM参数（堆大小、GC策略）。
- 微服务场景下启用连接池（如HikariCP）、熔断器（如Sentinel）。

服务网格（Service Mesh）调优
启用Istio链路级超时和重试控制：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
    - route:
        - destination:
            host: my-svc
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s

1
2
3
4
5
6
7
8
9
10
11

# 5. 验证与长期防护

操作步骤：

扩缩容策略加固
- 启用Cluster Autoscaler自动伸缩节点池。
监控与告警增强
在Prometheus中配置关键阈值（如Pod重启次数、节点CPU>90%持续5分钟），联动Slack/邮件告警。

根据监控指标（CPU/内存/QPS）配置HPA：

kubectl autoscale deployment my-app --cpu-percent=70 --min=3 --max=10

压力测试验证

# 使用Vegeta或Locust发起负载测试
echo "GET http://my-app" | vegeta attack -duration=300s | vegeta report

1
2

# 最终效果

通过上述步骤，最终实现：

节点间负载差异从±40%降低到±15%
应用P99延迟从2s降至200ms
尖峰时段自动扩容耗时从10分钟缩短至2分钟

附件示例
可附上kube-scheduler自定义配置片段、HPA策略YAML模板等辅助工具文件（如有需要可补充）。

# 2、Kubernetes（K8s）创建一个Pod的详细流程

用户通过REST API创建一个Pod。
API Server接收到请求后，将其写入etcd。etcd是Kubernetes的分布式键值存储系统，用于存储所有集群状态的信息。
调度器检测到未绑定Node的Pod，开始调度并更新Pod的Node绑定。调度器根据一系列复杂的算法来选择合适的节点，如资源可用性、标签匹配、预选和亲和性约束等。
Kubelet通过与Node节点上的container runtime（如Docker或containerd）交互，检测到有新的Pod调度过来，并运行该Pod。Kubelet会根据Pod的配置文件创建容器，并将容器运行在指定的Node节点上。
Kubelet通过container runtime获取Pod的状态，并将其更新到API Server中。API Server将Pod的状态信息存储在etcd中。
所有组件通过API Server的Watch接口监测资源变化情况，并对资源作相应的操作。例如，Controller Manager通过Watch接口监测资源的状态变化，并根据资源状态的变化执行相应的控制逻辑。Scheduler通过Watch接口监测新创建的Pod，并根据调度算法选择合适的节点进行调度。

总之，Kubernetes通过API Server、etcd、Kubelet、Controller Manager和Scheduler等组件的协同工作，实现了Pod的创建、调度和运行。所有组件通过REST API和Watch接口进行通信，共同维护集群的状态和资源的运行状况。

# 3、网站访问慢排查和解决办法？

1.服务器出口带宽不够用

2.服务器负载过大，导致响应不过来

3.数据库瓶颈

1）查看每个host的当前连接数和总连接数

SELECT * FROM performance_schema.hosts;

2）查看数据库连接数

show processlist;

3）查看MySQL数据库状态

show slave status;

4.网站开发代码没有优化好

# 4、服务器cpu突然激增，怎么解决

# 1、快速监控与定位高CPU进程

工具使用：top、htop
分析进程是用户态还是内核态

1、分析服务器

用户态：通过工具分析、应用日志

内核态：查看系统日志

2、网络分析

2.1：定时任务检查

2.2：外部流量/请求突增

# 临时缓解与长期优化

应急措施：
- 使用 cpulimit 限制进程CPU：cpulimit -p <PID> -l 50（限制为50%）。
  - 调整容器资源（如Docker --cpus 参数）。
  - 重启服务或扩容实例（视业务场景）。
根本解决：
- 修复代码（如优化循环、避免阻塞操作）。
  - 调整配置（如线程池大小、JVM参数）。
  - 加强监控（如设置CPU阈值告警）。

# 回答示例

"当服务器CPU突增时，我会分步骤处理：

定位高负载进程：用 top 快速找到占用CPU最高的进程，观察是用户进程还是系统进程。
线程级分析：结合 jstack 或 perf 分析相关线程，确认是否存在死循环或锁竞争。
检查日志和安全：查看应用错误日志和安全日志，排除代码Bug或恶意攻击。
关联流量/任务：确认是否有突发流量或定时任务导致。例如之前遇到一个案例，是定时脚本未限制并发，导致CPU打满。
应急与修复：短期用 cpulimit 限流，长期优化代码逻辑，并完善监控告警。"

# 5、请简述kubernetes组件有哪些，k8s网络是怎么通信的

Kubernetes 组件概述
Kubernetes 的核心组件分为控制平面（Master）和工作节点（Node）两类：

控制平面组件（Master）
- API Server
  集群的唯一入口，提供 REST API，负责与其他组件及用户请求的交互。
- etcd
  分布式键值存储数据库，保存集群的所有状态和配置数据。
- Scheduler
  负责将 Pod 分配到合适的 Node 节点，基于资源需求和调度策略决策。
- Controller Manager
  运行多种控制器（如 Deployment、ReplicaSet、Node 控制器等），确保集群实际状态与期望状态一致。
工作节点组件（Node）
- kubelet
  管理 Node 上的 Pod 生命周期，如创建、删除容器，并监控容器状态。
- kube-proxy
  维护节点网络规则（如 iptables/ipvs），实现 Service 的负载均衡和网络路由。
- 容器运行时
  如 Docker、containerd，负责运行容器。

Kubernetes 网络通信机制
Kubernetes 网络模型的核心原则是：Pod 间可直接通信，无需 NAT，具体实现依赖 CNI（Container Network Interface）插件。通信流程如下：

Pod 内部通信
- 每个 Pod 拥有唯一 IP，内部容器共享网络命名空间（通过 localhost 通信）。
Pod 到 Pod 通信
- 同节点：通过同一节点的虚拟网桥（如 Docker 的 docker0 或 CNI 插件创建的 cni0）直接通信。
- 跨节点：由 CNI 插件实现（如 Calico、Flannel 等），通过 Overlay 网络（如 VXLAN）或路由策略，确保不同节点 Pod 的 IP 可全局路由。
Service 到 Pod 通信
- Service 是虚拟 IP（ClusterIP），通过 kube-proxy 维护的 iptables/ipvs 规则将请求负载均衡到后端 Pod。
- Endpoint 跟踪 Service 对应的 Pod 变化，动态更新代理规则。
外部访问 Service
- NodePort：通过节点的端口暴露 Service，流量转发到 Pod。
- Ingress：通过 HTTP/HTTPS 路由（如 Nginx Ingress Controller）暴露服务，支持域名和路径规则。
DNS 服务
- CoreDNS 为 Service 和 Pod 提供域名解析，例如：<service-name>.<namespace>.svc.cluster.local。

总结
Kubernetes 通过控制平面组件管理集群状态，工作节点运行容器和网络代理。网络通信依赖 CNI 插件实现跨节点 Pod 直连、Service 负载均衡和 DNS 解析，确保整个集群的高效连通性。网络策略（如 NetworkPolicy）可进一步控制流量安全性。

# 6、请简述cicd执行流程有那些

CI/CD执行流程的核心步骤如下：

代码提交与触发
- 开发者将代码推送到版本控制系统（如Git），触发CI流程。通常通过Webhook或定时任务启动。
持续集成（CI）阶段
- 代码静态分析：运行代码规范检查（如ESLint）、安全扫描（如SonarQube）。
- 自动化测试：执行单元测试、集成测试，确保代码质量。
- 构建（Build）：编译代码并生成制品（如JAR包、Docker镜像）。
- 归档制品：将构建产物存储到制品库（如Nexus、Docker Registry）。
持续交付（CD）阶段
- 部署到测试环境：将制品部署到测试环境，进行更复杂的测试（如端到端测试、性能测试）。
- 人工确认（可选）：测试通过后，由人工审批决定是否进入生产环境（持续交付），或全自动部署（持续部署）。
生产环境部署
- 滚动发布/蓝绿部署：采用零宕机策略更新生产环境。
- 监控与反馈：结合监控工具（如Prometheus）实时观察系统状态，发现问题自动触发告警或回滚。
回滚机制
- 若生产环境出现故障，快速回滚到上一个稳定版本（如通过Kubernetes的Rollback功能）。

上次更新: 2026/01/22, 13:46:13

← 云平台的性能问题企业级openvpn搭建→