K8s on Liangweidong's blog

双机房双集群架构：Redis Cluster 6 节点 + 多服务同步

Tue, 15 Apr 2025 00:00:00 +0800

双机房双集群是什么

同城双机房（Active-Active）是国内中大型生产环境的标配——一个机房挂了，另一个机房能继续服务。K8s 时代实现双机房有几个关键挑战：

集群独立：两个 K8s 集群，apiserver / etcd 都独立
服务双活：nacos / mysql / mqtt / redis 在两边都部署
数据同步：MySQL binlog、MinIO rsync、Loki/Grafana 数据可选同步
VIP + 防火墙：公网域名 + 内网 VIP 飘移

适用版本：K8s 1.28 / Redis 6.2 / EMQX 5.5.1 / 双机房（同城）

1. 整体架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 公网用户
 │
 ┌─────────▼─────────┐
 │ DNS / 防火墙 │
 │ (双 VIP 映射) │
 └──┬──────────────┬──┘
 │ │
 ┌────────▼───┐ ┌────▼───────┐
 │ 机房 1 │ │ 机房 2 │
 │ 10.8.33.x │ │ 10.8.35.x │
 │ ┌────────┐ │ │ ┌────────┐ │
 │ │ K8s │ │ │ │ K8s │ │
 │ │ cluster│ │ │ │ cluster│ │
 │ └────────┘ │ │ └────────┘ │
 │ ┌────────┐ │ │ ┌────────┐ │
 │ │ nacos │◄┼────┼►│ nacos │ │
 │ │ mysql │◄┼────┼►│ mysql │ │
 │ │ redis │◄┼────┼►│ redis │ │
 │ │ minio │◄┼────┼►│ minio │ │
 │ └────────┘ │ │ └────────┘ │
 └────────────┘ └────────────┘
 ▲ ▲
 └────── 双向同步 ──────┘

2. Redis Cluster 6 节点跨机房

2.1 为什么是 6 节点

Redis Cluster 用 hash slot（16384 个槽位）分片。3 master + 3 slave 是最稳的：

3 master：分别负责 0-5460 / 5461-10922 / 10923-16383
3 slave：每个 master 1 个，热备
任意一个 master 挂了，对应 slave 自动升级

跨机房时——机房 1 3 节点（1 master + 1 master + 1 master），机房 2 3 节点（3 slave）。这样机房 1 整体挂了，机房 2 还在（但只有 slave，新写会失败）。

生产更稳的方案：机房 1 2 master + 1 slave，机房 2 1 master + 2 slave，跨机房分布副本——但 6 节点就够覆盖大部分场景。

2.2 节点规划

机房	IP	端口	角色	存储
机房 1	10.8.33.6	7360	master 0	/home/docker/redis-cluster
机房 1	10.8.33.7	7370	master 1	/home/docker/redis-cluster
机房 1	10.8.33.8	7380	master 2	/home/docker/redis-cluster
机房 2	10.8.35.5	7550	slave of 7380	/home/docker/redis-cluster
机房 2	10.8.35.6	7560	slave of 7360	/home/docker/redis-cluster
机房 2	10.8.35.7	7570	slave of 7370	/home/docker/redis-cluster

实际 IP 用占位符 10.8.33.x 10.8.35.x 替代。

2.3 镜像准备

1
2
3


docker pull redis:6.2.17
docker tag redis:6.2.17 <harbor>:13001/base/redis:6.2.17
docker push <harbor>:13001/base/redis:6.2.17

2.4 6 个节点的 redis.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


cat > /home/docker/redis-cluster/redis.conf << "EOF"
port 7360 # 每节点不同
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly no
save ""
daemonize no
protected-mode no
pidfile /data/redis.pid
EOF

2.5 6 个节点的 docker run

1
2
3
4
5
6
7
8


docker run -d \
 --restart=always \
 --privileged=true \
 --name redis-7360 \
 --net host \
 -v /home/docker/redis-cluster:/data \
 <harbor>:13001/base/redis:6.2.17 \
 redis-server /data/redis.conf

6 节点命令相同，只改 --name 和 port。

2.6 创建集群

1
2
3
4
5
6
7
8


mkdir -p /home/docker/redis-cluster
# 6 节点都要建这个目录

docker exec -it redis-7360 \
 redis-cli -p 7360 --cluster create \
 10.8.33.6:7360 10.8.33.7:7370 10.8.33.8:7380 \
 10.8.35.5:7550 10.8.35.6:7560 10.8.35.7:7570 \
 --cluster-replicas 1

输出（关键部分）：

1
2
3
4
5
6
7


>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 10.8.35.6:7560 to 10.8.33.6:7360
Adding replica 10.8.35.7:7570 to 10.8.33.7:7370
Adding replica 10.8.35.5:7550 to 10.8.33.8:7380

确认 yes 后：

1
2
3
4
5


>>> Performing Cluster Check (using node 10.8.33.6:7360)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

2.7 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


docker exec -it redis-7360 redis-cli -p 7360 -c

# 集群信息
127.0.0.1:7360> cluster info
# cluster_state:ok
# cluster_slots_assigned:16384
# cluster_known_nodes:6
# cluster_size:3

# 节点列表
127.0.0.1:7360> cluster nodes
# 02f0476e155902b1eda400ee84602ace90e821cd 10.8.35.5:7550@17550 slave 952938798efe17832a3c9492be9a45675c58fe69 ...

2.8 Spring Boot 客户端配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


spring:
 redis:
 timeout: 10s
 cluster:
 nodes:
 - 10.8.33.6:7360
 - 10.8.33.7:7370
 - 10.8.33.8:7380
 - 10.8.35.5:7550
 - 10.8.35.6:7560
 - 10.8.35.7:7570
 max-redirects: 3
 jedis:
 pool:
 max-active: 500
 max-wait: -1ms
 max-idle: 200
 min-idle: 100

2.9 单 db0 的坑

Redis Cluster 只支持 db0——所有 key 都在 db0。如果你的应用假设"按 db 切分数据"（如 db:4），需要重构。

3. nacos 双活

nacos 双机房同时部署，应用启动时配两个 server：

1

spring.cloud.nacos.discovery.server-addr=10.8.33.6:8848,10.8.35.5:8848

每个机房都跑 nacos，互相不依赖——一个挂掉另一个继续工作。

机房	对外地址	部署方式	账户
机房 1	`http://10.8.33.250:30680/nacos`	k8s	nacos/nacos
机房 2	`http://10.8.35.250:30680/nacos`	k8s	nacos/nacos

4. MySQL 双主架构

双机房 MySQL 同步有 2 种思路：

4.1 双主互相同步

1
2
3


机房1-Master1 ────→ 机房2-Master2
 ↑ │
 └───────────────────┘

每个机房都是 Master，写自己 + 同步到对方。风险：双写冲突、循环同步。

解决：每张表用 server_id 区分，比如 ID 奇数写机房 1，偶数写机房 2。

4.2 主从单向同步

1

机房1-Master ────→ 机房2-Slave

机房 1 是主，机房 2 是从，只读不写。机房 1 挂掉时人工切主。

4.3 多租户 MySQL 部署

1
2
3
4
5


volumes:
 - name: mysql-data
 nfs:
 server: 10.8.33.111
 path: /nfs/park-prod/mysql/data

1
2
3
4
5


volumes:
 - name: mysql-data
 nfs:
 server: 10.8.33.111
 path: /nfs/safety-dev/mysql/data

/etc/mysql/conf.d 走 ConfigMap 注入。

机房	用途	部署方式
机房 1 10.8.33.8:3309	多租户库 + powerjob + nacos	二进制
机房 2 10.8.35.6:3309	多租户库	二进制
机房 2 10.8.35.250:30606	powerjob + nacos	k8s

5. EMQX MQTT 集群

5.5.1 用 static 集群发现策略，所有节点都列在 seeds 里：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


version: "3"
services:
 emqx1:
 image: emqx:5.5.1
 container_name: emqx1
 environment:
 - EMQX_NODE_NAME=emqx@10.8.33.6
 - EMQX_CLUSTER__DISCOVERY_STRATEGY=static
 - EMQX_CLUSTER__STATIC__SEEDS=[emqx@10.8.33.6,emqx@10.8.33.7,emqx@10.8.33.8,emqx@10.8.35.5,emqx@10.8.35.6,emqx@10.8.35.7]
 network_mode: "host"
 healthcheck:
 test: ["CMD", "/opt/emqx/bin/emqx_ctl", "status"]
 interval: 5s
 timeout: 25s
 retries: 5

5.1 客户端配置

1
2
3
4


客户端账号: <your-org> / {{MQTT_PASSWORD}}
机房 1 节点: 10.8.33.6, 10.8.33.7, 10.8.33.8
机房 2 节点: 10.8.35.5, 10.8.35.6（不可用）, 10.8.35.7
公网入口: tcp://mq.cloud.example.com:1885

防火墙映射：公网 1885 → 10.8.33.110:1883 → 10.8.33.6:1883

MQTT 密码用占位符 {{MQTT_PASSWORD}} 替代。

5.2 客户端连接示例

1
2
3
4
5
6
7
8
9


# 加入集群
docker exec -it emqx1 emqx ctl cluster join emqx@10.8.35.5

# 看集群状态
docker exec -it emqx1 emqx ctl cluster status

# 重启
docker-compose -f /home/docker-compose-emqx.yml down
docker-compose -f /home/docker-compose-emqx.yml up -d

6. nginxwebui 负载均衡

服务	协议	策略	负载	备注
mqtt-ws	http	ip	6 节点 8083	前端订阅
mqtt-tcp	tcp	-	6 节点 1883	后端订阅
gateway	http	ip	双 VIP:30697	网关
location-netty	tcp	-	双 VIP:30687	定位基站
minioapi	http	ip	10.8.33.254:9091	文件服务
safety-pc	http	ip	双 VIP:30618	PC 入口
safety-apph5	http	ip	双 VIP:30628	APP 入口
webrtc-stun	tcp/udp	-	10.8.33.127:3478 + 10.8.35.7:3478	STUN
webrtc	http	-	10.8.33.127:8000 + 10.8.35.7:8000	虚拟 ip:443

7. 防火墙映射

公网到机房 1：

1

公网 <your-public-ip>:1885 → 10.8.33.110:1883 → 10.8.33.6:1883

公网到机房 2：

1

公网 <your-public-ip>:xxxx → 10.8.35.2:xxxx → 机房 2 服务

实际 IP 用占位符替代。

机房 2 防火墙登录：https://10.8.35.2，admin / {{FIREWALL_PASSWORD}}

8. 同步策略

资源	同步方式
nacos 配置	nacos 自身多节点 + 应用端多 server-addr
MySQL 数据	binlog 主从 / 双主 + server_id 区分
Redis 数据	Cluster 自动跨节点同步
MinIO 文件	rsync + lsyncd 双向（已有方案）
MQTT 消息	EMQX 集群内自动同步
应用镜像	都从同一个 harbor 私有仓库拉
Prometheus 数据	可选 federation / remote_write
Loki 日志	可选都指向同一个对象存储

9. VIP 与 keepalived 跨机房

unicast_src_ip + unicast_peer 模式（见 2015-02-15 文章）。

机房 1：

1
2
3
4


unicast_src_ip 10.8.33.253
unicast_peer {
 10.8.35.7
}

机房 2：

1
2
3
4


unicast_src_ip 10.8.35.7
unicast_peer {
 10.8.33.253
}

不同机房 VIP 飘移。

10. 排错

现象	原因	解决
Redis Cluster `CLUSTERDOWN`	跨机房链路断	检查防火墙 / 路由
MySQL 双主冲突	两个机房同时写	改 server_id 区分写
nacos 注册的服务没同步	客户端没配双 server-addr	应用配置加 `,` 分隔
EMQX 节点反复脱离集群	网络抖动	调大 `cluster.node_timeout`
公网 502	keepalived 没漂	看 nginx / keepalived 日志
机房 1 全挂后机房 2 写不了	MySQL 单向同步	改双向 / 切主

11. 小结

同城双机房 K8s 集群的核心是"两边都能独立工作"：

Redis Cluster 6 节点 跨机房分布是基础
nacos / MySQL / EMQX 都做双活
MinIO 用 rsync 双向同步
VIP + 防火墙 让公网无感
故障演练——定期模拟机房 1 挂掉

这是 K8s 系列博客的最后一篇——到此生产 K8s 集群从 0 到异地多活的完整链路已经走通。

Loki + Promtail 日志体系：helm 部署 + yaml 自定义 + 排错

Sat, 15 Mar 2025 00:00:00 +0800

K8s 日志采集的 3 种方式

方式	资源占用	适用
DaemonSet 采集（默认）	低	中小集群
Sidecar 采集	高	大集群、多租户隔离
应用主动推送	取决于应用	自定义需求

本文部署 Loki + Promtail——K8s 时代最主流的日志方案（比 ELK 轻量 10 倍，查询语法像 PromQL）。

适用版本：Loki 2.9.3 / Promtail / K8s 1.28.5

1. Loki 架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


 ┌──────────────────┐
 │ Grafana │ ← 查询
 └─────────┬────────┘
 │ LogQL
 ┌─────────▼────────┐
 │ Loki │ ← 存储 + 索引
 │ (write/read/ │
 │ backend/ │
 │ gateway) │
 └─────────┬────────┘
 │ push
 ┌──────────────────┴──────────────────┐
 │ │
 ┌────▼────┐ ┌────▼────┐
 │ Promtail│ ←─ 采集 /var/log/pods/ │ Promtail│
 │ (Node1)│ │ (Node2)│
 └─────────┘ └─────────┘
 ▲ ▲
 /var/log/pods/ /var/log/pods/
 /var/lib/docker/containers/ /var/lib/docker/containers/

3 大模块：

Grafana Agent / Promtail：每节点一个 DaemonSet，抓容器日志
Loki：存储 + 查询（分 write / read / backend / gateway 4 个微服务）
Grafana：可视化查询

2. helm 部署（推荐）

2.1 添加仓库

1
2
3
4
5
6
7


helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# 拉 chart
helm pull grafana/loki-stack
tar xvf loki-stack-2.10.0.tgz
cd loki-stack

2.2 备份默认 values

1

cp values.yaml values-prod.yaml

2.3 修改 values-prod.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


loki:
 enabled: true
 persistence:
 enabled: true
 storageClassName: nfs-client
 accessModes:
 - ReadWriteOnce
 size: 10Gi

promtail:
 enabled: true

grafana:
 enabled: true
 service:
 type: NodePort
 persistence:
 enabled: true
 storageClassName: nfs-client
 accessModes:
 - ReadWriteOnce
 size: 10Gi

2.4 处理冲突 RBAC

1
2
3
4
5
6


k get ClusterRole
# ClusterRole "loki-promtail" in namespace "" exists and cannot be imported into the current release

cd loki-stack
kubectl delete ClusterRole loki-promtail
kubectl delete ClusterRole loki-grafana-clusterrole

2.5 部署

1
2
3
4
5
6
7


kubectl create ns logging

helm upgrade --install loki . \
 -f values-prod.yaml \
 -n logging

kubectl logs -f -n logging loki-0

2.6 验证

1
2
3
4


kubectl get pod -n logging
# loki-0 1/1 Running
# loki-promtail-xxx 1/1 Running
# loki-grafana-xxx 1/1 Running

3. 私有 yaml 部署（更可控）

如果不想用 helm 那一堆微服务，可以直接用 statefulset + configmap。

3.1 准备镜像

1
2
3


docker pull grafana/loki:2.9.3
docker tag grafana/loki:2.9.3 <harbor>/base/grafana/loki:2.9.3
docker push <harbor>/base/grafana/loki:2.9.3

3.2 完整 yaml

/data/k8scnf/loki.yaml（节选关键部分）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161


---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: loki
 namespace: logging
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: loki
 namespace: logging
 labels:
 app: loki
data:
 loki.yaml: |
 auth_enabled: false
 ingester:
 chunk_idle_period: 3m
 chunk_block_size: 262144
 chunk_retain_period: 1m
 max_transfer_retries: 0
 lifecycler:
 ring:
 kvstore:
 store: inmemory
 replication_factor: 1
 wal:
 enabled: true
 dir: /data/wal
 limits_config:
 enforce_metric_name: false
 reject_old_samples: true
 reject_old_samples_max_age: 8h
 schema_config:
 configs:
 - from: "2024-01-19"
 store: boltdb-shipper
 object_store: filesystem
 schema: v11
 index:
 prefix: index_
 period: 24h
 server:
 http_listen_port: 3100
 storage_config:
 boltdb_shipper:
 active_index_directory: /data/loki/boltdb-shipper-active
 cache_location: /data/loki/boltdb-shipper-cache
 cache_ttl: 24h
 shared_store: filesystem
 filesystem:
 directory: /data/loki/chunks
 chunk_store_config:
 max_look_back_period: 0s
 table_manager:
 retention_deletes_enabled: true
 retention_period: 48h
 compactor:
 working_directory: /data/loki/boltdb-shipper-compactor
 shared_store: filesystem
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: loki
 namespace: logging
spec:
 podManagementPolicy: OrderedReady
 replicas: 1
 serviceName: loki
 template:
 metadata:
 labels:
 app: loki
 spec:
 serviceAccountName: loki
 securityContext:
 fsGroup: 10001
 runAsGroup: 10001
 runAsNonRoot: true
 runAsUser: 10001
 initContainers:
 - name: fix-permissions
 image: busybox:latest
 securityContext:
 privileged: true
 runAsGroup: 0
 runAsNonRoot: false
 runAsUser: 0
 command:
 - sh
 - -c
 - >-
 id;
 mkdir -p /data/loki;
 chown 10001:10001 /data -R;
 ls -la /data/
 volumeMounts:
 - mountPath: /data
 name: loki-storage
 containers:
 - name: loki
 image: grafana/loki:2.9.3
 args:
 - -config.file=/etc/loki/config/loki.yaml
 volumeMounts:
 - name: config
 mountPath: /etc/loki/config/loki.yaml
 subPath: loki.yaml
 - name: loki-storage
 mountPath: /data
 ports:
 - name: http-metrics
 containerPort: 3100
 livenessProbe:
 httpGet:
 path: /ready
 port: http-metrics
 initialDelaySeconds: 45
 readinessProbe:
 httpGet:
 path: /ready
 port: http-metrics
 initialDelaySeconds: 45
 securityContext:
 readOnlyRootFilesystem: true
 volumeClaimTemplates:
 - metadata:
 name: loki-storage
 spec:
 accessModes: [ReadWriteOnce]
 resources:
 requests:
 storage: 3Gi
---
apiVersion: v1
kind: Service
metadata:
 name: loki
 namespace: logging
spec:
 type: ClusterIP
 ports:
 - port: 3100
 name: http-metrics
 selector:
 app: loki
---
apiVersion: v1
kind: Service
metadata:
 name: loki-outer
 namespace: logging
spec:
 type: NodePort
 ports:
 - port: 3100
 nodePort: 32537
 selector:
 app: loki

3.3 部署

1
2


kubectl create ns logging
kubectl apply -f /data/k8scnf/loki.yaml

4. Promtail 部署

Promtail 是 Loki 的"客户端"，每节点跑一个 DaemonSet。

4.1 ConfigMap

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


apiVersion: v1
kind: ConfigMap
metadata:
 name: promtail
 namespace: logging
data:
 promtail.yaml: |
 server:
 http_listen_port: 9080
 positions:
 filename: /tmp/positions.yaml
 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_name]
 target_label: __service__
 - source_labels: [__meta_kubernetes_pod_node_name]
 target_label: __host__
 - action: labelmap
 regex: __meta_kubernetes_pod_label_(.+)
 - action: replace
 source_labels: [__meta_kubernetes_namespace]
 target_label: namespace
 - action: replace
 source_labels: [__meta_kubernetes_pod_name]
 target_label: pod

4.2 DaemonSet + RBAC

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


apiVersion: v1
kind: ServiceAccount
metadata:
 name: promtail
 namespace: logging
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: promtail
rules:
 - apiGroups: [""]
 resources: [nodes, nodes/proxy, services, endpoints, pods]
 verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: promtail
subjects:
 - kind: ServiceAccount
 name: promtail
 namespace: logging
roleRef:
 kind: ClusterRole
 name: promtail
 apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: promtail
 namespace: logging
spec:
 selector:
 matchLabels:
 name: promtail
 template:
 metadata:
 labels:
 name: promtail
 spec:
 serviceAccountName: promtail
 containers:
 - name: promtail
 image: grafana/promtail:2.9.3
 args:
 - -config.file=/etc/promtail/promtail.yaml
 volumeMounts:
 - name: config
 mountPath: /etc/promtail
 - name: docker
 mountPath: /var/lib/docker/containers
 readOnly: true
 - name: pods
 mountPath: /var/log/pods
 readOnly: true
 volumes:
 - name: config
 configMap:
 name: promtail
 - name: docker
 hostPath:
 path: /var/lib/docker/containers
 - name: pods
 hostPath:
 path: /var/log/pods

5. 验证与查询

5.1 Loki 健康

1
2
3
4


kubectl -n logging port-forward svc/loki 3100:3100
# 浏览器
http://localhost:3100/ready
# 看到 "ready" 即 OK

5.2 Grafana 配置 Loki 数据源

Grafana → Configuration → Data sources → Add data source → Loki

URL：http://loki:3100

5.3 查日志

Grafana Explore → 数据源选 Loki → 查询：

1
2
3


{namespace="kube-system"}
{namespace="default"} |= "error"
{app="my-app"} | json | line_format "{{.msg}}"

{job="kubernetes-pods"} |= "ERROR" 查所有 ERROR 日志。

6. 常见问题

6.1 `loki-0 1/2 CrashLoopBackOff`

容器权限问题。yaml 里加 initContainer：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


initContainers:
 - name: fix-permissions
 image: busybox:latest
 securityContext:
 privileged: true
 runAsGroup: 0
 runAsUser: 0
 command:
 - sh
 - -c
 - >-
 mkdir -p /data/loki;
 chown 10001:10001 /data -R;
 ls -la /data/
 volumeMounts:
 - mountPath: /data
 name: storage

实测 2.7.3 有 bug，2.6.1 反而正常——怀疑是 Loki 配置变更导致容器启动顺序问题。直接换成 2.6.1。

6.2 `no such file or directory: /var/log/pods/...`

docker 数据目录迁移过 → Promtail 找不到容器日志。

解决：把 Promtail 的 /var/lib/docker/containers 路径改成实际路径；或重装 docker 到默认路径。

临时方案：重启故障 Pod：

1

kubectl delete po <pod> -n kube-system

6.3 Promtail 一直 Buffer filling up

Promtail 默认 buffer 满了就丢日志。调大：

1
2
3
4
5
6


positions:
 filename: /tmp/positions.yaml
clients:
 - url: http://loki:3100/loki/api/v1/push
 batchwait: 1s
 batchsize: 1048576

6.4 日志保留时间太短

1
2
3
4
5


limits_config:
 retention_period: 168h  # 7 天
table_manager:
 retention_deletes_enabled: true
 retention_period: 168h

6.5 helm 部署 RBAC 冲突

1
2


kubectl delete ClusterRole loki-promtail
kubectl delete ClusterRole loki-grafana-clusterrole

7. 小结

Loki + Promtail 是 K8s 时代"轻量级日志方案"的事实标准：

DaemonSet 采集 占资源最少，适合中小集群
Loki 4 微服务（write / read / backend / gateway）支持水平扩展
LogQL 语法像 PromQL，习惯 Prometheus 的人秒上手
容器权限问题 用 initContainer 修
保留策略 默认 48h，生产建议 7-30 天

下一步：K8s 实战：Deployment/StatefulSet/DaemonSet 区别 + 探针 + hostNetwork 调度。

Istio 1.20 服务网格：bookinfo + Kiali/Grafana 面板

Sat, 15 Feb 2025 00:00:00 +0800

Istio 是 K8s 上的"服务网格"标准

Istio 是 CNCF 毕业项目，2017 年由 Google + IBM + Lyft 联合开源。它在 K8s Pod 里自动注入 Envoy 边车代理，把服务间通信从应用层下沉到基础设施层，实现：

流量管理（灰度、A/B、熔断）
安全（mTLS 加密 + RBAC 鉴权）
可观测性（指标 / 日志 / 链路追踪）

本文部署 Istio 1.20.2（2024-01 发布的稳定版），并跑通官方 demo。

适用版本：Istio 1.20.2 / K8s 1.28.5

1. 9 个内置 Profile

1
2


istioctl profile list
# ambient / default / demo / empty / external / minimal / openshift / preview / remote

profile	包含组件
default	istiod + istio-ingressgateway（生产推荐）
demo	default + istio-egressgateway（demo / 学习用）
minimal	仅 istiod
preview	实验性
ambient	新的无 sidecar 模式（实验）

生产用 default，学习用 demo。

2. 安装 Istio

2.1 下载

1

https://github.com/istio/istio/releases/download/1.20.2/istio-1.20.2-linux-amd64.tar.gz

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


cd /data/softs
tar xf istio-1.20.2-linux-amd64.tar.gz
cd istio-1.20.2

# 目录结构
tree -L 2
# ├── bin/istioctl
# ├── manifests/ # 部署 yaml
# ├── samples/ # 示例应用（bookinfo 等）
# ├── tools/

2.2 复制 istioctl

1
2
3
4
5


cp bin/istioctl /usr/local/bin/

istioctl version
# no ready Istio pods in "istio-system"
# 1.20.2

2.3 安装 demo profile

1
2
3
4
5
6
7
8


istioctl install --set profile=demo -y

# 输出
# ✔ Istio core installed
# ✔ Istiod installed
# ✔ Egress gateways installed
# ✔ Ingress gateways installed
# ✔ Installation complete

2.4 给 namespace 打自动注入标签

1

kubectl label namespace default istio-injection=enabled

之后再 default 命名空间下创建的 Pod 都会自动注入 Envoy 边车。

2.5 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


mkdir -p /data/k8scnf/istio
cd /data/k8scnf/istio

# 用 manifest 验证安装
istioctl manifest generate --set profile=demo > generated-manifest.yaml
istioctl verify-install -f generated-manifest.yaml
# ✔ Istio is installed and verified successfully

kubectl get pods -n istio-system
# NAME READY STATUS RESTARTS AGE
# istio-egressgateway-69b6bdb898-2jh2c 1/1 Running 0 7m
# istio-ingressgateway-778f947c84-wspbb 1/1 Running 0 7m
# istiod-7d4d6677c5-qdvrh 1/1 Running 0 8m

kubectl get crds | grep istio
# 应该有 15 个 CRD（VirtualService、DestinationRule、Gateway 等）

3. 部署 bookinfo 示例

bookinfo 是 Istio 官方示例，包含 4 个微服务：

productpage：入口
details：书籍详情
reviews：评论（3 个版本 v1/v2/v3）
ratings：评分

1
2
3
4
5
6


mv /data/softs/istio-1.20.2/samples /data/k8scnf/istio/

kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
# service/details created
# deployment.apps/details-v1 created
# ...

1
2
3
4
5


kubectl get po
# details-v1-698d88b-w292r 2/2 Running 0 77s
# productpage-v1-675fc69cf-wxs9r 0/2 Init:0/1 0 76s ← 等 envoy sidecar
# ratings-v1-6484c4d9bb-8tg8t 0/2 PodInitializing
# reviews-v1-v3 0/2 PodInitializing

注意 2/2 表示 1 个应用容器 + 1 个 envoy 边车。

3.1 验证应用启动

1
2
3


kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- \
 curl -s productpage:9080/productpage | grep -o "<title>.*</title>"
# 输出：<title>Simple Bookstore App</title>

3.2 创建 Gateway

1
2
3


kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
# gateway.networking.istio.io/bookinfo-gateway created
# virtualservice.networking.istio.io/bookinfo created

1
2


istioctl analyze
# 可能会警告：default 命名空间下某些 Pod 没注入 envoy，忽略（测试 Pod）

3.3 访问入口

1
2
3


kubectl -n istio-system get svc istio-ingressgateway
# NAME TYPE PORT(S)
# istio-ingressgateway LoadBalancer 80:31824/TCP,443:32488/TCP

31824 是 NodePort，从任意 master 节点：

1
2


# 通过 VIP 访问
http://<vip-internal>:31824/productpage

浏览器能看到 bookinfo 应用，刷新几次页面会看到 reviews 三个版本（v1 无评分 / v2 黑色星 / v3 红色星）的随机切换。

4. 安装 Dashboard

K8s 上的 Istio Dashboard 包含 4 个组件：

Kiali：服务网格拓扑
Grafana：监控面板
Prometheus：指标采集
Jaeger（或 Zipkin）：链路追踪

1
2
3
4
5


kubectl apply -f samples/addons
# 一次性 apply grafana / jaeger / kiali / prometheus

kubectl rollout status deployment/kiali -n istio-system
# deployment "kiali" successfully rolled out

4.1 Kiali 面板

1
2


istioctl dashboard kiali
# http://localhost:20001/kiali

外网访问需要改 NodePort：

1
2
3
4
5
6
7
8


kubectl -n istio-system patch svc kiali -p '{"spec":{"type":"NodePort"}}'

kubectl -n istio-system get svc kiali
# NAME TYPE PORT(S)
# kiali NodePort 20001:32171/TCP

# 浏览器
http://<vip-internal>:32171/kiali

Kiali 主页能看到：

Graph：服务间调用拓扑（不同颜色表示 2xx/3xx/4xx/5xx）
Applications：应用列表
Services：服务列表
Workloads：工作负载（Deployment）列表

4.2 Grafana 面板

1
2
3
4


kubectl -n istio-system patch svc grafana -p '{"spec":{"type":"NodePort"}}'

# 默认 admin/admin
http://<vip-internal>:31693

4.3 触发流量看面板

1
2
3
4


clusterIP=$(kubectl -n istio-system get svc istio-ingressgateway -ojsonpath='{.spec.clusterIP}')
for i in $(seq 1 100); do
 curl -s -o /dev/null "http://$clusterIP:80/productpage"
done

Kiali 的 Graph 立即能看到 productpage → details / reviews / ratings 的调用关系，每个箭头带成功率 / 响应时间。

5. 灰度发布：把 reviews 全部切到 v3

默认 bookinfo 的 reviews 3 个版本随机分配（50% v1, 33% v2, 17% v3）。

把流量全部切到 v3：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# samples/bookinfo/networking/virtual-service-reviews-v3.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: reviews
spec:
 hosts:
 - reviews
 http:
 - route:
 - destination:
 host: reviews
 subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: reviews
spec:
 host: reviews
 subsets:
 - name: v1
 labels:
 version: v1
 - name: v2
 labels:
 version: v2
 - name: v3
 labels:
 version: v3

1

kubectl apply -f virtual-service-reviews-v3.yaml

刷新页面 → 全部红色星（v3）。

5.1 按用户灰度

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: reviews
spec:
 hosts:
 - reviews
 http:
 - match:
 - headers:
 end-user:
 exact: jason
 route:
 - destination:
 host: reviews
 subset: v2
 - route:
 - destination:
 host: reviews
 subset: v1

用户 jason 走 v2，其他用户走 v1。

6. 常见问题

6.1 `unable to proxy Istiod pods. Make sure your Kubernetes API server has access to the Istio control plane through 8080 port`

istioctl dashboard 依赖 socat 端口转发：

1

apt install socat -y

6.2 `grafana URL is not set in Kiali configuration`

Kiali 找不到 Grafana 入口：

1

kubectl -n istio-system edit cm/kiali

1
2
3
4
5
6
7


external_services:
 grafana:
 url: "http://grafana.istio-system:3000"
 custom_dashboards:
 enabled: true
 istio:
 root_namespace: istio-system

1
2


# 删 pod 让它重建
kubectl delete po -n istio-system kiali-545878ddbb-shkkn

6.3 `loki-0 1/2 CrashLoopBackOff`

Loki 容器初始化权限不够。加 initContainer：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


initContainers:
 - name: fix-permissions
 image: busybox:latest
 securityContext:
 privileged: true
 runAsGroup: 0
 runAsNonRoot: false
 runAsUser: 0
 command:
 - sh
 - -c
 - >-
 id;
 mkdir -p /data/loki;
 chown 10001:10001 /data -R;
 ls -la /data/
 volumeMounts:
 - mountPath: /data
 name: storage

