RAIDS和K8S-优快云博客

Radi

常见级别

RAID 0

RAID 0：条带化（数据分块）但没有冗余，提供较高的读写性能。

RAID 1

具有数据冗余的能力，能够一定保证其中一块硬盘坏掉，数据不会丢失，如果两块硬盘来做RAID1，读写效率依旧是一块硬盘的，存储量也只有较小那块硬盘的大小

RAID 5

至少需要三块硬盘组成，既具有数据并行存储的能力，也具有防止某块硬盘坏掉数据丢失的能力

RAID 6

RAID 6使用数据条带化（striping）的方式将数据分散存储在多个磁盘驱动器上，并通过分布式奇偶校验和双重奇偶校验实现数据的冗余备份

RAID 10

是RAID0和RAID1的组合，先后顺序肯定会有区别的，该种磁盘阵列至少需要4块硬盘，并且RAID10的应用要优于RAID01

Raid级别	最小磁盘数	优点	缺点	可容量数据
RAID 0	2	读写性能高，磁盘利用率100%	无容错能力，单盘故障数据全丢	N*C
RAID 1	2	数据安全性高，读取性能提升	磁盘利用率仅50%，写入性能较低	C
RAID 5	3	存储利用率高，读性能接近RAID 0	写入性能较低，重建数据时性能下降	(N-1)*C
RAID 6	4	数据安全性高，能承受两块硬盘同时损坏	写入性能较差，磁盘利用率低	(N-2)*C
RAID 10	4	读写性能高，支持多盘故障	成本高，磁盘利用率仅50%	N/2*C

#服务器安装了Linux操作系统发生了异常重启的原因分析思路

第一阶段：收集关键信息与日志（首要任务）

系统日志 (journalctl & /var/log/messages, /var/log/syslog)：
- 命令：
  - journalctl -b -1：查看上一次启动的日志（异常重启发生前）。
  - journalctl -b：查看本次启动的日志（重启后）。
  - journalctl --since "yyyy-mm-dd HH:MM:SS" --until "yyyy-mm-dd HH:MM:SS"：查看特定时间段的日志。
  - grep -i 'error\|warn\|crit\|fatal\|panic\|oops\|segfault' /var/log/syslog：快速扫描关键错误信息。
- 关注点：
  - 重启前瞬间：是否有内核恐慌 (Kernel panic)、Oops（严重内核错误）、硬件错误 (MCE - Machine Check Exception)、驱动崩溃、关键服务崩溃 (segmentation fault) 的明确记录？
  - 重启前几分钟/小时：是否有资源耗尽警告（内存 OOM - Out Of Memory, 高 CPU, 磁盘满）？是否有硬件监控报警（温度过高 thermal, 风扇故障 fan, 电压异常 voltage）？是否有服务异常退出的记录？
  - 启动过程：系统启动是否顺利？是否有文件系统错误 (fsck)、挂载失败、服务启动失败的记录？
内核环形缓冲区 (dmesg)：
- 命令：dmesg -T (带时间戳) 或 dmesg | less。特别注意重启后立即查看，因为 dmesg 只保留本次启动的信息。
- 关注点：包含更底层的硬件和驱动信息。重点查找重启前瞬间或启动初期的：
  - Kernel panic 信息
  - Oops 堆栈跟踪
  - Hardware error / MCE / EDAC 报告
  - 特定硬件（网卡、磁盘控制器、GPU等）驱动崩溃信息
  - NMI received (不可屏蔽中断，常指示严重硬件问题)
  - BUG 信息
last 和 reboot 命令：
- 命令：
  - last -x | head：查看关机/重启记录，确认重启发生的确切时间和类型（reboot vs shutdown）。
  - reboot 命令本身也可能在 /var/log/auth.log 或安全日志中找到记录（排查人为误操作）。
系统监控数据（如果部署了）：
- 工具：Zabbix, Nagios, Prometheus/Grafana, Netdata 等。
- 关注点：重启前关键指标的图表：
  - CPU：使用率、负载、温度、核心电压
  - 内存：使用率、Swap 使用、OOM Killer 活动
  - 磁盘：I/O 延迟、使用率、SMART 健康状态（如果监控了）
  - 网络：流量、错误/丢包
  - 温度：CPU、主板、硬盘、GPU 温度
  - 电源：电压、电流（如果硬件/IPMI支持）
  - 进程：特定进程的资源消耗峰值
