背景与问题

运维工程师在学习 Kubernetes 时，往往会在某些核心概念上反复卡住。这些概念不是孤立的知识点，而是相互关联、层层递进的体系。理解这些概念的关键在于动手实践，而非仅仅阅读文档。

本文针对 2026 年最新的 Kubernetes 进行讲解，所有命令和示例均在 Ubuntu 24.04 LTS 或 CentOS Stream 9 环境下验证通过。目标读者为具备 Linux 基础和 Docker 使用经验的初中级运维工程师。

概念一：Control Plane 与 Worker Node 的职责边界

1.1 架构概述

Kubernetes 集群由 Control Plane 和 Worker Node 两部分组成。Control Plane 负责集群的管理和控制，Worker Node 负责运行工作负载。

Control Plane 的核心组件包括：

kube-apiserver：集群的统一入口，处理所有 RESTful 请求。

etcd：分布式键值存储，保存集群的所有状态数据。

kube-scheduler：调度器，为 Pod 选择最佳节点。

kube-controller-manager：运行各种控制器，执行集群管理任务。

cloud-controller-manager：与云厂商交互，管理云资源。

Worker Node 的核心组件包括：

kubelet：与 API Server 通信，管理节点上的 Pod。

kube-proxy：维护网络规则，实现 Service 通信。

container-runtime：容器运行时，如 containerd 或 cri-o。

1.2 常见误解

新手常犯的错误是混淆了 Control Plane 和 Worker Node 的职责。例如，试图在 Worker Node 上查看 etcd 数据或 API Server 日志。

查看 Control Plane 组件状态：

# 查看 Control Plane 组件健康状态
kubectl get componentstatuses
kubectl get cs

# 完整输出示例
NAME                 STATUS    MESSAGE                         ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-0               Healthy   {"health":"true","reason":""}

查看 etcd 状态（需要在 Control Plane 节点上执行）：

# 查看 etcd 集群健康状态
sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

# 查看 etcd 成员列表
sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list

1.3 kubelet 与 API Server 的通信机制

kubelet 与 API Server 之间采用双向 TLS 认证机制：

API Server 需要验证 kubelet 的证书，确保请求来自合法的节点。

kubelet 需要验证 API Server 的证书，确保连接的是真正的 API Server。

查看 kubelet 的认证配置：

# 查看 kubelet 配置
cat /var/lib/kubelet/config.yaml

# 查看 kubelet 的证书信息
openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep -E "Subject:|Issuer:|Not Before:|Not After:"

概念二：命名空间与资源隔离

2.1 命名空间的作用

命名空间是 Kubernetes 最重要的隔离机制之一，但新手往往低估了它的作用范围。

命名空间隔离的内容：资源对象（Pod、Service、Deployment 等）、RBAC 权限、网络策略、资源配额。

命名空间不隔离的内容：Node、PersistentVolume、CustomResourceDefinition。

查看集群中的命名空间：

kubectl get namespaces
kubectl describe namespace production

命名空间级别的资源查看：

# 默认查看 default 命名空间
kubectl get pods

# 查看特定命名空间
kubectl get pods -n production

# 查看所有命名空间
kubectl get pods -A

# 查看所有命名空间的所有资源
kubectl get all -A

2.2 跨命名空间访问

跨命名空间访问是新手容易混淆的地方。Kubernetes 中的 Service 访问遵循以下规则：

同命名空间内访问：直接使用 Service 名称即可。

跨命名空间访问：使用 Service 名称加上命名空间，格式为 servicename.namespacename.svc.cluster.local。

# 在 default 命名空间中访问 production 命名空间的 nginx-service
# 完整格式
nginx-service.production.svc.cluster.local

# 简写格式（在同一命名空间内）
nginx-service.production

实际测试：

# 创建测试 Pod
kubectl run -it --rm debug --image=busybox:1.36 -- sh

# 在 Pod 内测试 DNS 解析
nslookup kubernetes.default
nslookup nginx-service.production.svc.cluster.local

