2025-3-14 vivo面试

你们的k8s集群的高可用架构怎么设计的？ #

5个master节点剩下是node节点，联邦，2个控制面集群和38运行面集群组成k8s联邦，控制面k8s集群只跑paas平台的应用，运行面集群跑业务应用，AD BC 分区，多AZ夸机房容灾

Kubernetes 集群的高可用架构设计对于确保系统的稳定性、可扩展性和容灾能力非常重要。根据你描述的设计架构，以下是详细的分析和展开：

1. 5个 Master 节点（控制面） #

多节点设计：高可用的 Kubernetes 集群需要至少三个 master 节点来提供冗余，以避免单点故障。你选择了 5 个 master 节点，这样可以进一步增强集群的高可用性，避免任何 2 个节点宕机时集群服务的不可用。
控制面职责：Kubernetes master 节点负责调度、集群状态管理、API 服务器、控制器管理器等核心功能。将 master 节点分布在不同的物理或虚拟机上，并使用负载均衡器进行流量分配，可以有效避免 master 节点单点故障。
负载均衡：使用负载均衡器（如 Nginx、HAProxy 或云服务商的负载均衡）对外暴露 Kubernetes API Server，使得所有的客户端（如 kubectl、应用）能够在多个 master 节点之间负载均衡，避免单一 master 节点的宕机导致不可用。

2. Node 节点（工作节点） #

运行业务应用：Kubernetes 的 node 节点负责运行容器化的业务应用。在该架构下，节点数目通常根据工作负载的需求进行扩展。每个 node 节点运行 kubelet 和 kube-proxy，这些组件管理节点的健康和服务发现。
自动扩容：可以通过 Kubernetes 集群的 HPA（Horizontal Pod Autoscaler）来根据业务需求动态地增加或减少 node 节点的数量，从而应对负载的波动。

3. 联邦架构（Federation） #

控制面集群和运行面集群的分离：在联邦架构中，控制面集群负责管理和控制集群的整体状态，但不运行具体的业务应用。而运行面集群专注于运行业务应用，负载由控制面集群统一调度。控制面集群通常只运行 PaaS 平台相关的应用，而业务应用则运行在运行面集群中。
联邦调度：Kubernetes 联邦可以跨多个集群进行调度，支持多个集群中的服务发现、跨集群负载均衡等功能。使用 Kubernetes 联邦可以实现跨地域、跨数据中心的服务扩展，从而保证高可用性。
跨区域容灾：联邦架构中的多个运行面集群可以部署在不同的可用区域（Availability Zone，AZ）和不同的数据中心。通过合理的设计，可以在一个区域发生故障时，自动将流量切换到另一个区域，从而实现跨区域容灾。

4. AD BC 分区 #

AD 和 BC 是不同的区域分区：这里的 AD 和 BC 很可能指的是不同的应用区域分区或者不同的业务功能模块分区。AD 和 BC 代表了两类不同的业务场景，每个分区可能有独立的业务需求和安全隔离要求。
分区管理：通过为不同的业务模块使用不同的 Kubernetes Namespace，可以在同一集群中实现一定程度的资源隔离、权限管理和网络隔离。

5. 多 AZ 跨机房容灾设计 #

跨机房部署：通过将 Kubernetes 集群部署在多个数据中心或多个可用区（AZ）之间，实现高可用和灾难恢复。例如，使用多个 master 节点跨机房部署，并利用云服务提供的负载均衡和高可用性网络设计，保证 master 节点能够跨机房访问且高可用。
Pod 跨 AZ 部署：在 Kubernetes 集群中，Pod 可以跨多个 AZ 部署，通过配置 topologySpreadConstraints 或使用适当的亲和性和反亲和性策略，确保应用在多个 AZ 中有冗余备份，避免某个 AZ 故障导致整个服务不可用。
Persistent Volume 跨 AZ 存储：使用跨 AZ 的持久化存储（如云提供商的跨区域存储卷）确保在一个 AZ 故障时，应用的持久化数据能够快速恢复。某些云平台如 AWS EBS 支持跨可用区的数据复制。

6. 健康检查和负载均衡 #

健康检查：通过存活检测和就绪检测确保每个组件（如 kube-apiserver、etcd、kubelet 等）都处于正常状态。如果某个组件失败，自动进行自愈或重新调度。
Pod 调度和负载均衡：Kubernetes 调度器会根据集群的负载和容器的资源需求，将 Pod 分配到合适的 Node 节点上，同时利用 Service 和 Ingress 对外暴露应用，确保流量能够在不同的 Pod 和节点之间负载均衡。

7. 灾难恢复与容错 #

Etcd 高可用：Etcd 是 Kubernetes 集群的关键组件，存储了集群的所有配置信息和状态。通过将 Etcd 部署为高可用集群（通常是奇数个节点，如 3 个或 5 个节点），确保在任意节点故障时，集群依然能够正常工作。
多区域冗余：通过跨区域部署 Etcd 节点和 Master 节点，确保在单个区域或数据中心发生故障时，其他区域可以继续提供服务。即使在大规模灾难中，也能最大程度地保持系统的可用性。

8. 备份与恢复 #

定期备份：定期备份 Kubernetes 集群的核心组件（如 etcd、kube-apiserver 的配置等），以应对数据丢失或灾难恢复需求。
恢复方案：测试并制定恢复方案，在发生故障时能够迅速将集群恢复到正常状态。例如，可以使用 Velero 或其他备份工具进行集群备份和恢复。

总结 #

通过这样的高可用架构设计，Kubernetes 集群能够在面对节点故障、区域故障等情况下保持高度的可靠性和可扩展性。联邦架构、跨机房容灾、多 AZ 部署、Etcd 高可用等设计确保了应用在不同的业务需求下能够得到良好的支持，同时具备了强大的容错能力和扩展能力。

etcd或者控制面组件的容灾方案？ #

Kubernetes etcd 和 控制面（Control Plane） 组件的容灾方案至关重要，因为它们决定了整个集群的可用性。以下是 etcd 和 控制面组件 的容灾方案，包括高可用部署、备份恢复、自动故障转移等策略。

1. etcd 容灾方案 #

etcd 是 Kubernetes 的核心数据存储，存储了所有 API 资源对象的状态。如果 etcd 发生故障，整个 Kubernetes 控制面将无法正常工作。

(1) etcd 高可用部署 #

多节点集群（3、5、7 等奇数个节点）
- etcd 需要使用奇数个节点，以保证 Raft 共识算法可以正确选举 leader。
- 通常推荐至少 3 个节点，这样即使宕掉 1 个，集群仍能继续运行。
- 生产环境推荐5 个节点，以提升容灾能力。
跨 AZ 或机房部署
- 采用 多 AZ/多机房部署，分布式放置 etcd 节点，避免单点故障（如单个机房断网、断电）。
- 如果使用云环境（如 AWS、阿里云），可以利用云平台的 可用区（AZ） 分布 etcd 实例。
负载均衡
- etcd 集群之间的通信通常通过内部 DNS 解析，每个 etcd 成员需要使用固定 IP 或 DNS 解析来进行互联。
- 也可以使用 Keepalived + HAProxy 进行高可用性负载均衡，以防止某个 etcd 实例崩溃时影响集群连接。

(2) etcd 备份与恢复 #

定期快照备份
- 通过
```
etcdctl snapshot save
```
  命令定期备份 etcd 数据：
```
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db
```
- 定期将快照文件存储到远程存储（如 阿里云 OSS、AWS S3、Ceph）。
恢复 etcd 集群
- 当 etcd 发生数据损坏或集群崩溃时，可以使用快照恢复：
```
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db
```
- 重新配置 etcd，并启动新的 etcd 实例加入集群。
监控 etcd 状态
- 使用
```
etcdctl endpoint status
```
  查看 etcd 健康状态：
```
ETCDCTL_API=3 etcdctl endpoint status --write-out=table
```
- 结合 Prometheus + Grafana 监控 etcd 关键指标，如 etcd_server_leader_changes_seen_total（leader 变更频率）、etcd_disk_wal_fsync_duration_seconds（写入延迟）。

(3) etcd 自动故障转移 #

自动选主
- etcd 使用 Raft 协议进行 leader 选举，当 leader 节点崩溃后，剩余 etcd 成员会自动选举新的 leader。
- 如果集群中 etcd 成员低于半数（N/2+1），则集群进入 Read-Only 模式，API Server 可能无法正常工作。
- 解决方案：
  - 及早发现 etcd 故障，及时扩容新的 etcd 成员。
  - 通过 etcdctl member list 监控 etcd 成员状态，并在必要时手动重新加入新的 etcd 节点。

2. Kubernetes 控制面组件容灾方案 #

Kubernetes 控制面包括以下核心组件：

kube-apiserver（API 服务器）
kube-scheduler（调度器）
kube-controller-manager（控制器管理器）
kubelet（节点管理）
kube-proxy（网络代理）
etcd（数据存储，前面已详细说明）

(1) 高可用架构 #

多 Master 高可用 #

采用 多 Master 架构（至少 3 个），避免单点故障：

+----------------------+        +----------------------+
|   Master-1 (Active)  |        |   Master-2 (Backup)  |
|   kube-apiserver     |  <---> |   kube-apiserver     |
|   kube-controller    |        |   kube-controller    |
|   kube-scheduler     |        |   kube-scheduler     |
+----------------------+        +----------------------+
         |                                |
         |                                |
      +----------------------------------------+
      |       HAProxy / Keepalived / VIP      |
      +----------------------------------------+
         |
      +----------------+
      |  Worker Nodes  |
      +----------------+

kube-apiserver
- 部署多个 kube-apiserver 实例，并使用 负载均衡器（HAProxy、Nginx、Keepalived） 进行流量分发，避免单点故障。
kube-controller-manager 和 kube-scheduler
- 只能运行在单个 leader 节点上（采用 leader election 机制）。
- 其他 master 节点会等待 leader 失效后自动接管控制权。
负载均衡
- Keepalived + HAProxy
  ：
  - Keepalived 提供 VIP 地址，实现故障时的 API Server 切换。
  - HAProxy 进行负载均衡，分发 API 请求。

(2) 监控与自动恢复 #

Prometheus 监控
- 监控 kube-apiserver 响应时间、etcd 读写延迟等关键指标。
- 发现异常时，触发自动扩容或故障转移。
自动重启
- 结合 systemd 或 Kubernetes 自愈能力（livenessProbe + readinessProbe），确保控制面组件崩溃时自动重启。

(3) 备份与恢复 #

API Server 备份

备份

kube-apiserver

配置文件：

cp -r /etc/kubernetes /backup/kubernetes

备份

kubeconfig

文件：

cp ~/.kube/config /backup/kube-config

恢复 API Server
- 如果
```
kube-apiserver
```
  崩溃：
```
systemctl restart kube-apiserver
```
- 如果 API Server 故障，可以切换至备用 master 节点。

3. 故障恢复策略 #

组件	可能的故障	容灾方案
etcd	单节点故障	Raft 自动选举新 leader
etcd	多节点故障	通过快照恢复数据
kube-apiserver	API 无法访问	负载均衡 + 备用 master 切换
kube-controller-manager	leader 故障	其他 master 自动接管
kube-scheduler	leader 故障	其他 master 自动选举新 leader

4. 结论 #

etcd 高可用：至少 3 个节点，跨 AZ 部署，定期备份，自动 leader 选举。
控制面高可用：多 Master 部署，Keepalived/HAProxy 负载均衡，自动选主。
监控与告警：Prometheus 监控，发现异常时自动扩容或切换。
备份与恢复：定期备份 etcd 数据和控制面配置，快速恢复服务。

