Docker 解决的是“如何运行容器”，而 Kubernetes 进一步解决的是“如何在一组机器上持续、可靠地运行和管理大量容器”。

Kubernetes 的核心不是某一条 kubectl 命令，而是理解 Cluster、Node、Pod、Deployment、Service、ConfigMap、Secret、PV/PVC、Ingress、调度与网络 之间的关系。

一、Kubernetes 概述#

1.1 什么是 Kubernetes#

Kubernetes（简称 K8s）是一个用于管理容器化工作负载和服务的平台，核心思想是通过声明式配置和控制器自动维护集群的目标状态。

Docker 更关注：

1
运行一个容器

而 Kubernetes 关注：

1
运行一组应用
2
 ↓
3
保持副本数量
4
 ↓
5
发现服务
6
 ↓
7
分配资源
8
 ↓
9
故障自动恢复
10
 ↓
11
滚动更新
12
 ↓
13
扩缩容

例如：

1
应用要求：
2
3 个 Web 实例
3

4
Kubernetes
5
    │
6
    ├── Pod 1
7
    ├── Pod 2
8
    └── Pod 3

如果其中一个 Pod 出现故障：

1
Pod 1
2
  X

控制器会根据声明的目标状态创建新的 Pod，使系统重新回到：

1
Pod 1
2
Pod 2
3
Pod 3

这就是 Kubernetes 中非常重要的：

1
Desired State

与：

1
Actual State

之间的持续协调。

Kubernetes 官方概念文档： Kubernetes Concepts

1.2 Kubernetes 的核心特点#

Kubernetes 的典型能力包括：

1
容器编排
2
自动调度
3
服务发现
4
负载分发
5
故障自愈
6
滚动更新
7
水平扩缩容
8
配置管理
9
存储管理
10
资源管理

因此 Kubernetes 并不是简单的：

1
“Docker 的批量启动器”

它实际上提供了一套完整的：

1
集群控制系统

二、Kubernetes Cluster 与 Node#

2.1 Cluster#

Cluster（集群）是 Kubernetes 的整体运行环境。

可以简单理解为：

1
Kubernetes Cluster
2
│
3
├── Control Plane
4
│
5
└── Worker Nodes
6
    ├── Node 1
7
    ├── Node 2
8
    └── Node 3

Kubernetes 官方架构中，一个集群由控制平面和一个或多个工作节点组成。控制平面负责管理集群状态，Worker Node 负责运行 Pod。

2.2 Control Plane#

Control Plane 可以理解为 Kubernetes 的“大脑”。

主要组件：

1
kube-apiserver
2
etcd
3
kube-scheduler
4
kube-controller-manager

其中：

kube-apiserver#

Kubernetes 的 API 入口。

1
kubectl
2
   │
3
   ▼
4
kube-apiserver

所有主要的集群资源操作都会通过 Kubernetes API 进行。

etcd#

用于保存 Kubernetes 的集群状态和 API 数据。

1
kube-apiserver
2
      │
3
      ▼
4
     etcd
5
      │
6
      └── Cluster State

可以把它理解成 Kubernetes 的核心状态存储。

kube-scheduler#

负责给尚未绑定 Node 的 Pod 选择合适的节点。

1
Pending Pod
2
    │
3
    ▼
4
kube-scheduler
5
    │
6
    ▼
7
Node

kube-controller-manager#

运行各种 Controller，不断比较：

1
Desired State
2
      vs
3
Actual State

然后执行对应操作。

例如 Deployment 想要：

1
replicas = 3

当前只有：

1
2 Pods

Controller 就会推动系统创建第 3 个 Pod。

2.3 Worker Node#

Worker Node 是真正运行工作负载的节点。

主要组件包括：

1
kubelet
2
container runtime
3
kube-proxy（传统 Service 实现中）

其中：

kubelet#

kubelet 运行在每个 Node 上，负责确保 Pod 中声明的容器处于运行状态。

可以理解为：

1
Control Plane
2
      │
3
      ▼
4
Node
5
      │
6
   kubelet
7
      │
8
      ▼
9
   Container

Container Runtime#

负责实际运行容器。

例如：

1
containerd
2
CRI-O

Kubernetes 通过 CRI 与容器运行时协作。

kube-proxy#

在传统 Kubernetes Service 实现中，kube-proxy 负责在节点上维护实现 Service 流量转发所需的网络规则。

需要注意：

kube-proxy 并不是 Kubernetes Pod 网络本身。Pod 网络由 CNI 等网络实现负责。

三、Pod#

3.1 Pod 是什么#

Pod 是 Kubernetes 中最小的可部署计算对象。

一个 Pod 可以包含一个或多个容器，这些容器共享：

1
Network
2
Storage
3
生命周期

并且通常会被调度到同一个 Node。

最常见的情况：

1
Pod
2
└── Container

但也可以：

1
Pod
2
├── App Container
3
└── Sidecar Container

例如：

1
Pod
2
├── application
3
└── log-agent

3.2 Pod 网络#