# 测试跨命名空间访问
wget -qO- http://nginx-service.production.svc.cluster.local:80

2.3 资源配额与限制

命名空间级别的资源配额是生产环境的必备配置：

apiVersion: v1
kind:ResourceQuota
metadata:
name:production-quota
namespace:production
spec:
hard:
    requests.cpu:"20"
    requests.memory:40Gi
    limits.cpu:"40"
    limits.memory:80Gi
    pods:"100"
    services:"20"
    persistentvolumeclaims:"50"

LimitRange 设置默认资源限制：

apiVersion: v1
kind:LimitRange
metadata:
name:production-limits
namespace:production
spec:
limits:
-max:
      cpu:"4"
      memory:8Gi
    min:
      cpu:"50m"
      memory:64Mi
    default:
      cpu:"500m"
      memory:256Mi
    defaultRequest:
      cpu:"100m"
      memory:128Mi
    type:Container

概念三：Etcd 与数据一致性

3.1 Etcd 的核心地位

Etcd 是 Kubernetes 的大脑，所有集群状态都存储在 etcd 中。如果 etcd 出现问题，整个集群将无法正常工作。

Etcd 采用 Raft 一致性算法，保证数据在多个节点间的一致性。生产环境通常使用 3 或 5 个 etcd 节点。

Etcd 的关键特性：

强一致性：所有读写操作都保证线性一致性。

高可用：少数节点故障不影响集群可用性。

高可靠：数据持久化到磁盘，支持快照备份。

3.2 常见故障场景

3.2.1 Etcd 磁盘空间耗尽

这是生产环境最常见的 etcd 故障。当磁盘空间不足时，etcd 可能无法写入数据，导致 API Server 无法处理请求。

排查方法：

# 在 etcd 节点上查看磁盘使用
df -h /var/lib/etcd

# 查看 etcd 日志
sudo journalctl -u etcd -n 100 | grep -i error

# 查看 etcd 存储使用量
sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint status

解决方案：

# 压缩 etcd 历史数据
sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  defrag

# 清理不需要的历史快照
ls -la /var/lib/etcd/member/snap/
ls -la /var/lib/etcd/member/wal/

# 设置自动压缩（编辑 etcd 启动参数）
--auto-compaction-retention=1
--max-snapshots=5
--max-wals=5

3.2.2 Etcd 证书过期

证书过期会导致 etcd 节点无法通信，集群进入不可用状态。

检查证书有效期：

# 查看所有 Kubernetes 证书的过期时间
sudo kubeadm certs check-expiration

# 查看特定证书
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -dates

更新证书：

# 在 Control Plane 节点上执行
sudo kubeadm certs renew all

# 重启相关服务
sudo systemctl restart kubelet

3.3 Etcd 备份与恢复

定期备份 etcd 是灾难恢复的关键：

# 创建快照
ETCDCTL_API=3 sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

# 查看快照状态
ETCDCTL_API=3 sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot status /backup/etcd-snapshot-$(date +%Y%m%d).db

# 从快照恢复
sudo systemctl stop etcd
ETCDCTL_API=3 sudo etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot restore /backup/etcd-snapshot-20260101.db \
  --data-dir=/var/lib/etcd/member
sudo systemctl start etcd

概念四：网络模型与 CNI 插件

4.1 Kubernetes 网络模型原则

Kubernetes 网络模型遵循以下基本原则：

每个 Pod 拥有独立的 IP 地址，Pod 之间的通信不需要 NAT。

节点上的代理（kubelet）能够与该节点上的所有 Pod 通信。

在不对网络进行特殊配置的情况下，Pod 可以与所有其他 Pod 通信。

这些原则使得应用无需修改即可在不同环境间迁移。

4.2 CNI 插件的作用

CNI（Container Network Interface）是容器网络接口标准，定义了容器运行时与网络插件之间的接口规范。

常见的 CNI 插件：

Flannel：简单的 overlay 网络，使用 VXLAN 封装。适合小型集群。