6.4 Pod 没自动注入 envoy

确认 namespace 有 istio-injection=enabled 标签：

1
2
3
4
5
6
7


kubectl get ns -L istio-injection

# 给 namespace 加
kubectl label namespace <name> istio-injection=enabled

# 已经创建的 Pod 要重启才会注入
kubectl rollout restart deployment <name> -n <ns>

6.5 卸载

1
2
3
4


kubectl delete -f samples/addons
istioctl uninstall -y --purge
kubectl delete namespace istio-system
kubectl label namespace default istio-injection-

7. 小结

Istio 让 K8s 集群具备了"微服务治理"能力：

demo profile 是学习首选（包含所有组件）
生产用 default profile（仅核心）
Kiali / Grafana 是 Istio 可观测性的灵魂
VirtualService + DestinationRule 是灰度发布 / 流量切分的核心
sidecar 自动注入 需要 namespace 标签

下一步：Loki + Promtail 日志体系：helm 部署 + yaml 自定义。

cert-manager 1.13 自动证书管理 + Ingress TLS 自动化

Wed, 15 Jan 2025 00:00:00 +0800

cert-manager 是 K8s 证书管理的"标准答案"

K8s 集群对外暴露 HTTPS 服务的痛点：

证书要申请、签发、安装
90 天过期，要定期续期
多域名、泛域名、通配符场景配置复杂

cert-manager 是 CNCF 沙箱项目，自动从 Let’s Encrypt、HashiCorp Vault 等 CA 申请、签发、自动续期证书，完全 K8s-native——证书本身就是 K8s 的 Secret 资源。

适用版本：cert-manager v1.13.3 / K8s 1.28.5 / quay.io 镜像

1. 架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 ┌─────────────────┐
 │ Let's Encrypt │
 │ ACME Server │
 └────────┬────────┘
 │ HTTP-01 / DNS-01
 │ challenge
 ┌────────▼────────┐
 │ cert-manager │
 │ - controller │
 │ - webhook │
 │ - cainjector │
 └────────┬────────┘
 │ 创建 / 更新
 ┌────────▼────────┐
 │ K8s Secret │
 │ (tls.crt, │
 │ tls.key) │
 └────────┬────────┘
 │ 引用
 ┌────────▼────────┐
 │ Ingress │
 │ (nginx) │
 └─────────────────┘

三个核心组件：

cert-manager：Controller 监听 Certificate 资源，自动签发 / 续期
webhook：API 校验
cainjector：把 CA 注入到 webhook / apiserver

2. 部署 cert-manager

2.1 安装

1
2
3
4
5


mkdir -p /data/k8scnf/cert-manager && cd /data/k8scnf/cert-manager

# 官方 yaml
curl -L -o cert-manager.yaml \
 https://github.com/cert-manager/cert-manager/releases/download/v1.13.3/cert-manager.yaml

2.2 镜像

quay.io 是红帽的镜像，国内网络直连一般通，不用额外加速：

1
2
3


image: "quay.io/jetstack/cert-manager-cainjector:v1.13.3"
image: "quay.io/jetstack/cert-manager-webhook:v1.13.3"
image: "quay.io/jetstack/cert-manager-controller:v1.13.3"

如果是内网部署，要先 tag 推到私有 harbor：

1
2
3
4


docker pull quay.io/jetstack/cert-manager-controller:v1.13.3
docker tag quay.io/jetstack/cert-manager-controller:v1.13.3 <harbor>/base/jetstack/cert-manager-controller:v1.13.3
docker push <harbor>/base/jetstack/cert-manager-controller:v1.13.3
# cainjector / webhook 同样

2.3 应用

1

kubectl apply -f /data/k8scnf/cert-manager/cert-manager.yaml

2.4 验证

1
2
3
4
5


kubectl get pod -n cert-manager
# NAME READY STATUS RESTARTS AGE
# cert-manager-5c9d8879fd-rtlwb 1/1 Running 0 106s
# cert-manager-cainjector-6cc9b5f678-5fbqk 1/1 Running 0 106s
# cert-manager-webhook-7bb7b75848-7bqzq 1/1 Running 0 106s

3 个 Pod 都 Running，部署成功。

3. ClusterIssuer / Issuer

3.1 概念

Issuer：单一 namespace 内的证书签发者
ClusterIssuer：集群范围（cluster-wide），可被所有 namespace 引用

生产用 ClusterIssuer。

3.2 Let’s Encrypt Staging（测试用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
spec:
 acme:
 server: https://acme-staging-v02.api.letsencrypt.org/directory
 email: ops@example.com
 privateKeySecretRef:
 name: letsencrypt-staging-account-key
 solvers:
 - http01:
 ingress:
 class: nginx

3.3 Let’s Encrypt Production（生产用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
spec:
 acme:
 server: https://acme-v02.api.letsencrypt.org/directory
 email: ops@example.com
 privateKeySecretRef:
 name: letsencrypt-prod-account-key
 solvers:
 - http01:
 ingress:
 class: nginx

Staging 配额宽（5 个 / 周 / 域名），适合调试；Production 有速率限制。生产前用 Staging 验证完再切 Production。

应用：

1
2
3
4
5


kubectl apply -f cluster-issuer.yaml

# 看状态
kubectl get clusterissuer
kubectl describe clusterissuer letsencrypt-prod

4. 自动签发证书

4.1 简单域名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: example-com
 namespace: default
spec:
 secretName: example-com-tls
 issuerRef:
 name: letsencrypt-prod
 kind: ClusterIssuer
 dnsNames:
 - example.com
 - www.example.com

1
2
3
4


kubectl apply -f certificate.yaml
kubectl get certificate
# NAME READY SECRET AGE
# example-com True example-com-tls 30s

4.2 Ingress 自动关联

让 cert-manager 自动从 Ingress 的 spec.tls.hosts 创建证书——加 annotation：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: my-app
 annotations:
 cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
 ingressClassName: nginx
 tls:
 - hosts:
 - app.example.com
 secretName: app-example-com-tls
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: my-app
 port:
 number: 80

cert-manager 会自动创建 Certificate 资源 + 触发 HTTP-01 challenge + 把证书写到 app-example-com-tls Secret。

5. 泛域名（DNS-01）

Let’s Encrypt 对泛域名 *.example.com 只支持 DNS-01 challenge（不是 HTTP-01）。需要 DNS 提供商 API。

5.1 阿里云 DNS 示例

1
2
3
4
5
6


# 创建阿里云 RAM AccessKey（DNS 权限）
# AccessKey ID / Secret 保存到 Secret
kubectl create secret generic alidns-secret \
 --from-literal=access-key={{ALIYUN_ACCESS_KEY}} \
 --from-literal=secret-key={{ALIYUN_SECRET_KEY}} \
 -n cert-manager

实际密钥用占位符 {{ALIYUN_ACCESS_KEY}} {{ALIYUN_SECRET_KEY}} 替代。

5.2 ClusterIssuer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod-dns
spec:
 acme:
 server: https://acme-v02.api.letsencrypt.org/directory
 email: ops@example.com
 privateKeySecretRef:
 name: letsencrypt-prod-account-key
 solvers:
 - dns01:
 rfc2136:
 nameserver: dns17.hichina.com:53
 tsigAlgorithm: HMACSHA1

不同 DNS 提供商插件不同（cert-manager-webhook-*），需要先部署对应插件 Pod。

5.3 申请泛域名证书

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: wildcard-example-com
 namespace: default
spec:
 secretName: wildcard-example-com-tls
 issuerRef:
 name: letsencrypt-prod-dns
 kind: ClusterIssuer
 dnsNames:
 - "*.example.com"
 - example.com

6. 自动续期

cert-manager 在证书 剩余有效期 < 30 天 时自动续期。续期过程对用户完全透明：

1
2
3
4
5
6
7
8


kubectl describe certificate example-com
# Events:
# Type Reason Age From Message
# ---- ------ ---- ---- -------
# Normal OrderCreated 60s cert-manager Created Order resource "example-com-12345"
# Normal OrderComplete 45s cert-manager Order "example-com-12345" completed successfully
# Normal CertIssued 45s cert-manager Certificate issued successfully
# Normal CertRenewed 5d cert-manager Certificate scheduled for renewal in 29 days

7. 与自建 CA 集成（私有场景）

如果内网不连公网 Let’s Encrypt，可以自建 CA（cfssl / step-ca）：

1
2
3
4
5
6
7


apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: internal-ca
spec:
 ca:
 secretName: internal-ca-secret

先创建 CA 根证书 Secret：

1
2
3
4
5


cfssl gencert -initca ca-csr.json | cfssljson -bare ca
kubectl create secret tls internal-ca-secret \
 --cert=ca.pem \
 --key=ca-key.pem \
 -n cert-manager

8. 实战：HTTPS 反代内网应用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


# 1. 部署应用（假设已部署 my-app Service 80 端口）
apiVersion: v1
kind: Service
metadata:
 name: my-app
spec:
 selector:
 app: my-app
 ports:
 - port: 80
 targetPort: 8080

---
# 2. Ingress + cert-manager 自动证书
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: my-app
 annotations:
 cert-manager.io/cluster-issuer: "letsencrypt-prod"
 nginx.ingress.kubernetes.io/proxy-body-size: "2048m"
spec:
 ingressClassName: nginx
 tls:
 - hosts:
 - app.example.com
 secretName: app-example-com-tls
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: my-app
 port:
 number: 80

1
2
3
4
5
6


# 等 60 秒
kubectl get certificate -n default
# READY = True

curl https://app.example.com
# 浏览器看到锁标志 + 证书

9. 排错

9.1 证书 Pending 不签发

1
2
3


kubectl describe certificate my-cert
kubectl describe challenge
# 常见：HTTP-01 challenge 失败，因为 80 端口未暴露

9.2 “rateLimited” 错误

Let’s Encrypt Production 速率限制（同一域名 50 证书 / 周）。换域名或等下周。

9.3 续期失败

1
2


kubectl describe order
# 找原因：DNS / 网络 / CA 配置

9.4 内网环境无外网

Let’s Encrypt 走 HTTP-01 必须公网可达。改：

自建 CA（cfssl + step-ca）
或用 DNS-01（DNS TXT 记录验证，不需要 HTTP）

9.5 Pod 启动失败

1
2


kubectl logs -n cert-manager deploy/cert-manager
# 通常是 webhook 配置问题，看 Events

10. 小结

cert-manager 让 K8s 证书管理"零运维"：

HTTP-01 适合公网 Ingress（最简单）
DNS-01 适合泛域名 + 内网
自建 CA 适合纯内网
cert-manager 自动续期，永远不用手动管理证书
Staging → Production 两步走避免触发速率限制

下一步：Istio 1.20 服务网格：bookinfo + Kiali/Grafana 面板。

K8s 节点扩容：worker 加入集群一键脚本

Sun, 15 Dec 2024 00:00:00 +0800

K8s 集群扩容的场景

集群跑了一段时间，资源不够了，要加新 worker？常见两种来源：

全新机器（裸金属 + Ubuntu 22.04）
之前装过 kubeadm 跑挂了，现在想重新加入

第二种特别棘手——kubeadm 残留的证书、配置文件、iptables 规则都会让 node join 失败。

适用版本：K8s 1.28.5 / Ubuntu 22.04

1. 全新 worker 加入（推荐）

1.1 master1 上操作

设置 hosts

1
2
3
4


cat << "EOF" >> /etc/hosts
<新 worker1 ip> worker1
<新 worker2 ip> worker2
EOF

免密登录

1
2
3
4
5


sshpass -p <YOUR_SSH_PASSWORD> ssh-copy-id -o StrictHostKeyChecking=no worker1

# 如果 worker 之前有 known_hosts 冲突
ssh-keygen -f "/root/.ssh/known_hosts" -R "worker1"
sshpass -p <YOUR_SSH_PASSWORD> ssh-copy-id -o StrictHostKeyChecking=no worker1

实际密码用占位符 <YOUR_SSH_PASSWORD> 替代（执行前请把 <YOUR_SSH_PASSWORD> 替换为真实 SSH 密码，或通过 export SSHPASS=... 后 sshpass -p $SSHPASS 注入）。

推送二进制 + 证书 + 服务配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 1. 推送二进制
scp /usr/local/bin/kube{let,-proxy} worker1:/usr/local/bin/
scp /usr/local/bin/cri-dockerd worker1:/usr/local/bin/

# 2. 推送证书
ssh worker1 mkdir -p /etc/kubernetes/{manifests,pki}
cd /etc/kubernetes
for FILE in pki/ca.pem pki/ca-key.pem pki/front-proxy-ca.pem kubelet-conf.yml kube-proxy.yaml bootstrap-kubelet.kubeconfig kubelet.kubeconfig kube-proxy.kubeconfig; do
 scp /etc/kubernetes/$FILE worker1:/etc/kubernetes/${FILE}
done
scp -r /etc/kubernetes/manifests worker1:/etc/kubernetes

# 3. 推送 systemd 单元
for FILE in /etc/systemd/system/cri-docker.service /etc/systemd/system/cri-docker.socket /etc/systemd/system/kubelet.service /etc/systemd/system/kube-proxy.service; do
 scp $FILE worker1:${FILE}
done

1.2 一键脚本（推荐）

把上面 3 步封装到 join_k8s.sh，在 master1 上：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


#!/bin/bash
# join_k8s.sh <worker-name>
WORKER=$1
echo "=== Pushing binaries to $WORKER ==="
scp /usr/local/bin/kube{let,-proxy} $WORKER:/usr/local/bin/
scp /usr/local/bin/cri-dockerd $WORKER:/usr/local/bin/

echo "=== Pushing certs ==="
ssh $WORKER "mkdir -p /etc/kubernetes/{manifests,pki}"
for FILE in pki/ca.pem pki/ca-key.pem pki/front-proxy-ca.pem kubelet-conf.yml kube-proxy.yaml bootstrap-kubelet.kubeconfig kubelet.kubeconfig kube-proxy.kubeconfig; do
 scp /etc/kubernetes/$FILE $WORKER:/etc/kubernetes/${FILE}
done
scp -r /etc/kubernetes/manifests $WORKER:/etc/kubernetes

echo "=== Pushing systemd units ==="
for FILE in /etc/systemd/system/cri-docker.service /etc/systemd/system/cri-docker.socket /etc/systemd/system/kubelet.service /etc/systemd/system/kube-proxy.service; do
 scp $FILE $WORKER:${FILE}
done
echo "=== Done. Now SSH to $WORKER and start services ==="

worker 上的 worker.sh：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


#!/bin/bash
# worker.sh
echo "=== Disable swap ==="
swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab

echo "=== Set hostname ==="
hostnamectl set-hostname $(hostname)

echo "=== Install nfs-common (for nfs pv) ==="
apt install -y nfs-common

echo "=== Reload systemd ==="
systemctl daemon-reload

echo "=== Start services ==="
systemctl enable --now cri-docker.socket
systemctl enable --now cri-docker.service
systemctl enable --now kubelet.service
systemctl enable --now kube-proxy.service
systemctl restart kubelet.service
systemctl restart kube-proxy.service

echo "=== Status ==="
systemctl status cri-docker.socket
systemctl status cri-docker.service
systemctl status kubelet.service
systemctl status kube-proxy.service

echo "=== Logs ==="
journalctl -f -u kubelet

执行：

1
2
3
4
5


# 在 worker 上
bash worker.sh worker1

# 在 master1 上
bash /data/softs/join_k8s.sh worker1

1.3 验证

1
2


kubectl get node
# worker1 应该出现在列表中，STATUS 从 NotReady 变 Ready

2. 之前装过 kubeadm 的 worker 清理

kubeadm reset 是最干净的清理方式（如果还装在系统里）：

1
2


# 如果 kubeadm 还在
kubeadm reset

如果 kubeadm 已经删了，需要手动清：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# 卸载相关包
sudo yum remove -y kubeadm kubectl kubelet kubernetes-cni kube*
sudo yum autoremove -y

# Ubuntu
sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*
sudo apt-get autoremove

# 清残留
rm -rf ~/.kube
rm -rf /var/lib/kube*
systemctl stop kubelet.service
systemctl stop kube-proxy.service
systemctl disable kubelet.service
systemctl disable kube-proxy.service

# 清 iptables 规则（kubeadm 会留下）
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

再走"全新 worker"流程。

3. 常见坑

3.1 日志采集不到

1
2
3


failed to tail file, stat failed
stat /var/log/pods/kube-system_calico-node-95qkq_d7cbeb3d-5f17-40b9-bbb4-6e4cdb04a42e/calico-node/0.log:
no such file or directory

原因：docker 改过数据目录路径（比如 data-root）。

解决：改回 /var/lib/docker 或者把 journalctl 改用 journal 模式（不依赖文件）。

临时方案：删 calico-node Pod，让它自动重建：

1

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

3.2 kubelet 启动报 `kubelet.go:2286] "Error updating node status"`

通常是 node IP 选错（多网卡场景）。在 kubelet-conf.yml 加：

1

nodeIP: <固定 IP>

3.3 `kubelet: failed to create kubelet: cgroup driver "cgroupfs" is different from docker "systemd"`

Docker cgroupDriver 与 kubelet 不一致：

1
2
3


{
 "exec-opts": ["native.cgroupdriver=systemd"]
}

1

systemctl restart docker

3.4 `kubelet: failed to start ContainerManager ... cgroup ... not found`

swap 没禁，或 cgroup 子系统没加载：

1
2
3
4


swapoff -a
# 加载内核模块
modprobe br_netfilter
modprobe ip_vs

3.5 `kubelet.go:1380] "Failed to start cAdvisor" ... Failed to get cgroup stats`

cgroup v2 内核与 cadvisor 不兼容。降级到 cgroup v1：

1
2
3
4
5
6


# 启动参数加 systemd.unified_cgroup_hierarchy=0
# /etc/default/grub
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

update-grub
reboot

3.6 `kubelet: node "<name>" not found`

node 没注册到 apiserver。检查：

1
2
3
4


kubectl get csr
# 应该有 Pending 的 CSR（worker 发出的证书请求）

kubectl certificate approve <csr-name>

3.7 容器启动后立即退出

1
2
3


kubectl describe pod <pod>
# Events 里有 "Back-off pulling image" / "Failed to pull image"
# 解决：检查 docker daemon.json 的 insecure-registries + imagePullSecrets

3.8 节点 NotReady

1
2
3
4
5
6
7


kubectl describe node <name>
# Conditions：
# Ready False
# NetworkUnavailable True（calico 没装）
# MemoryPressure False
# DiskPressure False
# PIDPressure False

NetworkUnavailable = calico DaemonSet 还没起来，重启一下。

3.9 节点 Ready 但 Pod 起不来

1

kubectl get events -A | grep -i error

常见：calico-kube-controllers CrashLoopBackOff → 重新 apply calico.yaml。

4. 缩容

如果要把 worker 退出集群：

1
2
3
4
5
6


# 驱逐 Pod
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# 标记不可调度
kubectl cordon <node>
# 删除节点
kubectl delete node <node>

worker 上清理：

1
2
3
4
5
6
7
8
9


systemctl stop kubelet
systemctl stop kube-proxy
systemctl disable kubelet
systemctl disable kube-proxy

rm -rf /etc/kubernetes
rm -rf /var/lib/kubelet
rm -rf /usr/local/bin/kubelet
rm -rf /usr/local/bin/kube-proxy

5. 实战：worker10 加入（带坑排查）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. SSH 免密
sshpass -p <YOUR_SSH_PASSWORD> ssh-copy-id -o StrictHostKeyChecking=no worker10

# 2. 跑一键脚本
bash join_k8s.sh worker10

# 3. 在 worker10 上启动
bash worker.sh

# 4. 等 30 秒
kubectl get node
# worker10 出现

日志采不到 → 删 calico-node 让它重建。

6. 小结

节点扩容 / 缩容看似简单，但隐藏的坑很多：

全新机器 走 join_k8s.sh + worker.sh 一键脚本
kubeadm 残留 必须 kubeadm reset 或手动清包 + iptables
calico-node CrashLoopBackOff 删 Pod 重建最省事
cgroup driver 一致 是节点 Ready 的前提
cgroup v2 K8s 1.24 之前需要 systemd.unified_cgroup_hierarchy=0

下一步：[cert-manager 1.13 自动证书管理 + Ingress TLS 自动化](/p/k8s-cert-manager-zi dong-zhengshu-guanli-ingress-tls-zidonghua/)。

K8s 集群升级与卸载：版本升级 + finalizers 清理

Fri, 15 Nov 2024 00:00:00 +0800

升级 vs 卸载

K8s 集群"生命周期"两个最复杂的操作：

升级：小版本（1.28.5 → 1.28.8）可以"无脑"替换二进制；大版本（1.28 → 1.29）要看组件参数变化
卸载：彻底清掉所有 master / worker 上的 K8s 文件、systemd 单元、容器运行时、证书

适用版本：升级 1.28.5 → 1.28.8 / 卸载 K8s 1.28.5

1. 升级策略

1.1 大版本 vs 小版本

小版本升级（patch 1.28.x → 1.28.y）：只换二进制 + 重启组件
次版本升级（1.28 → 1.29）：要关注 deprecated API（如 policy/v1beta1）、CRD schema 变化、组件 flag 变化
大版本升级（1.x → 2.x）：官方不支持，必须重装

1.2 升级顺序

1

master1 → master2 → master3 → worker1 → worker2 → ... → workerN

etcd 先升，K8s 控制面组件（apiserver → controller-manager → scheduler）后升，最后 worker。

1.3 当前环境

组件	当前	目标
etcd	v3.5.11	3.5.13
kubernetes-server	1.28.5	1.28.8
coredns	1.29.0	1.29.0（不动）

2. 升级 etcd

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# 备份
mkdir -p /data/etcd-bak
etcdctl snapshot save /data/etcd-bak/etcd-snapshot-$(date +%Y%m%d).db

# 停 etcd
systemctl stop etcd.service
mv /usr/local/bin/etcd* /data/etcd-bak/

# 装新版本
cd /data/softs
tar -xf etcd-v3.5.13-linux-amd64.tar.gz
mv etcd-v3.5.13-linux-amd64/etcd /usr/local/bin/
mv etcd-v3.5.13-linux-amd64/etcdctl /usr/local/bin/
mv etcd-v3.5.13-linux-amd64/etcdutl /usr/local/bin/

# 同步到其他 master
for NODE in master2 master3; do
 ssh $NODE "mv /usr/local/bin/etcd* /data/etcd-bak/"
 scp /usr/local/bin/etcd* $NODE:/usr/local/bin/
done

# 启动
systemctl start etcd.service
etcdctl version
# etcdctl version: 3.5.13

3. 升级 K8s 控制面

3.1 升级 master1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# 备份
mkdir -p /usr/local/bin/bak
mv /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} /usr/local/bin/bak

# 装新版本
cd /data/softs
tar -xf kubernetes-server-linux-amd64.tar.gz \
 --strip-components=3 \
 -C /usr/local/bin \
 kubernetes/server/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}

# 重启所有 master 组件
systemctl restart kube-apiserver.service
systemctl restart kube-controller-manager.service
systemctl restart kube-scheduler.service
systemctl restart kubelet.service
systemctl restart kube-proxy.service

# 验证
kubectl get node
# master1 应该还是 Ready，但 VERSION 还是 1.28.5（只有 etcd 那台没升时）

3.2 升级 master2 + master3

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


for NODE in master2 master3; do
 echo "=== $NODE ==="
 ssh root@$NODE "mkdir -p /usr/local/bin/bak && \
 mv /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} /usr/local/bin/bak"
 scp /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} \
 $NODE:/usr/local/bin/
 ssh root@$NODE "systemctl restart kube-apiserver.service && \
 systemctl restart kube-controller-manager.service && \
 systemctl restart kube-scheduler.service && \
 systemctl restart kubelet.service && \
 systemctl restart kube-proxy.service"
done

3.3 升级 worker

1
2
3
4
5
6
7
8


for NODE in worker1 worker2 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do
 echo "=== $NODE ==="
 ssh root@$NODE "mkdir -p /usr/local/bin/bak && \
 mv /usr/local/bin/kube{let,-proxy} /usr/local/bin/bak"
 scp /usr/local/bin/kube{let,-proxy} $NODE:/usr/local/bin/
 ssh root@$NODE "systemctl restart kubelet.service && \
 systemctl restart kube-proxy.service"
done

3.4 验证

1
2


kubectl get node
# 全部 Ready，VERSION 显示 1.28.8

4. 升级时的节点隔离

升级 master 时要先把 master 标记不可调度（避免新 Pod 调度到正在重启的 master）：

1
2
3
4
5
6
7
8


# 隔离
kubectl cordon master1
kubectl drain master1 --delete-local-data --ignore-daemonsets --force
systemctl restart kube-apiserver.service
# ...

# 恢复
kubectl uncordon master1

drain 驱逐所有非 DaemonSet Pod 到其他节点。--delete-emptydir-data 允许删除 emptyDir 类型数据（一般安全）。

5. 卸载 K8s 集群

5.1 停服务顺序

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 停所有 K8s 服务
systemctl status kube-apiserver.service
systemctl status kube-controller-manager.service
systemctl status kube-scheduler.service
systemctl status kubelet.service
systemctl status kube-proxy.service

# 停
systemctl stop kube-apiserver.service
systemctl disable kube-apiserver.service
# ... 同上其他

5.2 删 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


rm -rf /etc/systemd/system/kube-apiserver.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-apiserver.service
rm -rf /etc/systemd/system/kube-controller-manager.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-controller-manager.service
rm -rf /etc/systemd/system/kube-scheduler.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-scheduler.service
rm -rf /etc/systemd/system/kubelet.service
rm -rf /etc/systemd/system/multi-user.target.wants/kubelet.service
rm -rf /etc/systemd/system/kube-proxy.service
rm -rf /etc/systemd/system/multi-user.target.wants/kube-proxy.service
rm -rf ~/bootstrap
systemctl daemon-reload

5.3 删目录

1
2
3
4
5
6
7


rm -rf /etc/kubernetes
rm -rf /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}
rm -rf /var/lib/kubelet
rm -rf /var/log/kubernetes
rm -rf /etc/cni/net.d
rm -rf /root/.kube
rm -rf ~/bootstrap/bootstrap.secret.yaml

5.4 清环境变量

1
2
3
4
5
6


# 临时
unset KUBECONFIG

# 永久
sudo sed -i '/KUBECONFIG/d' /etc/profile ~/.bashrc ~/.profile
source ~/.bashrc

5.5 停 etcd

1
2
3
4
5
6
7
8


systemctl status etcd.service
systemctl stop etcd.service
systemctl disable etcd.service
rm -rf /etc/systemd/system/etcd.service
rm -rf /usr/local/bin/etcd*
rm -rf /etc/etcd
rm -rf /var/lib/etcd
systemctl daemon-reload

5.6 停容器运行时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 停所有 docker 相关
systemctl stop docker.service
systemctl disable docker.service
systemctl stop cri-docker.socket
systemctl disable cri-docker.socket
systemctl stop cri-docker.service
systemctl disable cri-docker.service
systemctl stop containerd.service
systemctl disable containerd.service

# 删 systemd 单元
rm -rf /etc/systemd/system/{docker.service,docker.socket,cri-docker.service,cri-docker.socket,containerd.service}
rm -rf /etc/docker
rm -rf /usr/local/bin/{containerd*,docker*,runc,cri-dockerd,ctr}
rm -rf /var/lib/docker
rm -rf /var/lib/containerd
rm -rf /run/cri-dockerd.sock
rm -rf /var/run/docker.sock

systemctl daemon-reload

5.7 其他清理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 网络（IPIP 模式 / CNI）
modprobe -r ipip 2>/dev/null
ip link delete tunl0 2>/dev/null
rm -rf /opt/cni/bin
rm -rf /var/lib/cni
rm -rf /var/lib/calico 2>/dev/null

# bootstrap 目录
rm -rf ~/bootstrap

# 历史镜像
docker system prune -af 2>/dev/null

5.8 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 进程
ps -ef | grep -E "kube|etcd|docker|containerd" | grep -v grep
# 应当空

# 端口
ss -tlnp | grep -E "6443|2379|2380|10250|10251|10252|10255"
# 应当空

# 残留目录
ls /usr/local/bin | grep -E "kube|etcd|containerd|docker"
# 应当空

6. namespace 卡 Terminating 终极清理

卸载过程中如果 namespace 一直卡 Terminating（典型场景：Rook-Ceph、cert-manager）：

1
2
3
4
5


# 通用方法
ns=rook-ceph
kubectl get namespace $ns -o json | jq '.spec = {"finalizers":[]}' > temp.json
curl -k -H "Content-Type: application/json" -X PUT \
 --data-binary @temp.json 127.0.0.1:8001/api/v1/namespaces/$ns/finalize

或：

1

kubectl patch ns rook-ceph --type=merge -p '{"metadata":{"finalizers":null}}'

但要先启动 kubectl proxy：

1

kubectl proxy &

6.1 PVC 卡 Terminating

1
2
3
4


kubectl patch pvc jenkins-agent-pvc -n kube-ops --type=merge -p '{"metadata":{"finalizers":null}}'

kubectl patch pv pvc-c87554c7-6b20-42ed-8cdd-8be1d630a744 \
 -p '{"metadata":{"finalizers":null}}' --type=merge

6.2 Pod 卡 Terminating

1
2
3
4


kubectl patch pod nacos-0 -n safety-xjprod \
 --type=merge -p '{"metadata":{"finalizers":null}}'

kubectl delete po <pod> -n <ns> --grace-period=0 --force

6.3 后台强删 namespace

1
2


nohup kubectl delete ns cattle-impersonation-system --grace-period=0 --force > /dev/null 2>&1 &
nohup kubectl delete ns cattle-system --grace-period=0 --force > /dev/null 2>&1 &

6.4 KubeSphere 等第三方组件

1
2
3
4
5
6
7
8
9


# 看 CRD
kubectl get crd,clusterrole,clusterrolebinding | grep kubesphere

# 删 cluster CRD
kubectl edit crd clusters.cluster.kubesphere.io
# 删 metadata.finalizers 保存

# 后台删 namespace
nohup kubectl delete namespace kubesphere-system --force --grace-period=0 > /dev/null 2>&1 &

7. 排错速查

现象	原因	解决
升级后 `kubectl get node` 仍是旧版本	部分 master 没升完	检查每台 master 的 `kubelet --version`
`etcdctl: this member is not a leader`	etcd 升级没让 leader 先升	先升 leader，重启会自动选主
`kubectl drain` 报 “cannot delete Pods using local storage”	用了 local PV	加 `--delete-emptydir-data --force`
卸载后 `kubelet` 还在	daemon-reload 没跑	跑 `systemctl daemon-reload` 再 `systemctl reset-failed`
节点还在 cluster 里	`kubectl delete node` 没跑	`kubectl delete node <name>`

8. 小结

升级 / 卸载是 K8s 集群"压箱底"操作：

小版本升级 只换二进制，2 分钟一台
卸载顺序：停服务 → 删单元 → 删目录 → 清环境变量
finalizers 是 namespace 卡死的最常见原因，patch 一下就解决
保留备份（etcd snapshot、admin.kubeconfig）永远不亏

下一步：K8s 节点扩容：worker 加入集群一键脚本。

K8s 集群运维命令大全：kubectl 速查 + 节点维护 + harbor 私有仓库

Tue, 15 Oct 2024 00:00:00 +0800

kubectl 是 K8s 运维的"瑞士军刀"

K8s 1.28 时代的运维 90% 都靠 kubectl 完成。本文是"速查手册"——按场景分类，所有命令都可以直接复制粘贴。

适用版本：kubectl ≥ 1.28 / K8s 1.28.5

1. 基础环境

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 启用命令补全
apt install -y bash-completion
echo 'source <(kubectl completion bash)' >> ~/.bashrc
source ~/.bashrc

# 所有用户生效
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null

# 设置别名
echo 'alias k=kubectl' >> ~/.bashrc
source ~/.bashrc

# 设置默认 namespace
kubectl config set-context --current --namespace=rook-ceph

2. 资源查看

2.1 kubectl get 简写表

