【Linux&Kubernetes】必学知识点合集六

qq_43064223

1368人浏览 · 2026-02-13 19:40:08

qq_43064223 · 2026-02-13 19:40:08 发布

一、POD 的 CIDR 配置与管理

1. CIDR 核心概念

2. 集群级 CIDR 配置（kubeadm 初始化）

（2）初始化本地 Git 仓库（用于管理 K8s 配置文件）

三、查看 Pod 日志：定位 Pod 运行时错误

1. 查看 Pod 基础日志（无容器名指定）

2. 查看多容器 Pod 的指定容器日志

3. 实时查看 Pod 日志（动态监控）

4. 查看 Pod 历史日志（容器重启后）

5. 按时间筛选查看 Pod 日志

四、查看 Pod 详细状态（describe）：分析 Event 事件解决错误

1. 查看 Pod 详细状态与 Event 事件

2. 常见 Event 事件错误与解决方案

（1）镜像拉取失败（ErrImagePull/ImagePullBackOff）

（2）Pod 调度失败（FailedScheduling）

（3）卷挂载失败（FailedMount）

（4）容器启动失败（CrashLoopBackOff）

3. 仅查看 Pod 的 Event 事件（精简输出）

五、核心知识点总结

一、POD 的 CIDR 配置与管理

POD 的 CIDR 是 Kubernetes 集群为 Pod 分配私有 IP 地址的网段范围，核心作用是为集群内所有 Pod 划分独立的网络地址空间，保证 Pod 间网络互通且不与集群外网络冲突，是 K8s 网络规划的核心基础配置。

1. CIDR 核心概念

CIDR（无类别域间路由）格式为网段/子网掩码，例如10.244.0.0/16，其中：

网段：为 Pod 分配 IP 的基础地址段；
子网掩码：决定网段内可分配的 IP 数量，/16表示可分配 65534 个可用 IP，满足大规模 Pod 部署需求。

2. 集群级 CIDR 配置（kubeadm 初始化）

在使用kubeadm初始化 K8s 集群时，通过--pod-network-cidr参数指定 Pod 的 CIDR 网段，这是最基础也是最核心的配置方式，执行命令：

# 初始化集群并指定Pod CIDR为10.244.0.0/16（适配flannel网络插件）
kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=集群控制节点IP

注：Pod CIDR 需与网络插件（flannel/calico/weave）配置的网段一致，否则会导致 Pod 网络不通。

3. 验证 Pod CIDR 配置

集群初始化完成后，通过查看集群配置确认 Pod CIDR 是否生效，执行命令：

# 查看kubeadm集群配置
kubeadm config view | grep pod-network-cidr
# 或查看apiserver启动参数
ps -ef | grep kube-apiserver | grep pod-network-cidr

4. 节点级 Pod CIDR 分配

K8s 控制器会将集群级 Pod CIDR 划分子网段，为每个节点分配独立的 Pod CIDR（例如10.244.1.0/24），验证节点 CIDR 分配结果：

# 查看所有节点的Pod CIDR配置
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}: {.spec.podCIDR}{"\n"}{end}'

二、Git 管理 K8s 资源配置文件

K8s 集群的 Pod、Deployment、Service 等资源配置文件均为 YAML 格式，通过 Git 对配置文件进行版本控制、多人协作、历史追溯，是企业级 K8s 运维的标准实践，核心实现配置文件的规范化管理。

1. 环境准备与 Git 仓库初始化

（1）安装 Git 客户端

# CentOS/RHEL系统
yum install git -y
# Ubuntu/Debian系统
apt install git -y

（2）初始化本地 Git 仓库（用于管理 K8s 配置文件）

# 创建K8s配置文件专属目录
mkdir -p ~/k8s-configs && cd ~/k8s-configs
# 初始化Git仓库
git init
# 创建.gitignore文件，忽略无关文件
cat > .gitignore << 'EOF'
# 忽略临时文件
*.tmp
# 忽略日志文件
*.log
# 忽略kubeconfig文件（敏感信息）
*.kubeconfig
EOF

2. 配置文件提交与版本控制

将 K8s Pod、Deployment 等 YAML 配置文件放入 Git 仓库，完成首次提交，实现版本追溯：

# 将配置文件放入仓库目录
cp ~/pod-demo.yml ~/k8s-configs/
# 添加文件到暂存区
git add .
# 提交到本地仓库，添加提交说明
git commit -m "init: 新增pod-demo.yml配置文件，定义Nginx Pod"

3. 远程仓库关联与推送（多人协作）

将本地 Git 仓库关联到远程 Git 仓库（Gitee/GitHub/GitLab），实现配置文件的远程备份与多人协作：

# 关联远程Git仓库
git remote add origin git@xxx.com:username/k8s-configs.git
# 将本地master分支推送到远程仓库
git push -u origin master

4. 配置文件修改与版本追溯

修改配置文件后，通过 Git 提交并记录修改说明，后续可通过git log查看历史修改记录，实现问题追溯：