Calico：高性能三层网络，支持 BGP 路由和网络策略。适合中大型集群。

Cilium：基于 eBPF 的网络方案，提供 L7 网络可视化和细粒度控制。

查看当前使用的 CNI 插件：

# 查看 CNI 配置目录
ls -la /etc/cni/net.d/

# 查看 CNI 插件配置
cat /etc/cni/net.d/10-flannel.conflist

# 查看网桥信息
ip link show type bridge
ip addr show flannel.1

4.3 Pod 网络故障排查

4.3.1 同节点 Pod 通信异常

# 查看 Pod 的网络命名空间
kubectl exec -it <pod-name> -- ip addr

# 查看 Pod 的路由表
kubectl exec -it <pod-name> -- ip route

# 测试 Pod 之间的连通性
kubectl exec -it <source-pod> -- ping -c 3 <target-pod-ip>

# 查看节点的网桥和 veth 对
ip link show type bridge
ip link show type veth

4.3.2 跨节点 Pod 通信异常

# 在源节点上测试
ping -I cni0 <target-pod-ip>

# 查看 CNI 插件的 overlay 网络
ip addr show flannel.1   # Flannel
ip addr show calico      # Calico

# 查看路由表
route -n
ip route

4.4 DNS 故障排查

DNS 是 Kubernetes 中最常见的问题来源之一。

CoreDNS 是 Kubernetes 默认的 DNS 服务器，通常以 Deployment 形式运行在 kube-system 命名空间。

查看 CoreDNS 状态：

kubectl get pod -n kube-system -l k8s-app=kube-dns

# 查看 CoreDNS 配置
kubectl get configmap coredns -n kube-system -o yaml

常见 DNS 问题：

DNS 解析超时：检查 CoreDNS Pod 是否正常运行。

DNS 记录不存在：检查 Service 和 Pod 的命名和标签是否正确。

DNS 缓存问题：检查是否存在旧的 DNS 记录。

测试 DNS：

# 创建调试 Pod
kubectl run -it --rm dnsutils --image=tutum/dnsutils -- sh

# 测试 DNS 解析
nslookup kubernetes
nslookup kubernetes.default.svc.cluster.local
nslookup <service-name>
nslookup <service-name>.<namespace>
nslookup <service-name>.<namespace>.svc.cluster.local

# 测试 DNS 响应时间
time nslookup kubernetes.default.svc.cluster.local

概念五：存储卷与持久化存储

5.1 存储卷的类型

Kubernetes 存储卷分为多种类型，每种类型有不同的使用场景。

临时存储卷：emptyDir，用于临时数据存储，Pod 删除后数据丢失。

本地存储卷：hostPath、local，用于节点级别的持久化存储。

网络存储卷：NFS、Ceph、GlusterFS，用于跨节点共享存储。

云存储卷：AWS EBS、GCE PD、Azure Disk，用于云环境的高可用存储。

5.2 PersistentVolume 与 PersistentVolumeClaim

PersistentVolume（PV）是集群级别的存储资源，由管理员或存储系统自动配置。

PersistentVolumeClaim（PVC）是用户对存储的请求，Pod 通过 PVC 使用 PV。

apiVersion: v1
kind:PersistentVolume
metadata:
name:pv-nfs
spec:
capacity:
    storage:100Gi
accessModes:
    -ReadWriteMany
nfs:
    server:nfs-server.example.com
    path:/exports/pv01
---
apiVersion:v1
kind:PersistentVolumeClaim
metadata:
name:pvc-nfs
spec:
accessModes:
    -ReadWriteMany
resources:
    requests:
      storage:50Gi
selector:
    matchLabels:
      type:fast-storage

5.3 存储类与动态 provisioning

StorageClass 允许动态创建 PV，简化存储管理：

apiVersion: storage.k8s.io/v1
kind:StorageClass
metadata:
name:fast-storage
provisioner:kubernetes.io/aws-ebs
parameters:
type:gp3
fsType:ext4
replication-type:regional-pd
volumeBindingMode:WaitForFirstConsumer
allowVolumeExpansion:true

