信创 AI 智能运维 + K8s 快速排障（新手级超详细教程）

倔强的胖蚂蚁

484人浏览 · 2026-03-05 11:12:20

倔强的胖蚂蚁 · 2026-03-05 11:12:20 发布

适用人群：K8s 新手、运维工程师、开发工程师、IT 管理人员

适用环境：信创合规环境（国产芯片 / OS / 中间件）

1 基础认知

1.1 什么是信创？（信息技术应用创新）

1.1.1 核心定义

信创是 “自主可控、安全合规” 的 IT 底层体系重构，旨在替代国外软硬件，保障国家信息技术安全。简单说：用国产的芯片、系统、软件，搭建安全可靠的 IT 环境。

1.1.2 信创核心组成

层级	国产代表产品	作用
芯片	鲲鹏（华为）、飞腾、海光	服务器 / 终端的 “大脑”
操作系统	麒麟 OS、统信 UOS、欧拉 OS	管理硬件资源的基础软件
容器 / 云原生	国产 K8s 发行版（华为云 CCE、欧拉 K8s）	容器编排、调度的核心平台
数据库	达梦、人大金仓、巨杉	存储业务数据的软件
中间件	宝兰德、东方通	衔接应用与底层资源的工具

1.1.3 信创环境的关键要求

自主可控：核心技术国产化，无国外技术依赖
安全合规：满足等保 2.0 三级 / 四级、信创名录要求
兼容性：软硬件之间相互适配（如芯片→OS→K8s→应用）

1.2 什么是 AI 智能运维（AIOps）？

1.2.1 核心定义

AI 智能运维是 “AI 技术 + 运维流程” 的结合，用机器学习、大模型替代人工重复工作，实现故障的自动发现、自动定位、自动修复。

1.2.2 AIOps 能解决什么问题？（新手痛点）

人工排障慢：传统运维靠 “猜 + 查日志”，新手可能几小时找不到问题
告警风暴：几千条告警分不清主次，关键故障被淹没
夜间故障：没人值守导致业务中断时间延长
经验依赖：老运维离职带走排障经验，新手无从下手

1.2.3 信创版 AIOps 的核心能力

数据采集：自动收集 K8s 集群的指标（CPU / 内存）、日志、事件、链路数据
异常检测：AI 模型识别 “正常 vs 异常”（如突然 CPU 飙升）
根因分析：大模型（ChatGLM/Qwen 国产版）自动分析日志，定位问题根源
故障自愈：自动执行修复脚本（如重启服务、迁移 Pod）
合规审计：所有操作留痕，满足信创审计要求

1.3 什么是 K8s？为什么需要排障？

1.3.1 K8s 核心定义

K8s（Kubernetes）是容器编排平台，简单说：管理大量容器的 “管家”，负责容器的启动、调度、扩容、故障恢复。

1.3.2 K8s 核心组件（新手必须认识）

组件	作用	地位
控制平面	apiserver、etcd、scheduler、controller-manager	集群 “大脑”，管理决策
节点（Node）	运行容器的服务器（物理机 / 虚拟机）	集群 “手脚”，执行任务
Pod	最小部署单元（1 个或多个容器）	应用运行的 “房子”
Service	暴露 Pod 网络访问（固定地址）	应用的 “入口”
Ingress	外部访问集群的统一入口（域名）	集群的 “大门”
PVC/PV	存储资源申请 / 分配	应用的 “仓库”

1.3.3 K8s 故障的 4 个层级

K8s 故障从底层到上层分为 4 类，排障需 “从下到上” 排查：

节点层（Node）：节点宕机、kubelet 服务停止
控制平面层：apiserver 超时、etcd 数据损坏
工作负载层（Pod/Deployment）：Pod 启动失败、反复崩溃
网络 / 存储层：Service 不通、PVC 挂载失败

1.4 信创 + AI + K8s 快速排障的核心价值

合规达标：满足信创名录、等保 2.0 要求，避免政策风险
效率翻倍：新手也能 10 分钟定位故障（传统运维可能 1 小时 +）
降低门槛：AI 给出 “傻瓜式” 修复步骤，不用记复杂命令
业务稳定：故障自愈减少人工干预，业务中断时间缩短 90%
成本降低：减少运维人力投入，避免故障导致的经济损失

2 核心配置

2.1 信创环境基础配置（前置准备，必须做）

2.1.1 服务器硬件要求（信创标准）

芯片：鲲鹏 920/930、飞腾 2000+/6000
内存：最小 8G（生产环境 16G+）
磁盘：SSD 100G+（系统盘）+ 数据盘 200G+
操作系统：麒麟 OS V10、统信 UOS Server、欧拉 OS 22.03

2.1.2 基础配置步骤（逐步操作）

步骤 1：关闭 Swap 分区（K8s 强制要求）

查看 Swap 状态：

free -h # 若 Swap 行数值不为0，说明已开启

临时关闭 Swap

swapoff -a # 立即生效，重启后失效

永久关闭 Swap（修改配置文件）：

vi /etc/fstab # 编辑配置文件

在文件中找到含 “swap” 的行，在行首加 “#” 注释（如：# /dev/mapper/centos-swap swap）
保存退出：按 Esc → 输入 :wq → 回车
验证：reboot 重启服务器后，执行 free -h，Swap 行数值为 0 即可

步骤 2：配置时钟同步（避免时间不一致导致故障）

安装 chrony 服务（信创 OS 默认自带，无则安装）：

yum install chrony -y # 麒麟/欧拉OS用yum；统信用apt install chrony -y

启动并设置开机自启：

systemctl start chronyd

systemctl enable chronyd

同步时间：

chronyc sources # 查看同步源

chronyc sync # 手动同步

验证：date 命令查看时间，与北京时间一致即可

步骤 3：关闭防火墙 / 放行 K8s 端口（信创环境安全配置）

方式 1：直接关闭防火墙（测试环境用）

systemctl stop firewalld

systemctl disable firewalld

方式 2：放行 K8s 必需端口（生产环境用）

# 控制平面节点（apiserver等）

firewall-cmd --permanent --add-port=6443/tcp # apiserver端口

firewall-cmd --permanent --add-port=2379-2380/tcp # etcd端口

firewall-cmd --permanent --add-port=10250/tcp # kubelet端口

firewall-cmd --permanent --add-port=10251/tcp # scheduler端口

firewall-cmd --permanent --add-port=10252/tcp # controller-manager端口

# 工作节点（Node）

firewall-cmd --permanent --add-port=10250/tcp # kubelet端口

firewall-cmd --permanent --add-port=30000-32767/tcp # NodePort端口

# 生效配置

firewall-cmd --reload

步骤 4：内核参数优化（信创 OS 适配 K8s）

编辑内核配置文件：

vi /etc/sysctl.d/k8s.conf

粘贴以下内容（直接复制）：

net.bridge.bridge-nf-call-iptables = 1

net.bridge.bridge-nf-call-ip6tables = 1

net.ipv4.ip_forward = 1 # 开启IP转发

net.ipv4.tcp_tw_recycle = 0

vm.swappiness = 0 # 禁用Swap

fs.inotify.max_user_watches = 89100

net.ipv4.neigh.default.gc_thresh1 = 1024

net.ipv4.neigh.default.gc_thresh2 = 2048

net.ipv4.neigh.default.gc_thresh3 = 4096

生效配置：

sysctl --system # 立即生效

验证：

sysctl -a | grep net.ipv4.ip_forward # 输出1即可

2.2 K8s 核心组件安装（信创兼容版，逐步操作）

2.2.1 安装容器引擎（containerd，信创推荐）

步骤 1：安装 containerd

yum install containerd.io -y # 麒麟/欧拉OS；统信用apt install containerd.io -y

步骤 2：配置 containerd （适配 K8s）

生成默认配置文件

containerd config default > /etc/containerd/config.toml

编辑配置文件：

vi /etc/containerd/config.toml

修改 3 处关键配置（新手搜索关键词定位）：

找到 SystemdCgroup，改为 SystemdCgroup = true（兼容系统）

找到 sandbox_image，改为国产镜像（默认是国外镜像，信创环境不通）：

sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.9"

找到 registry.mirrors，添加国内镜像源（加速拉取）：

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]