名称	简写	示例	说明
`pods`	`po`	`k get po -A`	Pod
`services`	`svc`	`k get svc -A`	Service
`deployments`	`deploy`	`k get deploy -A`	Deployment
`statefulsets`	`sts`	`k get sts -A`	StatefulSet
`daemonsets`	`ds`	`k get ds -A`	DaemonSet
`nodes`	`no`	`k get no`	Node
`namespaces`	`ns`	`k get ns`	Namespace
`configmaps`	`cm`	`k get cm -A`	ConfigMap
`secrets`		`k get secret -A`	Secret
`persistentvolumes`	`pv`	`k get pv`	PV
`persistentvolumeclaims`	`pvc`	`k get pvc -A`	PVC
`ingresses`	`ing`	`k get ing -A`	Ingress
`storageclasses`	`sc`	`k get sc`	StorageClass
`events`	`ev`	`k get ev -A`	Event

2.2 常用查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 看所有 kind
kubectl api-resources --verbs=list --namespaced -o name

# 全集群资源
kubectl get all -o wide -A

# 命名空间下所有资源
kubectl api-resources --verbs=list --namespaced -o name | \
 xargs -n 1 kubectl get --show-kind --ignore-not-found -n <namespace>

# 看 image
kubectl get deployment <name> -n <ns> -o jsonpath='{.spec.template.spec.containers[0].image}'

# 镜像与版本
kubectl api-versions

2.3 节点负载

1
2


kubectl top node
kubectl top pod -A

3. 节点管理

3.1 节点状态

1
2
3
4
5
6
7
8


# 查询节点
kubectl get node

# 节点标签
kubectl label nodes worker2 mysql-node=tenant1
kubectl label nodes worker2 mysql-node- # 删除
kubectl get nodes --show-labels
kubectl label nodes worker9 --list

3.2 节点污点（Taints）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 添加污点
kubectl taint nodes master3 node-role.kubernetes.io/master3=:NoSchedule
# 去除
kubectl taint nodes master3 node-role.kubernetes.io/master3-

# Rook-Ceph 专用污点（不让普通 Pod 调度到 mon 节点）
kubectl taint nodes master3 dedicated=ceph:NoSchedule --overwrite

# Rook-Ceph Pod 加容忍度
# kubectl -n rook-ceph edit deploy rook-ceph-operator
# 在 spec.template.spec.tolerations 中加：
tolerations:
 - key: "dedicated"
 operator: "Equal"
 value: "ceph"
 effect: "NoSchedule"

3.3 节点隔离与驱逐

1
2
3
4
5
6
7
8


# 标记不可调度
kubectl cordon master1

# 驱逐 Pod
kubectl drain master1 --delete-emptydir-data --ignore-daemonsets --force

# 恢复调度
kubectl uncordon master1

3.4 删除节点

1
2


kubectl delete node master1
# 节点上的 kubelet 进程会自动停

4. Pod 运维

4.1 查 Pod

1
2
3
4
5


kubectl get po -owide -n <ns>
kubectl get pods -n <ns> | grep redis | awk '{print $1}'

# 详细
kubectl describe po -n kube-system metrics-server-7745c6dfc5-8sjjc

4.2 日志

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 单容器
kubectl logs -f <pod> -n <ns>

# 多容器
kubectl logs -f <pod> -c <container> -n <ns>

# 用标签
kubectl logs -f --tail=100 -l app=nginx -n test

# 时间范围
kubectl logs --since=9h -l app=app -n test
kubectl logs --since-time="2024-12-15T00:00:00Z" -l app=app -n test

4.3 执行命令

1
2
3
4
5
6
7
8
9


# 单次
kubectl exec <pod> -n <ns> -- nslookup kubernetes

# 交互
kubectl exec -it <pod> -- sh
kubectl exec -it <pod> -c <container> -- sh

# 临时容器（K8s 1.23+，调试 CrashLoopBackOff 神器）
kubectl debug -it <pod> --image=busybox:1.28 --target=<container>

4.4 删除

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 正常
kubectl delete po <pod> -n <ns>
kubectl delete -f deployment.yaml

# 强制
kubectl delete po <pod> -n <ns> --grace-period=0 --force
kubectl delete po calico-kube-controllers-546dcc6886-mf8rt -n kube-system --force --grace-period=0

# 批量删 Error
kubectl delete po $(kubectl get po | grep Error | awk '{print $1}')

# 批量删非 Running
kubectl delete pod -n <ns> $(kubectl get pods -n <ns> | grep -v "Running" | awk '{print $1}') --force --grace-period=0

4.5 副本数

1
2


kubectl scale --replicas=1 deployment/<name> -n <ns>
kubectl -n kube-system scale --replicas=10 deployment/coredns

4.6 强制重启

1
2


kubectl rollout restart deployment/<name> -n <ns>
kubectl rollout status deployment/<name> -n <ns>

5. Deployment 高级

5.1 版本回滚

1
2
3
4
5
6
7
8
9


# 记录版本（apply 时 --record 已废弃，用 annotate）
kubectl annotate deployment/<name> kubernetes.io/change-cause="image updated"

# 历史
kubectl rollout history deployment/<name>

# 回滚
kubectl rollout undo deployment/<name>
kubectl rollout undo deployment/<name> --to-revision=2

5.2 HPA（自动扩缩）

1
2
3


# 设置 HPA（注意：设了 HPA 后不能手动 scale）
kubectl autoscale deployment <name> -n <ns> --min=1 --max=1
kubectl edit hpa <name> -n <ns>

5.3 测试压测

1
2


kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- \
 /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

6. Secret 与 harbor

6.1 创建 harbor secret

1
2
3
4
5


kubectl create secret docker-registry harbor-secret \
 --docker-server=<harbor-host>:13001 \
 --docker-username=admin \
 --docker-password={{HARBOR_PASSWORD}} \
 -n <ns>

真实密码用占位符 {{HARBOR_PASSWORD}} 替代。

6.2 Pod 引用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: v1
kind: Pod
metadata:
 name: pod-harbor
spec:
 containers:
 - name: c1
 image: <harbor-host>:13001/test/nginx:v1
 imagePullSecrets:
 - name: harbor-secret

6.3 docker daemon.json（提前配）

所有节点：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": { "max-size": "50m", "max-file": "1" },
 "registry-mirrors": [
 "https://<your-mirror>.mirror.aliyuncs.com",
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com"
 ],
 "insecure-registries": ["<harbor-host>:13001"]
}

6.4 Token（admin 登录）

1

kubectl -n kube-system create token admin-user

7. 内部网络测试

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 创建测试 pod
kubectl run -it --rm busybox --image=busybox:1.28 -- nslookup mine-backend.test

# 测试 DNS
kubectl run busybox --image=busybox:1.28 -- sleep 3600
kubectl exec -it busybox -- sh
nslookup kubernetes.default
nslookup extend-service.test

# 跨 namespace 解析
kubectl exec busybox -n default -- nslookup safety-auth.safety-hnpre.svc.cluster.local

修改 CoreDNS 配置后重启：

1
2
3
4
5
6
7
8
9


kubectl edit configmap coredns -n kube-system

# 改 forward 段
forward . __PILLAR__CLUSTER__DNS__ {
 prefer_udp
 max_concurrent 1000
}

kubectl rollout restart deploy/coredns -n kube-system

8. 命名空间与 finalizers

8.1 命名空间管理

1
2
3


kubectl create ns <name>
kubectl delete ns <name>
kubectl get ns

8.2 namespace 卡 Terminating

1
2
3
4
5
6


ns=cattle-fleet-system
kubectl get namespace $ns -o json | jq '.metadata.finalizers=[]' | \
 kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -

# 通用 patch
kubectl patch ns rook-ceph --type=merge -p '{"metadata":{"finalizers":null}}'

8.3 PVC 卡 Terminating

1
2
3
4


kubectl patch pvc jenkins-agent-pvc -n kube-ops --type=merge -p '{"metadata":{"finalizers":null}}'

kubectl patch pv pvc-c87554c7-6b20-42ed-8cdd-8be1d630a744 \
 -p '{"metadata":{"finalizers":null}}' --type=merge

9. 排错速查表

现象	命令	解决
节点 NotReady	`kubectl describe node <n>`	查 Conditions
Pod Pending	`kubectl describe po <p>`	查 Events
Pod CrashLoopBackOff	`kubectl logs <p> --previous`	看上一次容器日志
Service 不通	`kubectl get ep`	ep 是不是有后端 Pod
NodePort 外网访问不了	`kubectl get svc -o yaml`	type=NodePort, nodePort 范围
DNS 不通	`kubectl exec <p> -- nslookup kubernetes`	CoreDNS Pod 状态
镜像拉不到	`kubectl describe po <p>`	检查 imagePullSecrets
PVC Pending	`kubectl describe pvc`	StorageClass 配额 / 节点亲和
HPA 不会缩	`kubectl describe hpa`	看 metrics-server 是否正常
升级失败	`kubectl rollout undo`	回滚

10. 小结

kubectl 命令覆盖 K8s 运维的 80% 场景：

get + describe + logs 是排障三件套
rollout undo 是版本回滚神器
drain + cordon 是节点维护的标配
drain + delete node 是缩容的标配
patch … finalizers=null 是 namespace 卡死的杀手锏

下一步：K8s 集群升级与卸载：版本升级 + finalizers 清理。

GlusterFS 10 分布式文件系统：七种卷类型 + Kadalu CSI 接入

Sun, 15 Sep 2024 00:00:00 +0800

GlusterFS 在 K8s 时代的角色

GlusterFS 是一个用户态分布式文件系统，2011 年由 Red Hat 收购，是 OpenStack 默认后端存储之一。它有 7 种卷类型，从最简单的"分布式"（类似 RAID0）到"分布式复制卷"（类似 RAID10），可以覆盖几乎所有文件存储场景。

适用版本：GlusterFS 10.5 / Kadalu Operator 1.3.0 / K8s 1.28.5

1. GlusterFS 七种卷类型

卷类型	英文	是否支持（10.5）	特点
分布式卷	Distributed	✅	文件 HASH 到所有 Brick，无冗余，类似 RAID0
复制卷	Replicated	✅	多副本同步，有容错，类似 RAID1
分布式复制卷	Distributed Replicated	✅	兼具分布式+复制，生产推荐
条带卷	Stripe	❌（10.5 移除）	数据分块轮询，类似 RAID0
分布式条带卷	Distributed Stripe	❌	大文件场景
条带复制卷	Stripe Replica	❌	RAID10
分布式条带复制卷	Distributed Stripe Replica	❌	三种基本卷复合
纠删码卷	Dispersed	✅	类似 RAID5/6
分布式纠删码卷	Distributed Dispersed	✅	兼具分布式+纠删码

2. 节点与目录准备

4 节点集群示例：

1
2
3
4


10.0.0.5 worker5
10.0.0.6 worker6
10.0.0.7 worker7
10.0.0.8 worker8

共享目录 /gfs（100GB），所有节点免密登录：

1
2
3
4
5
6
7


apt install -y sshpass
ssh-keygen -f /root/.ssh/id_rsa -P ''
export IP="worker5 worker6 worker7 worker8"
export SSHPASS=<YOUR_SSH_PASSWORD>
for HOST in $IP; do
 sshpass -e ssh-copy-id -o StrictHostKeyChecking=no $HOST
done

实际密码用占位符 <YOUR_SSH_PASSWORD> 替代（执行前请 export SSHPASS=真实密码 后用 sshpass -e 形式调用，避免密码出现在 shell history）。

3. 安装 GlusterFS

3.1 4 节点同时执行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


mkdir -p /gfs

# Ubuntu 22.04 添加 glusterfs 10 源
apt install software-properties-common -y
add-apt-repository ppa:gluster/glusterfs-10 -y
apt update
apt install glusterfs-server -y
systemctl start glusterd
systemctl enable glusterd
gluster --version
# glusterfs 10.5

3.2 加入可信池（任意一节点执行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


gluster peer probe 10.0.0.6
gluster peer probe 10.0.0.7
gluster peer probe 10.0.0.8

gluster pool list
# UUID Hostname State
# 6c831f26-52ee-4895-9df8-ea9f16670cab worker6 Connected
# 48b796bf-3d08-43c6-976c-4e3f586345e5 worker7 Connected
# 69d9b73c-d8e5-42fa-865f-5db204b9b14f worker8 Connected
# 4ea470e9-710a-458d-acd1-1be3c3937609 localhost Connected

注意：peer probe 一次就够（任意一节点执行），其他节点自动同步。

4. 创建分布式卷（无冗余）

master 节点（这里是 worker5/6/7/8 4 节点做演示），先把磁盘做成 XFS：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


mkfs.xfs -f /dev/sdb
mkfs.xfs -f /dev/sdc

mkdir -p /mnt/gluster/sdb
mkdir -p /mnt/gluster/sdc

mount /dev/sdb /mnt/gluster/sdb
mount /dev/sdc /mnt/gluster/sdc

echo "/dev/sdb /mnt/gluster/sdb xfs defaults,noatime 0 0" >> /etc/fstab
echo "/dev/sdc /mnt/gluster/sdc xfs defaults,noatime 0 0" >> /etc/fstab

# 创建子目录
mkdir -p /mnt/gluster/sdb/brick
mkdir -p /mnt/gluster/sdc/brick

umount /mnt/gluster/sdb

创建分布式卷：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


gluster volume create dv \
 transport tcp \
 10.0.0.5:/mnt/gluster/sdb/brick \
 10.0.0.5:/mnt/gluster/sdc/brick \
 10.0.0.6:/mnt/gluster/sdb/brick \
 10.0.0.6:/mnt/gluster/sdc/brick \
 10.0.0.7:/mnt/gluster/sdb/brick \
 10.0.0.7:/mnt/gluster/sdc/brick

gluster volume start dv
gluster volume quota dv enable
gluster volume info dv

4.1 开机自动启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


cat << "EOF" > /etc/systemd/system/gdv.service
[Unit]
Description=Start GlusterFS Volume dv on Boot
After=glusterd.service
Requires=glusterd.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/sbin/gluster --mode=script volume start dv
ExecStop=/usr/sbin/gluster --mode=script volume stop dv force
ExecReload=/usr/sbin/gluster --mode=script volume stop dv -f && /usr/sbin/gluster --mode=script volume start dv

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable gdv
systemctl start gdv

4.2 客户端使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 安装客户端
apt install glusterfs-client -y

# 挂载
mkdir -p /mnt/glusterfs_dv
mount -t glusterfs 10.0.0.5:/dv /mnt/glusterfs_dv

df -h
# 10.0.0.5:/dv 5.3T 92G 5.2T 2% /mnt/glusterfs_dv

# 开机自动挂载
echo "10.0.0.5:/dv /mnt/glusterfs_dv glusterfs defaults,_netdev 0 0" >> /etc/fstab
mount -a

4.3 性能压测（fio）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apt install fio
fio --name=randread \
 --filename=/mnt/glusterfs_dv/testfile \
 --bs=16k \
 --size=1G \
 --time_based \
 --runtime=60 \
 --rw=randread \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=16

# 结果：108MiB/s 吞吐、6886 IOPS，平均延迟 2.3ms

5. 分布式复制卷（生产推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


gluster volume create gv replica 2 transport tcp \
 10.0.0.5:/gfs \
 10.0.0.6:/gfs \
 10.0.0.7:/gfs \
 10.0.0.8:/gfs \
 force

# Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this
gluster volume start gv
gluster volume quota gv enable
gluster volume info gv

重要警告：

volume create: gv: failed: The brick worker5:/gfs is being created in the root partition. ... use 'force' → 用 force 绕过
Replica 2 易脑裂，生产建议 Replica 3（6 节点起步）

删除卷：

1
2
3
4
5


gluster volume stop gv
gluster volume delete gv
gluster peer detach worker6
gluster peer detach worker7
gluster peer detach worker8

6. 客户端验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 在 worker5 上挂
mount -t glusterfs 10.0.0.5:/gv /mnt/glusterfs_gv

# 写 9 个文件
touch /mnt/test{1..9}

# 验证分布（前 2 节点一个复制集，后 2 节点一个复制集）
ls /gfs
# worker5 看到 test1 test2 test4 test5 test8 test9
# worker6 看到 test1 test2 test4 test5 test8 test9
# worker7 看到 test3 test6 test7
# worker8 看到 test3 test6 test7

7. Kadalu Operator 接入 K8s

Kadalu 是 GlusterFS 官方推荐的 K8s CSI 方案，把 GlusterFS 集群变成 K8s StorageClass。

7.1 镜像准备

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


docker login -u admin -p {{HARBOR_PASSWORD}} <harbor-ip>:13001

docker pull kadalu/kadalu-operator:1.3.0
docker tag kadalu/kadalu-operator:1.3.0 <harbor-ip>:13001/base/kadalu/kadalu-operator:1.3.0
docker push <harbor-ip>:13001/base/kadalu/kadalu-operator:1.3.0

docker pull kadalu/kadalu-csi:1.3.0
docker tag kadalu/kadalu-csi:1.3.0 <harbor-ip>:13001/base/kadalu/kadalu-csi:1.3.0
docker push <harbor-ip>:13001/base/kadalu/kadalu-csi:1.3.0

docker pull raspbernetes/csi-node-driver-registrar:2.0.1
docker tag raspbernetes/csi-node-driver-registrar:2.0.1 <harbor-ip>:13001/base/raspbernetes/csi-node-driver-registrar:2.0.1
docker push <harbor-ip>:13001/base/raspbernetes/csi-node-driver-registrar:2.0.1

docker pull raspbernetes/csi-external-provisioner:2.0.2
docker tag raspbernetes/csi-external-provisioner:2.0.2 <harbor-ip>:13001/base/raspbernetes/csi-external-provisioner:2.0.2
docker push <harbor-ip>:13001/base/raspbernetes/csi-external-provisioner:2.0.2

docker pull raspbernetes/csi-external-attacher:3.0.0
docker tag raspbernetes/csi-external-attacher:3.0.0 <harbor-ip>:13001/base/raspbernetes/csi-external-attacher:3.0.0
docker push <harbor-ip>:13001/base/raspbernetes/csi-external-attacher:3.0.0

docker pull raspbernetes/csi-external-resizer:1.0.0
docker tag raspbernetes/csi-external-resizer:1.0.0 <harbor-ip>:13001/base/raspbernetes/csi-external-resizer:1.0.0
docker push <harbor-ip>:13001/base/raspbernetes/csi-external-resizer:1.0.0

docker pull busybox
docker tag busybox <harbor-ip>:13001/base/library/busybox
docker push <harbor-ip>:13001/base/library/busybox

7.2 SSH 密钥

1
2
3
4
5


kubectl create ns kadalu
kubectl create secret generic glusterquota-ssh-secret \
 --from-literal=glusterquota-ssh-username=root \
 --from-file=ssh-privatekey=/root/.ssh/id_rsa \
 -n kadalu

7.3 部署 Operator

1
2
3
4
5


curl -L -o kadalu-operator.yaml https://github.com/kadalu/kadalu/releases/download/1.3.0/kadalu-operator.yaml
# 替换镜像
sed -i "s#docker.io/kadalu/kadalu-operator:1.3.0#<harbor-ip>:13001/base/kadalu/kadalu-operator:1.3.0#g" kadalu-operator.yaml

kubectl apply -f kadalu-operator.yaml

7.4 接入外部 GlusterFS 集群

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: kadalu-operator.storage/v1alpha1
kind: KadaluStorage
metadata:
 name: gfs
spec:
 type: External
 kadalu_format: native
 details:
 gluster_hosts:
 - 10.0.0.5
 - 10.0.0.6
 - 10.0.0.7
 - 10.0.0.8
 gluster_volname: gv
 gluster_options: log-level=DEBUG

1

kubectl apply -f /data/k8scnf/kadalu/kadalu.yml

7.5 设置默认 StorageClass

1

kubectl patch storageclass kadalu.gfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

7.6 测试

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# gfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-gfs
 namespace: testgfs
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Gi
 storageClassName: kadalu.gfs

1
2
3
4
5
6


kubectl create ns testgfs
kubectl apply -f gfs-pvc.yaml
kubectl apply -f gfs-nginx.yaml

# 访问 nginx（通过 nodeport）
http://<vip-internal>:30052

上传文件到 /mnt/subvol/22/88/pvc-xxx/（glusterfs 物理路径），页面能立刻看到。

8. 常见问题

8.1 `chown: changing ownership of '/data': Transport endpoint is not connected`

1
2


gluster pool list
# 看哪些 peer Disconnected

修复：检查防火墙、24007 端口、glusterd 服务。

8.2 `volume create: failed: The brick ... is being created in the root partition`

brick 必须在独立挂载点（或子目录），不能直接用根分区。用 force 绕过。

8.3 Replica 2 脑裂

Replica 2 易脑裂。生产用 Replica 3 或 Arbiter Volume。

8.4 卷扩容

1

gluster volume add-brick gv node03:/data/brick1 node04:/data/brick1

8.5 Kadalu 排错

1
2
3
4
5


# 节点上能访问 gluster
nc -zv 10.0.0.5 24007

# 容器内能查
kubectl exec -it kadalu-csi-provisioner-0 -n kadalu -c kadalu-logging -- sh

9. 小结

GlusterFS 在 K8s 上依然有它的位置——比 Ceph 简单，比 NFS 强：

分布式卷 无冗余，胜在容量大
分布式复制卷 兼顾容量和安全，生产推荐
Kadalu 是把 GlusterFS 集群接入 K8s 的官方方式
Replica 3 才能保证脑裂不丢数据

下一步：MinIO / JuiceFS / OpenEBS：K8s 对象存储与本地 PV 全方案。

Rook-Ceph 1.17 分布式存储：块存储 RBD + CephFS + OSD/MON 实战

Thu, 15 Aug 2024 00:00:00 +0800

为什么用 Rook 部署 Ceph

Ceph 是开源分布式存储"老大哥"，提供 3 种存储接口：

RBD（块存储）：单 Pod 独占，ReadWriteOnce，性能最高
CephFS（共享文件系统）：多 Pod 共享，ReadWriteMany，适合数据共享
RGW（对象存储）：S3 兼容，适合大文件备份

Rook 是 CNCF 毕业项目，把 Ceph 复杂的手工部署变成 K8s Operator 模式：CRD 定义存储集群，Operator 维护所有守护进程。

适用版本：Rook v1.17.4 / Ceph v19.2.2（Reef）/ K8s 1.28.5 内核要求：≥ 4.17（CephFS 配额强制）

1. 架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


 ┌─────────────────────────────┐
 │ K8s Control Plane │
 └──────────────┬───────────────┘
 │ Operator 管理
 ▼
 ┌─────────────────────────────┐
 │ Rook Ceph Operator (CRD) │
 └──────┬──────┬──────┬────────┘
 │ │ │
 ┌───────▼──┐ ┌─▼───┐ ┌─▼───────┐
 │ MON │ │ MGR │ │ OSD │
 │ (3 副本) │ │ 2 │ │ (N 块盘)│
 └──────────┘ └─────┘ └─────────┘
 │ │
 └──────┬──────┘
 ▼
 ┌────────────────────────┐
 │ RBD / CephFS / RGW │
 └────────────────────────┘

Rook 部署后产出的 Operator 守护：

Operator：控制端，监控存储守护进程
Agent：每个存储节点
OSD：每块硬盘一个 OSD，提供存储
MON：监控集群，记录拓扑
MDS：CephFS 元数据服务
RGW：S3 接口（可选）
MGR：统一管理入口

2. 部署 Rook Operator

2.1 克隆代码

1
2


git clone --single-branch --branch v1.17.4 https://github.com/rook/rook.git
cd rook/deploy/examples

2.2 镜像替换

默认镜像从 quay.io / registry.k8s.io 拉，生产环境要先 tag 到私有 harbor：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


docker login -u admin -p {{HARBOR_PASSWORD}} <harbor-ip>:13001

# operator
docker pull quay.io/cephcsi/cephcsi:v3.14.0
docker tag quay.io/cephcsi/cephcsi:v3.14.0 <harbor-ip>:13001/base/cephcsi/cephcsi:v3.14.0
docker push <harbor-ip>:13001/base/cephcsi/cephcsi:v3.14.0

docker pull registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.13.0
docker tag registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.13.0 <harbor-ip>:13001/base/sig-storage/csi-node-driver-registrar:v2.13.0
docker push <harbor-ip>:13001/base/sig-storage/csi-node-driver-registrar:v2.13.0

docker pull registry.k8s.io/sig-storage/csi-resizer:v1.13.2
docker tag registry.k8s.io/sig-storage/csi-resizer:v1.13.2 <harbor-ip>:13001/base/sig-storage/csi-resizer:v1.13.2
docker push <harbor-ip>:13001/base/sig-storage/csi-resizer:v1.13.2

docker pull registry.k8s.io/sig-storage/csi-provisioner:v5.2.0
docker tag registry.k8s.io/sig-storage/csi-provisioner:v5.2.0 <harbor-ip>:13001/base/sig-storage/csi-provisioner:v5.2.0
docker push <harbor-ip>:13001/base/sig-storage/csi-provisioner:v5.2.0

docker pull registry.k8s.io/sig-storage/csi-snapshotter:v8.2.1
docker tag registry.k8s.io/sig-storage/csi-snapshotter:v8.2.1 <harbor-ip>:13001/base/sig-storage/csi-snapshotter:v8.2.1
docker push <harbor-ip>:13001/base/sig-storage/csi-snapshotter:v8.2.1

docker pull registry.k8s.io/sig-storage/csi-attacher:v4.8.1
docker tag registry.k8s.io/sig-storage/csi-attacher:v4.8.1 <harbor-ip>:13001/base/sig-storage/csi-attacher:v4.8.1
docker push <harbor-ip>:13001/base/sig-storage/csi-attacher:v4.8.1

docker pull docker.io/rook/ceph:v1.17.4
docker tag docker.io/rook/ceph:v1.17.4 <harbor-ip>:13001/base/rook/ceph:v1.17.4
docker push <harbor-ip>:13001/base/rook/ceph:v1.17.4

docker pull quay.io/ceph/ceph:v19.2.2
docker tag quay.io/ceph/ceph:v19.2.2 <harbor-ip>:13001/base/ceph/ceph:v19.2.2
docker push <harbor-ip>:13001/base/ceph/ceph:v19.2.2

修改 operator.yaml 镜像源：

1
2


sed -i "s#image: rook/ceph:v1.14.8#image: <harbor-ip>:13001/base/rook/ceph:v1.17.4#g" operator.yaml
sed -i "s#image: quay.io/ceph/ceph:v18.2.2#image: <harbor-ip>:13001/base/ceph/ceph:v19.2.2#g" cluster.yaml

2.3 应用

1

kubectl create -f crds.yaml -f common.yaml -f operator.yaml

2.4 创建 CephCluster

cluster.yaml 关键配置：

1
2
3
4
5
6
7


spec:
 cephVersion:
 image: <harbor-ip>:13001/base/ceph/ceph:v19.2.2
 dataDirHostPath: /var/lib/rook
 storage:
 useAllNodes: true # 用所有节点
 useAllDevices: true # 用所有未分区盘

或精确指定：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


spec:
 storage:
 useAllNodes: false
 useAllDevices: false
 config:
 nodes:
 - name: "master1"
 devices:
 - name: "sdb"
 - name: "sdc"
 - name: "master2"
 devices:
 - name: "sdb"
 - name: "sdc"
 - name: "master3"
 devices:
 - name: "sdb"
 - name: "sdc"

1

kubectl create -f cluster.yaml

2.5 验证

1
2


kubectl -n rook-ceph get pods
# 应该有 3 个 mon、2 个 mgr、多个 osd、csi-rbdplugin、csi-cephfsplugin 等

3. 块存储（RBD）StorageClass

3.1 创建 CephBlockPool

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
 name: replicapool
 namespace: rook-ceph
spec:
 failureDomain: host  # host 级容灾
 replicated:
 size: 3 # 3 副本
 requireSafeReplicaSize: true

3.2 创建 StorageClass

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: rook-ceph-block
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
 clusterID: rook-ceph  # namespace:cluster
 pool: replicapool
 imageFormat: "2"
 imageFeatures: layering
 csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
 csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
 csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
 csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph
 csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
 csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
 csi.storage.k8s.io/fstype: ext4
allowVolumeExpansion: true
reclaimPolicy: Delete

3.3 测试 PVC

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: rbd-pvc
 namespace: rook-ceph
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: rook-ceph-block

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: v1
kind: Pod
metadata:
 name: rbd-demo-pod
 namespace: rook-ceph
spec:
 containers:
 - name: rbd-demo-pod
 image: busybox:stable-glibc
 command: ["sleep", "3600"]
 volumeMounts:
 - mountPath: /var/lib/www/html
 name: data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: rbd-pvc

验证：

1
2
3
4
5


kubectl exec rbd-demo-pod -n rook-ceph -- df -ah
# 看到 /dev/rbd0 1G

kubectl delete -f rbd-pod.yaml
kubectl delete -f rbd-pvc.yaml

4. CephFS 共享文件系统

4.1 创建 CephFilesystem

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


apiVersion: ceph.rook.io/v1
kind: CephFilesystem
metadata:
 name: myfs
 namespace: rook-ceph
spec:
 metadataPool:
 replicated:
 size: 3
 requireSafeReplicaSize: true
 dataPools:
 - failureDomain: host
 replicated:
 size: 3
 requireSafeReplicaSize: true
 metadataServer:
 activeCount: 1 # 生产建议 3
 preserveFilesystemOnDelete: true

4.2 StorageClass

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: rook-cephfs
provisioner: rook-ceph.cephfs.csi.ceph.com
parameters:
 clusterID: rook-ceph
 fsName: myfs
 pool: myfs-replicated
 csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
 csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
 csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
 csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph
 csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
 csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
reclaimPolicy: Delete

4.3 测试 RWX

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: busybox-data-pvc
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 2Gi
 storageClassName: rook-cephfs
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: busybox
spec:
 replicas: 2
 selector:
 matchLabels:
 app: busybox
 template:
 metadata:
 labels:
 app: busybox
 spec:
 containers:
 - name: busybox-container
 image: busybox:stable-glibc
 command: ["sleep", "3600"]
 volumeMounts:
 - name: data-volume
 mountPath: /data
 volumes:
 - name: data-volume
 persistentVolumeClaim:
 claimName: busybox-data-pvc

两个 Pod 都能读写 /data，就是 CephFS 的 RWX 能力。

5. RBD 块存储的局限

RBD 是块设备，只能 ReadWriteOnce 挂载到单个 Pod。Deployment 滚动更新时：

旧 Pod 还挂载着 RBD
新 Pod 调度到不同节点，想再挂载同一个 PV → 失败
旧 Pod 没删除前，RBD 不让别的 Pod 挂

解决方案：

用 CephFS / GlusterFS 这种支持 RWX 的存储
给 Node 加 label，Pod 强制调度到固定 Node（不推荐，单点）

6. Dashboard

1

kubectl apply -f dashboard-external-https.yaml

获取密码：

1

kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode

默认用户 admin，可以登录后改密。

7. Toolbox（排障工具）

1
2


kubectl create -f toolbox.yaml
kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

常用命令：

1
2
3
4
5
6
7


ceph status # 集群状态
ceph osd status # OSD 状态
ceph osd tree # OSD 拓扑
ceph df # 容量使用
ceph health detail # 健康详情
ceph mgr module enable rook
ceph orch set backend rook

8. 常见问题

8.1 MON_DISK_LOW: mon is low on available space

/var/lib/rook 或 mon 容器所在节点的 /var 满了：

1
2
3
4
5
6


docker system prune -af
journalctl --vacuum-time=1w
journalctl --vacuum-size=500M

