背景與問題

運(yùn)維工程師在學(xué)習(xí) Kubernetes 時，往往會在某些核心概念上反復(fù)卡住。這些概念不是孤立的知識點(diǎn)，而是相互關(guān)聯(lián)、層層遞進(jìn)的體系。理解這些概念的關(guān)鍵在于動手實踐，而非僅僅閱讀文檔。

本文針對 2026 年最新的 Kubernetes 進(jìn)行講解，所有命令和示例均在 Ubuntu 24.04 LTS 或 CentOS Stream 9 環(huán)境下驗證通過。目標(biāo)讀者為具備 Linux 基礎(chǔ)和 Docker 使用經(jīng)驗的初中級運(yùn)維工程師。

概念一：Control Plane 與 Worker Node 的職責(zé)邊界

1.1 架構(gòu)概述

Kubernetes 集群由 Control Plane 和 Worker Node 兩部分組成。Control Plane 負(fù)責(zé)集群的管理和控制，Worker Node 負(fù)責(zé)運(yùn)行工作負(fù)載。

Control Plane 的核心組件包括：

kube-apiserver：集群的統(tǒng)一入口，處理所有 RESTful 請求。

etcd：分布式鍵值存儲，保存集群的所有狀態(tài)數(shù)據(jù)。

kube-scheduler：調(diào)度器，為 Pod 選擇最佳節(jié)點(diǎn)。

kube-controller-manager：運(yùn)行各種控制器，執(zhí)行集群管理任務(wù)。

cloud-controller-manager：與云廠商交互，管理云資源。

Worker Node 的核心組件包括：

kubelet：與 API Server 通信，管理節(jié)點(diǎn)上的 Pod。

kube-proxy：維護(hù)網(wǎng)絡(luò)規(guī)則，實現(xiàn) Service 通信。

container-runtime：容器運(yùn)行時，如 containerd 或 cri-o。

1.2 常見誤解

新手常犯的錯誤是混淆了 Control Plane 和 Worker Node 的職責(zé)。例如，試圖在 Worker Node 上查看 etcd 數(shù)據(jù)或 API Server 日志。

查看 Control Plane 組件狀態(tài)：

# 查看 Control Plane 組件健康狀態(tài)
kubectl get componentstatuses
kubectl get cs

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

查看 etcd 狀態(tài)（需要在 Control Plane 節(jié)點(diǎn)上執(zhí)行）：

# 查看 etcd 集群健康狀態(tài)
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 的通信機(jī)制

kubelet 與 API Server 之間采用雙向 TLS 認(rèn)證機(jī)制：

API Server 需要驗證 kubelet 的證書，確保請求來自合法的節(jié)點(diǎn)。

kubelet 需要驗證 API Server 的證書，確保連接的是真正的 API Server。

查看 kubelet 的認(rèn)證配置：

# 查看 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 最重要的隔離機(jī)制之一，但新手往往低估了它的作用范圍。

命名空間隔離的內(nèi)容：資源對象（Pod、Service、Deployment 等）、RBAC 權(quán)限、網(wǎng)絡(luò)策略、資源配額。

命名空間不隔離的內(nèi)容：Node、PersistentVolume、CustomResourceDefinition。

查看集群中的命名空間：

kubectl get namespaces
kubectl describe namespace production

命名空間級別的資源查看：

# 默認(rèn)查看 default 命名空間
kubectl get pods

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

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

# 查看所有命名空間的所有資源
kubectl get all -A

2.2 跨命名空間訪問

跨命名空間訪問是新手容易混淆的地方。Kubernetes 中的 Service 訪問遵循以下規(guī)則：

同命名空間內(nèi)訪問：直接使用 Service 名稱即可。

跨命名空間訪問：使用 Service 名稱加上命名空間，格式為servicename.namespacename.svc.cluster.local。

# 在 default 命名空間中訪問 production 命名空間的 nginx-service
# 完整格式
nginx-service.production.svc.cluster.local

# 簡寫格式（在同一命名空間內(nèi)）
nginx-service.production

實際測試：

# 創(chuàng)建測試 Pod
kubectl run -it --rm debug --image=busybox:1.36 -- sh

# 在 Pod 內(nèi)測試 DNS 解析
nslookup kubernetes.default
nslookup nginx-service.production.svc.cluster.local

# 測試跨命名空間訪問
wget -qO- http://nginx-service.production.svc.cluster.local:80