endpoint = ["https://registry.docker-cn.com"]

重启 containerd 并设置开机自启：

systemctl restart containerd

systemctl enable containerd

验证：

containerd --version # 显示版本即成功

2.2.2 安装 K8s 组件（kubeadm/kubelet/kubectl）

步骤 1：配置 K8s yum 源（信创兼容）

创建源文件：

vi /etc/yum.repos.d/kubernetes.repo

粘贴以下内容（新手直接复制）：

[kubernetes]

name=Kubernetes

baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-$basearch/

enabled=1

gpgcheck=1

repo_gpgcheck=1

gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

exclude=kubelet kubeadm kubectl

清理并更新 yum 缓存：

yum clean all && yum makecache

步骤 2：安装 K8s 组件

yum install -y kubelet-1.26.0 kubeadm-1.26.0 kubectl-1.26.0 --disableexcludes=kubernetes

（说明：1.26.0 是信创环境稳定版，新手不建议用最新版）

步骤 3：启动 kubelet 并设置开机自启

systemctl start kubelet

systemctl enable kubelet

步骤 4：初始化 K8s 集群（控制平面节点执行）

初始化命令（指定国产镜像源，新手直接复制）：

kubeadm init \

--image-repository registry.aliyuncs.com/google_containers \

--kubernetes-version v1.26.0 \

--pod-network-cidr=10.244.0.0/16 \

--service-cidr=10.96.0.0/12

等待 5-10 分钟，出现以下提示说明初始化成功：

Your Kubernetes control-plane has initialized successfully!

配置 kubectl 权限（让当前用户能操作 K8s）：

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

验证：

kubectl get nodes # 显示控制平面节点，状态为 NotReady（未安装网络插件）

2.2.3 安装 CNI 网络插件（Calico，信创兼容）

步骤 1：下载 Calico 配置文件（国内源）

wget https://docs.projectcalico.org/v3.25/manifests/calico.yaml # 若wget不存在，先装：yum install wget -y

步骤 2：修改配置文件（适配 Pod 网段）

编辑文件：

vi calico.yaml

找到 CALICO_IPV4POOL_CIDR，改为初始化 K8s 时指定的 pod-network-cidr（10.244.0.0/16）：

- name: CALICO_IPV4POOL_CIDR

value: "10.244.0.0/16"

安装 Calico：

kubectl apply -f calico.yaml

验证：

kubectl get pods -n kube-system # 所有 calico-xxx Pod 状态为 Running 即可

kubectl get nodes # 节点状态变为 Ready（成功）

2.2.4 安装监控 / 日志 / 告警组件（信创兼容）

组件	安装步骤（新手直接复制命令）
Prometheus（监控）	kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.64.0/bundle.yaml
Grafana（可视化）	kubectl apply -f https://raw.githubusercontent.com/grafana/grafana/main/conf/kubernetes/grafana.yaml
Loki（日志）	kubectl apply -f https://raw.githubusercontent.com/grafana/loki/v2.8.0/production/kubernetes/loki.yaml
Alertmanager（告警）	随 Prometheus 自动安装，无需额外操作

2.3 AI 智能运维平台配置（信创版）

2.3.1 选择信创兼容的 AI 运维平台（推荐）

开源选型：ChatGLM-4 + Prometheus + Alertmanager + 自定义自愈脚本
商业选型：华为云 AIOps、阿里云 ARMS（信创版）、深信服 AI 运维平台

2.3.2 核心配置步骤（以开源版为例）

步骤 1：部署本地私有化大模型（ChatGLM-6B）

安装依赖：

pip3 install torch transformers sentencepiece accelerate

下载模型（信创环境内网部署，需提前下载离线包）：

git clone https://github.com/THUDM/ChatGLM-6B.git

cd ChatGLM-6B

启动模型服务：

python3 web_demo.py --model-path ./ --listen 0.0.0.0 # 局域网可访问

步骤 2：配置数据接入（让 AI 能获取 K8s 数据）

安装 Prometheus 数据导出器：

kubectl apply -f https://raw.githubusercontent.com/prometheus/node-exporter/v1.6.1/deployments/kubernetes/node-exporter.yaml

配置 Loki 日志采集：

# 创建日志采集规则

vi loki-promtail.yaml

粘贴以下内容（采集所有 Pod 日志）：

apiVersion: v1

kind: ConfigMap

metadata:

namespace: kube-system

data:

promtail.yaml: |

server:

http_listen_port: 3101

clients:

- url: http://loki:3100/loki/api/v1/push

scrape_configs:

- job_name: kubernetes-pods

kubernetes_sd_configs:

- role: pod

relabel_configs:

- source_labels: [__meta_kubernetes_pod_label_app]

action: replace

target_label: app

- source_labels: [__meta_kubernetes_namespace]

action: replace

target_label: namespace

---

apiVersion: apps/v1

kind: DaemonSet

metadata:

namespace: kube-system

spec:

selector:

matchLabels:

app: promtail

template:

metadata:

labels:

app: promtail

spec:

containers:

- name: promtail

image: grafana/promtail:v2.8.0

args:

- -config.file=/etc/promtail/promtail.yaml

volumeMounts:

- name: config

mountPath: /etc/promtail

- name: varlog

mountPath: /var/log

volumes:

- name: config

configMap:

- name: varlog

hostPath:

path: /var/log

应用配置：

kubectl apply -f loki-promtail.yaml

步骤 3：配置 AI 异常检测与自愈

编写异常检测规则（如 CPU 使用率 > 80% 触发告警）：

vi ai-alert-rule.yaml

粘贴内容：

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

namespace: monitoring

spec:

groups:

- name: ai.rules

rules:

- alert: HighCpuUsage

expr: avg(rate(node_cpu_usage[5m])) by (instance) > 0.8

for: 5m

labels:

severity: critical

annotations:

summary: "节点 CPU 使用率过高"

description: "节点 {{ $labels.instance }} CPU 使用率超过 80%，持续 5 分钟"

应用规则：

kubectl apply -f ai-alert-rule.yaml

配置 AI 自愈脚本（如 CPU 过高自动重启相关 Pod）：

# 创建自愈脚本 ConfigMap

vi ai-self-heal.yaml

粘贴内容：

apiVersion: v1

kind: ConfigMap

metadata:

namespace: kube-system

data:

restart-high-cpu-pods.sh: |

#!/bin/bash

# 获取 CPU 使用率前 3 的 Pod

PODS=$(kubectl top pods -A --sort-by=cpu | tail -n 3 | awk '{print $2,"-n",$1}')

# 重启 Pod

for POD in $PODS; do

kubectl delete pod $POD --grace-period=0 --force

done

应用配置：

kubectl apply -f ai-self-heal.yaml

关联 AI 模型与自愈脚本（通过 Alertmanager webhook）：

编辑 Alertmanager 配置，添加 webhook 指向自愈脚本执行服务大模型

接收告警后，自动调用脚本执行修复

2.4 排障必备工具与命令（必须背会 + 会用）

2.4.1 核心工具

kubectl：K8s 命令行工具（操作集群的唯一入口）
journalctl：查看系统服务日志（如 kubelet）
systemctl：管理系统服务（启动 / 停止 / 重启）
AI 运维平台：可视化界面 + 自动排障（新手优先用）

2.4.2 4 个核心命令（新手每天用，详细解释）

命令	作用	详细解释	示例
kubectl get -o wide	查看资源状态	-A：所有命名空间；-o wide：显示详细信息	kubectl get pods -A -o wide（查看所有 Pod）
kubectl describe <资源类型> >	查看资源详细事件（排障关键）	输出资源的创建过程、错误事件、配置信息	kubectl describe pod nginx-xxx（查看 Pod 事件）
kubectl logs 容器名] [-f]	查看 Pod 日志	-c：多容器时指定容器；-f：实时跟踪日志	kubectl logs nginx-xxx -f（实时看日志）
kubectl exec -it /bin/bash	进入 Pod 容器内部（调试）	-it：交互式终端；--：分隔命令与参数	kubectl exec -it nginx-xxx -- /bin/bash

2.4.3 辅助命令（新手常用）

# 查看节点详情

kubectl get nodes -o wide