这套方案可以保证 Kubernetes 在发生故障时能够快速恢复，提升集群的可靠性和稳定性。

演练，怎么设计演练场景，覆盖核心风险和推动改进的措施？ #

Kubernetes 容灾演练方案设计 #

容灾演练的目的是验证 Kubernetes 集群在关键组件故障、节点丢失、网络异常等情况下的恢复能力，并找到改进点，提升系统的高可用性。容灾演练需覆盖 etcd、控制面、计算节点、存储、网络等核心组件，并推演各种可能的故障场景。

1. 演练目标 #

✅ 验证 Kubernetes 高可用架构是否可靠 ✅ 发现可能的单点故障（SPOF） ✅ 确保 etcd 备份与恢复机制有效 ✅ 测试 负载均衡与故障转移能力 ✅ 提升应急响应效率，优化告警、日志、监控机制

2. 演练核心场景 #

容灾演练分为 核心组件故障、网络异常、存储故障、高并发压力测试等。

🟢 场景 1：etcd 故障 #

🎯 目标：确保 etcd 崩溃后 Kubernetes 仍能正常运作，并验证 etcd 快照恢复机制。

🔹 演练步骤：

删除 etcd Leader 节点
```
docker stop etcd
```
观察 etcdctl endpoint status，确认新 Leader 选举情况。
模拟多节点 etcd 故障
```
systemctl stop etcd
```
观察 Kubernetes API 是否可用：
```
kubectl get nodes
```
恢复 etcd
- 若单节点故障，等待 etcd 自动选主。
- 若集群崩溃，使用 etcd 备份恢复：
```
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db
```

🛠 改进措施：

确保 etcd 备份策略有效（定期快照 + 远程存储）。
监控 etcd_server_leader_changes_seen_total 频率，提前发现异常。

🟡 场景 2：Master 节点故障 #

🎯 目标：确保 Kubernetes 控制面具备高可用性，验证 API Server 故障转移能力。

🔹 演练步骤：

关闭主 Master 节点
```
systemctl stop kube-apiserver
```
观察 kubectl get nodes 和 kubectl get pods -n kube-system，确认其他 Master 是否接管流量。
模拟所有 Master 节点宕机
- 关闭所有 API Server 进程：
```
systemctl stop kube-apiserver kube-controller-manager kube-scheduler
```
- 观察 集群状态、负载均衡，验证 Keepalived 是否切换 VIP。
- 重新启动 Master：
```
systemctl start kube-apiserver kube-controller-manager kube-scheduler
```
确认控制面是否恢复。

🛠 改进措施：

确保 HAProxy / Keepalived VIP 可用，自动切换。
监控 API Server 响应时间，防止超时导致业务异常。

🔴 场景 3：Node 计算节点故障 #

🎯 目标：验证 Pod 迁移能力，确保业务不会因 Worker 节点故障而中断。

🔹 演练步骤：

选取一个 Node，

驱逐该节点所有 Pod

：

kubectl drain <node-name> --ignore-daemonsets --delete-local-data

观察 Pod 迁移
：
```
kubectl get pods -o wide
```
彻底下线该节点
：
```
kubectl delete node <node-name>
```
重新加入该节点
：
- 重新安装 kubelet：
```
kubeadm reset && kubeadm join ...
```
- 确认节点恢复：
```
kubectl get nodes
```

🛠 改进措施：

业务应用应配置 Pod 反亲和性、HPA（自动扩缩容），防止节点故障时业务不可用。
监控 kubelet 状态，确保节点故障能自动触发告警。

🟠 场景 4：Ingress/Service 负载均衡异常 #

🎯 目标：模拟负载均衡异常，验证流量切换是否正常。

🔹 演练步骤：

关闭 Ingress Controller

kubectl delete pod -n ingress-nginx --all

观察外部请求是否受影响：
```
curl http://<ingress-url>
```
删除 Service 负载均衡器
```
kubectl delete service my-lb-service
```
确认 Service 是否重新创建，并绑定新的 IP。

🛠 改进措施：

增加 多副本 Ingress Controller，避免单点故障。
使用 MetalLB / Keepalived 保障 Service 高可用。

🔵 场景 5：存储故障 #

🎯 目标：确保 PVC 挂载失败时，应用能正确恢复。

🔹 演练步骤：

删除存储节点
```
kubectl delete node storage-node-1
```
观察 PVC 状态
```
kubectl get pvc -A
```
重新创建存储节点
：
- 确保新的存储节点能正确绑定 PVC。
- 确认 Pod 能正确访问数据。

🛠 改进措施：

采用 Ceph、NFS、GlusterFS 等分布式存储，避免单点故障。
增加 PVC 绑定策略，确保数据不会丢失。

3. 保障措施 #

✅ 提前通知：制定演练时间，通知相关团队 ✅ 预案准备：提前配置恢复方案，确保快速回滚 ✅ 监控告警：结合 Prometheus + Grafana 监控关键指标 ✅ 日志分析：结合 ELK / Loki 进行故障分析 ✅ 演练总结：记录演练过程，持续改进

4. 结论 #

通过故障注入（如 etcdctl snapshot restore、kubectl drain），模拟核心组件故障，验证集群的恢复能力。
监控 etcd leader 选举、API Server 响应、Pod 迁移、负载均衡 等关键路径，找出潜在风险点。
结合 Prometheus + ELK 监控故障，提升告警和自动恢复能力。

这套方案可以帮助 Kubernetes 集群在极端情况下稳定运行、快速恢复、降低业务影响。 🚀

演练发现的问题和改进的地方？ #

演练发现的问题与改进方案 #

在 Kubernetes 容灾演练过程中，可能会发现一些系统设计、运维管理、组件可靠性方面的潜在风险。下面总结了一些常见问题，并提供对应的改进方案。

1. etcd 相关问题 #

🛑 问题 1：etcd 选主时间过长，影响 API Server 响应 #

现象：
- kubectl get nodes 等命令超时
- etcdctl endpoint status 显示 leader 变化
- kube-apiserver 无法正常访问 etcd
原因：
- etcd 选举时间过长
- 网络抖动导致 etcd 连接断开
- etcd 负载高，写入慢，影响 leader 选举

✅ 改进方案：

调整 etcd 选举超时时间
（默认 1000ms，建议 200ms~500ms）：
```
election-timeout: 250ms
```
优化 etcd 性能：
- 使用 SSD 作为存储盘，避免磁盘 IO 瓶颈
- etcdctl defrag 释放碎片化空间
- 限制 kube-apiserver 访问 etcd 频率（减少高并发请求）
增加 etcd 监控：
- etcd_server_leader_changes_seen_total 频繁变化 → 可能有网络问题
- etcd_disk_wal_fsync_duration_seconds_bucket 高 → 说明磁盘 IO 存在瓶颈

🛑 问题 2：etcd 备份未生效，恢复失败 #

现象：
- 使用 etcdctl snapshot restore 恢复时，发现 data-dir 路径冲突
- etcdctl member list 显示数据不完整
原因：
- etcd 备份不完整，恢复时报错
- 备份未包含 member 目录，导致 etcd 无法正确加载快照

✅ 改进方案：

使用正确方式备份 etcd：

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db

恢复时指定新的 data-dir：

ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db --data-dir=/var/lib/etcd-new

定期检查 etcd 备份完整性：

etcdctl snapshot status /backup/etcd-snapshot.db

2. Master 组件问题 #

🛑 问题 3：kube-apiserver 宕机，负载均衡未生效 #

现象：
- kubectl 命令卡住，API 无法访问
- haproxy 仍然转发流量到故障 Master
原因：
- 负载均衡健康检查失效，导致流量仍然转发到宕机 Master
- kube-apiserver 未配置多个 --etcd-servers
- VIP 切换失败（Keepalived 未正常触发）

✅ 改进方案：

优化负载均衡健康检查：

backend kube-apiservers
  option httpchk GET /livez
  default-server check fall 3 rise 2

配置 API Server 连接多个 etcd 节点：

--etcd-servers=https://etcd-1:2379,https://etcd-2:2379,https://etcd-3:2379

优化 Keepalived VIP 切换：

vrrp_script chk_apiserver {
  script "curl -s http://127.0.0.1:6443/livez || exit 1"
  interval 2
  weight -2
}

3. Node 计算节点问题 #

🛑 问题 4：节点驱逐后 Pod 迁移失败 #

现象：
- kubectl drain 后，Pod 没有调度到其他节点
- kubectl get pods -o wide 发现 Pod 卡在 Terminating 状态
原因：
- Pod 没有定义资源限制，导致新节点资源不足
- Pod 绑定到指定 Node（nodeSelector、affinity 限制）
- DaemonSet 不能自动迁移，影响 Node 级组件（如 fluentd）

✅ 改进方案：

给 Pod 设定 requests 和 limits，确保有足够资源：

resources:
  requests:
    cpu: "100m"
    memory: "200Mi"
  limits:
    cpu: "500m"
    memory: "1Gi"

检查 nodeSelector / affinity 规则，避免过于严格：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: NotIn
          values:
          - failed-node

使用 kubectl delete pod --force 释放卡住的 Pod。

4. Ingress / Service 问题 #

🛑 问题 5：Ingress Nginx 宕机后，业务不可访问 #

现象：
- 业务访问 502 Bad Gateway
- kubectl get pods -n ingress-nginx 发现 Pod 处于 CrashLoopBackOff
原因：
- Ingress Controller 只有 1 个副本，没有高可用
- Pod 绑定了指定 Node，导致该 Node 故障时影响所有流量
- Backend Service 无可用 Pod

✅ 改进方案：

增加 Ingress 副本数：
```
replicas: 3
```
移除固定节点绑定：
```
nodeSelector: {}
```
在 Prometheus 监控 Ingress 组件状态，提前告警：
```
rate(nginx_ingress_controller_requests[5m])
```

5. 存储问题 #

🛑 问题 6：PVC 绑定失败，Pod 进入 `Pending` 状态 #

现象：
- kubectl describe pvc 显示 Waiting for first consumer
- kubectl get pods 发现 MountVolume.SetUp failed
原因：
- Pod 没有调度到存储支持的节点
- 存储类 StorageClass 没有正确绑定 PVC
- 底层 NFS / Ceph 故障，导致存储不可用

✅ 改进方案：

强制 Pod 绑定支持存储的节点：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: storage-node
          operator: In
          values:
          - "true"

提前 Provision 预分配 PVC，避免动态绑定失败：
```
kubectl create pvc --storage-class=fast-storage
```
监控存储后端健康状态：
```
ceph -s
```

总结 #

✅ etcd 选主优化，减少 API Server 无响应时间 ✅ 负载均衡健康检查，避免 Master 宕机影响集群 ✅ Pod 资源优化，确保节点故障时 Pod 迁移顺畅 ✅ Ingress 高可用，避免流量入口单点故障 ✅ 存储策略优化，确保 PVC 绑定稳定

这些改进措施能提高 Kubernetes 集群的可靠性、恢复能力，让系统在发生故障时能快速恢复！ 🚀

集群大规模启动pod失败，怎么定位问题并调优？ #

大规模启动 Pod 失败的排查与优化方案 #

在 Kubernetes 集群中大规模启动 Pod 时，可能会遇到 Pod 处于 Pending 或 ContainerCreating 状态，甚至部分节点负载过高，导致集群整体不可用。这里提供完整的排查流程和优化方案。