# 大头往往是 /var/lib/docker 和 /var/lib/kubelet
du -sh /var/lib/* | sort -hr | head

8.2 MON_CLOCK_SKEW detected on mon.b, mon.c

时钟漂移。检查所有节点 ntp/chrony：

1
2
3
4
5
6
7
8


kubectl -n rook-ceph get cm rook-config-override -o yaml

# 放宽容忍
apiVersion: v1
data:
 config: |
 [global]
 mon clock drift allowed = 1

重启 mon：

1

kubectl -n rook-ceph delete pod $(kubectl -n rook-ceph get pods -o custom-columns=NAME:.metadata.name --no-headers | grep mon)

8.3 TOO_FEW_OSDS

少于 3 块 OSD。Ceph 需要至少 3 副本。检查每台节点上是否真的发现了裸盘：

1
2


lsblk
# 应该是裸盘，不能有分区或文件系统

8.4 卸载卡 Terminating

1
2
3
4
5


NAMESPACE=rook-ceph
kubectl proxy &

kubectl get namespace $NAMESPACE -o json | jq '.spec = {"finalizers":[]}' > temp.json
curl -k -H "Content-Type: application/json" -X PUT --data-binary @temp.json 127.0.0.1:8001/api/v1/namespaces/$NAMESPACE/finalize

8.5 cephcluster 无法删除

1
2


kubectl edit cephcluster.ceph.rook.io -n rook-ceph
# 删掉 finalizers 字段

8.6 卸载后硬盘数据未清

1
2
3


sgdisk --zap-all /dev/sdb
dd if=/dev/zero of=/dev/sdb bs=1M count=100 oflag=direct,dsync
blkdiscard /dev/sdb

9. 小结

Rook-Ceph 是 K8s 上跑 Ceph 的事实标准：

RBD 适合 RWO 高性能场景（数据库）
CephFS 适合 RWX 共享场景（多 Pod 数据共享）
MON/OSD 至少 3 副本，生产至少 3 节点 9 块盘
磁盘满、时钟漂移 是最常见的 2 类故障

下一步：GlusterFS 10 分布式文件系统：七种卷类型 + Kadalu CSI 接入。

K8s Dashboard + Reloader 部署实战

Mon, 15 Jul 2024 00:00:00 +0800

Dashboard 与 Reloader

Dashboard 是 K8s 官方 Web UI，可以看 Pod/Service/Deployment 状态，看日志，exec 进容器，编辑资源。生产环境强烈建议部署一个，方便排障。

Reloader（stakater/Reloader）能监听 ConfigMap / Secret 变化，自动滚动升级引用了这些 ConfigMap/Secret 的 Deployment / StatefulSet / DaemonSet。生产环境必备——改一个配置不用手动 rollout。

适用版本：Dashboard v2.7.0 / Reloader v1.0.80 / K8s 1.28.5

1. Dashboard 部署

1.1 快速部署

1
2
3
4


mkdir -p /data/k8scnf/dashboard && cd /data/k8scnf/dashboard

# 默认官方 yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

1.2 修改为 NodePort

默认 Dashboard Service 是 ClusterIP，外部访问不到。改成 NodePort：

1

kubectl edit svc kubernetes-dashboard -n kubernetes-dashboard

1
2
3
4
5
6
7
8


spec:
 type: NodePort
 ports:
 - port: 443
 targetPort: 8443
 nodePort: 32443
 selector:
 k8s-app: kubernetes-dashboard

或者直接修改 recommended.yaml 后 apply。

1.3 创建 admin user

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


cat << "EOF" > dashboard-user.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
 name: admin-user
 namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: admin-user
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
- kind: ServiceAccount
 name: admin-user
 namespace: kube-system
EOF

kubectl apply -f dashboard-user.yaml

1.4 生成登录 token

1
2
3
4
5


# K8s 1.24+ 用 create token
kubectl -n kube-system create token admin-user

# K8s 1.23 及以下用以下方法
# kubectl -n kube-system get secret $(kubectl -n kube-system get sa/admin-user -o jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64 -d

token 默认 1 小时过期，可以延长：

1

kubectl edit -n kubernetes-dashboard deploy/kubernetes-dashboard

1
2
3
4
5


spec:
 containers:
 - args:
 - --auto-generate-certificates
 - --token-ttl=86400  # 单位分钟，1 天

1.5 访问 Dashboard

1
2
3
4
5
6


# 通过 VIP 访问（生产推荐）
https://<vip-internal>:32443/#/login
https://<vip-public>:32443/#/login

# 或通过任意 master 节点
https://<master1-ip>:32443/#/login

输入上一步生成的 token 即可登录。

1.6 修改 dashboard-metrics-scraper

Dashboard 还依赖 dashboard-metrics-scraper（拉取 metrics 数据），要确保镜像能拉到。如果用私有 harbor，需要替换：

1
2
3
4
5


kubectl edit deploy dashboard-metrics-scraper -n kubernetes-dashboard

# image: kubernetesui/metrics-scraper:v1.0.8
# 改为
# image: <private-registry>/base/kubernetesui/metrics-scraper:v1.0.8

2. Reloader 部署

2.1 为什么需要 Reloader

K8s Deployment 不会自动监听 ConfigMap 变化。改了一个 ConfigMap 之后，Pod 内的配置还是旧的——必须手动 kubectl rollout restart deployment。

Reloader 通过 watch apiserver 事件解决这个问题：

监听 reload.annotation 标注的 ConfigMap / Secret
一旦内容变化，自动 rollout 引用此 ConfigMap 的所有 Deployment / StatefulSet / DaemonSet

2.2 部署

1
2
3
4


mkdir -p /data/k8scnf/reloader && cd /data/k8scnf/reloader

# 下载官方 yaml
curl -L -o reloader.yaml https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

修改镜像（用国内源 / 私有 harbor）：

1

sed -i "s#stakater/reloader:#<private-registry>/base/stakater/reloader:#g" reloader.yaml

应用：

1

kubectl apply -f reloader.yaml

2.3 验证

1
2
3
4


kubectl get pods -A | grep reloader
# reloader-xxx 1/1 Running 0 1m

kubectl logs -f <reloader-pod-name>

2.4 使用方法

自动 reload 所有 ConfigMap

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 annotations:
 reloader.stakater.com/auto: "true" # 任何 ConfigMap/Secret 变化都自动 reload
spec:
 template:
 spec:
 containers:
 - name: my-app
 envFrom:
 - configMapRef:
 name: my-app-config

精确控制 reload 哪些 ConfigMap

1
2
3
4
5
6
7
8


apiVersion: v1
kind: ConfigMap
metadata:
 name: my-app-config
 annotations:
 reloader.stakater.com/match: "true" # 这个 ConfigMap 变化时，触发 reload 标了 reloader.stakater.com/match 的 Deployment
data:
 key: value

1
2
3
4
5
6
7
8


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 annotations:
 reloader.stakater.com/match: "true" # 只 reload 标了 match 的 ConfigMap
spec:
 ...

Reload Secret

1
2
3
4
5
6
7
8
9


apiVersion: v1
kind: Secret
metadata:
 name: my-app-secret
 annotations:
 reloader.stakater.com/auto: "true"
type: Opaque
stringData:
 password: "{{SECRET_PASSWORD}}"

2.5 实战场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 1. 创建 ConfigMap
kubectl create cm mysql-config -n test --from-literal=db.host=mysql-master

# 2. Deployment 引用
# envFrom: configMapRef: name: mysql-config
# annotations: reloader.stakater.com/auto: "true"

# 3. 改 ConfigMap
kubectl edit cm mysql-config -n test
# 改一个 value 后 :wq 退出

# 4. 自动生效
# kubectl get pods -n test -l app=mysql
# 能看到 Pod 已经被重建

3. 排错

3.1 Dashboard 403 / token 无效

检查 token 是否过期
检查 ClusterRoleBinding 里的 namespace 是否正确

3.2 Dashboard 页面空白

metrics-scraper 没拉起来：

1
2


kubectl logs -n kubernetes-dashboard deploy/dashboard-metrics-scraper
# 通常是镜像拉不到

3.3 Reloader 不触发

检查 Deployment 是否有 reloader.stakater.com/auto: "true" annotation
检查 ConfigMap 是不是真的被 Deployment 引用
看 Reloader Pod 日志：

1

kubectl logs -f -l app=reloader

3.4 Reloader 触发后 Pod 起不来

通常是 ConfigMap 内容错了。先 kubectl describe pod 看 event 排错。

4. 小结

Dashboard + Reloader 是 K8s 集群"运维体验"的关键：

Dashboard 给非 K8s 用户一个 Web 入口，token 方式鉴权
Reloader 让 ConfigMap 改动自动生效，省去手动 rollout
两者都依赖基础镜像能拉到，私有 harbor 部署要提前 tag + push

下一步：NFS 存储实战：单节点 + Keepalived 双机热备。

K8s 核心插件部署：Calico 网络 + CoreDNS + Metrics-server

Sat, 15 Jun 2024 00:00:00 +0800

为什么需要这些插件

K8s 1.28 集群"裸装"起来后，节点虽然 Ready，但还不能真正跑业务——还差三件套：

网络插件（Calico / Flannel / Cilium）：给 Pod 分配 IP，实现跨节点 Pod 互通 + Network Policy
DNS 插件（CoreDNS）：让 Pod 能用 Service 名解析集群内服务
Metrics 插件（Metrics-server）：给 kubectl top / HPA 提供 metrics API

本文部署 1.28 时代最稳的组合：Calico v3.29 + CoreDNS 1.10 + Metrics-server v0.6.4。

适用版本：Calico v3.29.3 / CoreDNS 1.10.1 / Metrics-server v0.6.4 / K8s 1.28.5

1. Calico 网络插件

1.1 安装方式选择

Calico 支持两种部署：

Operator 模式（推荐，K8s 1.20+）：通过 tigera-operator 管理
Static manifests 模式：直接 apply 一堆 yaml

生产用 Operator 模式：

1
2
3
4


mkdir -p /data/k8scnf/calico && cd /data/k8scnf/calico

# 下载 v3.29.3
curl -L -o calico.yaml https://raw.githubusercontent.com/projectcalico/calico/v3.29.3/manifests/calico.yaml

1.2 关键参数

Calico 部署后，所有 Pod 的 IP 都来自 cluster-cidr，本集群是 172.218.0.0/12。

Pod CIDR 与 kube-controller-manager 的 --cluster-cidr 必须一致。

1.3 应用

1

kubectl apply -f /data/k8scnf/calico/calico.yaml

1.4 验证

1
2
3
4
5
6


kubectl get pods -A
# NAMESPACE NAME READY STATUS RESTARTS AGE
# kube-system calico-kube-controllers-7ddc4f45bc-9j22g 1/1 Running 0 2m
# kube-system calico-node-b68zm 1/1 Running 0 2m
# kube-system calico-node-fstr6 1/1 Running 0 2m
# kube-system calico-node-xp8pp 1/1 Running 0 2m

每台 Node 都有一个 calico-node-* Pod Running，集群就 OK。

1.5 IPIP / BGP 模式

Calico 默认用 IPIP（IP-in-IP）封装。如果数据中心路由器支持 BGP，可以切到 BGP 模式减少封装开销：

1
2


# calicoctl get bgpPeer
# 或编辑 calico-node DaemonSet

1.6 卸载 Calico

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 删除 K8s 资源
kubectl delete -f calico.yaml

# 检查并清理每个节点的网络（卸载 IPIP 模块）
ip addr show | grep -i tunl # 看到 tunl0 表示 IPIP 还在
modprobe -r ipip

# 删除 CNI 残留
rm -rf /etc/cni/net.d/*
rm -rf /opt/cni/bin/*
rm -rf /var/lib/cni/*
rm -rf /var/lib/calico

systemctl restart kubelet

1.7 常见问题

报错：

1
2


felix/ipsets.go 569: Bad return code from 'ipset list'.
error=exit status 1 family="inet" stderr="ipset v7.11: Kernel and userspace incompatible: settype hash:ip,port with revision 7 not supported by userspace."

原因：内核与 ipset userspace 版本不兼容。

解决：升级 Calico 到 v3.29.3（修复了该问题），如果还在用 v3.26.1 必须升级：

1
2
3
4


docker pull docker.io/calico/node:v3.29.3
docker tag calico/node:v3.29.3 <private-registry>/base/calico/node:v3.29.3
docker push <private-registry>/base/calico/node:v3.29.3
# 对 cni、kube-controllers 镜像同样处理

2. CoreDNS 部署

2.1 安装 Helm

1
2
3
4
5
6


cd /data/softs
tar xvf helm-v3.13.3-linux-amd64.tar.gz
cp linux-amd64/helm /usr/local/bin/
rm -rf linux-amd64
helm version
# version.BuildInfo{Version:"v3.13.3", ...}

2.2 添加仓库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


helm repo add coredns https://coredns.github.io/helm
helm repo update

# 离线下载
helm pull coredns/coredns
# Error: Get "...coredns-1.29.0.tgz": dial tcp 20.205.243.166:443: connect: connection refused

# 离线下载（手动从 GitHub release 拿）
tar xvf coredns-1.29.0.tgz
mv /data/coredns /data/k8scnf
cd /data/k8scnf/coredns

2.3 修改 values.yaml

1
2


service:
 clusterIP: "10.96.0.10"

把镜像地址改国内源：

1

sed -i "s#registry.k8s.io/#registry.aliyuncs.com/google_containers/#g" coredns/values.yaml

2.4 安装

1

helm install coredns ./ -n kube-system

2.5 验证

1
2
3
4
5
6


# 部署一个测试 Pod
kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools

# 在容器内
> host kubernetes
kubernetes.default.svc.cluster.local has address 10.96.0.1

2.6 kubectl apply 方式（备选）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 来自 K8s 1.28.5 源码
curl -L -o coredns.yaml https://raw.githubusercontent.com/kubernetes/kubernetes/v1.28.5/cluster/addons/dns/coredns/coredns.yaml.base

# 修改 4 个占位符
# __DNS__DOMAIN__ → cluster.local
# __DNS__MEMORY__LIMIT__ → 150Mi
# __DNS__SERVER__ → 10.96.0.10
# image: registry.aliyuncs.com/google_containers/coredns:v1.10.1

kubectl apply -f /data/k8scnf/coredns/coredns.yaml

2.7 性能优化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 副本数控制
kubectl -n kube-system scale --replicas=3 deployment/coredns

# HPA
cat << "EOF" | kubectl apply -f -
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
 name: coredns
 namespace: kube-system
spec:
 maxReplicas: 10
 minReplicas: 2
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: coredns
 targetCPUUtilizationPercentage: 50
EOF

2.8 常见问题

CoreDNS 一直 CrashLoopBackOff：

1
2


kubectl describe pods -n kube-system coredns-687c56b785-fz2mx
# 原因：因为 /etc/resolv.conf 中存在 nameserver 127.0.0.53 回环地址造成循环引用

解决：在所有节点上：

1
2
3
4
5
6
7
8


sudo apt install -y unbound
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm -rf /etc/resolv.conf
sudo touch /etc/resolv.conf
systemctl daemon-reload
systemctl restart docker.service
systemctl restart kubelet

3. Metrics-server 部署

3.1 下载

1
2
3
4
5


mkdir -p /data/k8scnf/metrics-server && cd /data/k8scnf/metrics-server

# HA 版本（生产用）
curl -L -o high-availability.yaml \
 https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/high-availability.yaml

3.2 修改镜像 + 参数

1
2


# 镜像改国内源
sed -i "s#registry.k8s.io/metrics-server#registry.cn-hangzhou.aliyuncs.com/google_containers#g" high-availability.yaml

加 --kubelet-insecure-tls（跳过 kubelet 证书校验，自签证书集群必备）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


spec:
 template:
 spec:
 containers:
 - args:
 - --cert-dir=/tmp
 - --secure-port=4443
 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
 - --kubelet-use-node-status-port
 - --metric-resolution=15s
 - --kubelet-insecure-tls
 image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.4

挂载主机 pki 目录（让 metrics-server 验证 kubelet 证书）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


volumeMounts:
 - mountPath: /tmp
 name: tmp-dir
 - name: ca-ssl
 mountPath: /etc/kubernetes/pki
volumes:
 - emptyDir: {}
 name: tmp-dir
 - name: ca-ssl
 hostPath:
 path: /etc/kubernetes/pki

修改 apiVersion: policy/v1beta1 为 policy/v1（K8s 1.25+ 必改）：

1

sed -i 's#policy/v1beta1#policy/v1#g' high-availability.yaml

3.3 部署

1

kubectl apply -f /data/k8scnf/metrics-server/high-availability.yaml

3.4 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


kubectl get pods -A | grep metrics
# kube-system metrics-server-5ff5cfd88f-j68v5 1/1 Running 0 15s
# kube-system metrics-server-5ff5cfd88f-zx47p 1/1 Running 0 15s

kubectl top node
# NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
# master1 170m 4% 1706Mi 45%
# master2 186m 4% 1669Mi 44%
# master3 148m 3% 1641Mi 43%

kubectl top pod -A
# 看每个 Pod 的 CPU / 内存

3.5 排错

kubectl top node 报 Metrics API not available：

1
2


kubectl logs -n kube-system -l k8s-app=metrics-server
# 通常是 --kubelet-insecure-tls 没加 或 pki 挂载错

4. 集群 Ready 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 集群核心组件
kubectl get cs
# NAME STATUS MESSAGE ERROR
# scheduler Healthy ok
# controller-manager Healthy ok
# etcd-0 Healthy ok

# 节点
kubectl get node
# 全部 Ready

# 部署一个测试 pod
kubectl run busybox --image=busybox:1.28 -- sleep 3600
kubectl exec busybox -- nslookup kubernetes
# Server: 10.96.0.10
# Address 1: 10.96.0.10 coredns.kube-system.svc.cluster.local
# Name: kubernetes
# Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

至此 K8s 集群可观测、可调度、可服务发现——达到生产可用状态。

5. 小结

网络 + DNS + Metrics 三大件是 K8s 集群"能跑起来"的最低要求：

Calico 是 1.28 时代最稳的网络方案（IPIP 模式兼容所有网络环境）
CoreDNS 必须用 helm 或 kubectl apply，别忘了关 systemd-resolved
Metrics-server 必须加 --kubelet-insecure-tls（自签证书集群）

下一步：K8s Dashboard + Reloader 部署实战。

K8s 节点组件部署：kubelet + kube-proxy + IPVS

Wed, 15 May 2024 00:00:00 +0800

kubelet + kube-proxy 是什么

kubelet 是每个 Node 上的"代理"，负责：

接收 apiserver 的 Pod spec
调用容器运行时（cri-dockerd）启动容器
上报节点状态、心跳、资源 metrics

kube-proxy 是每个 Node 上的"网络代理"，负责：

监听 apiserver 的 Service / Endpoints 变化
维护节点上 iptables 或 IPVS 规则
实现 ClusterIP、NodePort 的流量转发

适用版本：Kubernetes 1.28.5 / IPVS 部署位置：所有 master + worker 节点

1. kubelet 部署

1.1 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


cat << "EOF" > /etc/systemd/system/kubelet.service
[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kubelet \
 --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig \
 --kubeconfig=/etc/kubernetes/kubelet.kubeconfig \
 --config=/etc/kubernetes/kubelet-conf.yml \
 --container-runtime-endpoint=unix:///run/cri-dockerd.sock \
 --node-labels=node.kubernetes.io/node=
Restart=always
RestartSec=5
StartLimitInterval=0

[Install]
WantedBy=multi-user.target
EOF

1.2 kubelet-conf.yml（关键）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70


apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
port: 10250
readOnlyPort: 10255
authentication:
 anonymous:
 enabled: false
 webhook:
 cacheTTL: 2m0s
 enabled: true
 x509:
 clientCAFile: /etc/kubernetes/pki/ca.pem
authorization:
 mode: Webhook
 webhook:
 cacheAuthorizedTTL: 5m0s
 cacheUnauthorizedTTL: 30s
cgroupDriver: systemd  # 必须与 docker daemon.json 一致
cgroupsPerQOS: true
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
containerLogMaxFiles: 5
containerLogMaxSize: 10Mi
contentType: application/vnd.kubernetes.protobuf
cpuCFSQuota: true
cpuManagerPolicy: none
cpuManagerReconcilePeriod: 10s
enableControllerAttachDetach: true
enableDebuggingHandlers: true
enforceNodeAllocatable:
- pods
eventBurst: 10
eventRecordQPS: 5
evictionHard:
 imagefs.available: 15%
 memory.available: 100Mi
 nodefs.available: 10%
 nodefs.inodesFree: 5%
evictionPressureTransitionPeriod: 5m0s
failSwapOn: true # 强制要求 swap 已禁
fileCheckFrequency: 20s
hairpinMode: promiscuous-bridge
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 20s
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80
imageMinimumGCAge: 2m0s
iptablesDropBit: 15
iptablesMasqueradeBit: 14
kubeAPIBurst: 10
kubeAPIQPS: 5
makeIPTablesUtilChains: true
maxOpenFiles: 1000000
maxPods: 110
nodeStatusUpdateFrequency: 10s
oomScoreAdj: -999
podPidsLimit: -1
registryBurst: 10
registryPullQPS: 5
resolvConf: /etc/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 2m0s
serializeImagePulls: true
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 4h0m0s
syncFrequency: 1m0s
volumeStatsAggPeriod: 1m0s

1.3 复制到所有节点

1
2
3
4
5
6


for NODE in master1 master2 master3 worker1 worker2 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do
 scp /etc/kubernetes/kubelet-conf.yml $NODE:/etc/kubernetes/
 scp /etc/kubernetes/bootstrap-kubelet.kubeconfig $NODE:/etc/kubernetes/
 scp /etc/kubernetes/kube-proxy.kubeconfig $NODE:/etc/kubernetes/
 scp /etc/systemd/system/kubelet.service $NODE:/etc/systemd/system/
done

1.4 启动 kubelet

1
2
3
4
5


systemctl daemon-reload
systemctl enable --now kubelet.service
systemctl restart kubelet.service
systemctl status kubelet.service
journalctl -f -u kubelet

1.5 命令补全

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


cat << "EOF" >> /root/.bashrc
export KUBECONFIG=/etc/kubernetes/admin.kubeconfig
alias k=kubectl
source <(kubectl completion bash)
EOF

source /root/.bashrc

# 查看节点
kubectl get node

# 看容器运行时
kubectl describe node | grep Runtime

2. kube-proxy 部署

2.1 分发 kubeconfig

1
2
3


for NODE in master1 master2 master3; do
 scp /etc/kubernetes/kube-proxy.kubeconfig $NODE:/etc/kubernetes/
done

2.2 kube-proxy.service

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes
After=network.target

[Service]
ExecStart=/usr/local/bin/kube-proxy \
 --config=/etc/kubernetes/kube-proxy.yaml \
 --v=2
Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target

2.3 kube-proxy.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 0.0.0.0
clientConnection:
 acceptContentTypes: ""
 burst: 10
 contentType: application/vnd.kubernetes.protobuf
 kubeconfig: /etc/kubernetes/kube-proxy.kubeconfig
 qps: 5
clusterCIDR: 172.218.0.0/12,fc00:2222::/112
configSyncPeriod: 15m0s
conntrack:
 max: null
 maxPerCore: 32768
 min: 131072
 tcpCloseWaitTimeout: 1h0m0s
 tcpEstablishedTimeout: 24h0m0s
enableProfiling: false
healthzBindAddress: 0.0.0.0:10256
hostnameOverride: ""
iptables:
 masqueradeAll: false
 masqueradeBit: 14
 minSyncPeriod: 0s
 syncPeriod: 30s
ipvs:
 masqueradeAll: true
 minSyncPeriod: 5s
 scheduler: "rr"
 syncPeriod: 30s
kind: KubeProxyConfiguration
metricsBindAddress: 127.0.0.1:10249
mode: "ipvs"
nodePortAddresses: null
oomScoreAdj: -999
portRange: ""
udpIdleTimeout: 250ms

2.4 启动

1
2
3
4
5


for NODE in master1 master2 master3 worker1 worker2 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do
 ssh $NODE "systemctl daemon-reload"
 ssh $NODE "systemctl enable --now kube-proxy.service"
 ssh $NODE "systemctl restart kube-proxy.service"
done

2.5 验证 IPVS

1
2


ipvsadm -ln
# 预期看到 10.96.0.0/12 的 Service IP 列表

3. 节点 Ready 验证

1
2
3
4
5
6
7
8


# 等待 30 秒后
kubectl get node
# NAME STATUS ROLES AGE VERSION
# master1 Ready <none> 5m v1.28.5
# master2 Ready <none> 5m v1.28.5
# master3 Ready <none> 5m v1.28.5
# worker1 Ready <none> 3m v1.28.5
# ...

如果节点 NotReady：

1
2


kubectl describe node <node-name>
# 看 Conditions 里的 Ready 状态

常见原因：

cgroupDriver 不一致 → kubelet 起不来
CRI socket 路径错 → container-runtime-endpoint 检查
kubelet.conf 里 clusterDNS 写错 → CoreDNS IP 必须是 10.96.0.10

4. 排错速查

现象	原因	解决
`kubelet: failed to run Kubelet: validate service connection: validate CRI v1 runtime API`	cri-dockerd 没起	启动 cri-docker.service
`kubelet: cgroup driver "cgroupfs" is different from docker "systemd"`	docker cgroup driver 不一致	改 daemon.json + 重启 docker
`kubelet: node "master1" not found`	apiserver 没有这个 node 对象	`kubectl get csr` 看有没有待批准的证书
`kubelet: unauthorized`	bootstrap token 错	重新生成 bootstrap.secret.yaml
`failed to start CRI service: timeout`	cri-dockerd socket 不存在	检查 `/run/cri-dockerd.sock`
`kubelet.service: Main process exited, code=exited, status=255`	kubelet-conf.yml 写错	`kubelet --config=... --v=4` 看具体错

5. 小结

节点组件是 K8s 集群的"四肢"：

kubelet + cri-dockerd 缺一不可
cgroupDriver 必须 kubelet 与 docker 一致（都是 systemd）
IPVS 模式比 iptables 在大规模集群下性能更好
TLS Bootstrapping 用 token 代替每个 node 签证书

下一步：K8s 核心插件部署：Calico 网络 + CoreDNS + Metrics-server。

K8s 1.28 核心组件二进制部署：apiserver/scheduler/controller-manager

Mon, 15 Apr 2024 00:00:00 +0800

K8s 控制平面三大组件

K8s 控制平面（Control Plane）由 3 个核心组件组成：

kube-apiserver：所有通信的入口，REST API server
kube-scheduler：决定 Pod 调度到哪个 Node
kube-controller-manager：运行所有控制器（Node、Replication、Endpoint、ServiceAccount 等）

本文只讲这 3 个组件的部署与配置，节点组件（kubelet、kube-proxy）单独成篇。

适用版本：Kubernetes 1.28.5 / Ubuntu 22.04 部署位置：master1、master2、master3 各一份

1. 准备目录

1
2
3
4
5


# 所有 master 节点执行
mkdir -p /etc/kubernetes/manifests/ \
 /etc/systemd/system/kubelet.service.d \
 /var/lib/kubelet \
 /var/log/kubernetes

2. K8s 1.28.5 二进制分发

2.1 master1 解压

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


cd /data/softs
tar -xf kubernetes-server-linux-amd64.tar.gz \
 --strip-components=3 \
 -C /usr/local/bin \
 kubernetes/server/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}

ls /usr/local/bin
# etcd etcdctl etcdutl kube-apiserver kube-controller-manager kubectl kubelet kube-proxy kube-scheduler

kubelet --version
# Kubernetes v1.28.5

2.2 分发到其他 master

1
2
3
4
5


for NODE in master2 master3; do
 scp /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} \
 $NODE:/usr/local/bin/
 scp /usr/local/bin/etcd* $NODE:/usr/local/bin/
done

2.3 分发到 worker（只发 kubelet 和 kube-proxy）

1
2
3
4


for NODE in worker1 worker2; do
 echo $NODE
 scp /usr/local/bin/kube{let,-proxy} $NODE:/usr/local/bin/
done

3. K8s 1.28 证书签发

3.1 CA 根证书

1
2
3
4
5
6


mkdir -p /data/softs/pki && cd /data/softs/pki

# CA 根
cfssl gencert -initca ca-csr.json | cfssljson -bare /etc/kubernetes/pki/ca
ls /etc/kubernetes/pki
# ca.csr ca-key.pem ca.pem

3.2 apiserver 证书（关键）

apiserver-csr.json 里的 hosts 字段必须预留未来所有可能加入的 Node IP：

1
2
3
4
5
6
7


cfssl gencert \
 -ca=/etc/kubernetes/pki/ca.pem \
 -ca-key=/etc/kubernetes/pki/ca-key.pem \
 -config=ca-config.json \
 -hostname=10.96.0.1,<vip-internal>,127.0.0.1,kubernetes,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.default.svc.cluster.local,<master1-ip>,<master2-ip>,<master3-ip> \
 -profile=kubernetes \
 apiserver-csr.json | cfssljson -bare /etc/kubernetes/pki/apiserver

后续扩容加 IP 时，重新生成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 备份旧证书
mkdir -p ~/apiserverbak
cd /etc/kubernetes/pki
mv apiserver.csr apiserver.pem apiserver-key.pem ~/apiserverbak

# 重新签发（加新 IP）
cfssl gencert \
 -ca=/etc/kubernetes/pki/ca.pem \
 -ca-key=/etc/kubernetes/pki/ca-key.pem \
 -config=ca-config.json \
 -hostname=10.96.0.1,<vip-internal>,127.0.0.1,kubernetes,kubernetes.default,...,<新IP1>,<新IP2> \
 -profile=kubernetes \
 apiserver-csr.json | cfssljson -bare /etc/kubernetes/pki/apiserver

# 推送到其他 master
for NODE in master2 master3; do
 for FILE in apiserver.csr apiserver.pem apiserver-key.pem; do
 scp /etc/kubernetes/pki/${FILE} $NODE:/etc/kubernetes/pki/${FILE}
 done
done

# 重启
systemctl restart kube-apiserver.service

3.3 front-proxy 聚合层证书

1
2
3
4
5
6
7


cfssl gencert -initca front-proxy-ca-csr.json | cfssljson -bare /etc/kubernetes/pki/front-proxy-ca
cfssl gencert \
 -ca=/etc/kubernetes/pki/front-proxy-ca.pem \
 -ca-key=/etc/kubernetes/pki/front-proxy-ca-key.pem \
 -config=ca-config.json \
 -profile=kubernetes \
 front-proxy-client-csr.json | cfssljson -bare /etc/kubernetes/pki/front-proxy-client

3.4 controller-manager 和 scheduler 证书

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


cfssl gencert \
 -ca=/etc/kubernetes/pki/ca.pem \
 -ca-key=/etc/kubernetes/pki/ca-key.pem \
 -config=ca-config.json \
 -profile=kubernetes \
 manager-csr.json | cfssljson -bare /etc/kubernetes/pki/controller-manager

cfssl gencert \
 -ca=/etc/kubernetes/pki/ca.pem \
 -ca-key=/etc/kubernetes/pki/ca-key.pem \
 -config=ca-config.json \
 -profile=kubernetes \
 scheduler-csr.json | cfssljson -bare /etc/kubernetes/pki/scheduler

# kube-proxy 证书
cfssl gencert \
 -ca=/etc/kubernetes/pki/ca.pem \
 -ca-key=/etc/kubernetes/pki/ca-key.pem \
 -config=ca-config.json \
 -profile=kubernetes \
 kube-proxy-csr.json | cfssljson -bare /etc/kubernetes/pki/kube-proxy

# admin 证书
cfssl gencert \
 -ca=/etc/kubernetes/pki/ca.pem \
 -ca-key=/etc/kubernetes/pki/ca-key.pem \
 -config=ca-config.json \
 -profile=kubernetes \
 admin-csr.json | cfssljson -bare /etc/kubernetes/pki/admin

3.5 ServiceAccount Key（SA 签名密钥对）

1
2


openssl genrsa -out /etc/kubernetes/pki/sa.key 2048
openssl rsa -in /etc/kubernetes/pki/sa.key -pubout -out /etc/kubernetes/pki/sa.pub

3.6 推送到其他 master

1
2
3
4
5
6
7
8
9


for NODE in master2 master3; do
 ssh $NODE "mkdir -p /etc/kubernetes/pki"
 for FILE in $(ls /etc/kubernetes/pki | grep -v etcd); do
 scp /etc/kubernetes/pki/${FILE} $NODE:/etc/kubernetes/pki/${FILE}
 done
 for FILE in admin.kubeconfig controller-manager.kubeconfig scheduler.kubeconfig; do
 scp /etc/kubernetes/${FILE} $NODE:/etc/kubernetes/${FILE}
 done
done

4. kubeconfig 文件

K8s 用 kubeconfig 描述"集群 + 凭据 + 上下文"三元组。每个组件的 kubeconfig 用 kubectl config set-* 生成。

4.1 controller-manager.kubeconfig

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


kubectl config set-cluster kubernetes \
 --certificate-authority=/etc/kubernetes/pki/ca.pem \
 --embed-certs=true \
 --server=https://<vip-internal>:10443 \
 --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig

kubectl config set-credentials system:kube-controller-manager \
 --client-certificate=/etc/kubernetes/pki/controller-manager.pem \
 --client-key=/etc/kubernetes/pki/controller-manager-key.pem \
 --embed-certs=true \
 --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig

kubectl config set-context system:kube-controller-manager@kubernetes \
 --cluster=kubernetes \
 --user=system:kube-controller-manager \
 --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig

kubectl config use-context system:kube-controller-manager@kubernetes \
 --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig

4.2 scheduler.kubeconfig

同上，user 改成 system:kube-scheduler，cert 改成 scheduler.pem。

4.3 admin.kubeconfig

user 改成 kubernetes-admin，cert 改成 admin.pem：

1
2
3
4
5
6
7


kubectl config set-context kubernetes-admin@kubernetes \
 --cluster=kubernetes \
 --user=kubernetes-admin \
 --kubeconfig=/etc/kubernetes/admin.kubeconfig

kubectl config use-context kubernetes-admin@kubernetes \
 --kubeconfig=/etc/kubernetes/admin.kubeconfig

4.4 kube-proxy.kubeconfig

user kube-proxy，cert kube-proxy.pem。

5. kube-apiserver 部署

5.1 kube-apiserver.service（master1）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
After=network.target

[Service]
ExecStart=/usr/local/bin/kube-apiserver \
 --v=2 \
 --allow-privileged=true \
 --bind-address=0.0.0.0 \
 --secure-port=6443 \
 --advertise-address=<master1-ip> \
 --service-cluster-ip-range=10.96.0.0/12,fd00:1111::/112 \
 --service-node-port-range=30000-32767 \
 --etcd-servers=https://<master1-ip>:2379,https://<master2-ip>:2379,https://<master3-ip>:2379 \
 --etcd-cafile=/etc/etcd/ssl/etcd-ca.pem \
 --etcd-certfile=/etc/etcd/ssl/etcd.pem \
 --etcd-keyfile=/etc/etcd/ssl/etcd-key.pem \
 --client-ca-file=/etc/kubernetes/pki/ca.pem \
 --tls-cert-file=/etc/kubernetes/pki/apiserver.pem \
 --tls-private-key-file=/etc/kubernetes/pki/apiserver-key.pem \
 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver.pem \
 --kubelet-client-key=/etc/kubernetes/pki/apiserver-key.pem \
 --service-account-key-file=/etc/kubernetes/pki/sa.pub \
 --service-account-signing-key-file=/etc/kubernetes/pki/sa.key \
 --service-account-issuer=https://kubernetes.default.svc.cluster.local \
 --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname \
 --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota \
 --authorization-mode=Node,RBAC \
 --enable-bootstrap-token-auth=true \
 --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem \
 --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.pem \
 --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client-key.pem \
 --requestheader-allowed-names=aggregator \
 --requestheader-group-headers=X-Remote-Group \
 --requestheader-extra-headers-prefix=X-Remote-Extra- \
 --requestheader-username-headers=X-Remote-User \
 --enable-aggregator-routing=true
Restart=on-failure
RestartSec=10s
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

master2 / master3 的 unit 只需要改 --advertise-address 为各自 IP。

5.2 启动

1
2
3
4
5


systemctl daemon-reload
systemctl enable --now kube-apiserver.service
systemctl restart kube-apiserver.service
systemctl status kube-apiserver.service
journalctl -f -u kube-apiserver

6. kube-controller-manager 部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


[Service]
ExecStart=/usr/local/bin/kube-controller-manager \
 --v=2 \
 --bind-address=0.0.0.0 \
 --root-ca-file=/etc/kubernetes/pki/ca.pem \
 --cluster-signing-cert-file=/etc/kubernetes/pki/ca.pem \
 --cluster-signing-key-file=/etc/kubernetes/pki/ca-key.pem \
 --service-account-private-key-file=/etc/kubernetes/pki/sa.key \
 --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig \
 --leader-elect=true \
 --use-service-account-credentials=true \
 --node-monitor-grace-period=40s \
 --node-monitor-period=5s \
 --controllers=*,bootstrapsigner,tokencleaner \
 --allocate-node-cidrs=true \
 --service-cluster-ip-range=10.96.0.0/12,fd00:1111::/112 \
 --cluster-cidr=172.218.0.0/12,fc00:2222::/112 \
 --node-cidr-mask-size-ipv4=24 \
 --node-cidr-mask-size-ipv6=120 \
 --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem
Restart=always
RestartSec=10s

启动：

1
2
3


systemctl daemon-reload
systemctl enable --now kube-controller-manager.service
systemctl restart kube-controller-manager.service

7. kube-scheduler 部署

1
2
3
4
5
6
7
8


[Service]
ExecStart=/usr/local/bin/kube-scheduler \
 --v=2 \
 --bind-address=0.0.0.0 \
 --leader-elect=true \
 --kubeconfig=/etc/kubernetes/scheduler.kubeconfig
Restart=always
RestartSec=10s

8. TLS Bootstrapping（自动签证书给 kubelet）

传统 K8s 部署需要在每个 worker 上手动签 kubelet 证书，1.4 引入的 TLS Bootstrapping 让 worker 用一个临时 token 自动签证书。

8.1 bootstrap-kubelet.kubeconfig

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


kubectl config set-cluster kubernetes \
 --certificate-authority=/etc/kubernetes/pki/ca.pem \
 --embed-certs=true \
 --server=https://<vip-internal>:10443 \
 --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig

kubectl config set-credentials tls-bootstrap-token-user \
 --token=<BOOTSTRAP_TOKEN_ID>.<BOOTSTRAP_TOKEN_SECRET> \
 --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig

kubectl config set-context tls-bootstrap-token-user@kubernetes \
 --cluster=kubernetes \
 --user=tls-bootstrap-token-user \
 --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig

kubectl config use-context tls-bootstrap-token-user@kubernetes \
 --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig

Token 形如 c8ad9c.2e4d610cf3e7426e（前半段是 ID，后半段是 Secret），可自定义但要保证长度够。

8.2 bootstrap.secret.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


apiVersion: v1
kind: Secret
metadata:
 name: bootstrap-token-<BOOTSTRAP_TOKEN_ID>
 namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
 description: "The default bootstrap token generated by 'kubelet'."
 token-id: <BOOTSTRAP_TOKEN_ID>
 token-secret: <BOOTSTRAP_TOKEN_SECRET>
 usage-bootstrap-authentication: "true"
 usage-bootstrap-signing: "true"
 auth-extra-groups: system:bootstrappers:default-node-token,system:bootstrappers:worker,system:bootstrappers:ingress
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: kubelet-bootstrap
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:bootstrappers:default-node-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: node-autoapprove-bootstrap
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:bootstrappers:default-node-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: node-autoapprove-certificate-rotation
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:nodes

执行：

1
2
3
4
5
6
7
8
9


kubectl create -f bootstrap.secret.yaml

# 验证
kubectl get cs
# Warning: v1 ComponentStatus is deprecated in v1.19+
# NAME STATUS MESSAGE ERROR
# scheduler Healthy ok
# controller-manager Healthy ok
# etcd-0 Healthy ok

8.3 admin 客户端

1
2
3
4


mkdir -p /root/.kube
cp /etc/kubernetes/admin.kubeconfig /root/.kube/config
echo "export KUBECONFIG=/etc/kubernetes/admin.kubeconfig" >> /etc/profile
source /etc/profile

9. 验证

1
2
3


# 所有 master 上
systemctl status kube-apiserver kube-controller-manager kube-scheduler
journalctl -u kube-apiserver --since "5 minutes ago"

3 个 master 都需要启动正常。kubectl get cs 三个组件都应显示 Healthy。

10. 排错

现象	原因	解决
`apiserver: x509: certificate signed by unknown authority`	CA 不一致	同步 `/etc/kubernetes/pki/ca.pem` 到所有 master
`etcd cluster is unavailable`	apiserver 找不到 etcd	检查 `--etcd-servers` + etcd 证书路径
`the server has invalid kubeconfig`	kubeconfig 写错	重新生成
`kubelet TLS bootstrap failed`	token 错或 RBAC 没建	检查 token + `kubectl get clusterrolebinding \| grep bootstrap`
`failed to create listener: address already in use`	6443 端口占用	`ss -tlnp \| grep 6443`

11. 小结

控制平面三大组件是 K8s 的"大脑"。几个关键点：

apiserver 证书必须预留未来 Node IP（避免后续扩容重签）
TLS Bootstrapping 用临时 token省去每个 worker 签证书
3 master 配置必须一致（除了 advertise-address）
kubeconfig 一定要 embed-certs=true避免每次 kubectl 都要指定 CA

下一步：K8s 节点组件部署：kubelet + kube-proxy + IPVS。

etcd 3.5 集群二进制部署与 TLS 证书签发

Fri, 15 Mar 2024 00:00:00 +0800

为什么 etcd 必须独立部署

etcd 是 K8s 唯一的状态存储后端，所有 Pod/Service/ConfigMap 状态都写在 etcd 里。生产环境对 etcd 的要求：

3 节点或 5 节点集群（raft 多数派容错）
所有通信必须 TLS（peer + client）
必须与 kube-apiserver 分开部署（不要复用 master 节点或用容器化 etcd）

本文用 cfssl 工具签发全套证书，部署 3 节点 etcd 集群。

适用版本：etcd v3.5.11 / cfssl 1.6.4 / Ubuntu 22.04 部署位置：master1、master2、master3 各一份

1. 安装 cfssl 工具

1
2
3
4
5
6
7
8


cd /data/softs
cp cfssl_1.6.4_linux_amd64 /usr/local/bin/cfssl
cp cfssljson_1.6.4_linux_amd64 /usr/local/bin/cfssljson
cp cfssl-certinfo_1.6.4_linux_amd64 /usr/local/bin/cfssl-certinfo
chmod +x /usr/local/bin/cfssl /usr/local/bin/cfssljson /usr/local/bin/cfssl-certinfo

ls /usr/local/bin
# cfssl cfssl-certinfo cfssljson containerd ...

2. etcd 证书生成

所有证书的生成操作只在 master1 上做，然后 scp 到其他 master。

2.1 创建证书目录

1
2


mkdir -p /etc/etcd/ssl
mkdir -p /data/softs/pki && cd /data/softs/pki

需要的 11 个 JSON 配置文件（生产里通常从运维仓库分发）：

1
2
3
4


admin-csr.json apiserver-csr.json ca-config.json
ca-csr.json etcd-ca-csr.json etcd-csr.json
front-proxy-ca-csr.json front-proxy-client-csr.json
kube-proxy-csr.json manager-csr.json scheduler-csr.json

2.2 生成 etcd CA 与证书

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 生成 CA 根证书
cfssl gencert -initca etcd-ca-csr.json | cfssljson -bare /etc/etcd/ssl/etcd-ca

# 生成 etcd server 证书（hostname 和 IP 必须包含所有 3 个节点）
cfssl gencert \
 -ca=/etc/etcd/ssl/etcd-ca.pem \
 -ca-key=/etc/etcd/ssl/etcd-ca-key.pem \
 -config=ca-config.json \
 -hostname=127.0.0.1,master1,master2,master3,<master1-ip>,<master2-ip>,<master3-ip> \
 -profile=kubernetes \
 etcd-csr.json | cfssljson -bare /etc/etcd/ssl/etcd

生成结果：

1
2
3


ls /etc/etcd/ssl/
# etcd-ca.csr etcd-ca-key.pem etcd-ca.pem
# etcd.csr etcd-key.pem etcd.pem

2.3 把证书复制到其他 master

1
2
3
4
5
6


for NODE in master2 master3; do
 ssh $NODE "mkdir -p /etc/etcd/ssl"
 for FILE in etcd-ca-key.pem etcd-ca.pem etcd-key.pem etcd.pem; do
 scp /etc/etcd/ssl/${FILE} $NODE:/etc/etcd/ssl/${FILE}
 done
done

内网 IP 用占位符 <master1-ip> 等替代；实际操作换成真实 IP。

3. etcd 二进制安装

1
2
3
4
5
6
7
8
9


cd /data/softs
tar -xf etcd-v3.5.11-linux-amd64.tar.gz
mv etcd-v3.5.11-linux-amd64/etcd /usr/local/bin/
mv etcd-v3.5.11-linux-amd64/etcdctl /usr/local/bin/
mv etcd-v3.5.11-linux-amd64/etcdutl /usr/local/bin/

etcdctl version
# etcdctl version: 3.5.11
# API version: 3.5

推送到 master2 / master3：

1
2
3


for NODE in master2 master3; do
 scp /usr/local/bin/etcd* $NODE:/usr/local/bin/
done

4. etcd 配置文件

4.1 etcd.config.yml（master1 示例）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


name: 'master1'
data-dir: /var/lib/etcd
wal-dir: /var/lib/etcd/wal
snapshot-count: 5000
heartbeat-interval: 100
election-timeout: 1000
quota-backend-bytes: 0
listen-peer-urls: 'https://<master1-ip>:2380'
listen-client-urls: 'https://<master1-ip>:2379,http://127.0.0.1:2379'
max-snapshots: 3
max-wals: 5
initial-advertise-peer-urls: 'https://<master1-ip>:2380'
advertise-client-urls: 'https://<master1-ip>:2379'
initial-cluster: 'master1=https://<master1-ip>:2380,master2=https://<master2-ip>:2380,master3=https://<master3-ip>:2380'
initial-cluster-token: 'etcd-k8s-cluster'
initial-cluster-state: 'new'
strict-reconfig-check: false
enable-v2: true
enable-pprof: true
client-transport-security:
 cert-file: '/etc/etcd/ssl/etcd.pem'
 key-file: '/etc/etcd/ssl/etcd-key.pem'
 client-cert-auth: true
 trusted-ca-file: '/etc/etcd/ssl/etcd-ca.pem'
 auto-tls: true
peer-transport-security:
 cert-file: '/etc/etcd/ssl/etcd.pem'
 key-file: '/etc/etcd/ssl/etcd-key.pem'
 peer-client-cert-auth: true
 trusted-ca-file: '/etc/etcd/ssl/etcd-ca.pem'
 auto-tls: true

master2 / master3 的配置只需要改 name 字段、listen-peer-urls 里的 IP。

4.2 etcd.service 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


[Unit]
Description=Etcd Service
Documentation=https://coreos.com/etcd/docs/latest/
After=network.target

[Service]
Type=notify
ExecStart=/usr/local/bin/etcd --config-file=/etc/etcd/etcd.config.yml
Restart=on-failure
RestartSec=10
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
Alias=etcd3.service

5. 启动与验证

5.1 启动

1
2
3


systemctl daemon-reload
systemctl enable --now etcd.service
systemctl status etcd.service

5.2 验证集群状态

1
2
3
4
5
6
7


export ETCDCTL_API=3

etcdctl --endpoints="<master1-ip>:2379,<master2-ip>:2379,<master3-ip>:2379" \
 --cacert=/etc/etcd/ssl/etcd-ca.pem \
 --cert=/etc/etcd/ssl/etcd.pem \
 --key=/etc/etcd/ssl/etcd-key.pem \
 endpoint status --write-out=table

预期输出：

1
2
3
4
5
6
7


+------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| <master1-ip>:2379 | b55511e3290daa2b | 3.5.11 | 20 kB | true | false | 2 | 8 | 8 | |
| <master2-ip>:2379 | 64aba84b878707bb | 3.5.11 | 20 kB | false | false | 2 | 8 | 8 | |
| <master3-ip>:2379 | 3eafefedb1462a99 | 3.5.11 | 20 kB | false | false | 2 | 8 | 8 | |
+------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

只要 IS LEADER 有一个 true，RAFT TERM 都一致，ERRORS 都为空，集群就是健康的。

5.3 etcd 性能压测

1

etcdctl check perf

5.4 备份与恢复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 备份
etcdctl snapshot save /tmp/etcd-snapshot.db
etcdctl snapshot status /tmp/etcd-snapshot.db --write-out=table

# 恢复（停 etcd 后）
etcdctl snapshot restore /tmp/etcd-snapshot.db \
 --name master1 \
 --initial-cluster master1=https://...,master2=...,master3=... \
 --initial-advertise-peer-urls https://<master1-ip>:2380 \
 --data-dir /var/lib/etcd-restore

6. 排错速查

现象	原因	解决
`etcdctl: command not found`	旧版本客户端	`export ETCDCTL_API=3`
`certificate verify failed`	CA 不匹配	检查 `trusted-ca-file`
raft term 不增长	集群未选主	检查 `initial-cluster` 是否 3 节点都在
`db size exceeds quota`	默认 2GB	调大 `quota-backend-bytes`
peer URL 改后无法加入	老的 peer 还在	删 data-dir 重启

7. 小结

etcd 集群是 K8s 状态的"心脏"：

必须 3 节点或 5 节点（raft 多数派）
所有通信必须 TLS（peer + client 都要）
证书 hostname 列表必须包含所有 3 节点
定期备份（etcdctl snapshot save）

下一步：K8s 1.28 核心组件二进制部署：apiserver/scheduler/controller-manager。

高可用负载均衡：Nginx + Keepalived 编译与 VIP 漂移

Thu, 15 Feb 2024 00:00:00 +0800

为什么需要 Nginx + Keepalived

K8s 1.28 集群 3 个 master 上的 kube-apiserver 监听 6443 端口，但是：

worker 节点上的 kubelet 不会写死某个 master IP——它们需要一个虚拟入口
kubectl 客户端也希望只配置一个 server 地址
多个 master 之间的负载需要均衡

业界主流方案是 Nginx 4 层 stream 反代 + Keepalived VIP 漂移：

Nginx 用 stream 块做 TCP 4 层反代（不是 7 层 HTTP），把 10443 端口收到的请求分发到 3 个 master 的 6443
Keepalived 用 VRRP 协议做 VIP 漂移（抢占模式必须 nopreempt），3 个 master 只有一个是 MASTER，2 个 BACKUP

适用版本：nginx 1.24.0 / keepalived 2.2.8 / Ubuntu 22.04 部署位置：master1、master2（只在 2 台上部署，master3 上可装可不装，但 stream 配置要一样）

1. 编译安装 Nginx

1.1 编译依赖

1

apt install -y make g++ openssl libssl-dev libpcre3 libpcre3-dev zlib1g-dev libgd-dev

1.2 编译配置

关键参数：--with-stream（4 层反代）、--with-stream_ssl_module（TLS 透传）、--with-http_ssl_module（7 层 HTTPS）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


cd /data/softs
tar xf nginx-1.24.0.tar.gz && cd nginx-1.24.0

./configure \
 --prefix=/usr/local/nginx \
 --with-http_ssl_module \
 --with-http_stub_status_module \
 --with-pcre \
 --with-http_gzip_static_module \
 --with-stream \
 --with-stream_ssl_module

make && make install

如果还要支持 --with-stream_ssl_preread_module（按 SNI 分流），需要二次编译：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


./configure \
 --prefix=/usr/local/nginx \
 --with-http_ssl_module \
 --with-http_stub_status_module \
 --with-pcre \
 --with-http_gzip_static_module \
 --with-stream \
 --with-stream_ssl_module \
 --with-stream_ssl_preread_module

make
# 备份旧的
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx_bak
# 替换
cp objs/nginx /usr/local/nginx/sbin/

1.3 解决 libpcre.so.1 not found

1
2
3
4


# 查依赖
ldd $(which /usr/local/nginx/sbin/nginx)
# libpcre.so.1 => not found
# 解决：编译时加 --with-pcre=../pcre-xxx 源码路径，或安装 libpcre3-dev

2. Nginx 配置

2.1 主配置 nginx.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


worker_processes 1;
events {
 worker_connections 1024;
}
http {
 include mime.types;
 default_type application/octet-stream;
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';

 sendfile on;
 keepalive_timeout 65;
 autoindex on;
 gzip on;
 gzip_buffers 32 4K;
 gzip_comp_level 6;
 gzip_min_length 1k;
 gzip_types application/javascript text/css text/xml;
 gzip_disable "MSIE [1-6]\.";
 gzip_http_version 1.1;
 gzip_vary on;

 client_body_buffer_size 1024k;
 client_max_body_size 2048m;
 client_header_buffer_size 128k;
 large_client_header_buffers 4 128k;

 proxy_buffer_size 256k;
 proxy_buffering on;
 proxy_buffers 64 128k;
 proxy_busy_buffers_size 512k;

 fastcgi_buffers 6 512k;
 fastcgi_buffer_size 512k;
 fastcgi_busy_buffers_size 512k;
 fastcgi_temp_file_write_size 512k;
 fastcgi_intercept_errors on;

 include conf.d/*.conf;
}
stream {
 log_format proxy '[$time_local] $protocol status:$status, bytes client:$bytes_sent/$bytes_received $session_time, '
 'client: $remote_addr, upstream:"$upstream_addr", '
 'bytes upstream:$upstream_bytes_sent $upstream_bytes_received $upstream_connect_time';
 include stream/*.conf;
}

2.2 stream 反代 kube-apiserver

stream/stream.conf：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


upstream k8sapiserver {
 hash $remote_addr consistent;
 server <master1-ip>:6443 max_fails=3 fail_timeout=30s;
 server <master2-ip>:6443 max_fails=3 fail_timeout=30s;
 server <master3-ip>:6443 max_fails=3 fail_timeout=30s;
}
server {
 error_log logs/10443_error.log;
 access_log logs/10443_access.log proxy;
 listen 10443;
 proxy_connect_timeout 1s;
 proxy_pass k8sapiserver;
}

2.3 测试页 conf.d/default.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


server {
 listen 10088;
 server_name localhost;
 error_log logs/10088_error.log;
 access_log logs/10088_access.log;

 location / {
 root html;
 index index.html index.htm;
 }
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root html;
 }
}

2.4 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


[Unit]
Description=kube-apiserver nginx proxy
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStartPre=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx
ExecReload=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -p /usr/local/nginx -s reload
PrivateTmp=true
Restart=always
RestartSec=5
StartLimitInterval=0
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

启动：

1
2
3
4
5
6
7
8
9


systemctl daemon-reload
systemctl enable --now nginx.service
systemctl status nginx.service
journalctl -f -u nginx.service

# 验证（区分两台机器的页面）
sed -i "s#Welcome to nginx#Welcome to nginx master1#g" /usr/local/nginx/html/index.html
curl <master1-ip>:10088
curl <master2-ip>:10088

3. Keepalived 编译与配置

3.1 编译安装

1
2
3
4
5
6
7
8


cd /data/softs
tar xf keepalived-2.2.8.tar.gz && cd keepalived-2.2.8

./configure --prefix=/usr/local/keepalived
make && make install
cd .. && rm -rf keepalived-2.2.8

mkdir -p /usr/local/keepalived/conf

3.2 健康检查脚本

check_nginx.sh：每 2 秒检查一次 nginx，挂了先重启；重启失败就让 keepalived 主动降权让 VIP 漂走。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


cat << "EOF" > /usr/local/keepalived/conf/check_nginx.sh
#!/bin/bash
url="http://127.0.0.1:10088"
code=`curl -s -o /dev/null -w %{http_code} $url`
if [ $code -ne 200 ]; then
 /usr/bin/systemctl start nginx
 sleep 2
 code=`curl -s -o /dev/null -w %{http_code} $url`
 if [ $code -ne 200 ]; then
 /usr/bin/systemctl stop keepalived
 fi
fi
EOF

chmod +x /usr/local/keepalived/conf/check_nginx.sh

必须：脚本用 HTTP 200 判断，不能用 ps -C nginx——多 worker 进程下 ps 不可靠。

3.3 keepalived.conf（master1）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


global_defs {
 router_id LVS_DEVEL
 vrrp_skip_check_adv_addr
 vrrp_garp_interval 0
 vrrp_gna_interval 0
}
vrrp_script check_nginx {
 script "/usr/local/keepalived/conf/check_nginx.sh"
 interval 2
 weight -2
}
vrrp_instance VI_1 {
 state MASTER
 interface eno1 # 网卡名按机器实际改
 mcast_src_ip <master1-ip>
 virtual_router_id 51
 priority 100
 advert_int 2
 nopreempt # **关键**：不抢占，主恢复后 VIP 不会自动抢回
 authentication {
 auth_type PASS
 auth_pass K8SHA_KA_AUTH
 }
 virtual_ipaddress {
 <vip-internal>
 <vip-public>
 }
 track_script {
 check_nginx
 }
}

3.4 keepalived.conf（master2）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


global_defs { router_id LVS_DEVEL ... }
vrrp_script check_nginx { script ".../check_nginx.sh"; interval 2; weight -2; }
vrrp_instance VI_1 {
 state BACKUP # BACKUP 角色
 interface eno1
 mcast_src_ip <master2-ip>
 virtual_router_id 51 # 必须和 master1 一致
 priority 80 # 比 MASTER 低
 advert_int 2
 nopreempt
 authentication { auth_type PASS; auth_pass K8SHA_KA_AUTH; }
 virtual_ipaddress { <vip-internal> <vip-public> }
 track_script { check_nginx; }
}

3.5 keepalived.conf（master3，可选）

1
2
3
4


state BACKUP
priority 60
virtual_router_id 51
... (其余同 master2)

3.6 systemd 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


[Unit]
Description=VRRP High Availability Monitor
After=network-online.target syslog.target
Wants=network-online.target
Documentation=https://keepalived.org/manpage.html

[Service]
Type=forking
KillMode=process
ExecStart=/usr/local/keepalived/sbin/keepalived -D -f /usr/local/keepalived/conf/keepalived.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

启动：

1
2
3
4
5


systemctl daemon-reload
systemctl enable --now keepalived
systemctl restart keepalived
systemctl status keepalived
journalctl -f -u keepalived

打包已安装的 keepalived 用于其他节点：

1
2
3


cd /usr/local
tar -zcvf keepalived.tar.gz keepalived
scp keepalived.tar.gz master2:/usr/local/

4. 跨机房 VIP（Unicast 模式）

如果两个机房之间是 L3 路由（不是同 L2），VRRP 多播会被丢，需要切到单播模式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


vrrp_instance VI_1 {
 state MASTER
 interface eno1
 virtual_router_id 51
 priority 100
 advert_int 1
 unicast_src_ip <this-node-ip>
 unicast_peer {
 <peer-node-ip> # 另一机房的对端 IP
 }
 authentication { auth_type PASS; auth_pass 1111; }
 virtual_ipaddress { <vip-cross-dc> }
}

unicast_src_ip + unicast_peer 显式指定对端，绕过 VRRP 多播。

5. 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 验证 VIP
curl <vip-internal>:10088

# 停 master1 模拟故障
ssh master1 "systemctl stop keepalived"
# VIP 应该在 1-3 秒内漂到 master2

# 启动 master1 keepalived
ssh master1 "systemctl start keepalived"
# 因为 nopreempt，VIP 不会回到 master1，仍在 master2 上

6. 常见问题

6.1 ping 不通 VIP

ARP 缓存未刷新。在 client 上：

1
2


# 清理 ARP 缓存
arp -n | awk '/^[1-9]/{print "arp -d " $1}' | sh

或等 30 秒（ARP 默认老化时间）。

6.2 不同网段 ping 不通

防火墙或路由限制。检查 iptables -L -n 与 ip route。

6.3 VIP 漂移后不能自动启动

健康检查脚本没成功。先手动跑：

1

bash /usr/local/keepalived/conf/check_nginx.sh

6.4 master3 也想加 VIP 漂移

把 master3 也装 nginx + keepalived，配置 state BACKUP + priority 60 即可。

7. 小结

Nginx stream 4 层 + Keepalived VIP 是 K8s 1.20+ 时代最稳的 apiserver HA 方案。几个关键点：

nginx 必须 --with-stream 编译
keepalived 必须 nopreempt（否则主备反复切换时丢包）
健康检查用 HTTP 200 不用 ps
跨机房用 unicast_src_ip + unicast_peer 替代多播

下一步：etcd 3.5 集群二进制部署与 TLS 证书签发。

容器运行时：Docker + cri-dockerd 二进制部署实战

Mon, 15 Jan 2024 00:00:00 +0800

为什么需要 cri-dockerd

Kubernetes 1.24（2022-05）正式移除了内置的 dockershim，也就是说 1.24+ 集群如果还想用 Docker 作为容器运行时，必须额外装 cri-dockerd 这个适配器——它把 K8s 的 CRI（Container Runtime Interface）请求转译成 Docker API。

适用版本：Kubernetes 1.28.5 / Docker 24.0.7 / cri-dockerd 0.3.9 / Ubuntu 22.04 部署位置：所有 master 和 worker 节点

1. Docker 离线安装

1.1 下载包

1
2
3
4
5


# 官方下载页
https://download.docker.com/linux/static/stable/x86_64/

# 具体版本
https://download.docker.com/linux/static/stable/x86_64/docker-24.0.7.tgz

1.2 解压到所有节点

1
2
3
4
5
6
7
8


cd /data/softs
tar xf docker-*.tgz

# 文件夹里包含以下二进制
ls docker
# containerd containerd-shim-runc-v2 ctr docker dockerd docker-init docker-proxy runc

cp docker/* /usr/local/bin/

1.3 containerd 单元文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


cat << "EOF" > /etc/systemd/system/containerd.service
[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/containerd
Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=1048576
TasksMax=infinity
OOMScoreAdjust=-999

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now containerd.service
systemctl status containerd.service

1.4 docker.service 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


cat << "EOF" > /etc/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.service

[Service]
Type=notify
ExecStart=/usr/local/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always
StartLimitBurst=3
StartLimitInterval=60s
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
Delegate=yes
KillMode=process
OOMScoreAdjust=-500

[Install]
WantedBy=multi-user.target
EOF

1.5 docker.socket 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


cat << "EOF" > /etc/systemd/system/docker.socket
[Unit]
Description=Docker Socket for the API

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target
EOF

1.6 daemon.json 配置

镜像加速、容器日志轮转、systemd cgroup driver：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


mkdir -p /etc/docker

cat << "EOF" > /etc/docker/daemon.json
{
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": { "max-size": "50m", "max-file": "1" },
 "registry-mirrors": [
 "https://<your-mirror>.mirror.aliyuncs.com",
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://docker.nju.edu.cn",
 "https://docker.mirrors.sjtug.sjtu.edu.cn",
 "https://dockerproxy.com"
 ],
 "insecure-registries": ["<private-registry>:13001"]
}
EOF

关键点：exec-opts 必须用 native.cgroupdriver=systemd，否则 kubelet 与 docker 的 cgroup driver 不一致会导致节点 NotReady。

1.7 启动 Docker

1
2
3
4
5


groupadd docker
systemctl daemon-reload
systemctl enable --now docker.socket
systemctl enable --now docker.service
docker info

2. cri-dockerd 部署

2.1 下载与安装

1

https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.9/cri-dockerd-0.3.9.amd64.tgz

1
2
3


cd /data/softs
tar xf cri-dockerd-*.amd64.tgz
cp cri-dockerd/cri-dockerd /usr/local/bin/

2.2 cri-docker.service 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


cat << "EOF" > /etc/systemd/system/cri-docker.service
[Unit]
Description=CRI Interface for Docker Application Container Engine
Documentation=https://docs.mirantis.com
After=network-online.target firewalld.service docker.service
Wants=network-online.target
Requires=cri-docker.socket

[Service]
Type=notify
ExecStart=/usr/local/bin/cri-dockerd --network-plugin=cni --pod-infra-container-image=<private-registry>:13001/base/google_containers/pause:3.9
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always
StartLimitBurst=3
StartLimitInterval=60s
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
Delegate=yes
KillMode=process

[Install]
WantedBy=multi-user.target
EOF

2.3 cri-docker.socket 单元

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


cat << "EOF" > /etc/systemd/system/cri-docker.socket
[Unit]
Description=CRI Docker Socket for the API
PartOf=cri-docker.service

[Socket]
ListenStream=%t/cri-dockerd.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target
EOF

2.4 启动 cri-dockerd

1
2
3
4
5


systemctl daemon-reload
systemctl enable --now cri-docker.socket
systemctl enable --now cri-docker.service
systemctl restart cri-docker.service
systemctl status cri-docker.service

2.5 验证

1
2


systemctl status containerd.service docker.socket docker.service cri-docker.socket cri-docker.service
journalctl -f -u containerd.service

3. 常见问题

3.1 `containerd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT`

容器运行时配置损坏：

1
2
3
4
5
6
7
8


rm -rf /var/lib/containerd
systemctl restart containerd

rm -rf /var/run/docker.sock
systemctl restart docker.socket

rm -rf /run/cri-dockerd.sock
systemctl restart cri-docker.socket

3.2 节点 NotReady 且 `RuntimeReady=False`

kubelet 报 validate CRI v1 runtime API 失败。原因是 cri-dockerd 启动顺序问题，在 systemd 中加 After= 依赖。

3.3 cgroup driver 不一致

1
2
3
4
5
6


docker info | grep cgroup
# Cgroup Driver: systemd

# kubelet 也要 systemd
cat /etc/kubernetes/kubelet-conf.yml | grep cgroupDriver
# cgroupDriver: systemd

4. 小结

容器运行时是 K8s 集群所有组件的"地基"——etcd、apiserver、kubelet 都要通过 CRI socket 与运行时通信。最容易踩的坑：

cri-dockerd 没装或 pause:3.9 镜像拉不到
cgroup driver 不一致
systemd-resolved 占用 53 端口（前置篇已关，但加新节点时容易忘）

下一步：高可用负载均衡：Nginx + Keepalived 编译与 VIP 漂移。

K8s 生产二进制集群前置：节点规划与 Linux 系统调优

Fri, 15 Dec 2023 00:00:00 +0800

写在前面

在 Kubernetes 1.6（2017 年）之前，社区主流的"高可用生产集群"基本是 3 master + N worker 手工二进制部署路线——比起 kubeadmin/kubeadm，手工二进制能完全掌控每个组件的 flag、证书路径和 systemd 单元，是国内大厂 2018-2022 年生产环境的标配方案。

本文是整个 K8s 二进制部署系列的前置篇，只讲集群起步：网络规划、服务器角色划分、Ubuntu 22.04 系统基础优化、IPVS/iptables 内核参数准备。不涉及任何 K8s 组件安装。

适用版本：Kubernetes 1.28.5 / etcd 3.5.11 / Ubuntu 22.04 server 集群规模：3 master（etcd + controlplane + nginx/keepalived）+ 10 worker

1. 集群网络与节点规划

1.1 角色划分

角色	数量	部署组件
master	3	etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、nginx、keepalived
worker	N	kubelet、kube-proxy、容器运行时
VIP	2	一个内网用，一个公网用，keepalived 漂移

1.2 IP 与 VIP 段（示例拓扑）

网段	用途	说明
`<node-network>`	节点操作系统网段	物理网络，所有节点 IP 都在此
`10.96.0.0/12`	Service 网段	kube-apiserver 默认 `--service-cluster-ip-range`
`10.96.0.10`	CoreDNS Service IP	kube-dns 固定 IP
`172.218.0.0/12`	Pod 网络	kube-controller-manager 的 `--cluster-cidr`
`<vip-internal>`	内网 VIP	漂移在 master1 / master2
`<vip-public>`	公网映射 VIP	漂移在 master1 / master2

Service 段、Pod 段在生产中可以按需调整，前提是所有节点路由可达。

1.3 NodePort 端口范围

K8s 默认 Service NodePort 范围是 30000-32767，如果需要在前面用 Nginx 4 层反代 NodePort，必须在 kube-apiserver 启动参数里显式声明：

1

--service-node-port-range=30000-32767

修改 /etc/systemd/system/kube-apiserver.service 后：

1
2


systemctl daemon-reload
systemctl restart kube-apiserver.service

1.4 主机名与 hosts

1
2
3
4


# 三个 master 设置 hostname
hostnamectl set-hostname master1 # 内网示例：<node-ip> 节点
hostnamectl set-hostname master2
hostnamectl set-hostname master3

所有节点配置 /etc/hosts（内网 IP 替换为实际值）：

1
2
3
4
5
6
7


cat << "EOF" >> /etc/hosts
<node-ip> master1
<node-ip> master2
<node-ip> master3
<node-ip> worker1
<node-ip> worker2
EOF

注意：内网 IP 已用占位符 <node-ip> 替代；实际操作时换成你集群的真实 IP。

2. 安装文件清单

在 master1 上准备好所有需要分发的二进制包（典型命名）：

文件	用途
`docker-24.0.7.tgz`	Docker 静态二进制包
`cri-dockerd-0.3.9.amd64.tgz`	cri-dockerd（K8s 1.24+ 不再内置 dockershim）
`nginx-1.24.0.tar.gz`	nginx 源码（编译 `--with-stream`）
`keepalived-2.2.8.tar.gz`	keepalived 源码
`etcd-v3.5.11-linux-amd64.tar.gz`	etcd 二进制
`kubernetes-server-linux-amd64.tar.gz`	K8s 1.28.5 服务端二进制
`cfssl_1.6.4_linux_amd64`	证书签发工具
`cfssljson_1.6.4_linux_amd64`	证书 JSON 化工具
`cfssl-certinfo_1.6.4_linux_amd64`	证书查看工具
`helm-v3.13.3-linux-amd64.tar.gz`	Helm 包管理
`coredns-1.29.0.tgz`	CoreDNS chart（DNS 插件）

3. 目录约定

每台机器统一下列目录结构，方便后面所有组件统一路径：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# 系统服务目录
mkdir -p /etc/systemd/system

# 二进制目录
mkdir -p /usr/local/bin

# 所有节点安装包路径
mkdir -p /data/softs

# 所有节点 k8s 配置目录
mkdir -p /data/k8scnf

# 所有节点的 k8s 证书目录
mkdir -p /etc/kubernetes/pki

# 所有节点 k8s 运行目录
mkdir -p /etc/kubernetes/manifests/
mkdir -p /etc/systemd/system/kubelet.service.d
mkdir -p /var/lib/kubelet
mkdir -p /var/log/kubernetes

# 所有节点 docker 配置目录
mkdir -p /etc/docker

# 所有 master etcd 证书目录
mkdir -p /etc/etcd/ssl

# master1, master2 的 nginx 目录
mkdir -p /usr/local/nginx/conf/{conf.d,stream}
mkdir -p /usr/local/keepalived/conf

4. 节点免密登录（master1 推送前置）

master1 上一键推送 SSH 公钥到其他节点（密码用占位符）：

1
2
3
4
5
6


apt install -y sshpass
ssh-keygen -f /root/.ssh/id_rsa -P ''

for HOST in master2 master3 worker1 worker2 worker3 worker4 worker5 worker6 worker7 worker8 worker9; do \
 sshpass -p "{{SSH_PASSWORD}}" ssh-copy-id -o StrictHostKeyChecking=no $HOST; \
done

非 22 端口的节点：

1

ssh-copy-id -i ~/.ssh/id_rsa.pub "-p 10022 user@server"

文件批量推送到其他 master：

1

for HOST in master2 master3; do scp -r /data/softs $HOST:/data; done

5. Ubuntu 22.04 源切换

为了避免 apt install 卡顿，所有节点切到清华源（或其他国内源）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mv /etc/apt/sources.list /etc/apt/sources.listbak

cat > /etc/apt/sources.list << "EOF"
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ jammy-security main restricted universe multiverse
EOF

apt update

6. 系统基础优化

6.1 禁用 swap

K8s 1.20+ 仍要求关闭 swap（kubelet 默认 failSwapOn: true）：

1
2
3
4


free -m
swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab
cat /etc/fstab

6.2 关闭防火墙

1
2
3


sudo systemctl stop ufw
sudo systemctl disable ufw
systemctl status ufw # 状态应为 inactive (dead)

6.3 关闭 systemd-resolved（关键）

Ubuntu 22.04 默认的 systemd-resolved 占用 53 端口，导致 CoreDNS 装不上：

1
2
3
4
5


sudo apt install -y unbound
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm -rf /etc/resolv.conf
sudo touch /etc/resolv.conf

6.4 时间同步

1
2
3
4
5
6
7
8
9


timedatectl status # System clock synchronized 必须是 yes
timedatectl set-timezone Asia/Shanghai
apt install -y ntpdate
ntpdate time1.aliyun.com

# 定时同步
crontab -e
*/5 * * * * ntpdate time1.aliyun.com
crontab -l