# 查看 Service （暴露的服务）

kubectl get svc -A

# 查看 PVC （存储）

kubectl get pvc -A

# 查看命名空间

kubectl get ns

# 强制删除 Pod（卡死后用）

kubectl delete pod -n --grace-period=0 --force

# 查看 kubelet 日志（节点故障用）

journalctl -u kubelet -f

# 查看集群信息

kubectl cluster-info

3 实操场景（12 个高频排障，步骤超详细）

场景 1：Node 状态 NotReady（节点不可用，最常见）

现象

执行 kubectl get nodes 后，节点状态显示 NotReady，Pod 无法调度到该节点。

排障步骤

步骤 1：查看节点状态，确认问题节点

kubectl get nodes # 示例输出：node-1 NotReady 10m v1.26.0

步骤 2：查看节点详细事件，定位原因

kubectl describe node node-1 # node-1 是问题节点名

重点看输出的 Conditions 部分（如 DiskPressure、MemoryPressure）
重点看输出的 Events 部分（底部），红色错误信息是关键

步骤 3：登录问题节点，检查 kubelet 服务状态

# 登录节点（通过 SSH 或服务器控制台）

ssh root@node-1-ip # node-1-ip 是节点IP

# 查看 kubelet 服务状态

systemctl status kubelet

若显示 inactive (dead)：说明 kubelet 服务停止
若显示 active (running)：但节点仍 NotReady，继续下一步

步骤 4：查看 kubelet 日志，找错误原因

journalctl -u kubelet -f # -f 实时跟踪日志

常见错误关键词：out of memory（内存不足）、disk full（磁盘满）、CNI network error（网络插件异常）

步骤 5：针对性解决（按常见原因分类）

原因 1：磁盘满（最常见）

查看磁盘使用情况：

df -h # 查看所有磁盘，找到使用率 100% 的分区（如 / 分区）

清理磁盘（删除无用文件 / 日志）：

# 删除 /var/log 下的旧日志（保留3天内的）

find /var/log -type f -mtime +3 -delete

# 删除 K8s 旧镜像（谨慎操作）

crictl rmi $(crictl images -q) # 需安装 crictl：yum install cri-tools -y

重启 kubelet：

systemctl restart kubelet

验证：kubectl get nodes，节点状态变为 Ready

原因 2：内存打满

查看内存使用：

free -h # 若 used 接近 total，说明内存满

查看占用内存最高的进程：

top # 按 Shift+M 排序，找到占用高的进程（如无用的应用）

杀死无用进程：

kill -9 # 进程ID 从 top 命令中获取

重启 kubelet：systemctl restart kubelet

原因 3：kubelet 服务异常

重启 kubelet：

systemctl restart kubelet

若重启失败，查看配置文件：

vi /etc/kubernetes/kubelet.conf # 检查配置文件是否有误

重置 kubelet 配置（极端情况）：

kubeadm reset

systemctl restart kubelet

原因 4：CNI 网络插件（Calico）异常

查看 Calico Pod 状态：

kubectl get pods -n kube-system | grep calico

若 Calico Pod 未 Running，重启 Calico：

kubectl delete pods -n kube-system -l k8s-app=calico-node # 自动重建

验证：等待 2-3 分钟，kubectl get nodes 状态变为 Ready

AI 自动排障动作

AI 平台自动检测节点 NotReady，触发告警
自动登录节点，执行 df -h、free -h、systemctl status kubelet 检查
自动识别原因（如磁盘满），执行清理脚本
自动重启 kubelet，恢复节点状态
发送恢复通知到运维群

场景 2：Pod 一直 Pending（调度失败，新手常遇）

现象

执行 kubectl get pods -n 空间>，Pod 状态一直是 Pending，READY 列显示 0/1。

排障步骤

步骤 1：查看 Pod 详细事件（关键步骤）

kubectl describe pod <pod名> -n <命名空间> # 替换为实际 Pod 名和命名空间

重点看输出的 Events 部分（底部），红色错误信息直接提示原因

步骤 2：根据 Events 提示，针对性排查（常见原因）

原因 1：资源不足（节点没有足够的 CPU / 内存）

Events 提示：0/3 nodes are available: 3 Insufficient cpu.（3 个节点都 CPU 不足）

解决步骤：

查看节点资源使用情况：

kubectl top nodes # 查看每个节点的 CPU/内存使用

方法 1:

调整 Pod 资源请求（减少 CPU / 内存）

编辑 Pod 配置文件：

kubectl edit pod 名> -n 空间>

找到 resources.requests 部分，降低数值：

resources:

requests:

cpu: "100m" # 从 500m 改为 100m（1核=1000m）

memory: "256Mi" # 从 1Gi 改为 256Mi

保存退出（按 Esc → :wq → 回车）

方法 2：扩容节点（增加新的节点，提供更多资源）

验证：kubectl get pods，Pod 状态变为 Running

原因 2：节点污点（Taint）导致调度排斥

Events 提示：0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.（控制平面节点有污点，Pod 不兼容）

解决步骤：

查看节点污点：

kubectl describe node > | grep Taint

方法 1:

给 Pod 添加容忍（Toleration）

编辑 Pod 配置：

kubectl edit pod > -n >

在 spec 下添加容忍配置：

tolerations:

- key: "node-role.kubernetes.io/control-plane"

operator: "Exists"

effect: "NoSchedule"

保存退出

方法 2：删除节点污点（不推荐控制平面节点）

kubectl taint nodes role.kubernetes.io/control-plane:NoSchedule-

验证：Pod 开始调度，状态变为 Running

原因 3：亲和性 / 反亲和性冲突

Events 提示：0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity rules.

解决步骤：

查看 Pod 的亲和性配置：

kubectl get pod n o yaml | grep -A 20 "affinity:"

检查配置的亲和性标签（如 app: redis）是否有节点匹配：

kubectl get nodes -l app:redis # 若没有节点输出，说明无匹配节点

修改亲和性配置（删除或调整标签）：

kubectl edit pod -n

保存退出，Pod 重新调度

AI 自动排障动作

自动解析 kubectl describe pod 的 Events 日志
自动检测是资源不足 / 污点 / 亲和性问题
推荐解决方案（如调整资源请求、添加容忍）
一键执行修复（如自动编辑 Pod 配置）

场景 3：ImagePullBackOff（镜像拉取失败，高频）

现象

Pod 状态显示 ImagePullBackOff 或 ErrImagePull，执行 kubectl describe pod 提示镜像拉取失败。

排障步骤

步骤 1：查看镜像拉取错误详情

kubectl describe pod 名> -n 空间> | grep -A 10 "Failed to pull image"

错误示例 1：Error: ImagePullBackOff: failed to pull image "nginx:1.250": 镜像 tag 不存在

错误示例 2：Error: ImagePullBackOff: failed to resolve image "harbor.example.com/app/nginx:v1": no available registry endpoint: 仓库不通

错误示例 3：Error: ImagePullBackOff: unauthorized: authentication required: 缺少仓库密钥

步骤 2：针对性解决（按错误类型）

错误类型 1：镜像地址 / Tag 错误

解决步骤：

确认正确的镜像地址和 Tag：

询问开发人员，或查看镜像仓库（如 Harbor、Docker Hub）

编辑 Pod 配置，修改镜像地址：