# 修改配置文件后，添加到暂存区
git add pod-demo.yml
# 提交修改，注明修改内容
git commit -m "modify: 调整pod-demo.yml的镜像版本为nginx:1.25"
# 推送至远程仓库
git push
# 查看历史提交记录
git log --oneline

5. 配置文件回滚（故障恢复）

若因配置文件修改导致 Pod 运行故障，可通过 Git 回滚到历史正常版本，快速恢复：

# 查看历史提交的版本号
git log --oneline
# 回滚到指定版本（版本号取前7位）
git reset --hard 6f9288a
# 将回滚后的配置推送到远程仓库
git push -f origin master
# 重新应用K8s配置文件
kubectl apply -f pod-demo.yml

三、查看 Pod 日志：定位 Pod 运行时错误

Pod 日志记录了容器内应用的运行输出、报错信息、业务日志等核心内容，是排查 Pod运行时错误（如应用启动失败、代码报错、端口占用）的最基础手段，核心命令为kubectl logs。

1. 查看 Pod 基础日志（无容器名指定）

若 Pod 中仅运行一个容器，直接通过 Pod 名称查看日志，执行命令：

# 查看Pod全部日志
kubectl logs <pod-name>
# 示例：查看nginx-demo Pod的全部日志
kubectl logs nginx-demo

2. 查看多容器 Pod 的指定容器日志

若 Pod 中运行多个容器（如业务容器 + 日志收集容器），需通过-c参数指定容器名，执行命令：

# 查看多容器Pod中指定容器的日志
kubectl logs <pod-name> -c <container-name>
# 示例：查看app-demo Pod中app容器的日志
kubectl logs app-demo -c app

3. 实时查看 Pod 日志（动态监控）

通过-f参数实时跟踪 Pod 日志输出，类似tail -f命令，适用于排查实时运行的故障，执行命令：

# 实时查看Pod日志
kubectl logs -f <pod-name>
# 示例：实时监控nginx-demo Pod的日志
kubectl logs -f nginx-demo
# 多容器Pod实时查看指定容器日志
kubectl logs -f <pod-name> -c <container-name>

4. 查看 Pod 历史日志（容器重启后）

若 Pod 因故障重启，通过--previous参数查看容器重启前的历史日志，定位重启原因，执行命令：

# 查看Pod重启前的历史日志
kubectl logs <pod-name> --previous
# 多容器Pod查看指定容器的历史日志
kubectl logs <pod-name> -c <container-name> --previous

5. 按时间筛选查看 Pod 日志

通过--since（指定时间）或--tail（指定行数）筛选日志，快速定位近期报错信息，执行命令：

# 查看最近10分钟的Pod日志
kubectl logs <pod-name> --since=10m
# 查看最后100行的Pod日志
kubectl logs <pod-name> --tail=100
# 组合使用：查看最近5分钟的最后50行日志
kubectl logs <pod-name> --since=5m --tail=50

四、查看 Pod 详细状态（describe）：分析 Event 事件解决错误

kubectl describe pod <pod-name>命令用于查看 Pod 的全量详细状态，包含 Pod 的创建信息、容器状态、节点分配、卷挂载、事件（Events）等核心内容，其中Events 事件是排查 Pod创建 / 调度 / 启动失败（如镜像拉取失败、调度失败、卷挂载失败）的关键，记录了 Pod 从创建到运行的全生命周期行为。

1. 查看 Pod 详细状态与 Event 事件

执行核心命令查看 Pod 全量信息，重点关注最后面的Events模块，执行命令：

# 查看Pod详细状态与Event事件
kubectl describe pod <pod-name>
# 示例：查看nginx-demo Pod的详细信息
kubectl describe pod nginx-demo

2. 常见 Event 事件错误与解决方案

（1）镜像拉取失败（ErrImagePull/ImagePullBackOff）

典型 Event 事件：

Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  10s               default-scheduler  Successfully assigned default/nginx-demo to node1
  Warning  Failed     8s                kubelet            Failed to pull image "nginx:1.30": rpc error: code = Unknown desc = Error response from daemon: pull access denied for nginx:1.30, repository does not exist or may require 'docker login'
  Warning  Failed     8s                kubelet            Error: ErrImagePull
  Normal   BackOff    7s                kubelet            Back-off pulling image "nginx:1.30"
  Warning  Failed     7s                kubelet            Error: ImagePullBackOff

错误原因：镜像名称错误、镜像版本不存在、私有镜像未配置拉取密钥、镜像仓库网络不通。解决方案：

# 1. 验证镜像名称和版本是否正确
docker pull nginx:1.30  # 本地验证
# 2. 私有镜像需配置ImagePullSecret
kubectl create secret docker-registry reg-secret --docker-server=镜像仓库地址 --docker-username=用户名 --docker-password=密码 --docker-email=邮箱
# 3. 在Pod配置中引用ImagePullSecret
kubectl edit pod nginx-demo
# 添加以下配置
spec:
  imagePullSecrets:
  - name: reg-secret