每个 Pod 在 Kubernetes 网络模型中拥有自己的 IP。

同一个 Pod 内的容器共享网络命名空间，因此可以通过：

1
localhost

互相通信。

例如：

1
Pod
2
├── app :8080
3
└── sidecar :9000

两个容器可以：

1
localhost:8080
2
localhost:9000

但由于共享同一个网络命名空间，一个 Pod 内两个容器不能同时监听完全相同的端口。

3.3 Pod 为什么通常不直接管理#

虽然可以直接创建 Pod：

1
kubectl run nginx --image=nginx

但生产环境一般不直接管理裸 Pod，而是交给：

1
Deployment
2
StatefulSet
3
DaemonSet
4
Job
5
CronJob

等更高级的控制器管理。

最常见的无状态应用：

1
Deployment
2
   ↓
3
ReplicaSet
4
   ↓
5
Pods

四、Namespace#

Namespace 用于在同一个 Kubernetes Cluster 中对资源进行逻辑隔离。

例如：

1
Cluster
2
│
3
├── default
4
│   ├── web
5
│   └── redis
6
│
7
├── dev
8
│   ├── web
9
│   └── redis
10
│
11
└── prod
12
    ├── web
13
    └── redis

查看：

1
kubectl get namespaces

也可以：

1
kubectl get ns

创建：

1
kubectl create namespace dev

之后：

1
kubectl get pods -n dev

这样就能只查看 dev Namespace 中的 Pod。

Namespace 并不是完整的安全边界，但它是 Kubernetes 中组织和隔离资源的重要机制。

五、使用 kubectl 管理 Kubernetes#

kubectl 是 Kubernetes 最常用的命令行工具。

基本结构：

1
kubectl
2
   │
3
   ├── get
4
   ├── describe
5
   ├── create
6
   ├── apply
7
   ├── edit
8
   ├── exec
9
   └── delete

5.1 kubectl get#

查看资源：

1
kubectl get pods

查看 Deployment：

1
kubectl get deployments

查看 Service：

1
kubectl get svc

查看所有 Namespace：

1
kubectl get ns

查看 Node：

1
kubectl get nodes

查看更多信息：

1
kubectl get pods -o wide

5.2 kubectl describe#

查看资源详细信息：

1
kubectl describe pod nginx

它特别适合故障排查。

例如可以看到：

1
Events
2
Volumes
3
Containers
4
Conditions
5
Node
6
Image

后面的很多故障排查都离不开：

1
kubectl describe

5.3 kubectl create#

例如：

1
kubectl create deployment nginx \
2
  --image=nginx

创建 Namespace：

1
kubectl create namespace dev

5.4 kubectl apply#

Kubernetes 非常强调声明式配置。

例如：

1
kubectl apply -f deployment.yaml

意思不是：

1
执行一堆命令

而是：

1
“让集群状态变成 YAML 描述的状态”

因此实际生产环境中经常使用：

1
YAML
2
   ↓
3
kubectl apply
4
   ↓
5
Kubernetes API

5.5 kubectl edit#

可以直接编辑正在运行的资源：

1
kubectl edit deployment nginx

Kubernetes 会打开资源当前的 YAML 表示。

不过生产环境通常更推荐：

1
修改 Git 中的 YAML
2
      ↓
3
提交
4
      ↓
5
部署

而不是长期直接手工 kubectl edit，这样更容易保持配置可追踪和可审计。

5.6 kubectl exec#

进入容器：

1
kubectl exec -it nginx -- /bin/sh

如果 Pod 中有多个容器，可以指定：

1
kubectl exec -it nginx \
2
  -c app \
3
  -- /bin/sh

常用于排查：

1
配置
2
DNS
3
网络
4
文件
5
环境变量
6
进程

5.7 kubectl delete#

删除资源：

1
kubectl delete pod nginx

或者：

1
kubectl delete -f deployment.yaml

需要注意：

如果 Pod 由 Deployment 管理：

1
Deployment
2
   ↓
3
ReplicaSet
4
   ↓
5
Pod

直接删除 Pod：

1
kubectl delete pod nginx

并不一定意味着应用永久减少一个副本。

Controller 会发现：

1
Desired = 3
2
Actual = 2

然后重新创建 Pod。

六、Deployment 与 ReplicaSet#

6.1 Deployment#

Deployment 用于声明和管理无状态应用的副本以及更新。

例如：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx
5
spec:
6
  replicas: 3
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx:latest
18
          ports:
19
            - containerPort: 80

应用：

1
kubectl apply -f deployment.yaml

查看：

1
kubectl get deployment

查看 Pod：

1
kubectl get pods

6.2 ReplicaSet#

Deployment 通常不会直接管理 Pod，而是通过 ReplicaSet：

1
Deployment
2
     │
3
     ▼
4
ReplicaSet
5
     │
6
     ├── Pod
7
     ├── Pod
8
     └── Pod

例如：

1
replicas: 3

意味着 ReplicaSet 会尽可能维持：

1
3 Pods