kubectl edit pod ```

找到 image: 字段，替换为正确地址（如 nginx:1.25 而非 nginx:1.250）：

spec:

containers:

- name: nginx

image: nginx:1.25 # 正确的镜像+Tag

保存退出，Pod 自动重新拉取镜像

错误类型 2：镜像仓库网络不通

解决步骤：

进入任意正常运行的 Pod，测试仓库连通性：

kubectl exec -it n /bin/bash

# 在 Pod 内执行 ping 或 curl（需安装：apt install curl -y 或 yum install curl -y）

curl -I https://harbor.example.com # 替换为镜像仓库地址

若不通，检查网络配置：

节点防火墙是否放行仓库端口（如 80/443）

集群是否能访问外网（公网镜像）或内网仓库

放行端口（节点上执行）：

firewall-cmd --permanent --add-port=443/tcp

firewall-cmd --reload

重新拉取镜像：

kubectl delete pod > -n > # 重建 Pod

错误类型 3：缺少镜像仓库密钥（私有仓库）

解决步骤：

创建仓库密钥（用户名 / 密码是镜像仓库的登录凭证）：

kubectl create secret docker-registry > \

--docker-server=harbor.example.com \ # 镜像仓库地址

--docker-username=admin \ # 仓库用户名

--docker-password=123456 \ # 仓库密码

--docker-email=admin@example.com -n 空间>

编辑 Pod 配置，关联密钥：

kubectl edit pod <pod名> -n <命名空间>

在 spec 下添加 imagePullSecrets：

spec:

imagePullSecrets:

- name: > # 第一步创建的密钥名

containers:

- name: nginx

image: harbor.example.com/app/nginx:v1

保存退出，Pod 自动使用密钥拉取镜像

AI 自动排障动作

自动校验镜像地址格式、Tag 有效性
自动测试镜像仓库连通性
自动检测是否缺少密钥，若缺少则提示创建命令
一键关联密钥到 Pod，重新拉取镜像

场景 4：CrashLoopBackOff（Pod 启动后立即崩溃，反复重启）

现象

Pod 状态显示 CrashLoopBackOff，RESTARTS 列数值不断增加（如 5/5 表示重启 5 次）。

排障步骤

步骤 1：查看 Pod 日志（关键，找崩溃原因）

# 查看当前日志

kubectl logs -n

# 查看上一次启动的日志（当前日志可能为空）

kubectl logs n previous

常见日志错误：

Error: unable to open config file: /etc/app/config.yaml: no such file or directory（配置文件缺失）

FATAL: port 8080 already in use（端口占用）

Traceback (most recent call last): ...（Python 代码错误）

OutOfMemoryError（内存不足，OOM）

步骤 2：进入 Pod 调试（若能短暂启动）

# 若 Pod 能启动几秒，用 --rm 临时启动一个调试容器

kubectl run -it --rm --image=<Pod镜像> -- /bin/bash

# 在容器内检查：配置文件是否存在、端口是否被占用、依赖是否安装

ls /etc/app/config.yaml # 检查配置文件

netstat -tulpn | grep 8080 # 检查端口（需安装 net-tools：yum install net-tools -y）

步骤 3：针对性解决（常见原因）

原因 1：配置文件缺失 / 错误

解决步骤：

确认配置文件是否通过 ConfigMap/Secret 挂载：

kubectl get configmap -n # 查看是否有对应的 ConfigMap

kubectl get secret -n <命名空间> # 查看是否有对应的 Secret

检查 Pod 配置是否挂载了 ConfigMap/Secret：

kubectl get pod yaml | grep -A 10 "volumeMounts:"

若未挂载，编辑 Pod 配置添加挂载：

kubectl edit pod n ```

示例挂载 ConfigMap：

spec:

volumes:

- name: app-config

configMap:

containers:

- name: app

image: app:v1

volumeMounts:

- name: app-config

mountPath: /etc/app # 配置文件挂载到容器内的路径

保存退出，Pod 重新启动

原因 2：端口占用

解决步骤：

查看 Pod 配置的端口：

kubectl get pod n o yaml | grep "containerPort:"

检查同一节点上是否有其他 Pod 占用该端口：

# 先找到 Pod 所在节点

kubectl get pod -n -o wide | awk '{print $7}' # 第7列是节点名

# 登录节点，查看端口占用

ssh root@IP>

netstat -tulpn | grep ```

若占用，修改 Pod 端口：

kubectl edit pod n ```

找到 containerPort，改为未占用的端口：

containers:

- name: app

image: app:v1

ports:

- containerPort: 8081 # 从 8080 改为 8081

保存退出

原因 3：代码错误（开发问题）

解决步骤：

将日志信息发送给开发人员，确认代码问题

开发修复后，推送新的镜像（如 app:v2）

更新 Pod 镜像：

kubectl set image pod/<pod名> 名>=app:v2 -n

验证：Pod 启动成功，状态变为 Running

AI 自动排障动作

自动分析日志关键词，定位崩溃原因（配置缺失 / 端口占用 / 代码错误）
自动检查 ConfigMap/Secret 挂载情况
自动检测端口占用情况
推荐修复方案（如添加挂载、修改端口）

场景 5：OOMKilled（内存溢出，Pod 被 K8s 杀死）

现象

Pod 状态显示 OOMKilled，RESTARTS 增加，执行 kubectl describe pod 提示 Reason: OOMKilled。

排障步骤

步骤 1：确认 OOM 原因

kubectl describe pod -n | grep -A 5 "OOMKilled"

输出示例：State: Terminated, Reason: OOMKilled, Exit Code: 137（Exit Code 137 是 OOM 标志）

步骤 2：查看 Pod 内存配置和使用情况

查看 Pod 内存限制（limit）：

kubectl get pod -n -o yaml | grep -A 5 "resources:"

示例输出：

resources:

limits:

memory: "512Mi" # 内存限制 512M

requests:

memory: "256Mi"

查看 Pod 运行时内存使用：

kubectl top pods > -n >

若使用量接近或超过 limits，说明限制太小

步骤 3：解决方法（按优先级）

方法 1：临时调大内存限制（快速解决）

编辑 Pod 配置：

kubectl edit pod n ```

增加 limits.memory 数值：

resources:

limits:

memory: "1Gi" # 从 512Mi 改为 1Gi

requests:

memory: "512Mi"

保存退出，Pod 重建后验证

方法 2：优化应用程序（根本解决）

分析应用内存泄漏：
- 开启应用的内存监控（如 Java 应用用 JVM 参数 -XX:+HeapDumpOnOutOfMemoryError）
- 生成内存快照，发送给开发人员分析
- 开发修复内存泄漏问题，推送新镜像
- 更新 Pod 镜像：kubectl set image pod/<pod名> <容器名>=app:v2 -n >

方法 3：开启 Pod 重启策略（避免业务中断）

编辑 Pod 配置，设置自动重启：

kubectl edit pod 名> -n 空间>

在 spec 下添加：

spec:

restartPolicy: Always # 总是重启（默认值）

# 或设置为 OnFailure：只有失败时重启

AI 自动排障动作

自动识别 OOM 事件，分析内存使用趋势
推荐合理的内存限制数值（基于历史使用数据）
自动调整内存限制，重启 Pod
提醒开发人员检查内存泄漏

场景 6：Service 无法访问（ClusterIP/NodePort 不通）

现象

ClusterIP：Pod 正常运行，但通过 Service 的 ClusterIP 无法访问应用
NodePort：通过节点IP:NodePort 无法访问应用

排障步骤（从内到外排查）

步骤 1：确认 Pod 正常运行且能访问

查看 Pod 状态：

kubectl get pods <pod名> -n <命名空间> -o wide # 状态为 Running

进入同一命名空间的其他 Pod，测试访问目标 Pod 的 IP: 端口：

# 启动一个测试 Pod

kubectl run -it --rm --image=busybox:1.35 -- /bin/sh -n # 在测试 Pod 内执行 wget 或 curl

wget -q -O - IP>: # 如 wget -q -O - 10.244.1.5:8080

若访问失败：问题在 Pod 本身（应用未启动、端口错误）
若访问成功：问题在 Service 配置

步骤 2：检查 Service 配置（关键）

查看 Service 基本信息：

kubectl get svc wide

确认 TYPE（ClusterIP/NodePort）、CLUSTER-IP、PORT(S)（如 8080:30001/TCP，30001 是 NodePort）

查看 Service 详细配置：

kubectl describe svc n ```

- 重点看 `Selector`（标签选择器）：必须与 Pod 的标签一致

- 重点看 `Endpoints`：必须包含目标 Pod 的 IP:端口（为空则说明标签不匹配）

步骤 3：针对性解决（常见原因）

原因 1：Service Selector 标签不匹配（最常见）

解决步骤：

查看 Pod 的标签：

kubectl get pods 名> -n 空间> -o jsonpath='{.metadata.labels}'

示例输出：{"app":"my-app","version":"v1"}

查看 Service 的 Selector：

kubectl get svc <service名> -n <命名空间> -o jsonpath='{.spec.selector}'

示例输出：{"app":"my-app-v1"}（与 Pod 标签不一致）