硬件日志 (IPMI/BMC/SEL)：
- 命令：ipmitool sel list (需要安装 ipmitool 且服务器支持 IPMI)
- 关注点：服务器的基板管理控制器 (BMC) 记录着独立于操作系统的硬件事件日志 (System Event Log - SEL)。这是诊断硬件故障（如电源、内存、CPU、风扇、温度）的黄金标准。查找重启时刻附近的 Critical 或 Warning 级别事件（如 Power Supply failure, Memory ECC error, Processor thermal trip, Fan failure）。
应用日志：
- 位置：通常在 /var/log/ 下（如 /var/log/nginx/, /var/log/mysql/error.log, /var/log/apache2/error.log）或应用自定义路径。
- 关注点：重启前是否有关键应用程序（如数据库、Web 服务器、业务应用）崩溃、卡死或抛出致命错误 (Fatal error, Crash, Segmentation fault)，特别是如果该应用是核心服务且可能触发系统问题。

第二阶段：分层分析原因（基于收集到的证据）

硬件问题 (非常常见)：
- 过热：CPU/主板/硬盘温度过高触发保护关机。查 IPMI SEL 和系统日志 (thermal, temperature)。
- 电源故障：电源单元 (PSU) 不稳定、功率不足、冗余失效、市电波动/UPS 问题。查 IPMI SEL (Power Supply)。
- 内存故障：ECC 错误累积、内存条损坏、接触不良。查 IPMI SEL (Memory ECC, Correctable/Uncorrectable Error), dmesg (EDAC, MCE), 运行 memtester 或 memtest86+ (需重启进内存测试工具)。
- CPU 故障：罕见但可能。查 IPMI SEL (Processor), dmesg (MCE), 运行压力测试 (如 stress-ng)。
- 主板/扩展卡故障：板载组件或 PCIe 设备（RAID卡、网卡、GPU）问题。查 IPMI SEL, dmesg 中相关驱动错误。
- 磁盘故障：系统盘或关键磁盘故障导致 I/O 卡死或文件系统损坏。查 dmesg, SMART 数据 (smartctl -a /dev/sdX)，文件系统日志 (fsck 输出)。
- 风扇故障：散热不足导致连锁过热。查 IPMI SEL (Fan)。
内核/驱动问题：
- 内核 Bug/Panic/Oops：dmesg 或系统日志中明确记录的内核级崩溃，通常有堆栈跟踪。可能由特定内核版本 Bug、驱动 Bug 或不兼容硬件触发。
- 驱动崩溃：特定硬件（尤其是新添加或固件升级后的硬件）的驱动不稳定导致内核崩溃。查 dmesg 中相关驱动的错误信息。
- 内核模块冲突：加载了冲突或不稳定的内核模块。
资源耗尽：
- 内存耗尽 (OOM Killer)：系统物理内存和 Swap 全部耗尽，内核 OOM Killer 被迫杀死进程以释放内存。如果 OOM Killer 杀掉了关键进程（如数据库、SSH）或大量进程，可能导致系统不稳定或重启。查系统日志 (Out of memory, oom-killer, invoked oom-killer), dmesg。监控内存使用历史。
- CPU 软锁/硬锁：极端 CPU 负载、内核 Bug 或硬件问题导致 CPU 完全无响应。dmesg 可能有 NMI received 或 soft lockup detected/hard lockup detected。
- 关键文件系统满：根文件系统 (/) 或关键分区 (如 /var, /tmp) 被写满，导致系统无法正常运行。查 df -h 历史或日志中的相关警告。
软件/服务问题：
- 关键系统服务崩溃：如 systemd, init, dbus 等核心服务崩溃可能直接或间接导致重启。查系统日志。
- 应用崩溃触发连锁反应：一个高权限或关键应用（如虚拟化管理程序 kvm, libvirtd）的严重崩溃 (Segmentation fault, Aborted) 可能影响整个系统稳定性。
- 守护进程配置错误：某些进程被配置为崩溃后自动重启系统（极不推荐且少见）。
外部因素：
- 人为误操作：意外执行了 reboot、shutdown -r now 或按了物理电源/复位按钮（查 auth.log, last 命令）。
- 远程管理卡操作：通过 IPMI/BMC 或 iDRAC/iLO 等远程管理界面执行了重启（查 IPMI SEL 和远程管理卡日志）。
- 计划任务/脚本：是否有配置错误或逻辑错误的 Cron 任务或脚本在特定时间执行了重启命令？查 /etc/crontab, /var/spool/cron/。
- 电源事件：数据中心断电、UPS 切换失败或测试、PDU 故障。
- 内核更新/配置变更后：最近是否更新了内核或修改了关键系统配置（如 /etc/sysctl.conf, Grub 参数）？可能是新内核或配置不稳定。
安全事件 (可能性较低但需警惕)：
- 内核级 Rootkit：极其罕见且复杂，恶意软件可能干扰系统导致崩溃重启。需专业工具排查 (rkhunter, chkrootkit, 完整性检查 aide, tripwire)。