6.3 自愈#

假设：

1
Pod A
2
Pod B
3
Pod C

其中 Pod B 崩溃：

1
Pod A
2
Pod B X
3
Pod C

ReplicaSet 会发现实际数量变成：

1
2

于是创建：

1
Pod D

恢复：

1
Pod A
2
Pod C
3
Pod D

这就是 Kubernetes 的控制器模型。

6.4 Deployment 更新#

修改镜像：

1
nginx:1.27
2
↓
3
nginx:1.28

然后：

1
kubectl apply -f deployment.yaml

Deployment 会创建新的 ReplicaSet，并逐步替换旧 Pod。

1
Deployment
2
    │
3
    ├── Old ReplicaSet
4
    │      ├── Pod
5
    │      └── Pod
6
    │
7
    └── New ReplicaSet
8
           ├── Pod
9
           └── Pod

这就是常见的：

1
Rolling Update

查看发布状态：

1
kubectl rollout status deployment/nginx

查看历史：

1
kubectl rollout history deployment/nginx

回滚：

1
kubectl rollout undo deployment/nginx

七、Service 与 Kubernetes 网络#

Pod 有 IP，但是 Pod 本身并不适合作为稳定的访问入口。

因为 Pod 可能：

1
被删除
2
被重新创建
3
被调度到其他 Node
4
IP 改变

因此 Kubernetes 使用 Service 为一组 Pod 提供稳定的网络入口。

Kubernetes 官方网络模型中，Service 提供稳定的 IP 或 DNS 名称，并通过 EndpointSlice 记录当前后端 Pod。

7.1 Service#

例如：

1
             Service
2
           10.96.10.20
3
                │
4
       ┌────────┼────────┐
5
       ▼        ▼        ▼
6
     Pod A    Pod B    Pod C

Service 一般通过：

1
Label Selector

选择后端 Pod。

例如：

1
selector:
2
  app: nginx

对应：

1
labels:
2
  app: nginx

7.2 ClusterIP#

默认类型：

1
type: ClusterIP

它主要用于集群内部访问。

例如：

1
backend
2
   │
3
   ▼
4
redis.default.svc.cluster.local
5
   │
6
   ▼
7
Redis Pods

可以通过 Service 的 DNS 名称访问。

7.3 NodePort#

NodePort 会在节点上开放一个端口。

例如：

1
type: NodePort

结构：

1
Client
2
  │
3
  ▼
4
NodeIP:30080
5
  │
6
  ▼
7
Service
8
  │
9
  ▼
10
Pod

因此可以通过：

1
<NodeIP>:NodePort

访问服务。

7.4 LoadBalancer#

在支持云厂商负载均衡器的环境中，可以使用：

1
type: LoadBalancer

典型结构：

1
Internet
2
   │
3
   ▼
4
Cloud Load Balancer
5
   │
6
   ▼
7
Service
8
   │
9
   ▼
10
Pods

如果是裸机环境，则需要额外的 LoadBalancer 实现，例如 MetalLB 等方案。

7.5 Service 的本质#

可以把 Service 理解成：

1
稳定入口
2
   +
3
Pod 集合

因此：

1
Pod
2
→ 容易变化
3

4
Service
5
→ 提供稳定访问入口

八、Kubernetes 集群网络基础#

Kubernetes 网络涉及多个层次：

1
Container → Container
2
Pod → Pod
3
Pod → Service
4
External → Service

官方文档把这些视为不同的网络问题。

8.1 Pod 网络#

每个 Pod 获得一个集群范围内唯一的 IP。

基本模型是：

1
Pod A
2
10.244.1.10
3
   │
4
   │
5
   ▼
6
Pod B
7
10.244.2.20

即使两个 Pod 位于不同 Node：

1
Node 1
2
  └── Pod A
3

4
Node 2
5
  └── Pod B

也应该能够按照 Kubernetes 网络模型直接通信。

8.2 CNI#

Kubernetes 本身定义网络模型，但不会替你实现整个 Pod 网络。

通常通过 CNI（Container Network Interface）插件实现 Pod 网络。

常见方案包括：

1
Cilium
2
Calico
3
Flannel

其职责可能涉及：

1
Pod IP 分配
2
跨节点 Pod 通信
3
网络路由
4
NetworkPolicy

因此：

1
Kubernetes
2
   │
3
   └── 网络模型
4

5
CNI
6
   │
7
   └── 具体网络实现

8.3 Service 网络#

Service 是另一层抽象：

1
Pod IP
2
   ↓
3
Service IP
4
   ↓
5
Service Backend

所以排查 Kubernetes 网络问题时，不应该把：

1
Pod IP
2
Service IP
3
Node IP

混为一谈。

九、ConfigMap 与 Secret#

Kubernetes 支持把应用配置与容器镜像分离。

9.1 ConfigMap#

ConfigMap 用于保存：

1
非敏感配置

例如：

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: app-config
5
data:
6
  APP_ENV: production
7
  LOG_LEVEL: info

创建：

1
kubectl apply -f configmap.yaml