🛠 1. 通过 `kubectl` 和 `describe` 命令排查 #

📌 查看 Pod 状态 #

kubectl get pods -A -o wide

Pending：表示 Pod 还未被调度到节点
ContainerCreating：Pod 已调度到节点，但容器未能成功创建
CrashLoopBackOff：Pod 不断重启，可能是应用问题

📌 获取详细信息 #

kubectl describe pod <pod-name> -n <namespace>

```
Events
```
字段可查看错误原因：
- FailedScheduling：调度失败，可能资源不足
- Network not ready：CNI 组件故障
- Failed to attach volume：存储挂载失败

🔍 2. 调度问题（Pod 无法被分配到节点） #

🛑 问题 1：集群资源不足 #

现象

：

kubectl describe pod

显示：

0/50 nodes are available: insufficient CPU, insufficient memory

kubectl get nodes 显示部分节点 NotReady

✅ 解决方案：

检查节点可用资源
```
kubectl top nodes
```
如果 CPU 或内存已满，可以：
- 释放无用 Pod
- 扩容 Worker 节点

调整调度策略（使用 priorityClass 提升关键 Pod 优先级）

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "High priority for critical pods"

优化 Pod 资源请求

避免 Pod 申请过多资源导致调度失败：

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "1Gi"

🛑 问题 2：节点调度限制 #

现象
：
- ```
kubectl describe pod
```
  显示：
```
0/50 nodes match node selector
```
- Pod 绑定了 nodeSelector 或 affinity，导致没有可用节点

✅ 解决方案：

检查 Pod 的 nodeSelector

nodeSelector:
  node-type: "high-performance"

确保有至少一个符合条件的节点：
```
kubectl get nodes --show-labels
```

检查 affinity 规则

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disktype
          operator: In
          values:
          - ssd

可适当降低 requiredDuringSchedulingIgnoredDuringExecution 的约束级别。

🔍 3. 容器创建问题（ContainerCreating 卡住） #

🛑 问题 3：CNI 网络组件异常 #

现象

：

kubectl describe pod

显示：

Failed create pod sandbox: rpc error: code = Unknown desc = failed to setup network

kubectl get pods -n kube-system 发现 coredns、calico-node 等网络组件异常

✅ 解决方案：

检查 CNI 插件状态

kubectl get pods -n kube-system | grep calico
kubectl logs -f <cni-pod-name> -n kube-system

如果 CNI 组件崩溃，重启它：

kubectl delete pod <cni-pod-name> -n kube-system

检查 IP 资源是否耗尽

kubectl get ippools -A

如果 IP 地址不足，需要扩展 IP 池：

kind: IPPool
metadata:
  name: default-pool
spec:
  cidr: 192.168.1.0/24
  blockSize: 26

🛑 问题 4：容器镜像拉取失败 #

现象

：

kubectl describe pod

显示：

Failed to pull image: ImagePullBackOff

kubectl get events

发现：

Failed to pull image "myrepo/myimage:v1.0": not found

✅ 解决方案：

检查私有镜像仓库的 Secret

kubectl get secret -n <namespace>

如果没有

imagePullSecret

，创建：

kubectl create secret docker-registry my-registry-secret \
  --docker-server=<your-registry> \
  --docker-username=<your-username> \
  --docker-password=<your-password> \
  --namespace=<namespace>

修改 Pod 配置：

imagePullSecrets:
- name: my-registry-secret

检查镜像仓库可用性

docker login <your-registry>
docker pull myrepo/myimage:v1.0

🔍 4. 存储问题（PVC 绑定失败） #

🛑 问题 5：存储卷挂载失败 #

现象

：

kubectl describe pod

显示：

MountVolume.SetUp failed for volume "pvc-xxxx" : rpc error: code = DeadlineExceeded

Pod 处于 ContainerCreating 状态

✅ 解决方案：

检查 PVC 状态

kubectl get pvc -n <namespace>

如果
```
STATUS
```
为
```
Pending
```
，则需要确认存储类：
```
kubectl get sc
```

如果 PVC 绑定失败，尝试强制重新绑定
```
kubectl delete pod <pod-name> -n <namespace>
```

🔍 5. Master 组件负载过高 #

🛑 问题 6：API Server 负载过高 #

现象
：
- kubectl get pods 响应缓慢
- kube-apiserver CPU 飙高

✅ 解决方案：

检查 API Server 压力

kubectl get --raw "/metrics" | grep apiserver_request

启用 kube-proxy IPVS 模式，减少 API Server 负载
```
mode: "ipvs"
```

增加 API Server 副本数

kubectl scale deploy kube-apiserver --replicas=3

🎯 总结 #

问题	解决方案
资源不足	调整 `requests/limits`，扩容节点
调度失败	放宽 `nodeSelector`，使用 `priorityClass`
CNI 故障	检查 `coredns` 和 `calico-node`
镜像拉取失败	添加 `imagePullSecrets`，检查镜像仓库
PVC 绑定失败	检查 `StorageClass` 和 `PersistentVolume`
API Server 负载高	启用 IPVS，增加副本数

如果集群大规模启动 Pod 失败，按照以上方法逐步排查，优化调度和资源分配，即可提高系统稳定性！ 🚀

部署redis或者kafka中间件吗？怎么设计容器化方案？高可用？数据持久化或者延迟的情况？ #

Kubernetes 中 Redis 和 Kafka 容器化方案 #

在 Kubernetes 中部署 Redis 或 Kafka 需要考虑高可用、数据持久化和延迟优化等关键点。以下是详细的设计方案。

1️⃣ Redis 容器化部署方案 #

📌 Redis 方案设计 #

架构
：
- Redis Sentinel + Redis 主从（高可用）
- Redis Cluster（分片扩展）
存储持久化
：
- AOF（Append Only File，适用于数据一致性要求高的场景）
- RDB（周期性快照，适用于性能优先场景）
部署方式
：
- StatefulSet 管理 Redis Master/Slave
- Sentinel 监控并自动故障转移
- 持久化 PVC 存储 Redis 数据

📌 方案 1：Redis Sentinel 高可用 #

🛠 1.1 创建 Redis StatefulSet #

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:6.2
        args: ["redis-server", "/redis.conf"]
        volumeMounts:
        - name: data
          mountPath: /data
        ports:
        - containerPort: 6379
      volumes:
      - name: redis-config
        configMap:
          name: redis-config
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

🛠 1.2 创建 Sentinel 部署 #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-sentinel
spec:
  replicas: 3
  selector:
    matchLabels:
      app: redis-sentinel
  template:
    metadata:
      labels:
        app: redis-sentinel
    spec:
      containers:
      - name: sentinel
        image: redis:6.2
        args: ["redis-sentinel", "/sentinel.conf"]
        ports:
        - containerPort: 26379

📌 高可用原理 #

Sentinel 监听 Redis 主从状态，如果主节点挂掉，会自动选举新的主节点。
StatefulSet 保证 Redis 节点的稳定性，Pod 重启后 IP 不变。
PVC 持久化 Redis 数据，防止 Pod 删除导致数据丢失。

📌 方案 2：Redis Cluster（分片） #

适用于高吞吐场景，分片存储，提高可扩展性。
需要 6 个 Redis Pod（3 Master + 3 Slave）。

使用

StatefulSet

部署 Redis，每个 Pod 运行

redis-server

并开启集群模式：

redis-cli --cluster create <master1-ip>:6379 <master2-ip>:6379 <master3-ip>:6379 --cluster-replicas 1

缺点
：
- 需要应用端支持 Redis Cluster 访问方式（JedisCluster 或 lettuce）。
- 需要 configmap 提前配置 redis.conf 以支持 cluster-enabled yes。

2️⃣ Kafka 容器化部署方案 #

Kafka 需要考虑高可用、数据持久化和延迟优化，推荐使用 Kafka + Zookeeper 进行管理。

📌 Kafka 方案设计 #

存储：Kafka 依赖磁盘 IO，需要 PersistentVolume
高可用：多副本 replication-factor > 1
优化
：
- log.segment.bytes 调整 segment 大小，优化日志存储
- message.max.bytes 限制单条消息大小，防止 OOM
- num.partitions 适当增加分区，提高并发能力

📌 Kafka 容器化部署 #

🛠 2.1 部署 Zookeeper（用于管理 Kafka Broker） #

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: zookeeper
spec:
  serviceName: zookeeper
  replicas: 3
  selector:
    matchLabels:
      app: zookeeper
  template:
    metadata:
      labels:
        app: zookeeper
    spec:
      containers:
      - name: zookeeper
        image: bitnami/zookeeper:latest
        env:
        - name: ALLOW_ANONYMOUS_LOGIN
          value: "yes"
        ports:
        - containerPort: 2181

🛠 2.2 部署 Kafka StatefulSet #

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka
spec:
  serviceName: kafka
  replicas: 3
  selector:
    matchLabels:
      app: kafka
  template:
    metadata:
      labels:
        app: kafka
    spec:
      containers:
      - name: kafka
        image: bitnami/kafka:latest
        env:
        - name: KAFKA_CFG_ZOOKEEPER_CONNECT
          value: "zookeeper:2181"
        - name: KAFKA_CFG_ADVERTISED_LISTENERS
          value: "PLAINTEXT://kafka:9092"
        - name: KAFKA_CFG_DEFAULT_REPLICATION_FACTOR
          value: "2"
        - name: KAFKA_CFG_NUM_PARTITIONS
          value: "3"
        ports:
        - containerPort: 9092
        volumeMounts:
        - name: data
          mountPath: /bitnami/kafka
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

3️⃣ 关键优化点 #

📌 1. 数据持久化 #

Redis：使用 PVC 存储 /data 目录，防止重启丢失数据。
Kafka：使用 PVC 持久化 /bitnami/kafka 目录，防止 Broker 失效导致数据丢失。

📌 2. 高可用 #

组件	方案
Redis	Sentinel 或 Cluster
Kafka	`replication-factor=2`，避免单点故障
Zookeeper	3 个副本，避免 Leader 选举失败

📌 3. 延迟优化 #

Redis：
- 关闭 fsync 以提高写入吞吐（但可能导致数据丢失）
- maxclients 限制并发连接，防止 OOM
- timeout 设置超时回收空闲连接
Kafka：
- acks=1 提高生产者吞吐量（acks=all 可保证一致性，但会增加延迟）
- linger.ms=5 批量处理消息，减少 IO 请求
- replication-factor=2 确保消息不丢失

✅ 总结 #

组件	高可用	持久化	优化策略
Redis	Sentinel / Cluster	PVC / AOF	fsync 关闭，maxclients 限流
Kafka	多 Broker + Zookeeper	PVC	acks=1, linger.ms=5
Zookeeper	3 副本	PVC	Leader 选举优化

通过 Kubernetes StatefulSet 进行 Redis 和 Kafka 部署，可以保证高可用、持久化和低延迟，同时能够动态扩展，提高系统稳定性！ 🚀

drgonfly的原理？ #

Dragonfly 原理解析 #

📌 Dragonfly 是什么？ #

Dragonfly 是阿里巴巴开源的P2P 分发系统，主要用于云原生环境，优化大规模镜像、文件分发，解决 Kubernetes 集群中容器镜像拉取慢的问题。

1️⃣ Dragonfly 主要组成 #

Dragonfly 主要由以下核心组件构成：