第三阶段：诊断与验证

关联时间点：最关键的是将重启发生的精确时间与所有日志（系统日志、dmesg、应用日志、IPMI SEL）在该时间点前后（尤其是前几秒到几分钟）的记录进行关联分析。寻找最直接、最严重的错误信息。
重现问题 (谨慎)：如果条件允许且问题间歇性发生，尝试在监控下重现问题（如运行特定负载、测试特定硬件操作），但需评估风险。
硬件诊断工具：
- memtest86+：长时间运行内存测试（需从USB/CD启动）。
- smartctl：检查磁盘健康 (smartctl -a /dev/sdX)。
- ipmitool sensor / sdr：实时读取传感器数据（电压、温度、风扇）。
- mcelog (如果支持)：解析更详细的 MCE 错误。
- 厂商诊断工具：服务器厂商通常提供更全面的硬件诊断套件。
软件/内核调试：
- 分析 Kernel Core Dump：如果配置了 kdump (需要提前设置)，内核崩溃时会生成 vmcore 文件，使用 crash 工具分析能获得最根本原因。这是诊断内核 Panic/Oops 的最有力手段。
- 降级内核/驱动：如果怀疑是新内核或驱动引入的问题，尝试回退到已知稳定的版本。
- 最小化启动：在 Grub 引导时进入单用户模式或恢复模式，禁用非必要服务和启动项，看是否稳定，逐步排除软件干扰。

总结思路流程图

├── 第一步：紧急信息收集
│   ├── 1. 系统日志 (journalctl, syslog)
│   ├── 2. 内核日志 (dmesg -T)
│   ├── 3. 重启记录 (last -x, reboot)
│   ├── 4. 监控数据 (CPU/内存/磁盘/温度/网络)
│   ├── 5. 硬件日志 (ipmitool sel list) ★关键硬件证据
│   └── 6. 应用日志 (Nginx/MySQL等)
│
├── 第二步：基于证据分层分析
│   ├── 硬件层
│   │   ├── 过热 (CPU/盘)
│   │   ├── 电源故障
│   │   ├── 内存故障 (ECC)
│   │   ├── CPU故障
│   │   ├── 主板/卡故障
│   │   ├── 磁盘故障
│   │   └── 风扇故障
│   │
│   ├── 内核/驱动层
│   │   ├── Kernel Panic
│   │   ├── Oops
│   │   ├── 驱动崩溃
│   │   └── 模块冲突
│   │
│   ├── 资源层
│   │   ├── OOM Killer
│   │   ├── CPU 锁死
│   │   └── 磁盘满
│   │
│   ├── 软件层
│   │   ├── 核心服务崩溃
│   │   ├── 应用崩溃连锁
│   │   └── 错误配置
│   │
│   └── 外部因素
│       ├── 人为误操作
│       ├── 远程管理卡
│       ├── 计划任务
│       ├── 电源事件
│       └── 安全事件
│
└── 第三步：诊断验证
    ├── 关联时间点 (所有日志聚焦重启瞬间) ★最重要一步
    ├── (谨慎)尝试重现问题
    ├── 硬件工具 (memtest, smartctl, ipmi)
    ├── 分析内核转储 (vmcore + crash) ★内核崩溃金标准
    ├── 降级内核/驱动
    └── 最小化启动排除

IPMI/BMC SEL 日志是硬件问题的首要线索！ 务必优先检查。
重启前瞬间的 dmesg 和系统日志是软件/内核问题的首要线索！
配置 kdump 并分析 vmcore 是诊断内核崩溃的最有效方法。 强烈建议生产服务器启用 kdump。
不要忽视监控数据！ 它能清晰展示重启前的系统状态趋势。
系统性地收集所有证据后再做结论，避免先入为主。 多个因素可能同时存在或相互影响。
如果问题难以定位且反复发生，考虑联系服务器硬件厂商支持或专业 Linux 系统工程师协助。

Kubernetes（常简称为 K8s）是用于自动化容器化应用部署、扩展和管理的开源平台。它源自 Google 的 Borg 系统，现由 CNCF（云原生计算基金会）维护，已成为容器编排领域的事实标准。

一、核心价值与解决的问题

传统痛点	Kubernetes 解决方案
手动部署容器效率低	自动化调度容器到集群节点
应用扩展困难	一键水平扩展（HPA）
服务宕机恢复慢	自愈能力（自动重启/迁移故障容器）
资源利用率低	智能资源调度（Bin Packing）
跨环境部署不一致	声明式配置 + 环境无关性

二、核心架构