ConfigMap 可以通过：

1
环境变量
2
命令参数
3
Volume

等方式提供给 Pod。

9.2 Secret#

Secret 用于保存：

1
密码
2
Token
3
密钥
4
证书

例如：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: app-secret
5
type: Opaque
6
stringData:
7
  DB_USER: app
8
  DB_PASSWORD: example

需要注意：

Secret 主要表达“这是敏感数据”，并不意味着数据天然就具备完整的安全保护。

生产环境还应该考虑：

1
RBAC
2
API Server 安全
3
静态数据加密
4
外部 Secret 管理系统
5
访问审计

Kubernetes 官方文档也将 Secret 与 ConfigMap 区分开：ConfigMap 用于非机密配置，Secret 面向密码、Token、Key 等敏感数据。

9.3 为什么配置应该与镜像分离#

不推荐：

1
Docker Image
2
  └── production-config

更推荐：

1
Application Image
2
       +
3
ConfigMap / Secret

这样：

1
同一个 Image
2
      │
3
      ├── dev
4
      ├── test
5
      └── prod

只需要注入不同配置。

十、Kubernetes Volume、PV 与 PVC#

10.1 Volume#

Pod 可以声明 Volume。

例如：

1
volumes:
2
  - name: data
3
    emptyDir: {}

然后挂载：

1
volumeMounts:
2
  - name: data
3
    mountPath: /data

10.2 emptyDir#

emptyDir 会随着 Pod 创建而产生一个空目录。

1
Pod
2
└── emptyDir
3
       └── /data

适用于：

1
临时文件
2
缓存
3
Pod 内多个容器共享临时数据

但 Pod 被删除后，该 Volume 中的数据也会消失。

因此：

1
emptyDir
2
≠
3
持久化存储

10.3 PersistentVolume#

PV（PersistentVolume）代表集群中的持久化存储资源。

1
Storage
2
   │
3
   ▼
4
PersistentVolume

它可以来自不同存储后端。

10.4 PersistentVolumeClaim#

PVC（PersistentVolumeClaim）是工作负载对存储的请求：

1
Pod
2
 │
3
 ▼
4
PVC
5
 │
6
 ▼
7
PV
8
 │
9
 ▼
10
Storage

例如：

1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: app-data
5
spec:
6
  accessModes:
7
    - ReadWriteOnce
8
  resources:
9
    requests:
10
      storage: 10Gi

Pod 使用 PVC：

1
volumes:
2
  - name: data
3
    persistentVolumeClaim:
4
      claimName: app-data

这样应用就不需要直接关心底层磁盘的具体实现。

十一、Ingress 与 HTTP 流量管理#

11.1 Ingress#

Ingress 用于描述从集群外部进入 Kubernetes Service 的 HTTP/HTTPS 路由。

例如：

1
                Internet
2
                    │
3
                    ▼
4
                 Ingress
5
              /     |     \
6
             /      |      \
7
            ▼       ▼       ▼
8
          web     api     admin
9
           │        │        │
10
        Service  Service  Service

Ingress 可以根据：

1
Host
2
Path

进行路由。

例如：

1
example.com/
2
        ↓
3
web-service
4

5
example.com/api
6
        ↓
7
api-service
8

9
admin.example.com
10
        ↓
11
admin-service

11.2 Ingress Controller#

Ingress 资源本身只是 API 对象，并不会自动处理网络流量。

需要实际的 Ingress Controller：

1
Ingress
2
    │
3
    ▼
4
Ingress Controller
5
    │
6
    ▼
7
Service

常见实现包括：

1
NGINX Ingress Controller
2
Traefik
3
HAProxy

具体选择取决于集群和平台。

11.3 Ingress 的当前定位#

Ingress API 从 Kubernetes v1.19 起稳定，但目前已经冻结，不再继续增加新的 API 功能；Kubernetes 官方推荐新项目考虑 Gateway API。

因此学习 Ingress 仍然非常重要，因为大量现有 Kubernetes 集群仍在使用它：

1
历史与现有系统
2
→ Ingress
3

4
新的流量管理设计
5
→ Gateway API

11.4 Ingress 不是什么#

Ingress 主要针对：

1
HTTP
2
HTTPS

它不是一个通用 TCP/UDP 端口代理。

如果需要暴露其他协议，通常仍然会使用：

1
NodePort
2
LoadBalancer
3
Gateway

等方案。

十二、资源请求、限制与调度#

Kubernetes 调度的重要输入之一，就是 Pod 对资源的声明。

最常见的是：

1
CPU
2
Memory

12.1 Requests#

例如：

1
resources:
2
  requests:
3
    cpu: "500m"
4
    memory: "512Mi"

可以理解为：

1
“我至少希望调度系统为我考虑这么多资源”

Scheduler 会根据 Pod 的资源请求等条件选择合适的 Node。

12.2 Limits#

例如：

1
resources:
2
  limits:
3
    cpu: "1"
4
    memory: "1Gi"

用于限制容器可以使用的资源上限。