常见报错：Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend 解决：用 lsof /var/lib/dpkg/lock-frontend 查到占用 PID 后 kill -9 杀掉。

6.5 ulimit 与文件描述符

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


ulimit -SHn 65535

cat >> /etc/security/limits.conf << "EOF"
* soft nofile 655360
* hard nofile 131072
* soft nproc 655350
* hard nproc 655350
* soft memlock unlimited
* hard memlock unlimited
EOF

6.6 内核升级

K8s 1.28 要求内核 ≥ 4.18，Ubuntu 22.04 默认 5.15 满足，无需额外升级。

1
2


uname -r
# 5.15.0-91-generic 满足

7. IPVS 与内核网络参数

K8s kube-proxy 的 IPVS 模式比 iptables 模式在大规模集群下性能更好：

7.1 安装 IPVS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apt install -y ipvsadm ipset sysstat conntrack

cat >> /etc/modules-load.d/ipvs.conf << "EOF"
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack
ip_tables
ip_set
xt_set
ipt_set
ipt_rpfilter
ipt_REJECT
ipip
EOF

systemctl restart systemd-modules-load.service
lsmod | grep -e ip_vs -e nf_conntrack

7.2 sysctl 优化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


cat << "EOF" > /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
fs.may_detach_mounts = 1
vm.overcommit_memory = 1
vm.panic_on_oom = 0
fs.inotify.max_user_watches = 89100
fs.file-max = 52706963
fs.nr_open = 52706963
net.netfilter.nf_conntrack_max = 2310720

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_orphans = 327680
net.ipv4.tcp_orphan_retries = 3
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.ip_conntrack_max = 65536
net.ipv4.tcp_timestamps = 0
net.core.somaxconn = 16384
EOF