编辑 Service，修正 Selector：

kubectl edit svc <service名> -n <命名空间>

修改 spec.selector 与 Pod 标签一致：

spec:

selector:

app: my-app # 与 Pod 的 app 标签一致

version: v1 # 可选，若 Pod 有该标签

验证：kubectl describe svc ，Endpoints` 显示 Pod IP: 端口

原因 2：Service 端口配置错误

解决步骤：

查看 Service 端口配置：

kubectl get svc > -n > -o yaml | grep -A 10 "ports:"

示例输出：

ports:

- name: http

port: 80 # Service 暴露的端口

targetPort: 8080 # Pod 内应用的端口（必须正确）

nodePort: 30001

确认 Pod 内应用的端口（与 targetPort 一致）：

或进入 Pod 执行 netstat -tulpn 查看应用监听端口

查看 Pod 配置的 containerPort若不一致，编辑 Service

修改 targetPort：

kubectl edit svc ```

保存退出，重新测试访问

原因 3：网络策略（NetworkPolicy）拦截

解决步骤：

查看命名空间下的网络策略：

kubectl get networkpolicy -n <命名空间>

查看网络策略是否拦截了访问：

kubectl describe networkpolicy n ```

临时删除网络策略测试（生产环境谨慎）：

kubectl delete networkpolicy ```

若能访问，说明策略拦截，需修改策略允许访问

AI 自动排障动作

自动校验 Service Selector 与 Pod 标签匹配度
自动检查 Endpoints 是否为空
自动测试 Pod IP: 端口、Service ClusterIP: 端口、NodeIP:NodePort 连通性
自动检测网络策略拦截，推荐修改方案

场景 7：Ingress 外部无法访问（域名不通）

安装 Ingress Controller（信创兼容版）：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

验证 Ingress Controller 运行：

kubectl get pods -n ingress-nginx # 状态为 Running 即可

测试域名解析与连通性

本地配置 hosts 文件（测试环境，生产环境需配置 DNS）：

Windows：编辑 C:\Windows\System32\drivers\etc\hosts

Linux/Mac：编辑 /etc/hosts添加内容：Ingress-ADDRESS

app.example.com（Ingress-ADDRESS 是 kubectl get ingress 输出的 ADDRESS）

测试域名访问：

curl http://app.example.com # 或用浏览器访问

若提示 404 Not Found：Ingress 规则配置错误

若提示 Connection refused：网络 / 端口问题

步骤 4：针对性解决（常见原因）

原因 1：Ingress 规则配置错误（Host/Path 错误）

解决步骤：

重新检查 Ingress 规则：

kubectl get ingress n o yaml

确认 3 点：

spec.rules.host：与访问的域名一致（如 app.example.com）

spec.rules.http.paths.path：与应用暴露的路径一致（如 / 或 /api）

spec.rules.http.paths.backend.service.name：后端 Service 名称正确

编辑 Ingress 修正规则：

kubectl edit ingress <ingress名> -n ```

示例正确配置：

spec:

rules:

- host: app.example.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80 # Service 暴露的端口

保存退出，重新测试访问

原因 2：Ingress Controller 端口未放行（生产环境）

解决步骤：

查看 Ingress Controller 暴露的端口：

kubectl get svc -n ingress-nginx # 通常是 80/TCP、443/TCP

节点放行端口（信创环境防火墙配置）：

firewall-cmd --permanent --add-port=80/tcp

firewall-cmd --permanent --add-port=443/tcp

firewall-cmd --reload

云环境需配置安全组：在云平台（如华为云、阿里云）的安全组中放行 80/443 端口

原因 3：SSL 证书错误（HTTPS 访问）

现象：浏览器提示 “证书无效” 或 curl: (60) SSL certificate problem

解决步骤：

查看 Ingress 配置：

kubectl get ingress > -n > -o yaml | grep -A 10 "tls:"

确认证书 Secret 存在且有效：

kubectl get secret <证书Secret名> -n 需是 kubernetes.io/tls 类型

重新创建证书 Secret（若证书过期 / 错误）：

kubectl create secret tls \

--cert=path/to/tls.crt \ # 公钥文件路径

--key=path/to/tls.key -n # 私钥文件路径

编辑 Ingress 关联证书：

kubectl edit ingress 名> -n 空间>

添加 tls 配置：

spec:

tls:

- hosts:

- app.example.com

secretName: 名> # 新创建的证书Secret

rules:

- host: app.example.com

# ... 其余规则不变

AI 自动排障动作

自动校验 Ingress 规则（Host/Path/Backend 匹配度）
自动检查 Ingress Controller 运行状态与端口放行
自动验证 SSL 证书有效性（过期时间、域名匹配）
一键生成正确的 Ingress 配置 YAML，支持直接应用

场景 8：PVC 一直 Pending（存储挂载失败）

现象

执行 kubectl get pvc -n >，PVC 状态一直为 Pending，无法绑定到 PV（PersistentVolume）。

排障步骤

步骤 1：查看 PVC 详细事件（关键）

kubectl describe pvc -n

常见 Events 提示：
- no persistent volumes available for this claim and no storage class is set：未指定 StorageClass，且无可用 PV
- storageclass.storage.k8s.io "standard" not found：指定的 StorageClass 不存在
- insufficient capacity：PV 容量不足

步骤 2：检查存储相关资源状态

查看 StorageClass（存储类）：

kubectl get sc # 列出所有可用的 StorageClass

若 PVC 指定了 storageClassName，需确认该 SC 存在且状态正常

查看可用 PV：

kubectl get pv # 状态为 Available 的 PV 才能被绑定

检查 PV 的容量、访问模式（AccessModes）是否与 PVC 匹配

步骤 3：针对性解决（常见原因）

原因 1：未指定 StorageClass 且无可用 PV

解决步骤：

方法 1：

创建 StorageClass（推荐，动态分配 PV）

编辑 SC 配置文件：

vi storageclass.yaml

粘贴信创兼容的 SC 配置（以 NFS 为例）：

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # 需提前安装 nfs-provisioner

parameters:

archiveOnDelete: "true"

reclaimPolicy: Delete # PV 回收策略

应用配置：

kubectl apply -f storageclass.yaml

方法 2：编辑 PVC，指定 StorageClass：

kubectl edit pvc n ```

在 spec 下添加 storageClassName：

spec:

storageClassName: nfs-sc # 与创建的 SC 名称一致

accessModes:

- ReadWriteOnce # 访问模式（需与 PV 匹配）

resources:

requests:

storage: 10Gi # 存储容量

保存退出，PVC 会自动绑定动态创建的 PV

原因 2：StorageClass 不存在或不可用

解决步骤：

确认 SC 名称是否正确：

kubectl get sc | grep <指定的SC名称> # 无输出则说明名称错误

若 SC 不存在，重新创建

若 SC 存在但不可用，查看 SC 事件：

kubectl describe sc ```

常见问题：provisioner 未安装（如 nfs-provisioner 未部署），需安装对应的 provisioner

原因 3：PV 容量不足或访问模式不匹配

解决步骤：

查看 PVC 要求的容量和访问模式：

kubectl get pvc <pvc名> -n <命名空间> -o yaml | grep -A 5 "spec:"

查看可用 PV 的容量和访问模式：

kubectl get pv -o custom-columns=NAME:.metadata.name,CAPACITY:.spec.capacity.storage,ACCESSMODES:.spec.accessModes

若容量不足：创建更大容量的 PV，或减少 PVC 的存储请求

若访问模式不匹配（如 PVC 要求 ReadWriteMany，PV 是 ReadWriteOnce）：

编辑 PVC 调整访问模式，或创建匹配

访问模式的 PV访问模式说明：

ReadWriteOnce（RWO）：只能被一个节点挂载读写

ReadOnlyMany（ROX）：可被多个节点挂载只读

ReadWriteMany（RWX）：可被多个节点挂载读写

AI 自动排障动作

自动检测 StorageClass 存在性与可用性
自动匹配 PVC 与 PV 的容量、访问模式
一键生成 StorageClass 和 PVC 修正配置
自动检查存储插件（如 nfs-provisioner）运行状态

场景 9：RBAC 权限不足（操作被拒绝）

现象

执行 kubectl 命令时提示 error: You must be logged in to the server (Unauthorized) 或 error: forbidden: User "xxx" cannot list pods in the namespace "default"。

排障步骤

步骤 1：确认当前用户身份与权限

查看当前 kubectl 配置的用户：

kubectl config view --minify -o jsonpath='{.users[0].name}'

测试具体权限（如查看 Pod 的权限）：

kubectl auth can-i list pods -n as= ```