组件	作用
dfdaemon	运行在每个 Node 上的 P2P 下载守护进程，拦截 `docker pull` 请求
scheduler	调度节点，负责 Peer 节点管理、任务分发、P2P 下载调度
cdn	缓存中心，加速种子文件分发
dfget	具体执行下载任务的工具
dfstore	分布式存储，用于缓存分片数据

2️⃣ Dragonfly 的工作原理 #

Dragonfly 主要通过P2P 方式加速文件分发，整体流程如下：

🛠 1. 镜像/文件下载请求 #

用户在 Kubernetes 集群中执行 docker pull 拉取镜像。
dfdaemon 作为本地代理，拦截 docker pull 请求，改为使用 Dragonfly 下载。

🛠 2. 调度节点（scheduler） #

dfdaemon 将请求发送给 scheduler，查询是否有缓存。
```
scheduler
```
负责：
1. 查询缓存：检查 cdn 是否已有完整文件。
2. 调度 P2P 下载：如果 cdn 没有完整文件，则从 source 下载并切分成多个分片，并调度到多个节点。

🛠 3. P2P 下载 #

scheduler 选择最优 peer 作为种子节点，分发数据块。
其他 dfdaemon 互相请求数据，实现P2P 传输，避免所有节点都去访问 cdn 或 registry，降低带宽压力。

🛠 4. 本地缓存 #

下载完成后，dfdaemon 会缓存分片数据，加速后续下载，避免重复拉取。
dfdaemon 也可以充当新种子节点，供其他 Peer 下载，提高下载速度。

3️⃣ Dragonfly 的 P2P 下载机制 #

🔥 P2P 分块下载 #

任务分片：文件或镜像被拆分成多个小块（chunk）。
并行下载：多个 dfdaemon 互相下载分片，避免单点瓶颈。
动态调度：scheduler 计算最优 peer，减少带宽消耗。

4️⃣ Dragonfly 高可用架构 #

🌍 多级缓存架构 #

本地缓存（dfdaemon）：加速相同文件的重复拉取。
集群级缓存（P2P）：不同节点互相拉取，提高整体吞吐。
全局 CDN 缓存：存储完整文件，避免回源 Registry。

⚡ 关键特性 #

P2P 下载，减少单点压力，优化大规模集群的拉取性能。
自动降级，如果 P2P 失败，回退为 HTTP 直连下载。
对 Kubernetes 友好，可与 containerd、docker 无缝集成。

5️⃣ Dragonfly 在 Kubernetes 集群中的应用 #

Dragonfly 主要用于优化 Kubernetes 集群镜像拉取，特别是在大规模 Pod 启动时。

🔥 在 Kubernetes 使用 Dragonfly #

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dfdaemon
spec:
  selector:
    matchLabels:
      app: dfdaemon
  template:
    metadata:
      labels:
        app: dfdaemon
    spec:
      containers:
      - name: dfdaemon
        image: dragonflyoss/dfdaemon:latest
        ports:
        - containerPort: 65001
        volumeMounts:
        - name: dfdaemon-cache
          mountPath: /var/cache/dragonfly

🚀 使用方式 #

dfdaemon 运行在每个 Node 上，拦截 docker pull。
调度 dfget 进行 P2P 下载，提高并行度。
加速大规模 Kubernetes Pod 启动，避免 Registry 压力过大。

6️⃣ Dragonfly 对比其他加速方案 #

方案	传统 Registry	Dragonfly	镜像加速 Proxy
拉取方式	单点拉取	P2P 下载	CDN 缓存
适用于	小规模集群	大规模分发	普通加速
资源消耗	高	低	适中
可靠性	依赖 CDN	P2P 自适应	依赖源站

✅ 总结 #

Dragonfly 采用 P2P + CDN，优化大规模镜像/文件分发。
通过 dfdaemon、scheduler、cdn 组件，实现高效调度、缓存优化。
适用于 Kubernetes 集群，提升大规模 Pod 启动的下载性能，减少 Registry 压力。

🚀 在 K8s 大规模集群中，Dragonfly 是解决镜像拉取慢的利器！

监控和cicd了解哪些？监控日活千万的app，设计监控体系和关注哪些指标？ #

监控日活千万级 App 的监控体系设计 #

日活千万级 App 需要构建一个 高可用、低延迟、可观测性强 的监控体系，以保障稳定运行、快速发现问题、优化用户体验。以下是完整的监控设计方案：

1. 监控体系设计 #

（1）监控架构 #

监控体系一般由 数据采集、存储、分析、告警 四个核心部分组成：

数据采集（Agent/SDK/Exporter）
- 业务指标：埋点日志、APM（SkyWalking、Zipkin）
- 系统监控：Prometheus Node Exporter、cAdvisor
- 日志分析：ELK、Fluentd
- 网络监控：Ping、Traceroute、NetFlow
数据存储
- 时序数据库：Prometheus、Thanos、VictoriaMetrics
- 日志存储：Elasticsearch、Loki
- APM 分析：SkyWalking、Jaeger
数据分析
- 指标查询：Grafana
- 异常检测：Anomaly Detection（AI 结合 PromQL）
告警机制
- 实时告警：Prometheus Alertmanager、企业微信、钉钉、短信
- 自动扩缩容：HPA（Horizontal Pod Autoscaler）
- 智能故障诊断：AI 预测 + 机器学习

2. 关键监控指标 #

（1）业务层监控 #

💡 业务指标能直观反映 App 运行情况：

监控项	说明	影响
DAU（日活）	每日活跃用户数	低于预期需排查用户流失原因
MAU（月活）	每月活跃用户数	反映长期用户趋势
UV/PV	访问人数/页面浏览量	监控用户访问情况
留存率	N 日留存率	用户粘性 & 营销效果
用户请求量	每秒请求数（QPS）	突增可能 DDoS 攻击或活动流量激增
平均响应时间（P99/P95）	用户请求处理时间	过高说明系统或数据库有瓶颈
支付成功率	订单支付成功率	低于预期需排查支付渠道问题
Crash 率	App 崩溃率	影响用户体验

（2）系统层监控 #

💡 保障 App 服务器和基础设施稳定：

监控项	说明	影响
CPU 使用率	服务器 CPU 负载	持续高负载可能导致请求阻塞
内存占用（RSS、OOM）	进程内存消耗情况	OOM 可能导致服务异常
磁盘 IO & 磁盘空间	读写速率 & 剩余空间	高 IO 可能影响数据库性能
网络流量	出入带宽、丢包率、RTT	突然升高可能是攻击或用户激增
Pod 副本数	Kubernetes Pod 运行状态	Pod 异常减少说明 K8s 可能有问题
依赖服务健康	Redis、Kafka、MySQL、外部 API	依赖异常可能导致服务不可用

（3）应用层监控（APM） #

💡 结合分布式链路追踪（SkyWalking/Jaeger）：

监控项	说明	影响
接口响应时间	API 响应时间（P99/P95）	影响用户体验
数据库查询耗时	SQL 查询慢查询分析	数据库索引优化
HTTP 状态码（5xx、4xx）	HTTP 错误比例	5xx 说明服务器异常
线程池使用情况	线程数量、阻塞率	影响吞吐量
消息队列积压	Kafka/RabbitMQ 队列长度	影响数据处理速度

（4）日志 & 异常监控 #

💡 通过 ELK 或 Loki 监控日志异常：

监控项	说明	影响
错误日志数量	每秒产生的 ERROR 级别日志	突增可能是 bug
OOM Kill 记录	进程被杀记录	容器内存不足
API 超时日志	API 响应超时情况	后端压力过大
用户行为日志	用户行为分析	用户流失诊断
攻击行为日志	404/403/SQL 注入等攻击行为	可能是安全漏洞

3. 监控工具选型 #

监控类型	解决方案
系统监控	Prometheus + Node Exporter
日志分析	ELK / Loki / Fluentd
APM（链路追踪）	SkyWalking / Jaeger
数据库监控	MySQL Exporter、Redis Exporter
告警通知	Prometheus Alertmanager + 钉钉/微信

4. 告警策略 #

（1）告警分级 #

级别	处理方式
严重（S1）	影响全站，立即电话通知
高（S2）	影响部分用户，5 分钟内处理
中（S3）	影响少量用户，1 小时内处理
低（S4）	影响较小，业务团队跟进

（2）自动化运维 #

自愈机制：Pod OOM 自动重启（K8s HPA）
扩缩容：CPU / QPS 超阈值时自动扩容
日志分析：自动识别异常日志，预测故障

5. 典型故障场景 & 处理 #

故障类型	可能原因	解决方案
高并发 QPS 突增	活动流量激增	增加 Pod 副本、开启缓存
数据库慢查询	SQL 语句未优化	增加索引、分库分表
Redis 连接数过高	连接未复用	使用连接池
服务器 CPU 100%	GC 频繁	调整 JVM 参数
流量异常下降	CDN/负载均衡异常	检查 Nginx/Ingress
请求响应时间变长	API 限流	增加实例数

总结 #

建立完善的监控体系（采集、存储、分析、告警）
覆盖业务、系统、APM、日志等多维度
使用 Prometheus、ELK、SkyWalking 进行全方位监控
通过 AI 预测和自动化运维减少人工干预
确保关键指标有合理的告警策略

这样可以 快速发现问题，保障 App 的高可用性 🚀

prometheus oom怎么解决的？ #

在使用 Prometheus 进行监控时，遇到 OOM（Out Of Memory，内存溢出）问题可能是由于多种原因导致的，例如数据量过大、配置不当等。以下是解决 Prometheus OOM问题的一些常见方法：

1. 增加 Prometheus 的内存限制 #

方法：通过调整 Prometheus 启动参数来增加其可用的内存。
参数：--storage.tsdb.max-block-duration、--storage.tsdb.retention.time 等。
具体操作：可以通过在 Prometheus 的启动命令中增加如 --storage.tsdb.retention.time=15d 来限制数据的保留时间，减少内存压力。

2. 调整 `max-memory` 限制 #

Prometheus 默认会使用更多的内存来存储时间序列数据。如果你遇到 OOM，可以增加 Prometheus 容器的内存限制。
方法
：在 Kubernetes 中可以通过配置资源请求和限制来增加内存限制。
```
resources:
  requests:
    memory: "4Gi"
  limits:
    memory: "8Gi"
```

3. 减少 Prometheus 存储数据的量 #

时间序列保留策略：调整 --storage.tsdb.retention.time，减少保留的数据量，可以减少内存占用。
示例
：可以将数据的保留时间设置为 7 天，而不是默认的 15 天或更长：
```
--storage.tsdb.retention.time=7d
```

4. 使用较小的 `scrape_interval` #

问题：Prometheus 在每个 scrape_interval 时间间隔内拉取目标数据。如果 scrape_interval 太短，Prometheus 会频繁抓取数据，导致内存占用过高。
解决
：适当增加
```
scrape_interval
```
，例如将默认的
```
15s
```
改为
```
30s
```
或更长，减少每次抓取的数据量。
```
scrape_interval: 30s
```

5. 优化数据源和查询 #

问题：如果你的数据源包含大量的数据点，Prometheus 在进行聚合查询时可能会导致高内存占用。
解决：优化查询，避免在短时间内进行大量数据的聚合，或者通过分段查询的方式减少内存使用。

6. 启用 `remote_write` 和外部存储 #

如果 Prometheus 内存使用较高，可以将数据通过 remote_write 发送到外部存储，如 Thanos 或 Cortex。这样可以将大量历史数据从 Prometheus 中移除，减少内存使用。

配置

：

remote_write:
  - url: "http://thanos-receiver:9201/api/v1/receive"