sysctl --system

8. 排错速查

现象	原因	解决
`apt` 卡 `dpkg lock-frontend`	后台 unattended-upgrade 占用	`lsof /var/lib/dpkg/lock-frontend` → `kill -9 PID`
CoreDNS Pod 一直 `CrashLoopBackOff`	systemd-resolved 占用 53	关闭 systemd-resolved，见 6.3
kubelet 启动失败 `failSwapOn`	swap 未关	`swapoff -a` + `/etc/fstab` 注释
NodePort 配 80 端口启动失败	不在 30000-32767 范围	kube-apiserver 加 `--service-node-port-range`
节点 `NotReady`	路由转发未开	`net.ipv4.ip_forward = 1`

9. 小结

集群前置看似都是"复制粘贴"的体力活，但每一步都是后面所有组件能起来的前提。最容易踩的坑是：

systemd-resolved 没关 → CoreDNS 起不来
swap 没禁 → kubelet 直接 failSwapOn 拒绝启动
防火墙没关 → 跨节点 Service 不通
时间不同步 → 证书签名失败、etcd 集群脑裂

下一步：容器运行时：Docker + cri-dockerd 二进制部署实战。

前置知识 / 下一步

前置：了解 Linux 基础（systemd、apt、sysctl）
本篇：所有 master/worker 节点一致的系统基线
下一步：在所有节点上部署容器运行时（Docker 24 + cri-dockerd）

Portainer 容器可视化管理：单 Docker 与集群一站搞定

Wed, 15 Mar 2023 00:00:00 +0800

命令行的 docker ps、docker logs 用得再熟，新人 onboard 时一句"这容器跑哪了"还是能把人问住。Portainer 就是一个"看得见的 Docker 管理面板"——容器、镜像、网络、存储卷、用户、权限，一站式在 Web 界面操作，特别适合给非运维同学用。这篇文章讲清楚容器化部署、Socket 挂载、初始账号、单 Docker / 集群模式选择。

阅读对象：想给团队/客户提供一个"点开就能用"的 Docker 管理界面的同学
覆盖范围：Portainer CE 容器化部署、Docker Socket 挂载、初始账号、单 Docker 模式 / Swarm 模式 / K8s 模式差异

一、为什么是 Portainer

容器管理工具不少，但定位不同：

工具	定位	适用场景
Portainer CE	通用、轻量、社区版	单 Docker / 小团队 / 给非运维用
Rancher	重量级、企业 K8s 管理	多 K8s 集群管理（已转型到 Rancher Prime）
Docker Desktop	本地开发	macOS / Windows 上单机使用
Lazydocker	TUI	命令行党、SSH 远程
Cockpit + podman	系统管理	RHEL 系

Portainer 的"杀手锏"是零学习成本——只要能开浏览器就能用 docker，比着文档点点鼠标就能拉镜像、起容器、看日志。

When to use：当你的团队里有人不熟 docker 命令行，或者要给客户演示/验收容器部署，Portainer 几乎是不二之选。如果只是个人开发用，且只需要起一两个容器，Portainer 会"杀鸡用牛刀"。

二、容器化部署

2.1 单 Docker 模式（最常见）

1
2
3
4
5
6
7


docker run -d \
 --restart=unless-stopped \
 --name portainer \
 -p 9900:9000 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /home/docker/portainer/data:/data \
 portainer/portainer

挂载说明：

挂载点	作用
`/var/run/docker.sock:/var/run/docker.sock`	接管宿主机 Docker Daemon，让 Portainer 能 list/start/stop 容器
`/home/docker/portainer/data:/data`	Portainer 自己的数据（账号、配置、堆栈）持久化

访问 http://{{HOST}}:9900：

首次进入会要求设置 admin 账号（不是默认账号！）
然后选择 “Get started” / “Local” 进入单 Docker 模式

2.2 初始账号

重要：新版本 Portainer 不再有默认账号，首次启动强制让你创建 admin 账号（最少 12 位密码）。网上很多老教程说"admin/admin123456789"那是过期文档。

2.3 Community Edition vs Business Edition

Portainer 有两个版本：

CE（Community Edition）：免费，单一环境（单 Docker / 单 Swarm / 单 K8s），基础 RBAC
BE（Business Edition）：商业授权，多环境管理、LDAP/AD 集成、细粒度 RBAC、合规审计

绝大多数中小团队用 CE 足够。如果企业有合规、审计、SSO 需求，再考虑 BE。

三、核心功能

进入 Portainer 后，左侧导航是核心功能区：

3.1 Stacks（Compose 一键部署）

Stacks → Add stack，把 docker-compose.yml 内容贴进去（支持 Git 仓库、Web editor、Upload），点 Deploy 就能拉起一整套服务。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


version: "3"
services:
 redis:
 image: redis:7-alpine
 restart: always
 ports:
 - 6379:6379
 postgres:
 image: postgres:15-alpine
 restart: always
 environment:
 POSTGRES_PASSWORD: "{{REDACTED}}"
 volumes:
 - pgdata:/var/lib/postgresql/data
volumes:
 pgdata:

变量插值：Portainer 支持 {{VAR}} 占位符，在 Stack 部署时填入。不要把明文密码写进 yaml 文件，用环境变量注入。

3.2 Containers / Images / Volumes / Networks

点进去就能 list、inspect、start、stop、kill、remove、exec。Container logs 还支持 tail -f 实时跟随——比 SSH 进去 docker logs -f 还方便。

3.3 Swarm 模式（多节点）

如果宿主机是 Docker Swarm 集群，Portainer 能识别并显示所有 worker 节点，统一管理。前提是 Swarm 集群已经初始化：

1

docker swarm init

集群里其它节点执行 docker swarm join --token ... 加入后，Portainer 自动发现。

3.4 K8s 模式

Add Environment → Kubernetes，填 kubeconfig 或者 service account，就能把 Portainer 接到 K8s 集群。但 K8s 模式功能比 CE 版还基础（命名空间、Deployment、Service、Pod 管理），复杂场景推荐用 Rancher / Lens / Octant。

四、生产环境建议

不要把 Portainer 暴露到公网——9000 端口直接对外是"裸奔"，docker.sock 挂载意味着谁拿到 Portainer 就能控制宿主机所有容器
用 Nginx / Caddy 反向代理——加 HTTPS、加 basic auth、加 IP 白名单
管理员账号——设置复杂的 12+ 位密码
数据备份——/home/docker/portainer/data 整个目录定期 tar 备份
升级——docker pull portainer/portainer && docker restart portainer，但要看 release notes 注意破坏性变更

五、踩坑清单

看不到容器——/var/run/docker.sock 没挂载，Portainer 只是空壳。检查挂载路径
Stacks 部署失败不报错——看 Events 标签页，docker daemon 的报错会写在那里
Container 控制台中文乱码——容器本身的 locale 问题，进 Exec 之前先 export LANG=C.UTF-8
Image 拉取超时——Portainer 不会自动用 daemon.json 里的 mirror，但 docker daemon 会（继承宿主配置），所以本质上不影响
多用户场景——CE 版的 RBAC 很基础（只支持 owner / administrator / operator / viewer 四种角色），复杂权限需要 BE

六、2024+ 视角补充

本文写于 2023-03，2024-2026 期间 Portainer 有几个显著演进：

Portainer CE 2.20+（2024 主流版本）：

Edge Agent 模式强化：分布式 IoT / 多机房场景下，Edge Agent 可以主动连中心 Portainer（出站 NAT 友好）
GitOps 集成：Stack 支持从 Git 仓库自动同步（Git pull = 自动 deploy），2024 起成为 CE 版的内置能力（之前是 BE 专属）
RBAC 增强：CE 版 RBAC 从 4 个角色（owner / administrator / operator / viewer）扩展到可自定义团队 + 资源访问控制（Namespace 级 / Stack 级 / Container 级）
K8s 体验大幅提升：之前 CE 版 K8s 模式功能很基础，2.20+ 加入 Helm chart 部署、ConfigMap / Secret 管理、Ingress 编辑

Container Management 之外的扩展：

Homepage / Dashboard 定制：每个用户可设自己的首页（“我关心的容器”）
通知集成扩展：Slack / Microsoft Teams / Email / webhook / PagerDuty / Opsgenie——alert rule 可直接推 oncall
审计日志：CE 2.21+ 内置审计日志（之前是 BE 专属），合规场景可用
备份 / 恢复：Stack 级别的"Export / Import"——开发→测试→生产用同一份 stack 配置

Portainer 替代品（2024 视野）：

Rancher Prime（2024 改名，原 Rancher）：SUSE 把 Rancher 商业化转型，企业 K8s 多集群管理首选
Lens：IDE 风格的 K8s 管理工具，免费，桌面应用
OpenLens：Lens 6 后部分闭源，OpenLens 是 fork 继续开源
Headlamp：Kubernetes 官方推荐的 Web UI（取代老旧的 Dashboard）
LazyDocker：终端党 2024 仍活跃
CasaOS / Cosmos：家用 NAS / 小团队 2024+ 更推荐（Portainer 偏运维，CasaOS 偏普通人）

安全更新：

Portainer 2024 年修复过几个严重 RCE（CVE-2024-21xxx），必须升 2.20.3+ 才是安全版本
Docker socket 挂载是核心风险：2024 起官方推荐用 Docker Socket Proxy（tecnativa/docker-socket-proxy）做"最小权限代理"，避免 Portainer 一旦被攻破就拿整个宿主机
2FA 强制开启：CE 2.18+ 强制所有 admin 必须配 2FA（之前是可选）

实战用法变化（2024 视角）：

+ Diun 自动检测镜像更新 → Portainer 推送通知
+ Watchtower 自动升级非关键容器
+ Traefik / Caddy 自动 HTTPS 终结（Portainer 仍主攻容器编排，HTTPS 让专门的反向代理做）
+ Headlamp 管理 K8s 集群（Portainer 主攻 Docker，K8s 用专门工具）

经验法则更新：

Docker 单机 / 小团队 → Portainer CE 2.20+ 仍是 2024+ 首选
K8s 集群 → 优先 Rancher Prime / Lens / Headlamp，Portainer K8s 模式为辅
家用 / 个人 → CasaOS 更轻量更易用
大企业 / 合规 → Portainer BE 仍是合规审计好选择

七、参考资料

Portainer 官方文档：https://docs.portainer.io/
社区版 vs 商业版：https://www.portainer.io/products
Docker Compose 规范：https://docs.docker.com/compose/compose-file/
Portainer 安全公告：https://github.com/portainer/portainer/security/advisories
Docker Socket Proxy：github.com/tecnativa/docker-socket-proxy
Headlamp K8s UI：headlamp.io

下一步

想管 K8s 集群？→ 看 Prometheus 监控告警体系一文
一站式监控+告警？→ HertzBeat 轻量监控告警
想用 PaaS？→ Erda 云原生 PaaS 一文

Docker 安装与基础：从 docker-ce/ee 拆分到多场景落地的完整路径

Mon, 15 Aug 2022 00:00:00 +0800

容器化已经是后端服务的标配，而 Docker 几乎是入门的"必经之地"。从 2013 年 Docker 公开，到 2017 年 Docker 公司宣布拆分社区版（docker-ce）和企业版（docker-ee），再到 2019 年底 Mirantis 接手 Docker Enterprise 业务、2020 年 Docker 把 buildx 收为官方 CLI 插件、2022 年 Kubernetes 1.24 移除 dockershim 引入 cri-dockerd——九年间，Docker 生态的"安装"二字已经远不止 apt install docker.io 那么简单。

这篇文章把零散的安装笔记、版本对比、配置细节整理成一条"从选型到可用"的完整路径，适合刚接触 Docker、或在新机器上做标准化的同学。

阅读对象：需要在 Linux 服务器上从零部署 Docker 的开发者、运维同学
覆盖范围：docker-ce / docker-ee / docker.io 三种发行版差异 + Debian/Ubuntu/Kali/CentOS 主流安装方式 + 离线部署（含 cri-dockerd、buildx、docker-compose v2）+ daemon.json 关键配置 + 清理卸载 + 常见排障

一、为什么需要 Docker

容器不是"更轻的虚拟机"那么简单。在引入 Docker 之前，团队通常被这些痛点反复折磨：

环境漂移：开发用 macOS、测试用 CentOS、生产用 Ubuntu，works on my machine 反复出现
资源浪费：一台物理机只跑两三个 Java 应用，资源利用率不足 20%
交付链条长：应用 + 运行时 + 依赖 + 配置，要运维一台台机器"对版本"
扩缩容难：业务流量上来后，手动扩容几台机器要写一堆脚本
与 K8s 集成难：容器运行时直接对接 kubelet 的 dockershim 接口一改，整个集群要重新适配

Docker 把应用 + 运行时 + 依赖打包成"镜像"，在装有 Docker 引擎的任意机器上一键运行，保证开发、测试、生产环境的一致性。这正是它被广泛接受的根本原因。

When to use：单体应用拆成多服务时、新人 onboard 需要快速搭建环境时、CI/CD 需要稳定可复现的构建产物时，Docker 几乎是首选解。从 LXC 时代走过来，Docker 通过标准化的镜像格式（OCI 规范）、BuildKit 构建系统和 Compose 编排，把"环境一致性"变成了开箱即用的能力。

二、版本选型：docker-ce / docker-ee / docker.io 的真实差异

2017 年 3 月 Docker 公司宣布将 Docker 拆分为两条产品线：开源的 Docker Community Edition（CE） 和商业的 Docker Enterprise Edition（EE）。这次拆分不是营销行为，而是把"包结构"和"维护承诺"做了明确切割——CE 由 Docker Inc. 维护源码、每月发布一次社区版；EE 在 CE 基础上叠加企业级功能，按"基本/标准/高级"三级订阅。

发行版	来源	特点	适用场景
`docker.io`	Debian / Ubuntu / Kali 官方仓库	由发行版包管理器接管依赖，升级时主程序与系统库同步更新；有时版本比 docker-ce 还新	服务器首选 Debian / Ubuntu 系列，追求"系统包管一切"
`docker-ce`	`download.docker.com` 官方源	Docker Inc. 维护源码，用 Go 把依赖尽量静态封装在一个包里，跨发行版一致	CentOS / RHEL / 任何需要"同一版本跑所有机器"的场景
`docker-ee`	Mirantis 客户专用仓库	在 CE 之上叠加 LDAP/AD 集成、RBAC、镜像安全扫描、连续漏洞监控等企业级能力	大型企业、需要 Docker Inc. / Mirantis 商业支持的客户

历史注脚：2019 年 11 月，Mirantis 收购了 Docker 的企业业务（包括 docker-ee 品牌）。所以现在严格意义上"docker-ee"是 Mirantis 商业产品线，而非 Docker Inc. 的产品。如果用 docker-ee 走商业支持，签合同的对象是 Mirantis。

docker-ce 的"致命缺陷"——依赖管理：

docker-ce 把 Docker 引擎依赖的成百上千个第三方库（glibc、openssl、libseccomp、containerd、runc 等）尽量静态或动态链接到自己的包里。这意味着理论上只要其中一个依赖出 CVE，整套 docker-ce 都得重新打补丁、重建二进制、再分发。反观 docker.io，依赖托管给系统包管理器，只需要升级 docker 主程序、系统的 libseccomp 等库跟随 Debian Security Advisory / USN 自动推补丁。

结论：

Debian / Ubuntu / Kali 服务器：直接 apt install docker.io，让系统接管一切
其他发行版（CentOS / RHEL / Amazon Linux / SUSE）：走 docker-ce 官方源或 get-docker.sh 脚本
商业场景：评估 docker-ee / Mirantis Container Cloud 的 SLA 与支持响应

三、Debian / Ubuntu / Kali 系安装

3.1 路线 A：apt 安装 docker.io（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 推荐安装
apt install -y docker.io

# 更新
apt update
apt upgrade -y docker.io

# 验证
docker --version
docker run --rm hello-world

docker.io 包是 Debian / Ubuntu 官方基于 Docker 社区源码封装的版本，特点是把 Docker 的依赖直接转接到主系统。换句话说，系统的 glibc / openssl / libseccomp 升级时，docker.io 自动跟随，不需要 Docker Inc. 单独发版。

3.2 路线 B：apt 安装 docker-ce

如果团队要求"全机器统一 Docker 版本"（比如某条线 CI 必须用 20.10.x），或者 Debian stable 仓库里的 docker.io 太老，就走 docker-ce 源：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# 1. 卸载旧版本（如果存在）
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do
 apt-get remove -y $pkg
done

# 2. 加 Docker 官方 GPG key
apt-get update
apt-get install -y ca-certificates curl gnupg
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/$(. /etc/os-release && echo "$ID")/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

# 3. 加 docker-ce 源
echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/$(. /etc/os-release && echo "$ID") \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 tee /etc/apt/sources.list.d/docker.list > /dev/null

apt-get update

# 4. 装最新 docker-ce
apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

注意：从 20.10 起，官方推荐把 buildx 和 docker-compose 作为插件（plugin）安装，文件落在 /usr/libexec/docker/cli-plugins/。这是为了和 Docker CLI 解耦，buildx 可以独立升级。

3.3 卸载 Debian/Ubuntu 系

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 1. 删主程序（含 docker-ce / docker-ee / docker.io / containerd / runc）
apt-get autoremove docker docker-ce docker-ee docker.io containerd runc

# 2. 查残留
dpkg -l | grep docker

# 3. 清理无用的相关配置文件（^rc 表示已删但留配置）
dpkg -l | grep ^rc | awk '{print $2}' | sudo xargs dpkg -P

# 4. 删 docker-ce-* 子包
apt-get autoremove docker-ce-*

# 5. 删残留目录（关键！apt remove 不会动这些）
rm -rf /etc/systemd/system/docker.service.d
rm -rf /var/lib/docker # 镜像、卷、网络元数据全在这
rm -rf /etc/docker # daemon.json 在这
rm -rf /var/run/docker.sock

# 6. 删 docker 用户组
groupdel docker

# 7. 验证
docker --version # 应该报 command not found

Why 这样卸载：apt remove 只会删主程序二进制，/var/lib/docker 下的镜像、卷、网络、自定义配置都还在；不删干净的话，新装 docker 时旧配置会"莫名生效"，排查很痛苦。

四、CentOS / RHEL 系安装

4.1 加 docker-ce 源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 安装 yum-utils
sudo yum install -y yum-utils

# Docker 官方源
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# 国内源（阿里云）
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

# 或者直接 wget
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo \
 -O /etc/yum.repos.d/docker-ce.repo

# 查看可装版本
yum list docker-ce --showduplicates | sort -r
# 输出类似：
# docker-ce.x86_64 20.10.21-3.el8 docker-ce-stable
# docker-ce.x86_64 18.03.1.ce-1.el7.centos docker-ce-stable

4.2 安装

1
2
3
4
5
6


# 推荐：装 docker-ce + CLI + containerd + buildx + compose 插件
sudo yum install -y docker-ce docker-ce-cli containerd.io \
 docker-buildx-plugin docker-compose-plugin

# 装指定版本
yum -y install docker-ce-20.10.21-3.el8

4.3 卸载 CentOS/RHEL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 查看已装包
rpm -qa | grep docker

# 典型输出（旧版本可能含 python36-docker-*）：
# python36-docker-2.6.1-3.el7.noarch
# docker-client-1.13.1-209.git7d71120.el7.centos.x86_64
# docker-1.13.1-209.git7d71120.el7.centos.x86_64
# docker-compose-1.18.0-4.el7.noarch
# docker-common-1.13.1-209.git7d71120.el7.centos.x86_64

# 一次性卸载
yum remove -y python36-docker-* docker-client-* docker-* \
 docker-compose-* docker-common-*

# 残留目录处理同 Debian
rm -rf /var/lib/docker /etc/docker /var/run/docker.sock

五、官方脚本通用安装

适合任何 Linux 发行版（CentOS、Ubuntu、Debian、Amazon Linux 等），是 Docker 官方最推荐的安装方式之一。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 方式 1：直接管道执行
curl -fLsS https://get.docker.com/ | sh

# 方式 2：下载脚本本地执行（推荐，便于审计）
curl -fsSL https://get.docker.com -o get-docker.sh
DRY_RUN=1 sh ./get-docker.sh # 可选：dry-run 看看会装什么
sudo sh get-docker.sh

# 方式 3：阿里云镜像
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

# 方式 4：DaoCloud 镜像
curl -sSL https://get.daocloud.io/docker | sh

get-docker.sh 会自动检测发行版、加源、装最新稳定版 docker-ce。CentOS 7 系列会自动停用旧版 docker 包，升级到 docker-ce。

六、离线安装

内网 / 无外网环境的标准做法。原理就是先在外网打包好 Docker 的静态二进制 + 依赖 + 配套工具（buildx / docker-compose / cri-dockerd），再传到内网机器解包、注册 systemd unit。

6.1 下载离线包

组件	下载地址
Docker 静态二进制	https://download.docker.com/linux/static/stable/x86_64/
阿里云镜像加速	https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
第三方整合脚本	https://gist.github.com/y0ngb1n/7e8f16af3242c7815e7ca2f0833d3ea6

以 Docker 24.0.7 为例，下载后是一组独立二进制：docker、docker-init、dockerd、runc、ctr、containerd-shim-runc-v2、containerd、docker-proxy。

6.2 解包并安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 解压
tar xvf docker-24.0.7.tgz