- 输出 `no` 说明无该权限，`yes` 说明有权限

步骤 2：检查 RBAC 资源配置（Role/RoleBinding）

RBAC 权限控制通过 4 种资源实现：Role（命名空间内权限）、ClusterRole（集群级权限）、RoleBinding（绑定命名空间内权限）、ClusterRoleBinding（绑定集群级权限）。

查看命名空间内的 Role：

kubectl get roles -n <命名空间>

查看 RoleBinding（绑定 Role 到用户 / ServiceAccount）：

kubectl get rolebindings -n ```

查看集群级的 ClusterRole 和 ClusterRoleBinding：

kubectl get clusterroles

kubectl get clusterrolebindings

步骤 3：针对性解决（常见原因）

原因 1：缺少对应的 Role/RoleBinding

解决步骤：

创建 Role（定义命名空间内的权限）：

vi pod-reader-role.yaml

粘贴配置（允许查看 Pod）：

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: <命名空间>

rules:

- apiGroups: [""] # 核心API组（Pod、Service等）

resources: ["pods"] # 资源类型

verbs: ["get", "list", "watch"] # 允许的操作

应用 Role：

kubectl apply -f pod-reader-role.yaml

创建 RoleBinding（绑定 Role 到用户）：

vi pod-reader-binding.yaml

粘贴配置：

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

namespace: 空间>

subjects:

- kind: User

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: Role

apiGroup: rbac.authorization.k8s.io

应用 RoleBinding：

kubectl apply -f pod-reader-binding.yaml

验证权限：

kubectl auth can-i list pods -n as= 输出 yes

原因 2：使用 ServiceAccount 访问时权限不足

解决步骤：

查看 Pod 使用的 ServiceAccount：

kubectl get pod n o yaml | grep serviceAccountName

给 ServiceAccount 绑定 Role（修改 RoleBinding 的 subjects 类型）：

subjects:

- kind: ServiceAccount

namespace: ```

应用修改后的 RoleBinding：

kubectl apply -f pod-reader-binding.yaml

原因 3：需要集群级权限（如查看所有命名空间的 Pod）

解决步骤：

创建 ClusterRole（集群级权限）：

vi cluster-pod-reader.yaml

粘贴配置：

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

rules:

- apiGroups: [""]

resources: ["pods"]

verbs: ["get", "list", "watch"]

应用 ClusterRole：

kubectl apply -f cluster-pod-reader.yaml

创建 ClusterRoleBinding（绑定到用户）：

kubectl create clusterrolebinding cluster-pod-reader-binding \

--clusterrole=cluster-pod-reader \

--user=>

AI 自动排障动作

自动检测权限不足的操作对应的 RBAC 规则
一键生成最小权限的 Role/RoleBinding YAML
支持 ServiceAccount / 用户 / 组多种主体的权限绑定
权限验证自动化，生成验证命令

场景 10：DNS 解析失败（Pod 内无法解析域名）

现象

Pod 内执行 nslookup kubernetes.default 或 ping app-service 时提示 server can't find kubernetes.default: NXDOMAIN，无法解析 K8s 内部服务或外部域名。

排障步骤

步骤 1：在 Pod 内测试 DNS 解析

启动测试 Pod（busybox 镜像）：

kubectl run -it --rm dns-test --image=busybox:1.35 -- /bin/sh

测试解析 K8s 内部服务（kubernetes.default 是默认服务）：

nslookup kubernetes.default

正常输出：Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

异常输出：nslookup: can't resolve 'kubernetes.default'

步骤 2：检查 DNS 组件（coredns）状态

K8s 默认 DNS 组件是 coredns，运行在 kube-system 命名空间。

查看 coredns Pod 状态：

kubectl get pods -n kube-system | grep coredns

若状态不是 Running，说明 coredns 异常

查看 coredns 日志：

kubectl logs ns-pod名> -n kube-system

常见错误：error: failed to read from etcd: context deadline exceeded（etcd 连接异常）、no endpoints for service "coredns"（服务端点异常）

步骤 3：检查 Pod 的 DNS 配置

查看 Pod 的 /etc/resolv.conf 文件（DNS 配置文件）：

kubectl exec -it 名> -n 空间> -- cat /etc/resolv.conf

正常配置：包含 nameserver 10.96.0.10（coredns 的 ClusterIP）、search default.svc.cluster.local svc.cluster.local cluster.local

异常配置：缺少 nameserver 或 search 字段

步骤 4：针对性解决（常见原因）

原因 1：coredns 未运行或崩溃

解决步骤：

重启 coredns Pod（自动重建）：

kubectl delete pods -n kube-system -l k8s-app=coredns

若重启后仍异常，检查 coredns 配置：

kubectl edit configmap coredns -n kube-system

确保配置正确（默认配置）：

data:

Corefile: |

.:53 {

errors

health {

lameduck 5s

}

ready

kubernetes cluster.local in-addr.arpa ip6.arpa {

pods insecure

fallthrough in-addr.arpa ip6.arpa

ttl 30

}

prometheus :9153

forward . /etc/resolv.conf {

max_concurrent 1000

}

cache 30

loop

reload

loadbalance

}

保存退出，重启 coredns

原因 2：网络策略拦截 DNS 流量

解决步骤：

查看命名空间下的网络策略：

kubectl get networkpolicy -n ```

检查是否有策略拦截 53 端口（DNS 端口）：

kubectl describe networkpolicy 名> -n 空间>

创建允许 DNS 流量的网络策略：

vi allow-dns.yaml

粘贴配置：

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

namespace: spec:

podSelector: {} # 应用于命名空间内所有 Pod

policyTypes:

- Egress

egress:

- to:

- namespaceSelector:

matchLabels:

kubernetes.io/metadata.name: kube-system # 允许访问 kube-system 命名空间（coredns 所在）

ports:

- protocol: UDP

port: 53 # DNS UDP 端口

- protocol: TCP

port: 53 # DNS TCP 端口

应用策略：

kubectl apply -f allow-dns.yaml

原因 3：Pod 的 DNS 策略配置错误

解决步骤：

查看 Pod 的 DNS 策略：

kubectl get pod -n -o yaml | grep -A 5 "dnsPolicy:"

若 dnsPolicy 为 None（无 DNS 配置），修改为默认的 ClusterFirst：

kubectl edit pod > -n >

修改 spec.dnsPolicy：

spec:

dnsPolicy: ClusterFirst # 优先使用集群 DNS（coredns）

保存退出，Pod 重建后测试 DNS 解析

AI 自动排障动作

自动检测 coredns 运行状态与日志错误
自动测试 Pod 内 DNS 解析连通性
自动识别网络策略对 DNS 端口的拦截
一键修复 coredns 配置或网络策略

场景 11：etcd 异常（控制平面故障，集群不可用）

现象

执行 kubectl 命令超时：kubectl get pods 提示 The connection to the server xxx:6443 was refused - did you specify the right host or port?
控制平面 Pod 异常：kubectl get pods -n kube-system 中 etcd-xxx、kube-apiserver-xxx 状态异常

排障步骤

步骤 1：检查 etcd 服务状态（控制平面节点）

登录控制平面节点（etcd 运行在控制平面）：

ssh root@>

查看 etcd 服务状态（容器化部署，通过 crictl 查看）：

crictl ps | grep etcd # 查看 etcd 容器

crictl logs > # 查看 etcd 日志

若 etcd 未运行，查看 kubelet 日志（控制平面组件由 kubelet 管理）：

journalctl -u kubelet -f | grep etcd

步骤 2：检查 etcd 数据目录与磁盘空间

etcd 数据目录默认在 /var/lib/etcd，磁盘满会导致 etcd 异常。

查看磁盘空间：

df -h /var/lib/etcd # 查看 etcd 数据目录所在分区

若磁盘使用率 > 90%，清理磁盘（谨慎操作）：

# 删除 etcd 旧快照（保留最近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 \

snapshot list | grep -v latest | head -n -3 | awk '{print $1}' | xargs -I {} etcdctl snapshot delete {}

压缩 etcd 数据（减少磁盘占用）：

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 \

compact $(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 status --write-out=json | jq -r '.[] | .header.revision')

碎片整理：

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 \

defrag

步骤 3：检查 etcd 集群健康状态（多节点 etcd 集群）

执行健康检查命令：

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

正常输出：https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 1.234ms

若节点不健康，查看 etcd 集群成员：

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 \

member list

移除异常成员（若有）：

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 \

member remove ```

