运维面试 高频10题 · 第五组

• K8s 的唯一数据存储，所有集群状态都在 etcd 里：Node 信息、Pod 定义、ConfigMap、Secret、Service、RBAC 规则等
• API Server 是唯一直接读写 etcd 的组件，其他组件通过 API Server 间接访问
• etcd 挂了 = 集群无法创建/修改任何资源（已运行的 Pod 不受影响）

• etcd 使用 Raft 算法保证强一致性
• 集群必须有 奇数个节点（3 或 5），超过半数节点存活才能提供服务
• 写入流程：Client → Leader → Leader 复制日志到多数 Follower → 多数确认 → 提交 → 返回成功
• 3 节点容忍 1 个挂；5 节点容忍 2 个挂

# 查看 etcd 集群健康状态
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

# 查看集群成员
etcdctl member list

# 备份快照（生产必做）
etcdctl snapshot save /backup/etcd-$(date +%F).db

# 查看快照状态
etcdctl snapshot status /backup/etcd-2025-01-01.db

# 第一步：确认是 OOMKilled
kubectl describe pod <pod-name>
# 看 Last State → Reason: OOMKilled
# 看 Exit Code: 137（128 + 9，被 SIGKILL）

# 第二步：看历史日志（容器重启前）
kubectl logs <pod-name> --previous

# 第三步：看内存使用趋势（Grafana / kubectl top）
kubectl top pod <pod-name> --containers

# 第四步：宿主机层面确认
dmesg | grep -i "oom\|killed"
journalctl -k | grep -i oom

• requests：调度保证值，scheduler 用它决定把 Pod 调到哪个节点（节点可用资源 ≥ requests 才调过去）
• limits：硬上限，容器内存超过 limit → 立即 OOMKill；CPU 超过 limit → 被限速（不会 Kill）

resources:
  requests:
    memory: "256Mi"   # 正常运行所需，通过监控 P90 用量确定
    cpu: "250m"       # 0.25 核，1000m = 1核
  limits:
    memory: "512Mi"   # requests 的 1.5~2 倍，留弹性空间
    cpu: "500m"       # CPU limit 可以设高，反正只限速不 Kill

• Guaranteed：requests == limits，OOM 时最后被杀，生产核心服务用这个
• Burstable：requests < limits，正常，大多数服务
• BestEffort：没设 requests/limits，OOM 时第一个被杀，禁止生产使用

#!/bin/bash
# 全量热备，不锁表，生产推荐
DATE=$(date +%F)
BACKUP_DIR="/backup/mysql/$DATE"

xtrabackup --backup \
  --user=backup_user \
  --password=<pwd> \
  --target-dir=$BACKUP_DIR

# prepare 阶段（使备份可用）
xtrabackup --prepare --target-dir=$BACKUP_DIR

# 上传到对象存储
ossutil cp -r $BACKUP_DIR oss://your-bucket/mysql/

# 场景：误删数据，需要恢复到 10:30 之前
# 1. 恢复最近的全量备份
xtrabackup --copy-back --target-dir=/backup/mysql/2025-01-01
chown -R mysql:mysql /var/lib/mysql

# 2. 用 binlog 回放到指定时间点（不包含误操作）
mysqlbinlog \
  --start-datetime="2025-01-01 00:00:00" \
  --stop-datetime="2025-01-01 10:29:59" \
  /var/lib/mysql/mysql-bin.* | mysql -u root -p

# 关键：binlog 必须提前开启
# my.cnf: log_bin = /var/lib/mysql/mysql-bin

• livenessProbe（存活探针）：失败 → 杀死容器并重启。用于检测进程死锁、僵死等无法自恢复的状态
• readinessProbe（就绪探针）：失败 → 从 Service Endpoints 摘除（不接收流量），但不重启。用于服务预热、依赖未就绪等
• startupProbe（启动探针）：慢启动应用专用，启动期间 liveness/readiness 暂停检查，防止启动中被误杀

livenessProbe:
  httpGet:
    path: /healthz     # 接口返回 2xx 即存活
    port: 8080
  initialDelaySeconds: 30   # 容器启动后等30秒再开始探测
  periodSeconds: 10         # 每10秒探测一次
  failureThreshold: 3       # 连续失败3次才重启

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 2       # 失败2次就摘流量

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30      # 允许最多 30*10=300秒 启动时间
  periodSeconds: 10

• initialDelaySeconds 太短：应用还没起来就被 liveness 判定失败 → 无限重启循环（CrashLoopBackOff）
• liveness 探测接口依赖 DB：DB 抖动 → 大量 Pod 被重启 → 雪崩。liveness 只查进程自身状态，readiness 才查依赖
• 没有 readiness：Pod 刚启动还没 warm up，流量就打进来 → 大量 502

• 数据按 Hash Slot（哈希槽） 分片，共 16384 个槽，均分给各主节点
• 写入 key 时：CRC16(key) % 16384 计算归属槽，路由到对应节点
• 客户端请求错误节点时，收到 MOVED 重定向，客户端再去正确节点请求

# 查看集群状态
redis-cli -c -h 127.0.0.1 -p 7001 cluster info
redis-cli -c cluster nodes   # 查看各节点槽分布

# 模拟客户端（-c 开启自动重定向）
redis-cli -c -h 127.0.0.1 -p 7001
> set foo bar     # 自动 MOVED 到正确节点

# 在线迁移槽（扩容时用）
redis-cli --cluster reshard 127.0.0.1:7001