2.3 資源配額與限制

命名空間級別的資源配額是生產(chǎn)環(huán)境的必備配置：

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 設(shè)置默認(rèn)資源限制：

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 與數(shù)據(jù)一致性

3.1 Etcd 的核心地位

Etcd 是 Kubernetes 的大腦，所有集群狀態(tài)都存儲在 etcd 中。如果 etcd 出現(xiàn)問題，整個集群將無法正常工作。

Etcd 采用 Raft 一致性算法，保證數(shù)據(jù)在多個節(jié)點(diǎn)間的一致性。生產(chǎn)環(huán)境通常使用 3 或 5 個 etcd 節(jié)點(diǎn)。

Etcd 的關(guān)鍵特性：

強(qiáng)一致性：所有讀寫操作都保證線性一致性。

高可用：少數(shù)節(jié)點(diǎn)故障不影響集群可用性。

高可靠：數(shù)據(jù)持久化到磁盤，支持快照備份。

3.2 常見故障場景

3.2.1 Etcd 磁盤空間耗盡

這是生產(chǎn)環(huán)境最常見的 etcd 故障。當(dāng)磁盤空間不足時，etcd 可能無法寫入數(shù)據(jù)，導(dǎo)致 API Server 無法處理請求。

排查方法：

# 在 etcd 節(jié)點(diǎn)上查看磁盤使用
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 歷史數(shù)據(jù)
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/

# 設(shè)置自動壓縮（編輯 etcd 啟動參數(shù)）
--auto-compaction-retention=1
--max-snapshots=5
--max-wals=5

3.2.2 Etcd 證書過期

證書過期會導(dǎo)致 etcd 節(jié)點(diǎn)無法通信，集群進(jìn)入不可用狀態(tài)。

檢查證書有效期：

# 查看所有 Kubernetes 證書的過期時間
sudo kubeadm certs check-expiration

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

更新證書：

# 在 Control Plane 節(jié)點(diǎn)上執(zhí)行
sudo kubeadm certs renew all

# 重啟相關(guān)服務(wù)
sudo systemctl restart kubelet

3.3 Etcd 備份與恢復(fù)

定期備份 etcd 是災(zāi)難恢復(fù)的關(guān)鍵：

# 創(chuàng)建快照
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

# 查看快照狀態(tài)
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

# 從快照恢復(fù)
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

概念四：網(wǎng)絡(luò)模型與 CNI 插件

4.1 Kubernetes 網(wǎng)絡(luò)模型原則

Kubernetes 網(wǎng)絡(luò)模型遵循以下基本原則：

每個 Pod 擁有獨(dú)立的 IP 地址，Pod 之間的通信不需要 NAT。

節(jié)點(diǎn)上的代理（kubelet）能夠與該節(jié)點(diǎn)上的所有 Pod 通信。

在不對網(wǎng)絡(luò)進(jìn)行特殊配置的情況下，Pod 可以與所有其他 Pod 通信。

這些原則使得應(yīng)用無需修改即可在不同環(huán)境間遷移。

4.2 CNI 插件的作用

CNI（Container Network Interface）是容器網(wǎng)絡(luò)接口標(biāo)準(zhǔn)，定義了容器運(yùn)行時與網(wǎng)絡(luò)插件之間的接口規(guī)范。

常見的 CNI 插件：

Flannel：簡單的 overlay 網(wǎng)絡(luò)，使用 VXLAN 封裝。適合小型集群。

Calico：高性能三層網(wǎng)絡(luò)，支持 BGP 路由和網(wǎng)絡(luò)策略。適合中大型集群。

Cilium：基于 eBPF 的網(wǎng)絡(luò)方案，提供 L7 網(wǎng)絡(luò)可視化和細(xì)粒度控制。

查看當(dāng)前使用的 CNI 插件：

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

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

# 查看網(wǎng)橋信息
ip link showtypebridge
ip addr show flannel.1

4.3 Pod 網(wǎng)絡(luò)故障排查

4.3.1 同節(jié)點(diǎn) Pod 通信異常

# 查看 Pod 的網(wǎng)絡(luò)命名空間
kubectlexec-it  -- ip addr

# 查看 Pod 的路由表
kubectlexec-it  -- ip route

# 測試 Pod 之間的連通性
kubectlexec-it  -- ping -c 3 

# 查看節(jié)點(diǎn)的網(wǎng)橋和 veth 對
ip link showtypebridge
ip link showtypeveth