# 拷贝二进制到 PATH 目录
cp docker/* /usr/bin

# 准备 containerd 配置（containerd.io 默认配置）
mkdir -p /etc/containerd
containerd config default | tee /etc/containerd/config.toml

# 创建 / 启用 docker systemd unit
systemctl daemon-reload
systemctl enable --now containerd.service
systemctl enable --now docker.service
systemctl enable --now docker.socket

# 验证
docker info
docker run --rm hello-world

2018 时代差异：早期 Docker 还是用 vim /etc/init.d/docker + service docker start + chkconfig docker on 三件套。现在统一走 systemd：写 /etc/systemd/system/docker.service.d/*.conf 覆盖、systemctl daemon-reload、systemctl restart docker。

6.3 配套组件：cri-dockerd（K8s 1.24+ 必装）

Kubernetes 1.24（2022 年 5 月 GA）移除了内置的 dockershim，CRI 改由 containerd / CRI-O 直接对接。如果还想用 Docker 作为 K8s 容器运行时，必须装 cri-dockerd——它把 Docker Engine 重新"翻译"成 CRI 接口给 kubelet 用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 下载 cri-dockerd（与 docker 版本匹配）
curl -fL https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.9/cri-dockerd-0.3.9.amd64.tgz \
 -o /tools/cri-dockerd-0.3.9.amd64.tgz

# 解压
tar xf /tools/cri-dockerd-*.amd64.tgz -C /tools
cp /tools/cri-dockerd/cri-dockerd /usr/local/bin

# 注册 systemd unit
systemctl daemon-reload
systemctl enable --now cri-docker.socket
systemctl enable --now cri-docker.service

# 在 kubeadm init 时指定：
# kubeadm init --cri-socket=unix:///var/run/cri-dockerd.sock

Mirantis 出品：cri-dockerd 是 Mirantis（2019 年接手 Docker Enterprise 的公司）维护的开源项目，所以 Mirantis/cri-dockerd 这个 GitHub 路径是规范来源。

6.4 配套组件：buildx（多架构构建）

buildx 是 Docker 公司在 2020 年 9 月推出的 BuildKit CLI 插件，用来取代老的 docker build。它支持：

多架构构建：一条命令同时打 linux/amd64 和 linux/arm64 镜像
缓存导出：把构建缓存 push 到 registry，下次 docker build 直接命中
BuildKit 高级特性：并发构建、secrets 挂载、SSH 转发

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 安装（在 docker-ce 20.10+ 已经是默认插件）
apt install -y docker-buildx-plugin # Debian/Ubuntu
yum install -y docker-buildx-plugin # CentOS

# 或者从 release 二进制
mkdir -p ~/.docker/cli-plugins
curl -fsSL https://github.com/docker/buildx/releases/download/v0.10.4/buildx-v0.10.4.linux-amd64 \
 -o ~/.docker/cli-plugins/docker-buildx
chmod +x ~/.docker/cli-plugins/docker-buildx

# 创建多架构 builder
docker buildx create --name multiarch --driver docker-container --use
docker buildx inspect --bootstrap

# 跨架构构建示例
docker buildx build \
 --platform linux/amd64,linux/arm64 \
 --tag your-registry.com/your-app:v1.0 \
 --push .

6.5 配套组件：docker-compose v1 / v2 选择

版本	发布时间	形态	现状
Compose v1	2014-07	独立二进制 `docker-compose`（Python 写）	已弃用，2023 年起 Docker Desktop 不再预装
Compose v2	2020-08	Docker CLI 插件 `docker compose`（空格，无连字符）	当前推荐，统一走 Go 重写

离线安装 Compose v1（如果有遗留项目依赖 v1）：

1
2
3


cp /tools/docker_compose /usr/local/bin
chmod +x /usr/local/bin/docker-compose
docker-compose --version

离线安装 Compose v2（推荐）：

1
2
3
4
5


mkdir -p /usr/local/lib/docker/cli-plugins
curl -fsSL https://github.com/docker/compose/releases/download/v2.21.0/docker-compose-linux-x86_64 \
 -o /usr/local/lib/docker/cli-plugins/docker-compose
chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
docker compose version # 注意：v2 是空格

七、验证安装

任何安装方式，最后都要做这几步验证：

1
2
3
4
5
6


systemctl status docker # 状态是否 active
systemctl start docker # 没起就启动
systemctl enable docker # 开机自启
docker info # 引擎详细信息（看 Storage Driver / Cgroup Driver / Registry Mirrors）
docker version # 客户端/服务端版本
docker run --rm hello-world # 跑一个最小测试容器

hello-world 能正常打印 “Hello from Docker!” 就算通了。

八、关键配置：daemon.json

/etc/docker/daemon.json 是 Docker Daemon 的主配置文件。90% 的日常配置都在这里。

8.1 推荐模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": { "max-size": "50m", "max-file": "3" },
 "registry-mirrors": [
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://docker.nju.edu.cn",
 "https://docker.mirrors.sjtug.sjtu.edu.cn"
 ],
 "insecure-registries": [],
 "live-restore": true,
 "storage-driver": "overlay2"
}

8.2 关键字段说明

字段	作用	建议值
`exec-opts.cgroupdriver`	cgroup 驱动	K8s 节点推荐 `systemd`（与 kubelet 保持一致）
`log-driver`	日志驱动	生产环境 `json-file` 或 `journald`
`log-opts.max-size`	单个日志文件大小	`50m` 避免撑爆磁盘
`log-opts.max-file`	保留日志文件数	`3`~`5`，轮转策略
`registry-mirrors`	镜像加速器	国内服务器必加，否则 `docker pull` 慢到怀疑人生
`insecure-registries`	信任的 HTTP 私有仓库	内网 registry 才需要，格式 `IP:PORT`
`live-restore`	Daemon 重启时容器不中断	K8s 节点必须开，否则 kubelet 升级 Docker 就会重启所有 Pod
`storage-driver`	镜像 / 容器分层存储	`overlay2`（CentOS 7.4+ / Ubuntu 18.04+ / Debian 10+ 默认）

8.3 应用配置

1
2
3
4
5
6
7
8


systemctl daemon-reload
systemctl restart docker

# 验证镜像加速生效
docker info | grep -A 10 "Registry Mirrors"

# 验证 live-restore
docker info | grep -i live

进一步可以用 time docker pull nginx:latest 测速，能从几十秒压到几秒就算 mirror 生效。

九、live-restore：K8s 节点的隐藏必修项

Live Restore 是 Docker Daemon 的一项"升级 / 重启不打断容器"的特性。对 K8s 节点来说这是必修项——kubelet 升级、操作系统补丁、daemon 自身重启时，节点上的 Pod 不能因此被重启。

开启方式：

1
2
3
4


// /etc/docker/daemon.json
{
 "live-restore": true
}

1
2
3
4
5
6


systemctl daemon-reload
sudo systemctl reload docker.service # 注意是 reload，不是 restart

# 验证
docker info | grep -i live
# 应输出：Live Restore Enabled: true

集群环境下，daemon.json 改完用 scp + ssh 推送到所有 master / worker 节点：

1
2
3
4
5


for NODE in master2 master3 worker1 worker3 worker4; do
 echo $NODE
 scp /etc/docker/daemon.json $NODE:/etc/docker/
 ssh root@$NODE "systemctl daemon-reload && systemctl reload docker"
done

十、存储卷（Volume）基础

容器文件系统是分层的、临时的，docker rm 之后容器内的数据就没了。生产数据（数据库、用户上传、配置）必须挂到 volume 上。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 创建
docker volume create my-data

# 查看
docker volume ls

# 查看详细信息（包含 mount point）
docker volume inspect my-data

# 删除单个
docker volume rm my-data

# 删除所有未被引用的卷
docker volume prune

-v 挂载用法：

1
2
3
4


docker run -d --name mysql \
 -v mysql_data:/var/lib/mysql \
 -e MYSQL_ROOT_PASSWORD=xxx \
 mysql:8.0

关键警告：docker volume prune 会永久删除未被任何容器引用的卷，里面如果有数据库 / 业务数据，删了就没了——生产环境慎用。删之前先 docker volume ls + docker volume inspect 逐个确认。

十一、网络模式与网桥清理

11.1 docker0 网桥

Docker 进程启动时，会在主机上创建一个名为 docker0 的虚拟网桥，默认地址 172.17.0.0/16。所有以 Bridge 模式启动的容器都"插"到这个虚拟交换机上，通过 docker0 ↔ 物理网卡 eth0 ↔ 外部网络。

如果想彻底关掉默认网桥（自定义网络场景）：

1
2
3
4
5


// /etc/docker/daemon.json
{
 "iptables": false,
 "bridge": ""
}

1
2


systemctl daemon-reload
systemctl restart docker

注意：删 docker0 是一次性的——下次 daemon 启动没指定 -b 参数又会自动重建。一般用 daemon.json 里的 bridge: "" 永久关闭更稳妥。

11.2 容器从网桥上摘除

1
2


# 把某个容器从默认 bridge 网络上摘除
docker network disconnect -f bridge container-name

十二、基础清理

跑完一轮测试容器之后，会留下不少"垃圾"。下面是分级清理命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 删除所有未使用的对象（停掉的容器、dangling 镜像、未用网络）
docker system prune -f

# 包括未使用的卷（危险：会丢数据）
docker system prune -f --volumes

# 只删未使用的网络
docker network prune -f

# 只删 12 小时前创建的网络
docker network prune -a --filter "until=12h"

# 只删 24 小时前没用的镜像
docker image prune -a --filter "until=24h"

核心要点 / 常见坑：

docker system prune --volumes 会删未挂载的卷，里面如果残留数据库数据，删了就没了——生产慎用
dangling 镜像指的是无 tag 的中间层镜像（<none>:<none>），安全可删
想看"能删多少"先用 docker system df 看磁盘占用
docker system df -v 还能看到每个 volume / image 占多少空间，方便定位"硬盘杀手"

十三、镜像代理（应对国内拉镜像慢）

拉 Docker Hub / ghcr / gcr / k8s.gcr.io / quay.io 镜像在国内慢到超时是常态。常见做法是用镜像代理做反代。

原始 registry	代理写法（以 `dockerproxy.com` 为例）
Docker Hub	`docker pull dockerproxy.com/library/nginx:latest`
GHCR	`docker pull ghcr.dockerproxy.com/username/image:tag`
GCR	`docker pull gcr.dockerproxy.com/username/image:tag`
k8s.gcr.io / registry.k8s.io	`docker pull k8s.dockerproxy.com/coredns:1.6.5`
Quay.io	`docker pull quay.dockerproxy.com/username/image:tag`

南京大学 GHCR 镜像：ghcr.nju.edu.cn 是国内 GHCR 加速的另一个选择，直接把 ghcr.io/xxx 替换为 ghcr.nju.edu.cn/xxx 即可。

如果嫌每个镜像都改前缀麻烦，直接配 daemon.json 的 registry-mirrors（见第八节）就能让所有 docker pull 走代理。

十四、常见问题速查

报错	原因	解决
`permission denied` 访问 `/var/run/docker.sock`	当前用户不在 docker 组	`sudo usermod -aG docker $USER`，重新登录
`Cannot connect to the Docker daemon`	daemon 没起	`systemctl start docker`
`WARNING: IPv4 forwarding is disabled`	宿主机没开 ip_forward	`echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf`，`sysctl -p`
`unknown or invalid runtime name: docker-runc`	老 docker 升级后 runtime 名变了	`grep -rl 'docker-runc' /var/lib/docker/containers/ \| xargs sed -i 's/docker-runc/runc/g'`，重启 daemon
K8s 1.24+ 报 `failed to create sandbox: cri-dockerd not found`	用了 docker 但没装 cri-dockerd shim	装 cri-dockerd（见 6.3 节），kubelet 加 `--cri-socket=unix:///var/run/cri-dockerd.sock`
`kubelet cgroup driver: "cgroupfs" is different from docker: "systemd"`	kubelet / docker cgroup driver 不一致	双方都改成 `systemd`：daemon.json 加 `"exec-opts": ["native.cgroupdriver=systemd"]`，kubelet 加 `--cgroup-driver=systemd`
`image pull failed: toomanyrequests`	Docker Hub 匿名拉取限流	配 `registry-mirrors` 走国内 mirror，或登录 Docker Hub 账号

十五、小结

把这一篇的要点压缩成 7 条：

版本选型：Debian/Ubuntu 优先 docker.io（系统接管依赖），其他发行版走 docker-ce 官方源，商业场景评估 docker-ee / Mirantis 商业支持
离线部署：静态二进制 + systemd unit + daemon.json，三件套即可；K8s 1.24+ 别忘了 cri-dockerd
buildx：2020 年后推荐用 docker buildx，多架构 + 缓存导出 + BuildKit 特性完胜老 docker build
Compose v2：用空格 docker compose，v1 已弃用
关键配置：daemon.json 的 log-driver / log-opts 一定要限制大小，否则生产会撑爆磁盘；K8s 节点必须开 live-restore
国内镜像：必须配 registry-mirrors，否则 docker pull 慢到怀疑人生
卸载干净：apt/yum remove 删不干净 /var/lib/docker，重装前手动清掉避免配置残留

下一步：装好 Docker 之后，最常被问到的就是"容器之间怎么通信"、“数据怎么持久化”——这正是下一篇《Docker 进阶与运维：网络模式、存储卷与镜像加速》要展开的内容。

参考资料

K8s 实战：Deployment/StatefulSet/DaemonSet 区别 + 探针 + hostNetwork

Thu, 15 Aug 2019 00:00:00 +0800

K8s 三种核心控制器

K8s 应用的"控制器"决定了 Pod 的行为模式。生产环境用错控制器，轻则"Pod 不断重启"，重则"数据全丢"。

1. Deployment：无状态

1.1 原理

Deployment 通过 ReplicaSet 管 Pod 副本——保证"指定数量的 Pod 副本在运行"，Pod 之间无差别。

适用场景：

Web 服务（nginx / Spring Boot）
API 服务
微服务（无状态）
任何"可以随时被 kill + 重建"的应用

1.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: nginx:latest
 ports:
 - containerPort: 80

2. StatefulSet：有状态

2.1 原理

StatefulSet 给每个 Pod 分配：

稳定的网络标识：my-sts-0、my-sts-1、my-sts-2
稳定的持久存储：每个 Pod 绑定独立 PVC
有序部署 / 扩容 / 缩容：my-sts-0 先 Ready，my-sts-1 才创建

适用场景：

数据库（MySQL、MongoDB、PostgreSQL）
消息队列（Kafka、RabbitMQ 集群模式）
分布式存储节点
任何"必须有持久身份"的应用

2.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: my-statefulset
spec:
 replicas: 3
 serviceName: my-service
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: nginx:latest
 ports:
 - containerPort: 80
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: [ReadWriteOnce]
 resources:
 requests:
 storage: 10Gi

2.3 关键：serviceName 必填

StatefulSet 必须有 serviceName（Headless Service 的名字），K8s 通过这个 Service 给每个 Pod 生成 DNS 记录：

1
2


my-sts-0.my-service.default.svc.cluster.local
my-sts-1.my-service.default.svc.cluster.local

3. DaemonSet：节点守护

3.1 原理

DaemonSet 在每个 Node 上都跑一个 Pod 副本。新节点加入集群 → 自动创建 Pod；节点删除 → 自动清理。

适用场景：

日志收集（Promtail / Filebeat / Fluentd）
节点监控（node-exporter / cadvisor）
网络组件（calico-node / flannel / cilium）
存储守护进程

3.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: my-daemonset
spec:
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-container
 image: nginx:latest
 ports:
 - containerPort: 80

DaemonSet 不关心 replicas 数量，只关心"每个节点都有"。

3.3 节点选择器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


spec:
 template:
 spec:
 nodeSelector:
 node-role: worker  # 只在打了这个标签的节点跑
 tolerations:
 - key: dedicated
 operator: Equal
 value: ceph
 effect: NoSchedule  # 能容忍 NoSchedule 污点

4. 三者对比

维度	Deployment	StatefulSet	DaemonSet
副本数	任意	任意	节点数
Pod 名称	随机	有序稳定	稳定
存储	共享 PVC	独立 PVC	hostPath / 共享
扩缩容	无序	有序	自动跟随节点
滚动更新	任意	有序	任意
删除	一起删	有序删	节点没了才删
适用	Web / API	DB / 消息队列	监控 / 日志 / 网络

5. 健康探针（Probe）

5.1 3 种探针

探针	作用	失败后果
livenessProbe	容器是否"活着"	重启容器
readinessProbe	容器是否"准备好接流量"	从 Service Endpoints 移除
startupProbe	启动是否完成	慢启动场景，避免 liveness 过早失败

5.2 Spring Boot 应用示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


spec:
 containers:
 - name: springboot-app
 image: my-app:1.0
 ports:
 - name: http
 containerPort: 8080
 - name: management
 containerPort: 9090
 livenessProbe:
 httpGet:
 path: /actuator/health/liveness
 port: management
 initialDelaySeconds: 180 # 启动后等 3 分钟
 periodSeconds: 10
 timeoutSeconds: 1
 successThreshold: 1
 failureThreshold: 6 # 连续失败 6 次才重启
 readinessProbe:
 httpGet:
 path: /actuator/health/readiness
 port: management
 initialDelaySeconds: 180
 periodSeconds: 10
 timeoutSeconds: 5
 successThreshold: 1
 failureThreshold: 9 # 连续失败 9 次才下线

坑：initialDelaySeconds 设太短（如 10s）会导致慢启动应用被频繁重启；设太长（>10min）会拖慢故障恢复。

5.3 tcpSocket 探针

1
2
3
4
5


livenessProbe:
 tcpSocket:
 port: 8080
 initialDelaySeconds: 30
 periodSeconds: 10

5.4 exec 探针

1
2
3
4
5
6
7


livenessProbe:
 exec:
 command:
 - cat
 - /tmp/healthy
 initialDelaySeconds: 5
 periodSeconds: 5

6. hostNetwork 调度

6.1 为什么用

有些场景 Pod 必须用宿主网络命名空间：

Ingress-nginx（DaemonSet + hostNetwork 监听 80/443）
监控 agent（采集宿主机 metrics）
端口被固定需要"独占"某端口

6.2 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


apiVersion: apps/v1
kind: Deployment
metadata:
 name: safety-powerjob-worker
 namespace: test
spec:
 replicas: 1
 template:
 metadata:
 labels:
 app: safety-powerjob-worker
 spec:
 hostNetwork: true
 hostAliases:
 - ip: 10.100.99.252
 hostnames: ["extend-service.test"]
 affinity:
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [safety-powerjob-worker]
 topologyKey: "kubernetes.io/hostname"
 containers:
 - name: safety-powerjob-worker
 image: my-app:latest

6.3 关键风险

端口冲突：hostNetwork 模式下 Pod 直接占用宿主机端口。如果 2 个 Pod 调度到同一节点都想占用 8080 → 后启动的 CrashLoopBackOff。

症状：

1
2


kubectl describe pod <pod>
# Events: ... failed to bind port 8080

解决：

DaemonSet + hostAntiAffinity（推荐）
用 DaemonSet 而不是 Deployment（每节点最多 1 个）
指定 nodeName 强制单节点

6.4 实战：hostNetwork + 端口冲突排查

1
2


journalctl -u kubelet | grep "<pod-name>"
# 看到 "port already in use"

常见原因：calico-kube-controllers 用了 hostNetwork，端口被其他 Pod 抢占。

7. 节点亲和与反亲和

7.1 软亲和 / 反亲和（preferred）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


affinity:
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [my-app]
 topologyKey: "kubernetes.io/hostname"

软约束：尽量不调度到一起，但不保证。生产用得最多。

7.2 硬亲和 / 反亲和（required）

1
2
3
4
5
6
7
8
9


affinity:
 podAntiAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [my-app]
 topologyKey: "kubernetes.io/hostname"

硬约束：必须不调度到一起，调度不到就 Pending。

7.3 节点亲和（nodeAffinity）

1
2
3
4
5
6
7
8


affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: dedicated
 operator: In
 values: [ml]

把 Pod 调度到打了 dedicated=ml 标签的节点（专用机器学习节点）。

8. 节点选择与污点容忍

1
2
3
4
5
6
7
8


spec:
 nodeSelector:
 disktype: ssd
 tolerations:
 - key: dedicated
 operator: Equal
 value: ml
 effect: NoSchedule

nodeSelector 选节点，tolerations 容忍污点。

9. 实战：Spring Boot 微服务完整 yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


apiVersion: apps/v1
kind: Deployment
metadata:
 name: user-service
 labels:
 app: user-service
spec:
 replicas: 3
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxSurge: 1
 maxUnavailable: 0
 selector:
 matchLabels:
 app: user-service
 template:
 metadata:
 labels:
 app: user-service
 spec:
 affinity:
 podAntiAffinity:
 preferredDuringSchedulingIgnoredDuringExecution:
 - weight: 100
 podAffinityTerm:
 labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values: [user-service]
 topologyKey: "kubernetes.io/hostname"
 containers:
 - name: user-service
 image: my-harbor.example.com/base/user-service:v1.2.3
 ports:
 - name: http
 containerPort: 8080
 env:
 - name: SPRING_PROFILES_ACTIVE
 value: prod
 - name: NACOS_SERVER
 value: nacos.example.com:8848
 resources:
 requests:
 cpu: 500m
 memory: 512Mi
 limits:
 cpu: 2000m
 memory: 2048Mi
 livenessProbe:
 httpGet:
 path: /actuator/health/liveness
 port: 8080
 initialDelaySeconds: 120
 periodSeconds: 10
 readinessProbe:
 httpGet:
 path: /actuator/health/readiness
 port: 8080
 initialDelaySeconds: 60
 periodSeconds: 5
 imagePullSecrets:
 - name: harbor-secret
---
apiVersion: v1
kind: Service
metadata:
 name: user-service
spec:
 selector:
 app: user-service
 ports:
 - port: 80
 targetPort: 8080
 name: http
 type: ClusterIP

10. 常见问题

10.1 Deployment 一直 RestartCount 增长

livenessProbe 失败 → kubelet 重启容器。检查：

1
2
3


kubectl describe pod <pod>
# Events: ... Liveness probe failed
kubectl logs <pod> --previous

10.2 StatefulSet 扩容后 Pod 一直 Pending

PVC 创建失败。检查：

1
2
3


kubectl get pvc -n <ns>
kubectl describe pvc <pvc-name>
# FailedBinding：节点不满足 storage class 标签

10.3 DaemonSet 一些节点没 Pod

1
2
3
4


kubectl describe daemonset <name>
# 看 Desired / Current / Ready / Available
kubectl get nodes --show-labels
# 节点有 nodeSelector 标签吗？

10.4 hostNetwork 端口冲突

1
2


journalctl -u kubelet -n 50 --no-pager
# 看到 "address already in use"

10.5 Pod 调度到 taint 节点失败

1
2


kubectl describe pod <pod>
# Events: ... 0/3 nodes are available: 3 node(s) had taint {dedicated: ceph}, that the pod didn't tolerate.

加 tolerations 或换节点。

11. 小结

K8s 控制器三件套是部署应用的"基本功"：

Deployment 是默认选择（无状态）
StatefulSet 用于有状态（必须有 serviceName）
DaemonSet 用于节点级守护
Probe + hostNetwork + Affinity 是高级调度三件套
RollingUpdate strategy 控制滚动更新节奏

下一步（其他批次的双机房双集群 / Redis Cluster 6 节点架构实践）。

K8s PVC 备份恢复：CSI Snapshot / Velero / rsync 三方案

Wed, 15 Nov 2017 00:00:00 +0800

K8s 数据备份为什么这么难

K8s 部署的应用大部分是无状态的，但总有些"有状态"必须保：

数据库（MySQL/PostgreSQL）：跑在 StatefulSet 上
配置中心（Nacos/Consul）：配置不能丢
用户上传（图片/文件）：存在 PVC 上

K8s 本身的 controller 只管"无状态"应用，PVC 数据完全靠用户自己备份。

1. 5 种 PVC 备份方式

方法	说明	支持所有卷类型？
Volume 快照（CSI Snapshot）	CSI 插件实现卷快照	✅ CSI 卷
Velero	用 Velero 备份 PVC（需配合对象存储）	✅ 大多数
Rsync / tar + 挂载 PVC	手动挂载 PVC 拷贝	✅ 几乎所有
GlusterFS 专用方法	gluster snapshot / rsync	⚠️ 仅 GlusterFS
StatefulSet + PVC 模板	应用层备份	⚠️ 依赖应用设计

1.1 选型决策

用了 Rook-Ceph / Portworx / Longhorn：CSI Snapshot（最快）
用了 NFS / GlusterFS 这种"无快照能力"的：Velero（标准方案）
临时备份/迁移：rsync + 挂载 PVC（最灵活）
应用本身有备份能力（mysqldump、etcd snapshot）：让应用自己备份

2. GlusterFS 备份与恢复

2.1 挂载 GlusterFS 客户端

1
2
3
4
5


# Ubuntu
sudo apt install -y glusterfs-client

sudo mkdir -p /mnt/glusterfs_old
sudo mount -t glusterfs <gluster-node-ip>:<volume-name> /mnt/glusterfs_old

2.2 备份数据

1
2
3
4
5
6
7
8


mkdir -p /backup/zendao_pvc

# 找到 PVC 对应目录
cd /mnt/glusterfs_dv
cd "$(find . -type d -name 'pvc-<uuid>' -print -quit)"

# 同步
rsync -av /mnt/glusterfs_dv/subvol/<path>/pvc-<uuid>/ /backup/zendao_pvc/

2.3 还原

1
2
3


# 创建新 PVC（kadalu / nfs-subdir），拿到新 PVC 路径
# 把数据写回
rsync -av /backup/zendao_pvc/ /mnt/glusterfs_dv/subvol/<新路径>/pvc-<新uuid>/

3. 远程 rsync 备份

把数据同步到远程备份机（避免单点）：

1
2
3
4
5
6
7
8
9


# 远程机器先建目录
mkdir -p /home/bak/dv/zendao_pvc

# 同步
rsync \
 -avz \
 -e ssh \
 /backup/zendao_pvc/ \
 root@<worker4-ip>:/home/bak/dv/zendao_pvc/

增量同步（带删除）：

1
2
3
4
5
6
7


rsync \
 -avz \
 --delete \
 --dry-run \
 -e ssh \
 /mnt/glusterfs_dv/subvol/<path>/pvc-<uuid>/ \
 root@<worker4-ip>:/home/bak/dv/zendao_pvc/

--dry-run 看到底要同步什么；去掉它就是真的同步。

4. 借助"中转 Pod"做 PVC 备份

K8s 上直接访问 PVC 路径比较麻烦（要 exec 进 pod，或者用 driver 内置工具）。一个"中转 pod"模式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# pvc-tester.yaml
apiVersion: v1
kind: Pod
metadata:
 name: pvc-tester
 namespace: kube-ops
spec:
 containers:
 - name: tester
 image: alpine
 command: ["sleep", "3600"]
 volumeMounts:
 - name: data
 mountPath: /mnt/pvc
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: jenkins-agent-pvc

1

kubectl apply -f pvc-tester.yaml

4.1 远程到 pod（用 rsync over SSH）

Pod 内装 openssh-server，挂载 pod 上 .ssh 目录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 主机上生成 SSH key
ssh-keygen

# 公钥写到 pod 内
kubectl -n kube-ops exec -it pvc-tester -- sh -c "mkdir -p /root/.ssh && chmod 700 /root/.ssh"
cat ~/.ssh/id_rsa.pub | kubectl -n kube-ops exec -i pvc-tester -- sh -c "cat >> /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys"

# 远程 rsync 到 pod
POD_IP=$(kubectl -n kube-ops get pod pvc-tester -o jsonpath='{.status.podIP}')
rsync -avz --progress -e ssh /backup/jenkins_pvc/ root@$POD_IP:/mnt/pvc/

注意：Pod 内需要有 sshd（基础 alpine 镜像没有）；可以换 openssh-server 镜像，或用 kubectl cp 简化。

4.2 kubectl cp 简化

1
2
3
4
5


# 不需要 sshd
kubectl -n kube-ops cp /backup/jenkins_pvc/. pvc-tester:/mnt/jenkins-pvc/

# 反向：把 pod 内数据拷出来
kubectl -n kube-ops cp pvc-tester:/mnt/zentao-pvc/ /backup/zendao_pvc/

局限：kubectl cp 走 tar 流，对超大文件慢（GB 级以上）。

5. CSI Snapshot（生产推荐）

CSI 1.0+（K8s 1.17+）提供 VolumeSnapshot / VolumeSnapshotContent / VolumeSnapshotClass 三个 CRD。

5.1 前置

存储驱动必须实现 VolumeSnapshot 接口（Rook-Ceph 1.0+、Portworx、Longhorn 1.2+ 都支持）。

5.2 VolumeSnapshotClass

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
 name: csi-rbd-snapclass
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
 clusterID: rook-ceph
 csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner
 csi.storage.k8s.io/snapshotter-secret-namespace: rook-ceph
 csi.storage.k8s.io/snapshotter-list-secret-name: rook-csi-rbd-provisioner
 csi.storage.k8s.io/snapshotter-list-secret-namespace: rook-ceph
deletionPolicy: Retain

5.3 创建快照

1
2
3
4
5
6
7
8
9


apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: mysql-snapshot-2024-12-15
 namespace: default
spec:
 volumeSnapshotClassName: csi-rbd-snapclass
 source:
 persistentVolumeClaimName: mysql-data

1
2


kubectl get volumesnapshot
# STATUS 必须是 Ready

5.4 从快照恢复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mysql-restored
 namespace: default
spec:
 storageClassName: rook-ceph-block
 dataSource:
 name: mysql-snapshot-2024-12-15
 kind: VolumeSnapshot
 apiGroup: snapshot.storage.k8s.io
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 10Gi

新 Pod 挂载 mysql-restored PVC 就拿到快照时的数据。

6. Velero（集群级备份）

Velero 备份整个 K8s 资源 + PV 数据到对象存储。

6.1 安装

1
2
3
4
5


velero install \
 --provider aws \
 --bucket <bucket-name> \
 --secret-file ./credentials-velero \
 --use-restic

如果用 MinIO 当对象存储：

1
2
3
4
5
6


velero install \
 --provider aws \
 --bucket velero-backups \
 --secret-file ./credentials-velero \
 --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://<minio-host>:9000 \
 --use-restic

6.2 备份

1
2
3
4
5
6
7
8


# 备份整个集群
velero backup create full-backup-2024-12-15

# 备份指定 namespace
velero backup create mysql-backup --include-namespaces default

# 备份指定资源
velero backup create jenkins-backup --include-resources statefulsets,pvc

6.3 恢复

1

velero restore create --from-backup full-backup-2024-12-15

6.4 定时备份

1

velero schedule create daily-backup --schedule="0 2 * * *"

每天凌晨 2 点全量备份。

7. 实战：禅道 + Jenkins PVC 备份

以 kube-ops 命名空间下的禅道和 Jenkins 为例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. 准备中转 pod
kubectl apply -f pvc-tester.yaml

# 2. 备份禅道
kubectl -n kube-ops cp pvc-tester:/mnt/zentao-pvc/ /backup/zendao_pvc/
kubectl -n kube-ops cp pvc-tester:/mnt/jenkins-pvc/ /backup/jenkins_pvc/

# 3. 远程同步
rsync -avz -e ssh /backup/zendao_pvc/ root@<remote-backup-host>:/backup/

# 4. 清理
kubectl delete -f pvc-tester.yaml

恢复时反向操作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 启动中转 pod
kubectl apply -f pvc-re.yaml

# 2. 恢复数据
kubectl -n kube-ops cp /backup/jenkins_pvc/. pvc-tester:/mnt/jenkins-pvc/
kubectl -n kube-ops cp /backup/zendao_pvc/. pvc-tester:/mnt/zentao-pvc/

# 3. 恢复原服务
kubectl apply -f xxxx.yaml
kubectl exec -it zentao-5dd779bcb8-ngl5p -n kube-ops -- bash
chmod 777 -R /apps/zentao/tmp/

8. 常见问题

8.1 PVC 一直 Pending

1
2
3


kubectl describe pvc jenkins-agent-pvc -n kube-ops
# 找 "no persistent volumes available for this claim" → storage class 不对
# 找 "FailedBinding" → 节点不满足

如果是 SSH 问题（OpenEBS 节点访问），pvc-tester 上检查：

1
2


ssh root@<gluster-host>
# 确认 ssh key 配好

8.2 VolumeSnapshot 失败

1
2


kubectl describe volumesnapshot mysql-snapshot
# 查 Events：通常是 RBAC 或 Secret 缺

8.3 Velero 备份后恢复失败

Velero 默认不备份所有 CRD。恢复前确认：

1
2


velero backup describe full-backup --details
# 看 Resources 列表

8.4 kubectl cp 大文件超时

1
2


# 加 timeout
kubectl --request-timeout=600s cp ...

或换 rsync over SSH（pod 内装 openssh-server）。

9. 小结

PVC 备份的"最佳实践"是组合拳：

日常：CSI Snapshot（最快，秒级）
跨集群：Velero（标准方案）
冷备/迁移：rsync + tar（最灵活）
不要忘：应用层备份（mysqldump、etcd snapshot）

下一步：K8s 集群运维命令大全：kubectl 速查 + 节点维护。

MinIO / JuiceFS / OpenEBS：K8s 对象存储与本地 PV 全方案

Tue, 15 Aug 2017 00:00:00 +0800

三种 K8s 存储的"非主流"路线

主流 K8s 存储是 NFS + Ceph，但有些场景它们都力不从心：

S3 兼容对象存储（备份、日志、镜像）→ MinIO
海量小文件 + 多云（AI 训练、媒资）→ JuiceFS
本地磁盘池化（DB 性能、StatefulSet）→ OpenEBS

本文一次讲清这三套方案。

适用版本：MinIO 2024.x / JuiceFS 1.x / OpenEBS 3.4

1. MinIO 作为 PV 存储

1.1 思路

通过 k8s-csi-s3 这个 CSI 驱动，让 S3（MinIO）作为 K8s 的 PV 后端——申请 PVC 时自动创建 S3 bucket，Pod 内能像本地目录一样访问。

警告：源码明确写"不建议生产环境使用"。原因是 S3 不是真正的文件系统，POSIX 兼容有限（特别是 append 写）。但作为 静态资源 / 备份 场景的 PV 非常合适。

1.2 要求

Kubernetes 1.16+（CSI v1.0.0）
kubelet 允许特权容器
Docker daemon MountFlags=shared（新增分区无需重启 Docker）

1
2
3
4
5
6


# /etc/systemd/system/docker.service
[Service]
MountFlags=shared
Type=notify
ExecStart=/usr/local/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
...

1.3 创建 Secret

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: v1
kind: Secret
metadata:
 name: csi-driver-s3-secret
 namespace: kube-system
stringData:
 accessKeyID: "{{MINIO_ACCESS_KEY}}"
 secretAccessKey: "{{MINIO_SECRET_KEY}}"
 endpoint: https://<minio-endpoint>
 region: ""

实际访问密钥用占位符 {{MINIO_ACCESS_KEY}} {{MINIO_SECRET_KEY}} 替代。

1.4 安装 CSI 驱动

按 yandex-cloud/k8s-csi-s3 仓库的 provisioner.yaml / attacher.yaml / csi-driver-s3.yaml / psp.yaml 部署。

1.5 mounter 选择

驱动支持 4 种 mount 工具：

mounter	兼容性	性能	适用
rclone	几乎完全 POSIX	中	通用
s3fs	较大子集	中	通用，不支持 append
goofys	弱	最高	只读/大批量，不支持 append
s3backer	实验性	-	块设备，但卷损坏风险大

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: csi-driver-s3
provisioner: s3.csi.metal-stack.io
parameters:
 mounter: s3fs
 csi.storage.k8s.io/provisioner-secret-name: csi-driver-s3-secret
 csi.storage.k8s.io/provisioner-secret-namespace: kube-system
 csi.storage.k8s.io/controller-publish-secret-name: csi-driver-s3-secret
 csi.storage.k8s.io/controller-publish-secret-namespace: kube-system
 csi.storage.k8s.io/node-stage-secret-name: csi-driver-s3-secret
 csi.storage.k8s.io/node-stage-secret-namespace: kube-system
 csi.storage.k8s.io/node-publish-secret-name: csi-driver-s3-secret
 csi.storage.k8s.io/node-publish-secret-namespace: kube-system

1.6 使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: csi-s3-pvc
 namespace: default
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-s3
---
apiVersion: v1
kind: Pod
metadata:
 name: csi-s3-test-nginx
spec:
 containers:
 - name: csi-s3-test-nginx
 image: nginx
 volumeMounts:
 - mountPath: /var/lib/www/html
 name: webroot
 volumes:
 - name: webroot
 persistentVolumeClaim:
 claimName: csi-s3-pvc
 readOnly: false

1
2
3
4
5


kubectl exec -it csi-s3-test-nginx -- bash
cd /var/lib/www/html/
touch 2024-12-15.txt
ls
# 2024-12-15.txt

MinIO 上能看到自动创建的 bucket 里有这个文件。

2. JuiceFS 架构

2.1 三大组件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


┌─────────────────────────────────────────────────────────┐
│ JuiceFS 文件系统 │
│ │
│ ┌────────────┐ ┌────────────┐ ┌──────────────────┐ │
│ │ JuiceFS │ │ 数据存储 │ │ 元数据引擎 │ │
│ │ Client │ │ (对象存储) │ │ (Redis/TiKV/MySQL│ │
│ │ (FUSE) │ │ S3/MinIO │ │ /PostgreSQL/ │ │
│ │ │ │ Ceph/OSS │ │ SQLite) │ │
│ └─────┬──────┘ └─────┬──────┘ └────────┬─────────┘ │
│ │ │ │ │
│ └───────────────┴──────────────────┘ │
│ POSIX 兼容挂载 │
└─────────────────────────────────────────────────────────┘

Client：所有文件读写都在客户端，通过 FUSE 暴露 POSIX 接口
数据存储：文件切分上传到 S3/MinIO/Ceph
元数据引擎：文件名、权限、目录树、文件锁、引用计数等

2.2 5 种接入方式

方式	适用场景
FUSE	通用，Linux 服务器当本地盘用
Hadoop Java SDK	替代 HDFS
Kubernetes CSI	K8s 集群直接挂载
S3 网关	用 AWS CLI / s3cmd 访问 JuiceFS
WebDAV	HTTP 协议

2.3 K8s 部署

JuiceFS 官方 CSI 文档：https://juicefs.com/docs/zh/community/getting-started/for_distributed

1
2


helm repo add juicefs https://juicedata.github.io/charts
helm install juicefs juicefs/juicefs-csi-driver -n juicefs --create-namespace

创建 Secret 提供元数据引擎与对象存储凭据：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: Secret
metadata:
 name: juicefs-secret
type: Opaque
stringData:
 name: <filesystem-name>
 metaurl: redis://:<redis-password>@<redis-host>:6379/1
 bucket: http://<minio-host>:9000/<bucket>
 access-key: {{MINIO_ACCESS_KEY}}
 secret-key: {{MINIO_SECRET_KEY}}
 storage-class: STANDARD

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: juicefs
provisioner: csi.juicefs.com
parameters:
 csi.storage.k8s.io/provisioner-secret-name: juicefs-secret
 csi.storage.k8s.io/provisioner-secret-namespace: default
 csi.storage.k8s.io/node-publish-secret-name: juicefs-secret
 csi.storage.k8s.io/node-publish-secret-namespace: default
reclaimPolicy: Retain

2.4 适用场景

AI 训练数据集（海量小文件 + POSIX）
媒资管理（图片、视频）
跨云数据共享

3. OpenEBS 本地 PV

3.1 简介

传统 K8s LocalPV 受限于"单节点单盘"，OpenEBS 通过 iSCSI 协议把"工作节点本地盘"池化：

本地卷（LocalPV）：单节点本地盘，性能最高，DB 推荐
复制卷（cStor）：跨节点复制，有冗余（3 副本）

3.2 内核要求

OpenEBS 走 iSCSI，所有节点装客户端：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# CentOS
yum install iscsi-initiator-utils -y

# Ubuntu
apt install -y open-iscsi

# 启动
systemctl enable --now iscsid
systemctl start iscsid.service

# 可选：开启 nvme_tcp
modprobe iscsi_tcp
echo iscsi_tcp >/etc/modules-load.d/iscsi-tcp.conf
echo "nvme_tcp" | sudo tee /etc/modules-load.d/openebs.conf

3.3 部署 Operator

1
2
3
4
5
6
7
8


# OpenEBS 官方源
helm repo add openebs https://openebs.github.io/openebs
helm repo update

helm install openebs \
 --namespace openebs \
 openebs/openebs \
 --create-namespace

或者 yaml 方式：

1

kubectl apply -f https://openebs.github.io/charts/openebs-operator.yaml

3.4 默认存储路径

1
2


- name: BasePath
 value: "/var/openebs/local/"

OpenEBS 在每个节点上 /var/openebs/local/ 下创建 PV。

3.5 使用

OpenEBS 装好后自动创建几个 StorageClass：

1
2
3
4
5


kubectl get sc
# openebs-hostpath 默认
# openebs-device
# openebs-jiva-csi-default
# openebs-zfspv

直接引用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 storageClassName: openebs-hostpath
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi

3.6 备份

OpenEBS 推荐用 Velero 做备份，原理是 K8s 资源 + PV 数据快照到对象存储。

1
2
3
4
5
6


velero install \
 --provider aws \
 --bucket <bucket-name> \
 --secret-file ./credentials-velero \
 --backup-location-config region=minio \
 --use-restic

4. 三种方案对比

方案	类型	性能	容量上限	多 Pod 共享	适用
MinIO CSI	对象	中（小文件慢）	无限	否（RWO）	静态资源、备份
JuiceFS	分布式文件	中-高	无限	是（RWX）	AI 数据、媒资
OpenEBS LocalPV	本地盘	最高	单机	否	DB、StatefulSet
OpenEBS cStor	分布式块	中	中	否	通用数据库

5. 排错速查

5.1 MinIO CSI Pod 一直 Pending

通常是 RBAC / ServiceAccount 权限问题：

1
2


kubectl describe pod csi-provisioner-s3 -n kube-system
# 查 Events

5.2 JuiceFS 挂载失败

元数据引擎（Redis/MySQL）网络可达？
对象存储 endpoint 正确？
Secret 里的 access-key / secret-key 权限够？

5.3 OpenEBS Node Disk Manager 没起来

1
2


kubectl get pods -n openebs
# openebs-ndm DaemonSet 没起 = iscsi 没装

5.4 OpenEBS PVC 一直 Pending

1
2
3


kubectl describe pvc my-pvc
# 找"没有可用节点满足 volume node affinity"
# 解决：调度到打了 openebs.io/localpv 标签的节点

6. 小结

K8s 存储选型不是"一刀切"：

MinIO CSI 解决"对象存储当 PV 用"的备份场景
JuiceFS 是"国内开源 + 兼容 S3 + POSIX"的分布式文件
OpenEBS 把"工作节点本地盘"统一管理，性能和 Ceph RBD 不相上下

下一步：K8s PVC 备份恢复：CSI Snapshot / Velero / rsync 三方案。

NFS 存储实战：单节点 + Keepalived 双机热备 + nfs-subdir 动态供给

Tue, 15 Nov 2016 00:00:00 +0800

为什么 NFS 在 K8s 时代还有用

很多人觉得 K8s 时代应该用 Rook-Ceph / Longhorn 这类"云原生存储"，NFS 是"老古董"。但实际上：

NFS 在 RWX 场景（多个 Pod 同时读写同一份数据）依然是最稳的
NFS + nfs-subdir-external-provisioner 是 K8s 动态 PV 的"最短路径"——5 分钟搞定一个 StorageClass
NFS + Keepalived + rsync 组成"穷人版"高可用，不需要 3 副本，单机故障 30 秒恢复
在国产化、私有化场景，NFS 是"无 Ceph 也能跑"的兜底方案

适用版本：NFS 4.1 / nfs-subdir-external-provisioner 4.0.18 / Ubuntu 22.04

1. 单节点 NFS 服务

1.1 安装服务端

1
2
3
4
5
6
7


apt install -y nfs-kernel-server

# 验证
systemctl is-enabled nfs-server
systemctl status nfs-server
cat /proc/fs/nfsd/versions
# +3 +4 +4.1 +4.2

1.2 共享目录

1
2
3
4
5
6
7


mkdir -p /home/nfs
chown -R nobody:nogroup /home/nfs
chmod 777 /home/nfs

mkdir -p /nfs
chown -R nobody:nogroup /nfs
chmod 777 /nfs

1.3 配置 /etc/exports

1
2


echo "/home/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
echo "/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports

参数解释：

*：所有网段可访问（生产应换成具体子网）
rw：读写
sync：同步写入内存和硬盘
no_root_squash：root 用户保留权限
no_subtree_check：不检查父目录权限

应用：

1
2
3
4


exportfs -a
systemctl restart nfs-server
exportfs -v
showmount -e

1.4 所有节点安装客户端

1
2
3
4


apt install -y nfs-common
showmount -e <nfs-server-ip>
# Export list for <nfs-server-ip>:
# /home/nfs *

1.5 客户端挂载测试

1
2
3


mount -t nfs <nfs-server-ip>:/home/nfs /mnt
df -h
umount /mnt

1.6 客户端常见挂不上

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 一些机器 mount 失败：mount.nfs: Connection timed out
# 解决：
mount -t nfs -o vers=3,nolock,proto=tcp <nfs-server-ip>:/nfs /mnt/nfs

# K8s 上修改 StorageClass
kubectl edit storageclass nfs-client

mountOptions:
 - vers=3
 - nolock
 - proto=tcp

2. K8s 中使用 NFS 存储

2.1 直接在 Pod 中引用 NFS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


apiVersion: apps/v1
kind: Deployment
metadata:
 name: redis
spec:
 selector:
 matchLabels:
 app: redis
 template:
 metadata:
 labels:
 app: redis
 spec:
 containers:
 - image: redis
 name: redis
 env:
 - name: ALLOW_EMPTY_PASSWORD
 value: "yes"
 volumeMounts:
 - name: redis-persistent-storage
 mountPath: /data
 volumes:
 - name: redis-persistent-storage
 nfs:
 path: /home/nfs
 server: <nfs-server-ip>

2.2 静态 PV + PVC

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: v1
kind: PersistentVolume
metadata:
 name: nfs-pv
 namespace: go
spec:
 capacity:
 storage: 2Gi
 volumeMode: Filesystem
 accessModes:
 - ReadWriteMany
 persistentVolumeReclaimPolicy: Recycle
 storageClassName: nfs
 mountOptions:
 - hard
 - nfsvers=4.1
 nfs:
 path: /nfs
 server: <nfs-server-ip>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nfs-pvc
 namespace: go
spec:
 storageClassName: nfs
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 2Gi

PV 卡在 Terminating 时的强删：

1

kubectl patch pv nfs-pv -p '{"metadata":{"finalizers":null}}' -n go

2.3 动态 StorageClass（推荐）

nfs-subdir-external-provisioner 是 NFS 动态供给的标配——它会监听 PVC 自动在 NFS 上创建子目录。

1
2
3
4


cd /data/softs
tar -xvf nfs-subdir-external-provisioner-4.0.18.tgz
mv nfs-subdir-external-provisioner /data/k8scnf/nfs/
cd /data/k8scnf/nfs/nfs-subdir-external-provisioner/

修改 values.yaml：

1
2
3
4


repository: registry.cn-shenzhen.aliyuncs.com/atomic/nfs-subdir-external-provisioner
nfs:
 server: <nfs-server-ip>
 path: /home/nfs

安装：

1
2


kubectl create namespace nfs
helm install nfs-subdir-external-provisioner . -n nfs

设置默认 StorageClass：

1

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

卸载：

1
2
3
4
5
6
7


helm uninstall nfs-subdir-external-provisioner -n nfs
kubectl delete namespace nfs
kubectl delete serviceaccount nfs-client-provisioner -n nfs
kubectl delete clusterrolebinding run-nfs-subdir-external-provisioner
kubectl delete role/leader-locking-nfs-subdir-external-provisioner -n nfs
kubectl delete rolebinding/leader-locking-nfs-subdir-external-provisioner -n nfs
kubectl delete storageclass nfs-client

2.4 测试动态 PV

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


cat << "EOF" > test-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-claim
 namespace: nfs
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Mi
 storageClassName: nfs-client
EOF

cat << "EOF" > test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 namespace: nfs
spec:
 containers:
 - name: test-pod
 image: busybox
 command: ["/bin/sh", "-c", "echo SUCCESS > /data/SUCCESS; sleep 3600"]
 volumeMounts:
 - name: nfs-pvc
 mountPath: /data
 volumes:
 - name: nfs-pvc
 persistentVolumeClaim:
 claimName: test-claim
 restartPolicy: Never
EOF

kubectl apply -f test-claim.yaml
kubectl apply -f test-pod.yaml

# 等 1 分钟后
ls /nfs/nfs-test-claim-pvc-*/
# 看到 SUCCESS 文件