步骤 4：恢复 etcd 数据（数据损坏时）

找到 etcd 快照文件（默认路径 /var/lib/etcd/snapshots）：

ls /var/lib/etcd/snapshots

停止 kube-apiserver 服务（恢复期间需停止访问 etcd）：

systemctl stop kubelet # kube-apiserver 是容器化，停止 kubelet 会停止容器

恢复数据：

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 \

snapshot restore db \

--data-dir=/var/lib/etcd-restore \

--name=master \

--initial-cluster=master=https://节点IP>:2380 \

--initial-cluster-token=etcd-cluster-token \

--initial-advertise-peer-urls=https://<控制平面节点IP>:2380

修改 etcd 数据目录配置（替换原目录）：

mv /var/lib/etcd /var/lib/etcd-backup # 备份原数据目录

mv /var/lib/etcd-restore /var/lib/etcd # 替换为恢复后的目录

启动 kubelet 服务，恢复控制平面：

systemctl start kubelet

验证：kubectl get pods -n kube-system，etcd、kube-apiserver 状态变为 Running

AI 自动排障动作

自动巡检 etcd 健康状态、磁盘空间、集群成员
自动识别数据损坏、磁盘满、成员异常等问题
自动执行数据压缩、碎片整理、快照清理
提供数据恢复向导，生成恢复命令（需人工确认执行）

场景 12：容器内无法访问外部网络（网络不通）

现象

Pod 内执行 ping baidu.com 提示 ping: bad address 'baidu.com' 或超时
Pod 内执行 curl https://www.baidu.com 提示 curl: (7) Failed to connect to www.baidu.com port 443 after 10000 ms: Couldn't connect to server

排障步骤

步骤 1：分层测试网络连通性

测试 DNS 解析（先确认域名能解析）：

kubectl exec -it slookup baidu.com

若解析失败：参考场景 10（DNS 解析失败）排查

测试访问外部 IP（跳过 DNS，直接访问 IP）：

kubectl exec -it n ping 180.101.49.12 # 百度IP

若 ping 不通：网络路由或防火墙问题

测试访问外部端口（如 80/443）：

kubectl exec -it n curl -I 180.101.49.12:80

步骤 2：检查节点网络连通性

Pod 网络依赖节点网络，先确认节点能访问外部网络：

kubectl get pod 名> -n 空间> -o wide | awk '{print $7}' # 获取节点名

ssh root@IP>

在节点上测试访问外部网络：

ping baidu.com

curl -I https://www.baidu.com

若节点也无法访问：问题在节点网络（如网关、防火墙、路由）

若节点能访问，Pod 不能：问题在 CNI 网络插件或 Pod 网络策略

步骤 3：针对性解决（常见原因）

原因 1：节点网络问题（网关 / 防火墙）

解决步骤：

检查节点网关配置：

ip route show default # 查看默认网关

ping <网关IP> # 测试网关连通性

若网关不通，检查网络配置文件（信创 OS 示例）：

vi /etc/sysconfig/network-scripts/ifcfg-eth0 # 网卡配置文件

确认网关配置正确（GATEWAY= 字段），重启网络：

systemctl restart network # 麒麟/欧拉OS

检查节点防火墙是否拦截出站流量：

firewall-cmd --list-all # 查看防火墙规则

# 放行出站流量（生产环境按需配置）

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" direction="out" action="accept"'

firewall-cmd --reload

原因 2：CNI 网络插件（Calico/Flannel）异常

解决步骤：

查看 CNI 插件 Pod 状态：

kubectl get pods -n kube-system | grep -E "calico|flannel"

若 Pod 未 Running，重启 CNI 插件：

# Calico 重启

kubectl delete pods -n kube-system -l k8s-app=calico-node

# Flannel 重启

kubectl delete pods -n kube-system -l app=flannel

查看 CNI 插件日志，排查错误：

kubectl logs /flannel-pod名> -n kube-system

若 CNI 配置损坏，重新安装 CNI 插件（参考 2.2.3 节）

原因 3：Pod 网络策略拦截出站流量

解决步骤：

查看命名空间下的网络策略：

kubectl get networkpolicy -n ```

检查是否有策略限制出站流量（policyTypes: [Egress] 且无允许规则）：

kubectl describe networkpolicy ```

修改网络策略，允许出站流量：