7. 提高 Prometheus 性能 #

方法：通过调整 TSDB（时间序列数据库）相关的配置来提升 Prometheus 性能，减少内存占用。

配置

：例如调整

--storage.tsdb.min-block-duration

来减少数据块的大小。

--storage.tsdb.min-block-duration=2h

8. 扩展 Prometheus 集群 #

方法：在高负载环境下，可以考虑将 Prometheus 扩展为集群模式，使用如 Thanos 或 Cortex 等解决方案进行水平扩展。这能有效地分散负载，避免单个 Prometheus 实例内存溢出。

总结： #

解决 Prometheus OOM 问题通常需要从内存配置、数据保留策略、查询优化、外部存储等方面入手。根据实际的监控需求，合理调整这些配置，可以有效避免内存溢出，并提升 Prometheus 的性能和稳定性。

Prometheus 联邦（Federation）是 Prometheus 监控系统中的一个重要特性，旨在帮助解决大规模监控集群中的数据聚合问题，尤其是当多个 Prometheus 实例（或集群）需要汇总到一个中央 Prometheus 实例时。通过联邦，您可以跨多个 Prometheus 实例收集和聚合数据，从而在分布式系统中实现集中监控。

Prometheus 联邦的核心概念 #

Prometheus 联邦是一种将一个 Prometheus 实例的数据暴露给另一个 Prometheus 实例的机制。中央 Prometheus 实例可以定期从其他 Prometheus 实例抓取数据（scrape），从而实现跨 Prometheus 实例的数据汇聚和查询。

联邦的工作原理 #

数据采集（Scraping）：
- 每个 Prometheus 实例都会收集自己所在区域的监控数据，并将其存储在本地的 TSDB（时间序列数据库）中。
- 中央 Prometheus 实例（即主 Prometheus 实例）配置为定期从各个子 Prometheus 实例抓取数据。这些数据通常是通过 HTTP 访问暴露出来的时间序列数据。
数据聚合：
- 联邦允许中央 Prometheus 实例通过向其他 Prometheus 实例发送抓取请求来汇总数据。每个 Prometheus 实例可以作为一个“子集”，将部分数据暴露给主 Prometheus 实例。
- 被抓取的数据可以包括时间序列数据、指标数据、Alertmanager 配置等。
存储和查询：
- 中央 Prometheus 实例可以存储来自不同 Prometheus 实例的数据，并可以对这些数据进行统一的查询和分析。
- 使用 Prometheus 查询语言（PromQL）时，中央 Prometheus 实例可以对所有联邦的 Prometheus 实例的数据进行聚合查询。

联邦的典型用途 #

跨数据中心的数据汇聚：
- 在分布式系统中，可能有多个数据中心或者多个独立的 Prometheus 实例运行在不同的地理位置。通过联邦，可以将所有这些实例的数据汇聚到一个中央实例，以便统一监控和报警。
跨集群监控：
- 在 Kubernetes 等容器化环境中，可能有多个集群，且每个集群都有自己的 Prometheus 实例。通过 Prometheus 联邦，您可以从各个集群的 Prometheus 实例抓取数据，并集中存储和查询。
分层架构：
- 使用联邦可以实现分层监控架构。例如，在大型企业环境中，可以通过联邦将子集群的数据暴露给总部的中央 Prometheus 实例，方便进行汇总、报警和全局查询。
局部数据存储与查询：
- 在某些情况下，可能希望在本地 Prometheus 实例中存储和查询特定的、与该区域相关的时间序列数据，而将某些跨区域的数据聚合到中央 Prometheus 实例。

Prometheus 联邦的配置 #

Prometheus 联邦的配置实际上是将一个 Prometheus 实例配置为从另一个 Prometheus 实例抓取数据。这可以通过 scrape_config 来配置，以下是一个基本的例子：

scrape_configs:
  - job_name: 'federation'
    scrape_interval: 1m
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="kubernetes-cadvisor"}'  # 只抓取特定的指标
    static_configs:
      - targets:
        - 'prometheus-server-1:9090'
        - 'prometheus-server-2:9090'

关键参数解释 #

metrics_path: /federate：这是 Prometheus 联邦请求的路径，Prometheus 会从其他实例的 /federate 路径拉取数据。
params：使用 match[] 参数，可以指定要抓取的指标的过滤条件。这样可以只抓取特定类型的数据，避免抓取不必要的数据。
targets：指定从哪些 Prometheus 实例抓取数据，可以列出多个 Prometheus 实例。

优势 #

集中管理：通过联邦，可以实现跨多个 Prometheus 实例的数据汇总和集中查询，方便统一管理。
高可扩展性：随着监控的扩展，新的 Prometheus 实例可以很容易地加入联邦，数据会自动被集成。
灵活性：可以灵活地选择哪些数据需要集中存储，哪些数据在本地处理。
分布式架构支持：支持跨数据中心、跨集群的分布式监控。

限制和挑战 #

存储限制：联邦数据会增加中央 Prometheus 实例的存储需求。需要配置合适的存储和处理策略。
查询复杂性：联邦的 Prometheus 实例间的查询可能会引入一定的延迟，因为需要从多个实例抓取数据并进行汇总。
维护和管理：随着 Prometheus 实例的增加，联邦管理可能会变得更加复杂，特别是在大型环境中。

总结 #

Prometheus 联邦提供了一个有效的解决方案来扩展 Prometheus 监控系统，特别是在跨多个集群、数据中心或区域的环境中。通过合理配置联邦，可以实现大规模的监控数据汇聚和统一查询，但同时也需要考虑性能和存储等方面的挑战。

用ansible部署二进制集群？怎么保证play-book的幂等性和安全性？ #

使用 Ansible 部署二进制集群时，可以通过编写 playbook 来管理集群的安装、配置、更新等操作。为了确保 幂等性 和 安全性，我们需要在 playbook 中遵循一些最佳实践，确保每次运行时结果一致，同时避免潜在的安全漏洞。

部署二进制集群的步骤： #

假设我们要使用 Ansible 部署一个基于二进制安装的 Kubernetes 集群。步骤如下：

1. 准备工作 #

先确保每台节点的操作系统符合要求，且能通过 SSH 访问。
将需要部署的二进制文件（如 kubeadm、kubelet、kubectl）上传到目标节点。

2. Ansible Playbook 示例 #

以下是一个简化的 playbook 示例，演示如何通过 Ansible 在各个节点上部署 Kubernetes 二进制集群。

---
- name: Deploy Kubernetes Cluster
  hosts: k8s_nodes
  become: true
  tasks:
    - name: Ensure the necessary directories exist
      file:
        path: "{{ item }}"
        state: directory
        mode: "0755"
      loop:
        - /etc/kubernetes
        - /etc/kubernetes/manifests
        - /var/lib/kubelet
        - /var/lib/kubernetes

    - name: Copy kubeadm, kubelet, and kubectl binaries
      copy:
        src: "/path/to/binaries/{{ item }}"
        dest: "/usr/local/bin/{{ item }}"
        mode: "0755"
      loop:
        - kubeadm
        - kubelet
        - kubectl
      notify:
        - restart kubelet

    - name: Initialize Kubernetes master using kubeadm
      command: kubeadm init --pod-network-cidr=10.244.0.0/16
      when: inventory_hostname == groups['k8s_master'][0]
      register: kubeadm_init_output

    - name: Set up kubeconfig for the master node
      copy:
        src: "/etc/kubernetes/admin.conf"
        dest: "~/.kube/config"
        remote_src: yes
      when: inventory_hostname == groups['k8s_master'][0]

    - name: Apply CNI network plugin (flannel)
      command: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
      when: inventory_hostname == groups['k8s_master'][0]

    - name: Join the worker nodes to the cluster
      command: "{{ kubeadm_init_output.stdout_lines[0] | regex_replace('.*(kubeadm join.*)', '\\1') }}"
      when: inventory_hostname != groups['k8s_master'][0]

保证 Playbook 的幂等性： #

Ansible 的核心特性之一就是 幂等性，它意味着当你多次运行同一个 playbook 时，结果是相同的，不会对系统做不必要的更改。为了保证 playbook 的幂等性，需要：

检查资源的当前状态：
- 使用 state 参数来指定目标资源的状态（如：file、service 模块）。
- 例如，在部署 Kubernetes 二进制时，我们应该确保文件已存在且为正确的版本。
使用适当的 Ansible 模块：
- 使用 file、copy、yum、apt 等模块时，它们会自动检查目标状态，并且在目标已达到期望状态时，不会再次执行。
- 例如，copy 模块会在文件已经存在并且内容一致时跳过文件的复制。
避免冗余操作：
- 在 command 或 shell 模块中，确保命令不会重复执行，或者在条件满足时才执行。例如，在执行 kubeadm init 时，只在主节点上执行初始化操作。
配置文件变更：
- 对于需要更改配置文件的操作（例如 Kubernetes 配置文件、系统参数等），确保使用 lineinfile 或 template 模块，这些模块会检查文件是否已经按预期配置，避免重复修改。
```
- name: Ensure kubelet service is enabled and running
  service:
    name: kubelet
    state: started
    enabled: true
```

幂等性相关模块示例： #

file 模块：确保文件和目录的状态，如权限、存在与否。
copy 模块：确保文件只被复制一次，且内容一致。
template 模块：使用 Jinja2 模板来生成配置文件，并确保内容一致。
service 模块：确保服务启动、停止和启用的状态。
lineinfile 模块：确保文件中某行是存在的或被修改为指定的内容。

保证 Playbook 的安全性： #

避免硬编码敏感信息：
- 在 playbook 中避免直接写入敏感信息，如密码、密钥等。可以通过 Ansible Vault 来加密敏感信息。
```
ansible-vault create secrets.yml
```
然后在 playbook 中引用这个文件：
```
- name: Deploy Kubernetes Cluster
  vars_files:
    - secrets.yml
```
最小权限原则：
- 使用 become: true 提升权限时，确保只在必要的任务中使用 sudo 权限，不要在所有任务中都提升权限。
- 使用适当的用户和组来执行任务，确保不使用 root 用户执行所有操作。

确保文件权限和所有权：

通过 Ansible 的 file 模块确保配置文件和二进制文件的权限和所有权符合安全要求，避免文件被未授权用户访问。

- name: Set permissions on kubeconfig
  file:
    path: "~/.kube/config"
    owner: "{{ ansible_user }}"
    group: "{{ ansible_user }}"
    mode: "0600"

安全的网络配置：
- 在 Kubernetes 集群中，网络配置是安全的关键。确保只有允许的 IP 地址能访问 Kubernetes API 服务器等关键组件，使用 firewalld 或 iptables 配置网络防火墙规则。

使用防火墙限制访问：

使用 Ansible 来管理防火墙规则，确保只有受信任的主机可以访问集群中的关键端口。

- name: Allow access to Kubernetes API server
  ufw:
    rule: allow
    name: "Kubernetes API"
    port: 6443
    proto: tcp

保持软件更新：
- 定期更新 Kubernetes 组件和依赖项，以避免已知的安全漏洞。

通过遵循以上实践，您可以使用 Ansible 部署二进制集群，并确保 playbook 具有幂等性和安全性。

业务要实现灰度发布？怎么设计流水线？ #

灰度发布（Gray Release）是一种逐步发布新版本的策略，通过控制新版本的发布范围和用户群体，确保在发现问题时能够快速回滚，避免全量发布的风险。在实施灰度发布时，CI/CD 流水线的设计需要保证可以灵活地控制版本的发布范围，并且能够与不同的环境进行交互。