4.3.2 跨節(jié)點(diǎn) Pod 通信異常

# 在源節(jié)點(diǎn)上測試
ping -I cni0 

# 查看 CNI 插件的 overlay 網(wǎng)絡(luò)
ip addr show flannel.1 # Flannel
ip addr show calico   # Calico

# 查看路由表
route -n
ip route

4.4 DNS 故障排查

DNS 是 Kubernetes 中最常見的問題來源之一。

CoreDNS 是 Kubernetes 默認(rèn)的 DNS 服務(wù)器，通常以 Deployment 形式運(yùn)行在 kube-system 命名空間。

查看 CoreDNS 狀態(tài)：

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 是否正常運(yùn)行。

DNS 記錄不存在：檢查 Service 和 Pod 的命名和標(biāo)簽是否正確。

DNS 緩存問題：檢查是否存在舊的 DNS 記錄。

測試 DNS：

# 創(chuàng)建調(diào)試 Pod
kubectl run -it --rm dnsutils --image=tutum/dnsutils -- sh

# 測試 DNS 解析
nslookup kubernetes
nslookup kubernetes.default.svc.cluster.local
nslookup 
nslookup .
nslookup ..svc.cluster.local

# 測試 DNS 響應(yīng)時間
time nslookup kubernetes.default.svc.cluster.local

概念五：存儲卷與持久化存儲

5.1 存儲卷的類型

Kubernetes 存儲卷分為多種類型，每種類型有不同的使用場景。

臨時存儲卷：emptyDir，用于臨時數(shù)據(jù)存儲，Pod 刪除后數(shù)據(jù)丟失。

本地存儲卷：hostPath、local，用于節(jié)點(diǎn)級別的持久化存儲。

網(wǎng)絡(luò)存儲卷：NFS、Ceph、GlusterFS，用于跨節(jié)點(diǎn)共享存儲。

云存儲卷：AWS EBS、GCE PD、Azure Disk，用于云環(huán)境的高可用存儲。

5.2 PersistentVolume 與 PersistentVolumeClaim

PersistentVolume（PV）是集群級別的存儲資源，由管理員或存儲系統(tǒng)自動配置。

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 存儲類與動態(tài) provisioning

StorageClass 允許動態(tài)創(chuàng)建 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 狀態(tài)

# 查看 PVC 詳情
kubectl describe pvc 

# 常見原因：
# 1. 沒有滿足條件的 PV
# 2. StorageClass 不存在
# 3. 存儲配額不足

# 排查 StorageClass
kubectl get storageclass
kubectl describe storageclass 

# 查看所有 PV
kubectl get pv

5.4.2 Pod 無法掛載存儲卷

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

# 常見錯誤：
# Unable to attach or mount volumes: timeout expired
# node has pod with unmet topology requirement

# 查看節(jié)點(diǎn)的存儲卷信息
kubectl get pv  -o yaml | grep -A 5 nodeAffinity

概念六：認(rèn)證、授權(quán)與 RBAC

6.1 Kubernetes 的認(rèn)證機(jī)制

Kubernetes 支持多種認(rèn)證方式：

X509 客戶端證書：最常用的方式，CA 簽發(fā)證書標(biāo)識用戶身份。

靜態(tài)令牌：Bearer Token，簡單但安全性較低。

ServiceAccount 令牌：Pod 使用的服務(wù)賬號令牌。

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

查看集群的認(rèn)證配置：

# 查看 API Server 的認(rèn)證配置
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -E"authentication|authorization"

# 查看當(dāng)前用戶的認(rèn)證信息
kubectl config view --raw

6.2 RBAC 權(quán)限模型

RBAC（Role-Based Access Control）是 Kubernetes 默認(rèn)的授權(quán)模式。

核心概念：

Role 和 ClusterRole：定義一組權(quán)限規(guī)則。

RoleBinding 和 ClusterRoleBinding：將權(quán)限綁定到用戶或組。

Role 作用于命名空間，ClusterRole 作用于整個集群。

# 定義只讀權(quán)限
apiVersion:rbac.authorization.k8s.io/v1
kind:Role
metadata:
name:pod-reader
namespace:default
rules:
-apiGroups:[""]
resources:["pods"]
verbs:["get","list","watch"]

# 綁定權(quán)限到用戶
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 常見權(quán)限問題排查

6.3.1 權(quán)限不足錯誤