kubectl delete -f test-pod.yaml
kubectl delete -f test-claim.yaml
# NFS 上的 pvc 目录自动清理

3. 双机热备 + rsync/lsyncd

3.1 架构

1
2
3
4
5
6
7


┌──────────────┐ keepalived ┌──────────────┐
│ worker4 │ ←── VRRP VIP ────→ │ worker2 │
│ nfs-server │ <10.x.x.x> │ nfs-server │
│ rsync 主 │ │ rsync 备 │
└──────────────┘ └──────────────┘
 ↓ ↓
 /nfs <──── lsyncd + rsync 实时同步 ────/nfs

3.2 两台机器都装 NFS + keepalived

两台机器都跑 NFS 服务（同一份数据），keepalived 决定哪个 IP 在线。

1
2
3
4
5
6
7
8


# 两台都执行
apt install -y nfs-kernel-server
mkdir -p /nfs
chown -R nobody:nogroup /nfs
chmod 777 /nfs
echo "/nfs *(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
exportfs -a
systemctl restart nfs-server

3.3 keepalived 配置（必须 nopreempt）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


vrrp_instance VI_1 {
 state BACKUP # 两台都是 BACKUP（vs master）
 interface enp3s0
 virtual_router_id 111
 priority 100 # worker4 设 100
 priority 80 # worker2 设 80
 advert_int 1
 nopreempt # **必须**：防止主备反复切换时数据丢失
 authentication { auth_type PASS; auth_pass 1111; }
 virtual_ipaddress { <nfs-vip>; }
}

健康检查脚本（nfs 挂了就把 keepalived 停掉，让 VIP 漂移）：

1
2
3
4
5
6
7
8
9


#!/bin/bash
A=`ps -C nfsd --no-header | wc -l`
if [ $A -eq 0 ]; then
 systemctl restart nfs-server.service
 sleep 2
 if [ `ps -C nfsd --no-header | wc -l` -eq 0 ]; then
 pkill keepalived
 fi
fi

NFS 双机热备的 nfs_check.sh 比 keepalived 自身的 chk_*.sh 更重要——必须让 NFS 挂了之后主动让出 VIP，否则客户端挂载会卡死。

3.4 rsync + lsyncd 实时同步

lsyncd 监听 inotify 事件触发 rsync 同步，是 Linux 文件实时同步的"标配"。

1
2


apt install -y rsync lsyncd
systemctl enable --now rsync lsyncd

内核参数优化（必做，否则 inotify 句柄不够）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


sysctl -w fs.inotify.max_queued_events="99999999"
sysctl -w fs.inotify.max_user_watches="99999999"
sysctl -w fs.inotify.max_user_instances="65535"

cat >> /etc/sysctl.conf << "EOF"
fs.inotify.max_queued_events=99999999
fs.inotify.max_user_watches=99999999
fs.inotify.max_user_instances=65535
EOF
sysctl -p

rsync 配置文件（/etc/rsyncd.conf）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsyncd.lock
[backup]
path = /nfs
comment = sync nfs from client
uid = root
gid = root
port = 873
ignore errors
use chroot = no
read only = no
list = no
max connections = 200
timeout = 600
auth users = root
secrets file = /etc/rsync.password
hosts allow = 10.0.0.0/8

密码文件：

1
2
3
4
5


echo 'root:{{NFS_RSYNC_PASSWORD}}' > /etc/rsync.password
chmod 600 /etc/rsync.password

echo "{{NFS_RSYNC_PASSWORD}}" > /etc/rsyncd.password
chmod 600 /etc/rsyncd.password

实际密码用占位符 {{NFS_RSYNC_PASSWORD}} 替代，原密码登记在 _drafts/私人笔记.md。

lsyncd 配置（worker4 把 /nfs 推到 worker2）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


settings {
 logfile = "/var/log/lsyncd/lsyncd.log",
 statusFile = "/var/log/lsyncd/lsyncd.status",
 inotifyMode = "CloseWrite",
 maxProcesses = 8,
}
sync {
 default.rsync,
 source = "/nfs",
 target = "root@<worker2-ip>::backup",
 delete = true,
 delay = 1,
 exclude = {".*"},
 rsync = {
 binary = "/usr/bin/rsync",
 archive = true,
 compress = false,
 verbose = true,
 password_file = "/etc/rsyncd.password",
 _extra = {"--bwlimit=20000"}
 }
}

worker2 的配置对称——把 target 指向 worker4。

3.5 验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 在 worker4 上
mount -t nfs <nfs-vip>:/nfs /mnt
cd /mnt
echo "test" > test.txt
cd ../
umount /mnt

# 在 worker2 上
ls /nfs
# 应该能看到 test.txt

3.6 模拟故障

停 worker4 keepalived → VIP 飘到 worker2
启 worker4 keepalived（nopreempt 不会让 VIP 回来）
停 worker2 keepalived → VIP 飘回 worker4
内网其他机器 ping VIP 一直是通的

4. Ingress 持久化日志

Ingress-nginx 容器本身是无状态的，access log 默认写到 stdout（容器内）。生产场景希望 log 落盘到 NFS，方便 ELK / Loki 采集。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


cat << "EOF" > /data/k8scnf/ingress-nginx/ingress-nfs.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: ingress-nfs
 namespace: ingress-nginx
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 10Gi
 storageClassName: nfs-client
EOF

kubectl apply -f /data/k8scnf/ingress-nginx/ingress-nfs.yaml

修改 ingress-nginx-controller：

1

kubectl edit -n ingress-nginx DaemonSet/ingress-nginx-controller

1
2
3
4
5
6
7


volumeMounts:
 - mountPath: /var/log/nginx/
 name: ingress-nfs
volumes:
 - name: ingress-nfs
 persistentVolumeClaim:
 claimName: ingress-nfs

修改 ConfigMap 改变日志格式：

1

kubectl edit -n ingress-nginx configmaps/ingress-nginx-controller

NFS 上自动创建 default-ingress-nfs-pvc-xxx/ 目录，所有 ingress-controller Pod 的 access log 都会落在这里。

单点故障注意：NFS 本身是单点，NFS 挂了 ingress 日志会卡。生产建议加 keepalived VIP（本文方案）。

5. 排错

现象	原因	解决
`mount.nfs: Connection timed out`	防火墙	放通 2049/111/20048
`mount.nfs: Operation not permitted`	NFS 版本不匹配	加 `-o vers=3,nolock,proto=tcp`
PVC 一直 Pending	节点没装 nfs-common	所有节点 `apt install nfs-common`
nfs-subdir 装不上	helm chart 镜像拉不到	改国内源 + push 私有 harbor
双机热备 VIP 频繁漂移	没设 nopreempt	keepalived.conf 加 `nopreempt`
lsyncd 同步延迟大	inotify 句柄不够	调 `fs.inotify.*` 参数

6. 2024 NFS 现状

本文 2016 年写时 NFS 还是 K8s 动态存储的"穷人首选"。8 年后（2024）回望，NFS 协议本身有了 NFS 4.2、pNFS 等增强，但更重要的是生态位发生了变化——长虹、Ceph/Longhorn/OpenEBS 等云原生存储在 K8s 场景蚕食了 NFS 的份额。下面是当前状态。

6.1 NFS 协议本身：4.2 与 pNFS

NFS 版本	发布时间	关键特性	2024 现状
NFSv3	1995	异步写、TCP 支持	老系统兼容仍用
NFSv4.0	2003	状态化、复合操作、Kerberos	Linux 默认
NFSv4.1	2010	pNFS（并行 NFS）、会话	主流
NFSv4.2	2016	服务器端复制、稀疏文件、空间预留、应用数据块（ADBs）	2024 标配

pNFS 的核心思想：把元数据和数据通道分离——元数据服务器只管 layout，客户端直接和多个存储节点传输数据，理论上能做到并行带宽聚合（类似 CephFS 的 striping）。

1
2
3


# 挂载 pNFS（需要服务端支持）
mount -t nfs -o nfsvers=4.1,minorversion=1 <server>:/export /mnt
# 或 nfsvers=4.2 启用 4.2 特性

实际部署率：pNFS 在企业存储（NetApp / Dell EMC Isilon / IBM Spectrum Scale）早就支持，但Linux 内核的 pNFS client 直到 5.x 才稳定，很多 K8s 节点跑的还是 NFSv3/4.1 而不是 pNFS。

6.2 nfs-subdir-external-provisioner 现状

版本	时间	状态
v3.x	2019-2021	旧 API，CSI 转换中
v4.0.x	2022-2023	当时主流
v4.0.18+	2023-2024	当前推荐
v4.0.20+	2024	k8s 1.28+ 兼容

v4.x 关键变化：

完全重写为 CSI（Container Storage Interface） 驱动
支持 Kubernetes 1.25+（旧的 in-tree NFS provisioner 已废弃）
Helm chart 改为标准 oci:// 仓库：

1
2
3
4
5
6


# 2024 推荐装法（Helm 3.8+）
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
 --set nfs.server=<nfs-server-ip> \
 --set nfs.path=/home/nfs \
 -n nfs-client --create-namespace

6.3 2024 替代方案对比

方案	类型	适用场景	复杂度	性能	HA
NFS + nfs-subdir	文件（RWX）	中小规模、传统业务	低	中	需 keepalived 自建
Longhorn	块（RWX via NFS）	K8s 云原生首选	中	中	内置
Rook-Ceph	块/文件/对象	大规模、混合负载	高	高	内置（多副本）
OpenEBS	块/文件	国产化、CSI 友好	中	中	可选
CubeFS	文件/对象/块	国产云原生	中	高	内置
Vitess / TiDB	数据库专用	持久化数据库	高	高	内置
Local Path / HostPath	本地盘	单节点 / StatefulSet	低	最高	无
AWS EBS / GCP PD	云盘	云上	低	高	内置
NFS CSI driver for K8s	NFS 官方版	NFS 4.1+	低	中	自建

6.4 2024 选型建议

业务场景	推荐
CI/CD 临时构建、多 Pod 共享配置	NFS + nfs-subdir 仍最优（RWX 简单）
生产数据库（MySQL / PG / Redis）	云盘 / Rook-Ceph RBD / 本地盘（RWO 性能）
AI / 大数据	CephFS / Lustre / JuiceFS（高带宽）
国产化	CubeFS / 浪潮 AS13000
小团队 + 简单	Longhorn（一键装、UI 友好）
私有化 + 信创	NFS + nfs-subdir（Linux 原生 + 国产 OS 兼容）

6.5 实战：Longhorn 一键装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


# Longhorn 是 Rancher 出品的云原生块存储
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.4/deploy/longhorn.yaml

# 默认 StorageClass
kubectl get sc longhorn

# 创建一个 StatefulSet 用 Longhorn
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: pg
spec:
 serviceName: pg
 replicas: 1
 selector:
 matchLabels: { app: pg }
 template:
 metadata:
 labels: { app: pg }
 spec:
 containers:
 - name: pg
 image: postgres:16
 volumeMounts:
 - name: data
 mountPath: /var/lib/postgresql/data
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 storageClassName: longhorn
 resources:
 requests:
 storage: 10Gi
EOF

Longhorn 自动做 3 副本 + 跨节点同步 + 在线扩容 + 备份——NFS 的 keepalived + rsync 全套都不用做。

6.6 NFS 2024 仍然"有用"的场景

虽然新项目优先选 Longhorn/Ceph，但以下场景 NFS 仍是最佳选择：

跨 namespace / 跨集群共享数据（Longhorn 默认单集群）
Windows + Linux 混合客户端（NFS 协议通用性强）
AI 训练把数据集放在 NFS，多个训练 Pod 同时读（RWX）
传统业务——银行 ERP、政府办公系统（必须 NFS、SMB 协议）
国产化 / 信创项目（NFS 是 Linux 内核自带，不依赖任何商业软件）

6.7 一句话总结

2016 年的 NFS 4.1 + nfs-subdir + keepalived 方案在 2024 仍然能跑——但新项目建议直接用 Longhorn（块 + 简单）或 Ceph（大规模 + 混合）。

NFS 不是"过时"了，而是从默认选择退到备选——看场景用。

7. 小结

NFS 在 K8s 存储选型中仍然有一席之地：

动态 StorageClass（nfs-subdir）让 NFS 用法跟云盘一样简单
keepalived + rsync + lsyncd 组成"穷人版"高可用
NFS 单点风险依然存在，关键业务建议 Ceph / Longhorn
2024 新选择：Longhorn（首选）/ Rook-Ceph（大规模）/ 国产 CubeFS（信创）

下一步：Rook-Ceph 1.17 分布式存储：块存储 RBD + CephFS + OSD/MON。 2024 推荐：先看 Longhorn 官方文档（一键装，3 副本 + 备份），再做 Ceph。

K8s on Liangweidong's blog

双机房双集群架构：Redis Cluster 6 节点 + 多服务同步

双机房双集群是什么

1. 整体架构

2. Redis Cluster 6 节点跨机房

2.1 为什么是 6 节点

2.2 节点规划

2.3 镜像准备

2.4 6 个节点的 redis.conf

2.5 6 个节点的 docker run

2.6 创建集群

2.7 验证

2.8 Spring Boot 客户端配置

2.9 单 db0 的坑

3. nacos 双活

4. MySQL 双主架构

4.1 双主互相同步

4.2 主从单向同步

4.3 多租户 MySQL 部署

5. EMQX MQTT 集群

5.1 客户端配置

5.2 客户端连接示例

6. nginxwebui 负载均衡

7. 防火墙映射

8. 同步策略

9. VIP 与 keepalived 跨机房

10. 排错

11. 小结

Loki + Promtail 日志体系：helm 部署 + yaml 自定义 + 排错

K8s 日志采集的 3 种方式

1. Loki 架构

2. helm 部署（推荐）

2.1 添加仓库

2.2 备份默认 values

2.3 修改 values-prod.yaml

2.4 处理冲突 RBAC

2.5 部署

2.6 验证

3. 私有 yaml 部署（更可控）

3.1 准备镜像

3.2 完整 yaml

3.3 部署

4. Promtail 部署

4.1 ConfigMap

4.2 DaemonSet + RBAC

5. 验证与查询

5.1 Loki 健康

5.2 Grafana 配置 Loki 数据源

5.3 查日志

6. 常见问题

6.1 loki-0 1/2 CrashLoopBackOff

6.2 no such file or directory: /var/log/pods/...

6.3 Promtail 一直 Buffer filling up

6.4 日志保留时间太短

6.5 helm 部署 RBAC 冲突

7. 小结

Istio 1.20 服务网格：bookinfo + Kiali/Grafana 面板

Istio 是 K8s 上的"服务网格"标准

1. 9 个内置 Profile

2. 安装 Istio

2.1 下载

2.2 复制 istioctl

2.3 安装 demo profile

2.4 给 namespace 打自动注入标签

2.5 验证

3. 部署 bookinfo 示例

3.1 验证应用启动

3.2 创建 Gateway

3.3 访问入口

4. 安装 Dashboard

4.1 Kiali 面板

4.2 Grafana 面板

4.3 触发流量看面板

5. 灰度发布：把 reviews 全部切到 v3

5.1 按用户灰度

6. 常见问题

6.1 unable to proxy Istiod pods. Make sure your Kubernetes API server has access to the Istio control plane through 8080 port

6.2 grafana URL is not set in Kiali configuration

6.3 loki-0 1/2 CrashLoopBackOff

6.4 Pod 没自动注入 envoy

6.1 `loki-0 1/2 CrashLoopBackOff`

6.2 `no such file or directory: /var/log/pods/...`

6.1 `unable to proxy Istiod pods. Make sure your Kubernetes API server has access to the Istio control plane through 8080 port`

6.2 `grafana URL is not set in Kiali configuration`

6.3 `loki-0 1/2 CrashLoopBackOff`

3.2 kubelet 启动报 `kubelet.go:2286] "Error updating node status"`

3.3 `kubelet: failed to create kubelet: cgroup driver "cgroupfs" is different from docker "systemd"`

3.4 `kubelet: failed to start ContainerManager ... cgroup ... not found`

3.5 `kubelet.go:1380] "Failed to start cAdvisor" ... Failed to get cgroup stats`

3.6 `kubelet: node "<name>" not found`