# 4. 验证仓库网络连通性（节点上执行）
ping 镜像仓库IP

（2）Pod 调度失败（FailedScheduling）

典型 Event 事件：

Events:
  Type     Reason            Age               From               Message
  ----     ------            ----              ----               -------
  Warning  FailedScheduling  20s               default-scheduler  0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.

错误原因：Pod 未配置容忍度，无法调度到带有污点的节点（如控制节点），或节点资源不足（CPU / 内存）、节点标签不匹配。解决方案：

# 1. 若需调度到控制节点，为Pod添加容忍度
kubectl edit pod nginx-demo
# 添加以下配置
spec:
  tolerations:
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Exists"
    effect: "NoSchedule"
# 2. 检查节点资源使用情况，确认是否有足够CPU/内存
kubectl top nodes
# 3. 检查Pod节点选择器与节点标签是否匹配
kubectl get nodes --show-labels
kubectl describe pod nginx-demo | grep NodeSelector

（3）卷挂载失败（FailedMount）

典型 Event 事件：

Events:
  Type     Reason       Age               From               Message
  ----     ------       ----              ----               -------
  Normal   Scheduled    30s               default-scheduler  Successfully assigned default/nginx-demo to node1
  Warning  FailedMount  28s               kubelet            MountVolume.SetUp failed for volume "nginx-pv" : hostPath type check failed: /data/nginx is not a directory
  Warning  FailedMount  10s               kubelet            MountVolume.SetUp failed for volume "nginx-pv" : hostPath type check failed: /data/nginx does not exist

错误原因：主机路径（hostPath）不存在、主机路径类型不匹配（如指定为目录但实际是文件）、PV/PVC 绑定失败。解决方案：

# 1. 在节点上创建对应的主机路径
ssh node1 "mkdir -p /data/nginx && chmod 777 /data/nginx"
# 2. 验证PV/PVC状态是否正常
kubectl get pv
kubectl get pvc
# 3. 检查Pod卷挂载配置与PV/PVC名称是否一致
kubectl describe pod nginx-demo | grep Volume

（4）容器启动失败（CrashLoopBackOff）

典型 Event 事件：

Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  1m                default-scheduler  Successfully assigned default/app-demo to node1
  Normal   Pulled     1m                kubelet            Successfully pulled image "app:v1" in 3s
  Normal   Created    1m                kubelet            Created container app
  Normal   Started    1m                kubelet            Started container app
  Normal   Killing    59s               kubelet            Container app failed liveness probe, will be restarted
  Warning  Unhealthy  59s               kubelet            Liveness probe failed: HTTP probe failed with statuscode: 500
  Normal   Pulled     58s               kubelet            Successfully pulled image "app:v1" in 2s
  Normal   Created    58s               kubelet            Created container app
  Normal   Started    58s               kubelet            Started container app
  Warning  BackOff    10s               kubelet            Back-off restarting failed container

错误原因：存活探针（livenessProbe）/ 就绪探针（readinessProbe）配置不合理、应用启动后立即退出、端口配置错误。解决方案：

# 1. 先查看Pod日志，定位应用内部报错
kubectl logs app-demo --previous
# 2. 调整探针配置（增加初始延迟、延长超时时间）
kubectl edit pod app-demo
# 修改探针配置
spec:
  containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30  # 延长初始延迟
      timeoutSeconds: 5         # 延长超时时间
      periodSeconds: 10
# 3. 验证应用端口是否配置正确
kubectl describe pod app-demo | grep Port

3. 仅查看 Pod 的 Event 事件（精简输出）

若只需查看 Pod 的 Event 事件，无需全量详细信息，可通过管道过滤输出，执行命令：

# 仅查看Pod的Event事件
kubectl describe pod <pod-name> | grep -A 20 "Events:"
# 示例：仅查看nginx-demo Pod的Event事件
kubectl describe pod nginx-demo | grep -A 20 "Events:"

五、核心知识点总结

POD 的 CIDR：是 K8s 为 Pod 分配 IP 的网段基础，通过kubeadm init --pod-network-cidr配置，需与网络插件网段一致，节点会被分配子 CIDR，保证 Pod 网络互通；
Git 管理 K8s 配置：实现配置文件的版本控制、多人协作、历史追溯，核心通过git commit/push/reset完成配置提交、推送、回滚，是故障快速恢复的重要手段；
Pod 日志排查：通过kubectl logs实现基础日志、实时日志、历史日志、指定容器日志的查看，重点排查Pod 运行时应用层错误，是最基础的故障排查方式；
Pod describe 与 Event 事件：通过kubectl describe pod查看 Pod 全量状态，核心关注Events 事件，定位Pod 创建 / 调度 / 启动阶段的系统层错误（镜像拉取、调度、卷挂载、探针失败等）；
故障排查思路：先通过kubectl get pods查看 Pod 整体状态→再通过kubectl logs排查运行时应用错误→最后通过kubectl describe pod分析 Event 事件排查系统层错误，层层递进定位根因。