因此：

1
requests
2
→ 调度参考
3

4
limits
5
→ 资源约束

Kubernetes 官方资源管理文档将 Requests、Limits 作为工作负载资源管理的核心机制。

12.3 CPU#

Kubernetes 中：

1
1 CPU
2
= 1 个 CPU 核心或对应计算单位

例如：

1
500m

表示：

1
0.5 CPU

12.4 Memory#

例如：

1
512Mi
2
1Gi
3
2Gi

表示内存大小。

12.5 为什么必须合理设置资源#

如果没有合理的资源声明：

1
Node
2
 ├── App A
3
 ├── App B
4
 └── App C

其中 App A 可能不断消耗资源：

1
Memory ↑↑↑
2
CPU    ↑↑↑

最终影响整个 Node。

因此 Kubernetes 需要结合：

1
Requests
2
Limits
3
QoS
4
Scheduling
5
Eviction

来进行资源管理。

十三、Kubernetes 调度#

Scheduler 的基本流程可以理解成：

1
Pending Pod
2
      │
3
      ▼
4
Scheduler
5
      │
6
      ├── Node 是否满足资源？
7
      ├── 是否满足约束？
8
      ├── 是否存在污点？
9
      ├── 是否满足亲和性？
10
      └── ...
11
      │
12
      ▼
13
选择 Node

例如：

1
Node A
2
CPU: 剩余 100m
3

4
Pod 需要：
5
CPU: 500m

那么 Pod 不适合调度到 Node A。

而：

1
Node B
2
CPU: 剩余 2 CPU

则更适合。

因此：

Kubernetes 调度不是简单地“找一台空闲机器”。

它需要综合考虑资源、节点属性和各种调度约束。

十四、kubeadm 搭建 Kubernetes 集群#

kubeadm 是 Kubernetes 官方提供的集群引导工具之一。

它适合：

1
学习环境
2
实验环境
3
裸机集群
4
自建 Kubernetes

官方文档： Installing kubeadm

14.1 一个典型集群#

实验环境可以准备：

1
Control Plane
2
192.168.1.10
3

4
Worker Node 1
5
192.168.1.11
6

7
Worker Node 2
8
192.168.1.12

整体：

1
             Control Plane
2
             192.168.1.10
3
                  │
4
        ┌─────────┼─────────┐
5
        ▼         ▼         ▼
6
     Node 1     Node 2    Node ...

14.2 准备条件#

具体要求会随着 Kubernetes 版本和发行版变化，但通常需要准备：

1
Linux
2
稳定主机名 / DNS
3
网络连通
4
容器运行时
5
kubeadm
6
kubelet
7
kubectl

此外还需要正确处理：

1
Swap
2
内核模块
3
sysctl
4
cgroup
5
防火墙 / 端口
6
时间同步

实际部署应该按照目标 Kubernetes 版本对应的官方 kubeadm 文档逐项准备，而不要完全照抄旧教程。

截至 2026 年 9 月，Kubernetes 官方当前维护的最新三个 minor release 为 1.37、1.36、1.35，其中 1.37.0 于 2026 年 8 月 26 日发布。

14.3 安装容器运行时#

Kubernetes Node 需要容器运行时。

常见：

1
containerd
2
CRI-O

例如完成：

1
containerd

安装与配置后，再准备：

1
kubeadm
2
kubelet
3
kubectl

14.4 初始化 Control Plane#

在控制平面节点运行：

1
sudo kubeadm init

实际生产或多网卡环境中通常需要明确指定：

1
apiserver-advertise-address
2
pod-network-cidr
3
control-plane-endpoint

例如：

1
sudo kubeadm init \
2
  --apiserver-advertise-address=192.168.1.10 \
3
  --pod-network-cidr=10.244.0.0/16

这里的：

1
pod-network-cidr

必须与后续选择的 CNI 配置匹配。

14.5 配置 kubectl#

初始化完成后，通常需要为当前用户配置：

1
mkdir -p $HOME/.kube
2

3
sudo cp -i /etc/kubernetes/admin.conf \
4
  $HOME/.kube/config
5

6
sudo chown "$(id -u)":"$(id -g)" \
7
  $HOME/.kube/config

测试：

1
kubectl get nodes

此时可能看到：

1
NAME      STATUS     ROLES           AGE
2
master    NotReady   control-plane   ...

为什么是：

1
NotReady

因为此时通常还没有安装 Pod Network。

14.6 安装 CNI#

接下来安装选定的 CNI，例如：

1
Calico
2
Cilium
3
Flannel

安装后再检查：

1
kubectl get nodes

如果网络配置正常，Node 通常会逐渐变成：

1
Ready

14.7 加入 Worker Node#

在 Worker Node 上先完成：

1
container runtime
2
kubeadm
3
kubelet

然后使用 Control Plane 初始化时生成的 join 命令：

1
kubeadm join <control-plane>:6443 \
2
  --token <token> \
3
  --discovery-token-ca-cert-hash sha256:<hash>