灰度发布流水线设计思路 #

分阶段发布：灰度发布通常会分为多个阶段，从最小的用户群体开始，逐步扩大到全体用户。在流水线设计上，需要支持逐步发布的过程，例如：
- 阶段1：仅在内部或开发环境中发布。
- 阶段2：小范围的真实用户群体（例如，10%的生产流量）。
- 阶段3：全量发布给所有用户。
版本控制：灰度发布通常涉及多个版本的并存，需要流水线支持不同版本的部署。例如，你可能同时部署旧版本和新版本，确保新版本能够与旧版本兼容，并能平滑过渡。
A/B 测试：灰度发布可以与 A/B 测试结合，控制不同用户组的流量。流水线需要能够将用户流量按照设定的规则（例如 80% 流量走旧版本，20% 流量走新版本）进行分配。

设计灰度发布流水线的步骤： #

代码提交触发：每当代码提交到 Git 仓库时，CI 流水线开始触发。使用工具如 Jenkins、GitLab CI、GitHub Actions、ArgoCD 等。
- 构建阶段：使用构建工具（如 Maven、Gradle、Docker 等）构建应用程序并生成镜像。
- 单元测试：运行单元测试，确保代码质量。
- 镜像推送：将构建的镜像推送到容器镜像仓库（例如 Docker Hub、Harbor）。
灰度发布策略：灰度发布策略通常基于 Kubernetes 的 Deployment 和 Ingress 控制流量的分发。流水线可以通过调整 ReplicaSet 或 Pod 的副本数来实现。
下面是一个基本的 Kubernetes 灰度发布流程：
- 阶段1：小范围发布：使用 canary 或 blue-green 模式部署新版本。
  - 在第一个阶段，流量只指向新版本的 Pod 的一部分。
  - 使用 Kubernetes Deployment 控制副本数，从而控制流量比例。
- 阶段2：扩大范围：在新版本无问题的情况下，逐渐增加新版本的流量。
  - 使用 Service 的流量管理和 Ingress 控制流量比例。
- 阶段3：全量发布：在没有问题后，完全替换旧版本，进行全量发布。

灰度发布流水线的任务：

下面是一个 Jenkins 和 Kubernetes 灰度发布流水线示例：

pipeline {
    agent any
    environment {
        DOCKER_IMAGE = "your_image_name"
        NAMESPACE = "production"
    }
    stages {
        stage('Build') {
            steps {
                script {
                    // 构建 Docker 镜像
                    sh 'docker build -t ${DOCKER_IMAGE}:${BUILD_NUMBER} .'
                    // 推送镜像到 Docker Hub
                    sh 'docker push ${DOCKER_IMAGE}:${BUILD_NUMBER}'
                }
            }
        }
        stage('Deploy to Staging') {
            steps {
                script {
                    // 部署到 Staging 环境
                    sh 'kubectl apply -f kubernetes/staging.yaml'
                }
            }
        }
        stage('Canary Release') {
            steps {
                script {
                    // 部署少量副本到生产环境（比如 10% 流量）
                    sh 'kubectl set image deployment/your-deployment your-container=${DOCKER_IMAGE}:${BUILD_NUMBER} --record'
                    sh 'kubectl scale deployment your-deployment --replicas=10' // 部署 10 个 Pod
                }
            }
        }
        stage('Monitor Canary') {
            steps {
                script {
                    // 等待一段时间，监控新版本是否正常
                    sleep(time: 5, unit: 'MINUTES')
                    sh 'kubectl get pods'
                }
            }
        }
        stage('Rollout') {
            steps {
                script {
                    // 扩展新版本的 Pod 数量，逐步增加流量
                    sh 'kubectl scale deployment your-deployment --replicas=50'
                }
            }
        }
        stage('Full Release') {
            steps {
                script {
                    // 完全替换为新版本
                    sh 'kubectl set image deployment/your-deployment your-container=${DOCKER_IMAGE}:${BUILD_NUMBER} --record'
                    sh 'kubectl scale deployment your-deployment --replicas=100'
                }
            }
        }
    }
    post {
        always {
            // 清理操作
            sh 'kubectl delete -f kubernetes/staging.yaml'
        }
    }
}

灰度发布中的关键技术和工具： #

Kubernetes：
- Deployment：使用 Deployment 控制 Pod 副本数量，进行逐步发布。
- ReplicaSet：调整副本数来控制流量。
- RollingUpdate 策略：使得 Kubernetes 可以逐步更新 Pods。
流量控制：
- Ingress Controller：可以使用 Nginx 或 Traefik 来管理 HTTP 流量，控制灰度发布流量的比例（例如：80% 旧版本，20% 新版本）。
- Service：控制新旧版本 Pod 的流量分配。
监控与告警：
- 在灰度发布过程中，必须有完善的监控机制，确保在发布新版本时能够及时发现问题。
- 使用 Prometheus + Grafana 监控系统，确保应用性能正常。
- 设置告警机制（如在性能下降时自动回滚）。
回滚机制：
- 当发现问题时，流水线应支持自动回滚到上一个稳定版本。
- 可以通过 Kubernetes 的 kubectl rollout undo 命令回滚部署，或者使用 ArgoCD 等工具来进行版本控制。

总结： #

灰度发布流水线的设计要保证在各个阶段都有自动化的控制和监控机制。流水线通常包括代码提交、镜像构建、部署、监控和回滚等多个步骤。通过与 Kubernetes 和流量管理工具配合，灰度发布可以有效减少发布带来的风险，并确保应用稳定运行。

业务场景，链路分发。业务运维，流量洪峰，设计自动扩缩的方案？ #

流量洪峰自动扩缩容方案设计 🚀 #

业务运维中，面对 大促、节假日、突发流量 时，自动扩缩容 是保障系统稳定的关键。针对 Kubernetes（K8s）容器化环境，我们可以结合 HPA（水平扩展）、VPA（垂直扩展）和 CA（Cluster Autoscaler） 来应对流量洪峰。

1. 流量洪峰的特征 #

突增 QPS（每秒请求数），通常表现为访问量短时间内飙升
CPU、内存飙升，单个实例资源紧张
数据库连接数暴涨，导致慢查询或超时
消息队列积压，消费端处理不过来
外部 API 响应变慢，依赖服务压力过大

2. 自动扩缩容架构 #

🚀 核心组件

HPA（Horizontal Pod Autoscaler）：基于 CPU、内存、QPS 等指标，自动扩展 Pod 副本
VPA（Vertical Pod Autoscaler）：动态调整 Pod 资源（CPU/内存）请求
Cluster Autoscaler（CA）：节点资源不足时自动扩展计算节点
KEDA（Kubernetes Event-driven Autoscaling）：基于消息队列（Kafka、RabbitMQ）负载进行扩缩容

📌 方案架构图

+----------------------------------+
|   Cluster Autoscaler (CA)        |  <==>  扩展 Kubernetes 计算节点
+----------------------------------+
          |
          v
+---------------------------+
|  Horizontal Pod Autoscaler (HPA)  |  <==>  扩展 Pod 数量
+---------------------------+
          |
          v
+---------------------------+
|  Vertical Pod Autoscaler (VPA)    |  <==>  调整 Pod 资源 (CPU/内存)
+---------------------------+
          |
          v
+---------------------------+
|  KEDA (事件驱动扩缩容)      |  <==>  基于消息队列负载扩容
+---------------------------+

3. 关键扩缩容策略 #

（1）Pod 水平扩展（HPA） #

适用于 QPS、CPU、内存、响应时间 波动的情况。

📌 示例：基于 CPU 自动扩缩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 50  # 最大扩展 50 个 Pod
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60  # CPU 超过 60% 时扩容

📌 HPA 触发条件

CPU > 60%
内存占用率高
QPS > 阈值

（2）Pod 垂直扩展（VPA） #

适用于 单个 Pod 资源不足（CPU/内存） 的情况。

📌 示例：VPA 自动调整 Pod 资源

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"  # 自动调整 CPU 和内存

📌 VPA 触发条件

单个 Pod CPU 长期 100%
内存持续超出限额
高并发场景下单个 Pod 处理能力不足

（3）集群节点扩展（Cluster Autoscaler） #

适用于 所有 Pod 都已调度但无可用节点 的情况。

📌 如何工作

HPA 扩展 Pod 失败 → 计算资源不足 → 触发 CA 增加新节点
CA 会根据 Pod 需求，自动扩展云厂商上的节点（阿里云 ACK、AWS EKS、GKE）

📌 配置 Cluster Autoscaler

cluster-autoscaler --nodes=3:50  # 节点最少 3 个，最多 50 个

📌 CA 触发条件

Pod 处于 Pending 状态（调度失败）
节点 CPU / 内存不足

（4）事件驱动扩缩容（KEDA） #

适用于 消息队列、Kafka 订阅任务激增 的情况。

📌 示例：基于 Kafka 消费积压自动扩缩

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer
spec:
  scaleTargetRef:
    name: kafka-consumer-deployment
  minReplicaCount: 1
  maxReplicaCount: 100
  triggers:
  - type: kafka
    metadata:
      topic: my-topic
      bootstrapServers: my-kafka-broker:9092
      lagThreshold: "1000"  # 消息积压超过 1000 条时扩容

📌 KEDA 触发条件

Kafka/RabbitMQ 消息积压
外部 API 请求排队
数据库连接数暴涨

4. 预案 & 高可用策略 #

（1）流量预案 #

📌 提前扩容

活动前手动扩容 Pod 和节点（预扩容）
预估 QPS 峰值，提前加机器

📌 灰度发布

蓝绿发布，确保新版本无异常
金丝雀发布，逐步放量

📌 弹性流量调度

流量分级：高优先级用户优先处理
熔断限流：Redis + Sentinel 做限流降级
动态降级：超时接口自动降级

（2）故障恢复 #

📌 自愈机制

Pod OOM 自动重启
节点宕机自动迁移
数据库超时自动降级

📌 快速扩展

手动快速扩展：

kubectl scale --replicas=100 deployment/my-app

自动恢复（Prometheus + Alertmanager）
- 发现 CPU 过高 → 触发 HPA 扩容
- 发现 Pod 过载 → 触发 CA 增加节点

5. 方案总结 #

方案	适用场景	优势
HPA（水平扩展）	CPU、QPS、内存	快速扩展 Pod 副本
VPA（垂直扩展）	CPU / 内存不足	调整单个 Pod 资源
Cluster Autoscaler	无可用节点	自动增加计算资源
KEDA（事件驱动扩容）	消息队列积压	低延迟扩缩容

最终架构 #

HPA + VPA + CA + KEDA 组合方案
高并发时 HPA 迅速扩容
计算资源不足时 CA 扩展节点
VPA 确保单个 Pod 性能
KEDA 应对事件驱动场景

这样可以 低成本、自动化 处理流量洪峰，保障业务稳定 💪🚀

故障排查？视频加载缓慢,网络存储链路分析，怎么一个排查思路？ #

排查视频加载缓慢的问题，尤其是在网络、存储和链路方面，通常需要按步骤进行细致的分析。以下是一个常见的排查思路：

1. 确定视频加载缓慢的表现 #

是否所有视频都慢：问题是普遍的还是仅限于某些视频？
延迟在哪个环节：是视频播放开始慢，还是在播放过程中卡顿？
网络或存储：是否与网络带宽、存储读写速度、缓存等因素有关？

2. 分析网络链路 #