# 查看錯誤信息
kubectl get pods
Error from server (Forbidden): pods is forbidden: User"systemworker1"cannot list resource"pods"inAPI group""inthe namespace"default"

# 診斷步驟
# 1. 確認(rèn)當(dāng)前用戶/ServiceAccount
kubectl config current-context

# 2. 查看用戶擁有的角色
kubectl auth can-i --list --as=systemworker1

# 3. 測試特定權(quán)限
kubectl auth can-i get pods --as=systemworker1
kubectl auth can-i delete pods --as=systemworker1

6.3.2 調(diào)試 RBAC 配置

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

# 查看特定 ServiceAccount 的權(quán)限
kubectl auth can-i list pods --as=systemdefault:default

# 遞歸查看所有權(quán)限（使用 rbac-lookup 工具）
kubectl rbac-lookup  --kind=User

6.4 ServiceAccount 的使用

每個 Pod 都有一個關(guān)聯(lián)的 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 內(nèi)使用 ServiceAccount 令牌訪問 API Server：

# 在 Pod 內(nèi)查看令牌
kubectlexec-it my-app -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

# 使用令牌訪問 API Server
kubectlexec-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)"

綜合排障流程

當(dāng)遇到 Kubernetes 集群問題時，建議按照以下流程逐步排查：

第一步：確認(rèn)問題范圍

# 查看集群所有組件狀態(tài)
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

第二步：逐層排查資源狀態(tài)

# 1. 檢查 Deployment 狀態(tài)
kubectl get deployment -A
kubectl describe deployment  -n 

# 2. 檢查 ReplicaSet 狀態(tài)
kubectl get rs -A
kubectl describe rs  -n 

# 3. 檢查 Pod 狀態(tài)
kubectl get pods -A
kubectl describe pod  -n 

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

第三步：檢查網(wǎng)絡(luò)連通性

# 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 間連通性
kubectlexec-it  -- ping -c 3 

第四步：檢查資源配額

# 檢查命名空間資源配額
kubectl describe namespace  | grep -A 10"ResourceQuota"

# 檢查 LimitRange
kubectl describe limitrange -n 

# 檢查節(jié)點(diǎn)資源使用
kubectl describe node  | grep -A 10"Allocated resources"

最佳實踐建議

集群部署

生產(chǎn)環(huán)境應(yīng)使用 kubeadm 進(jìn)行高可用部署，Control Plane 至少 3 個節(jié)點(diǎn)，etcd 使用 3 或 5 節(jié)點(diǎn)集群。

命名規(guī)范

建立統(tǒng)一的命名規(guī)范，包括命名空間名稱、資源標(biāo)簽、注釋等。建議使用以下標(biāo)準(zhǔn)標(biāo)簽：

app.kubernetes.io/name：應(yīng)用名稱

app.kubernetes.io/instance：應(yīng)用實例名稱

app.kubernetes.io/version：應(yīng)用版本

app.kubernetes.io/component：組件類型

app.kubernetes.io/part-of：所屬應(yīng)用

監(jiān)控告警

部署 Prometheus + Grafana 監(jiān)控集群組件狀態(tài)，配置關(guān)鍵指標(biāo)告警：

API Server 請求延遲

etcd 磁盤使用率和集群健康狀態(tài)

kubelet 的 Pod 啟動失敗數(shù)

節(jié)點(diǎn)資源使用率

定期維護(hù)

建立定期維護(hù)機(jī)制，包括 etcd 快照備份、證書檢查和更新、日志清理、存儲卷清理等。

總結(jié)

Kubernetes 的六個核心概念——Control Plane 與 Worker Node 職責(zé)邊界、命名空間隔離、etcd 數(shù)據(jù)一致性、網(wǎng)絡(luò)模型與 CNI 插件、存儲卷與持久化、認(rèn)證授權(quán)與 RBAC——構(gòu)成了理解集群的基礎(chǔ)框架。

這六個概念相互關(guān)聯(lián)：Control Plane 通過 etcd 保存集群狀態(tài)，命名空間提供資源隔離，網(wǎng)絡(luò)模型實現(xiàn) Pod 通信，存儲卷提供持久化能力，RBAC 控制權(quán)限訪問。

遇到問題時，按照數(shù)據(jù)流和控制邏輯逐層排查，善用 kubectl describe 和 kubectl logs 命令，查看 Events 是快速定位問題的關(guān)鍵。