多个项目 Jenkinsfile 有大量重复代码（构建镜像、推 Harbor、kubectl 部署逻辑相同），修改一处要改所有项目。共享库把公共逻辑提取为函数库，各项目直接调用。

# Git 仓库结构（jenkins-shared-library）
├── vars/
│   ├── buildImage.groovy     # 全局函数：构建推送镜像
│   ├── deployK8s.groovy      # 全局函数：部署到 K8s
│   └── notify.groovy         # 全局函数：钉钉通知
└── src/                      # 类库（复杂逻辑）

// vars/buildImage.groovy
def call(String imageName, String tag) {
    sh """
        docker build -t harbor.xx.com/${imageName}:${tag} .
        docker push harbor.xx.com/${imageName}:${tag}
        docker rmi harbor.xx.com/${imageName}:${tag}
    """
}

// vars/deployK8s.groovy
def call(String namespace, String deployment, String image) {
    sh "kubectl set image deployment/${deployment} \
        app=${image} -n ${namespace} --record"
    sh "kubectl rollout status deployment/${deployment} -n ${namespace}"
}

// 引用共享库（在 Jenkins 全局配置里注册 Git 地址）
@Library('jenkins-shared-library') _

pipeline {
    agent any
    stages {
        stage('构建镜像') {
            steps { buildImage('myapp', env.BUILD_NUMBER) }
        }
        stage('部署') {
            steps {
                deployK8s('production', 'myapp',
                  "harbor.xx.com/myapp:${env.BUILD_NUMBER}")
            }
        }
    }
    post { failure { notify('构建失败') } }
}

# Zabbix Agent 配置（被监控端）
# /etc/zabbix/zabbix_agentd.conf
Server=192.168.1.100         # Zabbix Server IP
ServerActive=192.168.1.100   # 主动模式
Hostname=web-server-01       # 在 Zabbix UI 里对应的主机名

# 自定义监控项（UserParameter）
UserParameter=nginx.conn,ss -ant | grep ESTABLISHED | wc -l

• PV（Physical Volume）：物理磁盘或分区，最底层
• VG（Volume Group）：多个 PV 组成资源池
• LV（Logical Volume）：从 VG 中分配，格式化后挂载使用

# 场景：/data 目录满了，新增一块磁盘 /dev/sdb 扩容

# 第1步：初始化新磁盘为 PV
pvcreate /dev/sdb
pvdisplay                     # 查看 PV 列表

# 第2步：将 PV 加入 VG（假设 VG 名为 datavg）
vgextend datavg /dev/sdb
vgdisplay datavg              # 确认 VG 空间增加

# 第3步：扩展 LV（+100G 或扩到最大）
lvextend -L +100G /dev/datavg/datalv
# 或扩到 VG 全部剩余空间
lvextend -l +100%FREE /dev/datavg/datalv

# 第4步：在线扩容文件系统（不卸载）
# ext4 文件系统
resize2fs /dev/datavg/datalv
# xfs 文件系统（CentOS 7+ 默认）
xfs_growfs /data

# 验证
df -h /data

主动在系统中注入故障（网络延迟、Pod 宕机、磁盘满、CPU 满），验证系统的容错能力和告警响应是否符合预期，在可控条件下暴露隐患，而不是等线上真实故障时才发现。

# 1. 随机删除 Pod（验证 Deployment 自愈能力）
kubectl delete pod -l app=myapp -n production --grace-period=0

# 2. 模拟节点 NotReady（验证 Pod 漂移）
# 在某个 worker 上停止 kubelet
systemctl stop kubelet
# 观察：Pod 是否在 5分钟后漂移到其他节点

# 3. 模拟 OOMKill（验证 limits 和告警）
kubectl exec -it <pod> -- stress --vm 1 --vm-bytes 600M

# 4. 网络注入（用 tc 模拟延迟）
tc qdisc add dev eth0 root netem delay 200ms 50ms
# 恢复
tc qdisc del dev eth0 root

# 5. 使用 Chaos Mesh（K8s 原生混沌工具）
kubectl apply -f - <<EOF
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-test
spec:
  action: pod-kill
  selector:
    namespaces: [staging]        # 只在预发环境测！
    labelSelectors:
      app: myapp
  scheduler:
    cron: "@every 5m"
EOF

• 变更计划：明确变更内容、影响范围、执行步骤、预计时长
• 回滚方案：每个变更必须有明确的回滚步骤，且能在 5 分钟内完成
• 验证标准：变更后如何判断成功（接口返回 200、监控无告警、日志无报错）

# === 代码/配置 ===
□ 代码已 Code Review，通过 SonarQube 静态扫描
□ 镜像已构建并在测试环境验证通过
□ ConfigMap / 环境变量变更已确认
□ 数据库变更脚本已准备（DDL 变更需提前评估锁表风险）

# === 资源 ===
□ 节点资源充足（kubectl top nodes，预留 20% 余量）
□ PVC 空间充足（df -h，磁盘使用率 < 80%）
□ 镜像已推送到 Harbor 并扫描无高危漏洞

# === 流量 ===
□ 选低峰时段（凌晨或周末）
□ 分批灰度上线（先 1 个 Pod，观察5分钟再全量）
□ Nginx / Ingress 限流规则已确认

# === 应急 ===
□ 回滚命令已准备（kubectl rollout undo）
□ 告警通道畅通（钉钉/企微 webhook 已测试）
□ 相关人员已通知并在线待命

• 故障发生后 24 小时内完成 RCA（根因分析）
• 记录：时间线、根因、影响范围、临时措施、永久修复方案
• 不追责个人，关注系统性问题，建立长效机制