回到 Control Plane：

1
kubectl get nodes

可以看到：

1
NAME      STATUS   ROLES
2
master    Ready    control-plane
3
worker1   Ready    <none>
4
worker2   Ready    <none>

14.8 kubeadm 背后的架构#

使用 kubeadm 后，可以进一步理解：

1
Control Plane
2
├── kube-apiserver
3
├── etcd
4
├── kube-scheduler
5
├── kube-controller-manager
6
└── static Pods
7

8
Worker
9
├── kubelet
10
├── container runtime
11
└── kube-proxy / CNI

kubeadm 常见的控制平面组件可以以 Static Pod 方式运行，这是当前官方 kubeadm 架构中的典型做法。

十五、Kubernetes 日志#

Kubernetes 中排查应用故障时，最常用的命令之一：

1
kubectl logs

15.1 查看 Pod 日志#

1
kubectl logs nginx

持续查看：

1
kubectl logs -f nginx

查看上一次崩溃的容器日志：

1
kubectl logs nginx --previous

15.2 多容器 Pod#

如果 Pod 中有多个容器：

1
kubectl logs nginx -c app

指定：

1
-c <container>

15.3 日志与容器#

通常：

1
Application
2
   │
3
   ├── stdout
4
   └── stderr
5
         │
6
         ▼
7
    Container Runtime
8
         │
9
         ▼
10
 Kubernetes logs

因此应用容器最好能够把关键日志输出到：

1
stdout
2
stderr

而不是只写在容器内部不易收集的文件里。

生产环境再进一步通过日志系统进行集中收集：

1
Pod
2
 │
3
 ▼
4
Log Collector
5
 │
6
 ▼
7
Central Log System

Kubernetes 本身不会强制绑定某一种日志系统。

十六、Events 与故障排查#

很多 Kubernetes 故障不是：

1
Application Exception

而是：

1
Scheduler
2
Image
3
Volume
4
Network
5
Node

层面的问题。

因此：

1
kubectl get events

以及：

1
kubectl describe pod <pod>

非常重要。

16.1 Pod Pending#

例如：

1
STATUS: Pending

排查：

1
kubectl describe pod <pod>

重点看：

1
Events

常见原因：

1
资源不足
2
节点不可用
3
PVC 未绑定
4
调度约束
5
Taint / Toleration

16.2 ImagePullBackOff#

例如：

1
ImagePullBackOff
2
ErrImagePull

重点检查：

1
镜像名称
2
Tag
3
Registry
4
网络
5
认证
6
imagePullSecrets

可以：

1
kubectl describe pod <pod>

查看 Events。

16.3 CrashLoopBackOff#

如果 Pod：

1
启动
2
 ↓
3
崩溃
4
 ↓
5
重启
6
 ↓
7
再次崩溃

最终可能出现：

1
CrashLoopBackOff

重点检查：

1
kubectl logs <pod>
2
kubectl logs <pod> --previous
3
kubectl describe pod <pod>

常见原因：

1
配置错误
2
环境变量错误
3
依赖服务不可用
4
启动命令错误
5
权限问题
6
应用本身崩溃

16.4 Service 无法访问#

排查顺序：

1
Pod
2
 ↓
3
Pod IP
4
 ↓
5
Pod Label
6
 ↓
7
Service Selector
8
 ↓
9
EndpointSlice
10
 ↓
11
Service
12
 ↓
13
Ingress / LoadBalancer

例如：

1
kubectl get pods --show-labels

检查：

1
kubectl get svc

然后：

1
kubectl get endpointslices

如果 Service 存在：

1
Service

但没有对应后端：

1
EndpointSlice = empty

通常需要检查：

1
Selector
2
Labels
3
Pod Ready 状态

十七、Kubernetes 存储故障#

如果：

1
Pod
2
   ↓
3
PVC
4
   ↓
5
PV

其中任何一层异常，都可能导致 Pod 无法正常运行。

检查：

1
kubectl get pvc
2
kubectl get pv

详细信息：

1
kubectl describe pvc <name>

常见问题：

1
PVC Pending
2
StorageClass 不存在
3
PV 无法绑定
4
权限错误
5
CSI 异常
6
存储后端不可用

因此 Kubernetes 存储排查不能只看：

1
Pod

而要一直追踪到：

1
Pod
2
 ↓
3
PVC
4
 ↓
5
PV
6
 ↓
7
StorageClass / CSI
8
 ↓
9
Storage Backend

十八、Kubernetes 网络故障排查#

网络排查需要区分：

1
Pod → Pod
2
Pod → Service
3
Node → Pod
4
External → Service

18.1 Pod → Pod#

检查 Pod：

1
kubectl get pods -o wide

查看 Pod IP 和 Node。

然后进入容器：

1
kubectl exec -it <pod> -- /bin/sh

测试：

1
ping <pod-ip>

或者：

1
curl http://<pod-ip>:8080

18.2 Pod → Service#

先查看：

1
kubectl get svc

再查看 EndpointSlice：

1
kubectl get endpointslices