检查带宽：
- 下载速度：测试网络的下载速度，确保带宽足够。使用工具如 speedtest-cli 检查网络的上传和下载速度。
- 是否有带宽瓶颈：使用 iperf3 进行带宽测试，检查是否存在网络带宽的瓶颈。
网络延迟和丢包：
- ping 测试：使用 ping 测试到服务器的延迟，确保网络延迟不会影响视频加载。
- traceroute 路由追踪：使用 traceroute 或 mtr 追踪网络路由，看是否有某一跳存在显著的延迟或丢包现象。
网络质量：
- TCP连接数限制：如果服务器接入了大量的并发请求，可能会导致 TCP 连接池溢出。检查服务器和客户端的连接数。
- 内容分发网络 (CDN)：如果使用了 CDN，检查 CDN 节点是否正常。如果是单一节点出现问题，可能导致某些用户加载缓慢。
HTTP 响应时间：
- 使用 curl 或 wget：检查视频文件请求的响应时间，确认是否是服务器端的响应慢导致加载延迟。
- HTTP 缓存：确认是否使用了合适的 HTTP 缓存机制，如果没有，服务器每次请求都需要重新生成视频流，可能导致延迟。
协议优化：
- 如果使用的是 HTTP/1，考虑切换到 HTTP/2，后者在多连接、头部压缩、请求优先级等方面有较大改进，能有效减少延迟。

3. 存储层排查 #

磁盘 I/O 性能：
- 磁盘性能：检查存储服务器的磁盘 I/O 性能，使用工具如 iostat、vmstat 等查看磁盘的吞吐量和延迟。
- 磁盘使用率：确认存储空间是否满，或磁盘是否达到负载上限。df -h 和 iostat 可以帮助分析存储设备的使用情况。
存储缓存：
- 缓存机制：检查是否有缓存机制（如 CDN 缓存、反向代理缓存等），并验证缓存是否工作正常。如果没有缓存，存储的读取负载会导致延迟。
- SSD vs HDD：如果存储设备是 HDD，可能会导致读取速度较慢。SSD 可以大幅提高读取速度。
存储系统负载：
- 存储服务的负载：如果是使用的共享存储或网络存储（如 NAS、SAN），确保存储系统本身没有过载，网络延迟和存储 I/O 高峰期可能会影响视频加载速度。

4. 视频文件分析 #

视频文件格式：检查视频文件的格式和编码。某些视频格式可能不适合网络传输，或者没有进行合适的编码优化。
视频分辨率和码率：如果视频的分辨率和码率过高，可能会导致网络传输过程中出现缓冲。考虑提供多种分辨率的视频版本，允许客户端根据网络条件自动选择合适的码率。
视频分片：确保视频文件采用了分片处理（如 HLS、DASH 等流媒体协议），这样客户端可以逐步下载视频而不是一次性下载完整视频文件。

5. 客户端排查 #

客户端性能：
- 确认客户端设备是否性能不足（CPU、内存、GPU 等）。例如，低性能设备可能无法处理高分辨率或高码率的视频流。
- 检查客户端是否使用了合适的视频播放器，并且是否支持硬件解码。软件解码可能会导致播放卡顿。
浏览器/播放器优化：
- 浏览器缓存：检查浏览器缓存是否正确工作。浏览器可以缓存部分视频数据，避免每次都从头开始加载。
- 视频播放器设置：确保播放器设置了适当的缓冲策略，例如设置足够的缓冲区大小来平滑播放。
网络环境：
- 确认客户端网络是否稳定，如果使用 Wi-Fi，尝试切换到有线网络进行测试，排除无线网络带来的不稳定因素。

6. 流程监控与日志 #

日志分析：
- 视频播放器日志：查看视频播放器的日志，检查是否有加载失败或延迟的错误信息。
- Web 服务器日志：检查视频请求的服务器日志，查看是否存在错误或异常的 HTTP 响应码（如 404、500 等）。
- 存储日志：如果使用分布式存储或对象存储，检查相关存储服务的日志，确保没有出现故障。
监控系统：
- 设置监控指标，监控存储、网络、服务器等关键资源的性能，利用 Prometheus、Grafana 等工具实时查看资源的负载情况。

7. 进行压力测试 #

在排查过程中，可以使用 压力测试 工具（如 Apache Benchmark、JMeter）模拟用户请求，查看服务器和存储的性能瓶颈，尤其是视频文件的读写能力。

总结： #

视频加载缓慢问题的排查需要从 网络链路、存储性能、视频文件、客户端性能 等多个维度进行分析。通过逐步检查各个环节，定位瓶颈，并根据发现的问题进行优化。如果是网络延迟或带宽不足，可以通过升级网络设施、增加 CDN 节点等方式解决；如果是存储瓶颈，可以考虑升级存储硬件或优化存储架构；如果是视频编码或播放器问题，可以通过调整视频的分辨率和码率，或者改进客户端播放器来解决。

多个故障，怎么区分优先级？ #

区分多个故障的优先级，通常需要依据故障的严重性、对业务的影响、恢复的难易程度和时间紧迫性来进行判断。以下是一些常见的优先级分类方法，帮助你快速、有效地区分和处理多个故障。

1. 根据故障影响范围分类 #

高优先级（Critical / P1）：
- 故障导致 关键业务中断，对公司收入、客户体验、安全等产生 严重影响。
- 例如：数据库宕机、核心系统无法访问、大规模的服务中断。
- 处理方式：立即响应，紧急修复，甚至需要全员参与处理。
中优先级（Major / P2）：
- 故障影响到部分用户或服务，导致 功能受限，但 业务仍可进行。
- 例如：某些服务响应缓慢、单个功能不可用，部分用户受影响。
- 处理方式：尽快响应，优先修复受影响范围广、影响较大的部分。
低优先级（Minor / P3）：
- 故障对业务没有直接影响或仅造成 小范围的功能损失。
- 例如：某些非关键服务的性能问题、UI bug，甚至是日志中的警告信息。
- 处理方式：通常可以排在后面处理，根据实际情况分配时间。

2. 根据故障恢复难易度分类 #

高优先级：如果故障较难修复或需要复杂的操作，如涉及到系统重启、硬件故障、数据库恢复等，应该优先处理。
低优先级：如果故障简单易修复，比如某个配置错误或小范围的代码bug，修复时间短，则优先级较低。

3. 根据时间敏感性分类 #

紧急（High urgency）：如果故障需要 尽快恢复，比如影响到 客户服务或收入，应该优先处理。
普通（Medium urgency）：如果故障不涉及直接的业务损失，但仍然需要在一定时间内解决，如影响到非高峰时段的流量。
不紧急（Low urgency）：如果故障不会在短期内对业务产生任何影响，且可以在后续的维护窗口中解决，属于低优先级。

4. 故障分类 #

功能性故障：例如，API 调用失败、数据库查询失败等，这类故障通常需要快速恢复。
性能性故障：例如，响应时间过长、系统卡顿等，可能会影响用户体验，尤其在高并发的场景下，需要及时修复。
安全性故障：如数据泄漏、权限漏洞等，这类问题具有较高的优先级，通常需要第一时间处理。
可用性问题：例如服务间歇性不可用，应该尽快定位故障源，修复时进行适当监控，确保业务恢复。

5. 使用故障管理系统 #

服务级别协议（SLA）：依据 SLA，定义每个故障类型的响应时间和恢复时间。遵守 SLA 是确保业务正常运营的关键。
自动化故障监控与告警：利用 Prometheus、Grafana 等监控工具设置 告警阈值，帮助实时获取故障信息，并自动将故障分类并标记优先级。
故障管理工具：使用如 Jira、ServiceNow 等故障管理工具，设定优先级、分配责任人并跟踪修复进度。

6. 基于业务价值评估 #

关键系统：如果故障涉及到影响核心业务的系统或组件，应该优先处理。比如支付系统、核心数据库、用户认证系统等。
非核心系统：对业务影响较小的系统可以排在后面，例如日志收集、监控系统等。

7. 确定恢复的最小可行方案 #

对于每个故障，根据业务需要，制定 最小可行恢复方案。有些故障可以临时绕过或采用简化方式恢复服务，而无需立即完全修复。

排查故障的优先级处理流程： #

紧急响应：首先处理对业务影响较大、需迅速恢复的故障（如系统宕机、用户无法访问等）。
逐一处理次要故障：在处理完高优先级故障后，逐步排查并处理中优先级的故障。
监控与调整：设置监控，确保业务恢复过程中没有新的问题，随时调整处理优先级。

总结 #

故障的优先级应该根据故障的 严重性、影响范围、恢复难度 和 时间敏感性 来判断。通过合理分类，能够确保高优先级的问题尽快得到处理，同时也不忽视较低优先级的长期改进。优先级分类需要灵活，根据不同场景和业务需求动态调整，确保业务不中断并保持最佳运行状态。

二线做什么事情？一线反馈到你这边，怎么去解决？ #

在运维或技术支持中，二线支持（L2）通常是 处理和解决一线支持（L1）无法解决的更复杂问题的部门。二线支持通常处理的问题比一线更复杂，涉及到深入的技术分析、故障排查以及系统优化等工作。

二线的主要工作职责： #

复杂问题排查：
- 一线可能会收到来自用户的故障反馈（如系统崩溃、性能下降等），但是这些问题超出了他们的解决范围。二线需要接手这些问题，并通过更详细的日志分析、系统配置检查等方法进行故障定位和解决。
- 比如，针对服务端出现的性能瓶颈、数据库查询慢等问题，二线工程师需要深入到代码、数据库、配置文件以及网络层级进行排查。
问题的根本原因分析：
- 一线通常通过标准流程解决已知问题，但如果问题较为复杂或没有现成的解决方案，二线会进行根本原因分析（Root Cause Analysis，RCA）。他们会查阅更详细的日志，分析系统健康状况，诊断出问题的根源并制定修复方案。
处理系统异常和故障：
- 二线支持处理的一些问题可能涉及到系统崩溃、硬件故障、网络问题或是与第三方集成的故障。例如，Kubernetes 集群故障、网络连接中断等。这些都超出了基础支持的范围，二线支持需要具备较强的技术能力来解决。
部署、维护与优化：
- 二线支持还会参与系统的维护工作，如升级、补丁管理、配置优化等。他们会对系统进行优化，确保系统运行稳定。
与开发团队的协作：
- 当问题涉及到代码或开发层面的缺陷时，二线需要与开发团队紧密配合，进行代码排查、功能验证和修复。
知识库管理：
- 在处理问题时，二线团队还会积累大量的技术文档和解决方案，这些可以帮助一线快速定位和解决常见问题。因此，二线支持需要持续更新技术文档和知识库。
提供技术支持与培训：
- 二线支持还负责为一线团队提供技术培训和指导，以提高他们的技术水平，减少重复性故障。

一线反馈到二线后，如何解决问题？ #

当一线无法解决的问题反馈给二线时，解决过程一般包括以下步骤：

问题确认与分类：
- 首先，二线支持人员会确认问题的性质，并进行初步分类。比如，是硬件故障、软件问题还是网络问题。
- 确认一线已经尝试过的解决方法，并确认所有基本步骤（如重启服务、检查网络连接等）已被一线执行。
获取更多信息：
- 二线支持会收集更多的背景信息，包括但不限于：
  - 错误日志、系统监控数据（CPU、内存、磁盘等）
  - 故障发生时的环境（如负载、流量、用户操作等）
  - 出现问题的具体步骤和操作流程