1. 控制平面（Control Plane）：集群的“大脑”

组件	功能
kube-apiserver	集群唯一入口，REST API 服务，接收所有操作请求
etcd	分布式键值数据库，存储集群所有状态数据（唯一有状态组件）
kube-scheduler	监控未调度 Pod，根据策略（资源、亲和性等）将其绑定到合适 Node
kube-controller-manager	运行控制器（如 Node Controller、Deployment Controller），确保集群状态符合预期
cloud-controller-manager	对接云厂商 API（如 AWS/GCP），实现负载均衡、存储卷等云服务集成

2. 数据平面（Data Plane）：运行工作负载的节点

组件	功能
kubelet	节点代理，管理 Pod 生命周期（创建/销毁容器）、报告节点状态
kube-proxy	维护节点网络规则（iptables/IPVS），实现 Service 的负载均衡和网络访问
容器运行时	运行容器的引擎（如 containerd、CRI-O）
Pod	Kubernetes 最小调度单元，包含 1 个或多个共享网络/存储的容器

三、关键概念

1. 工作负载资源

资源类型	用途
Deployment	管理无状态应用（如 Web 服务），支持滚动更新、回滚
StatefulSet	管理有状态应用（如数据库），保障 Pod 有序性和持久存储
DaemonSet	每个节点运行一个 Pod（如日志收集 agent）
Job/CronJob	运行一次性任务/定时任务

2. 服务发现与网络

资源类型	用途
Service	为一组 Pod 提供固定访问入口（ClusterIP/NodePort/LoadBalancer）
Ingress	HTTP(S) 路由规则管理器，提供外部访问入口（需配合 Ingress Controller）

3. 配置与存储

资源类型	用途
ConfigMap	存储非敏感配置（如环境变量）
Secret	存储敏感数据（如密码、TLS 证书）
PersistentVolume (PV)	集群存储资源（如云磁盘、NFS）
PersistentVolumeClaim (PVC)	Pod 申请存储资源的“需求单”

四、核心特性

声明式 API
用户定义期望状态（如 YAML 文件），K8s 自动驱动集群向目标状态迁移。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3  # 期望状态：3个副本
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25

自愈能力（Self-healing）
自动重启故障容器、替换不可用节点、重新调度 Pod。
水平自动扩缩（HPA）
根据 CPU/内存或自定义指标自动调整 Pod 数量：
```
kubectl autoscale deployment nginx-deploy --cpu-percent=50 --min=2 --max=10
```
服务发现与负载均衡
Service 通过标签选择器关联 Pod，并提供内部 DNS 名称（如 my-svc.my-namespace.svc.cluster.local）。
滚动更新与回滚
逐步替换旧版本 Pod，失败时可一键回滚：
```
kubectl rollout undo deployment/nginx-deploy
```

五、典型工作流

用户提交 YAML 到 kube-apiserver
etcd 存储资源定义
kube-scheduler 为 Pod 选择节点
目标节点 kubelet 拉取镜像并启动容器
kube-controller-manager 监控状态并确保符合预期
kube-proxy 配置 Service 的访问规则
Ingress Controller 处理外部流量路由

六、生态工具

类别	主流工具
集群部署	kubeadm, kops, RKE, EKS/AKS/GKE（托管服务）
网络插件	Calico, Flannel, Cilium, Weave Net
存储方案	Rook (Ceph), Longhorn, CSI 驱动（如 AWS EBS, GCP PD）
CI/CD集成	Argo CD, Flux, Jenkins, GitLab CI
监控日志	Prometheus + Grafana, EFK（Elasticsearch+Fluentd+Kibana）
服务网格	Istio, Linkerd, Consul Connect

七、学习建议路线

基础
- 掌握容器基础（Docker）
- 理解 Pod/Deployment/Service 核心概念
- 编写 YAML 文件部署应用
进阶
- 深入网络（CNI）、存储（PV/PVC）原理
- 配置 HPA、Resource Quotas
- 使用 Helm 管理应用模板
生产实践
- 集群高可用部署
- 安全加固（RBAC、Network Policies）
- 备份恢复（Velero）

💡 推荐实践：

本地环境：Minikube / Kind
线上实验：Play with Kubernetes (PWK)
认证考试：CKA（Kubernetes 认证管理员）

八、适用场景 vs 不适用场景

适合 Kubernetes 的场景	不建议使用的场景
微服务架构应用	单体应用（过度复杂化）
需要快速扩展的 Web 服务	对资源极度敏感的应用（如 HPC）
多环境（Dev/Test/Prod）统一管理	无状态且无需编排的简单任务
混合云/多云部署	缺乏容器化经验的团队