检查 DNS：

1
kubectl exec -it <pod> -- \
2
  nslookup <service-name>

18.3 External → Service#

如果使用：

1
NodePort
2
LoadBalancer
3
Ingress

则需要继续检查：

1
外部入口
2
 ↓
3
Node / LoadBalancer
4
 ↓
5
Service
6
 ↓
7
EndpointSlice
8
 ↓
9
Pod

任何一层异常，都可能导致：

1
浏览器访问失败

十九、Helm 基础#

当 Kubernetes YAML 增多以后，直接维护大量 YAML 会变得复杂。

例如一个生产应用可能包含：

1
Deployment
2
Service
3
ConfigMap
4
Secret
5
Ingress
6
PVC
7
HPA
8
ServiceAccount

于是出现了 Helm。

19.1 Helm 是什么#

Helm 是 Kubernetes 常见的软件包管理工具。

可以理解为：

1
Helm
2
   │
3
   └── Package Manager
4
             │
5
             ▼
6
        Kubernetes

Helm 中一个应用包通常叫：

1
Chart

一个 Chart 可以包含：

1
Chart.yaml
2
values.yaml
3
templates/

19.2 Helm Chart#

典型结构：

1
myapp/
2
├── Chart.yaml
3
├── values.yaml
4
└── templates/
5
    ├── deployment.yaml
6
    ├── service.yaml
7
    ├── configmap.yaml
8
    └── ingress.yaml

其中：

1
templates/

保存模板。

而：

1
values.yaml

保存可配置参数。

例如：

1
replicaCount: 3
2

3
image:
4
  repository: nginx
5
  tag: "1.28"
6

7
service:
8
  port: 80

19.3 Helm Install#

例如：

1
helm install myapp ./myapp

查看：

1
helm list

卸载：

1
helm uninstall myapp

19.4 Helm Upgrade#

修改：

1
values.yaml

然后：

1
helm upgrade myapp ./myapp

这样可以复用同一个 Chart：

1
dev
2
 ↓
3
values-dev.yaml
4

5
test
6
 ↓
7
values-test.yaml
8

9
prod
10
 ↓
11
values-prod.yaml

而不是维护三套几乎相同的 YAML。

19.5 Helm 的定位#

可以这样理解：

1
Dockerfile
2
→ 构建容器镜像
3

4
Helm
5
→ 打包 Kubernetes 应用部署配置

它不负责替代：

1
Kubernetes

而是帮助更方便地管理 Kubernetes 应用。

二十、Kubernetes 常用命令速查#

虽然 Kubernetes 学习不能只靠背命令，但下面这些命令是日常运维中非常常见的。

1
# Node
2
kubectl get nodes
3
kubectl describe node <node>
4

5
# Pod
6
kubectl get pods
7
kubectl get pods -o wide
8
kubectl describe pod <pod>
9
kubectl logs <pod>
10
kubectl logs <pod> --previous
11
kubectl exec -it <pod> -- /bin/sh
12

13
# Deployment
14
kubectl get deployment
15
kubectl describe deployment <name>
16
kubectl rollout status deployment/<name>
17
kubectl rollout history deployment/<name>
18
kubectl rollout undo deployment/<name>
19

20
# Service
21
kubectl get svc
22
kubectl describe svc <name>
23

24
# Config / Secret
25
kubectl get configmap
26
kubectl get secret
27

28
# Storage
29
kubectl get pv
30
kubectl get pvc
31

32
# Events
33
kubectl get events
34

35
# Namespace
36
kubectl get ns
37

38
# Apply / Delete
39
kubectl apply -f app.yaml
40
kubectl delete -f app.yaml

其中最值得熟悉的是：

1
get
2
describe
3
logs
4
exec
5
apply
6
delete

可以把它们理解成：

1
get
2
→ 看有什么
3

4
describe
5
→ 看为什么
6

7
logs
8
→ 看应用说了什么
9

10
exec
11
→ 进入容器检查
12

13
apply
14
→ 让集群变成声明的状态
15

16
delete
17
→ 删除资源

二十一、Kubernetes 故障排查总模型#

Kubernetes 故障排查最好不要一上来就：

1
kubectl delete pod

而应该先定位故障层级。

1
                    用户访问失败
2
                         │
3
                         ▼
4
                    Ingress / LB
5
                         │
6
                         ▼
7
                      Service
8
                         │
9
                         ▼
10
                     Endpoint
11
                         │
12
                         ▼
13
                        Pod
14
                    ┌────┴────┐
15
                    ▼         ▼
16
                 Container   Volume
17
                    │
18
                    ▼
19
                  Process
20
                    │
21
                    ▼
22
                 Application

如果 Pod 本身有问题：

1
Pod
2
 │
3
 ├── Pending
4
 │
5
 ├── ImagePullBackOff
6
 │
7
 ├── CrashLoopBackOff
8
 │
9
 └── Running but not Ready

就继续沿着：

1
kubectl describe
2
kubectl logs
3
kubectl logs --previous
4
kubectl exec