- 可以与用户或一线进一步沟通，确认详细信息。
深度排查与分析：
- 基于收集到的信息，二线工程师开始深入排查，可能会使用更多的监控工具、分析工具或者查看更详细的日志文件，检查是否有系统瓶颈、配置错误或者其他影响因素。
- 如涉及到复杂的系统架构问题，二线支持人员可能需要排查网络、数据库、微服务之间的依赖，查找可能的瓶颈。
解决方案的设计与验证：
- 二线支持人员会根据故障的根本原因，设计一个解决方案。该方案可能涉及到：
  - 系统重启
  - 应用配置修改
  - 软件升级或回滚
  - 增加硬件资源
- 设计完方案后，二线会进行验证，确保方案有效并不会带来新的问题。
执行修复：
- 确认解决方案后，二线支持团队会执行修复工作，恢复系统的正常运行。修复过程中，二线支持人员需要确保不影响其他正常运行的服务或系统。
验证与监控：
- 故障修复后，二线团队会进行验证，确保系统恢复正常，并通过监控工具进行持续跟踪，确认问题没有复发。
报告与反馈：
- 故障解决后，二线会向一线提供详细的解决方案与报告，帮助一线了解如何避免类似问题的发生。
- 记录解决方案和过程，以便后续参考。
总结与知识库更新：
- 将该故障的详细处理过程、解决方法总结到知识库或文档中，方便未来相似问题的快速解决。

总结 #

一线反馈给二线后，二线要首先确认问题的性质，收集更多的信息，进行深度分析，设计和执行修复方案。
整个过程需要根据故障的严重性、影响范围和优先级来进行，有时需要和其他团队（如开发、运维）合作解决问题。
二线支持不仅仅是修复问题，还要不断总结经验，优化工作流程，提高整体的解决效率。

离职原因？ #

家庭原因

更偏基础运维，系统运维，针对业务去运维？ #

业务运维和系统运维虽然在目标上有重叠，但侧重点和职责不同。下面是两者的主要区别：

1. 定义和重点 #

业务运维：
- 定义：业务运维主要关注的是通过技术手段支持和优化业务流程，确保业务系统的高可用性、性能、扩展性、安全性等，最大化地满足业务需求。
- 重点：业务运维的重点是根据具体的业务需求来优化系统架构和流程。它侧重于业务层面的支持，比如业务高峰期流量的保障、应用的可用性、数据处理能力等。
- 目标：为业务提供持续、稳定、高效的运行环境，并保证业务系统能够灵活应对业务变动，提供高质量的服务。
系统运维：
- 定义：系统运维是指对 IT 基础设施（如服务器、网络设备、存储等）进行日常管理和维护，确保系统的稳定、可用和安全。其职责通常包括硬件、操作系统、数据库、中间件等技术层面的维护。
- 重点：系统运维主要关注底层 IT 资源的管理和优化，如服务器、存储、网络等硬件资源的高效利用，以及操作系统、数据库、应用服务器等的软件维护。
- 目标：确保技术基础设施稳定运行，为上层业务提供支撑，保证系统的正常运行，处理硬件故障、系统漏洞、安全性问题等。

2. 主要职责 #

业务运维的职责：
- 根据业务需求设计系统架构和资源规划，确保业务的高可用性和性能。
- 监控与分析业务系统的性能、流量等指标，并进行优化。
- 配置和维护与业务紧密相关的应用、服务（如 Web 服务、数据库集群、缓存服务等）。
- 管理业务级别的故障排查和恢复，确保业务不中断。
- 与开发团队紧密协作，确保部署流程、代码发布等与业务需求相匹配。
- 根据业务需求进行容量规划，支持业务增长。
- 灾难恢复规划和业务系统备份，确保在发生故障时业务能够快速恢复。
系统运维的职责：
- 管理和维护 IT 基础设施（服务器、存储、网络等硬件资源）。
- 配置和维护操作系统、数据库、中间件等基础软件。
- 执行日常监控、故障排查和性能优化。
- 确保系统的安全性和稳定性，管理权限和安全策略。
- 执行定期备份、补丁管理、日志管理等任务。
- 处理硬件故障、系统崩溃、网络延迟等技术问题。
- 自动化运维，减少人工操作，提高运维效率。

3. 关注点和目标 #

业务运维关注点：
- 业务需求：业务运维强调与业务部门的紧密配合，确保技术平台能够支持不断变化的业务需求。通过优化架构和资源配置，保证业务系统能够灵活扩展。
- 用户体验：重点关注最终用户体验，确保系统能够高效响应用户请求，满足高并发、高可用等需求。
- 容量规划：根据业务的增长趋势进行容量规划，避免系统过载或资源浪费。
系统运维关注点：
- 技术稳定性：系统运维重点是保障基础设施的稳定运行，关注硬件资源的高效利用，操作系统和中间件的稳定性。
- 故障排除：当发生系统故障时，系统运维负责快速定位问题并恢复服务，避免影响系统的正常运行。
- 安全性：系统运维会进行定期的安全检查，确保系统没有安全漏洞，防止攻击和数据泄露。

4. 跨部门协作 #

业务运维：通常需要与 业务团队、产品团队、开发团队 等进行密切的沟通和协作。业务运维人员不仅要了解技术细节，还要理解业务逻辑，以便为业务提供更精确的技术支持。
系统运维：通常主要与 开发团队 和 基础设施团队 协作，关注基础设施的构建和维护。系统运维人员需要理解硬件、操作系统和中间件的工作原理，确保技术平台的稳定性。

5. 运维工具与技术 #

业务运维的工具与技术：
- 监控工具：使用业务监控工具，如 Prometheus、Grafana 等，来监控与业务相关的指标（如交易量、响应时间、用户访问量等）。
- 日志分析：使用 ELK Stack、Fluentd 等工具收集和分析业务日志，发现潜在问题。
- 自动化部署与发布：通过 CI/CD 工具（如 Jenkins、GitLab CI 等）自动化代码的构建、测试、部署和发布，减少人工干预。
系统运维的工具与技术：
- 监控工具：使用系统监控工具，如 Zabbix、Nagios、Prometheus 等，来监控服务器、网络、存储等硬件资源的状态。
- 自动化管理工具：使用 Ansible、Puppet、Chef 等自动化工具进行资源配置、补丁管理、故障恢复等。
- 容器与虚拟化管理：使用 Kubernetes、Docker 等容器化技术进行应用的部署、管理和调度。

总结 #

业务运维是围绕业务需求和业务系统进行的运维工作，重点是保障业务应用的稳定运行和高效响应。
系统运维是关注底层技术基础设施的运维，确保操作系统、网络、硬件等组件的稳定、安全和高效运行。

两者的目标虽然不同，但最终都是为了确保 IT 系统能够稳定支持业务的运营。业务运维更多关注如何将技术与业务目标对接，而系统运维则更多关注如何管理和维护技术资源以支持上层应用。

运维团队？管理机器多少台？ #

负责链路分发的业务运维手机的app的响应告警业务需求，上万台机器，内容分发几千台？ #

链路分发包含业务，一个人维护好几个业务，工作很大一部分是这样，对接开发的需求，一线白屏化操作，帮做业务达成目标，在项目里面，一线偏执行这块。 #

团队的管理和文化氛围？早上9点-晚上7点，9点半-7点，加班不强制，开会有需要就开 #

管理没这么卷， #

日常应用发布变更？什么时间操作？看业务，业务稳定，好几周发一次，迭代的一周2-3次 #

白天操作，晚上不允许变更，周一到周五早上10-下午6点。 #

你们的k8s集群的高可用架构怎么设计的？ #

1. 5个 Master 节点（控制面） #

2. Node 节点（工作节点） #

3. 联邦架构（Federation） #

4. AD BC 分区 #

5. 多 AZ 跨机房容灾设计 #

6. 健康检查和负载均衡 #

7. 灾难恢复与容错 #

8. 备份与恢复 #

总结 #

etcd或者控制面组件的容灾方案？ #

1. etcd 容灾方案 #

(1) etcd 高可用部署 #

(2) etcd 备份与恢复 #

(3) etcd 自动故障转移 #

2. Kubernetes 控制面组件容灾方案 #

(1) 高可用架构 #

多 Master 高可用 #

(2) 监控与自动恢复 #

(3) 备份与恢复 #

3. 故障恢复策略 #

4. 结论 #

演练，怎么设计演练场景，覆盖核心风险和推动改进的措施？ #

Kubernetes 容灾演练方案设计 #

1. 演练目标 #

2. 演练核心场景 #

🟢 场景 1：etcd 故障 #

🟡 场景 2：Master 节点故障 #

🔴 场景 3：Node 计算节点故障 #

🟠 场景 4：Ingress/Service 负载均衡异常 #

🔵 场景 5：存储故障 #

3. 保障措施 #

4. 结论 #

演练发现的问题和改进的地方？ #

演练发现的问题与改进方案 #

1. etcd 相关问题 #

🛑 问题 1：etcd 选主时间过长，影响 API Server 响应 #

🛑 问题 2：etcd 备份未生效，恢复失败 #

2. Master 组件问题 #

🛑 问题 3：kube-apiserver 宕机，负载均衡未生效 #

3. Node 计算节点问题 #

🛑 问题 4：节点驱逐后 Pod 迁移失败 #

4. Ingress / Service 问题 #

🛑 问题 5：Ingress Nginx 宕机后，业务不可访问 #

5. 存储问题 #

🛑 问题 6：PVC 绑定失败，Pod 进入 Pending 状态 #

总结 #

集群大规模启动pod失败，怎么定位问题并调优？ #

大规模启动 Pod 失败的排查与优化方案 #

🛠 1. 通过 kubectl 和 describe 命令排查 #

📌 查看 Pod 状态 #

📌 获取详细信息 #

🔍 2. 调度问题（Pod 无法被分配到节点） #

🛑 问题 1：集群资源不足 #

🛑 问题 2：节点调度限制 #

🔍 3. 容器创建问题（ContainerCreating 卡住） #

🛑 问题 3：CNI 网络组件异常 #

🛑 问题 4：容器镜像拉取失败 #

🔍 4. 存储问题（PVC 绑定失败） #

🛑 问题 5：存储卷挂载失败 #

🔍 5. Master 组件负载过高 #

🛑 问题 6：API Server 负载过高 #

🎯 总结 #

部署redis或者kafka中间件吗？怎么设计容器化方案？高可用？数据持久化或者延迟的情况？ #

Kubernetes 中 Redis 和 Kafka 容器化方案 #

1️⃣ Redis 容器化部署方案 #

📌 Redis 方案设计 #

📌 方案 1：Redis Sentinel 高可用 #

🛠 1.1 创建 Redis StatefulSet #

🛠 1.2 创建 Sentinel 部署 #

📌 高可用原理 #

📌 方案 2：Redis Cluster（分片） #

2️⃣ Kafka 容器化部署方案 #

📌 Kafka 方案设计 #

📌 Kafka 容器化部署 #

🛠 2.1 部署 Zookeeper（用于管理 Kafka Broker） #

🛠 2.2 部署 Kafka StatefulSet #

3️⃣ 关键优化点 #

📌 1. 数据持久化 #

📌 2. 高可用 #

🛑 问题 6：PVC 绑定失败，Pod 进入 `Pending` 状态 #

🛠 1. 通过 `kubectl` 和 `describe` 命令排查 #

2. 调整 `max-memory` 限制 #

4. 使用较小的 `scrape_interval` #

6. 启用 `remote_write` 和外部存储 #