5.4 存储故障排查

5.4.1 PVC 一直处于 Pending 状态

# 查看 PVC 详情
kubectl describe pvc <pvc-name>

# 常见原因：
# 1. 没有满足条件的 PV
# 2. StorageClass 不存在
# 3. 存储配额不足

# 排查 StorageClass
kubectl get storageclass
kubectl describe storageclass <sc-name>

# 查看所有 PV
kubectl get pv

5.4.2 Pod 无法挂载存储卷

# 查看 Pod 事件
kubectl describe pod <pod-name> | grep -A 10 "Events:"

# 常见错误：
# Unable to attach or mount volumes: timeout expired
# node has pod with unmet topology requirement

# 查看节点的存储卷信息
kubectl get pv <pv-name> -o yaml | grep -A 5 nodeAffinity

概念六：认证、授权与 RBAC

6.1 Kubernetes 的认证机制

Kubernetes 支持多种认证方式：

X509 客户端证书：最常用的方式，CA 签发证书标识用户身份。

静态令牌：Bearer Token，简单但安全性较低。

ServiceAccount 令牌：Pod 使用的服务账号令牌。

OIDC：OpenID Connect，集成外部身份提供商。

查看集群的认证配置：

# 查看 API Server 的认证配置
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -E "authentication|authorization"

# 查看当前用户的认证信息
kubectl config view --raw

6.2 RBAC 权限模型

RBAC（Role-Based Access Control）是 Kubernetes 默认的授权模式。

核心概念：

Role 和 ClusterRole：定义一组权限规则。

RoleBinding 和 ClusterRoleBinding：将权限绑定到用户或组。

Role 作用于命名空间，ClusterRole 作用于整个集群。

# 定义只读权限
apiVersion:rbac.authorization.k8s.io/v1
kind:Role
metadata:
name:pod-reader
namespace:default
rules:
-apiGroups:[""]
resources:["pods"]
verbs:["get","list","watch"]

# 绑定权限到用户
apiVersion:rbac.authorization.k8s.io/v1
kind:RoleBinding
metadata:
name:pod-reader-binding
namespace:default
subjects:
-kind:User
name:jane
apiGroup:rbac.authorization.k8s.io
roleRef:
kind:Role
name:pod-reader
apiGroup:rbac.authorization.k8s.io

6.3 常见权限问题排查

6.3.1 权限不足错误

# 查看错误信息
kubectl get pods
Error from server (Forbidden): pods is forbidden: User "system:node:worker1" cannot list resource "pods"in API group ""in the namespace "default"

# 诊断步骤
# 1. 确认当前用户/ServiceAccount
kubectl config current-context

# 2. 查看用户拥有的角色
kubectl auth can-i --list --as=system:node:worker1

# 3. 测试特定权限
kubectl auth can-i get pods --as=system:node:worker1
kubectl auth can-i delete pods --as=system:node:worker1

6.3.2 调试 RBAC 配置

# 查看角色和绑定
kubectl get roles -A
kubectl get rolebindings -A

# 查看特定 ServiceAccount 的权限
kubectl auth can-i list pods --as=system:serviceaccount:default:default

# 递归查看所有权限（使用 rbac-lookup 工具）
kubectl rbac-lookup <user-or-serviceaccount> --kind=User

6.4 ServiceAccount 的使用

每个 Pod 都有一个关联的 ServiceAccount，控制 Pod 与 API Server 的交互：

apiVersion: v1
kind:ServiceAccount
metadata:
name:my-app-sa
namespace:default
---
apiVersion:v1
kind:Pod
metadata:
name:my-app
spec:
serviceAccountName:my-app-sa
containers:
-name:my-app
    image:my-app:latest

Pod 内使用 ServiceAccount 令牌访问 API Server：

# 在 Pod 内查看令牌
kubectl exec -it my-app -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