进行定位。

如果是网络问题：

1
Pod IP
2
 ↓
3
DNS
4
 ↓
5
Service
6
 ↓
7
EndpointSlice
8
 ↓
9
Ingress / LoadBalancer

如果是存储问题：

1
Pod
2
 ↓
3
Volume
4
 ↓
5
PVC
6
 ↓
7
PV
8
 ↓
9
StorageClass / CSI
10
 ↓
11
Storage Backend

如果是调度问题：

1
Pod Pending
2
 ↓
3
Events
4
 ↓
5
Requests
6
 ↓
7
Node
8
 ↓
9
Taint / Affinity
10
 ↓
11
Scheduler

二十二、Docker 与 Kubernetes 的关系#

学习完 Docker 和 Kubernetes，可以把两者放在一起理解。

1
Docker
2
│
3
├── Image
4
├── Container
5
├── Network
6
├── Volume
7
└── Compose

更偏向：

1
单机容器运行与管理

而 Kubernetes：

1
Cluster
2
│
3
├── Node
4
│
5
├── Pod
6
│
7
├── Deployment
8
│
9
├── Service
10
│
11
├── ConfigMap / Secret
12
│
13
├── PV / PVC
14
│
15
├── Ingress / Gateway
16
│
17
└── Scheduler

更偏向：

1
集群级容器编排与管理

两者并不是：

1
Docker
2
VS
3
Kubernetes

的简单竞争关系。

更接近：

1
Container Image
2
      │
3
      ▼
4
Container Runtime
5
      │
6
      ▼
7
 Kubernetes
8
      │
9
      ├── Scheduling
10
      ├── Networking
11
      ├── Storage
12
      ├── Service Discovery
13
      ├── Scaling
14
      └── Self-Healing

二十三、从运维视角理解 Kubernetes#

Docker 学习之后，真正值得建立的是 Kubernetes 的整体运行模型：

1
                        Kubernetes Cluster
2
                               │
3
                ┌──────────────┴──────────────┐
4
                │                             │
5
          Control Plane                    Nodes
6
                │                             │
7
      ┌─────────┼─────────┐          ┌────────┼────────┐
8
      ▼         ▼         ▼          ▼        ▼        ▼
9
   API Server  etcd   Scheduler    kubelet   CNI    Runtime
10
      │
11
      ▼
12
 Controllers
13
      │
14
      ▼
15
Deployment
16
      │
17
      ▼
18
ReplicaSet
19
      │
20
      ▼
21
Pods
22
      │
23
      ├── ConfigMap / Secret
24
      ├── Volume / PVC
25
      └── Resources

对外提供服务：

1
Internet
2
   │
3
   ▼
4
Ingress / Gateway
5
   │
6
   ▼
7
Service
8
   │
9
   ▼
10
Pods
11
   │
12
   ▼
13
Application

真正进行故障排查时：

1
用户
2
 ↓
3
Ingress
4
 ↓
5
Service
6
 ↓
7
Pod
8
 ↓
9
Container
10
 ↓
11
Process
12
 ↓
13
Application

而 Pod 无法启动时：

1
Pod
2
 ↓
3
Scheduler
4
 ↓
5
Node
6
 ↓
7
Image
8
 ↓
9
Runtime
10
 ↓
11
Volume
12
 ↓
13
Network

这就是 Kubernetes 运维中最核心的思维方式：

不要只记资源对象，而要理解一个请求、一个 Pod 和一份配置是怎样穿过整个 Kubernetes 系统的。

二十四、总结#

Kubernetes 的核心知识可以整理成下面这条主线：

1
Cluster
2
   │
3
   ├── Control Plane
4
   │
5
   └── Node
6
        │
7
        ▼
8
       Pod
9
        │
10
        ▼
11
   Deployment
12
        │
13
        ▼
14
    ReplicaSet
15
        │
16
        ▼
17
      Pods
18
        │
19
        ├── ConfigMap
20
        ├── Secret
21
        ├── Volume
22
        └── Resources

网络：

1
Pod
2
 │
3
 ▼
4
Service
5
 │
6
 ├── ClusterIP
7
 ├── NodePort
8
 └── LoadBalancer
9
 │
10
 ▼
11
Ingress / Gateway
12
 │
13
 ▼
14
External Traffic

存储：

1
Pod
2
 ↓
3
PVC
4
 ↓
5
PV
6
 ↓
7
Storage

网络：

1
Pod
2
 ↓
3
CNI
4
 ↓
5
Pod Network
6
 ↓
7
Service Network

运维：

1
kubectl get
2
      ↓
3
kubectl describe
4
      ↓
5
kubectl logs
6
      ↓
7
kubectl exec
8
      ↓
9
Events
10
      ↓
11
Node / Network / Storage / Resource

最终可以用一句话概括 Kubernetes：

Kubernetes 通过声明式 API 和控制器，把分散在多台机器上的容器组织成一个可以自动调度、自动恢复、扩缩容和对外提供稳定服务的集群系统。