kubectl edit networkpolicy n ```

添加允许所有出站流量的规则（测试环境）：

spec:

egress:

- {} # 允许所有出站流量

生产环境按需配置：只允许访问特定外部 IP / 端口

AI 自动排障动作

自动分层检测（Pod→节点→外部网络）连通性
自动识别 CNI 插件状态与配置错误
自动检测网络策略对出站流量的拦截
推荐节点网络配置修正方案（网关、防火墙）

4 进阶扩展（新手→高手路线）

4.1 AI 故障自愈（全自动排障，无需人工干预）

4.1.1 自愈规则配置（信创环境适配）

基于 Prometheus 告警触发自愈：
- 通过 Alertmanager 的 webhook 关联 AI 运维平台
- 示例 webhook 配置（Alertmanager 配置文件）：

global:

resolve_timeout: 5m

route:

group_by: ['alertname']

group_wait: 10s

group_interval: 10s

repeat_interval: 1h

receiver: 'ai-self-heal'

receivers:

- name: 'ai-self-heal'

webhook_configs:

- url: 'http://ai-ops-platform:8080/api/self-heal' # AI 平台自愈接口

自愈动作分类（信创合规要求：可审计、可回滚）：
- 轻度自愈：重启 Pod、重启 coredns、清理磁盘日志
- 中度自愈：驱逐节点上的 Pod、扩容 Deployment、调整资源限制
- 重度自愈：重建控制平面组件、恢复 etcd 数据（需人工确认）

4.1.2 基于大模型的智能自愈脚本生成

利用国产大模型（ChatGLM-4、Qwen）根据故障日志生成修复脚本：
- 示例：输入 Pod 出现 OOMKilled，内存限制 512Mi
- 大模型输出修复脚本：

# 自动调整 Pod 内存限制

kubectl patch pod -n -p '{"spec":{"containers":[{"name":"<容器名>","resources":{"limits":{"memory":"1Gi"}}}]}}'

脚本执行流程：
- 大模型生成脚本→AI 平台校验脚本安全性→执行脚本→记录操作日志→验证故障是否恢复

4.2 信创环境专属优化（满足合规 + 性能提升）

4.2.1 国产芯片 / OS 内核调优

鲲鹏芯片优化：

开启鲲鹏处理器的 NUMA 架构支持：

echo 1 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages

调整 CPU 调度策略：

sysctl -w kernel.sched_rt_runtime_us=-1

麒麟 / 欧拉 OS 优化：

关闭不必要的系统服务（节省资源）：

systemctl stop postfix.service

systemctl disable postfix.service

开启文件系统缓存优化：

sysctl -w vm.vfs_cache_pressure=50

4.2.2 容器运行时信创加固

containerd 安全配置（/etc/containerd/config.toml）：

启用镜像校验：

[plugins."io.containerd.grpc.v1.cri".imageVerification]

enabled = true

verifyConfig = "/etc/containerd/verify.conf"

限制容器权限：禁止容器以 root 用户运行

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]

SystemdCgroup = true

Privileged = false

ReadonlyRootfs = true # 只读根文件系统

镜像安全扫描（信创兼容工具：奇安信镜像扫描、华为云镜像安全中心）：

集成到 CI/CD 流程，扫描镜像漏洞后再部署到 K8s

示例扫描命令（奇安信工具）：

qax-scan image --image=harbor.example.com/app/nginx:v1 --output=scan-report.json

4.2.3 等保 2.0 三级合规配置

身份认证强化：

启用 kubectl 证书认证，禁用用户名密码登录：

kubectl config use-context > --user=>

配置证书有效期（建议 180 天）：

kubeadm certs renew all # 续签所有证书

日志审计：

开启 kube-apiserver 审计日志：

# 修改 kube-apiserver 启动参数（/etc/kubernetes/manifests/kube-apiserver.yaml）

- --audit-policy-file=/etc/kubernetes/audit-policy.yaml

- --audit-log-path=/var/log/kubernetes/audit.log

- --audit-log-maxage=30 # 日志保留30天

审计策略配置（audit-policy.yaml）：

apiVersion: audit.k8s.io/v1

kind: Policy

rules:

- level: RequestResponse # 记录请求和响应

resources:

- group: ""

resources: ["pods", "services", "secrets"] # 重点审计资源

4.3 可观测性全景建设（Metric+Log+Trace）

4.3.1 eBPF 无侵入数据采集（信创兼容）

安装 eBPF 采集工具（国产工具：DeepFlow、eBPF Explorer）：

kubectl apply -f https://deepflow.yunshan.net/docs/zh/install/yaml/deepflow-agent.yaml

采集数据类型：

网络数据：TCP 连接、延迟、丢包率

应用数据：HTTP/GRPC 接口响应时间、错误率

资源数据：进程 CPU / 内存使用率（无需在容器内安装代理）

4.3.2 服务拓扑自动生成

基于 Trace 数据生成服务调用拓扑：

集成 Jaeger 或 SkyWalking（信创版）：

kubectl apply -f https://raw.githubusercontent.com/apache/skywalking-kubernetes/master/chart/skywalking/values.yaml

拓扑功能：

直观展示 Pod→Service→Ingress 的调用链路

标记异常链路（如响应时间 > 500ms、错误率 > 1%）

4.3.3 动态阈值告警（AI 自适应）

传统静态阈值问题：固定阈值无法适应业务波动（如秒杀场景 CPU 飙升是正常现象）

AI 动态阈值配置（Prometheus + 国产大模型）：

大模型分析历史指标数据，生成自适应阈值

示例 Prometheus Rule：

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

spec:

groups:

- name: dynamic.rules

rules:

- alert: DynamicHighCpu

expr: avg(rate(node_cpu_usage[5m])) by (instance) > ai_adaptive_threshold("node_cpu_usage", "instance")

for: 5m

labels:

severity: warning

4.4 自动化排障平台搭建（信创版）

4.4.1 平台架构（开源组件组合）

数据层：Prometheus（指标）、Loki（日志）、Jaeger（Trace）、etcd（存储）
AI 层：ChatGLM-4（根因分析）、MLflow（模型训练）
执行层：Argo Workflows（工作流）、Shell 脚本（自愈动作）
展示层：Grafana（可视化）、自定义 Web 界面（信创前端框架：Vue3 + Element Plus）

4.4.2 一键巡检脚本（新手可直接使用）

编写巡检脚本（检查集群健康状态）：

vi k8s-inspect.sh

粘贴内容：

#!/bin/bash

echo "=== K8s 集群巡检报告 ==="

echo "1. 节点状态："

kubectl get nodes | grep -v Ready && echo "⚠️ 存在 NotReady 节点" || echo "✅ 所有节点正常"

echo -e "\n2. 控制平面组件状态："

CONTROL_PODS="kube-apiserver kube-controller-manager kube-scheduler etcd"

for POD in $CONTROL_PODS; do

kubectl get pods -n kube-system | grep $POD | grep -v Running && echo "⚠️ $POD 异常" || echo "✅ $POD 正常"

done

echo -e "\n3. 网络插件状态："

kubectl get pods -n kube-system | grep -E "calico|flannel" | grep -v Running && echo "⚠️ 网络插件异常" || echo "✅ 网络插件正常"

echo -e "\n4. PVC 状态："

kubectl get pvc -A | grep Pending && echo "⚠️ 存在 Pending PVC" || echo "✅ 所有 PVC 正常"

echo -e "\n5. 磁盘空间（节点）："

for NODE in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do

DISK_USAGE=$(ssh root@$NODE df -h / | awk 'NR==2 {print $5}' | sed 's/%//')

if [ $DISK_USAGE -gt 85 ]; then

echo "⚠️ 节点 $NODE 根分区使用率 $DISK_USAGE%（超过85%）"

else

echo "✅ 节点 $NODE 根分区使用率 $DISK_USAGE%"

done

赋予执行权限并运行：

chmod +x k8s-inspect.sh

./k8s-inspect.sh

4.5 新手成长路线图（6 个月从入门到精通）

第 1-2 个月：基础夯实

目标：熟练掌握信创环境搭建、K8s 核心命令
任务：
1. 独立搭建信创 K8s 集群（麒麟 OS + 鲲鹏芯片 + Calico）
2. 背诵并实操 2.4 节的所有 kubectl 命令
3. 完成 3 个基础场景排障（Node NotReady、Pod Pending、ImagePullBackOff）

第 3-4 个月：场景深耕

目标：能独立解决 12 个高频排障场景
任务：
1. 每个场景至少实操 2 次，记录排障过程
2. 搭建本地 AI 运维平台（ChatGLM-6B + Prometheus）
3. 编写 5 个自定义自愈脚本（如自动清理磁盘、重启 coredns）

第 5-6 个月：进阶提升

目标：能优化信创 K8s 集群、搭建自动化平台
任务：
1. 完成信创环境内核调优、容器安全加固
2. 搭建可观测性平台（Prometheus + Grafana + Loki + Jaeger）
3. 独立开发简单的 AI 排障工具（调用大模型 API 生成修复命令）

5 总结说明

5.1 适用范围

环境要求：信创合规环境（国产芯片：鲲鹏 / 飞腾 / 海光；国产 OS：麒麟 / 统信 UOS / 欧拉；K8s 版本：1.24-1.26）
人员要求：K8s 新手、运维工程师、开发工程师、IT 管理人员（无需深厚的底层知识）
工具依赖：kubectl、containerd、crictl、AI 运维平台（开源 / 商业均可）

5.2 排障核心原则（新手必须牢记）

从下到上：先排查节点层→控制平面→工作负载→网络 / 存储
先状态后日志：先通过 kubectl get 看资源状态，再通过 logs/describe 找原因
先基础后复杂：先检查配置（标签、端口、资源），再排查底层组件（etcd、CNI）
信创优先：所有操作需满足信创合规（如使用国产镜像、操作留痕）

5.3 常见问题求助渠道

官方文档：
- K8s 官方文档（中文）：https://kubernetes.io/zh-cn/docs/home/
- 麒麟 OS 文档：https://www.kylinos.cn/support/documentation.html
- 华为云 CCE（信创 K8s）文档：https://support.huaweicloud.com/cce/

社区支持：
- 信创社区：https://www.xinchuang.org/
- K8s 中文社区：https://kubernetes.io/zh-cn/community/

工具支持：
- AI 运维平台技术支持（商业产品）
- 国产大模型 API（ChatGLM、Qwen）

免责声明：本文中的命令和配置基于信创标准环境，实际使用时需根据自身集群配置调整（如镜像地址、IP、命名空间等）。操作前请备份关键数据，避免数据丢失。

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

破局“数据荒”与“质量墙”：从传统标注到大模型时代的智能数据治理实践

2048 AI社区

Cline怎么接OpenAI兼容API？Base URL、模型ID与工具调用配置

2048 AI社区

User-Agent 检测原理

User-Agent 检测是客户端识别技术的基石，它实现简单、部署成本低，在设备适配、基础防护等场景中有着不可替代的作用。但随着反爬对抗和黑灰产技术的升级，单一的 UA 检测已经不足以应对复杂场景。行业的发展趋势是从 “单一 UA 识别” 走向 “多维度指纹 + 行为分析” 的综合识别体系 ——UA 仍然是重要的身份标识，但不再是唯一的判断依据。理解 UA 检测的原理与边界，才能更好地搭建可靠的客