# 使用令牌访问 API Server
kubectl exec -it my-app -- \
  curl -k https://kubernetes.default.svc/api/v1/namespaces/default/pods \
  --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

综合排障流程

当遇到 Kubernetes 集群问题时，建议按照以下流程逐步排查：

第一步：确认问题范围

# 查看集群所有组件状态
kubectl get componentstatuses
kubectl get nodes

# 查看 Control Plane 组件日志
kubectl logs -n kube-system -l component=kube-apiserver --tail=100
kubectl logs -n kube-system -l component=kube-controller-manager --tail=100
kubectl logs -n kube-system -l component=kube-scheduler --tail=100

# 查看 kubelet 日志
sudo journalctl -u kubelet --tail=100

第二步：逐层排查资源状态

# 1. 检查 Deployment 状态
kubectl get deployment -A
kubectl describe deployment <name> -n <namespace>

# 2. 检查 ReplicaSet 状态
kubectl get rs -A
kubectl describe rs <name> -n <namespace>

# 3. 检查 Pod 状态
kubectl get pods -A
kubectl describe pod <name> -n <namespace>

# 4. 检查 Service 和 Endpoint
kubectl get svc -A
kubectl get endpoints -A

第三步：检查网络连通性

# 1. 测试 DNS 解析
kubectl run -it --rm debug --image=busybox:1.36 -- nslookup kubernetes

# 2. 测试 Service 访问
kubectl run -it --rm debug --image=busybox:1.36 -- wget -qO- http://kubernetes.default:80

# 3. 测试 Pod 间连通性
kubectl exec -it <pod-name> -- ping -c 3 <target-pod-ip>

第四步：检查资源配额

# 检查命名空间资源配额
kubectl describe namespace <namespace> | grep -A 10 "ResourceQuota"

# 检查 LimitRange
kubectl describe limitrange -n <namespace>

# 检查节点资源使用
kubectl describe node <node-name> | grep -A 10 "Allocated resources"

最佳实践建议

集群部署

生产环境应使用 kubeadm 进行高可用部署，Control Plane 至少 3 个节点，etcd 使用 3 或 5 节点集群。

命名规范

建立统一的命名规范，包括命名空间名称、资源标签、注释等。建议使用以下标准标签：

app.kubernetes.io/name：应用名称

app.kubernetes.io/instance：应用实例名称

app.kubernetes.io/version：应用版本

app.kubernetes.io/component：组件类型

app.kubernetes.io/part-of：所属应用

监控告警

部署 Prometheus + Grafana 监控集群组件状态，配置关键指标告警：

API Server 请求延迟

etcd 磁盘使用率和集群健康状态

kubelet 的 Pod 启动失败数

节点资源使用率

定期维护

建立定期维护机制，包括 etcd 快照备份、证书检查和更新、日志清理、存储卷清理等。

总结

Kubernetes 的六个核心概念——Control Plane 与 Worker Node 职责边界、命名空间隔离、etcd 数据一致性、网络模型与 CNI 插件、存储卷与持久化、认证授权与 RBAC——构成了理解集群的基础框架。

这六个概念相互关联：Control Plane 通过 etcd 保存集群状态，命名空间提供资源隔离，网络模型实现 Pod 通信，存储卷提供持久化能力，RBAC 控制权限访问。

遇到问题时，按照数据流和控制逻辑逐层排查，善用 kubectl describe 和 kubectl logs 命令，查看 Events 是快速定位问题的关键。

文末福利

你在用kubernetes时，有没有出现过故障？这时候你是否急需一份排错指南，帮助你更好地使用kubernetes？

今天就分享一份kubernetes网络排错指南，非常详细，如果你是kubernetes小白，那更建议你仔细看一看哦。

文末可免费领取高清PDF~1指南部分内容展示

指南一共包括4大部分：pod网络异常、常用网络排查工具、pod网络排查流程和案例学习。

扫描下方二维码，添加好友，回复暗号“K8s排查指南”，即可100%免费领取成功。

本文链接：https://www.yunweipai.com/49206.html