田小晖的博客

FRP v0.68.0 内网穿透完整教程

Tue, 04 Aug 2026 00:00:00 GMT

Nginx 反代模式 | 域名 aaa.example.com | Linux服务器 + Windows内网80端口#

文档版本：v1.0 | 适用 FRP 版本：v0.68.0 | 更新日期：2026-07-31

一、整体架构说明#

1
用户浏览器
2
    ↓ 80/443端口
3
Linux服务器 Nginx (反向代理)
4
    ↓ 内部转发 127.0.0.1:8080
5
Linux服务器 frps (vhostHTTPPort=8080, bindPort=7000)
6
    ↓ 7000端口通信
7
Windows内网 frpc
8
    ↓
9
Windows 本地 80 端口 Web 服务

关键特点：

frps 的 vhostHTTPPort 使用内部端口 8080，80 端口留给 Nginx
frps 的 vhostHTTPPort 只监听 127.0.0.1，无需对外防火墙放行 8080
Nginx 监听 80/443，负责转发请求到 frps 内部端口 + SSL 终止
防火墙只需放行：7000（frpc连接）、80/443（Nginx）

二、下载 FRP#

下载地址#

GitHub Release 页面：https://github.com/fatedier/frp/releases

下载包选择#

机器	系统	下载包
公网服务器	Linux 64位 (x86_64/amd64)	`frp_0.68.0_linux_amd64.tar.gz`
内网机器	Windows 64位	`frp_0.68.0_windows_amd64.zip`

同一个压缩包里同时包含 frps（服务端）和 frpc（客户端）。

三、Linux 公网服务器端配置#

步骤 1：上传并解压 FRP#

Terminal window

1
# 上传 frp_0.68.0_linux_amd64.tar.gz 到服务器后执行
2
cd /usr/local
3
tar -zxvf frp_0.68.0_linux_amd64.tar.gz
4
mv frp_0.68.0_linux_amd64 frp
5
cd frp

步骤 2：编写 frps.toml 配置文件#

⚠️ 注意：FRP v0.68.0 推荐使用 TOML/YAML/JSON 格式，旧版 INI 已不再推荐！

创建配置文件：

Terminal window

1
vim /usr/local/frp/frps.toml

写入以下完整可用配置：

1
# ==========================================
2
# FRP 服务端配置 frps.toml (v0.68.0)
3
# Nginx 反代模式：vhostHTTPPort 内部使用 8080
4
# ==========================================
5

6
# ---------- 基础连接配置 ----------
7
# frpc 连接的监听地址（需要对外，所以 0.0.0.0）
8
bindAddr = "0.0.0.0"
9
# frpc 连接 frps 的端口（客户端配置与此一致）
10
bindPort = 7000
11

12
# ---------- HTTP 虚拟主机端口（Nginx 反代模式关键配置） ----------
13
# 代理监听地址：只允许本地回环访问，禁止外部直连 8080
14
proxyBindAddr = "127.0.0.1"
15
# HTTP 类型代理监听端口（Nginx 会把请求转发到此端口）
16
vhostHTTPPort = 8080
17
# HTTP ResponseHeader 超时时间（秒）
18
vhostHTTPTimeout = 60
19

20
# 如果后续需要 HTTPS 代理（Nginx 不做 SSL 终止场景），取消下行注释
21
# vhostHTTPSPort = 8443
22

23
# ---------- 鉴权配置（必须开启！） ----------
24
[auth]
25
# 鉴权方式：token 或 oidc，默认 token
26
method = "token"
27
# 附加鉴权范围（可选）：HeartBeats, NewWorkConns
28
# additionalScopes = ["HeartBeats", "NewWorkConns"]
29
# ⚠️ 令牌（必须替换为复杂随机字符串，客户端必须设置相同的值）
30
token = "123456"
31

32
# ---------- 控制台 / Dashboard 配置 ----------
33
# ⚠️ 要直接通过 IP:7500 外网访问：addr 改成 "0.0.0.0"
34
# ⚠️ 只通过 Nginx 反代访问：保持 "127.0.0.1"
35
[webServer]
36
addr = "0.0.0.0"
37
port = 7500
38
user = "admin"
39
password = "123456"
40

41
# 是否提供 Prometheus 监控接口（需要 webServer 启用）
42
# enablePrometheus = true
43

44
# ---------- 日志配置 ----------
45
[log]
46
# 日志文件路径，console 表示输出到终端
47
to = "./frps.log"
48
# 日志级别：trace, debug, info, warn, error
49
level = "info"
50
# 日志保留天数
51
maxDays = 7
52
# 禁用日志颜色（写文件时建议禁用）
53
# disablePrintColor = false
54

55
# ---------- 传输层配置（可选优化） ----------
56
[transport]
57
# 允许客户端设置的最大连接池大小
58
maxPoolCount = 5
59
# 心跳连接超时时间（秒）
60
heartbeatTimeout = 90
61
# 底层 TCP keepalive 间隔（秒），负数表示不启用
62
tcpKeepalive = 30
63
# TCP Multiplex 心跳检查间隔（秒）
64
# tcpMuxKeepaliveInterval = 60
65

66
# ---------- 其他服务端限制（可选） ----------
67
# 服务端返回详细错误信息给客户端
68
# detailedErrorsToClient = true
69
# 限制单个客户端最大同时存在的代理数，0 表示无限制
70
# maxPortsPerClient = 0
71
# 用户建立连接后等待客户端响应的超时时间（秒）
72
# userConnTimeout = 10

展开收起

步骤 3：防火墙端口放行#

需要对外放行的端口：

端口	协议	来源	用途
7000	TCP	0.0.0.0/0	frpc → frps 通信端口
80	TCP	0.0.0.0/0	Nginx HTTP 访问
443	TCP	0.0.0.0/0	Nginx HTTPS 访问（如需）
7500	TCP	0.0.0.0/0	Dashboard 直接访问（addr=0.0.0.0 时需要）

不需要放行的端口：8080（只监听本地回环）

CentOS / RHEL (firewalld)#

Terminal window

1
firewall-cmd --permanent --add-port=7000/tcp
2
firewall-cmd --permanent --add-port=80/tcp
3
firewall-cmd --permanent --add-port=443/tcp
4
firewall-cmd --permanent --add-port=7500/tcp
5
firewall-cmd --reload
6
# 验证
7
firewall-cmd --list-ports

Ubuntu / Debian (ufw)#

Terminal window

1
ufw allow 7000/tcp
2
ufw allow 80/tcp
3
ufw allow 443/tcp
4
ufw allow 7500/tcp
5
ufw reload
6
# 验证
7
ufw status

使用 iptables#

Terminal window

1
iptables -I INPUT -p tcp --dport 7000 -j ACCEPT
2
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
3
iptables -I INPUT -p tcp --dport 443 -j ACCEPT
4
iptables -I INPUT -p tcp --dport 7500 -j ACCEPT
5
service iptables save

⚠️ 云服务器必须操作：阿里云/腾讯云/华为云/AWS 等还需要在云控制台安全组里放行上述入方向端口！

步骤 4：前台启动测试（必须先做！）#

Terminal window

1
cd /usr/local/frp
2
./frps -c ./frps.toml

成功标志（参考输出）：

1
2026/07/31 12:00:00 [I] [root.go:xxx] frps started successfully
2
2026/07/31 12:00:00 [I] [webserver.go:xxx] Dashboard listen on 0.0.0.0:7500

确认无误后，按 Ctrl + C 停止。

步骤 5：配置 systemd 服务（后台运行 + 开机自启）#

创建 systemd 服务文件：

Terminal window

1
vim /etc/systemd/system/frps.service

写入内容：

1
[Unit]
2
Description = FRP Server (Nginx Proxy Mode for aaa.example.com)
3
After = network.target syslog.target network-online.target
4
Wants = network.target network-online.target
5

6
[Service]
7
Type = simple
8
# 工作目录
9
WorkingDirectory = /usr/local/frp
10
# 启动命令（必须使用绝对路径）
11
ExecStart = /usr/local/frp/frps -c /usr/local/frp/frps.toml
12
# 异常自动重启策略
13
Restart = always
14
# 重启间隔（秒）
15
RestartSec = 5s
16
# 启动超时
17
TimeoutStartSec = 30s
18

19
[Install]
20
WantedBy = multi-user.target

展开收起

加载配置并启动：

Terminal window

1
# 重新加载 systemd 单元文件
2
systemctl daemon-reload
3

4
# 启动 frps 服务
5
systemctl start frps
6

7
# 设置开机自启
8
systemctl enable frps
9

10
# 查看运行状态（active (running) 表示正常）
11
systemctl status frps

查看日志：

Terminal window

1
# 实时查看 systemd 日志
2
journalctl -u frps -f
3

4
# 查看最近 100 行 frps 自身日志
5
tail -n 100 /usr/local/frp/frps.log
6

7
# 实时查看 frps 自身日志
8
tail -f /usr/local/frp/frps.log

步骤 6：配置 Nginx 反向代理（核心步骤）#

找到 Nginx 配置目录（通常是以下其中之一）：

/etc/nginx/conf.d/ ← CentOS 常见
/etc/nginx/sites-available/ + /etc/nginx/sites-enabled/ ← Debian/Ubuntu 常见

新建 FRP 专属配置文件：

Terminal window

1
vim /etc/nginx/conf.d/aaa.example.com.conf

写入以下完整配置（含 HTTP 反代 + Dashboard 反代 + 标准优化头）：

aaa.example.com展开收起

1
# ==========================================
2
# Nginx 反向代理 FRP 配置
3
# 后端: frps vhostHTTPPort = 127.0.0.1:8080
4
# ==========================================
5

6
# ---------- 主站点：HTTP 80 → frps:8080 ----------
7
server {
8
    listen 80;
9
    listen [::]:80;
10

11
    # ⚠️ 必须与 frpc 中 customDomains 完全一致
12
    server_name aaa.example.com;
13

14
    # 日志
15
    access_log  /var/log/nginx/aaa.example.com.access.log  main;
16
    error_log   /var/log/nginx/aaa.example.com.error.log   warn;
17

18
    # 大文件上传支持（按需调整，比如部署网盘时调大）
19
    client_max_body_size 1024m;
20

21
    # ---------- 核心反代配置 ----------
22
    location / {
23
        # ⚠️ 转发到 frps 的 vhostHTTPPort（必须与 frps.toml 一致）
24
        proxy_pass http://127.0.0.1:8080;
25

26
        # ========================================
27
        # ⚠️ 极其重要：必须正确转发 Host 头！
28
        # frps 依赖 Host 字段区分不同域名的代理，
29
        # 缺失或错误会直接导致 404 Not Found
30
        # ========================================
31
        proxy_set_header Host $host;
32

33
        # ---------- 真实客户端 IP 相关头 ----------
34
        proxy_set_header X-Real-IP $remote_addr;
35
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
36
        proxy_set_header X-Forwarded-Proto $scheme;
37
        proxy_set_header X-Forwarded-Host $host;
38
        proxy_set_header X-Forwarded-Port $server_port;
39

40
        # ---------- WebSocket 支持（长连接场景必需） ----------
41
        proxy_http_version 1.1;
42
        proxy_set_header Upgrade $http_upgrade;
43
        proxy_set_header Connection "upgrade";
44

45
        # ---------- 超时设置 ----------
46
        proxy_connect_timeout 60s;
47
        proxy_send_timeout 300s;
48
        proxy_read_timeout 300s;
49
        send_timeout 300s;
50

51
        # ---------- 其他优化 ----------
52
        proxy_buffering off;
53
        proxy_request_buffering off;
54
        proxy_redirect off;
55
    }
56
}

展开收起

可选 - 启用 HTTPS（强烈推荐生产环境使用）：

申请完 SSL 证书后，在上面的 server 块基础上增加或改为：

1
# ---------- HTTP → HTTPS 强制跳转 ----------
2
server {
3
    listen 80;
4
    listen [::]:80;
5
    server_name aaa.example.com;
6
    return 301 https://$host$request_uri;
7
}
8

9
# ---------- HTTPS 443 主站点 ----------
10
server {
11
    listen 443 ssl http2;
12
    listen [::]:443 ssl http2;
13
    server_name aaa.example.com;
14

15
    # SSL 证书路径（根据实际路径修改）
16
    ssl_certificate     /etc/letsencrypt/live/aaa.example.com/fullchain.pem;
17
    ssl_certificate_key /etc/letsencrypt/live/aaa.example.com/privkey.pem;
18

19
    # SSL 安全配置
20
    ssl_protocols TLSv1.2 TLSv1.3;
21
    ssl_ciphers HIGH:!aNULL:!MD5;
22
    ssl_prefer_server_ciphers on;
23
    ssl_session_cache shared:SSL:10m;
24
    ssl_session_timeout 10m;
25

26
    # HSTS（可选，仅全站 HTTPS 时开启）
27
    # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
28

29
    # 其他 location 配置（反代、Dashboard 等同上，保持不变）
30
    access_log  /var/log/nginx/aaa.example.com.access.log  main;
31
    error_log   /var/log/nginx/aaa.example.com.error.log   warn;
32
    client_max_body_size 1024m;
33

34
    location / {
35
        proxy_pass http://127.0.0.1:8080;
36
        proxy_set_header Host $host;
37
        proxy_set_header X-Real-IP $remote_addr;
38
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
39
        proxy_set_header X-Forwarded-Proto $scheme;
40
        proxy_set_header X-Forwarded-Host $host;
41
        proxy_set_header X-Forwarded-Port $server_port;
42
        proxy_http_version 1.1;
43
        proxy_set_header Upgrade $http_upgrade;
44
        proxy_set_header Connection "upgrade";
45
        proxy_connect_timeout 60s;
46
        proxy_send_timeout 300s;
47
        proxy_read_timeout 300s;
48
        proxy_buffering off;
49
    }
50
}

展开收起

步骤 7：验证并重载 Nginx#

Terminal window展开收起

1
# 1. 检查 Nginx 配置语法（必须通过，否则不要重载！）
2
nginx -t
3

4
# 预期输出：
5
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
6
# nginx: configuration file /etc/nginx/nginx.conf test is successful
7

8
# 2. 语法 OK 后重载（不中断现有连接）
9
nginx -s reload
10
# 或者
11
systemctl reload nginx
12

13
# 3. 确认 Nginx 正在监听 80
14
ss -tlnp | grep -E ':(80|443)'
15
# 或
16
netstat -tlnp | grep nginx

展开收起

步骤 8：配置 DNS 域名解析#

登录你的域名 DNS 管理后台（阿里云万网 / 腾讯云 DNSPod / Cloudflare / 华为云等），添加如下解析记录：

记录类型	主机记录	记录值	TTL	备注
A 记录	`aaa`	`你的公网服务器IP地址`	600 或默认	必配，子域名
A 记录	`@`	`你的公网服务器IP地址`	600 或默认	可选，根域名也想用时配

DNS 生效验证（本机 CMD / PowerShell / Linux Shell）：

Terminal window

1
# Windows
2
nslookup aaa.example.com
3
# 或 Linux / macOS
4
dig aaa.example.com +short
5
# 或通用
6
ping aaa.example.com

返回值等于你的服务器公网 IP 即解析成功。

⚠️ 如果使用 Cloudflare 等 CDN：测试阶段请先切换到「仅 DNS (DNS only)」模式，确认穿透成功后再开启 CDN 代理（橙色云）。

四、Windows 内网客户端配置#

步骤 1：解压并准备目录#

将下载的 frp_0.68.0_windows_amd64.zip 解压
移动到固定目录（避免误删），建议：
```
1
C:\Program Files\frp\
```

最终目录结构：

1
C:\Program Files\frp\
2
├── frpc.exe              ← 客户端程序
3
├── frpc.toml             ← 客户端配置（下一步创建）
4
├── frpc_full.toml        ← 完整配置参考（解压自带，按需查阅）
5
├── frpc.toml             ← 我们自己创建的最简生产配置
6
├── frps.exe              ← Windows 上用不到，可删除
7
└── frps_full.toml        ← 服务端完整参考，可删除

步骤 2：编写 frpc.toml 客户端配置文件#

在 C:\Program Files\frp\ 目录下新建文本文件，改名为 frpc.toml（注意扩展名是 .toml 不是 .txt），写入以下内容：

1
# ==========================================
2
# FRP 客户端配置 frpc.toml (v0.68.0)
3
# 场景：穿透 Windows 本地 80 端口 Web 服务
4
# 域名：aaa.example.com
5
# ==========================================
6

7
# ---------- 连接服务端配置 ----------
8
# ⚠️ 替换为你的公网服务器公网 IP 地址
9
serverAddr = "123.123.123.123"
10
# frps 的 bindPort（必须与服务端 frps.toml 的 bindPort 一致）
11
serverPort = 7000
12

13
# 第一次连接失败是否立即退出（true 方便调试，生产建议 false + 重连）
14
loginFailExit = false
15

16
# ---------- 鉴权配置（⚠️ 必须与服务端 frps.toml 完全一致！） ----------
17
[auth]
18
method = "token"
19
token = "123456"
20
# additionalScopes = ["HeartBeats", "NewWorkConns"]  # 服务端开启了这里也要开
21

22
# ---------- 客户端 Admin WebServer（可选，本地管理面板） ----------
23
# 浏览器访问：http://127.0.0.1:7400
24
[webServer]
25
addr = "127.0.0.1"
26
port = 7400
27
user = "admin"
28
password = "123456"
29

30
# ---------- 日志配置 ----------
31
[log]
32
to = "./frpc.log"
33
level = "info"
34
maxDays = 7
35
# disablePrintColor = false
36

37
# ---------- 传输层配置（可选优化） ----------
38
[transport]
39
# 通信协议：tcp, kcp, quic, websocket, wss（Nginx 反代场景用 tcp 即可）
40
protocol = "tcp"
41
# 连接服务端超时（秒）
42
dialServerTimeout = 10
43
# 底层 TCP keepalive（秒）
44
dialServerKeepalive = 30
45
# 连接池大小（与服务端 maxPoolCount 协调）
46
poolCount = 1
47
# TCP Multiplex（默认启用）
48
tcpMux = true
49
# 心跳包间隔（秒），tcpMux 启用后可设为 -1
50
heartbeatInterval = 30
51
# 心跳超时（秒）
52
heartbeatTimeout = 90
53

54
# TLS 连接（v0.68.0 默认启用，提高通信安全性）
55
[transport.tls]
56
enable = true
57

58
# ---------- 其他客户端配置 ----------
59
# 可选：附加元数据（服务端插件用）
60
# [metadatas]
61
# location = "office-shanghai"
62
# device = "windows-pc-01"
63

64
# ==========================================
65
# 代理配置：穿透本地 80 端口的 Web 服务
66
# ==========================================
67
[[proxies]]
68
# 代理名称（唯一，可自定义，服务端 Dashboard 中显示）
69
name = "web-80"
70
# 代理类型：http（域名复用、虚拟主机支持）
71
type = "http"
72
# 是否启用该代理（默认 true，false 可临时禁用不删除配置）
73
# enabled = true
74
# 被代理的本地服务 IP（本机就是 127.0.0.1；要代理局域网其他机器填对应 IP）
75
localIP = "127.0.0.1"
76
# 被代理的本地服务端口（Windows 上跑的 Web 端口）
77
localPort = 80
78

79
# ---------- HTTP 代理域名配置（必须与 Nginx server_name 一致！） ----------
80
customDomains = ["aaa.example.com"]
81

82
# 可选：通过子路径路由（例如只代理 /api/*）
83
# locations = ["/"]
84

85
# 可选：给穿透的网站加 HTTP Basic Auth 访问密码
86
# httpUser = "website-viewer"
87
# httpPassword = "Viewer@Pass2026"
88

89
# 可选：修改转发给后端的 Host Header（默认是 $host，按需改）
90
# hostHeaderRewrite = "internal.dev.local"
91

92
# 可选：请求/响应 Header 操作
93
# [proxies.requestHeaders]
94
# set = { "X-From-Frp" = "true", "X-Frp-User" = "admin" }
95
# [proxies.responseHeaders]
96
# set = { "X-Proxy" = "frp-v0.68.0" }
97

98
# ---------- 传输加密与压缩（推荐开启） ----------
99
[proxies.transport]
100
# 压缩传输内容（文本类资源效果显著，二进制图片/视频效果一般）
101
useCompression = true
102
# 额外加密（已启用全局 TLS 时可不开，双重加密略吃 CPU 但更安全）
103
useEncryption = true
104
# 可选：带宽限流（例如限制 10MB/s，防止内网带宽被占满）
105
# bandwidthLimit = "10MB"
106
# bandwidthLimitMode = "client"  # client 或 server
107

108
# ---------- 健康检查（可选，推荐开启） ----------
109
# 本地服务异常时自动下线，恢复后自动上线
110
# [proxies.healthCheck]
111
# # 检查类型：tcp 或 http
112
# type = "http"
113
# # http 类型必填：健康检查的 PATH
114
# path = "/"
115
# # 检查间隔（秒）
116
# intervalSeconds = 15
117
# # 单次超时（秒）
118
# timeoutSeconds = 5
119
# # 连续失败多少次判定不健康
120
# maxFailed = 3
121

122
# ==========================================
123
# 扩展：如果还想穿透其他端口/服务，可以继续加 [[proxies]]
124
# 示例：穿透 Windows 远程桌面 3389（TCP 类型）
125
# ==========================================
126
# [[proxies]]
127
# name = "windows-rdp-3389"
128
# type = "tcp"
129
# localIP = "127.0.0.1"
130
# localPort = 3389
131
# remotePort = 13389   # 服务端对外开放的端口（防火墙放行 13389）
132
# 然后在另一台电脑 mstsc 连接：服务器IP:13389

展开收起

步骤 3：确认本地 80 端口服务正常#

极其重要：先确保 Windows 本机浏览器能访问到 Web 服务。

在本机浏览器打开：http://127.0.0.1 或 http://localhost
确认能看到你的网站内容
如果打不开 → 穿透出去一定也打不开，请先解决本地服务问题

本机端口检查命令（PowerShell）：

Terminal window

1
# 查看 80 端口被哪个进程占用
2
netstat -ano | findstr :80
3

4
# 测试 80 端口连通性
5
Test-NetConnection 127.0.0.1 -Port 80
6
# TcpTestSucceeded : True 才是正常
7

8
# 查看 PID 对应的程序名
9
tasklist | findstr <上面查到的PID号>

步骤 4：前台启动 frpc 测试（必须先做！）#

以管理员身份打开 PowerShell 或 CMD：

Terminal window

1
# 进入 frp 目录
2
cd "C:\Program Files\frp"
3

4
# 前台启动（测试阶段推荐，可以直接看到错误）
5
.\frpc.exe -c .\frpc.toml

成功标志（参考输出）：

1
2026/07/31 12:00:00 [I] [service.go:xxx] [abc123xyz] login to server success, get run id [abc123xyz]
2
2026/07/31 12:00:00 [I] [proxy_manager.go:xxx] [abc123xyz] proxy added: [web-80]
3
2026/07/31 12:00:00 [I] [control.go:xxx] [abc123xyz] [web-80] start proxy success

出现上述三行即表示客户端与服务端连接成功 + 代理注册成功！

常见错误与处理：

错误信息	原因	解决方案
`dial tcp x.x.x.x:7000: connect: connection timed out`	7000 端口不通	① 云服务器安全组放行 TCP 7000 ② 服务器防火墙放行 7000 ③ 确认 serverAddr 是公网 IP
`authentication failed`	token 不一致	逐字检查 frps.toml 和 frpc.toml 的 `token` 是否完全相同（注意空格、大小写）
`login to server failed: no response from server`	协议不匹配	检查 `transport.protocol` 是否是 tcp（一般不用改）
`dial tcp 127.0.0.1:80: connectex: No connection could be made`	本地 80 端口没服务	先在本机浏览器打开 `http://127.0.0.1` 确认服务起来了
`proxy conflict: proxy name [xxx] already exists`	代理名重复	修改 `name = "web-80"` 换个唯一名称

步骤 5：外网访问验证测试#

用手机开 4G/5G 流量（确保不在同一局域网 / 同一 Wi-Fi 下），浏览器访问：

1
http://aaa.example.com

成功标志：看到你 Windows 本机 80 端口部署的网站内容 🎉

可选同时验证：

FRP Dashboard：http://你的服务器IP:7500 或 http://aaa.example.com/_frp_dashboard/
登录用 frps.toml 配置的用户名密码（默认 admin / 123456）
在 Dashboard 里可以看到：在线客户端数、已注册代理、流量统计、连接数等

💡 如果 Dashboard 进不去，检查：

webServer.addr 是否改为 0.0.0.0（直接访问场景）

云安全组 + 防火墙是否放行 7500

systemctl status frps 确认服务在跑

ss -tlnp | grep 7500 确认监听正常

grep -i dashboard /usr/local/frp/frps.log 看启动日志

步骤 6：配置 Windows 系统服务（开机自启 + 后台运行）#

前台测试通过后，必须配置成系统服务，否则关闭 CMD 窗口 frpc 就停了。推荐使用 NSSM（Non-Sucking Service Manager）—— 稳定、免费、无坑。

6.1 下载 NSSM#

官网：https://nssm.cc/release/nssm-2.24.zip

下载后解压
进入 win64/ 目录（32 位系统用 win32/）
复制 nssm.exe 到 C:\Program Files\frp\ 目录

最终目录：

1
C:\Program Files\frp\
2
├── frpc.exe
3
├── frpc.toml
4
├── frpc.log
5
└── nssm.exe    ← 放在这里

6.2 安装系统服务#

以管理员身份打开 PowerShell：

Terminal window

1
cd "C:\Program Files\frp"
2

3
# 安装服务（会弹出图形配置界面）
4
.\nssm.exe install FRPClient

图形界面按以下表格填写（每项都要检查，漏了会起不来）：

标签页	字段	填写内容
Application	Path	`C:\Program Files\frp\frpc.exe`
Application	Startup directory	`C:\Program Files\frp`
Application	Arguments	`-c C:\Program Files\frp\frpc.toml`
Details	Display name	`FRP Client - aaa.example.com`
Details	Description	`FRP内网穿透客户端 - 域名 aaa.example.com`
Details	Startup type	`Automatic`（自动）
Log on	Log on as	选择 `Local System account`，勾选 `Allow service to interact with desktop`
Dependencies		留空即可
I/O	Output (stdout)	`C:\Program Files\frp\nssm_stdout.log`
I/O	Error (stderr)	`C:\Program Files\frp\nssm_stderr.log`
I/O	Input (stdin)	留空
File rotation		勾选 Rotate files，设置 7 天 10MB 限制（可选）

确认无误后，点击 Install service 按钮。

6.3 启动并验证服务#

Terminal window展开收起

1
cd "C:\Program Files\frp"
2

3
# 启动服务
4
.\nssm.exe start FRPClient
5
# 预期：FRPClient: START: 操作成功完成。
6

7
# 查看状态（预期 SERVICE_RUNNING）
8
.\nssm.exe status FRPClient
9

10
# 查看 frpc 日志（确认连接成功）
11
Get-Content "C:\Program Files\frp\frpc.log" -Tail 50
12
# 应该能看到 login to server success + start proxy success
13

14
# 可选：实时追日志
15
Get-Content "C:\Program Files\frp\frpc.log" -Tail 30 -Wait

展开收起

6.4 NSSM 常用命令速查#

Terminal window展开收起

1
cd "C:\Program Files\frp"
2

3
# 启动 / 停止 / 重启
4
.\nssm.exe start FRPClient
5
.\nssm.exe stop FRPClient
6
.\nssm.exe restart FRPClient
7

8
# 查看状态 / 暂停 / 继续
9
.\nssm.exe status FRPClient
10
.\nssm.exe pause FRPClient
11
.\nssm.exe continue FRPClient
12

13
# 修改配置（再次弹出图形界面）
14
.\nssm.exe edit FRPClient
15

16
# 卸载服务
17
.\nssm.exe remove FRPClient
18
# 静默卸载（不弹确认框）
19
.\nssm.exe remove FRPClient confirm

展开收起

💡 备用方案（不用 NSSM）：可以用 Windows 「任务计划程序」创建「登录时 / 启动时」执行 frpc.exe -c frpc.toml 的任务，但稳定性和可控性不如 NSSM，不推荐生产使用。

五、完整验证流程图#

按顺序逐一确认，任何一步失败都要先解决再继续：

1
✅ Step 1. DNS 解析生效
2
   └─ Windows/Linux 执行：ping aaa.example.com
3
   └─ 预期：返回 = 你的公网服务器 IP
4

5
✅ Step 2. Nginx 监听正常
6
   └─ Linux 执行：ss -tlnp | grep -E ':(80|443)'
7
   └─ 预期：nginx 进程正在监听 80 / 443
8

9
✅ Step 3. frps 服务运行
10
   └─ Linux 执行：systemctl status frps
11
   └─ 预期：active (running)
12

13
✅ Step 4. frps 监听全部必需端口
14
   └─ Linux 执行：ss -tlnp | grep frps
15
   └─ 预期：0.0.0.0:7000、127.0.0.1:8080、0.0.0.0:7500 都在
16

17
✅ Step 5. frpc 成功登录
18
   └─ Windows 查看 frpc.log
19
   └─ 预期：login to server success
20

21
✅ Step 6. frpc 代理注册成功
22
   └─ Windows 查看 frpc.log
23
   └─ 预期：[web-80] start proxy success
24

25
✅ Step 7. 本地服务正常
26
   └─ Windows 浏览器：http://127.0.0.1
27
   └─ 预期：网站正常显示
28

29
✅ Step 8. 终极验证：外网访问
30
   └─ 手机流量浏览器：http://aaa.example.com
31
   └─ 预期：🎉 显示内网网站内容

展开收起

六、常用运维命令速查表#

6.1 Linux 服务器端#

Terminal window展开收起

1
# ---------- FRP 服务管理 ----------
2
systemctl start frps          # 启动
3
systemctl stop frps           # 停止
4
systemctl restart frps        # 重启
5
systemctl status frps         # 查看运行状态
6
systemctl enable frps         # 设置开机自启
7
systemctl disable frps        # 取消开机自启
8
systemctl is-active frps      # 快速判断是否在跑（active/inactive）
9

10
# ---------- FRP 日志查看 ----------
11
journalctl -u frps -f                 # 实时追 systemd 捕获的日志
12
journalctl -u frps -n 200 --no-pager  # 看最近 200 行（不分页）
13
tail -f /usr/local/frp/frps.log       # 实时追 frps 自身日志
14
tail -n 300 /usr/local/frp/frps.log   # 看最近 300 行
15
grep -iE "error|fail|warn" /usr/local/frp/frps.log  # 只看错误/警告
16

17
# ---------- Nginx 管理 ----------
18
nginx -t                        # 测试配置（改完配置必先跑！）
19
nginx -s reload                 # 平滑重载配置
20
nginx -s stop                   # 立即停止
21
nginx -s quit                   # 优雅停止（处理完现有请求）
22
systemctl reload nginx          # 同上重载
23
systemctl restart nginx         # 重启（会短暂中断）
24

25
# Nginx 日志
26
tail -f /var/log/nginx/aaa.example.com.access.log
27
tail -f /var/log/nginx/aaa.example.com.error.log
28
tail -f /var/log/nginx/error.log   # 全局错误日志
29

30
# ---------- 端口 / 进程检查 ----------
31
# 查看所有相关端口监听
32
ss -tlnp | grep -E ':(7000|80|8080|443|7500)'
33
# 等价
34
netstat -tlnp | grep -E ':(7000|80|8080|443|7500)'
35

36
# 查看 frps 进程
37
ps aux | grep frps | grep -v grep
38
pgrep -af frps
39

40
# 检查端口连通性（本机自测）
41
ss -tlnp | grep 7000          # frps 的 frpc 连接端口
42
curl -I http://127.0.0.1:8080 -H "Host: aaa.example.com"  # 直接打 frps
43
curl -I http://127.0.0.1      # 打 Nginx
44
curl -I http://127.0.0.1:7500 # 打 Dashboard
45

46
# ---------- 资源占用 ----------
47
# frps 内存 / CPU
48
top -p $(pgrep frps)
49
# 或者
50
htop -p $(pgrep frps)

展开收起

6.2 Windows 客户端#

Terminal window展开收起

1
# 进入 frp 目录
2
Set-Location "C:\Program Files\frp"
3

4
# ---------- FRP 服务管理（NSSM） ----------
5
.\nssm.exe start FRPClient       # 启动
6
.\nssm.exe stop FRPClient        # 停止
7
.\nssm.exe restart FRPClient     # 重启
8
.\nssm.exe status FRPClient      # 状态
9
.\nssm.exe edit FRPClient        # 改配置（弹窗）
10

11
# ---------- 日志查看 ----------
12
# 查看最近 50 行
13
Get-Content ".\frpc.log" -Tail 50
14
# 实时跟踪
15
Get-Content ".\frpc.log" -Tail 30 -Wait
16
# 筛选错误
17
Get-Content ".\frpc.log" | Select-String -Pattern "error|fail|warn" -CaseSensitive:$false
18

19
# ---------- 端口 / 网络检查 ----------
20
# 本地 80 端口占用
21
netstat -ano | findstr :80
22
Get-NetTCPConnection -LocalPort 80 -ErrorAction SilentlyContinue
23

24
# 测试连接 frps 服务器（7000 端口）
25
Test-NetConnection -ComputerName "你的服务器IP" -Port 7000
26
# TcpTestSucceeded : True 才是通的
27

28
# 测试本地 80
29
Test-NetConnection 127.0.0.1 -Port 80
30

31
# frpc 进程检查
32
Get-Process -Name frpc -ErrorAction SilentlyContinue
33
tasklist | findstr frpc
34

35
# ---------- 客户端面板（如果 webServer 启用了） ----------
36
# 浏览器打开
37
# http://127.0.0.1:7400

展开收起

七、常见问题排查 FAQ#

Q1. 访问 `http://aaa.example.com` 返回 404 Not Found#

原因：frps 收到请求后，根据 Host 头找不到匹配的代理。

排查步骤：

Nginx 丢失 Host 头（90% 概率）
- 检查 Nginx 配置：proxy_set_header Host $host; 必须存在，且不能写成 $proxy_host 或其他
- 改完必须 nginx -t && nginx -s reload
域名不匹配
- 三者必须完全一致（大小写、是否带 www）：
  - Nginx server_name aaa.example.com;
  - frpc.toml customDomains = ["aaa.example.com"]
  - 浏览器实际访问的域名
frpc 没注册成功
- 看 Windows 侧 frpc.log 有没有 start proxy success

Q2. 返回 502 Bad Gateway#

原因：Nginx → frps 或 frpc → 本地服务链路断开。

排查步骤：

frps 正常吗？

Terminal window

1
systemctl status frps
2
ss -tlnp | grep 8080

Nginx → frps 8080 能通吗？

Terminal window

1
curl -v http://127.0.0.1:8080 -H "Host: aaa.example.com"

frpc 还在线吗？查看 frps.log 有没有 client disconnect
Windows 本地 80 端口活着吗？本机访问 http://127.0.0.1
查 Nginx 错误日志：tail -f /var/log/nginx/aaa.example.com.error.log

Q3. 返回 504 Gateway Timeout#

原因：超时（frpc 响应太慢、网络抖动、本地服务卡住）。

排查与修复：

确认 Windows 本地 http://127.0.0.1 访问速度正常

临时加大 Nginx 超时：

1
proxy_read_timeout 600s;
2
proxy_send_timeout 600s;
3
proxy_connect_timeout 120s;

检查 frpc 日志有没有大量重连记录
检查服务器与 Windows 的网络质量：
- Linux 侧看 ping 延迟 / 丢包
- 如果丢包严重，试试换 transport.protocol = "kcp" 或 "quic"

Q4. frpc 日志显示 `connection timed out` 连不上 frps#

原因：客户端 → 服务器 7000 端口不通。

排查（按概率从高到低）：

云服务器安全组没放行 7000（最常见！）
- 登录阿里云/腾讯云控制台 → 安全组 → 入方向 → 放行 TCP 7000
Linux 系统防火墙
- CentOS：firewall-cmd --list-ports 确认有 7000
- Ubuntu：ufw status
serverAddr 填错了
- 确认填的是公网 IP，不是内网 IP、不是 127.0.0.1
服务器供应商额外防火墙
- 阿里云还有「网络 ACL」、IDC 机房可能有硬件防火墙
本地出口封了 7000
- 换端口试试：把 frps bindPort 改成 443（如果 443 不用）或 8443

Windows 本机验证

Terminal window

1
Test-NetConnection 服务器IP -Port 7000
2
# 或者用 telnet
3
telnet 服务器IP 7000

Q5. frps Dashboard 打不开（IP<7500> 拒绝连接）#

原因：配置没加载 / 监听地址错 / 端口没放行。

排查：

frps.toml 确认：

1
[webServer]
2
addr = "0.0.0.0"
3
port = 7500
4
user = "admin"
5
password = "123456"

重启 frps：systemctl restart frps
看日志：grep -i dashboard /usr/local/frp/frps.log，应该有 listen on 0.0.0.0:7500
看监听：ss -tlnp | grep 7500
放行防火墙 + 安全组 7500 端口

Q6. 图片加载慢 / 大文件上传失败 / 视频卡顿#

优化建议：

压缩：在 frpc.toml 开启了 useCompression = true（图片视频效果有限，主要针对文本）
带宽限流：检查 bandwidthLimit 是否设太小（注释掉就是不限）

Nginx 缓存静态资源（可选）：

1
location ~* \.(jpg|jpeg|png|gif|css|js|ico|svg|woff2?)$ {
2
    proxy_pass http://127.0.0.1:8080;
3
    proxy_set_header Host $host;
4
    proxy_cache_valid 200 7d;
5
    expires 7d;
6
    add_header Cache-Control "public, max-age=604800";
7
}

文件上传大小：检查 client_max_body_size 是否足够（已默认 1024m）
CDN 加速：Cloudflare 全站缓存静态资源（穿透成功后再开启）

Q7. 修改了 frpc.toml 后配置没生效#

原因：没有重启 frpc 服务 / 改了错误的文件。

操作步骤：

确认编辑的文件是 C:\Program Files\frp\frpc.toml（不是压缩包解压目录里的）

必须重启服务：

Terminal window

1
cd "C:\Program Files\frp"
2
.\nssm.exe restart FRPClient

查看启动日志确认：Get-Content ".\frpc.log" -Tail 50

💡 小技巧：改完配置可以先前台跑一次 .\frpc.exe -c .\frpc.toml 确认没语法报错，再起服务。

Q8. 使用 Cloudflare CDN 后穿透异常（521 / 522 错误）#

Cloudflare 代理模式（橙色云）对 WebSocket、长连接、大文件上传有一定影响。

解决方案：

测试阶段：Cloudflare DNS 设置为 「DNS only」灰色云，确认穿透 100% 正常
生产开启：
- Cloudflare SSL/TLS 模式选择 「Full (strict)」（前提是服务器上了有效 HTTPS 证书）
- Cloudflare Rules → 针对 aaa.example.com 关掉 Brotli / Rocket Loader（可能干扰）
- WebSocket 开启（默认已开）
- 缓存级别选择 Standard，避免缓存过多动态内容

Q9. frpc 每隔一段时间就断开重连（连接不稳定）#

排查：

日志里找原因：Get-Content frpc.log | Select-String "reconnect|disconnect|heartbeat"

心跳超时？调大两端 heartbeatTimeout：

frps.toml

1
[transport]
2
heartbeatTimeout = 180
3

4
# frpc.toml
5
[transport]
6
heartbeatInterval = 60
7
heartbeatTimeout = 180

网络质量差：试试切换协议 transport.protocol = "kcp" 或 "quic"（防火墙需要放行对应 UDP 端口）
Windows 休眠？关闭网卡省电模式：设备管理器 → 网卡属性 → 电源管理 → 取消「允许计算机关闭此设备以节约电源」

八、进阶：启用 HTTPS（Let’s Encrypt 免费证书）#

强烈建议生产环境启用 HTTPS，保护用户密码与隐私数据。

方式 A：Certbot 自动申请 + 自动配置 Nginx（推荐 Debain/Ubuntu）#

Terminal window

1
# 1. 安装 certbot + nginx 插件
2
apt update
3
apt install -y certbot python3-certbot-nginx
4

5
# 2. 一键申请 + 自动写入 Nginx 配置
6
certbot --nginx -d aaa.example.com
7

8
# 按提示操作：输入邮箱 → 同意协议 → 选择是否跳转（选 2: Redirect）
9

10
# 3. 验证自动续期（Certbot 默认已配置 systemd timer）
11
certbot renew --dry-run
12
# 输出 success 表示续期测试成功

Certbot 会自动：

申请 Let’s Encrypt 90 天免费证书
自动写入 ssl_certificate / ssl_certificate_key
自动加 80 → 443 301 跳转
自动配置续期 timer（到期前 30 天自动续）

方式 B：Certbot 独立模式 / CentOS#

Terminal window

1
# CentOS 安装
2
yum install -y epel-release
3
yum install -y certbot python3-certbot-nginx
4

5
# 或者手动停止 Nginx 走 standalone 模式（Nginx 插件失败时备用）
6
systemctl stop nginx
7
certbot certonly --standalone -d aaa.example.com -m your@email.com
8
systemctl start nginx

方式 C：其他面板（宝塔/1Panel/AppNode）#

在面板里操作即可：

新建站点：域名填 aaa.example.com，PHP 版本选「纯静态」
站点设置 → SSL → Let’s Encrypt → 申请
站点设置 → 反向代理 → 添加：
- 代理名称：frp
- 目标 URL：http://127.0.0.1:8080
- 发送域名：$host（务必选择，或手动写入 Host 头）
- 开启「替换 Host Header」

九、配置文件模板汇总#

为方便快速部署，以下是所有关键配置文件的可直接复制版本（只需改 IP、token、密码）：

📄 frps.toml 最简生产版#

1
bindAddr = "0.0.0.0"
2
bindPort = 7000
3
proxyBindAddr = "127.0.0.1"
4
vhostHTTPPort = 8080
5

6
[auth]
7
method = "token"
8
token = "123456"
9

10
[webServer]
11
addr = "0.0.0.0"
12
port = 7500
13
user = "admin"
14
password = "123456"
15

16
[log]
17
to = "./frps.log"
18
level = "info"
19
maxDays = 7

展开收起

📄 frpc.toml 最简生产版#

1
serverAddr = "123.123.123.123"
2
serverPort = 7000
3
loginFailExit = false
4

5
[auth]
6
method = "token"
7
token = "123456"
8

9
[webServer]
10
addr = "127.0.0.1"
11
port = 7400
12
user = "admin"
13
password = "FrpClient@789"
14

15
[log]
16
to = "./frpc.log"
17
level = "info"
18
maxDays = 7
19

20
[transport.tls]
21
enable = true
22

23
[[proxies]]
24
name = "web-80"
25
type = "http"
26
localIP = "127.0.0.1"
27
localPort = 80
28
customDomains = ["aaa.example.com"]
29

30
[proxies.transport]
31
useCompression = true
32
useEncryption = true

展开收起

📄 frps.service systemd 单元#

1
[Unit]
2
Description = FRP Server (Nginx Proxy Mode)
3
After = network.target syslog.target network-online.target
4
Wants = network-online.target
5

6
[Service]
7
Type = simple
8
WorkingDirectory = /usr/local/frp
9
ExecStart = /usr/local/frp/frps -c /usr/local/frp/frps.toml
10
Restart = always
11
RestartSec = 5s
12

13
[Install]
14
WantedBy = multi-user.target

📄 Nginx 反代配置（HTTP + Dashboard）#

1
server {
2
    listen 80;
3
    listen [::]:80;
4
    server_name aaa.example.com;
5

6
    access_log  /var/log/nginx/aaa.example.com.access.log  main;
7
    error_log   /var/log/nginx/aaa.example.com.error.log   warn;
8

9
    client_max_body_size 1024m;
10

11
    location / {
12
        proxy_pass http://127.0.0.1:8080;
13
        proxy_set_header Host $host;
14
        proxy_set_header X-Real-IP $remote_addr;
15
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
16
        proxy_set_header X-Forwarded-Proto $scheme;
17
        proxy_set_header X-Forwarded-Host $host;
18
        proxy_set_header X-Forwarded-Port $server_port;
19
        proxy_http_version 1.1;
20
        proxy_set_header Upgrade $http_upgrade;
21
        proxy_set_header Connection "upgrade";
22
        proxy_connect_timeout 60s;
23
        proxy_send_timeout 300s;
24
        proxy_read_timeout 300s;
25
        proxy_buffering off;
26
    }
27

28
    location ^~ /_frp_dashboard/ {
29
        proxy_pass http://127.0.0.1:7500/;
30
        proxy_set_header Host $host;
31
        proxy_set_header X-Real-IP $remote_addr;
32
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
33
        proxy_set_header X-Forwarded-Proto $scheme;
34
        proxy_http_version 1.1;
35
        proxy_set_header Upgrade $http_upgrade;
36
        proxy_set_header Connection "upgrade";
37
    }
38
}

展开收起

十、安全加固建议（生产必做）#

Token 设置得足够复杂：至少 20 位，混合大小写 + 数字 + 特殊字符
Dashboard 不要裸奔：
- 方案 A：addr = "127.0.0.1" + Nginx 反代 + Basic Auth 双因子
- 方案 B：监听 0.0.0.0 但用 iptables 只允许你的办公出口 IP 访问 7500
开启 TLS：frpc transport.tls.enable = true（v0.68.0 默认，确认没关掉）
HTTPS 全站：Let’s Encrypt 证书安排上，避免数据明文
限制客户端代理数：frps maxPortsPerClient = 20（防止滥用）

frp 文件权限：

Terminal window

1
chown -R root:root /usr/local/frp
2
chmod 700 /usr/local/frp
3
chmod 600 /usr/local/frp/frps.toml   # 防止配置文件被其他用户读到 token

不要用默认端口：有条件就把 bindPort 7000 改为 5 位数随机端口（减少扫描探测）

Apollo生产环境分布式部署

Mon, 05 Jan 2026 00:00:00 GMT

一、准备工作#

1.1 运行时环境#

1.1.1 OS#

服务端基于Spring Boot，启动脚本理论上支持所有Linux发行版，建议CentOS 7。

1.1.2 Java#

Apollo服务端：1.8+
Apollo客户端：1.7+

由于需要同时运行服务端和客户端，所以建议安装Java 1.8+。

对于Apollo客户端，运行时环境只需要1.7+即可。

在配置好后，可以通过如下命令检查：

Terminal window

1
java -version

1.2 MySQL#

版本要求：5.6.5+

Apollo的表结构对timestamp使用了多个default声明，所以需要5.6.5以上版本。

连接上MySQL后，可以通过如下命令检查：

Terminal window

1
SHOW VARIABLES WHERE Variable_name = 'version';

1.3 Docker部署#

Apollo项目已经自带了Docker file，可以参照2.2 获取安装包配置好安装包后通过下面的文件来打Docker镜像：

二、部署步骤#

部署步骤共三步：

创建数据库
- Apollo服务端依赖于MySQL数据库，所以需要事先创建并完成初始化
获取安装包
- Apollo服务端安装包共有3个：apollo-configservice, apollo-adminservice, apollo-portal
  - 可以直接下载我们事先打好的安装包，也可以自己通过源码构建
部署Apollo服务端
- 获取安装包后就可以部署到测试和生产环境了

2.1 创建数据库#

Apollo服务端共需要两个数据库：ApolloPortalDB和ApolloConfigDB，我们把数据库、表的创建和样例数据都分别准备了sql文件，只需要导入数据库即可。

需要注意的是ApolloPortalDB只需要在生产环境部署一个即可，而ApolloConfigDB需要在每个环境部署一套，如dev、test和pro分别部署3套ApolloConfigDB。

2.1.1 创建ApolloPortalDB#

2.1.1.1 手动导入SQL创建#

通过各种MySQL客户端导入apolloportaldb.sql即可。

以MySQL原生客户端为例：

Terminal window

1
source /your_local_path/scripts/sql/apolloportaldb.sql

2.1.1.3 验证#

导入成功后，可以通过执行以下sql语句来验证：

1
select `Id`, `Key`, `Value`, `Comment` from `ApolloPortalDB`.`ServerConfig` limit 1;

Id	Key	Value	Comment
1	apollo.portal.envs	dev	可支持的环境列表

2.1.2 创建ApolloConfigDB#

2.1.2.1 手动导入SQL#

通过各种MySQL客户端导入apolloconfigdb.sql即可。

以MySQL原生客户端为例：

Terminal window

1
source /your_local_path/scripts/sql/apolloconfigdb.sql

2.1.2.3 验证#

导入成功后，可以通过执行以下sql语句来验证：

1
select `Id`, `Key`, `Value`, `Comment` from `ApolloConfigDB`.`ServerConfig` limit 1;

Id	Key	Value	Comment
1	eureka.service.url	http://127.0.0.1:8080/eureka/	Eureka服务Url

Terminal window

1
docker run -p 8080:8080 -e DS_URL="jdbc:mysql://192.168.123.5:3306/ApolloConfigDB?characterEncoding=utf8" -e DS_USERNAME=root -e DS_PASSWORD=root -d -v /tmp/logs:/opt/logs --name apollo-configservice apollo-configservice

2.1.3 调整服务端配置#

Apollo自身的一些配置是放在数据库里面的，所以需要针对实际情况做一些调整。

以下配置除了支持在数据库中配置以外，也支持通过-D参数、application.properties等配置，且-D参数、application.properties等优先级高于数据库中的配置

2.1.3.1 调整ApolloPortalDB配置#

配置项统一存储在ApolloPortalDB.ServerConfig表中，也可以通过管理员工具 - 系统参数页面进行配置，无特殊说明则修改完一分钟实时生效。

1.apollo.portal.envs - 可支持的环境列表#

默认值是dev，如果portal需要管理多个环境的话，以逗号分隔即可（大小写不敏感），如：

1
DEV,FAT,UAT,PRO

修改完需要重启生效。

注1：一套Portal可以管理多个环境，但是每个环境都需要独立部署一套Config Service、Admin Service和ApolloConfigDB，具体请参考：2.1.2 创建ApolloConfigDB，2.1.3.2 调整ApolloConfigDB配置，2.2.1.2 配置数据库连接信息，另外如果是为已经运行了一段时间的Apollo配置中心增加环境，别忘了参考2.1.2.1 从别的环境导入ApolloConfigDB的项目数据对新的环境做初始化。

注2：只在数据库添加环境是不起作用的，还需要为apollo-portal添加新增环境对应的meta server地址，具体参考：2.2.1.2.4 配置apollo-portal的meta service信息。apollo-client在新的环境下使用时也需要做好相应的配置，具体参考：1.2.2 Apollo Meta Server。

注3：如果希望添加自定义的环境名称，具体步骤可以参考Portal如何增加环境。

注4：1.1.0版本增加了系统信息页面（管理员工具 -> 系统信息），可以通过该页面检查配置是否正确

3.superAdmin - Portal超级管理员#

超级管理员拥有所有权限，需要谨慎设置。

如果没有接入自己公司的SSO系统的话，可以先暂时使用默认值apollo（默认用户）。等接入后，修改为实际使用的账号，多个账号以英文逗号分隔(,)。

4.consumer.token.salt - consumer token salt#

如果会使用开放平台API的话，可以设置一个token salt。如果不使用，可以忽略。

5.wiki.address#

portal上“帮助”链接的地址，默认是Apollo github的wiki首页，可自行设置。

6.admin.createPrivateNamespace.switch#

是否允许项目管理员创建private namespace。设置为true允许创建，设置为false则项目管理员在页面上看不到创建private namespace的选项。了解更多Namespace

7. emergencyPublish.supported.envs#

配置允许紧急发布的环境列表，多个env以英文逗号分隔。

当config service开启一次发布只能有一个人修改开关(namespace.lock.switch)后，一次配置发布只能是一个人修改，另一个发布。为了避免遇到紧急情况时（如非工作时间、节假日）无法发布配置，可以配置此项以允许某些环境可以操作紧急发布，即同一个人可以修改并发布配置。

8. configView.memberOnly.envs#

只对项目成员显示配置信息的环境列表，多个env以英文逗号分隔。

对设定了只对项目成员显示配置信息的环境，只有该项目的管理员或拥有该namespace的编辑或发布权限的用户才能看到该私有namespace的配置信息和发布历史。公共namespace始终对所有用户可见。

从1.1.0版本开始支持，详见PR 1531

9. role.create-application.enabled - 是否开启创建项目权限控制#

适用于1.5.0及以上版本

默认为false，所有用户都可以创建项目

如果设置为true，那么只有超级管理员和拥有创建项目权限的帐号可以创建项目，超级管理员可以通过管理员工具 - 系统权限管理给用户分配创建项目权限

10. role.manage-app-master.enabled - 是否开启项目管理员分配权限控制#

适用于1.5.0及以上版本

默认为false，所有项目的管理员可以为项目添加/删除管理员

如果设置为true，那么只有超级管理员和拥有项目管理员分配权限的帐号可以为特定项目添加/删除管理员，超级管理员可以通过管理员工具 - 系统权限管理给用户分配特定项目的管理员分配权限

11. prefix.path - 设置Portal挂载到nginx/slb后的相对路径#

适用于1.6.0及以上版本

如果希望在Portal前挂软负载，一般情况下建议直接使用根目录来挂载，不过如果有些情况希望和其它应用共用nginx/slb，需要加上相对路径，那么可以配置此项，如prefix.path=/apollo，更多信息可以参考Portal挂载到nginx/slb后如何设置相对路径？。

修改完需要重启生效。

2.1.3.2 调整ApolloConfigDB配置#

配置项统一存储在ApolloConfigDB.ServerConfig表中，需要注意每个环境的ApolloConfigDB.ServerConfig都需要单独配置，修改完一分钟实时生效。

1. eureka.service.url - Eureka服务Url#

不管是apollo-configservice还是apollo-adminservice都需要向eureka服务注册，所以需要配置eureka服务地址。按照目前的实现，apollo-configservice本身就是一个eureka服务，所以只需要填入apollo-configservice的地址即可，如有多个，用逗号分隔（注意不要忘了/eureka/后缀）。

需要注意的是每个环境只填入自己环境的eureka服务地址，比如FAT的apollo-configservice是1.1.1.1<8080和2>.2.2.2<8080>，UAT的apollo-configservice是3.3.3.3<8080和4>.4.4.4<8080>，PRO的apollo-configservice是5.5.5.5<8080和6>.6.6.6<8080>，那么：

在FAT环境的ApolloConfigDB.ServerConfig表中设置eureka.service.url为：

1
http://1.1.1.1:8080/eureka/,http://2.2.2.2:8080/eureka/

在UAT环境的ApolloConfigDB.ServerConfig表中设置eureka.service.url为：

1
http://3.3.3.3:8080/eureka/,http://4.4.4.4:8080/eureka/

在PRO环境的ApolloConfigDB.ServerConfig表中设置eureka.service.url为：

1
http://5.5.5.5:8080/eureka/,http://6.6.6.6:8080/eureka/

注1：这里需要填写本环境中全部的eureka服务地址，因为eureka需要互相复制注册信息

注2：如果希望将Config Service和Admin Service注册到公司统一的Eureka上，可以参考部署&开发遇到的常见问题 - 将Config Service和Admin Service注册到单独的Eureka Server上章节

注3：在多机房部署时，往往希望config service和admin service只向同机房的eureka注册，要实现这个效果，需要利用ServerConfig表中的cluster字段，config service和admin service会读取所在机器的/opt/settings/server.properties（Mac/Linux）或C:\opt\settings\server.properties（Windows）中的idc属性，如果该idc有对应的eureka.service.url配置，那么就只会向该机房的eureka注册。比如config service和admin service会部署到SHAOY和SHAJQ两个IDC，那么为了实现这两个机房中的服务只向该机房注册，那么可以在ServerConfig表中新增两条记录，分别填入SHAOY和SHAJQ两个机房的eureka地址即可，default cluster的记录可以保留，如果有config service和admin service不是部署在SHAOY和SHAJQ这两个机房的，就会使用这条默认配置。

Key	Cluster	Value	Comment
eureka.service.url	default	http://1.1.1.1:8080/eureka/	默认的Eureka服务Url
eureka.service.url	SHAOY	http://2.2.2.2:8080/eureka/	SHAOY的Eureka服务Url
eureka.service.url	SHAJQ	http://3.3.3.3:8080/eureka/	SHAJQ的Eureka服务Url

2. namespace.lock.switch - 一次发布只能有一个人修改开关，用于发布审核#

这是一个功能开关，如果配置为true的话，那么一次配置发布只能是一个人修改，另一个发布。

生产环境建议开启此选项

3. config-service.cache.enabled - 是否开启配置缓存#

这是一个功能开关，如果配置为true的话，config service会缓存加载过的配置信息，从而加快后续配置获取性能。

默认为false，开启前请先评估总配置大小并调整config service内存配置。

开启缓存后必须确保应用中配置的app.id大小写正确，否则将获取不到正确的配置

4. item.key.length.limit - 配置项 key 最大长度限制#

默认配置是128。

5. item.value.length.limit - 配置项 value 最大长度限制#

默认配置是20000。

2.2 获取安装包#

可以通过两种方式获取安装包：

直接下载安装包
- 从GitHub Release页面下载预先打好的安装包
- 如果对Apollo的代码没有定制需求，建议使用这种方式，可以省去本地打包的过程
通过源码构建
- 从GitHub Release页面下载Source code包或直接clone源码后在本地构建
- 如果需要对Apollo的做定制开发，需要使用这种方式

2.2.1 直接下载安装包#

2.2.1.1 获取apollo-configservice、apollo-adminservice、apollo-portal安装包#

从GitHub Release页面下载最新版本的apollo-configservice-x.x.x-github.zip、apollo-adminservice-x.x.x-github.zip和apollo-portal-x.x.x-github.zip即可。

2.3 使用Docker部署Apollo服务端#

Terminal window

1
mkdir -p /opt/apollo/docker/apollo-configservice
2
mkdir -p /opt/apollo/docker/apollo-adminservice
3
mkdir -p /opt/apollo/docker/apollo-portal

2.3.1 部署apollo-configservice#

Terminal window展开收起

1
# Dockerfile for apollo-configservice
2
# 1. Copy apollo-configservice-${VERSION}-github.zip to current directory
3
# 2. Build with: docker build -t apollo-configservice .
4
# 3. Run with: docker run --restart=always  -p 8080:8080 -e "EUREKA_INSTANCE_IP-ADDRESS=你的宿主机IP" -e DS_URL="jdbc:mysql://192.168.123.5:3306/ApolloConfigDB?characterEncoding=utf8" -e DS_USERNAME=root -e DS_PASSWORD=root -d -v /tmp/logs:/opt/logs --name apollo-configservice apollo-configservice
5

6
FROM openjdk:8-jre-alpine
7
MAINTAINER ameizi <sxyx2008@163.com>
8

9
ENV VERSION 1.5.1
10
ENV SERVER_PORT 8080
11
# DataSource Info
12
ENV DS_URL ""
13
ENV DS_USERNAME ""
14
ENV DS_PASSWORD ""
15

16
RUN echo "http://mirrors.aliyun.com/alpine/v3.8/main" > /etc/apk/repositories \
17
    && echo "http://mirrors.aliyun.com/alpine/v3.8/community" >> /etc/apk/repositories \
18
    && apk update upgrade \
19
    && apk add --no-cache procps unzip curl bash tzdata \
20
    && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
21
    && echo "Asia/Shanghai" > /etc/timezone
22

23
ADD apollo-configservice-${VERSION}-github.zip /apollo-configservice/apollo-configservice-${VERSION}-github.zip
24

25
RUN unzip /apollo-configservice/apollo-configservice-${VERSION}-github.zip -d /apollo-configservice \
26
    && rm -rf /apollo-configservice/apollo-configservice-${VERSION}-github.zip \
27
    && sed -i '$d' /apollo-configservice/scripts/startup.sh \
28
    && chmod +x /apollo-configservice/scripts/startup.sh \
29
    && echo "tail -f /dev/null" >> /apollo-configservice/scripts/startup.sh
30

31
EXPOSE $SERVER_PORT
32

33
CMD ["/apollo-configservice/scripts/startup.sh"]

展开收起

2.3.2 部署apollo-adminservice#

Terminal window展开收起

1
# Dockerfile for apollo-adminservice
2
# 1. Copy apollo-adminservice-${VERSION}-github.zip to current directory
3
# 2. Build with: docker build -t apollo-adminservice .
4
# 3. Run with: docker run --restart=always -p 8090:8090 -e "EUREKA_INSTANCE_IP-ADDRESS=你的宿主机IP" -e DS_URL="jdbc:mysql://192.168.123.5:3306/ApolloConfigDB?characterEncoding=utf8" -e DS_USERNAME=root -e DS_PASSWORD=root -d -v /tmp/logs:/opt/logs --name apollo-adminservice apollo-adminservice
5

6
FROM openjdk:8-jre-alpine
7
MAINTAINER ameizi <sxyx2008@163.com>
8

9
ENV VERSION 1.5.1
10
ENV SERVER_PORT 8090
11
# DataSource Info
12
ENV DS_URL ""
13
ENV DS_USERNAME ""
14
ENV DS_PASSWORD ""
15

16
RUN echo "http://mirrors.aliyun.com/alpine/v3.8/main" > /etc/apk/repositories \
17
    && echo "http://mirrors.aliyun.com/alpine/v3.8/community" >> /etc/apk/repositories \
18
    && apk update upgrade \
19
    && apk add --no-cache procps unzip curl bash tzdata \
20
    && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
21
    && echo "Asia/Shanghai" > /etc/timezone
22

23
ADD apollo-adminservice-${VERSION}-github.zip /apollo-adminservice/apollo-adminservice-${VERSION}-github.zip
24

25
RUN unzip /apollo-adminservice/apollo-adminservice-${VERSION}-github.zip -d /apollo-adminservice \
26
    && rm -rf /apollo-adminservice/apollo-adminservice-${VERSION}-github.zip \
27
    && sed -i '$d' /apollo-adminservice/scripts/startup.sh \
28
    && chmod +x /apollo-adminservice/scripts/startup.sh \
29
    && echo "tail -f /dev/null" >> /apollo-adminservice/scripts/startup.sh
30

31
EXPOSE $SERVER_PORT
32

33
CMD ["/apollo-adminservice/scripts/startup.sh"]

展开收起

2.3.3 部署apollo-portal#

Terminal window展开收起

1
# Dockerfile for apollo-portal
2
# 1. Copy apollo-portal-${VERSION}-github.zip to current directory
3
# 2. Build with: docker build -t apollo-portal .
4
# 3. Run with: docker run --restart=always -p 8070:8070 -e DS_URL="jdbc:mysql://192.168.123.5:3306/ApolloPortalDB?characterEncoding=utf8" -e DS_USERNAME=root -e DS_PASSWORD=root -e DEV_META=http://192.168.123.5:8080 -d -v /tmp/logs:/opt/logs --name apollo-portal apollo-portal
5

6
FROM openjdk:8-jre-alpine
7
MAINTAINER ameizi <sxyx2008@163.com>
8

9
ENV VERSION 1.6.0
10
ENV SERVER_PORT 8070
11
# DataSource Info
12
ENV DS_URL ""
13
ENV DS_USERNAME ""
14
ENV DS_PASSWORD ""
15
# Environmental variable declaration (meta server url, different environments should have different meta server addresses)
16
ENV DEV_META ""
17
ENV TEST_META ""
18
#ENV UAT_META ""
19
#ENV LPT_META ""
20
ENV PRO_META ""
21

22
RUN echo "http://mirrors.aliyun.com/alpine/v3.8/main" > /etc/apk/repositories \
23
    && echo "http://mirrors.aliyun.com/alpine/v3.8/community" >> /etc/apk/repositories \
24
    && apk update upgrade \
25
    && apk add --no-cache procps unzip curl bash tzdata \
26
    && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
27
    && echo "Asia/Shanghai" > /etc/timezone
28

29
ADD apollo-portal-${VERSION}-github.zip /apollo-portal/apollo-portal-${VERSION}-github.zip
30

31
RUN unzip /apollo-portal/apollo-portal-${VERSION}-github.zip -d /apollo-portal \
32
    && rm -rf /apollo-portal/apollo-portal-${VERSION}-github.zip \
33
    && sed -i '$d' /apollo-portal/scripts/startup.sh \
34
    && chmod +x /apollo-portal/scripts/startup.sh \
35
    && echo "tail -f /dev/null" >> /apollo-portal/scripts/startup.sh
36

37
EXPOSE $SERVER_PORT
38

39
CMD ["/apollo-portal/scripts/startup.sh"]

展开收起

JAVA设计模式的七大原则

Mon, 05 Jan 2026 00:00:00 GMT

设计模式的目的#

架构设计中的MySQL设计原则

Mon, 05 Jan 2026 00:00:00 GMT

1.互联网电商背景下的难题#

大数据量的存储

单台服务器的存储能力及数据处理能力都是有限的, 因此需要增加服务器, 搭建集群来存储海量数据。
读性能瓶颈

FlexVolume

Mon, 05 Jan 2026 00:00:00 GMT

Kubernetes 默认情况下就提供了主流的存储卷接入方案，可以执行命令 kubectl explain pod.spec.volumes 查看到支持的各种存储卷，另外也提供了插件机制，允许其他类型的存储服务接入到 Kubernetes 系统中来，在 Kubernetes 中就对应 In-Tree 和 Out-Of-Tree 两种方式，In-Tree 就是在 Kubernetes 源码内部实现的，和 Kubernetes 一起发布、管理的，但是更新迭代慢、灵活性比较差，Out-Of-Tree 是独立于 Kubernetes 的，目前主要有 CSI 和 FlexVolume 两种机制，开发者可以根据自己的存储类型实现不同的存储插件接入到 Kubernetes 中去，其中 CSI 是现在也是以后主流的方式。

FlexVolume 提供了一种扩展 Kubernetes 存储插件的方式，用户可以自定义自己的存储插件。要使用 FlexVolume 需要在每个节点上安装存储插件二进制文件，该二进制需要实现 FlexVolume 的相关接口，默认存储插件的存放路径为 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/<vendor~driver>/<driver>，VolumePlugins 组件会不断 watch 这个目录来实现插件的添加、删除等功能。

其中 vendor~driver 的名字需要和 Pod 中flexVolume.driver 的字段名字匹配，例如：

Terminal window

1
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/foo~cifs/cifs

对应的 Pod 中的 flexVolume.driver 属性为：foo/cifs。

在实现自定义存储插件的时候，需要实现 FlexVolume 的部分接口，因为要看实际需求，并不一定所有接口都需要实现。比如对于类似于 NFS 这样的存储就没必要实现 attach/detach 这些接口了，因为不需要，只需要实现 init/mount/umount 3 个接口即可。

init: <driver executable> init - kubelet/kube-controller-manager 初始化存储插件时调用，插件需要返回是否需要要 attach 和 detach 操作
attach: <driver executable> attach <json options> <node name> - 将存储卷挂载到 Node 节点上
detach: <driver executable> detach <mount device> <node name> - 将存储卷从 Node 上卸载
waitforattach: <driver executable> waitforattach <mount device> <json options> - 等待 attach 操作成功（超时时间为 10 分钟）
isattached: <driver executable> isattached <json options> <node name> - 检查存储卷是否已经挂载
mountdevice: <driver executable> mountdevice <mount dir> <mount device> <json options> - 将设备挂载到指定目录中以便后续 bind mount 使用
unmountdevice: <driver executable> unmountdevice <mount device> - 将设备取消挂载
mount: <driver executable> mount <mount dir> <json options> - 将存储卷挂载到指定目录中
unmount: <driver executable> unmount <mount dir> - 将存储卷取消挂载

实现上面的这些接口需要返回如下所示的 JSON 格式的数据：

1
{
2
    "status": "<Success/Failure/Not supported>",
3
    "message": "<Reason for success/failure>",
4
    "device": "<Path to the device attached. This field is valid only for attach & waitforattach call-outs>"
5
    "volumeName": "<Cluster wide unique name of the volume. Valid only for getvolumename call-out>"
6
    "attached": <True/False (Return true if volume is attached on the node. Valid only for isattached call-out)>
7
    "capabilities": <Only included as part of the Init response>
8
    {
9
        "attach": <True/False (Return true if the driver implements attach and detach)>
10
    }
11
}

比如实现一个 NFS 的 FlexVolume 插件，最简单的方式就是写一个脚本，然后实现 init、mount、unmount 3 个命令即可，然后按照上面的 JSON 格式返回数据，最后把这个脚本放在节点的 FlexVolume 插件目录下面即可。

下面就是官方给出的一个 NFS 的 FlexVolume 插件示例，可以从 https://github.com/kubernetes/examples/blob/master/staging/volumes/flexvolume/nfs 获取脚本：

1
#!/bin/bash
2
# 注意:
3
#  - 在使用插件之前需要先安装 jq。
4
usage() {
5
    err "Invalid usage. Usage: "
6
    err "\t$0 init"
7
    err "\t$0 mount <mount dir> <json params>"
8
    err "\t$0 unmount <mount dir>"
9
    exit 1
10
}
11

12
err() {
13
    echo -ne $* 1>&2
14
}
15

16
log() {
17
    echo -ne $* >&1
18
}
19

20
ismounted() {
21
    MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1`
22
    if [ "${MOUNT}" == "${MNTPATH}" ]; then
23
        echo "1"
24
    else
25
        echo "0"
26
    fi
27
}
28

29
domount() {
30
    MNTPATH=$1
31

32
    NFS_SERVER=$(echo $2 | jq -r '.server')
33
    SHARE=$(echo $2 | jq -r '.share')
34

35
    if [ $(ismounted) -eq 1 ] ; then
36
        log '{"status": "Success"}'
37
        exit 0
38
    fi
39

40
    mkdir -p ${MNTPATH} &> /dev/null
41

42
    mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null
43
    if [ $? -ne 0 ]; then
44
        err "{ \"status\": \"Failure\", \"message\": \"Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}\"}"
45
        exit 1
46
    fi
47
    log '{"status": "Success"}'
48
    exit 0
49
}
50

51
unmount() {
52
    MNTPATH=$1
53
    if [ $(ismounted) -eq 0 ] ; then
54
        log '{"status": "Success"}'
55
        exit 0
56
    fi
57

58
    umount ${MNTPATH} &> /dev/null
59
    if [ $? -ne 0 ]; then
60
        err "{ \"status\": \"Failed\", \"message\": \"Failed to unmount volume at ${MNTPATH}\"}"
61
        exit 1
62
    fi
63

64
    log '{"status": "Success"}'
65
    exit 0
66
}
67

68
op=$1
69

70
if ! command -v jq >/dev/null 2>&1; then
71
    err "{ \"status\": \"Failure\", \"message\": \"'jq' binary not found. Please install jq package before using this driver\"}"
72
    exit 1
73
fi
74

75
if [ "$op" = "init" ]; then
76
    log '{"status": "Success", "capabilities": {"attach": false}}'
77
    exit 0
78
fi
79

80
if [ $# -lt 2 ]; then
81
    usage
82
fi
83

84
shift
85

86
case "$op" in
87
    mount)
88
        domount $*
89
        ;;
90
    unmount)
91
        unmount $*
92
        ;;
93
    *)
94
        log '{"status": "Not supported"}'
95
        exit 0
96
esac
97

98
exit 1

展开收起

将上面脚本命名成 nfs，放置到 node1 节点对应的插件下面： /usr/libexec/kubernetes/kubelet-plugins/volume/exec/tianch~nfs/nfs，并设置权限为 700：

Terminal window

1
➜ chmod 700 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/tianch~nfs/nfs
2
# 安装 jq 工具
3
➜ yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
4
➜ yum install jq -y

这个时候我们部署一个应用到 node1 节点上，并用 flexVolume 来持久化容器中的数据（当然也可以通过定义 flexvolume 类型的 PV、PVC 来使用），如下所示：

Kubernetes-LocalDNS

Mon, 05 Jan 2026 00:00:00 GMT

超时原因#

在 iptables 模式下（默认情况下），每个服务的 kube-proxy 在主机网络名称空间的 nat 表中创建一些 iptables 规则。

比如在集群中具有两个 DNS 服务器实例的 kube-dns 服务，其相关规则大致如下所示：

Terminal window

1
(1) -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
2
<...>
3
(2) -A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
4
<...>
5
(3) -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-LLLB6FGXBLX6PZF7
6
(4) -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -j KUBE-SEP-LRVEW52VMYCOUSMZ
7
<...>
8
(5) -A KUBE-SEP-LLLB6FGXBLX6PZF7 -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.32.0.6:53
9
<...>
10
(6) -A KUBE-SEP-LRVEW52VMYCOUSMZ -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.32.0.7:53

我们知道每个 Pod 的 /etc/resolv.conf 文件中都有填充的 nameserver 10.96.0.10 这个条目。所以来自 Pod 的 DNS 查找请求将发送到 10.96.0.10，这是 kube-dns 服务的 ClusterIP 地址。

由于 (1) 请求进入 KUBE-SERVICE 链，然后匹配规则 (2)，最后根据 (3) 的 random 随机模式，跳转到 (5) 或 (6) 条目，将请求 UDP 数据包的目标 IP 地址修改为 DNS 服务器的实际 IP 地址，这是通过 DNAT 完成的。其中 10.32.0.6 和 10.32.0.7 是我们集群中 CoreDNS 的两个 Pod 副本的 IP 地址。

内核中的 DNAT#

DNAT 的主要职责是同时更改传出数据包的目的地，响应数据包的源，并确保对所有后续数据包进行相同的修改。后者严重依赖于连接跟踪机制，也称为 conntrack，它被实现为内核模块。conntrack 会跟踪系统中正在进行的网络连接。

conntrack 中的每个连接都由两个元组表示，一个元组用于原始请求（IP_CT_DIR_ORIGINAL），另一个元组用于答复（IP_CT_DIR_REPLY）。对于 UDP，每个元组都由源 IP 地址，源端口以及目标 IP 地址和目标端口组成，答复元组包含存储在 src 字段中的目标的真实地址。

例如，如果 IP 地址为 10.40.0.17 的 Pod 向 kube-dns 的 ClusterIP 发送一个请求，该请求被转换为 10.32.0.6，则将创建以下元组：

Terminal window

1
原始：src = 10.40.0.17 dst = 10.96.0.10 sport = 53378 dport = 53
2
回复：src = 10.32.0.6 dst = 10.40.0.17 sport = 53 dport = 53378

通过这些条目内核可以相应地修改任何相关数据包的目的地和源地址，而无需再次遍历 DNAT 规则，此外，它将知道如何修改回复以及应将回复发送给谁。创建 conntrack 条目后，将首先对其进行确认，然后如果没有已确认的 conntrack 条目具有相同的原始元组或回复元组，则内核将尝试确认该条目。conntrack 创建和 DNAT 的简化流程如下所示：

conntrack

您尚未安装任何 GPG 公钥出现rpm --import public.gpg.key,解决办法

Mon, 05 Jan 2026 00:00:00 GMT

解决办法#

Terminal window

1
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

然后执行

Terminal window

1
yum install xxx

SpringBoot统一参数校验

Mon, 05 Jan 2026 00:00:00 GMT

无法加载文件 xxx 因为在此系统上禁止运行脚本

Mon, 05 Jan 2026 00:00:00 GMT

1、在系统中搜索框]输入 Windos PowerShell

2、点击“管理员身份运行”

3、输入 set-ExecutionPolicy RemoteSigned回车

4、根据提示，输入A，回车

5、再次执行命令就可执行成功。

ssh使用秘钥文件登录仍然需要密码的解决方案

Mon, 02 Dec 2024 00:00:00 GMT

SSH 使用密钥文件登录时，通常不需要密码，但有几种情况可能会要求你输入密码。以下是一些常见的原因和解决方法：

1. 密钥文件的权限问题#

SSH 密钥文件的权限必须正确设置，通常需要是只有用户自己可以读写。否则，SSH 客户端会拒绝使用它，并提示输入密码。

解决方法：

检查并修改密钥文件的权限：

Terminal window

1
chmod 600 ~/.ssh/id_rsa

2. 密钥文件未添加到 SSH 代理#

如果你使用 SSH 代理（例如 ssh-agent）管理密钥，但密钥未添加到代理中，则可能会要求你输入密码。

解决方法：

将密钥添加到 SSH 代理：

Terminal window

1
eval "$(ssh-agent -s)"
2
ssh-add ~/.ssh/id_rsa

3. 服务器端未正确配置公钥认证#

服务器端的 SSH 配置文件可能未正确启用公钥认证，或公钥未正确添加到 ~/.ssh/authorized_keys 文件中。

解决方法：

确保服务器端的 SSH 配置文件（通常为 /etc/ssh/sshd_config）中包含以下行，并且未被注释：

Terminal window

1
PubkeyAuthentication yes
2
AuthorizedKeysFile .ssh/authorized_keys

确保你的公钥已正确添加到服务器上的 ~/.ssh/authorized_keys 文件中：

Terminal window

1
cat ~/.ssh/id_rsa.pub | ssh user@remote_host 'cat >> ~/.ssh/authorized_keys'

4. 密钥文件有密码保护#

你的私钥文件可能设置了密码短语保护。在这种情况下，SSH 客户端会要求你输入密码短语来解锁私钥文件。

解决方法：

在生成密钥时，不要设置密码短语，或者在需要时输入密码短语解锁密钥。

5. SSH 客户端未指定正确的密钥文件#

如果你有多个密钥文件，并且 SSH 客户端未使用正确的密钥文件，可能会提示输入密码。

解决方法：

在 SSH 命令中明确指定密钥文件：

Terminal window

1
ssh -i ~/.ssh/id_rsa user@remote_host

或者在 ~/.ssh/config 文件中为特定主机指定密钥文件：

Terminal window

1
Host remote_host
2
IdentityFile ~/.ssh/id_rsa
3
User user

6. SSH 配置文件中的错误#

客户端或服务器端的 SSH 配置文件中可能有错误，导致公钥认证未正常工作。

解决方法：

检查并修复客户端的 ~/.ssh/config 和服务器端的 /etc/ssh/sshd_config 文件中的配置错误。

7. 服务器权限问题#

服务器上 ~/.ssh 目录或 authorized_keys 文件的权限不正确，可能会导致 SSH 无法读取公钥。

解决方法：

确保 ~/.ssh 目录和 authorized_keys 文件的权限设置正确：

Terminal window

1
chmod 700 ~/.ssh
2
chmod 600 ~/.ssh/authorized_keys

8. SSH 服务需要重启#

在更改 SSH 配置文件后，需要重启 SSH 服务以应用更改。

解决方法：

在服务器上重启 SSH 服务：

Terminal window

1
sudo systemctl restart sshd

或者在某些系统上：

Terminal window

1
sudo service ssh restart

通过检查以上各项，你可以找出并解决 SSH 使用密钥文件登录时仍然要求输入密码的问题。SSH

Kubernetes-Prometheus

Thu, 14 Dec 2023 00:00:00 GMT

Prometheus 最初是 SoundCloud 构建的开源系统监控和报警工具，是一个独立的开源项目，于 2016 年加入了 CNCF 基金会，作为继 Kubernetes 之后的第二个托管项目。Prometheus 相比于其他传统监控工具主要有以下几个特点：

具有由 metric 名称和键/值对标识的时间序列数据的多维数据模型
有一个灵活的查询语言
不依赖分布式存储，只和本地磁盘有关
通过 HTTP 的服务拉取时间序列数据
也支持推送的方式来添加时间序列数据
还支持通过服务发现或静态配置发现目标
多种图形和仪表板支持

Prometheus 由多个组件组成，但是其中有些组件是可选的：

Prometheus Server：用于抓取指标、存储时间序列数据
exporter：暴露指标让任务来抓
pushgateway：push 的方式将指标数据推送到该网关
alertmanager：处理报警的报警组件
adhoc：用于数据查询

大多数 Prometheus 组件都是用 Go 编写的，因此很容易构建和部署为静态的二进制文件。下图是 Prometheus 官方提供的架构及其一些相关的生态系统组件：

prometheus architecture

整体流程比较简单，Prometheus 直接接收或者通过中间的 Pushgateway 网关被动获取指标数据，在本地存储所有的获取的指标数据，并对这些数据进行一些规则整理，用来生成一些聚合数据或者报警信息，Grafana 或者其他工具用来可视化这些数据。

安装#

由于 Prometheus 是 Golang 编写的程序，所以要安装的话也非常简单，只需要将二进制文件下载下来直接执行即可，前往地址：https://prometheus.io/download 下载最新版本即可。

Prometheus 是通过一个 YAML 配置文件来进行启动的，如果使用二进制的方式来启动的话，可以使用下面的命令：

Terminal window

1
./prometheus --config.file=prometheus.yml

其中 prometheus.yml 文件的基本配置如下：

1
global:
2
  scrape_interval: 15s
3
  evaluation_interval: 15s
4

5
rule_files:
6
# - "first.rules"
7
# - "second.rules"
8

9
scrape_configs:
10
  - job_name: prometheus
11
    static_configs:
12
      - targets: ["localhost:9090"]

上面这个配置文件中包含了 3 个模块：global、rule_files 和 scrape_configs。

global 模块控制 Prometheus Server 的全局配置：
- scrape_interval：表示 prometheus 抓取指标数据的频率，默认是 15s，我们可以覆盖这个值
- evaluation_interval：用来控制评估规则的频率，prometheus 使用规则产生新的时间序列数据或者产生警报
rule_files：指定了报警规则所在的位置，prometheus 可以根据这个配置加载规则，用于生成新的时间序列数据或者报警信息，当前没有配置任何报警规则。
scrape_configs 用于控制 prometheus 监控哪些资源。

由于 prometheus 通过 HTTP 的方式来暴露的它本身的监控数据，prometheus 也能够监控本身的健康情况。在默认的配置里有一个单独的 job，叫做 prometheus，它采集 prometheus 服务本身的时间序列数据。这个 job 包含了一个单独的、静态配置的目标：监听 localhost 上的 9090 端口。prometheus 默认会通过目标的 /metrics 路径采集 metrics。所以，默认的 job 通过 URL：http://localhost:9090/metrics 采集 metrics。收集到的时间序列包含 prometheus 服务本身的状态和性能。如果还有其他的资源需要监控的话，直接配置在 scrape_configs 模块下面就可以了。

示例应用#

比如在本地启动一些样例来让 Prometheus 采集。Go 客户端库包含一个示例，该示例为具有不同延迟分布的三个服务暴露 RPC 延迟。

首先确保已经安装了 Go 环境并启用 go modules，下载 Prometheus 的 Go 客户端库并运行这三个示例：

Terminal window

1
git clone https://github.com/prometheus/client_golang.git
2
cd client_golang/examples/random
3
export GO111MODULE=on
4
export GOPROXY=https://goproxy.cn
5
go build

然后在 3 个独立的终端里面运行 3 个服务：

Terminal window

1
./random -listen-address=:8080
2
./random -listen-address=:8081
3
./random -listen-address=:8082

这个时候可以得到 3 个不同的监控接口：http://localhost:8080/metrics、http://localhost:8081/metrics 和 http://localhost:8082/metrics。

然后配置 Prometheus 来采集这些新的目标，将这三个目标分组到一个名为 example-random 的任务。假设前两个端点（即：http://localhost:8080/metrics、http://localhost:8081/metrics ）都是生产级目标应用，第三个端点（即：http://localhost:8082/metrics ）为金丝雀实例。要在 Prometheus 中对此进行建模，可以将多组端点添加到单个任务中，为每组目标添加额外的标签。在此示例中，将 group =“production” 标签添加到第一组目标，同时将 group=“canary”添加到第二组。将以下配置添加到 prometheus.yml 中的 scrape_configs 部分，然后重新启动 Prometheus 实例：

1
scrape_configs:
2
  - job_name: "example-random"
3
    # Override the global default and scrape targets from this job every 5 seconds.
4
    scrape_interval: 5s
5
    static_configs:
6
      - targets: ["localhost:8080", "localhost:8081"]
7
        labels:
8
          group: "production"
9
      - targets: ["localhost:8082"]
10
        labels:
11
          group: "canary"

然后到浏览器中查看 Prometheus 的配置是否有新增的任务，这就是 Prometheus 添加监控配置最基本的配置方式了，非常简单，只需要提供一个符合 metrics 格式的可访问的接口配置给 Prometheus 就可以了。

image-20231213175934662

由于最终要运行在 Kubernetes 系统中，所以用 Docker 镜像的方式运行。

为了能够方便的管理配置文件，这里将 prometheus.yml 文件用 ConfigMap 的形式进行管理：prometheus-cm.yaml

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: prometheus-config
5
  namespace: monitor
6
data:
7
  prometheus.yml: |
8
    global:
9
      scrape_interval: 15s
10
      scrape_timeout: 15s
11
    scrape_configs:
12
    - job_name: 'prometheus'
13
      static_configs:
14
      - targets: ['localhost:9090']

这里暂时只配置了对 prometheus 本身的监控，直接创建该资源对象：

Terminal window

1
kubectl apply -f prometheus-cm.yaml

配置文件创建完成了，以后有新的资源需要被监控，只需要将上面的 ConfigMap 对象更新即可。现在创建 prometheus 的 Pod 资源：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: prometheus
5
  namespace: monitor
6
  labels:
7
    app: prometheus
8
spec:
9
  selector:
10
    matchLabels:
11
      app: prometheus
12
  template:
13
    metadata:
14
      labels:
15
        app: prometheus
16
    spec:
17
      serviceAccountName: prometheus
18
      containers:
19
        - image: prom/prometheus:v2.48.1
20
          name: prometheus
21
          args:
22
            - "--config.file=/etc/prometheus/prometheus.yml"
23
            - "--storage.tsdb.path=/prometheus" # 指定tsdb数据路径
24
            - "--storage.tsdb.retention.time=24h"
25
            - "--web.enable-admin-api" # 控制对admin HTTP API的访问，其中包括删除时间序列等功能
26
            - "--web.enable-lifecycle" # 支持热更新，直接执行localhost:9090/-/reload立即生效
27
          ports:
28
            - containerPort: 9090
29
              name: http
30
          volumeMounts:
31
            - mountPath: "/etc/prometheus"
32
              name: config-volume
33
            - mountPath: "/prometheus"
34
              name: data
35
          resources:
36
            requests:
37
              cpu: 100m
38
              memory: 512Mi
39
            limits:
40
              cpu: 100m
41
              memory: 512Mi
42
      volumes:
43
        - name: data
44
          persistentVolumeClaim:
45
            claimName: prometheus-data
46
        - configMap:
47
            name: prometheus-config
48
          name: config-volume

展开收起

另外为了 prometheus 的性能和数据持久化这里是直接将通过一个 LocalPV 来进行数据持久化的，通过 --storage.tsdb.path=/prometheus 指定数据目录，创建如下所示的一个 PVC 资源对象，注意是一个 LocalPV，和 node1 节点具有亲和性：prometheus-pv.yaml

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: prometheus-local
5
  labels:
6
    app: prometheus
7
spec:
8
  accessModes:
9
    - ReadWriteOnce
10
  capacity:
11
    storage: 20Gi
12
  storageClassName: local-storage
13
  local:
14
    path: /data/k8s/prometheus
15
  nodeAffinity:
16
    required:
17
      nodeSelectorTerms:
18
        - matchExpressions:
19
            - key: kubernetes.io/hostname
20
              operator: In
21
              values:
22
                - node1
23
  persistentVolumeReclaimPolicy: Retain
24
---
25
apiVersion: v1
26
kind: PersistentVolumeClaim
27
metadata:
28
  name: prometheus-data
29
  namespace: monitor
30
spec:
31
  selector:
32
    matchLabels:
33
      app: prometheus
34
  accessModes:
35
    - ReadWriteOnce
36
  resources:
37
    requests:
38
      storage: 20Gi
39
  storageClassName: local-storage

展开收起

由于 prometheus 可以访问 Kubernetes 的一些资源对象，所以需要配置 rbac 相关认证，这里使用了一个名为 prometheus 的 serviceAccount 对象：prometheus-rbac.yaml

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: prometheus
5
  namespace: monitor
6
---
7
apiVersion: rbac.authorization.k8s.io/v1
8
kind: ClusterRole
9
metadata:
10
  name: prometheus
11
rules:
12
  - apiGroups:
13
      - ""
14
    resources:
15
      - nodes
16
      - services
17
      - endpoints
18
      - pods
19
      - nodes/proxy
20
    verbs:
21
      - get
22
      - list
23
      - watch
24
  - apiGroups:
25
      - "extensions"
26
    resources:
27
      - ingresses
28
    verbs:
29
      - get
30
      - list
31
      - watch
32
  - apiGroups:
33
      - ""
34
    resources:
35
      - configmaps
36
      - nodes/metrics
37
    verbs:
38
      - get
39
  - nonResourceURLs:
40
      - /metrics
41
    verbs:
42
      - get
43
---
44
apiVersion: rbac.authorization.k8s.io/v1beta1
45
kind: ClusterRoleBinding
46
metadata:
47
  name: prometheus
48
roleRef:
49
  apiGroup: rbac.authorization.k8s.io
50
  kind: ClusterRole
51
  name: prometheus
52
subjects:
53
  - kind: ServiceAccount
54
    name: prometheus
55
    namespace: monitor

展开收起

由于要获取的资源信息，在每一个 namespace 下面都有可能存在，所以这里使用的是 ClusterRole 的资源对象，值得一提的是这里的权限规则声明中有一个 nonResourceURLs 的属性，是用来对非资源型 metrics 进行操作的权限声明，这个在以前很少遇到过，然后直接创建上面的资源对象即可：

Terminal window

1
kubectl apply -f prometheus-rbac.yaml

现在可以添加 promethues 的资源对象了：

Terminal window

1
kubectl apply -f prometheus-deploy.yaml

Terminal window

1
kubectl get pods -n monitor

创建 Pod 后，看到并没有成功运行，出现了 open /prometheus/queries.active: permission denied 这样的错误信息，这是因为 prometheus 的镜像中是使用的 nobody 用户，但是通过 LocalPV 挂载到宿主机上面的目录的 ownership 却是 root：

Terminal window

1
ls -la /data/k8s

所以当然会出现操作权限问题了，这个时候我们就可以通过 securityContext 来为 Pod 设置下 volumes 的权限，通过设置 runAsUser=0 指定运行的用户为 root，也可以通过设置一个 initContainer 来修改数据目录权限：

1
......
2
initContainers:
3
- name: fix-permissions
4
  image: busybox
5
  command: [chown, -R, "nobody:nobody", /prometheus]
6
  volumeMounts:
7
  - name: data
8
    mountPath: /prometheus

重新更新下 prometheus：

Terminal window

1
kubectl apply -f prometheus-deploy.yaml

Pod 创建成功后，为了能够在外部访问到 prometheus 的 webUI 服务，还需要创建一个 Service 对象：prometheus-svc.yaml

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: prometheus
5
  namespace: monitor
6
  labels:
7
    app: prometheus
8
spec:
9
  selector:
10
    app: prometheus
11
  type: NodePort
12
  ports:
13
    - name: web
14
      port: 9090
15
      targetPort: http

展开收起

为了方便测试，这里创建一个 NodePort 类型的服务:

Terminal window

1
kubectl apply -f prometheus-svc.yaml

还可以创建一个 Ingress对象，通过域名来进行访问：prometheus-ingress.yaml

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: prometheus-nginx
5
  namespace: monitor
6
spec:
7
  ingressClassName: nginx
8
  rules:
9
    - host: prometheus.tianch.com.cn
10
      http:
11
        paths:
12
          - path: /
13
            pathType: Prefix
14
            backend:
15
              service:
16
                name: prometheus-k8s
17
                port:
18
                  number: 9090

展开收起

Terminal window

1
kubectl apply -f prometheus-ingress.yaml

现在我们就可以通过域名或者http://任意节点IP:nodePort端口访问 prometheus 的 webUI 服务了。

应用监控#

前面介绍了 Prometheus 的数据指标是通过一个公开的 HTTP(S) 数据接口获取到的，不需要单独安装监控的 agent，只需要暴露一个 metrics 接口，Prometheus 就会定期去拉取数据；对于一些普通的 HTTP 服务，完全可以直接重用这个服务，添加一个 /metrics 接口暴露给 Prometheus；而且获取到的指标数据格式是非常易懂的，不需要太高的学习成本。

现在很多服务从一开始就内置了一个 /metrics 接口，比如 Kubernetes 的各个组件、istio 服务网格都直接提供了数据指标接口。有一些服务即使没有原生集成该接口，也完全可以使用一些 exporter 来获取到指标数据，比如 mysqld_exporter、node_exporter，这些 exporter 就有点类似于传统监控服务中的 agent，作为服务一直存在，用来收集目标服务的指标数据然后直接暴露给 Prometheus。

普通应用#

对于普通应用只需要能够提供一个满足 prometheus 格式要求的 /metrics 接口就可以让 Prometheus 来接管监控，比如 Kubernetes 集群中非常重要的 CoreDNS 插件，一般默认情况下就开启了 /metrics 接口：

Terminal window

1
kubectl get cm coredns -n kube-system -o yaml

1
apiVersion: v1
2
data:
3
  Corefile: |
4
    .:53 {
5
        errors
6
        health {
7
           lameduck 5s
8
        }
9
        ready
10
        kubernetes cluster.local in-addr.arpa ip6.arpa {
11
           pods insecure
12
           fallthrough in-addr.arpa ip6.arpa
13
           ttl 30
14
        }
15
        prometheus :9153
16
        forward . /etc/resolv.conf {
17
           max_concurrent 1000
18
        }
19
        cache 30
20
        loop
21
        reload
22
        loadbalance
23
    }
24
kind: ConfigMap
25
metadata:
26
  creationTimestamp: "2023-11-14T08:49:41Z"
27
  name: coredns
28
  namespace: kube-system
29
  resourceVersion: "234"
30
  uid: febb80f5-bfc7-483b-8484-387e31d7f8ef

展开收起

上面 ConfigMap 中 prometheus :9153 就是开启 prometheus 的插件：

image-20231214153614761

可以先尝试手动访问下 /metrics 接口，如果能够手动访问到那证明接口是没有任何问题的。

可以看到可以正常访问到，从这里可以看到 CoreDNS 的监控数据接口是正常的了，然后就可以将这个 /metrics 接口配置到 prometheus.yml 中去了，直接加到默认的 prometheus 这个 job 下面：

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: prometheus-config
5
  namespace: monitor
6
data:
7
  prometheus.yml: |
8
    global:
9
      scrape_interval: 15s
10
      scrape_timeout: 15s
11

12
    scrape_configs:
13
    - job_name: 'prometheus'
14
      static_configs:
15
        - targets: ['localhost:9090']
16

17
    - job_name: 'coredns'
18
      static_configs:
19
        - targets: ['10.233.90.117:9153', '10.233.90.122:9153']

展开收起

这里只是一个很简单的配置，scrape_configs 下面可以支持很多参数，例如：

basic_auth 和 bearer_token：比如我们提供的 /metrics 接口需要 basic 认证的时候，通过传统的用户名/密码或者在请求的 header 中添加对应的 token 都可以支持
kubernetes_sd_configs 或 consul_sd_configs：可以用来自动发现一些应用的监控数据

重新更新这个 ConfigMap 资源对象：

Terminal window

1
kubectl apply -f prometheus-cm.yaml

现在 Prometheus 的配置文件内容已经更改了，过一会儿被挂载到 Pod 中的 prometheus.yml 文件也会更新，由于之前的 Prometheus 启动参数中添加了 --web.enable-lifecycle 参数，所以现在只需要执行一个 reload 命令即可让配置生效：

Terminal window

1
kubectl get pods -n monitor -o wide

由于 ConfigMap 通过 Volume 的形式挂载到 Pod 中去的热更新需要一定的间隔时间才会生效，所以需要稍微等一小会儿。

再去看 Prometheus 的 Dashboard 中查看采集的目标数据：

prometheus webui coredns

可以看到刚刚添加的 coredns 这个任务已经出现了，同样的可以切换到 Graph 下面去，可以找到一些 CoreDNS 的指标数据，至于这些指标数据代表什么意义，一般情况下，可以去查看对应的 /metrics 接口，里面一般情况下都会有对应的注释。

使用exporter监控#

上面说过有一些应用可能没有自带 /metrics 接口供 Prometheus 使用，在这种情况下，就需要利用 exporter 服务来为 Prometheus 提供指标数据了。Prometheus 官方为许多应用就提供了对应的 exporter 应用，也有许多第三方的实现，可以前往官方网站进行查看：exporters，当然如果你的应用本身也没有 exporter 实现，那么就要自己想办法去实现一个 /metrics 接口了，只要你能提供一个合法的 /metrics 接口，Prometheus 就可以监控你的应用。

比如这里通过一个 redis-exporter 的服务来监控 redis 服务，对于这类应用，一般会以 sidecar 的形式和主应用部署在同一个 Pod 中，比如这里部署一个 redis 应用，并用 redis-exporter 的方式来采集监控数据供 Prometheus 使用，如下资源清单文件：6.prometheus-redis.yaml

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: redis
5
  namespace: monitor
6
spec:
7
  selector:
8
    matchLabels:
9
      app: redis
10
  template:
11
    metadata:
12
      labels:
13
        app: redis
14
    spec:
15
      containers:
16
        - name: redis
17
          image: redis:6
18
          resources:
19
            limits:
20
              cpu: 100m
21
              memory: 100Mi
22
          ports:
23
            - containerPort: 6379
24
        - name: redis-exporter
25
          image: oliver006/redis_exporter:latest
26
          resources:
27
            limits:
28
              cpu: 100m
29
              memory: 100Mi
30
          ports:
31
            - containerPort: 9121
32
---
33
kind: Service
34
apiVersion: v1
35
metadata:
36
  name: redis
37
  namespace: monitor
38
spec:
39
  selector:
40
    app: redis
41
  ports:
42
    - name: redis
43
      port: 6379
44
      targetPort: 6379
45
    - name: prometheus
46
      port: 9121
47
      targetPort: 9121

展开收起

可以看到上面 redis 这个 Pod 中包含了两个容器，一个就是 redis 本身的主应用，另外一个容器就是 redis_exporter。现在直接创建上面的应用：

Terminal window

1
kubectl apply -f prome-redis.yaml

image-20231214155638181

创建完成后，可以看到 redis 的 Pod 里面包含有两个容器：

image-20231214155829925

可以通过 9121 端口来校验是否能够采集到数据：

Terminal window

1
curl 10.233.26.191:9121/metrics

同样的，现在只需要更新 Prometheus 的配置文件：

1
- job_name: "redis"
2
  static_configs:
3
    - targets: ["redis:9121"]

由于这里是通过 Service 去配置的 redis 服务，当然直接配置 Pod IP 也是可以的，因为和 Prometheus 处于同一个 namespace，所以直接使用 servicename 即可。配置文件更新后，重新加载：

Terminal window

1
➜ kubectl apply -f prometheus-cm.yaml
2
configmap/prometheus-config configured
3
# 隔一会儿执行reload操作
4
➜ curl -X POST "http://10.233.26.191:9090/-/reload"

这个时候再去看 Prometheus 的 Dashboard 中查看采集的目标数据：

prometheus webui redis

可以看到配置的 redis 这个 job 已经生效了。切换到 Graph 下面可以看到很多关于 redis 的指标数据，选择任意一个指标，比如 redis_exporter_scrapes_total，然后点击执行就可以看到对应的数据图表了：

prometheus webui redisquery

集群节点#

上面记录了用 Promethues 来监控 Kubernetes 集群中的应用，但是对于 Kubernetes 集群本身的监控也是非常重要的，需要时时刻刻了解集群的运行状态。

对于集群的监控一般需要考虑以下几个方面：

Kubernetes 节点的监控：比如节点的 cpu、load、disk、memory 等指标
内部系统组件的状态：比如 kube-scheduler、kube-controller-manager、kubedns/coredns 等组件的详细运行状态
编排级的 metrics：比如 Deployment 的状态、资源请求、调度和 API 延迟等数据指标

Kubernetes 集群的监控方案目前主要有以下几种方案：

Heapster：Heapster 是一个集群范围的监控和数据聚合工具，以 Pod 的形式运行在集群中。 heapster 除了 Kubelet/cAdvisor 之外，还可以向 Heapster 添加其他指标源数据，比如 kube-state-metrics，需要注意的是 Heapster 已经被废弃了，后续版本中会使用 metrics-server 代替。
cAdvisor：cAdvisor 是 Google 开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持 Docker 容器。
kube-state-metrics：kube-state-metrics 通过监听 API Server 生成有关资源对象的状态指标，比如 Deployment、Node、Pod，需要注意的是 kube-state-metrics 只是简单提供一个 metrics 数据，并不会存储这些指标数据，所以可以使用 Prometheus 来抓取这些数据然后存储。
metrics-server：metrics-server 也是一个集群范围内的资源数据聚合工具，是 Heapster 的替代品，同样的，metrics-server 也只是显示数据，并不提供数据存储服务。

不过 kube-state-metrics 和 metrics-server 之间还是有很大不同的，二者的主要区别如下：

kube-state-metrics 主要关注的是业务相关的一些元数据，比如 Deployment、Pod、副本状态等
metrics-server 主要关注的是资源度量 API 的实现，比如 CPU、文件描述符、内存、请求延时等指标。

监控集群节点#

要监控节点其实已经有很多非常成熟的方案了，比如 Nagios、zabbix，甚至自己来收集数据也可以，这里通过 Prometheus 来采集节点的监控指标数据，可以通过 node_exporter 来获取，顾名思义，node_exporter 就是抓取用于采集服务器节点的各种运行指标，目前 node_exporter 支持几乎所有常见的监控点，比如 conntrack，cpu，diskstats，filesystem，loadavg，meminfo，netstat 等，详细的监控点列表可以参考其 Github 仓库。

可以通过 DaemonSet 控制器来部署该服务，这样每一个节点都会自动运行一个这样的 Pod，如果从集群中删除或者添加节点后，也会进行自动扩展。

在部署 node-exporter 的时候有一些细节需要注意，如下资源清单文件：prome-node-exporter.yaml

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: node-exporter
5
  namespace: monitor
6
  labels:
7
    app: node-exporter
8
spec:
9
  selector:
10
    matchLabels:
11
      app: node-exporter
12
  template:
13
    metadata:
14
      labels:
15
        app: node-exporter
16
    spec:
17
      hostPID: true
18
      hostIPC: true
19
      hostNetwork: true
20
      nodeSelector:
21
        kubernetes.io/os: linux
22
      containers:
23
        - name: node-exporter
24
          image: prom/node-exporter:v1.3.1
25
          args:
26
            - --web.listen-address=$(HOSTIP):9100
27
            - --path.procfs=/host/proc
28
            - --path.sysfs=/host/sys
29
            - --path.rootfs=/host/root
30
            - --no-collector.hwmon # 禁用不需要的一些采集器
31
            - --no-collector.nfs
32
            - --no-collector.nfsd
33
            - --no-collector.nvme
34
            - --no-collector.dmi
35
            - --no-collector.arp
36
            - --collector.filesystem.ignored-mount-points=^/(dev|proc|sys|var/lib/containerd/.+|/var/lib/docker/.+|var/lib/kubelet/pods/.+)($|/)
37
            - --collector.filesystem.ignored-fs-types=^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$
38
          ports:
39
            - containerPort: 9100
40
          env:
41
            - name: HOSTIP
42
              valueFrom:
43
                fieldRef:
44
                  fieldPath: status.hostIP
45
          resources:
46
            requests:
47
              cpu: 150m
48
              memory: 180Mi
49
            limits:
50
              cpu: 150m
51
              memory: 180Mi
52
          securityContext:
53
            runAsNonRoot: true
54
            runAsUser: 65534
55
          volumeMounts:
56
            - name: proc
57
              mountPath: /host/proc
58
            - name: sys
59
              mountPath: /host/sys
60
            - name: root
61
              mountPath: /host/root
62
              mountPropagation: HostToContainer
63
              readOnly: true
64
      tolerations:
65
        - operator: "Exists"
66
      volumes:
67
        - name: proc
68
          hostPath:
69
            path: /proc
70
        - name: dev
71
          hostPath:
72
            path: /dev
73
        - name: sys
74
          hostPath:
75
            path: /sys
76
        - name: root
77
          hostPath:
78
            path: /

展开收起

由于要获取到的数据是主机的监控指标数据，而 node-exporter 是运行在容器中的，所以在 Pod 中需要配置一些 Pod 的安全策略，这里就添加了 hostPID: true、hostIPC: true、hostNetwork: true 3 个策略，用来使用主机的 PID namespace、IPC namespace 以及主机网络，这些 namespace 就是用于容器隔离的关键技术，要注意这里的 namespace 和集群中的 namespace 是两个完全不相同的概念。

另外还将主机的 /dev、/proc、/sys这些目录挂载到容器中，这些因为采集的很多节点数据都是通过这些文件夹下面的文件来获取到的，比如在使用 top 命令可以查看当前 cpu 使用情况，数据就来源于文件 /proc/stat，使用 free 命令可以查看当前内存使用情况，其数据来源是来自 /proc/meminfo 文件。

另外由于集群使用的是 kk 搭建的，所以如果希望 master 节点也一起被监控，则需要添加相应的容忍，然后直接创建上面的资源对象：

Terminal window

1
kubectl apply -f prome-node-exporter.yaml

Terminal window

1
kubectl get pods -n kubesphere-monitoring-system -l app.kubernetes.io/name=node-exporter -o wide

image-20231214161806622

部署完成后，可以看到在几个节点上都运行了一个 Pod，由于指定了 hostNetwork=true，所以在每个节点上就会绑定一个端口 9100，我们可以通过这个端口去获取到监控指标数据：

Terminal window

1
curl 10.168.1.21:9100/metrics
2
...
3
node_filesystem_device_error{device="shm",fstype="tmpfs",mountpoint="/rootfs/var/lib/docker/containers/aefe8b1b63c3aa5f27766053ec817415faf8f6f417bb210d266fef0c2da64674/shm"} 1
4
node_filesystem_device_error{device="shm",fstype="tmpfs",mountpoint="/rootfs/var/lib/docker/containers/c8652ca72230496038a07e4fe4ee47046abb5f88d9d2440f0c8a923d5f3e133c/shm"} 1
5
node_filesystem_device_error{device="tmpfs",fstype="tmpfs",mountpoint="/dev"} 0
6
node_filesystem_device_error{device="tmpfs",fstype="tmpfs",mountpoint="/dev/shm"} 0
7
...

当然如果觉得上面的手动安装方式比较麻烦，也可以使用 Helm 的方式来安装：

Terminal window

1
helm upgrade --install node-exporter --namespace monitor stable/prometheus-node-exporter

服务发现#

由于每个节点上面都运行了 node-exporter 程序，如果通过一个 Service 来将数据收集到一起用静态配置的方式配置到 Prometheus 去中，就只会显示一条数据，就得自己在指标数据中去过滤每个节点的数据，当然也可以手动的把所有节点用静态的方式配置到 Prometheus 中去，但是以后要新增或者去掉节点的时候就还得手动去配置，那么有没有一种方式可以让 Prometheus 去自动发现节点的 node-exporter 程序，并且按节点进行分组呢？这就是 Prometheus 里面非常重要的服务发现功能了。

在 Kubernetes 下，Promethues 通过与 Kubernetes API 集成，主要支持 5 中服务发现模式，分别是：Node、Service、Pod、Endpoints、Ingress。

通过 kubectl 命令可以很方便的获取到当前集群中的所有节点信息：

Terminal window

1
kubectl get node

但是要让 Prometheus 也能够获取到当前集群中的所有节点信息的话，就需要利用 Node 的服务发现模式，同样的，在 prometheus.yml 文件中配置如下的 job 任务即可：

1
- job_name: "nodes"
2
  kubernetes_sd_configs:
3
    - role: node

通过指定 kubernetes_sd_configs 的模式为 node，Prometheus 就会自动从 Kubernetes 中发现所有的 node 节点并作为当前 job 监控的目标实例，发现的节点 /metrics 接口是默认的 kubelet 的 HTTP 接口。

prometheus 的 ConfigMap 更新完成后，执行 reload 操作，让配置生效：

Terminal window

1
 kubectl apply -f prometheus-cm.yaml
2
# 隔一会儿执行reload操作
3
 curl -X POST "http://10.233.26.191:9090/-/reload"

配置生效后，再去 prometheus 的 dashboard 中查看 Targets 是否能够正常抓取数据

image-20231214164925929

可以看到上面的 nodes 这个 job 任务已经自动发现了我们 4 个 node 节点，但是在获取数据的时候失败了，出现了类似于下面的错误信息：

Terminal window

1
server returned HTTP status 400 Bad Request

这个是因为 prometheus 去发现 Node 模式的服务的时候，访问的端口默认是 10250，而默认是需要认证的 https 协议才有权访问的，但实际上并不是希望让去访问 10250 端口的 /metrics 接口，而是 node-exporter 绑定到节点的 9100 端口，所以应该将这里的 10250 替换成 9100，但是应该怎样替换呢？

这里就需要使用到 Prometheus 提供的 relabel_configs 中的 replace 能力了，relabel 可以在 Prometheus 采集数据之前，通过 Target 实例的 Metadata 信息，动态重新写入 Label 的值。除此之外，还能根据 Target 实例的 Metadata 信息选择是否采集或者忽略该 Target 实例。比如这里就可以去匹配 __address__ 这个 Label 标签，然后替换掉其中的端口，如果不知道有哪些 Label 标签可以操作的话，可以在 Service Discovery 页面获取到相关的元标签，这些标签都是可以进行 Relabel 的标签：

image-20231214165110714

替换掉端口，修改 ConfigMap：

1
- job_name: "nodes"
2
  kubernetes_sd_configs:
3
    - role: node
4
  relabel_configs:
5
    - source_labels: [__address__]
6
      regex: "(.*):10250"
7
      replacement: "${1}:9100"
8
      target_label: __address__
9
      action: replace

这里就是一个正则表达式，去匹配 __address__ 这个标签，然后将 host 部分保留下来，port 替换成了 9100，重新更新配置文件，执行 reload 操作，然后再去看 Prometheus 的 Dashboard 的 Targets 路径下面 kubernetes-nodes 这个 job 任务是否正常了。

但是还有一个问题就是采集的指标数据 Label 标签就只有一个节点的 hostname，这对于在进行监控分组分类查询的时候带来了很多不方便的地方，要是能够将集群中 Node 节点的 Label 标签也能获取到就很好了。这里我们可以通过 labelmap 这个属性来将 Kubernetes 的 Label 标签添加为 Prometheus 的指标数据的标签：

1
- job_name: "kubernetes-nodes"
2
  kubernetes_sd_configs:
3
    - role: node
4
  relabel_configs:
5
    - source_labels: [__address__]
6
      regex: "(.*):10250"
7
      replacement: "${1}:9100"
8
      target_label: __address__
9
      action: replace
10
    - action: labelmap
11
      regex: __meta_kubernetes_node_label_(.+)

添加了一个 action 为 labelmap，正则表达式是 __meta_kubernetes_node_label_(.+) 的配置，这里的意思就是表达式中匹配都的数据也添加到指标数据的 Label 标签中去。

对于 kubernetes_sd_configs 下面可用的元信息标签如下：

__meta_kubernetes_node_name：节点对象的名称
_meta_kubernetes_node_label：节点对象中的每个标签
_meta_kubernetes_node_annotation：来自节点对象的每个注释
_meta_kubernetes_node_address：每个节点地址类型的第一个地址（如果存在）

关于 kubernets_sd_configs 更多信息可以查看官方文档：kubernetes_sd_config

另外由于 kubelet 也自带了一些监控指标数据，就上面提到的 10250 端口，所以这里也把 kubelet 的监控任务也一并配置上：

1
- job_name: "kubelet"
2
  kubernetes_sd_configs:
3
    - role: node
4
  scheme: https
5
  tls_config:
6
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
7
    insecure_skip_verify: true
8
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
9
  relabel_configs:
10
    - action: labelmap
11
      regex: __meta_kubernetes_node_label_(.+)

但是这里需要特别注意的是这里必须使用 https 协议访问，这样就必然需要提供证书，这里是通过配置 insecure_skip_verify: true 来跳过了证书校验，但是除此之外，要访问集群的资源，还必须要有对应的权限才可以，也就是对应的 ServiceAccount 棒的权限允许才可以，这里部署的 prometheus 关联的 ServiceAccount 对象前面已经提到过了，这里只需要将 Pod 中自动注入的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 和 /var/run/secrets/kubernetes.io/serviceaccount/token 文件配置上，就可以获取到对应的权限了。

现在再去更新下配置文件，执行 reload 操作，让配置生效，然后访问 Prometheus 的 Dashboard 查看 Targets 路径：

prometheus webui sd kubelet

现在可以看到上面添加的 kubernetes-kubelet 和 kubernetes-nodes 这两个 job 任务都已经配置成功了，而且二者的 Labels 标签都和集群的 node 节点标签保持一致了。

现在就可以切换到 Graph 路径下面查看采集的一些指标数据了，比如查询 node_load1 指标：

image-20231214165632117

可以看到将几个节点对应的 node_load1 指标数据都查询出来了，同样的，还可以使用 PromQL 语句来进行更复杂的一些聚合查询操作，还可以根据 Labels 标签对指标数据进行聚合，比如这里只查询 node1 节点的数据，可以使用表达式 node_load1{instance="node1"} 来进行查询：

image-20231214165741090

到这里就把 Kubernetes 集群节点使用 Prometheus 监控起来了，接下来我们再学习怎样监控 Pod 或者 Service 之类的资源对象。

容器监控#

说到容器监控自然会想到 cAdvisor，前面也说过 cAdvisor 已经内置在了 kubelet 组件之中，所以不需要单独去安装，cAdvisor 的数据路径为 /api/v1/nodes/<node>/proxy/metrics，但是不推荐使用这种方式，因为这种方式是通过 APIServer 去代理访问的，对于大规模的集群比如会对 APIServer 造成很大的压力，所以可以直接通过访问 kubelet 的 /metrics/cadvisor 这个路径来获取 cAdvisor 的数据，同样这里使用 node 的服务发现模式，因为每一个节点下面都有 kubelet，自然都有 cAdvisor 采集到的数据指标，配置如下：

1
- job_name: "kubernetes-cadvisor"
2
  kubernetes_sd_configs:
3
    - role: node
4
  scheme: https
5
  tls_config:
6
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
7
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
8
  relabel_configs:
9
    - action: labelmap
10
      regex: __meta_kubernetes_node_label_(.+)
11
      replacement: $1
12
    - source_labels: [__meta_kubernetes_node_name]
13
      regex: (.+)
14
      replacement: /metrics/cadvisor # <nodeip>/metrics -> <nodeip>/metrics/cadvisor
15
      target_label: __metrics_path__
16
# 下面的方式不推荐使用
17
# - target_label: __address__
18
#   replacement: kubernetes.default.svc:443
19
# - source_labels: [__meta_kubernetes_node_name]
20
#   regex: (.+)
21
#   target_label: __metrics_path__
22
#   replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

展开收起

上面的配置和之前配置 node-exporter 的时候几乎是一样的，区别是这里使用了 https 的协议，另外需要注意的是配置了 ca.cart 和 token 这两个文件，这两个文件是 Pod 启动后自动注入进来的，然后加上 __metrics_path__ 的访问路径 /metrics/cadvisor，现在同样更新下配置，然后查看 Targets 路径：

prometheus webui cadvisor

可以切换到 Graph 路径下面查询容器相关数据，比如这里来查询集群中所有 Pod 的 CPU 使用情况，kubelet 中的 cAdvisor 采集的指标和含义，可以查看 Monitoring cAdvisor with Prometheus 说明，其中有一项：

1
container_cpu_usage_seconds_total   Counter     Cumulative cpu time consumed    seconds

container_cpu_usage_seconds_total 是容器累计使用的 CPU 时间，用它除以 CPU 的总时间，就可以得到容器的 CPU 使用率了：

首先计算容器的 CPU 占用时间，由于节点上的 CPU 有多个，所以需要将容器在每个 CPU 上占用的时间累加起来，Pod 在 1m 内累积使用的 CPU 时间为：(根据 pod 和 namespace 进行分组查询)

1
sum(rate(container_cpu_usage_seconds_total{image!="",pod!=""}[1m])) by (namespace, pod)

**METRICS 变化:**在 Kubernetes 1.16 版本中移除了 cadvisor metrics 的 pod_name 和 container_name 这两个标签，改成了 pod 和 container。

“Removed cadvisor metric labels pod_name and container_name to match instrumentation guidelines. Any Prometheus queries that match pod_name and container_name labels (e.g. cadvisor or kubelet probe metrics) must be updated to use pod and container instead. (#80376, @ehashman)”

然后计算 CPU 的总时间，这里的 CPU 数量是容器分配到的 CPU 数量，container_spec_cpu_quota 是容器的 CPU 配额，它的值是容器指定的 CPU 个数 * 100000，所以 Pod 在 1s 内 CPU 的总时间为：Pod 的 CPU 核数 * 1s：

1
sum(container_spec_cpu_quota{image!="", pod!=""}) by(namespace, pod) / 100000

**CPU 配额:**由于 container_spec_cpu_quota 是容器的 CPU 配额，所以只有配置了 resource-limit CPU 的 Pod 才可以获得该指标数据。

将上面这两个语句的结果相除，就得到了容器的 CPU 使用率：

1
(sum(rate(container_cpu_usage_seconds_total{image!="",pod!=""}[1m])) by (namespace, pod))
2
/
3
(sum(container_spec_cpu_quota{image!="", pod!=""}) by(namespace, pod) / 100000) * 100

在 promethues 里面执行上面的 promQL 语句可以得到下面的结果：

prometheus cadvisor cpu rate

Pod 内存使用率的计算就简单多了，直接用内存实际使用量除以内存限制使用量即可：

1
sum(container_memory_rss{image!=""}) by(namespace, pod) / sum(container_spec_memory_limit_bytes{image!=""}) by(namespace, pod) * 100 != +inf

在 promethues 里面执行上面的 promQL 语句可以得到下面的结果：

prometheus cadvisor memory rate

监控apiserver#

apiserver 作为 Kubernetes 最核心的组件，当然他的监控也是非常有必要的，对于 apiserver 的监控可以直接通过 kubernetes 的 Service 来获取：

Terminal window

1
kubectl get svc

上面这个 Service 就是集群的 apiserver 在集群内部的 Service 地址，要自动发现 Service 类型的服务，就需要用到 role 为 Endpoints 的 kubernetes_sd_configs，可以在 ConfigMap 对象中添加上一个 Endpoints 类型的服务的监控任务：

1
- job_name: "kubernetes-apiservers"
2
  kubernetes_sd_configs:
3
    - role: endpoints

上面这个任务是定义的一个类型为 endpoints 的 kubernetes_sd_configs ，添加到 Prometheus 的 ConfigMap 的配置文件中，然后更新配置：

Terminal window

1
kubectl apply -f prometheus-cm.yaml
2
curl -X POST "http://10.244.3.174:9090/-/reload"

更新完成后，再去查看 Prometheus 的 Dashboard 的 target 页面：

prometheus webui apiserver

可以看到 kubernetes-apiservers 下面出现了很多实例，这是因为这里使用的是 Endpoints 类型的服务发现，所以 Prometheus 把所有的 Endpoints 服务都抓取过来了，同样的，上面需要的服务名为 kubernetes 这个 apiserver 的服务也在这个列表之中，那么应该怎样来过滤出这个服务来呢？还记得前面的 relabel_configs 吗？没错，同样需要使用这个配置，只是这里不是使用 replace 这个动作了，而是 keep，就是只把符合要求的给保留下来，哪些才是符合要求的呢？可以把鼠标放置在任意一个 target 上，可以查看到 Before relabeling里面所有的元数据，比如要过滤的服务是 default 这个 namespace 下面，服务名为 kubernetes 的元数据，所以这里就可以根据对应的 __meta_kubernetes_namespace 和 __meta_kubernetes_service_name 这两个元数据来 relabel，另外由于 kubernetes 这个服务对应的端口是 443，需要使用 https 协议，所以这里需要使用 https 的协议，对应的就需要将 ca 证书配置上，如下所示：

1
- job_name: "kubernetes-apiservers"
2
  kubernetes_sd_configs:
3
    - role: endpoints
4
  scheme: https
5
  tls_config:
6
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
7
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
8
  relabel_configs:
9
    - source_labels:
10
        [
11
          __meta_kubernetes_namespace,
12
          __meta_kubernetes_service_name,
13
          __meta_kubernetes_endpoint_port_name,
14
        ]
15
      action: keep
16
      regex: default;kubernetes;https

展开收起

现在重新更新配置文件、重新加载 Prometheus，切换到 Prometheus 的 Targets 路径下查看：

prometheus apiserver target

现在可以看到 kubernetes-apiserver 这个任务下面只有 apiserver 这一个实例了，证明 relabel 是成功的，现在切换到 Graph 路径下面查看下采集到的数据，比如查询 apiserver 的总的请求数：

prometheus apiserver rate

这样就完成了对 Kubernetes APIServer 的监控。

另外如果要来监控其他系统组件，比如 kube-controller-manager、kube-scheduler 的话应该怎么做呢？由于 apiserver 服务 namespace 在 default 使用默认的 Service kubernetes，而其余组件服务在 kube-system 这个 namespace 下面，如果想要来监控这些组件的话，需要手动创建单独的 Service，其中 kube-sheduler 的指标数据端口为 10251，kube-controller-manager 对应的端口为 10252，大家可以尝试下自己来配置下这几个系统组件。

监控 Pod#

上面的 apiserver 实际上就是一种特殊的 Endpoints，现在同样来配置一个任务用来专门发现普通类型的 Endpoint，其实就是 Service 关联的 Pod 列表：

1
- job_name: "kubernetes-endpoints"
2
  kubernetes_sd_configs:
3
    - role: endpoints
4
  relabel_configs:
5
    - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
6
      action: keep
7
      regex: true
8
    - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
9
      action: replace
10
      target_label: __scheme__
11
      regex: (https?)
12
    - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
13
      action: replace
14
      target_label: __metrics_path__
15
      regex: (.+)
16
    - source_labels:
17
        [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
18
      action: replace
19
      target_label: __address__
20
      regex: ([^:]+)(?::\d+)?;(\d+) # RE2 正则规则，+是一次多多次，?是0次或1次，其中?:表示非匹配组(意思就是不获取匹配结果)
21
      replacement: $1:$2
22
    - action: labelmap
23
      regex: __meta_kubernetes_service_label_(.+)
24
    - source_labels: [__meta_kubernetes_namespace]
25
      action: replace
26
      target_label: kubernetes_namespace
27
    - source_labels: [__meta_kubernetes_service_name]
28
      action: replace
29
      target_label: kubernetes_name
30
    - source_labels: [__meta_kubernetes_pod_name]
31
      action: replace
32
      target_label: kubernetes_pod_name

展开收起

注意这里在 relabel_configs 区域做了大量的配置，特别是第一个保留 __meta_kubernetes_service_annotation_prometheus_io_scrape 为 true 的才保留下来，这就是说要想自动发现集群中的 Endpoint，就需要在 Service 的 annotation 区域添加 prometheus.io/scrape=true 的声明，现在先将上面的配置更新，查看下效果：

prometheus k8s endpoints

可以看到 kubernetes-endpoints 这一个任务下面只发现了两个服务，这是因为在 relabel_configs 中过滤了 annotation 有 prometheus.io/scrape=true 的 Service，而现在我们系统中只有这样一个 kube-dns 服务符合要求，该 Service 下面有两个实例，所以出现了两个实例：

Terminal window展开收起

1
kubectl get svc kube-dns -n kube-system -o yaml
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  annotations:
6
    prometheus.io/port: "9153"  # metrics 接口的端口
7
    prometheus.io/scrape: "true"  # 这个注解可以让prometheus自动发现
8
  creationTimestamp: "2019-11-08T11:59:50Z"
9
  labels:
10
    k8s-app: kube-dns
11
    kubernetes.io/cluster-service: "true"
12
    kubernetes.io/name: KubeDNS
13
  name: kube-dns
14
  namespace: kube-system
15
......

展开收起

现在在之前创建的 redis 这个 Service 中添加上 prometheus.io/scrape=true 这个 annotation：(prometheus-redis.yaml)

1
kind: Service
2
apiVersion: v1
3
metadata:
4
  name: redis
5
  namespace: monitor
6
  annotations:
7
    prometheus.io/scrape: "true"
8
    prometheus.io/port: "9121"
9
spec:
10
  selector:
11
    app: redis
12
  ports:
13
    - name: redis
14
      port: 6379
15
      targetPort: 6379
16
    - name: prom
17
      port: 9121
18
      targetPort: 9121

展开收起

由于 redis 服务的 metrics 接口在 9121 这个 redis-exporter 服务上面，所以还需要添加一个 prometheus.io/port=9121 这样的 annotations，然后更新这个 Service：

Terminal window

1
kubectl apply -f prometheus-redis.yaml

更新完成后，去 Prometheus 查看 Targets 路径，可以看到 redis 服务自动出现在了 kubernetes-endpoints 这个任务下面：

prometheus k8s endpoints redis

这样以后我们有了新的服务，服务本身提供了 /metrics 接口，我们就完全不需要用静态的方式去配置了，到这里我们就可以将之前配置的 redis 的静态配置去掉了。

kube-state-metrics#

上面配置了自动发现 Endpoints 的监控，但是这些监控数据都是应用内部的监控，需要应用本身提供一个 /metrics 接口，或者对应的 exporter 来暴露对应的指标数据，但是在 Kubernetes 集群上 Pod、DaemonSet、Deployment、Job、CronJob 等各种资源对象的状态也需要监控，这也反映了使用这些资源部署的应用的状态。比如：

我调度了多少个副本？现在可用的有几个？
多少个 Pod 是 running/stopped/terminated 状态？
Pod 重启了多少次？
有多少 job 在运行中等等

通过查看前面从集群中拉取的指标(这些指标主要来自 apiserver 和 kubelet 中集成的 cAdvisor)，并没有具体的各种资源对象的状态指标。对于 Prometheus 来说，当然是需要引入新的 exporter 来暴露这些指标，Kubernetes 提供了一个kube-state-metrics 就是我们需要的。

与 metric-server 的对比#

metric-server 是从 APIServer 中获取 cpu、内存使用率这种监控指标，并把他们发送给存储后端，如 influxdb 或云厂商，当前的核心作用是为 HPA 等组件提供决策指标支持。
kube-state-metrics 关注于获取 Kubernetes 各种资源的最新状态，如 deployment 或者 daemonset，metric-server 仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而 kube-state-metrics 是获取集群最新的指标。
像 Prometheus 这种监控系统，并不会去用 metric-server 中的数据，他都是自己做指标收集、集成的，但 Prometheus 可以监控 metric-server 本身组件的监控状态并适时报警，这里的监控就可以通过 kube-state-metrics 来实现，如 metric-server pod 的运行状态。

安装#

kube-state-metrics 已经给出了在 Kubernetes 部署的 manifest 定义文件，我们直接将代码 Clone 到集群中(能用 kubectl 工具操作就行)，不过需要注意兼容的版本：

Terminal window

1
git clone https://github.com/kubernetes/kube-state-metrics.git
2
cd kube-state-metrics/examples/standard

默认的镜像为gcr 的，这里可以将 deployment.yaml 下面的镜像替换成 cnych/kube-state-metrics:v2.0.0-rc.0，此外上面为 Prometheus 配置了 Endpoints 的自动发现，所以可以给 kube-state-metrics 的 Service 配置上对应的 annotations 来自动被发现，然后直接创建即可：

Terminal window展开收起

1
cat service.yaml
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  labels:
6
    app.kubernetes.io/name: kube-state-metrics
7
    app.kubernetes.io/version: 2.0.0-rc.0
8
  annotations:
9
    prometheus.io/scrape: "true"
10
    prometheus.io/port: "8080"  # 8081是kube-state-metrics应用本身指标的端口
11
  name: kube-state-metrics
12
  namespace: kube-system
13
......
14
kubectl apply -f .
15
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created
16
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
17
deployment.apps/kube-state-metrics created
18
serviceaccount/kube-state-metrics created
19
service/kube-state-metrics created

展开收起

部署完成后正常就可以被 Prometheus 采集到指标了：

img

水平缩放(分片)#

kube-state-metrics 已经内置实现了一些自动分片功能，可以通过 --shard 和 --total-shards 参数进行配置。现在还有一个实验性功能，如果将 kube-state-metrics 部署在 StatefulSet 中，它可以自动发现其命名位置，以便自动配置分片，这是一项实验性功能，可能以后会被移除。

要启用自动分片，必须运行一个 kube-state-metrics 的 StatefulSet，并且必须通过 --pod 和 --pod-namespace 标志将 pod 名称和名称空间传递给 kube-state-metrics 进程。可以参考 /examples/autosharding 目录下面的示例清单文件进行说明。

使用#

使用 kube-state-metrics 的一些典型场景：

存在执行失败的 Job: kube_job_status_failed
集群节点状态错误: kube_node_status_condition{condition="Ready", status!="true"}==1
集群中存在启动失败的 Pod：kube_pod_status_phase{phase=~"Failed|Unknown"}==1
最近 30 分钟内有 Pod 容器重启: changes(kube_pod_container_status_restarts_total[30m])>0

现在有一个问题是前面做 endpoints 类型的服务发现的时候做了一次 labelmap，将 namespace 和 pod 标签映射到了指标中，但是由于 kube-state-metrics 暴露的指标中本身就包含 namespace 和 pod 标签，这就会产生冲突，这种情况会将映射的标签变成 exported_namespace 和 exported_pod，这变会对指标的查询产生影响，如下所示：

kube_pod_info

这个情况下可以使用 metric_relabel_configs 这 Prometheus 保存数据前的最后一步重新编辑标签，metric_relabel_configs 模块和 relabel_configs 模块很相似，metric_relabel_configs 一个很常用的用途就是可以将监控不需要的数据，直接丢掉，不在 Prometheus 中保存。比如这里可以重新配置 endpoints 类型的指标发现配置：

1
- job_name: "endpoints"
2
  kubernetes_sd_configs:
3
    - role: endpoints
4
  metric_relabel_configs:
5
    - source_labels: [__name__, exported_pod]
6
      regex: kube_pod_info;(.+)
7
      target_label: pod
8
    - source_labels: [__name__, exported_namespace]
9
      regex: kube_pod_info;(.+)
10
      target_label: namespace
11
    - source_labels: [__name__, exported_node]
12
      regex: kube_pod_info;(.+)
13
      target_label: node
14
    - source_labels: [__name__, exported_service]
15
      regex: kube_pod_info;(.+)
16
      target_label: service
17
  relabel_configs:
18
  # ......

展开收起

metric_relabel_configs 与 relabel_configs 虽然非常类似，但是还是有很大不同的，relabel_configs 是针对 target 指标采集前和采集中的筛选，而 metric_relabel_configs 是针对指标采集后的筛选，如果一个不起作用，那么可以随时尝试使用另一个！

Prometheus 需要知道要抓取什么，这就是服务发现和 relabel_configs 配置的地方，relabel_configs 允许你选择要抓取的目标以及目标标签是什么，所以如果想抓取这种类型的机器而不是那种类型的机器，请使用relabel_configs。

metric_relabel_configs 相比之下，在抓取发生之后，但在数据被存储系统摄取之前应用，因此，如果你想要删除一些昂贵的指标，或者你想要操作来自抓取目标本身的标签（例如来自 /metrics 页面），那就用 metric_relabel_configs。

譬如下面的 relabel_configs drop 动作：

1
relabel_configs:
2
  - source_labels: [__meta_xxx_label_xxx]
3
    regex: Example.*
4
    action: drop

那么将不会收集这个指标，而 metric_relabel_configs 使用的时候指标已经采集过了：

1
metric_relabel_configs:
2
  - source_labels: [__name__]
3
    regex: "(container_tasks_state|container_memory_failures_total)"
4
    action: drop

所以 metric_relabel_configs 相对来说，更加昂贵，因为指标已经采集了。

关于 kube-state-metrics 的更多用法可以查看官方 GitHub 仓库：https://github.com/kubernetes/kube-state-metrics

Kubernetes-Local Storage

Tue, 12 Dec 2023 00:00:00 GMT

前面通过 hostPath 或者 emptyDir 的方式来持久化数据，但是显然还需要更加可靠的存储来保存应用的持久化数据，这样容器在重建后，依然可以使用之前的数据。但是存储资源和 CPU 资源以及内存资源有很大不同，为了屏蔽底层的技术实现细节，让用户更加方便的使用，Kubernetes 便引入了 PV 和 PVC 两个重要的资源对象来实现对存储的管理。

概念#

PV 的全称是：PersistentVolume（持久化卷），是对底层共享存储的一种抽象，PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS、hostPath 等，都是通过插件机制完成与共享存储的对接。

PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。

但是通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求，而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了，此外 StorageClass 还可以自动生成 PV，免去了每次手动创建的麻烦。

hostPath#

上面提到了 PV 是对底层存储技术的一种抽象，PV 一般都是由管理员来创建和配置的，首先来创建一个 hostPath 类型的 PersistentVolume。Kubernetes 支持 hostPath 类型的 PersistentVolume 使用节点上的文件或目录来模拟附带网络的存储，但是需要注意的是在生产集群中，不会使用 hostPath，集群管理员会提供网络存储资源，比如 NFS 共享卷或 Ceph 存储卷，集群管理员还可以使用 StorageClasses 来设置动态提供存储。因为 Pod 并不是始终固定在某个节点上面的，所以要使用 hostPath 的话就需要将 Pod 固定在某个节点上，这样显然就大大降低了应用的容错性。

比如这里将测试的应用固定在节点 node1 上面，首先在该节点上面创建一个 /data/k8s/test/hostpath 的目录，然后在该目录中创建一个 index.html 的文件：

Terminal window

1
mkdir -p /data/k8s/test/hostpath
2
echo 'Hello from Kubernetes hostpath storage' > /data/k8s/test/hostpath/index.html

然后接下来创建一个 hostPath 类型的 PV 资源对象：（pv-hostpath.yaml）

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: pv-hostpath
5
  labels:
6
    type: local
7
spec:
8
  storageClassName: manual
9
  capacity:
10
    storage: 10Gi
11
  accessModes:
12
    - ReadWriteOnce
13
  hostPath:
14
    path: "/data/k8s/test/hostpath"

配置文件中指定了该卷位于集群节点上的 /data/k8s/test/hostpath 目录，还指定了 10G 大小的空间和 ReadWriteOnce 的访问模式，这意味着该卷可以在单个节点上以读写方式挂载，另外还定义了名称为 manual 的 StorageClass，该名称用来将 PersistentVolumeClaim 请求绑定到该 PersistentVolum。下面是关于 PV 的这些配置属性的一些说明：

Capacity（存储能力）：一般来说，一个 PV 对象都要指定一个存储能力，通过 PV 的 capacity 属性来设置的，目前只支持存储空间的设置，就是我们这里的 storage=10Gi，不过未来可能会加入 IOPS、吞吐量等指标的配置。
AccessModes（访问模式）：用来对 PV 进行访问模式的设置，用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
- ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
- ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
- ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
注意<一些> PV 可能支持多种访问模式，但是在挂载的时候只能使用一种访问模式，多种访问模式是不会生效的。

下图是一些常用的 Volume 插件支持的访问模式：

pv access modes

创建上面的资源对象：
```
1
kubectl apply -f pv-hostpath.yaml
```
Terminal window
```
1
kubectl get pv pv-hostpath
```
image-20231211192728076

其中有一项 RECLAIM POLICY 的配置，同样可以通过 PV 的 persistentVolumeReclaimPolicy（回收策略）属性来进行配置，目前 PV 支持的策略有三种：
- Retain（保留）：保留数据，需要管理员手工清理数据
- Recycle（回收）：清除 PV 中的数据，效果相当于执行 rm -rf /thevoluem/*
- Delete（删除）：与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务，比如 ASW EBS。
不过需要注意的是，目前只有 NFS 和 HostPath 两种类型支持回收策略，当然一般来说还是设置为 Retain 这种策略保险一点。

注意:Recycle 策略会通过运行一个 busybox 容器来执行数据删除命令，默认定义的 busybox 镜像是：gcr.io/google_containers/busybox:latest，并且 imagePullPolicy: Always，如果需要调整配置，需要增加kube-controller-manager 启动参数：--pv-recycler-pod-template-filepath-hostpath 来进行配置。

关于 PV 的状态，实际上描述的是 PV 的生命周期的某个阶段，一个 PV 的生命周期中，可能会处于 4 种不同的阶段：
- Available（可用）：表示可用状态，还未被任何 PVC 绑定
- Bound（已绑定）：表示 PV 已经被 PVC 绑定
- Released（已释放）：PVC 被删除，但是资源还未被集群重新声明
- Failed（失败）：表示该 PV 的自动回收失败
现在创建完成了 PV，如果需要使用这个 PV 的话，就需要创建一个对应的 PVC 来和他进行绑定了，就类似于服务是通过 Pod 来运行的，而不是 Node，只是 Pod 跑在 Node 上而已。

现在创建一个 PersistentVolumeClaim，Pod 使用 PVC 来请求物理存储，这里创建的 PVC 请求至少 3G 容量的卷，该卷至少可以为一个节点提供读写访问，下面是 PVC 的配置文件：pvc-hostpath.yaml
```
1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: pvc-hostpath
5
spec:
6
  storageClassName: manual
7
  accessModes:
8
    - ReadWriteOnce
9
  resources:
10
    requests:
11
      storage: 3Gi
```
直接创建这个 PVC 对象：
Terminal window
```
1
kubectl create -f pvc-hostpath.yaml
```
创建 PVC 之后，Kubernetes 就会去查找满足声明要求的 PV，比如 storageClassName、accessModes 以及容量这些是否满足要求，如果满足要求就会将 PV 和 PVC 绑定在一起。

**注意:**需要注意的是目前 PV 和 PVC 之间是一对一绑定的关系，也就是说一个 PV 只能被一个 PVC 绑定。

再次查看 PV 的信息：

Terminal window

1
kubectl get pv -l type=local

Terminal window

1
kubectl get pvc pvc-hostpath

image-20231211193748514

输出结果表明该 PVC 绑定了到了上面创建的 pv-hostpath 这个 PV 上面了，这里虽然声明的 3G 的容量，但是由于 PV 里面是 10G，所以显然也是满足要求的。

PVC 准备好过后，接下来就可以来创建 Pod 了，该 Pod 使用上面声明的 PVC 作为存储卷：pv-hostpath-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: pv-hostpath-pod
5
spec:
6
  volumes:
7
    - name: pv-hostpath
8
      persistentVolumeClaim:
9
        claimName: pvc-hostpath
10
  nodeSelector:
11
    kubernetes.io/hostname: node1
12
  containers:
13
    - name: task-pv-container
14
      image: nginx
15
      resources:
16
        limits:
17
          memory: "128Mi"
18
          cpu: "500m"
19
      ports:
20
        - containerPort: 80
21
      volumeMounts:
22
        - mountPath: "/usr/share/nginx/html"
23
          name: pv-hostpath

展开收起

这里需要注意的是，由于创建的 PV 真正的存储在节点 node1 上面，所以这里必须把 Pod 固定在这个节点下面，另外可以注意到 Pod 的配置文件指定了 PersistentVolumeClaim，但没有指定 PersistentVolume，对 Pod 而言，PVC 就是一个存储卷。直接创建这个 Pod 对象即可：

Terminal window

1
kubectl apply -f pv-hostpath-pod.yaml

Terminal window

1
kubectl get pod pv-hostpath-pod

运行成功后，打开一个 shell 访问 Pod 中的容器：

Terminal window

1
kubectl exec -it pv-hostpath-pod -- /bin/bash

在 shell 中，可以验证 nginx 的数据是否正在从 hostPath 卷提供 index.html 文件：

Terminal window

1
# 下面的命令是在pod的容器中执行的
2
apt-get update
3
apt-get install curl -y
4
curl localhost

image-20231212160418329

可以看到输出结果是前面写到 hostPath 卷种的 index.html 文件中的内容，同样可以把 Pod 删除，然后再次重建再测试一次，可以发现内容还是在 hostPath 中设置的内容。

在持久化容器数据的时候使用 PV/PVC 有什么好处呢？比如这里之前直接在 Pod 下面也可以使用 hostPath 来持久化数据，为什么还要费劲去创建 PV、PVC 对象来引用呢？PVC 和 PV 的设计，其实跟“面向对象”的思想完全一致，PVC 可以理解为持久化存储的“接口”，它提供了对某种持久化存储的描述，但不提供具体的实现；而这个持久化存储的实现部分则由 PV 负责完成。这样做的好处是，作为应用开发者，只需要跟 PVC 这个“接口”打交道，而不必关心具体的实现是 hostPath、NFS 还是 Ceph。毕竟这些存储相关的知识太专业了，应该交给专业的人去做，这样对于 Pod 来说就不用管具体的细节了，只需要给一个可用的 PVC 即可了，这样就完全屏蔽了细节和解耦了，所以更应该使用 PV、PVC 这种方式。

Local PV#

上面创建了后端是 hostPath 类型的 PV 资源对象，也提到了使用 hostPath 有一个局限性就是，Pod 不能随便漂移，需要固定到一个节点上，因为一旦漂移到其他节点上去了宿主机上面就没有对应的数据了，所以在使用 hostPath 的时候都会搭配 nodeSelector 来进行使用。但是使用 hostPath 明显也有一些好处的，因为 PV 直接使用的是本地磁盘，尤其是 SSD 盘，它的读写性能相比于大多数远程存储要好得多，所以对于一些对磁盘 IO 要求比较高的应用比如 etcd 就非常实用了。不过相比于正常的 PV 来说，使用了 hostPath 的这些节点一旦宕机数据就可能丢失，所以这就要求使用 hostPath 的应用必须具备数据备份和恢复的能力，允许把这些数据定时备份在其他位置。

所以在 hostPath 的基础上，Kubernetes 依靠 PV、PVC 实现了一个新的特性，这个特性的名字叫作：Local Persistent Volume，也就是我 Local PV。

其实 Local PV 实现的功能就非常类似于 hostPath 加上 nodeAffinity，比如，一个 Pod 可以声明使用类型为 Local 的 PV，而这个 PV 其实就是一个 hostPath 类型的 Volume。如果这个 hostPath 对应的目录，已经在节点 A 上被事先创建好了，那么，只需要再给这个 Pod 加上一个 nodeAffinity=nodeA，不就可以使用这个 Volume 了吗？理论上确实是可行的，但是事实上，绝不应该把一个宿主机上的目录当作 PV 来使用，因为本地目录的存储行为是完全不可控，它所在的磁盘随时都可能被应用写满，甚至造成整个宿主机宕机。所以，一般来说 Local PV 对应的存储介质是一块额外挂载在宿主机的磁盘或者块设备，可以认为就是“一个 PV 一块盘”。

另外一个 Local PV 和普通的 PV 有一个很大的不同在于 Local PV 可以保证 Pod 始终能够被正确地调度到它所请求的 Local PV 所在的节点上面，对于普通的 PV 来说，Kubernetes 都是先调度 Pod 到某个节点上，然后再持久化节点上的 Volume 目录，进而完成 Volume 目录与容器的绑定挂载，但是对于 Local PV 来说，节点上可供使用的磁盘必须是提前准备好的，因为它们在不同节点上的挂载情况可能完全不同，甚至有的节点可以没这种磁盘，所以，这时候，调度器就必须能够知道所有节点与 Local PV 对应的磁盘的关联关系，然后根据这个信息来调度 Pod，实际上就是在调度的时候考虑 Volume 的分布。

接下来测试下 Local PV 的使用，当然按照上面的分析我该给宿主机挂载并格式化一个可用的磁盘，我们这里就暂时将 node1 节点上的 /data/k8s/localpv 这个目录看成是挂载的一个独立的磁盘。现在来声明一个 Local PV 类型的 PV，如下所示：pv-local.yaml

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: pv-local
5
spec:
6
  capacity:
7
    storage: 5Gi
8
  volumeMode: Filesystem
9
  accessModes:
10
    - ReadWriteOnce
11
  persistentVolumeReclaimPolicy: Delete
12
  storageClassName: local
13
  local:
14
    path: /data/k8s/localpv # node1节点上的目录
15
  nodeAffinity:
16
    required:
17
      nodeSelectorTerms:
18
        - matchExpressions:
19
            - key: kubernetes.io/hostname
20
              operator: In
21
              values:
22
                - node1

展开收起

和前面定义的 PV 不同，这里定义了一个 local 字段，表明它是一个 Local PV，而 path 字段，指定的正是这个 PV 对应的本地磁盘的路径，即：/data/k8s/localpv，这也就意味着如果 Pod 要想使用这个 PV，那它就必须运行在 node1 节点上。所以，在这个 PV 的定义里，添加了一个节点亲和性 nodeAffinity 字段指定 node1 这个节点。这样，调度器在调度 Pod 的时候，就能够知道一个 PV 与节点的对应关系，从而做出正确的选择。

直接创建上面的资源对象：

Terminal window

1
kubectl apply -f pv-local.yaml

Terminal window

1
kubectl get pv

image-20231212164153534

可以看到这个 PV 创建后，进入了 Available（可用）状态。这个时候如果按照前面提到的，要使用这个 Local PV 的话就需要去创建一个 PVC 和他进行绑定：pvc-local.yaml

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

同样要注意声明的这些属性需要和上面的 PV 对应，直接创建这个资源对象：

Terminal window

1
kubectl apply -f pvc-local.yaml

Terminal window

1
kubectl get pvc

image-20231212165917447

可以看到现在 PVC 和 PV 已经处于 Bound 绑定状态了。但实际上这是不符合需求的，比如现在 Pod 声明使用这个 pvc-local，并且也明确规定这个 Pod 只能运行在 node2 这个节点上，如果按照上面这里的操作，这个 pvc-local 是不是就和这里的 pv-local 这个 Local PV 绑定在一起了，但是这个 PV 的存储卷又在 node1 这个节点上，显然就会出现冲突了，那么这个 Pod 的调度肯定就会失败了，所以在使用 Local PV 的时候，必须想办法延迟这个“绑定”操作。

要怎么来实现这个延迟绑定呢？可以通过创建 StorageClass 来指定这个动作，在 StorageClass 种有一个 volumeBindingMode=WaitForFirstConsumer 的属性，就是告诉 Kubernetes 在发现这个 StorageClass 关联的 PVC 与 PV 可以绑定在一起，但不要现在就立刻执行绑定操作（即：设置 PVC 的 VolumeName 字段），而是要等到第一个声明使用该 PVC 的 Pod 出现在调度器之后，调度器再综合考虑所有的调度规则，当然也包括每个 PV 所在的节点位置，来统一决定，这个 Pod 声明的 PVC，到底应该跟哪个 PV 进行绑定。通过这个延迟绑定机制，原本实时发生的 PVC 和 PV 的绑定过程，就被延迟到了 Pod 第一次调度的时候在调度器中进行，从而保证了这个绑定结果不会影响 Pod 的正常调度。

所以需要创建对应的 StorageClass 对象：local-storageclass.yaml

1
apiVersion: storage.k8s.io/v1
2
kind: StorageClass
3
metadata:
4
  name: local-storage
5
provisioner: kubernetes.io/no-provisioner
6
volumeBindingMode: WaitForFirstConsumer

这个 StorageClass 的名字，叫作 local-storage，也就是在 PV 中声明的，需要注意的是，在它的 provisioner 字段，指定的是 no-provisioner。这是因为这里是手动创建的 PV，所以不需要动态来生成 PV，另外这个 StorageClass 还定义了一个 volumeBindingMode=WaitForFirstConsumer 的属性，它是 Local PV 里一个非常重要的特性，即：延迟绑定。通过这个延迟绑定机制，原本实时发生的 PVC 和 PV 的绑定过程，就被延迟到了 Pod 第一次调度的时候在调度器中进行，从而保证了这个绑定结果不会影响 Pod 的正常调度。

创建这个 StorageClass 资源对象：

Terminal window

1
kubectl apply -f local-storageclass.yaml

删除上面声明的 PVC 对象，重新创建：

Terminal window

1
kubectl delete -f pvc-local.yaml

Terminal window

1
kubectl create -f pvc-local.yaml

image-20231212170626893

可以发现这个时候，集群中即使已经存在了一个可以与 PVC 匹配的 PV 了，但这个 PVC 依然处于 Pending 状态，也就是等待绑定的状态，这就是因为上面我们配置的是延迟绑定，需要在真正的 Pod 使用的时候才会来做绑定。

同样声明一个 Pod 来使用这里的 pvc-local 这个 PVC，资源对象如下所示：pv-local-pod.yaml

Terminal window展开收起

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: pv-local-pod
5
spec:
6
  volumes:
7
  - name: example-pv-local
8
    persistentVolumeClaim:
9
      claimName: pvc-local
10
  containers:
11
  - name: example-pv-local
12
    image: nginx
13
    resources:
14
      limits:
15
        memory: "128Mi"
16
        cpu: "500m"
17
    ports:
18
    - containerPort: 80
19
    volumeMounts:
20
    - mountPath: /usr/share/nginx/html
21
      name: example-pv-local

展开收起

直接创建这个 Pod：

Terminal window

1
kubectl apply -f pv-local-pod.yaml

创建完成后去查看前面声明的 PVC，会立刻变成 Bound 状态，与前面定义的 PV 绑定在了一起：

Terminal window

1
kubectl get pvc

这时候可以尝试在这个 Pod 的 Volume 目录里，创建一个测试文件，比如：

Terminal window

1
kubectl exec -it pv-local-pod /bin/sh
2
# cd /usr/share/nginx/html
3
# echo "Hello from Kubernetes local pv storage" > test.txt

然后，登录到 node1 这台机器上，查看一下它的 /data/k8s/localpv 目录下的内容，就可以看到刚刚创建的这个文件：

Terminal window

1
# 在node1节点上
2
ls /data/k8s/localpv
3
test.txt
4
cat /data/k8s/localpv/test.txt
5
Hello from Kubernetes local pv storage

image-20231212180334809

如果重新创建这个 Pod 的话，就会发现，之前创建的测试文件，依然被保存在这个持久化 Volume 当中：

Terminal window

1
kubectl delete -f pv-local-pod.yaml
2
kubectl apply -f pv-local-pod.yaml
3
kubectl exec -it pv-local-pod /bin/sh
4
# ls /usr/share/nginx/html
5
test.txt
6
# cat /usr/share/nginx/html/test.txt
7
Hello from Kubernetes local pv storage
8
#

到这里就说明基于本地存储的 Volume 是完全可以提供容器持久化存储功能的，对于 StatefulSet 这样的有状态的资源对象，也完全可以通过声明 Local 类型的 PV 和 PVC，来管理应用的存储状态。

需要注意的是，上面手动创建 PV 的方式，即静态的 PV 管理方式，在删除 PV 时需要按如下流程执行操作：

删除使用这个 PV 的 Pod
从宿主机移除本地磁盘
删除 PVC
删除 PV

如果不按照这个流程的话，这个 PV 的删除就会失败。

Kubernetes-NFS

Tue, 12 Dec 2023 00:00:00 GMT

安装#

安装nfs#

Terminal window

1
yum -y install nfs-utils rpcbind

配置共享目录#

Terminal window

1
mkdir -p /opt/nfs
2
chmod 755 /opt/nfs

配置nfs#

nfs 的默认配置文件在 /etc/exports 文件下，在该文件中添加下面的配置信息

Terminal window

1
vim /etc/exports
2
/opt/nfs  10.168.1.0/24(rw,sync,no_root_squash)

配置说明：

/opt/nfs：是共享的数据目录
*：表示任何人都有权限连接，当然也可以是一个网段，一个 IP，也可以是域名这里写10.168.1.0/24 我的内网网段
rw：读写的权限
sync：表示文件同时写入硬盘和内存
no_root_squash：当登录 NFS 主机使用共享目录的使用者是 root 时，其权限将被转换成为匿名使用者，通常它的 UID 与 GID，都会变成 nobody 身份

启动服务#

nfs 需要向 rpc 注册，rpc 一旦重启了，注册的文件都会丢失，向他注册的服务都需要重启注意启动顺序，先启动 rpcbind

启动rpcbind服务#

Terminal window

1
systemctl start rpcbind.service
2
systemctl enable rpcbind
3
systemctl status rpcbind

image-20231013164935829

看到上面的 active 证明启动成功了

启动nfs服务#

Terminal window

1
systemctl start nfs.service
2
systemctl enable nfs
3
systemctl status nfs

image-20231013165243369

看到上面的 active 证明启动成功了

还可以通过下面的命令确认下：

Terminal window

1
rpcinfo -p|grep nfs

image-20231212193352295

查看目录挂载权限#

Terminal window

1
cat /var/lib/nfs/etab

image-20231013165418547

安装nfs客户端#

到这里就把 nfs server 给安装成功了，然后就是前往节点安装 nfs 的客户端来验证，安装 nfs 当前也需要先关闭防火墙：

Terminal window

1
systemctl stop firewalld.service
2
systemctl disable firewalld.service

安装nfs#

Terminal window

1
yum -y install nfs-utils rpcbind

启动服务#

nfs 需要向 rpc 注册，rpc 一旦重启了，注册的文件都会丢失，向他注册的服务都需要重启注意启动顺序，先启动 rpcbind

启动rpcbind服务#

Terminal window

1
systemctl start rpcbind.service
2
systemctl enable rpcbind
3
systemctl status rpcbind

image-20231013164935829

看到上面的 active 证明启动成功了

启动nfs服务#

Terminal window

1
systemctl start nfs.service
2
systemctl enable nfs
3
systemctl status nfs

image-20231013165243369

看到上面的 active 证明启动成功了

挂载数据目录#

Terminal window

1
showmount -e 10.168.1.100

image-20231013165832419

测试挂载#

然后我们在客户端上新建目录：

Terminal window

1
mkdir -p /root/course/kubeadm/data

Terminal window

1
mount -t nfs 10.168.1.100:/opt/nfs /root/course/kubeadm/data

挂载成功后，在客户端上面的目录中新建一个文件，然后我们观察下 nfs 服务端的共享目录下面是否也会出现该文件：

Terminal window

1
touch /root/course/kubeadm/data/test.txt

然后在 nfs 服务端查看：

Terminal window

1
ll /var/lib/k8s/data/
2
-rw-r--r-- 1 nfsnobody nfsnobody    0 Dec 12 19:43 test.txt

如果上面出现了 test.txt 的文件，那么证明 nfs 挂载成功了。

使用#

创建一个如下所示 nfs 类型的 PV 资源对象：nfs-volume.yaml

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: nfs-pv
5
spec:
6
  storageClassName: manual
7
  capacity:
8
    storage: 1Gi
9
  accessModes:
10
    - ReadWriteOnce
11
  persistentVolumeReclaimPolicy: Retain
12
  nfs:
13
    path: /opt/nfs # 指定nfs的挂载点
14
    server: 10.168.1.100 # 指定nfs服务地址
15
---
16
apiVersion: v1
17
kind: PersistentVolumeClaim
18
metadata:
19
  name: nfs-pvc
20
spec:
21
  storageClassName: manual
22
  accessModes:
23
    - ReadWriteOnce
24
  resources:
25
    requests:
26
      storage: 1Gi

展开收起

用户真正使用的是 PVC，而要使用 PVC 的前提就是必须要先和某个符合条件的 PV 进行一一绑定，比如存储容器、访问模式，以及 PV 和 PVC 的 storageClassName 字段必须一样，这样才能够进行绑定，当 PVC 和 PV 绑定成功后就可以直接使用这个 PVC 对象了：nfs-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: test-volumes
5
spec:
6
  volumes:
7
    - name: nfs
8
      persistentVolumeClaim:
9
        claimName: nfs-pvc
10
  containers:
11
    - name: web
12
      image: nginx
13
      resources:
14
        limits:
15
          memory: "128Mi"
16
          cpu: "500m"
17
      ports:
18
        - name: web
19
          containerPort: 80
20
      volumeMounts:
21
        - name: nfs
22
          subPath: test-volumes
23
          mountPath: "/usr/share/nginx/html"

展开收起

直接创建上面的资源对象即可：

Terminal window

1
kubectl apply -f volume.yaml

Terminal window

1
kubectl apply -f pod.yaml

Terminal window

1
kubectl get pv nfs-pv

image-20231212195908587

由于 PV 中的数据为空，所以挂载后会将 nginx 容器中的 /usr/share/nginx/html 目录覆盖，那么访问应用的时候就没有内容了：

Terminal window

1
curl http://10.233.92.95

image-20231212200025141

在 PV 目录中添加一些内容：

Terminal window

1
#在nfs服务器上执行
2
echo "nfs pv content" > /opt/nfs/test-volumes/index.html

然后重新访问就有数据了，而且 Pod 应用挂掉或者被删掉重新启动后数据还是存在的，因为数据已经持久化了。

image-20231212200331680

上面的示例中需要手动去创建 PV 来和 PVC 进行绑定，有的场景下面需要自动创建 PV，这个时候就需要使用到 StorageClass 了，并且需要一个对应的 provisioner 来自动创建 PV，比如这里使用的 NFS 存储，则可以使用 nfs-subdir-external-provisioner 这个 Provisioner，它使用现有的和已配置的 NFS 服务器来支持通过 PVC 动态配置 PV，持久卷配置为 ${namespace}-${pvcName}-${pvName}，首先使用 Helm Chart 来安装：

Terminal window

1
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
2
helm upgrade --install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=10.168.1.100 --set nfs.path=/opt/nfs -n kube-system

上面的命令会在 kube-system 命名空间下安装 nfs-subdir-external-provisioner，并且会创建一个名为 nfs-client 默认的 StorageClass：

image-20231212200648291

Terminal window

1
kubectl get sc nfs-client -o yaml

image-20231212200718716

如果把nfs-client设置成默认的存储类之后,创建 PVC 时如果没有指定具体的 StorageClass 的时候，则会使用上面的 SC(nfs-client) 自动创建一个 PV。这里没有把nfs设置成默认的SC,所以要使用nfs-client的SC就需要指定storageClassName,比如创建一个如下所示的 PVC：nfs-sc-pvc.yaml

1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: nfs-sc-pvc
5
spec:
6
  storageClassName: nfs-client # 不指定则使用默认的 SC
7
  accessModes:
8
    - ReadWriteOnce
9
  resources:
10
    requests:
11
      storage: 1Gi

直接创建上面的 PVC 资源对象后就会自动创建一个 PV 与其进行绑定：

Terminal window

1
kubectl apply -f nfs-sc-pvc.yaml

image-20231212201424344

对应自动创建的 PV 如下所示：

Terminal window

1
kubectl get pv pvc-e662895d-e1e6-4e11-afe1-33f80fee7c6a -o yaml

image-20231212201542622

挂载的 nfs 目录为 /opt/nfs/default-nfs-sc-pvc-pvc-e662895d-e1e6-4e11-afe1-33f80fee7c6a，和上面的 ${namespace}-${pvcName}-${pvName} 规范一致的。

原理#

只是在 volumes 中指定了上面创建的 PVC 对象，当这个 Pod 被创建之后， kubelet 就会把这个 PVC 对应的这个 NFS 类型的 Volume（PV）挂载到这个 Pod 容器中的目录中去。前面也提到了这样的话对于普通用户来说完全就不用关心后面的具体存储在 NFS 还是 Ceph 或者其他了，只需要直接使用 PVC 就可以了，因为真正的存储是需要很多相关的专业知识的，这样就完全职责分离解耦了。

普通用户直接使用 PVC 没有问题，但是也会出现一个问题，那就是当普通用户创建一个 PVC 对象的时候，这个时候系统里面并没有合适的 PV 来和它进行绑定，因为 PV 大多数情况下是管理员创建的，这个时候启动 Pod 肯定就会失败了，如果现在管理员如果去创建一个对应的 PV 的话，PVC 和 PV 当然就可以绑定了，然后 Pod 也会自动的启动成功，这是因为在 Kubernetes 中有一个专门处理持久化存储的控制器 Volume Controller，这个控制器下面有很多个控制循环，其中一个就是用于 PV 和 PVC 绑定的 PersistentVolumeController。

PersistentVolumeController 会不断地循环去查看每一个 PVC，是不是已经处于 Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与未绑定的 PVC 进行绑定，这样，Kubernetes 就可以保证用户提交的每一个 PVC，只要有合适的 PV 出现，它就能够很快进入绑定状态。而所谓将一个 PV 与 PVC 进行绑定，其实就是将这个 PV 对象的名字，填在了 PVC 对象的 spec.volumeName 字段上。

PV 和 PVC 绑定上了，那么又是如何将容器里面的数据进行持久化的呢，Docker 的 Volume 挂载其实就是将一个宿主机上的目录和一个容器里的目录绑定挂载在了一起，具有持久化功能当然就是指的宿主机上面的这个目录了，当容器被删除或者在其他节点上重建出来以后，这个目录里面的内容依然存在，所以一般情况下实现持久化是需要一个远程存储的，比如 NFS、Ceph 或者云厂商提供的磁盘等等。所以接下来需要做的就是持久化宿主机目录这个过程。

当 Pod 被调度到一个节点上后，节点上的 kubelet 组件就会为这个 Pod 创建它的 Volume 目录，默认情况下 kubelet 为 Volume 创建的目录在 kubelet 工作目录下面：

Terminal window

1
/var/lib/kubelet/pods/<Pod的ID>/volumes/kubernetes.io~<Volume类型>/<Volume名字>

比如上面创建的 Pod 对应的 Volume 目录完整路径为：

Terminal window

1
/opt/nfs/default-nfs-sc-pvc-pvc-e662895d-e1e6-4e11-afe1-33f80fee7c6a/volumes/kubernetes.io~nfs/nfs-pv

!!! info “提示” 要获取 Pod 的唯一标识 uid，可通过命令 kubectl get pod pod名 -o jsonpath={.metadata.uid} 获取。

然后就需要根据 Volume 类型来决定需要做什么操作了，假如后端存储使用的 Ceph RBD，那么 kubelet 就需要先将 Ceph 提供的 RBD 挂载到 Pod 所在的宿主机上面，这个阶段在 Kubernetes 中被称为 Attach 阶段。Attach 阶段完成后，为了能够使用这个块设备，kubelet 还要进行第二个操作，即：格式化这个块设备，然后将它挂载到宿主机指定的挂载点上。这个挂载点，也就是上面提到的 Volume 的宿主机的目录。将块设备格式化并挂载到 Volume 宿主机目录的操作，在 Kubernetes 中被称为 Mount 阶段。但是对于这里使用的 NFS 就更加简单了，因为 NFS 存储并没有一个设备需要挂载到宿主机上面，所以这个时候 kubelet 就会直接进入第二个 Mount 阶段，相当于直接在宿主机上面执行如下的命令：

Terminal window

1
mount -t nfs 10.168.1.100:/opt/nfs /var/lib/kubelet/pods/d4fcdb11-baf7-43d9-8d7d-3ede24118e08/volumes/kubernetes.io~nfs/nfs-pv

同样可以在测试的 Pod 所在节点查看 Volume 的挂载信息：

Terminal window

1
findmnt /var/lib/kubelet/pods/d4fcdb11-baf7-43d9-8d7d-3ede24118e08/volumes/kubernetes.io~nfs/nfs-pv
2
TARGET                                                                               SOURCE                 FSTYPE OPTIONS
3
/var/lib/kubelet/pods/d4fcdb11-baf7-43d9-8d7d-3ede24118e08/volumes/kubernetes.io~nfs/nfs-pv
4
                                                                                     192.168.31.31:/var/lib/k8s/data/ nfs4   rw,relatime,

可以看到这个 Volume 被挂载到了 NFS（10.168.1.100:/opt/nfs/）下面，以后在这个目录里写入的所有文件，都会被保存在远程 NFS 服务器上。

这样在经过了上面的阶段过后，就得到了一个持久化的宿主机上面的 Volume 目录了，接下来 kubelet 只需要把这个 Volume 目录挂载到容器中对应的目录即可，这样就可以为 Pod 里的容器挂载这个持久化的 Volume 了，这一步其实也就相当于执行了如下所示的命令：

Terminal window

1
# docker 或者 nerdctl
2
docker run -v /var/lib/kubelet/pods/<Pod的ID>/volumes/kubernetes.io~<Volume类型>/<Volume名字>:/<容器内的目标目录> 镜像 ...

整个存储的架构可以用下图来说明：

存储架构

PV Controller：负责 PV/PVC 的绑定，并根据需求进行数据卷的 Provision/Delete 操作
AD Controller：负责存储设备的 Attach/Detach 操作，将设备挂载到目标节点
Volume Manager：管理卷的 Mount/Unmount 操作、卷设备的格式化等操作
Volume Plugin：扩展各种存储类型的卷管理能力，实现第三方存储的各种操作能力和 Kubernetes 存储系统结合

上面使用的 NFS 就属于 In-Tree 这种方式，In-Tree 就是在 Kubernetes 源码内部实现的，和 Kubernetes 一起发布、管理的，但是更新迭代慢、灵活性比较差，另外一种方式 Out-Of-Tree 是独立于 Kubernetes 的，目前主要有 CSI 和 FlexVolume 两种机制，开发者可以根据自己的存储类型实现不同的存储插件接入到 Kubernetes 中去，其中 CSI 是现在也是以后主流的方式。

Kubernetes-Ingress Nginx

Wed, 29 Nov 2023 00:00:00 GMT

运行原理#

ingress-nginx 控制器主要是用来组装一个 nginx.conf 的配置文件，当配置文件发生任何变动的时候就需要重新加载 Nginx 来生效，但是并不会只在影响 upstream 配置的变更后就重新加载 Nginx，控制器内部会使用一个 lua-nginx-module 来实现该功能。

Kubernetes 控制器使用控制循环模式来检查控制器中所需的状态是否已更新或是否需要变更，所以 ingress-nginx 需要使用集群中的不同对象来构建模型，比如 Ingress、Service、Endpoints、Secret、ConfigMap 等可以生成反映集群状态的配置文件的对象，控制器需要一直 Watch 这些资源对象的变化，但是并没有办法知道特定的更改是否会影响到最终生成的 nginx.conf 配置文件，所以一旦 Watch 到了任何变化控制器都必须根据集群的状态重建一个新的模型，并将其与当前的模型进行比较，如果模型相同则就可以避免生成新的 Nginx 配置并触发重新加载，否则还需要检查模型的差异是否只和端点有关，如果是这样，则需要使用 HTTP POST 请求将新的端点列表发送到在 Nginx 内运行的 Lua 处理程序，并再次避免生成新的 Nginx 配置并触发重新加载，如果运行和新模型之间的差异不仅仅是端点，那么就会基于新模型创建一个新的 Nginx 配置了，这样构建模型最大的一个好处就是在状态没有变化时避免不必要的重新加载，可以节省大量 Nginx 重新加载。

下面简单描述了需要重新加载的一些场景：

创建了新的 Ingress 资源
TLS 添加到现有 Ingress
从 Ingress 中添加或删除 path 路径
Ingress、Service、Secret 被删除了
Ingress 的一些缺失引用对象变可用了，例如 Service 或 Secret
更新了一个 Secret

对于集群规模较大的场景下频繁的对 Nginx 进行重新加载显然会造成大量的性能消耗，所以要尽可能减少出现重新加载的场景。

安装#

由于 ingress-nginx 所在的节点需要能够访问外网，这样域名可以解析到这些节点上直接使用，所以需要让 ingress-nginx 绑定节点的 80 和 443 端口，所以可以使用 hostPort 来进行访问，当然对于线上环境来说为了保证高可用，一般是需要运行多个 ingress-nginx 实例的，然后可以用一个 nginx/haproxy 作为入口，通过 keepalived 来访问边缘节点的 vip 地址。

**边缘节点:**即集群内部用来向集群外暴露服务能力的节点，集群外部的服务通过该节点来调用集群内部的服务，边缘节点是集群内外交流的一个 Endpoint。

这里使用 Helm Chart 的方式来进行安装：

支持的版本列表,根据k8s的版本下载支持的ingress-nginx:

image-20231115111025262

Terminal window

1
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
2
helm repo update
3
helm fetch ingress-nginx/ingress-nginx --version 4.5.2
4
# 解压下载的版本
5
tar -xvf ingress-nginx-x.x.x.tgz
6
cd ingress-nginx

Terminal window展开收起

1
├── changelog
2
│   └── Changelog-4.5.2.md
3
├── CHANGELOG.md
4
├── changelog.md.gotmpl
5
├── Chart.yaml
6
├── ci
7
│   ├── controller-admission-tls-cert-manager-values.yaml
8
│   ├── controller-custom-ingressclass-flags.yaml
9
│   ├── daemonset-customconfig-values.yaml
10
│   ├── daemonset-customnodeport-values.yaml
11
│   ├── daemonset-extra-modules.yaml
12
│   ├── daemonset-headers-values.yaml
13
│   ├── daemonset-internal-lb-values.yaml
14
│   ├── daemonset-nodeport-values.yaml
15
│   ├── daemonset-podannotations-values.yaml
16
│   ├── daemonset-tcp-udp-configMapNamespace-values.yaml
17
│   ├── daemonset-tcp-udp-portNamePrefix-values.yaml
18
│   ├── daemonset-tcp-udp-values.yaml
19
│   ├── daemonset-tcp-values.yaml
20
│   ├── deamonset-default-values.yaml
21
│   ├── deamonset-metrics-values.yaml
22
│   ├── deamonset-psp-values.yaml
23
│   ├── deamonset-webhook-and-psp-values.yaml
24
│   ├── deamonset-webhook-values.yaml
25
│   ├── deployment-autoscaling-behavior-values.yaml
26
│   ├── deployment-autoscaling-values.yaml
27
│   ├── deployment-customconfig-values.yaml
28
│   ├── deployment-customnodeport-values.yaml
29
│   ├── deployment-default-values.yaml
30
│   ├── deployment-extra-modules-default-container-sec-context.yaml
31
│   ├── deployment-extra-modules-specific-container-sec-context.yaml
32
│   ├── deployment-extra-modules.yaml
33
│   ├── deployment-headers-values.yaml
34
│   ├── deployment-internal-lb-values.yaml
35
│   ├── deployment-metrics-values.yaml
36
│   ├── deployment-nodeport-values.yaml
37
│   ├── deployment-podannotations-values.yaml
38
│   ├── deployment-psp-values.yaml
39
│   ├── deployment-tcp-udp-configMapNamespace-values.yaml
40
│   ├── deployment-tcp-udp-portNamePrefix-values.yaml
41
│   ├── deployment-tcp-udp-values.yaml
42
│   ├── deployment-tcp-values.yaml
43
│   ├── deployment-webhook-and-psp-values.yaml
44
│   ├── deployment-webhook-extraEnvs-values.yaml
45
│   ├── deployment-webhook-resources-values.yaml
46
│   └── deployment-webhook-values.yaml
47
├── OWNERS
48
├── README.md
49
├── README.md.gotmpl
50
├── templates
51
│   ├── admission-webhooks
52
│   │   ├── cert-manager.yaml
53
│   │   ├── job-patch
54
│   │   │   ├── clusterrolebinding.yaml
55
│   │   │   ├── clusterrole.yaml
56
│   │   │   ├── job-createSecret.yaml
57
│   │   │   ├── job-patchWebhook.yaml
58
│   │   │   ├── networkpolicy.yaml
59
│   │   │   ├── psp.yaml
60
│   │   │   ├── rolebinding.yaml
61
│   │   │   ├── role.yaml
62
│   │   │   └── serviceaccount.yaml
63
│   │   └── validating-webhook.yaml
64
│   ├── clusterrolebinding.yaml
65
│   ├── clusterrole.yaml
66
│   ├── controller-configmap-addheaders.yaml
67
│   ├── controller-configmap-proxyheaders.yaml
68
│   ├── controller-configmap-tcp.yaml
69
│   ├── controller-configmap-udp.yaml
70
│   ├── controller-configmap.yaml
71
│   ├── controller-daemonset.yaml
72
│   ├── controller-deployment.yaml
73
│   ├── controller-hpa.yaml
74
│   ├── controller-ingressclass.yaml
75
│   ├── controller-keda.yaml
76
│   ├── controller-poddisruptionbudget.yaml
77
│   ├── controller-prometheusrules.yaml
78
│   ├── controller-psp.yaml
79
│   ├── controller-rolebinding.yaml
80
│   ├── controller-role.yaml
81
│   ├── controller-serviceaccount.yaml
82
│   ├── controller-service-internal.yaml
83
│   ├── controller-service-metrics.yaml
84
│   ├── controller-servicemonitor.yaml
85
│   ├── controller-service-webhook.yaml
86
│   ├── controller-service.yaml
87
│   ├── controller-webhooks-networkpolicy.yaml
88
│   ├── default-backend-deployment.yaml
89
│   ├── default-backend-hpa.yaml
90
│   ├── default-backend-poddisruptionbudget.yaml
91
│   ├── default-backend-psp.yaml
92
│   ├── default-backend-rolebinding.yaml
93
│   ├── default-backend-role.yaml
94
│   ├── default-backend-serviceaccount.yaml
95
│   ├── default-backend-service.yaml
96
│   ├── dh-param-secret.yaml
97
│   ├── _helpers.tpl
98
│   ├── NOTES.txt
99
│   └── _params.tpl
100
└── values.yaml
101

102
5 directories, 95 files

展开收起

Helm Chart 包下载下来后解压可以看到里面包含的模板文件，其中的 ci 目录中就包含了各种场景下面安装的 Values 配置文件，values.yaml 文件中包含的是所有可配置的默认值，可以对这些默认值进行覆盖，这里测试环境就将 master 节点看成边缘节点，所以直接将 ingress-nginx 固定到 master 节点上，采用 hostNetwork 模式(生产环境可以使用 LB + DaemonSet hostNetwork 模式)，为了避免创建的错误 Ingress 等资源对象影响控制器重新加载，所以强烈建议大家开启准入控制器，ingess-nginx 中会提供一个用于校验资源对象的 Admission Webhook，可以通过 Values 文件进行开启。然后新建一个名为 ci/daemonset-prod.yaml 的 Values 文件，用来覆盖 ingress-nginx 默认的 Values 值。

主机网络模式

Terminal window

1
kubectl create ns ingress-nginx
2
helm upgrade --install ingress-nginx . -f values.yaml --namespace ingress-nginx

1
Release "ingress-nginx" does not exist. Installing it now.
2
NAME: ingress-nginx
3
LAST DEPLOYED: Wed Nov 15 11:26:50 2023
4
NAMESPACE: ingress-nginx
5
STATUS: deployed
6
REVISION: 1
7
TEST SUITE: None
8
NOTES:
9
The ingress-nginx controller has been installed.
10
It may take a few minutes for the LoadBalancer IP to be available.
11
You can watch the status by running 'kubectl --namespace ingress-nginx get services -o wide -w ingress-nginx-controller'
12

13
An example Ingress that makes use of the controller:
14
  apiVersion: networking.k8s.io/v1
15
  kind: Ingress
16
  metadata:
17
    name: example
18
    namespace: foo
19
  spec:
20
    ingressClassName: nginx
21
    rules:
22
      - host: www.example.com
23
        http:
24
          paths:
25
            - pathType: Prefix
26
              backend:
27
                service:
28
                  name: exampleService
29
                  port:
30
                    number: 80
31
              path: /
32
    # This section is only required if TLS is to be enabled for the Ingress
33
    tls:
34
      - hosts:
35
        - www.example.com
36
        secretName: example-tls
37

38
If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
39

40
  apiVersion: v1
41
  kind: Secret
42
  metadata:
43
    name: example-tls
44
    namespace: foo
45
  data:
46
    tls.crt: <base64 encoded cert>
47
    tls.key: <base64 encoded key>
48
  type: kubernetes.io/tls

展开收起

image-20231115134848460

安装完成后会自动创建一个名为 nginx 的 IngressClass 对象：

Terminal window

1
kubectl get ingressclass
2
kubectl get ingressclass nginx -o yaml

1
apiVersion: networking.k8s.io/v1
2
kind: IngressClass
3
metadata:
4
  annotations:
5
    meta.helm.sh/release-name: ingress-nginx
6
    meta.helm.sh/release-namespace: ingress-nginx
7
  creationTimestamp: "2023-11-15T03:27:16Z"
8
  generation: 1
9
  labels:
10
    app.kubernetes.io/component: controller
11
    app.kubernetes.io/instance: ingress-nginx
12
    app.kubernetes.io/managed-by: Helm
13
    app.kubernetes.io/name: ingress-nginx
14
    app.kubernetes.io/part-of: ingress-nginx
15
    app.kubernetes.io/version: 1.6.4
16
    helm.sh/chart: ingress-nginx-4.5.2
17
  name: nginx
18
  resourceVersion: "59635"
19
  uid: 620adf44-e02f-4837-9bcd-3983050297e8
20
spec:
21
  controller: k8s.io/ingress-nginx

展开收起

不过这里只提供了一个 controller 属性，如果还需要配置一些额外的参数，则可以在安装的 values 文件中进行配置。

第一个示例#

安装成功后，为一个 nginx 应用创建一个 Ingress 资源，如下所示：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: my-nginx
5
spec:
6
  selector:
7
    matchLabels:
8
      app: my-nginx
9
  template:
10
    metadata:
11
      labels:
12
        app: my-nginx
13
    spec:
14
      containers:
15
        - name: my-nginx
16
          image: nginx
17
          ports:
18
            - containerPort: 80
19
          resources:
20
            limits:
21
              cpu: 100m
22
              memory: 128Mi
23
---
24
apiVersion: v1
25
kind: Service
26
metadata:
27
  name: my-nginx
28
  labels:
29
    app: my-nginx
30
spec:
31
  ports:
32
    - port: 80
33
      protocol: TCP
34
      name: http
35
  selector:
36
    app: my-nginx
37
---
38
apiVersion: networking.k8s.io/v1
39
kind: Ingress
40
metadata:
41
  name: my-nginx
42
  namespace: default
43
spec:
44
  ingressClassName: nginx # 使用 nginx 的 IngressClass（关联的 ingress-nginx 控制器）
45
  rules:
46
    - host: ngdemo.tianch.com.cn # 将域名映射到 my-nginx 服务
47
      http:
48
        paths:
49
          - path: /
50
            pathType: Prefix
51
            backend:
52
              service: # 将所有请求发送到 my-nginx 服务的 80 端口
53
                name: my-nginx
54
                port:
55
                  number: 80
56
# 不过需要注意大部分Ingress控制器都不是直接转发到Service
57
# 而是只是通过Service来获取后端的Endpoints列表，直接转发到Pod，这样可以减少网络跳转，提高性能

展开收起

Terminal window

1
kubectl apply -f my-nginx.yaml

image-20231115140324520

在上面的 Ingress 资源对象中使用配置 ingressClassName: nginx 指定让安装的 ingress-nginx 这个控制器来处理 Ingress 资源，配置的匹配路径类型为前缀的方式去匹配 /，将来自域名 ngdemo.tianch.com.cn 的所有请求转发到 my-nginx 服务的后端 Endpoints 中去。

上面资源创建成功后，将域名 ngdemo.tianch.com.cn 解析到 ingress-nginx 所在的边缘节点中的任意一个，当然也可以在本地 /etc/hosts 中添加对应的映射也可以，然后就可以通过域名进行访问了。

image-20231115140606238

客户端是如何通过 Ingress 控制器连接到其中一个 Pod 的流程: 客户端首先对 ngdemo.tianch.com.cn 执行 DNS 解析，得到 Ingress 控制器所在节点的 IP，然后客户端向 Ingress 控制器发送 HTTP 请求，然后根据 Ingress 对象里面的描述匹配域名，找到对应的 Service 对象，并获取关联的 Endpoints 列表，将客户端的请求转发给其中一个 Pod。

前面也提到了 ingress-nginx 控制器的核心原理就是将 Ingress 这些资源对象映射翻译成 Nginx 配置文件 nginx.conf，通过查看控制器中的配置文件来验证这点：

1
## start server ngdemo.tianch.com.cn
2
  server {
3
    server_name ngdemo.tianch.com.cn ;
4

5
    listen 80  ;
6
    listen [::]:80  ;
7
    listen 443  ssl http2 ;
8
    listen [::]:443  ssl http2 ;
9

10
    set $proxy_upstream_name "-";
11

12
    ssl_certificate_by_lua_block {
13
      certificate.call()
14
    }
15

16
    location / {
17

18
      set $namespace      "default";
19
      set $ingress_name   "my-nginx";
20
      set $service_name   "my-nginx";
21
      set $service_port   "80";
22
      set $location_path  "/";
23
      set $global_rate_limit_exceeding n;
24

25
      rewrite_by_lua_block {
26
        lua_ingress.rewrite({
27
          force_ssl_redirect = false,
28
          ssl_redirect = true,
29
          force_no_ssl_redirect = false,
30
          preserve_trailing_slash = false,
31
          use_port_in_redirects = false,
32
          global_throttle = { namespace = "", limit = 0, window_size = 0, key = { }, ignored_cidrs = { } },
33
        })
34
        balancer.rewrite()
35
        plugins.run()
36
      }
37

38
      # be careful with `access_by_lua_block` and `satisfy any` directives as satisfy any
39
      # will always succeed when there's `access_by_lua_block` that does not have any lua code doing `ngx.exit(ngx.DECLINED)`
40
      # other authentication method such as basic auth or external auth useless - all requests will be allowed.
41
      #access_by_lua_block {
42
      #}
43

44
      header_filter_by_lua_block {
45
        lua_ingress.header()
46
        plugins.run()
47
      }
48

49
      body_filter_by_lua_block {
50
        plugins.run()
51
      }
52

53
      log_by_lua_block {
54
        balancer.log()
55

56
        monitor.call()
57

58
        plugins.run()
59
      }
60

61
      port_in_redirect off;
62

63
      set $balancer_ewma_score -1;
64
      set $proxy_upstream_name "default-my-nginx-80";
65
      set $proxy_host          $proxy_upstream_name;
66
      set $pass_access_scheme  $scheme;
67

68
      set $pass_server_port    $server_port;
69

70
      set $best_http_host      $http_host;
71
      set $pass_port           $pass_server_port;
72

73
      set $proxy_alternative_upstream_name "";
74

75
      client_max_body_size                    1m;
76

77
      proxy_set_header Host                   $best_http_host;
78

79
      # Pass the extracted client certificate to the backend
80

81
      # Allow websocket connections
82
      proxy_set_header                        Upgrade           $http_upgrade;
83

84
      proxy_set_header                        Connection        $connection_upgrade;
85

86
      proxy_set_header X-Request-ID           $req_id;
87
      proxy_set_header X-Real-IP              $remote_addr;
88

89
      proxy_set_header X-Forwarded-For        $remote_addr;
90

91
      proxy_set_header X-Forwarded-Host       $best_http_host;
92
      proxy_set_header X-Forwarded-Port       $pass_port;
93
      proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
94
      proxy_set_header X-Forwarded-Scheme     $pass_access_scheme;
95

96
      proxy_set_header X-Scheme               $pass_access_scheme;
97

98
      # Pass the original X-Forwarded-For
99
      proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;
100

101
      # mitigate HTTPoxy Vulnerability
102
      # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
103
      proxy_set_header Proxy                  "";
104

105
      # Custom headers to proxied server
106

107
      proxy_connect_timeout                   5s;
108
      proxy_send_timeout                      60s;
109
      proxy_read_timeout                      60s;
110

111
      proxy_buffering                         off;
112
      proxy_buffer_size                       4k;
113
      proxy_buffers                           4 4k;
114

115
      proxy_max_temp_file_size                1024m;
116

117
      proxy_request_buffering                 on;
118
      proxy_http_version                      1.1;
119

120
      proxy_cookie_domain                     off;
121
      proxy_cookie_path                       off;
122

123
      # In case of errors try the next upstream server before returning an error
124
      proxy_next_upstream                     error timeout;
125
      proxy_next_upstream_timeout             0;
126
      proxy_next_upstream_tries               3;
127

128
      proxy_pass http://upstream_balancer;
129

130
      proxy_redirect                          off;
131

132
    }
133

134
  }
135
  ## end server ngdemo.tianch.com.cn

展开收起

可以在 nginx.conf 配置文件中看到上面新增的 Ingress 资源对象的相关配置信息，不过需要注意的是现在并不会为每个 backend 后端都创建一个 upstream 配置块，现在是使用 Lua 程序进行动态处理的，所以没有直接看到后端的 Endpoints 相关配置数据。

Nginx配置#

如果想进行一些自定义配置，则有几种方式可以实现：使用 Configmap 在 Nginx 中设置全局配置、通过 Ingress 的 Annotations 设置特定 Ingress 的规则、自定义模板。接下来重点介绍使用注解来对 Ingress 对象进行自定义。

Basic Auth#

可以在 Ingress 对象上配置一些基本的 Auth 认证，比如 Basic Auth，可以用 htpasswd 生成一个密码文件来验证身份验证。

Terminal window

1
# 没有htpasswd命令的先安装一下
2
yum -y install httpd-tools

Terminal window

1
htpasswd -c auth foo
2
New password:
3
Re-type new password:
4
Adding password for user foo

Terminal window

1
kubectl create secret generic basic-auth --from-file=auth

Terminal window

1
kubectl get secret basic-auth -o yaml

image-20231115142331751

然后对上面的 my-nginx 应用创建一个具有 Basic Auth 的 Ingress 对象：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: ingress-with-auth
5
  namespace: default
6
  annotations:
7
    nginx.ingress.kubernetes.io/auth-type: basic # 认证类型
8
    nginx.ingress.kubernetes.io/auth-secret: basic-auth # 包含 user/password 定义的 secret 对象名
9
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required - foo" # 要显示的带有适当上下文的消息，说明需要身份验证的原因
10
spec:
11
  ingressClassName: nginx # 使用 nginx 的 IngressClass（关联的 ingress-nginx 控制器）
12
  rules:
13
    - host: bauth.tianch.com.cn # 将域名映射到 my-nginx 服务
14
      http:
15
        paths:
16
          - path: /
17
            pathType: Prefix
18
            backend:
19
              service: # 将所有请求发送到 my-nginx 服务的 80 端口
20
                name: my-nginx
21
                port:
22
                  number: 80

展开收起

image-20231115142834835

image-20231115142851687

Terminal window

1
curl -v http://bauth.tianch.com.cn -H 'Host: bauth.tianch.com.cn'

image-20231115143059604

可以看到出现了 401 认证失败错误，然后带上配置的用户名和密码进行认证：

Terminal window

1
curl -v http://bauth.tianch.com.cn -H 'Host: bauth.tianch.com.cn' -u 'foo:77589910'

image-20231115143227126

可以看到已经认证成功了。除了可以使用自己在本地集群创建的 Auth 信息之外，还可以使用外部的 Basic Auth 认证信息，比如使用 https://httpbin.org 的外部 Basic Auth 认证，创建如下所示的 Ingress 资源对象：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  annotations:
5
    # 配置外部认证服务地址
6
    nginx.ingress.kubernetes.io/auth-url: https://httpbin.org/basic-auth/user/passwd
7
  name: external-auth
8
  namespace: default
9
spec:
10
  ingressClassName: nginx
11
  rules:
12
    - host: external-bauth.tianch.com.cn
13
      http:
14
        paths:
15
          - path: /
16
            pathType: Prefix
17
            backend:
18
              service:
19
                name: my-nginx
20
                port:
21
                  number: 80

展开收起

创建资源对象:

Terminal window

1
kubectl apply -f my-nginx-with-external-auth.yaml

测试:

Terminal window

1
curl -k http://external-bauth.tianch.com.cn -v -H 'Host: external-bauth.tianch.com.cn'

image-20231115162235540

使用正确的用户名和密码测试：

Terminal window

1
curl -k http://external-bauth.tianch.com.cn -v -H 'Host: external-bauth.tianch.com.cn' -u 'user:passwd'

image-20231115162332471

用户名或者密码错误则同样会出现 401 的状态码：

Terminal window

1
curl -k http://external-bauth.tianch.com.cn -v -H 'Host: external-bauth.tianch.com.cn' -u 'user:passwd111'

image-20231115162416144

Terminal window

1
curl -k http://external-bauth.tianch.com.cn -v -H 'Host: external-bauth.tianch.com.cn' -u 'user111:passwd'

image-20231115162448926

除了 Basic Auth 这一种简单的认证方式之外，ingress-nginx 还支持一些其他高级的认证，比如可以使用 GitHub OAuth 来认证 Kubernetes 的 Dashboard。

URL Rewrite#

ingress-nginx 很多高级的用法可以通过 Ingress 对象的 annotation 进行配置，比如常用的 URL Rewrite 功能。很多时候会将 ingress-nginx 当成网关使用，比如对访问的服务加上 /app 这样的前缀，在 nginx 的配置里面有一个 proxy_pass 指令可以实现：

Terminal window

1
location /app/ {
2
  proxy_pass http://127.0.0.1/remote/;
3
}

proxy_pass 后面加了 /remote 这个路径，此时会将匹配到该规则路径中的 /app 用 /remote 替换掉，相当于截掉路径中的 /app。同样的在 Kubernetes 中使用 ingress-nginx 的 rewrite-target 注解来实现这个需求，比如现在要通过 rewrite.tianch.com.cn/gateway/ 来访问到 Nginx 服务，则需要对访问的 URL 路径做一个 Rewrite，在 PATH 中添加一个 gateway 的前缀，关于 Rewrite 的操作在 ingress-nginx 官方文档中也给出对应的说明:

ingress nginx rewrite

按照要求需要在 path 中匹配前缀 gateway，然后通过 rewrite-target 指定目标，Ingress 对象如下所示：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: rewrite
5
  annotations:
6
    nginx.ingress.kubernetes.io/rewrite-target: /$2
7
spec:
8
  ingressClassName: nginx
9
  rules:
10
    - host: rewrite.tianch.com.cn
11
      http:
12
        paths:
13
          - path: /gateway(/|$)(.*)
14
            pathType: Prefix
15
            backend:
16
              service:
17
                name: my-nginx
18
                port:
19
                  number: 80

展开收起

更新后，可以预见到直接访问域名肯定是不行了，因为没有匹配 / 的 path 路径：

image-20231115164910681

带上 gateway 的前缀再去访问:

image-20231115164950861

可以看到已经可以访问到了，这是因为在 path 中通过正则表达式 /gateway(/|$)(.*) 将匹配的路径设置成了 rewrite-target 的目标路径了，所以访问 rewite.tianch.com.cn/gateway/ 的时候实际上相当于访问的就是后端服务的 / 路径。

要解决访问主域名出现 404 的问题，可以给应用设置一个 app-root 的注解，这样当访问主域名的时候会自动跳转到指定的 app-root 目录下面，如下所示：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: rewrite
5
  annotations:
6
    nginx.ingress.kubernetes.io/app-root: /gateway/
7
    nginx.ingress.kubernetes.io/rewrite-target: /$2
8
spec:
9
  ingressClassName: nginx
10
  rules:
11
    - host: rewrite.tianch.com.cn
12
      http:
13
        paths:
14
          - path: /gateway(/|$)(.*)
15
            pathType: Prefix
16
            backend:
17
              service:
18
                name: my-nginx
19
                port:
20
                  number: 80

展开收起

更新应用后访问主域名 rewrite.tianch.com.cn 就会自动跳转到 rewrite.tianch.com.cn/gateway/ 路径下面去了。但是还有一个问题是 path 路径其实也匹配了 /app 这样的路径，希望应用在最后添加一个 / 这样的 slash，同样可以通过 configuration-snippet 配置来完成，如下 Ingress 对象：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: rewrite
5
  annotations:
6
    nginx.ingress.kubernetes.io/app-root: /gateway/
7
    nginx.ingress.kubernetes.io/rewrite-target: /$2
8
    nginx.ingress.kubernetes.io/configuration-snippet: |
9
      rewrite ^(/gateway)$ $1/ redirect;
10
spec:
11
  ingressClassName: nginx
12
  rules:
13
    - host: rewrite.tianch.com.cn
14
      http:
15
        paths:
16
          - path: /gateway(/|$)(.*)
17
            pathType: Prefix
18
            backend:
19
              service:
20
                name: my-nginx
21
                port:
22
                  number: 80

展开收起

更新后应用就都会以 / 这样的 slash 结尾了。

灰度发布#

在日常工作中经常需要对服务进行版本更新升级，所以经常会使用到滚动升级、蓝绿发布、灰度发布等不同的发布操作。而 ingress-nginx 支持通过 Annotations 配置来实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。

ingress-nginx 的 Annotations 支持以下 4 种 Canary 规则：

nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always 时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (canary-by-header) 一起使用。
nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求，权重为 100 意味着所有请求都将被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基于 cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的 cookie。当 cookie 值设置为 always 时，它将被路由到 Canary 入口；当 cookie 值设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

需要注意的是金丝雀规则按优先顺序进行排序：canary-by-header - > canary-by-cookie - > canary-weight

总的来说可以把以上的四个 annotation 规则划分为以下两类：

基于权重的 Canary 规则
基于权重的 Canary 规则
基于用户请求的 Canary 规则
基于用户请求的 Canary 规则

下面我们通过一个示例应用来对灰度发布功能进行说明。

第一步. 部署 Production 应用#

首先创建一个 production 环境的应用资源清单：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: production
5
  labels:
6
    app: production
7
spec:
8
  selector:
9
    matchLabels:
10
      app: production
11
  template:
12
    metadata:
13
      labels:
14
        app: production
15
    spec:
16
      containers:
17
        - name: production
18
          image: cnych/echoserver
19
          ports:
20
            - containerPort: 8080
21
          env:
22
            - name: NODE_NAME
23
              valueFrom:
24
                fieldRef:
25
                  fieldPath: spec.nodeName
26
            - name: POD_NAME
27
              valueFrom:
28
                fieldRef:
29
                  fieldPath: metadata.name
30
            - name: POD_NAMESPACE
31
              valueFrom:
32
                fieldRef:
33
                  fieldPath: metadata.namespace
34
            - name: POD_IP
35
              valueFrom:
36
                fieldRef:
37
                  fieldPath: status.podIP
38
---
39
apiVersion: v1
40
kind: Service
41
metadata:
42
  name: production
43
  labels:
44
    app: production
45
spec:
46
  ports:
47
    - port: 80
48
      targetPort: 8080
49
      name: http
50
  selector:
51
    app: production

展开收起

然后创建一个用于 production 环境访问的 Ingress 资源对象：

Terminal window展开收起

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: production
5
spec:
6
  ingressClassName: nginx
7
  rules:
8
  - host: echo.tianch.com.cn
9
    http:
10
      paths:
11
      - path: /
12
        pathType: Prefix
13
        backend:
14
          service:
15
            name: production
16
            port:
17
              number: 80

展开收起

直接创建上面的几个资源对象：

Terminal window

1
kubectl apply -f production.yaml
2
kubectl apply -f production-ingress.yaml
3
kubectl get pods -l app=production

image-20231115171707059

应用部署成功后，将域名 echo.tianch.com.cn 解析到 master 节点（ingress-nginx 所在的节点）的 IP 即可正常访问应用：

image-20231115171747367

第二步. 创建 Canary 版本#

参考将上述 Production 版本的 production.yaml 文件，再创建一个 Canary 版本的应用。

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: canary
5
  labels:
6
    app: canary
7
spec:
8
  selector:
9
    matchLabels:
10
      app: canary
11
  template:
12
    metadata:
13
      labels:
14
        app: canary
15
    spec:
16
      containers:
17
        - name: canary
18
          image: cnych/echoserver
19
          ports:
20
            - containerPort: 8080
21
          env:
22
            - name: NODE_NAME
23
              valueFrom:
24
                fieldRef:
25
                  fieldPath: spec.nodeName
26
            - name: POD_NAME
27
              valueFrom:
28
                fieldRef:
29
                  fieldPath: metadata.name
30
            - name: POD_NAMESPACE
31
              valueFrom:
32
                fieldRef:
33
                  fieldPath: metadata.namespace
34
            - name: POD_IP
35
              valueFrom:
36
                fieldRef:
37
                  fieldPath: status.podIP
38
---
39
apiVersion: v1
40
kind: Service
41
metadata:
42
  name: canary
43
  labels:
44
    app: canary
45
spec:
46
  ports:
47
    - port: 80
48
      targetPort: 8080
49
      name: http
50
  selector:
51
    app: canary

展开收起

创建上面的资源对象,接下来就可以通过配置 Annotation 规则进行流量切分了。

Terminal window

1
kubectl apply -f canary.yaml

image-20231115172049502

第三步. Annotation 规则配置#

1. 基于权重：基于权重的流量切分的典型应用场景就是蓝绿部署，可通过将权重设置为 0 或 100 来实现。例如，可将 Green 版本设置为主要部分，并将 Blue 版本的入口配置为 Canary。最初，将Blue版本的权重设置为 0，因此不会将流量代理到 Blue 版本。一旦新版本测试和验证都成功后，即可将 Blue 版本的权重设置为 100，即所有流量从 Green 版本转向 Blue。

创建一个基于权重的 Canary 版本的应用路由 Ingress 对象:

Terminal window展开收起

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: canary
5
  annotations:
6
    nginx.ingress.kubernetes.io/canary: 'true' # 要开启灰度发布机制，首先需要启用 Canary
7
    nginx.ingress.kubernetes.io/canary-weight: '30' # 分配30%流量到当前Canary版本
8
spec:
9
  ingressClassName: nginx
10
  rules:
11
  - host: echo.tianch.com.cn
12
    http:
13
      paths:
14
      - path: /
15
        pathType: Prefix
16
        backend:
17
          service:
18
            name: canary
19
            port:
20
              number: 80

展开收起

创建上面的资源对象：

image-20231115172714676

Canary 版本应用创建成功后，在命令行终端中来不断访问这个应用，观察 Hostname 变化：

Terminal window

1
for i in $(seq 1 10); do curl -s echo.tianch.com.cn | grep "Hostname"; done

image-20231115173138621

由于给 Canary 版本应用分配了 30% 左右权重的流量，所以上面每访问 10 次有 3-4 次访问到了 Canary 版本的应用，是符合预期的。

2. 基于 Request Header: 基于 Request Header 进行流量切分的典型应用场景即灰度发布或 A/B 测试场景。

在上面的 Canary 版本的 Ingress 对象中新增一条 annotation 配置 nginx.ingress.kubernetes.io/canary-by-header: canary（这里的 value 可以是任意值），使当前的 Ingress 实现基于 Request Header 进行流量切分，由于 canary-by-header 的优先级大于 canary-weight，所以会忽略原有的 canary-weight 的规则。

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: canary
5
  annotations:
6
    nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
7
    nginx.ingress.kubernetes.io/canary-by-header: canary # 基于header的流量切分
8
    nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
9
spec:
10
  ingressClassName: nginx
11
  rules:
12
    - host: echo.tianch.com.cn
13
      http:
14
        paths:
15
          - path: /
16
            pathType: Prefix
17
            backend:
18
              service:
19
                name: canary
20
                port:
21
                  number: 80

展开收起

更新上面的 Ingress 资源对象后，在请求中加入不同的 Header 值，再次访问应用的域名。

注意：当 Request Header 设置为 never 或 always 时，请求将不会或一直被发送到 Canary 版本，对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他 Canary 规则进行优先级的比较。

Terminal window

1
for i in $(seq 1 10); do curl -s -H "canary: never" echo.tianch.com.cn | grep "Hostname"; done

image-20231115173726435

在请求的时候设置了 canary: never 这个 Header 值，所以请求没有发送到 Canary 应用中去。如果设置为其他值:

Terminal window

1
for i in $(seq 1 10); do curl -s -H "canary: other-value" echo.tianch.com.cn | grep "Hostname"; done

image-20231115173918588

由于请求设置的 Header 值为 canary: other-value，所以 ingress-nginx 会通过优先级将请求与其他 Canary 规则进行优先级的比较，也就会进入 canary-weight: "30" 这个规则去。

在请求的时候设置 canary: always

Terminal window

1
for i in $(seq 1 10); do curl -s -H "canary: always" echo.tianch.com.cn | grep "Hostname"; done

image-20231115174132721

在请求的时候设置了 canary: always 这个 Header 值，所以请求都发送到了 Canary 应用中去。

在上一个 annotation (即 canary-by-header）的基础上添加一条 nginx.ingress.kubernetes.io/canary-by-header-value: user-value 这样的规则，就可以将请求路由到 Canary Ingress 中指定的服务了。

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: canary
5
  annotations:
6
    nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
7
    nginx.ingress.kubernetes.io/canary-by-header-value: user-value
8
    nginx.ingress.kubernetes.io/canary-by-header: canary # 基于header的流量切分
9
    nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
10
spec:
11
  ingressClassName: nginx
12
  rules:
13
    - host: echo.tianch.com.cn
14
      http:
15
        paths:
16
          - path: /
17
            pathType: Prefix
18
            backend:
19
              service:
20
                name: canary
21
                port:
22
                  number: 80

展开收起

同样更新 Ingress 对象后，重新访问应用，当 Request Header 满足 canary: user-value时，所有请求就会被路由到 Canary 版本：

Terminal window

1
for i in $(seq 1 10); do curl -s -H "canary: user-value" echo.tianch.com.cn | grep "Hostname"; done

image-20231115175126035

3. 基于 Cookie：与基于 Request Header 的 annotation 用法规则类似。例如在 A/B 测试场景下，需要让地域为北京的用户访问 Canary 版本。那么当 cookie 的 annotation 设置为 nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing"，此时后台可对登录的用户请求进行检查，如果该用户访问源来自北京则设置 cookie users_from_Beijing 的值为 always，这样就可以确保北京的用户仅访问 Canary 版本。

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: canary
5
  annotations:
6
    nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
7
    nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing" # 基于 cookie
8
    nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
9
spec:
10
  ingressClassName: nginx
11
  rules:
12
    - host: echo.tianch.com.cn
13
      http:
14
        paths:
15
          - path: /
16
            pathType: Prefix
17
            backend:
18
              service:
19
                name: canary
20
                port:
21
                  number: 80

展开收起

更新 Canary 版本的 Ingress 资源对象，采用基于 Cookie 来进行流量切分

更新上面的 Ingress 资源对象后，在请求中设置一个 users_from_Beijing=always 的 Cookie 值，再次访问应用的域名。

Terminal window

1
for i in $(seq 1 10); do curl -s -b "users_from_Beijing=always" echo.tianch.com.cn | grep "Hostname"; done

image-20231115175756547

可以看到应用都被路由到了 Canary 版本的应用中去了，如果将这个 Cookie 值设置为 never，则不会路由到 Canary 应用中。

HTTPS#

如果需要用 HTTPS 来访问这个应用的话，就需要监听 443 端口了，同样用 HTTPS 访问应用必然就需要证书，这里用 openssl 来创建一个自签名的证书：

Terminal window

1
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout tls.tianch.com.cn.key -out tls.tianch.com.cn.crt -subj "/CN=tls.tianch.com.cn"

然后通过 Secret 对象来引用证书文件：

Terminal window

1
kubectl create secret tls tls.tianch.com.cn-tls --cert=tls.tianch.com.cn.crt --key=tls.tianch.com.cn.key

创建一个 HTTPS 访问的应用：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: ingress-with-auth
5
  annotations:
6
    # 认证类型
7
    nginx.ingress.kubernetes.io/auth-type: basic
8
    # 包含 user/password 定义的 secret 对象名
9
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
10
    # 要显示的带有适当上下文的消息，说明需要身份验证的原因
11
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required - foo"
12
spec:
13
  ingressClassName: nginx
14
  tls: # 配置 tls 证书
15
    - hosts:
16
        - tls.tianch.com.cn
17
      secretName: tls.tianch.com.cn-tls
18
  rules:
19
    - host: tls.tianch.com.cn
20
      http:
21
        paths:
22
          - path: /
23
            pathType: Prefix
24
            backend:
25
              service:
26
                name: my-nginx
27
                port:
28
                  number: 80

展开收起

image-20231115180816893

除了自签名证书或者购买正规机构的 CA 证书之外，还可以通过一些工具来自动生成合法的证书，cert-manager 是一个云原生证书管理开源项目，可以用于在 Kubernetes 集群中提供 HTTPS 证书并自动续期，支持 Let's Encrypt/HashiCorp/Vault 这些免费证书的签发。在 Kubernetes 中，可以通过 Kubernetes Ingress 和 Let’s Encrypt 实现外部服务的自动化 HTTPS。

TCP 与 UDP#

由于在 Ingress 资源对象中没有直接对 TCP 或 UDP 服务的支持，要在 ingress-nginx 中提供支持，需要在控制器启动参数中添加 --tcp-services-configmap 和 --udp-services-configmap 标志指向一个 ConfigMap，其中的 key 是要使用的外部端口，value 值是使用格式 <namespace/service name>:<service port>:[PROXY]:[PROXY] 暴露的服务，端口可以使用端口号或者端口名称，最后两个字段是可选的，用于配置 PROXY 代理。

比如现在要通过 ingress-nginx 来暴露一个 MongoDB 服务，首先创建如下的应用：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: mongo
5
  labels:
6
    app: mongo
7
spec:
8
  selector:
9
    matchLabels:
10
      app: mongo
11
  template:
12
    metadata:
13
      labels:
14
        app: mongo
15
    spec:
16
      volumes:
17
        - name: data
18
          emptyDir: {}
19
      containers:
20
        - name: mongo
21
          image: mongo:4.0
22
          ports:
23
            - containerPort: 27017
24
          volumeMounts:
25
            - name: data
26
              mountPath: /data/db
27
---
28
apiVersion: v1
29
kind: Service
30
metadata:
31
  name: mongo
32
spec:
33
  selector:
34
    app: mongo
35
  ports:
36
    - port: 27017

展开收起

创建上面的资源对象：

Terminal window

1
kubectl apply -f mongo.yaml
2
kubectl get svc
3
kubectl get pods -l app=mongo

image-20231115181313479

要通过 ingress-nginx 来暴露上面的 MongoDB 服务，需要创建一个如下所示的 ConfigMap：

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: mango-tcp-service
5
  namespace: ingress-nginx
6
data:
7
  "27017": default/mongo:27017

然后在 ingress-nginx 的启动参数中添加 --tcp-services-configmap=$(POD_NAMESPACE)/ingress-nginx-tcp 这样的配置即可，由于这里使用的是 Helm Chart 进行安装的，只需要去覆盖 Values 值重新安装即可，修改 values.yaml 文件：

1
tcp: # 配置 tcp 服务
2
  27017: "default/mongo:27017" # 使用 27017 端口去映射 mongo 服务
3
  # 9000: "default/test:8080"   # 如果还需要暴露其他 TCP 服务，继续添加即可

配置完成后重新更新当前的 ingress-nginx：

Terminal window

1
# 进入到values.yaml所在的文件夹
2
helm upgrade --install ingress-nginx . -f values.yaml --namespace ingress-nginx

重新部署完成后会自动生成一个名为 ingress-nginx-tcp 的 ConfigMap 对象，如下所示：

Terminal window

1
kubectl get configmap -n ingress-nginx ingress-nginx-tcp -o yaml

image-20231115182038742

Terminal window

1
kubectl get pods -n ingress-nginx
2
kubectl get pod ingress-nginx-controller-fzlpl -n ingress-nginx -o yaml

image-20231115182748257

可以看到在 ingress-nginx 的启动参数中也添加上了 --tcp-services-configmap=$(POD_NAMESPACE)/ingress-nginx-tcp 这样的配置

现在就可以通过 ingress-nginx 暴露的 27017 端口去访问 Mongo 服务了：

image-20231115183043201

同样也可以去查看最终生成的 nginx.conf 配置文件：

Terminal window

1
kubectl exec -it ingress-nginx-controller-fzlpl -n ingress-nginx -- cat /etc/nginx/nginx.conf

image-20231115183240391

TCP 相关的配置位于 stream 配置块下面。从 Nginx 1.9.13 版本开始提供 UDP 负载均衡，同样也可以在 ingress-nginx 中来代理 UDP 服务，比如可以去暴露 kube-dns 的服务，同样需要创建一个如下所示的 ConfigMap：

Terminal window

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: udp-services
5
  namespace: ingress-nginx
6
data:
7
  53: 'kube-system/kube-dns:53'

然后需要在 ingress-nginx 参数中添加一个 - --udp-services-configmap=$(POD_NAMESPACE)/udp-services 这样的配置，当然这里只需要去修改 Values 文件值即可，修改 values.yaml 文件：

1
# ...... 其他部分省略，和之前的保持一致
2

3
tcp: # 配置 tcp 服务
4
  27017: "default/mongo:27017" # 使用 27017 端口去映射 mongo 服务
5
  # 9000: "default/test:8080"   # 如果还需要暴露其他 TCP 服务，继续添加即可
6

7
udp: # 配置 udp 服务
8
  53: "kube-system/kube-dns:53"

然后重新更新即可。

全局配置#

除了可以通过 annotations 对指定的 Ingress 进行定制之外，还可以配置 ingress-nginx 的全局配置，在控制器启动参数中通过标志 --configmap 指定了一个全局的 ConfigMap 对象，可以将全局的一些配置直接定义在该对象中即可：

1
containers:
2
  - args:
3
    - /nginx-ingress-controller
4
    - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
5
    ......

比如这里用于全局配置的 ConfigMap 名为 ingress-nginx-controller：

Terminal window

1
kubectl get configmap -n ingress-nginx

image-20231129183030181

比如可以添加如下所示的一些常用配置：

Terminal window

1
kubectl edit configmap ingress-nginx-controller -n ingress-nginx

1
apiVersion: v1
2
data:
3
  allow-snippet-annotations: "true"
4
  client-header-buffer-size: 32k  # 注意不是下划线
5
  client-max-body-size: 5m
6
  use-gzip: "true"
7
  gzip-level: "7"
8
  large-client-header-buffers: 4 32k
9
  proxy-connect-timeout: 11s
10
  proxy-read-timeout: 12s
11
  keep-alive: "75"   # 启用keep-alive，连接复用，提高QPS
12
  keep-alive-requests: "100"
13
  upstream-keepalive-connections: "10000"
14
  upstream-keepalive-requests: "100"
15
  upstream-keepalive-timeout: "60"
16
  disable-ipv6: "true"
17
  disable-ipv6-dns: "true"
18
  max-worker-connections: "65535"
19
  max-worker-open-files: "10240"
20
kind: ConfigMap
21
......

展开收起

修改完成后 Nginx 配置会自动重载生效，可以查看 nginx.conf 配置文件进行验证：

Terminal window

1
kubectl exec -it ingress-nginx-controller-fzlpl -n ingress-nginx -- cat /etc/nginx/nginx.conf |grep large_client_header_buffers

image-20231129183504115

由于这里是 Helm Chart 安装的，为了保证重新部署后配置还在，同样需要通过 Values 进行全局配置：

1
controller:
2
  config:
3
    allow-snippet-annotations: 'true'
4
    client-header-buffer-size: 32k # 注意不是下划线
5
    client-max-body-size: 5m
6
    use-gzip: 'true'
7
    gzip-level: '7'
8
    large-client-header-buffers: 4 32k
9
    proxy-connect-timeout: 11s
10
    proxy-read-timeout: 12s
11
    keep-alive: '75' # 启用keep-alive，连接复用，提高QPS
12
    keep-alive-requests: '100'
13
    upstream-keepalive-connections: '10000'
14
    upstream-keepalive-requests: '100'
15
    upstream-keepalive-timeout: '60'
16
    disable-ipv6: 'true'
17
    disable-ipv6-dns: 'true'
18
    max-worker-connections: '65535'
19
    max-worker-open-files: '10240'
20
......

展开收起

此外往往还需要对 ingress-nginx 部署的节点进行性能优化，修改一些内核参数，使得适配 Nginx 的使用场景，一般是直接去修改节点上的内核参数，为了能够统一管理，可以使用 initContainers 来进行配置：

1
initContainers:
2
- command:
3
  - /bin/sh
4
  - -c
5
  - |
6
    mount -o remount rw /proc/sys
7
    sysctl -w net.core.somaxconn=65535  # 具体的配置视具体情况而定
8
    sysctl -w net.ipv4.tcp_tw_reuse=1
9
    sysctl -w net.ipv4.ip_local_port_range="1024 65535"
10
    sysctl -w fs.file-max=1048576
11
    sysctl -w fs.inotify.max_user_instances=16384
12
    sysctl -w fs.inotify.max_user_watches=524288
13
    sysctl -w fs.inotify.max_queued_events=16384
14
image: busybox
15
imagePullPolicy: IfNotPresent
16
name: init-sysctl
17
securityContext:
18
  capabilities:
19
    add:
20
    - SYS_ADMIN
21
    drop:
22
    - ALL
23
......

展开收起

由于这里使用的是 Helm Chart 安装的 ingress-nginx，同样只需要去配置 Values 值即可，模板中提供了对 initContainers 的支持，配置如下所示：

1
controller:
2
  # 其他省略，配置 initContainers
3
  extraInitContainers:
4
    - name: init-sysctl
5
      image: busybox
6
      securityContext:
7
        capabilities:
8
          add:
9
            - SYS_ADMIN
10
          drop:
11
            - ALL
12
      command:
13
        - /bin/sh
14
        - -c
15
        - |
16
          mount -o remount rw /proc/sys
17
          sysctl -w net.core.somaxconn=65535  # socket监听的backlog上限
18
          sysctl -w net.ipv4.tcp_tw_reuse=1  # 开启重用，允许将 TIME-WAIT sockets 重新用于新的TCP连接
19
          sysctl -w net.ipv4.ip_local_port_range="1024 65535"
20
          sysctl -w fs.file-max=1048576
21
          sysctl -w fs.inotify.max_user_instances=16384
22
          sysctl -w fs.inotify.max_user_watches=524288
23
          sysctl -w fs.inotify.max_queued_events=16384

展开收起

重新部署即可：

Terminal window

1
helm upgrade --install ingress-nginx . -f values.yaml --namespace ingress-nginx

部署完成后通过 initContainers 就可以修改节点内核参数了，生产环境建议对节点内核参数进行相应的优化。

Kubernetes-Ingress

Tue, 14 Nov 2023 00:00:00 GMT

前面学习了在 Kubernetes 集群内部使用 kube-dns 实现服务发现的功能，那么部署在 Kubernetes 集群中的应用如何暴露给外部的用户使用呢？可以使用 NodePort 和 LoadBlancer 类型的 Service 可以把应用暴露给外部用户使用，除此之外，Kubernetes 还提供了一个非常重要的资源对象可以用来暴露服务给外部用户，那就是 Ingress。对于小规模的应用使用 NodePort 或许能够满足需求，但是当应用越来越多的时候，就会发现对于 NodePort 的管理就非常麻烦了，这个时候使用 Ingress 就非常方便了，可以避免管理大量的端口。

资源对象#

Ingress 资源对象是 Kubernetes 内置定义的一个对象，是从 Kuberenets 集群外部访问集群的一个入口，将外部的请求转发到集群内不同的 Service 上，其实就相当于 nginx、haproxy 等负载均衡代理服务器，可能会觉得直接使用 nginx 就实现了，但是只使用 nginx 这种方式有很大缺陷，每次有新服务加入的时候怎么改 Nginx 配置？不可能去手动更改或者滚动更新前端的 Nginx Pod 吧？那再加上一个服务发现的工具比如 consul 如何？貌似是可以，Ingress 实际上就是这样实现的，只是服务发现的功能自己实现了，不需要使用第三方的服务了，然后再加上一个域名规则定义，路由信息的刷新依靠 Ingress Controller 来提供。

ingress flow

Ingress Controller 可以理解为一个监听器，通过不断地监听 kube-apiserver，实时的感知后端 Service、Pod 的变化，当得到这些信息变化后，Ingress Controller 再结合 Ingress 的配置，更新反向代理负载均衡器，达到服务发现的作用。其实这点和服务发现工具 consul、 consul-template 非常类似。

定义#

一个常见的 Ingress 资源清单如下所示：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: demo-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/rewrite-target: /
7
spec:
8
  rules:
9
    - http:
10
        paths:
11
          - path: /testpath
12
            pathType: Prefix
13
            backend:
14
              service:
15
                name: test
16
                port:
17
                  number: 80

展开收起

上面这个 Ingress 资源的定义，配置了一个路径为 /testpath 的路由，所有 /testpath/** 的入站请求，会被 Ingress 转发至名为 test 的服务的 80 端口的 / 路径下。可以将 Ingress 狭义的理解为 Nginx 中的配置文件 nginx.conf。

此外 Ingress 经常使用注解 annotations 来配置一些选项，当然这具体取决于 Ingress 控制器的实现方式，不同的 Ingress 控制器支持不同的注解。

Ingress 资源清单的描述我们可以使用 kubectl explain 命令来了解：

Terminal window

1
kubectl explain Ingress

Terminal window

1
kubectl explain Ingress.spec

image-20231114181105758

image-20231114181212955

从上面描述可以看出 Ingress 资源对象中有几个重要的属性：defaultBackend、ingressClassName、rules、tls。

rules#

其中核心部分是 rules 属性的配置，每个路由规则都在下面进行配置：

host：可选字段，上面没有指定 host 属性，所以该规则适用于通过指定 IP 地址的所有入站 HTTP 通信，如果提供了 host 域名，则 rules 则会匹配该域名的相关请求，此外 host 主机名可以是精确匹配（例如 foo.bar.com）或者使用通配符来匹配（例如 *.foo.com）。
http.paths：定义访问的路径列表，比如上面定义的 /testpath，每个路径都有一个由 backend.service.name 和 backend.service.port.number 定义关联的 Service 后端，在控制器将流量路由到引用的服务之前，host 和 path 都必须匹配传入的请求才行。
backend：该字段其实就是用来定义后端的 Service 服务的，与路由规则中 host 和 path 匹配的流量会将发送到对应的 backend 后端去。

此外一般情况下在 Ingress 控制器中会配置一个 defaultBackend 默认后端，当请求不匹配任何 Ingress 中的路由规则的时候会使用该后端。defaultBackend 通常是 Ingress 控制器的配置选项，而非在 Ingress 资源中指定。

resource#

backend 后端除了可以引用一个 Service 服务之外，还可以通过一个 resource 资源进行关联，Resource 是当前 Ingress 对象命名空间下引用的另外一个 Kubernetes 资源对象，但是需要注意的是 Resource 与 Service 配置是互斥的，只能配置一个，Resource 后端的一种常见用法是将所有入站数据导向带有静态资产的对象存储后端，如下所示：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: ingress-resource-backend
5
spec:
6
  rules:
7
    - http:
8
        paths:
9
          - path: /icons
10
            pathType: ImplementationSpecific
11
            backend:
12
              resource:
13
                apiGroup: k8s.example.com
14
                kind: StorageBucket
15
                name: icon-assets

展开收起

该 Ingress 资源对象描述了所有的 /icons 请求会被路由到同命名空间下的名为 icon-assets 的 StorageBucket 资源中去进行处理。

pathType#

上面的示例中在定义路径规则的时候都指定了一个 pathType 的字段，事实上每个路径都需要有对应的路径类型，当前支持的路径类型有三种：

ImplementationSpecific：该路径类型的匹配方法取决于 IngressClass，具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理。
Exact：精确匹配 URL 路径，且区分大小写。
Prefix：基于以 / 分隔的 URL 路径前缀匹配，匹配区分大小写，并且对路径中的元素逐个完成，路径元素指的是由 / 分隔符分隔的路径中的标签列表。

Exact 比较简单，就是需要精确匹配 URL 路径，对于 Prefix 前缀匹配，需要注意如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配，例如 /foo/bar 可以匹配 /foo/bar/baz, 但不匹配 /foo/barbaz，可以查看下表了解更多的匹配场景（来自官网）：

20231114181732

在某些情况下，Ingress 中的多条路径会匹配同一个请求，这种情况下最长的匹配路径优先，如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。

IngressClass#

Kubernetes 1.18 起，正式提供了一个 IngressClass 资源，作用与 kubernetes.io/ingress.class 注解类似，因为可能在集群中有多个 Ingress 控制器，可以通过该对象来定义控制器，例如：

1
apiVersion: networking.k8s.io/v1
2
kind: IngressClass
3
metadata:
4
  name: external-lb
5
spec:
6
  controller: nginx-ingress-internal-controller
7
  parameters:
8
    apiGroup: k8s.example.com
9
    kind: IngressParameters
10
    name: external-lb

其中重要的属性是 metadata.name 和 spec.controller，前者是这个 IngressClass 的名称，需要设置在 Ingress 中，后者是 Ingress 控制器的名称。

Ingress 中的 spec.ingressClassName 属性就可以用来指定对应的 IngressClass，并进而由 IngressClass 关联到对应的 Ingress 控制器，如：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: myapp
5
spec:
6
  ingressClassName: external-lb # 上面定义的 IngressClass 对象名称
7
  defaultBackend:
8
    service:
9
      name: myapp
10
      port:
11
        number: 80

不过需要注意的是 spec.ingressClassName 与老版本的 kubernetes.io/ingress.class 注解的作用并不完全相同，因为 ingressClassName 字段引用的是 IngressClass 资源的名称，IngressClass 资源中除了指定了 Ingress 控制器的名称之外，还可能会通过 spec.parameters 属性定义一些额外的配置。

比如 parameters 字段有一个 scope 和 namespace 字段，可用来引用特定于命名空间的资源，对 Ingress 类进行配置。 scope 字段默认为 Cluster，表示默认是集群作用域的资源。将 scope 设置为 Namespace 并设置 namespace 字段就可以引用某特定命名空间中的参数资源，比如：

1
apiVersion: networking.k8s.io/v1
2
kind: IngressClass
3
metadata:
4
  name: external-lb
5
spec:
6
  controller: nginx-ingress-internal-controller
7
  parameters:
8
    apiGroup: k8s.example.com
9
    kind: IngressParameters
10
    name: external-lb
11
    namespace: external-configuration
12
    scope: Namespace

由于一个集群中可能有多个 Ingress 控制器，所以还可以将一个特定的 IngressClass 对象标记为集群默认是 Ingress 类。只需要将一个 IngressClass 资源的 ingressclass.kubernetes.io/is-default-class 注解设置为 true 即可，这样未指定 ingressClassName 字段的 Ingress 就会使用这个默认的 IngressClass。

如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 ingressClassName 的 Ingress 对象。最好的方式还是确保集群中最多只能有一个 IngressClass 被标记为默认。

TLS#

Ingress 资源对象还可以用来配置 https 的服务，可以通过设定包含 TLS 私钥和证书的 Secret 来保护 Ingress。 Ingress 只支持单个 TLS 端口 443，如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。需要注意 TLS Secret 必须包含名为 tls.crt 和 tls.key 的键名，例如：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: testsecret-tls
5
  namespace: default
6
data:
7
  tls.crt: base64 编码的 cert
8
  tls.key: base64 编码的 key
9
type: kubernetes.io/tls

在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道，需要确保创建的 TLS Secret 创建自包含 https-example.foo.com 的公用名称的证书，如下所示：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: tls-example-ingress
5
spec:
6
  tls:
7
    - hosts:
8
        - https-example.foo.com
9
      secretName: testsecret-tls
10
  rules:
11
    - host: https-example.foo.com
12
      http:
13
        paths:
14
          - path: /
15
            pathType: Prefix
16
            backend:
17
              service:
18
                name: service1
19
                port:
20
                  number: 80

展开收起

现在了解了如何定义 Ingress 资源对象了，但是仅创建 Ingress 资源本身没有任何效果。还需要部署 Ingress 控制器，例如 ingress-nginx，现在可以使用的 Ingress 控制器有很多，比如 traefik、nginx-controller、Kubernetes Ingress Controller for Kong、HAProxy Ingress controller，当然也可以自己实现一个 Ingress Controller，现在普遍用得较多的是 traefik 和 ingress-nginx，traefik 的性能比 ingress-nginx 差，但是配置使用要简单许多。

实际上社区目前还在开发一组高配置能力的 API，被称为 Service API，新 API 会提供一种 Ingress 的替代方案，它的存在目的不是替代 Ingress，而是提供一种更具配置能力的新方案。

Kubernetes-CoreDNS

Thu, 09 Nov 2023 00:00:00 GMT

前面可以通过 Service 生成的 ClusterIP(VIP) 来访问 Pod 提供的服务，但是在使用的时候还有一个问题：怎么知道某个应用的 VIP 呢？有两个应用，一个是 api 应用，一个是 db 应用，两个应用都是通过 Deployment 进行管理的，并且都通过 Service 暴露出了端口提供服务。api 需要连接到 db 这个应用，现在只知道 db 应用的名称和 db 对应的 Service 的名称，但是并不知道它的 VIP 地址，前面的 Service 中通过 ClusterIP 就可以访问到后面的 Pod 服务，知道 VIP 的地址就可以了。

环境变量#

为了解决上面的问题，在之前的版本中，Kubernetes 采用了环境变量的方法，每个 Pod 启动的时候，会通过环境变量设置所有服务的 IP 和 port 信息，这样 Pod 中的应用可以通过读取环境变量来获取依赖服务的地址信息，这种方法使用起来相对简单，但是有一个很大的问题就是依赖的服务必须在 Pod 启动之前就存在，不然是不会被注入到环境变量中的。比如首先创建一个 Nginx 服务：test-nginx.yaml

kubectl get pods -n default | grep Evicted | awk ‘{print$1}’| xargs kubectl delete -n default pods

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deploy
5
spec:
6
  replicas: 2
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx
18
          resources:
19
            limits:
20
              memory: "128Mi"
21
              cpu: "500m"
22
          ports:
23
            - containerPort: 80
24

25
---
26
apiVersion: v1
27
kind: Service
28
metadata:
29
  name: nginx-service
30
spec:
31
  selector:
32
    app: nginx
33
  ports:
34
    - port: 5000
35
      targetPort: 80

展开收起

创建上面的服务：

Terminal window

1
kubectl apply -f test-nginx.yaml

image-20231109111407293

可以看到两个 Pod 和一个名为 nginx-service 的服务创建成功了，该 Service 监听的端口是 5000，同时它会把流量转发给它代理的所有 Pod（这里就是拥有 app: nginx 标签的两个 Pod）。

再来创建一个普通的 Pod，观察下该 Pod 中的环境变量是否包含上面的 nginx-service 的服务信息：test-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: test-pod
5
spec:
6
  containers:
7
    - name: test-service-pod
8
      image: busybox
9
      command: ["/bin/sh", "-c", "env"]
10
      resources:
11
        limits:
12
          memory: "128Mi"
13
          cpu: "500m"

然后创建该测试的 Pod 并随后查看日志信息:

Terminal window

1
kubectl apply -f test-pod.yaml

Terminal window

1
kubectl logs test-pod -n default

image-20231109112149211

可以看到打印了很多环境变量信息，其中就包括刚刚创建的 nginx-service 这个服务，有 HOST、PORT、PROTO、ADDR 等，也包括其他已经存在的 Service 的环境变量，如果现在需要在这个 Pod 里面访问 nginx-service 的服务，可以直接通过 NGINX_SERVICE_SERVICE_HOST 和 NGINX_SERVICE_SERVICE_PORT 就可以了，但是如果这个 Pod 启动起来的时候 nginx-service 服务还没启动起来，在环境变量中是无法获取到这些信息的，当然可以通过 initContainer 之类的方法来确保 nginx-service 启动后再启动 Pod，但是这种方法毕竟增加了 Pod 启动的复杂性，所以这不是最优的方法，局限性太多了。

DNS#

由于上面环境变量这种方式存在局限性，所以需要一种更加智能的方案，那就是直接使用 Service 的名称，因为 Service 的名称不会变化，不需要关心分配的 ClusterIP 的地址，因为这个地址并不是固定不变的，所以如果直接使用 Service 的名字，然后对应的 ClusterIP 地址的转换能够自动完成。它们之间的转换功能通过 DNS 就可以解决了，同样的，Kubernetes 也提供了 DNS 的方案来解决上面的服务发现的问题。

DNS 服务不是一个独立的系统服务，而是作为一种 addon 插件而存在，现在比较推荐的两个插件：kube-dns 和 CoreDNS，实际上在比较新点的版本中已经默认是 CoreDNS 了，因为 kube-dns 默认一个 Pod 中需要 3 个容器配合使用，CoreDNS 只需要一个容器即可，搭建集群的时候直接安装的就是 CoreDNS 插件：

Terminal window

1
kubectl get pods -n kube-system -l k8s-app=kube-dns

image-20231109142312393

CoreDns 是用 GO 写的高性能，高扩展性的 DNS 服务，基于 HTTP/2 Web 服务 Caddy 进行编写的。CoreDns 内部采用插件机制，所有功能都是插件形式编写，用户也可以扩展自己的插件，以下是 Kubernetes 部署 CoreDns 时的默认配置：

1
apiVersion: v1
2
data:
3
  Corefile: |
4
    .:53 {
5
        errors           # 启用错误记录
6
        health {        # 启用健康检查检查端点，8080:health
7
          lameduck 5s
8
        }
9
        ready
10
        kubernetes cluster.local in-addr.arpa ip6.arpa {  # 处理 k8s 域名解析
11
          pods insecure
12
          fallthrough in-addr.arpa ip6.arpa
13
          ttl 30
14
        }
15
        prometheus :9153      # 启用 metrics 指标，9153:metrics
16
        forward . /etc/resolv.conf {  # 通过 resolv.conf 内的 nameservers 解析
17
          prefer_udp
18
          max_concurrent 1000
19
        }
20
        cache 30      # 通过 resolv.conf 内的 nameservers 解析
21
        loop          # 检查简单的转发循环并停止服务
22
        reload        # 运行自动重新加载 corefile，热更新
23
        loadbalance    # 负载均衡，默认 round_robin
24
    }
25
kind: ConfigMap
26
metadata:
27
  annotations:
28
    kubectl.kubernetes.io/last-applied-configuration: |
29
      {"apiVersion":"v1","data":{"Corefile":".:53 {\n    errors\n    health {\n      lameduck 5s\n    }\n    ready\n    kubernetes cluster.local in-addr.arpa ip6.arpa {\n      pods insecure\n      fallthrough in-addr.arpa ip6.arpa\n      ttl 30\n    }\n    prometheus :9153\n    forward . /etc/resolv.conf {\n      prefer_udp\n      max_concurrent 1000\n    }\n    cache 30\n    loop\n    reload\n    loadbalance\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"EnsureExists"},"name":"coredns","namespace":"kube-system"}}
30
  creationTimestamp: "2023-11-03T02:33:50Z"
31
  labels:
32
    addonmanager.kubernetes.io/mode: EnsureExists
33
  name: coredns
34
  namespace: kube-system
35
  resourceVersion: "273"
36
  uid: bdf90b96-0c07-45af-a119-818a51aae44b

展开收起

每个 {} 代表一个 zone,格式是 “Zone:port{}”, 其中"."代表默认 zone
{} 内的每个名称代表插件的名称，只有配置的插件才会启用，当解析域名时，会先匹配 zone（都未匹配会执行默认 zone），然后 zone 内的插件从上到下依次执行(这个顺序并不是配置文件内谁在前面的顺序，而是core/dnsserver/zdirectives.go内的顺序)，匹配后返回处理（执行过的插件从下到上依次处理返回逻辑），不再执行下一个插件

CoreDNS 的 Service 地址一般情况下是固定的，类似于 kubernetes 这个 Service 地址一般就是第一个 IP 地址 169.254.25.1，CoreDNS 的 Service 地址就是 169.254.25.10，该 IP 被分配后，kubelet 会将使用 --cluster-dns=<dns-service-ip> 参数配置的 DNS 传递给每个容器。DNS 名称也需要域名，本地域可以使用参数--cluster-domain = <default-local-domain> 在 kubelet 中配置：

Terminal window

1
cat /var/lib/kubelet/config.yaml

1
......
2
clusterDNS:
3
- 169.254.25.10
4
clusterDomain: cluster.local
5
......

如果建立的 Service 如果支持域名形式进行解析，就可以解决服务发现的问题，那么利用 kubedns 可以将 Service 生成怎样的 DNS 记录呢？

普通的 Service：会生成 servicename.namespace.svc.cluster.local 的域名，会解析到 Service 对应的 ClusterIP 上，在 Pod 之间的调用可以简写成 servicename.namespace，如果处于同一个命名空间下面，甚至可以只写成 servicename 即可访问
Headless Service：无头服务，就是把 clusterIP 设置为 None 的，会被解析为指定 Pod 的 IP 列表，同样还可以通过 podname.servicename.namespace.svc.cluster.local 访问到具体的某一个 Pod。

接下来使用一个简单 Pod 来测试下 Service 的域名访问：

Terminal window

1
kubectl run -it --image busybox test-dns --restart=Never --rm /bin/sh

image-20231109143743544

进入到 Pod 中，查看 /etc/resolv.conf 中的内容，可以看到 nameserver 的地址 169.254.25.10，该 IP 地址即是在安装 CoreDNS 插件的时候集群分配的一个固定的静态 IP 地址。

来访问下前面创建的 nginx-service 服务：

Terminal window

1
/ # wget -q -O- nginx-service.default.svc.cluster.local

image-20231109144627763

可以看到上面使用 wget 命令去访问 nginx-service 服务的域名的时候连接拒绝了，没有得到期望的结果，这是因为上面建立 Service 的时候暴露的端口是 5000：

image-20231109144655080

加上 5000 端口，就正常访问到服务，再试一试访问：nginx-service.default.svc、nginx-service.default、nginx-service，不出意外这些域名都可以正常访问到期望的结果。

给 Pod 添加 DNS 记录#

StatefulSet 中的 Pod 是拥有单独的 DNS 记录的，比如一个 StatefulSet 名称为 etcd，而它关联的 Headless SVC 名称为 etcd-headless，那么 CoreDNS 就会为它的每个 Pod 解析如下的记录：

Terminal window

1
etcd-0.etcd-headless.default.svc.cluster.local
2
etcd-1.etcd-headless.default.svc.cluster.local
3
......

那么除了 StatefulSet 管理的 Pod 之外，其他的 Pod 是否也可以生成 DNS 记录呢？

首先创建一个 Service ，其定义如下：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-service
5
spec:
6
  selector:
7
    app: nginx
8
  clusterIP: None
9
  ports:
10
    - port: 80

创建service，并尝试解析 service DNS：

image-20231109151130073

Terminal window

1
dig @169.254.25.10 nginx.default.svc.cluster.local

提示没有dig命令的执行下面的命令安装即可:

Terminal window

1
yum install -y bind-utils

image-20231109151413538

然后对 nginx 的 FQDN 域名进行 dig 操作，可以看到返回了多条 A 记录，每一条对应一个 Pod。

接下来试试在 service 名字前面加上 Pod 名字交给 kube-dns 做解析：

Terminal window

1
dig @169.254.25.10 nginx-deploy-67d4bdd6f5-n2ff5.nginx.default.svc.cluster.local

image-20231109152820900

可以看到并没有得到解析结果。官方文档中有一段 Pod’s hostname and subdomain fields 说明：

Pod 规范中包含一个可选的 hostname 字段，可以用来指定 Pod 的主机名。当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名。举个例子，给定一个 hostname 设置为 “my-host” 的 Pod，该 Pod 的主机名将被设置为 “my-host”。Pod 规约还有一个可选的 subdomain 字段，可以用来指定 Pod 的子域名。举个例子，某 Pod 的 hostname 设置为 “foo”，subdomain 设置为 “bar”，在名字空间 “my-namespace” 中对应的完全限定域名为 “foo.bar.my-namespace.svc.cluster-domain.example”。

现在编辑一下 nginx.yaml 加上 subdomain 测试下看看：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deploy
5
spec:
6
  replicas: 2
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      subdomain: nginx
16
      containers:
17
        - name: nginx
18
          image: nginx
19
          resources:
20
            limits:
21
              memory: "128Mi"
22
              cpu: "500m"
23
          ports:
24
            - containerPort: 80

展开收起

image-20231109153318014

可以看到依然不能解析，那就试试官方文档中的例子，不用 Deployment 直接创建 Pod 吧。第一步先将 hostname 和 subdomain 注释掉：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: default-subdomain
5
spec:
6
  selector:
7
    name: busybox
8
  clusterIP: None
9
  ports:
10
    - name: foo # Actually, no port is needed.
11
      port: 1234
12
      targetPort: 1234
13
---
14
apiVersion: v1
15
kind: Pod
16
metadata:
17
  name: busybox1
18
  labels:
19
    name: busybox
20
spec:
21
  hostname: busybox-1
22
  subdomain: default-subdomain
23
  containers:
24
    - image: busybox:1.28
25
      command:
26
        - sleep
27
        - "3600"
28
      name: busybox
29
      resources:
30
        limits:
31
          memory: "128Mi"
32
          cpu: "500m"
33
---
34
apiVersion: v1
35
kind: Pod
36
metadata:
37
  name: busybox2
38
  labels:
39
    name: busybox
40
spec:
41
  hostname: busybox-2
42
  subdomain: default-subdomain
43
  containers:
44
    - image: busybox:1.28
45
      command:
46
        - sleep
47
        - "3600"
48
      name: busybox
49
      resources:
50
        limits:
51
          memory: "128Mi"
52
          cpu: "500m"

展开收起

部署然后尝试解析 Pod DNS (注意这里 hostname 和 pod的name有区别，中间多了减号)：

Terminal window

1
dig @169.254.25.10 busybox-1.default-subdomain.default.svc.cluster.local

image-20231109154104935

现在看到有 ANSWER 记录回来了，hostname 和 subdomain 二者都必须显式指定，缺一不可。一开始的截图中的实现方式其实也是这种方式。

现在我们一下之前的 nginx deployment 加上 hostname，重新解析：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deploy
5
spec:
6
  replicas: 2
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      hostname: nginx
16
      subdomain: nginx
17
      containers:
18
        - name: nginx
19
          image: nginx
20
          resources:
21
            limits:
22
              memory: "128Mi"
23
              cpu: "500m"
24
          ports:
25
            - containerPort: 80
26

27
---
28
apiVersion: v1
29
kind: Service
30
metadata:
31
  name: nginx
32
spec:
33
  selector:
34
    app: nginx
35
  type: ClusterIP
36
  clusterIP: None
37
  ports:
38
    - port: 80

展开收起

Terminal window

1
dig @169.254.25.10 nginx.nginx.default.svc.cluster.local

image-20231109161815082

可以看到解析成功了，但是因为 Deployment 中无法给每个 Pod 指定不同的 hostname，所以两个 Pod 有同样的 hostname，解析出来两个 IP，跟本意就不符合了。不过知道了这种方式过后就可以自己去写一个 Operator 去直接管理 Pod 了，给每个 Pod 设置不同的 hostname 和一个 Headless SVC 名称的 subdomain，这样就相当于实现了 StatefulSet 中的 Pod 解析。

Pod的DNS策略#

DNS 策略可以单独对 Pod 进行设定，目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。这些策略可以在 Pod 规范中的 dnsPolicy 字段设置：

Default: 有人说 Default 的方式，是使用宿主机的方式，这种说法并不准确。这种方式其实是让 kubelet 来决定使用何种 DNS 策略。而 kubelet 默认的方式，就是使用宿主机的 /etc/resolv.conf（可能这就是有人说使用宿主机的 DNS 策略的方式吧），但是，kubelet 是可以灵活来配置使用什么文件来进行 DNS 策略的，完全可以使用 kubelet 的参数 –resolv-conf=/etc/resolv.conf 来决定 DNS 解析文件地址。
ClusterFirst: 这种方式，表示 Pod 内的 DNS 使用集群中配置的 DNS 服务，简单来说，就是使用 Kubernetes 中 kubedns 或 coredns 服务进行域名解析。如果解析不成功，才会使用宿主机的 DNS 配置进行解析。
ClusterFirstWithHostNet：在某些场景下，Pod 是用 HostNetwork 模式启动的，一旦用 HostNetwork 模式，表示这个 Pod 中的所有容器，都要使用宿主机的 /etc/resolv.conf 配置进行 DNS 查询，但如果还想继续使用 Kubernetes 的 DNS 服务，那就将 dnsPolicy 设置为 ClusterFirstWithHostNet。
None: 表示空的 DNS 设置，这种方式一般用于想要自定义 DNS 配置的场景，往往需要和 dnsConfig 配合一起使用达到自定义 DNS 的目的。

需要注意的是 Default 并不是默认的 DNS 策略，如果未明确指定 dnsPolicy，则使用 ClusterFirst。

下面的示例显示了一个 Pod，其 DNS 策略设置为 ClusterFirstWithHostNet，因为它已将 hostNetwork 设置为 true。

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: busybox
5
  namespace: default
6
spec:
7
  containers:
8
    - image: busybox
9
      command:
10
        - sleep
11
        - "3600"
12
      imagePullPolicy: IfNotPresent
13
      name: busybox
14
      resources:
15
        limits:
16
          memory: "128Mi"
17
          cpu: "500m"
18
  restartPolicy: Always
19
  hostNetwork: true
20
  dnsPolicy: ClusterFirstWithHostNet

展开收起

Pod 的 DNS 配置#

Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。dnsConfig 字段是可选的，它可以与任何 dnsPolicy 设置一起使用。但是，当 Pod 的 dnsPolicy 设置为 “None” 时，必须指定 dnsConfig 字段。

用户可以在 dnsConfig 字段中指定以下属性：

nameservers：将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定 3 个 IP 地址。当 Pod 的 dnsPolicy 设置为 “None” 时，列表必须至少包含一个 IP 地址，否则此属性是可选的。所列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。
searches：用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定此属性时，所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。重复的域名将被删除，Kubernetes 最多允许 6 个搜索域。
options：可选的对象列表，其中每个对象可能具有 name 属性（必需）和 value 属性（可选）。此属性中的内容将合并到从指定的 DNS 策略生成的选项。重复的条目将被删除。

以下是具有自定义 DNS 设置的 Pod 示例：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  namespace: default
5
  name: dns-example
6
spec:
7
  containers:
8
    - name: test
9
      image: nginx
10
      resources:
11
        limits:
12
          memory: "64Mi"
13
          cpu: "250m"
14
  dnsPolicy: "None"
15

16
  dnsConfig:
17
    nameservers:
18
      - 1.2.3.4
19
    searches:
20
      - ns1.svc.cluster-domain.example
21
      - my.dns.search.suffix
22
    options:
23
      - name: ndots
24
        value: "2"
25
      - name: edns0

展开收起

创建上面的 Pod 后，容器 test 会在其 /etc/resolv.conf 文件中获取以下内容：

Terminal window

1
nameserver 1.2.3.4
2
search ns1.svc.cluster-domain.example my.dns.search.suffix
3
options ndots:2 edns0

Kubernetes-RBAC

Tue, 07 Nov 2023 00:00:00 GMT

对于资源对象的操作都是通过 APIServer 进行的，那么集群是怎样知道请求就是合法的请求呢？这个就需要了解 Kubernetes 中另外一个非常重要的知识点了：RBAC（基于角色的权限控制）。

管理员可以通过 Kubernetes API 动态配置策略来启用RBAC，需要在 kube-apiserver 中添加参数--authorization-mode=RBAC，如果使用的 kubeadm 安装的集群那么是默认开启了 RBAC 的，可以通过查看 Master 节点上 apiserver 的静态 Pod 定义文件：

Terminal window

1
cat /etc/kubernetes/manifests/kube-apiserver.yaml|grep authorization-mode

image-20231106172346729

如果是二进制的方式搭建的集群，添加这个参数过后，记得要重启 kube-apiserver 服务。

API对象#

在学习 RBAC 之前，还需要再去理解下 Kubernetes 集群中的对象，在 Kubernetes 集群中，Kubernetes 对象是持久化的实体，就是最终存入 etcd 中的数据，集群中通过这些实体来表示整个集群的状态。前面都直接编写的 YAML 文件，通过 kubectl 来提交的资源清单文件，然后创建的对应的资源对象，那么它究竟是如何将 YAML 文件转换成集群中的一个 API 对象的呢？

这个就需要去了解下声明式 API的设计，Kubernetes API 是一个以 JSON 为主要序列化方式的 HTTP 服务，除此之外也支持 Protocol Buffers 序列化方式，主要用于集群内部组件间的通信。为了可扩展性，Kubernetes 在不同的 API 路径（比如/api/v1 或者 /apis/batch）下面支持了多个 API 版本，不同的 API 版本意味着不同级别的稳定性和支持：

Alpha 级别，例如 v1alpha1 默认情况下是被禁用的，可以随时删除对功能的支持，所以要慎用
Beta 级别，例如 v2beta1 默认情况下是启用的，表示代码已经经过了很好的测试，但是对象的语义可能会在随后的版本中以不兼容的方式更改
稳定级别，比如 v1 表示已经是稳定版本了，也会出现在后续的很多版本中。

在 Kubernetes 集群中，一个 API 对象在 Etcd 里的完整资源路径，是由：Group（API 组）、Version（API 版本）和 Resource（API 资源类型）三个部分组成的。通过这样的结构，整个 Kubernetes 里的所有 API 对象，实际上就可以用如下的树形结构表示出来：

apiserver tree

从上图中也可以看出 Kubernetes 的 API 对象的组织方式，在顶层，可以看到有一个核心组（由于历史原因，是 /api/v1 下的所有内容而不是在 /apis/core/v1 下面）和命名组（路径 /apis/$NAME/$VERSION）和系统范围内的实体，比如 /metrics。也可以用下面的命令来查看集群中的 API 组织形式：

Terminal window

1
kubectl get --raw /

1
{
2
  "paths": [
3
    "/.well-known/openid-configuration",
4
    "/api",
5
    "/api/v1",
6
    "/apis",
7
    ......
8
    "/version"
9
  ]
10
}

比如查看批处理这个操作，在当前这个版本中存在 1 个版本的操作：/apis/batch/v1，暴露了可以查询和操作的不同实体集合，同样还是可以通过 kubectl 来查询对应对象下面的数据：

Terminal window

1
kubectl get --raw /apis/batch/v1 | python -m json.tool

1
{
2
  "apiVersion": "v1",
3
  "groupVersion": "batch/v1",
4
  "kind": "APIResourceList",
5
  "resources": [
6
    {
7
      "categories": ["all"],
8
      "kind": "CronJob",
9
      "name": "cronjobs",
10
      "namespaced": true,
11
      "shortNames": ["cj"],
12
      "singularName": "",
13
      "storageVersionHash": "sd5LIXh4Fjs=",
14
      "verbs": [
15
        "create",
16
        "delete",
17
        "deletecollection",
18
        "get",
19
        "list",
20
        "patch",
21
        "update",
22
        "watch"
23
      ]
24
    },
25
    {
26
      "kind": "CronJob",
27
      "name": "cronjobs/status",
28
      "namespaced": true,
29
      "singularName": "",
30
      "verbs": ["get", "patch", "update"]
31
    },
32
    {
33
      "categories": ["all"],
34
      "kind": "Job",
35
      "name": "jobs",
36
      "namespaced": true,
37
      "singularName": "",
38
      "storageVersionHash": "mudhfqk/qZY=",
39
      "verbs": [
40
        "create",
41
        "delete",
42
        "deletecollection",
43
        "get",
44
        "list",
45
        "patch",
46
        "update",
47
        "watch"
48
      ]
49
    },
50
    {
51
      "kind": "Job",
52
      "name": "jobs/status",
53
      "namespaced": true,
54
      "singularName": "",
55
      "verbs": ["get", "patch", "update"]
56
    }
57
  ]
58
}

展开收起

但是这个操作和平时操作 HTTP 服务的方式不太一样，这里可以通过 kubectl proxy 命令来开启对 apiserver 的访问：

Terminal window

1
kubectl proxy

image-20231106174039875

然后重新开启一个新的终端，可以通过如下方式来访问批处理的 API 服务：

Terminal window

1
curl http://127.0.0.1:8001/apis/batch/v1

1
{
2
  "apiVersion": "v1",
3
  "groupVersion": "batch/v1",
4
  "kind": "APIResourceList",
5
  "resources": [
6
    {
7
      "categories": ["all"],
8
      "kind": "CronJob",
9
      "name": "cronjobs",
10
      "namespaced": true,
11
      "shortNames": ["cj"],
12
      "singularName": "",
13
      "storageVersionHash": "sd5LIXh4Fjs=",
14
      "verbs": [
15
        "create",
16
        "delete",
17
        "deletecollection",
18
        "get",
19
        "list",
20
        "patch",
21
        "update",
22
        "watch"
23
      ]
24
    },
25
    {
26
      "kind": "CronJob",
27
      "name": "cronjobs/status",
28
      "namespaced": true,
29
      "singularName": "",
30
      "verbs": ["get", "patch", "update"]
31
    },
32
    {
33
      "categories": ["all"],
34
      "kind": "Job",
35
      "name": "jobs",
36
      "namespaced": true,
37
      "singularName": "",
38
      "storageVersionHash": "mudhfqk/qZY=",
39
      "verbs": [
40
        "create",
41
        "delete",
42
        "deletecollection",
43
        "get",
44
        "list",
45
        "patch",
46
        "update",
47
        "watch"
48
      ]
49
    },
50
    {
51
      "kind": "Job",
52
      "name": "jobs/status",
53
      "namespaced": true,
54
      "singularName": "",
55
      "verbs": ["get", "patch", "update"]
56
    }
57
  ]
58
}

展开收起

通常，Kubernetes API 支持通过标准 HTTP POST、PUT、DELETE 和 GET 在指定 PATH 路径上创建、更新、删除和检索操作，并使用 JSON 作为默认的数据交互格式。

比如现在要创建一个 Deployment 对象，那么 YAML 文件的声明就需要怎么写：

1
apiVersion: apps/v1
2
kind: Deployment

其中 Deployment 就是这个 API 对象的资源类型（Resource），apps 就是它的组（Group），v1 就是它的版本（Version）。API Group、Version 和资源就唯一定义了一个 HTTP 路径，然后在 kube-apiserver 端对这个 url 进行了监听，然后把对应的请求传递给了对应的控制器进行处理而已，当然在 Kuberentes 中的实现过程是非常复杂的。

RBAC#

上面介绍了 Kubernetes 所有资源对象都是模型化的 API 对象，允许执行 CRUD(Create、Read、Update、Delete) 操作(也就是常说的增、删、改、查操作)，比如下面的这些资源：

Pods
ConfigMaps
Deployments
Nodes
Secrets
Namespaces
…

对于上面这些资源对象的可能存在的操作有：

create
get
delete
list
update
edit
watch
exec
patch

在更上层，这些资源和 API Group 进行关联，比如 Pods 属于 Core API Group，而 Deployements 属于 apps API Group，现在我们要在 Kubernetes 中通过 RBAC 来对资源进行权限管理，除了上面的这些资源和操作以外，还需要了解另外几个概念：

Rule：规则，规则是一组属于不同 API Group 资源上的一组操作的集合
Role 和 ClusterRole：角色和集群角色，这两个对象都包含上面的 Rules 元素，二者的区别在于，在 Role 中，定义的规则只适用于单个命名空间，也就是和 namespace 关联的，而 ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。另外 Role 和 ClusterRole 在 Kubernetes 中都被定义为集群内部的 API 资源，和前面的 Pod、Deployment 这些对象类似，都是集群的资源对象，所以同样的可以使用 YAML 文件来描述，用 kubectl 工具来管理
Subject：主题，对应集群中尝试操作的对象，集群中定义了 3 种类型的主题资源：
- User Account：用户，这是有外部独立服务进行管理的，管理员进行私钥的分配，用户可以使用 KeyStone 或者 Goolge 帐号，甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象，所以用户不能通过集群内部的 API 来进行管理
- Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如 cluster-admin
- Service Account：服务帐号，通过 Kubernetes API 来管理的一些用户帐号，和 namespace 进行关联的，适用于集群内部运行的应用程序，需要通过 API 来完成权限认证，所以在集群内部进行权限操作，都需要使用到 ServiceAccount
RoleBinding 和 ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和 Role 进行绑定的过程（给某个用户绑定上操作的权限），二者的区别也是作用范围的区别：RoleBinding 只会影响到当前 namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的 namespace。

只能访问某个 namespace 的普通用户#

创建一个 User Account，只能访问 kube-system 这个命名空间，对应的用户信息如下所示：

1
username: tianch
2
group: tch

创建用户凭证#

Kubernetes 没有 User Account 的 API 对象，不过要创建一个用户帐号的话也是挺简单的，利用管理员分配给你的一个私钥就可以创建了，这个可以参考官方文档中的方法，这里来使用 OpenSSL 证书来创建一个 User，当然也可以使用更简单的 cfssl工具来创建：

给用户 tianch 创建一个私钥，命名成 tianch.key：

Terminal window

1
openssl genrsa -out tianch.key 2048

image-20231106180944671

使用刚刚创建的私钥创建一个证书签名请求文件：tianch.csr，要注意需要确保在 -subj 参数中指定用户名和组(CN表示用户名，O表示组)：

Terminal window

1
openssl req -new -key tianch.key -out tianch.csr -subj "/CN=tianch/O=tch"

然后找到 Kubernetes 集群的 CA 证书，CA 相关证书位于 /etc/kubernetes/pki/ 目录下面，利用该目录下面的 ca.crt 和 ca.key两个文件来批准上面的证书请求。生成最终的证书文件，这里设置证书的有效期为 500 天：

Terminal window

1
openssl x509 -req -in tianch.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out tianch.crt -days 500

image-20231106180958587

image-20231106181054755

使用刚刚创建的证书文件和私钥文件在集群中创建新的凭证和上下文(Context):

Terminal window

1
kubectl config set-credentials tianch --client-certificate=tianch.crt --client-key=tianch.key

用户 tianch 创建了，然后为这个用户设置新的 Context，这里指定特定的一个 namespace：

--cluster需要获取自己的集群名称:

Terminal window

1
kubectl config get-clusters

image-20231107102254048

Terminal window

1
kubectl config set-context tianch-context --cluster=cluster.local --namespace=kube-system --user=tianch

到这里用户 tianch 就已经创建成功了，现在使用当前的这个配置文件来操作 kubectl 命令的时候，应该会出现错误，因为还没有为该用户定义任何操作的权限呢：

Terminal window

1
kubectl get pods --context=tianch-context

image-20231106181301623

创建角色#

用户创建完成后，接下来就需要给该用户添加操作权限，定义一个 YAML 文件，创建一个允许用户操作 Deployment、Pod、ReplicaSets 的角色，如下定义：tianch-role.yaml

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
  name: tianch-role
5
  namespace: kube-system
6
rules:
7
  - apiGroups: ["", "apps"]
8
    resources: ["deployments", "replicasets", "pods"]
9
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使用['*']

其中 Pod 属于 core 这个 API Group，在 YAML 中用空字符就可以，而 Deployment 和 ReplicaSet 现在都属于 apps 这个 API Group（如果不知道则可以用 kubectl explain 命令查看），所以 rules 下面的 apiGroups 就综合了这几个资源的 API Group：["", “apps”]，其中 verbs 就是上面提到的可以对这些资源对象执行的操作，这里需要所有的操作方法，所以也可以使用['*']来代替，然后直接创建这个 Role：

Terminal window

1
kubectl create -f tianch-role.yaml

注意这里没有使用上面的 tianch-context 这个上下文，因为暂时还没有权限。

创建`角色和权限绑定`#

Role 创建完成了，但是这个 Role 和用户 tianch 还没有任何关系，这里就需要创建一个 RoleBinding 对象，在 kube-system 这个命名空间下面将上面的 tianch-role 角色和用户 tianch 进行绑定：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: RoleBinding
3
metadata:
4
  name: tianch-rolebinding
5
  namespace: kube-system
6
subjects:
7
  - kind: User
8
    name: tianch
9
    apiGroup: ""
10
roleRef:
11
  kind: Role
12
  name: tianch-role
13
  apiGroup: rbac.authorization.k8s.io # 留空字符串也可以，则使用当前的apiGroup

上面的 YAML 文件中看到了 subjects 字段，这里就是上面提到的用来尝试操作集群的对象，这里对应上面的 User 帐号 tianch，使用 kubectl 创建上面的资源对象：

Terminal window

1
kubectl create -f tianch-rolebinding.yaml

测试#

现在应该可以用上面的 tianch-context 上下文来操作集群了：

Terminal window

1
kubectl get pods --context=tianch-context

image-20231107102711882

可以看到使用 kubectl 的使用并没有指定 namespace，这是因为上面创建这个 Context 的时候就绑定在了 kube-system 这个命名空间下面，如果在后面加上一个-n default

Terminal window

1
kubectl --context=tianch.context get pods --namespace=default

image-20231107102931165

获取其他的资源对象:

Terminal window

1
kubectl --context=tianch-context get svc

image-20231107103126664

可以看到没有权限获取，因为并没有为当前操作用户指定其它对象资源的访问权限，是符合预期的。这样就创建了一个只有单个命名空间访问权限的普通 User。

只能访问某个 namespace 的 ServiceAccount#

上面创建了一个只能访问某个命名空间下面的普通用户，前面也提到过 subjects 下面还有一种类型的主题资源：ServiceAccount，现在来创建一个集群内部的用户只能操作 kube-system 这个命名空间下面的 pods 和 deployments，首先来创建一个 ServiceAccount 对象：

Terminal window

1
kubectl create sa tianch-sa -n kube-system

也可以定义成 YAML 文件的形式来创建：

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: tianch-sa
5
  namespace: kube-system

然后新建一个 Role 对象和对象绑定：tianch-sa.yaml

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
  name: tianch-sa-role
5
  namespace: kube-system
6
rules:
7
  - apiGroups: [""]
8
    resources: ["pods"]
9
    verbs: ["get", "watch", "list"]
10
  - apiGroups: ["apps"]
11
    resources: ["deployments"]
12
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
13

14
---
15
kind: RoleBinding
16
apiVersion: rbac.authorization.k8s.io/v1
17
metadata:
18
  name: tianch-sa-rolebinding
19
  namespace: kube-system
20
subjects:
21
  - kind: ServiceAccount
22
    name: tianch-sa
23
    namespace: kube-system
24
roleRef:
25
  kind: Role
26
  name: tianch-sa-role
27
  apiGroup: rbac.authorization.k8s.io

展开收起

可以看到这里定义的角色没有创建、删除、更新 Pod 的权限，创建该 Role 对象和RoleBinding对象：

Terminal window

1
kubectl apply -f tianch-sa.yaml

image-20231107110333855

Terminal window

1
kubectl get secret tianch-sa-token-qm9wg -o jsonpath={.data.token} -n kube-system |base64 -d

ServiceAccount 会生成一个 Secret 对象和它进行映射，这个 Secret 里面包含一个 token，我们可以利用这个 token 去登录 Dashboard，然后我们就可以在 Dashboard 中来验证我们的功能是否符合预期。

安装Dashboard#

Terminal window

1
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

设置Service外网访问#

Terminal window

1
kubectl edit service kubernetes-dashboard -n kubernetes-dashboard

把spec.type改为NodePort esc+wq退出

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  annotations:
5
    kubectl.kubernetes.io/last-applied-configuration: |
6
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"k8s-app":"kubernetes-dashboard"},"name":"kubernetes-dashboard","namespace":"kubernetes-dashboard"},"spec":{"ports":[{"port":443,"targetPort":8443}],"selector":{"k8s-app":"kubernetes-dashboard"}}}
7
  creationTimestamp: "2023-11-07T03:08:57Z"
8
  labels:
9
    k8s-app: kubernetes-dashboard
10
  name: kubernetes-dashboard
11
  namespace: kubernetes-dashboard
12
  resourceVersion: "345760"
13
  uid: 760038b9-2d32-4897-8f41-2fb5188dd52f
14
spec:
15
  clusterIP: 10.233.61.54
16
  clusterIPs:
17
    - 10.233.61.54
18
  externalTrafficPolicy: Cluster
19
  internalTrafficPolicy: Cluster
20
  ipFamilies:
21
    - IPv4
22
  ipFamilyPolicy: SingleStack
23
  ports:
24
    - nodePort: 31186
25
      port: 443
26
      protocol: TCP
27
      targetPort: 8443
28
  selector:
29
    k8s-app: kubernetes-dashboard
30
  sessionAffinity: None
31
  type: NodePort
32
status:
33
  loadBalancer: {}

展开收起

image-20231107111614495

在default命名空间下提示没有权限,切换到kube-system命名空间后就可以了

image-20231107111851720

可以看到可以访问 pod 列表了，但是也会有一些其他额外的提示：events is forbidden: User “system:serviceaccount:kube-system:tianch-sa” cannot list events in the namespace “kube-system”，这是因为当前登录用只被授权了访问 pod 和 deployment 的权限。

可以根据自己的需求来对访问用户的权限进行限制，可以通过 Role 定义更加细粒度的权限，也可以使用系统内置的一些权限。

可以全局访问的 ServiceAccount#

上面创建的 tianch-sa 这个 ServiceAccount 和一个 Role 角色进行绑定的，如果创建一个新的 ServiceAccount，需要它操作的权限作用于所有的 namespace，这个时候就需要使用到 ClusterRole 和 ClusterRoleBinding 这两种资源对象了。首先新建一个 ServiceAcount 对象：(tianch-sa2.yaml)

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: tianch-sa2
5
  namespace: kube-system

后创建一个 ClusterRoleBinding 对象tianch-clusterolebinding.yaml

1
kind: ClusterRoleBinding
2
apiVersion: rbac.authorization.k8s.io/v1
3
metadata:
4
  name: tianch-sa2-clusterrolebinding
5
subjects:
6
  - kind: ServiceAccount
7
    name: tianch-sa2
8
    namespace: kube-system
9
roleRef:
10
  kind: ClusterRole
11
  name: cluster-admin
12
  apiGroup: rbac.authorization.k8s.io

上面没有为这个资源对象声明 namespace，因为这是一个 ClusterRoleBinding 资源对象，是作用于整个集群的，也没有单独新建一个 ClusterRole 对象，而是使用的 cluster-admin 这个对象，这是 Kubernetes 集群内置的 ClusterRole 对象，可以使用 kubectl get clusterrole 和 kubectl get clusterrolebinding 查看系统内置的一些集群角色和集群角色绑定，这里使用的 cluster-admin 这个集群角色是拥有最高权限的集群角色，所以一般需要谨慎使用该集群角色。

创建上面集群角色绑定资源对象，创建完成后同样使用 ServiceAccount 对应的 token 去登录 Dashboard 验证下：

Terminal window

1
kubectl apply -f tianch-clusterolebinding.yaml

image-20231107141012264

获取登录token

Terminal window

1
kubectl get secret tianch-sa2-token-xr4ht -o jsonpath={.data.token} -n kube-system |base64 -d

image-20231107141201837

一开始没有权限的default命名空间也可以访问了。

Kubernetes-Service

Tue, 07 Nov 2023 00:00:00 GMT

每个 Pod 都有自己的 IP 地址，但是如果 Pod 重建了的话 IP 很有可能也就变化了。这就会带来一个问题：比如有一些后端的 Pod 集合为集群中的其他应用提供 API 服务，在前端应用中把所有的这些后端的 Pod 的地址都写死，然后以某种方式去访问其中一个 Pod 的服务，这样看上去是可以工作的，但是如果这个 Pod 挂掉了，然后重新启动起来了，IP 地址就变了，这个时候前端就访问不到后端的服务了。

在没有使用 Kubernetes 之前，不一定是 IP 变化的问题，比如在部署一个 WEB 服务的时候，前端一般部署一个 Nginx 作为服务的入口，然后 Nginx 后面肯定就是挂载的这个服务的大量后端服务，很早以前是去手动更改 Nginx 配置中的 upstream 选项，来动态改变提供服务的数量，到后面出现了一些服务发现的工具，比如 Consul、ZooKeeper 等工具，有了这些工具过后就可以只需要把服务注册到这些服务发现中心去就可以，然后让这些工具动态的去更新 Nginx 的配置就可以了，完全不用去手工的操作了。

要解决上面遇到的问题实现一个服务发现的工具也可以解决，当我们 Pod 被销毁或者新建过后，可以把这个 Pod 的地址注册到这个服务发现中心去就可以了，但是这样的话前端应用就不能直接去连接后台的 Pod 集合了，应该连接到一个能够做服务发现的中间件上面。

为解决这个问题 Kubernetes 就提供了这样的一个对象 - Service，Service 是一种抽象的对象，它定义了一组 Pod 的逻辑集合和一个用于访问它们的策略，其实这个概念和微服务非常类似。一个 Serivce 下面包含的 Pod 集合是由 Label Selector 来决定的。

假如我们后端运行了 3 个副本，这些副本都是可以替代的，因为前端并不关心它们使用的是哪一个后端服务。尽管由于各种原因后端的 Pod 集合会发生变化，但是前端并不需要知道这些变化，也不需要自己用一个列表来记录这些后端的服务，Service 的这种抽象就可以达到这种解耦的目的。

三种IP#

在学习 Service 之前，需要先弄明白 Kubernetes 系统中的三种 IP:

Node IP：Node 节点的 IP 地址
Pod IP: Pod 的 IP 地址
Cluster IP: Service 的 IP 地址

Node IP 是 Kubernetes 集群中节点的物理网卡 IP 地址(一般为内网)，所有属于这个网络的服务器之间都可以直接通信，所以 Kubernetes 集群外要想访问 Kubernetes 集群内部的某个节点或者服务，肯定得通过 Node IP 进行通信（这个时候一般是通过外网 IP 访问）

Pod IP 是每个 Pod 的 IP 地址，它是网络插件进行分配的

Cluster IP 是一个虚拟的 IP，仅仅作用于 Kubernetes Service 这个对象，由 Kubernetes 自己来进行管理和分配地址

定义Service#

定义 Service 的方式和前面定义的各种资源对象的方式类似：有一组 Pod 服务，它们对外暴露了 8080 端口，同时都被打上了 app=myapp 这样的标签，就可以像下面这样来定义一个 Service 对象：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: myapp
5
spec:
6
  selector:
7
    app: myapp
8
  ports:
9
    - port: 80
10
      targetPort: 8080
11
      name: myapp-http
12
      protocol: TCP

通过使用 kubectl create -f myservice.yaml 就可以创建一个名为 myservice 的 Service 对象，它会将请求代理到使用 TCP 端口为 8080，具有标签 app=myapp 的 Pod 上，这个 Service 会被系统分配一个 Cluster IP，该 Service 还会持续的监听 selector 下面的 Pod，会把这些 Pod 信息更新到一个名为 myservice 的 Endpoints 对象上去，这个对象就类似于上面说的 Pod 集合了。

需要注意的是，Service 能够将一个接收端口映射到任意的 targetPort。默认情况下，targetPort 将被设置为与 port 字段相同的值。更有趣的是，targetPort 可以是一个字符串，引用了 backend Pod 的一个端口的名称。因实际指派给该端口名称的端口号，在每个 backend Pod 中可能并不相同，所以对于部署和设计 Service，这种方式会提供更大的灵活性。

另外 Service 能够支持 TCP 和 UDP 协议，默认是 TCP 协议。

kube-proxy#

在 Kubernetes 集群中，每个 Node 会运行一个 kube-proxy 进程, 负责为 Service 实现一种 VIP（虚拟 IP，就是上面说的 clusterIP）的代理形式，现在的 Kubernetes 中默认是使用的 iptables 这种模式来代理。

iptables#

这种模式，kube-proxy 会 watch apiserver 对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service，它会添加上 iptables 规则，从而捕获到达该 Service 的 clusterIP（虚拟 IP）和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某一个 Pod 上面。还可以使用 Pod readiness 探针 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端，这样做意味着可以避免将流量通过 kube-proxy 发送到已知失败的 Pod 中，所以对于线上的应用来说一定要做 readiness 探针。

service iptables

iptables 模式的 kube-proxy 默认的策略，随机选择一个后端 Pod。

比如当创建 backend Service 时，Kubernetes 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。假设 Service 的端口是 1234，该 Service 会被集群中所有的 kube-proxy 实例观察到。当 kube-proxy 看到一个新的 Service，它会安装一系列的 iptables 规则，从 VIP 重定向到 per-Service 规则。该 per-Service 规则连接到 per-Endpoint 规则，该 per-Endpoint 规则会重定向（目标 NAT）到后端的 Pod。

ipvs#

除了 iptables 模式之外，kubernetes 也支持 ipvs 模式，在 ipvs 模式下，kube-proxy watch Kubernetes 服务和端点，调用 netlink 接口相应地创建 IPVS 规则，并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保 IPVS 状态与所需状态匹配。访问服务时，IPVS 　将流量定向到后端 Pod 之一。

IPVS 代理模式基于类似于 iptables 模式的 netfilter 钩子函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。所以与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。所以对于较大规模的集群会使用 ipvs 模式的 kube-proxy，只需要满足节点上运行 ipvs 的条件，就可以直接将 kube-proxy 的模式修改为 ipvs，如果不满足运行条件会自动降级为 iptables 模式，现在都推荐使用 ipvs 模式，可以大幅度提高 Service 性能。

IPVS 提供了更多选项来平衡后端 Pod 的流量，默认是 rr，有如下一些策略：

rr: round-robin
lc: least connection (smallest number of open connections)
dh: destination hashing
sh: source hashing
sed: shortest expected delay
nq: never queue

不过现在只能整体修改策略，可以通过 kube-proxy 中配置 –ipvs-scheduler 参数来实现，暂时不支持特定的 Service 进行配置。

service ipvs

也可以实现基于客户端 IP 的会话亲和性，可以将 service.spec.sessionAffinity 的值设置为 “ClientIP” （默认值为 “None”）即可，此外还可以通过适当设置 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 来设置最大会话停留时间（默认值为 10800 秒，即 3 小时）:

1
apiVersion: v1
2
kind: Service
3
spec:
4
  sessionAffinity: ClientIP
5
  ...

**亲和性：**Service 只支持两种形式的会话亲和性服务：None 和 ClientIP，不支持基于 cookie 的会话亲和性，这是因为 Service 不是在 HTTP 层面上工作的，处理的是 TCP 和 UDP 包，并不关心其中的载荷内容，因为 cookie 是 HTTP 协议的一部分，Service 并不知道它们，所有会话亲和性不能基于Cookie。

Service#

在定义 Service 的时候可以指定一个自己需要的类型的 Service，如果不指定的话默认是 ClusterIP类型。

可以使用的服务类型如下：

ClusterIP：通过集群的内部 IP 暴露服务，服务只能够在集群内部可以访问，这也是默认的服务类型。
NodePort：通过每个 Node 节点上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 NodeIp:NodePort，可以从集群的外部访问一个 NodePort 服务。
LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务，这个需要结合具体的云厂商进行操作。
ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。

NodePort 类型#

如果设置 type 的值为 NodePort，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service。该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定，如果不指定的话会自动生成一个端口。

需要注意的是，Service 将能够通过 spec.ports[].nodePort 和 spec.clusterIp:spec.ports[].port 而对外可见。

创建一个 NodePort 的服务来访问前面的 Nginx 服务：service-nodeport-demo.yaml

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: myservice
5
spec:
6
  selector:
7
    app: myapp
8
  type: NodePort
9
  ports:
10
    - protocol: TCP
11
      port: 80
12
      targetPort: 80
13
      name: myapp-http

image-20231107172049567

可以看到 myservice 的 TYPE 类型已经变成了 NodePort，后面的 PORT(S) 部分也多了一个 30864的映射端口。

ExternalName#

ExternalName 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。对于运行在集群外部的服务，它通过返回该外部服务的别名来提供服务。

1
kind: Service
2
apiVersion: v1
3
metadata:
4
  name: my-service
5
  namespace: prod
6
spec:
7
  type: ExternalName
8
  externalName: my.database.example.com

当访问地址 my-service.prod.svc.cluster.local时，集群的 DNS 服务将返回一个值为 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应的 Pod，增加合适的 Selector 或 Endpoint，修改 Service 的 type，完全不需要修改调用的代码，这样就完全解耦了。

除了可以直接通过 externalName 指定外部服务的域名之外，还可以通过自定义 Endpoints 来创建 Service，前提是 clusterIP=None，名称要和 Service 保持一致，如下所示：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: etcd-k8s
5
  namespace: kube-system
6
  labels:
7
    k8s-app: etcd
8
spec:
9
  type: ClusterIP
10
  clusterIP: None
11
  ports:
12
    - name: port
13
      port: 2379
14

15
---
16
apiVersion: v1
17
kind: Endpoints
18
metadata:
19
  name: etcd-k8s # 名称必须和 Service 一致
20
  namespace: kube-system
21
  labels:
22
    k8s-app: etcd
23
subsets:
24
  - addresses:
25
      - ip: 10.168.1.20 # Service 将连接重定向到 endpoint
26
    ports:
27
      - name: port
28
        port: 2379 # endpoint 的目标端口

展开收起

上面这个服务就是将外部的 etcd 服务引入到 Kubernetes 集群中来。

externalIPs#

Service 的属性中还有一个 externalIPs 的属性，从 Kubernetes 官网文档可以看到该属性的相关描述：

如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes Service 会被暴露给这些 externalIPs。通过外部 IP（作为目的 IP 地址）进入到集群，传到 Service 的端口上的流量，将会被路由到 Service 的 Endpoint 上，externalIPs 不会被 Kubernetes 管理，它属于集群管理员的职责范畴。

这里最重要的一点就是确保使用哪个 IP 来访问 Kubernetes 集群，使用外部 IP Service 类型，我们可以将 Service 绑定到连接集群的 IP。

参考文档：https://www.fadhil-blog.dev/blog/kubernetes-external-ip/

获取客户端 IP#

通常，当集群内的客户端连接到服务的时候，是支持服务的 Pod 可以获取到客户端的 IP 地址的，但是，当通过节点端口接收到连接时，由于对数据包执行了源网络地址转换（SNAT），因此数据包的源 IP 地址会发生变化，后端的 Pod 无法看到实际的客户端 IP，对于某些应用来说是个问题，比如，nginx 的请求日志就无法获取准确的客户端访问 IP 了，比如下面我们的应用：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx
5
spec:
6
  replicas: 3
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx:1.7.9
18
          ports:
19
            - containerPort: 80
20
          resources:
21
            limits:
22
              cpu: "300m"
23
              memory: "128Mi"
24
---
25
apiVersion: v1
26
kind: Service
27
metadata:
28
  name: nginx
29
spec:
30
  selector:
31
    app: nginx
32
  type: NodePort
33
  ports:
34
    - protocol: TCP
35
      port: 80
36
      targetPort: 80

展开收起

直接创建后可以查看 nginx 服务被自动分配了一个 31320 的 NodePort 端口：

image-20231107174110630

image-20231107174532719

可以看到这个 3 个 Pod 被分配到了 3 个不同的节点，这个时候通过 master 节点的 NodePort 端口来访问下我们的服务，这个时候我们查看 nginx 的 Pod 日志可以看到其中获取到的 clientIP 是 10.233.70.0，其实是 master 节点的某一个内网 IP，并不是我们期望的真正的浏览器端访问的 IP 地址：

image-20231107175132043

这是因为 master 节点上并没有对应的 Pod，所以通过 master 节点去访问应用的时候必然需要额外的网络跳转才能到达其他节点上 Pod，在跳转过程中由于对数据包进行了 SNAT，所以看到的是 master 节点的 IP。这个时候可以在 Service 设置 externalTrafficPolicy 来减少网络跳数：

1
spec:
2
  externalTrafficPolicy: Local

如果 Service 中配置了 externalTrafficPolicy=Local，并且通过服务的节点端口来打开外部连接，则 Service 会代理到本地运行的 Pod，如果本地没有本地 Pod 存在，则连接将挂起，这里设置上该字段更新，这个时候通过 master 节点的 NodePort 访问应用是访问不到的，因为 master 节点上并没有对应的 Pod 运行，所以需要确保负载均衡器将连接转发给至少具有一个 Pod 的节点。

但是需要注意的是使用这个参数有一个缺点，通常情况下，请求都是均匀分布在所有 Pod 上的，但是使用了这个配置的话，情况就有可能不一样了。比如有两个节点上运行了 3 个 Pod，假如节点 A 运行一个 Pod，节点 B 运行两个 Pod，如果负载均衡器在两个节点间均衡分布连接，则节点 A 上的 Pod 将接收到所有请求的 50%，但节点 B 上的两个 Pod 每个Pod就只接收 25% 。

由于增加了externalTrafficPolicy: Local这个配置后，接收请求的节点和目标 Pod 都在一个节点上，所以没有额外的网络跳转（不执行 SNAT），所以就可以拿到正确的客户端 IP，如下所示把 Pod 都固定到 master 节点上：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx
5
spec:
6
  replicas: 3
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      tolerations:
16
        - operator: "Exists"
17
      nodeSelector:
18
        kubernetes.io/hostname: master
19
      containers:
20
        - name: nginx
21
          image: nginx
22
          ports:
23
            - containerPort: 80
24
          resources:
25
            limits:
26
              cpu: "300m"
27
              memory: "128Mi"
28
---
29
apiVersion: v1
30
kind: Service
31
metadata:
32
  name: nginx
33
spec:
34
  externalTrafficPolicy: Local
35
  selector:
36
    app: nginx
37
  type: NodePort
38
  ports:
39
    - protocol: TCP
40
      port: 80
41
      targetPort: 80

展开收起

image-20231107180621543

更新服务后，然后再通过 NodePort 访问服务可以看到拿到的就是正确的客户端 IP 地址了：

image-20231107180737257

Kubernetes-ConfigMap

Mon, 06 Nov 2023 00:00:00 GMT

对于应用的可变配置在 Kubernetes 中是通过一个 ConfigMap 资源对象来实现的，应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求，这些配置信息肯定不会直接写死到应用程序中去的，比如一个应用连接一个 redis 服务，下一次想更换一个，还得重新去修改代码，重新制作一个镜像，这肯定是不可取的，而 ConfigMap 就提供了向容器中注入配置信息的能力，不仅可以用来保存单个属性，还可以用来保存整个配置文件，比如可以用来配置一个 redis 服务的访问地址，也可以用来保存整个 redis 的配置文件。

创建#

ConfigMap 资源对象使用 key-value 形式的键值对来配置数据，这些数据可以在 Pod 里面使用，如下所示的资源清单：cm-demo.yaml

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: cm-demo
5
  namespace: default
6
data:
7
  data.1: hello
8
  data.2: world
9
  config: |
10
    property.1=value1
11
    property.2=value2
12
    property.3=value3

其中配置数据在 data 属性下面进行配置，前两个被用来保存单个属性，后面一个被用来保存一个配置文件。

可以看到 config 后面有一个竖线符 |，这在 yaml 中表示保留换行，每行的缩进和行尾空白都会被去掉，而额外的缩进会被保留。

1
lines: |
2
  我是第一行
3
  我是第二行
4
    我是吴彦祖
5
      我是第四行
6
  我是第五行
7

8
# JSON
9
{"lines": "我是第一行\n我是第二行\n  我是吴彦祖\n     我是第四行\n我是第五行"}

除了竖线之外还可以使用 > 右尖括号，用来表示折叠换行，只有空白行才会被识别为换行，原来的换行符都会被转换成空格。

1
lines: >
2
  我是第一行
3
  我也是第一行
4
  我仍是第一行
5
  我依旧是第一行
6

7
  我是第二行
8
  这么巧我也是第二行
9

10
# JSON
11
{"lines": "我是第一行 我也是第一行 我仍是第一行 我依旧是第一行\n我是第二行 这么巧我也是第二行"}

除了这两个指令之外，还可以使用竖线和加号或者减号进行配合使用，+ 表示保留文字块末尾的换行，- 表示删除字符串末尾的换行。

1
value: |
2
  hello
3

4
# {"value": "hello\n"}
5

6
value: |-
7
  hello
8

9
# {"value": "hello"}
10

11
value: |+
12
  hello
13

14
# {"value": "hello\n\n"} (有多少个回车就有多少个\n)

同样的可以使用kubectl create -f xx.yaml来创建上面的 ConfigMap 对象，如果不知道怎么创建 ConfigMap ，可以使用kubectl create configmap -h来查看关于创建 ConfigMap 的帮助信息：

Terminal window

1
Examples:
2
  # Create a new configmap named my-config based on folder bar
3
  kubectl create configmap my-config --from-file=path/to/bar
4

5
  # Create a new configmap named my-config with specified keys instead of file basenames on disk
6
  kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt
7

8
  # Create a new configmap named my-config with key1=config1 and key2=config2
9
  kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

可以看到可以从testcm的目录来创建一个 ConfigMap 对象，在testcm目录下面包含一些配置文件，redis 和 mysql 的连接信息，如下：

Terminal window

1
# redis.conf
2
host=127.0.0.1
3
port=6379
4

5
# mysql.conf
6
host=127.0.0.1
7
port=3306

然后就可以使用 from-file 关键字来创建包含这个目录下面所以配置文件的 ConfigMap：

Terminal window

1
kubectl create configmap cm-demo1 --from-file=xxx目录

其中 from-file 参数指定在testcm目录下面的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容。创建完成后，同样可以使用如下命令来查看 ConfigMap 列表：

可以看到已经创建了一个 cm-demo1 的 ConfigMap 对象，然后可以使用 describe 命令查看详细信息：

Terminal window

1
kubectl describe cm cm-demo1 -n default

可以看到两个 key 是 testcm 目录下面的文件名称，对应的 value 值就是文件内容，这里值得注意的是如果文件里面的配置信息很大的话，describe 的时候可能不会显示对应的值，要查看完整的键值，可以使用如下命令：

Terminal window

1
kubectl get cm cm-demo1 -n default -o yaml

image-20231106111529692

除了通过文件目录进行创建，也可以使用指定的文件进行创建 ConfigMap，同样的，以上面的配置文件为例，创建一个 redis 的配置的一个单独 ConfigMap 对象：

Terminal window

1
kubectl create configmap cm-demo2 --from-file=testcm/redis.conf

image-20231106141102350

可以看到一个关联 redis.conf 文件配置信息的 ConfigMap 对象创建成功了，另外值得注意的是 --from-file 这个参数可以使用多次，比如使用两次分别指定 redis.conf 和 mysql.conf 文件，就和直接指定整个目录是一样的效果了。

另外，通过帮助文档可以看到还可以直接使用字符串进行创建，通过 --from-literal 参数传递配置信息，同样的，这个参数可以使用多次，格式如下：

Terminal window

1
kubectl create configmap cm-demo3 -n default --from-literal=db.host=localhost --from-literal=db.port=3306

image-20231106141456031

使用#

ConfigMap 创建成功后，这些配置数据可以通过很多种方式在 Pod 里使用，主要有以下几种方式：

设置环境变量的值
在容器里设置命令行参数
在数据卷里面挂载配置文件

首先使用 ConfigMap 来填充环境变量，如下所示的 Pod 资源对象：testcm1-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: testcm1-pod
5
spec:
6
  containers:
7
  - name: testcm1
8
    image: busybox
9
    command: ["/bin/sh", "-c", "env"]
10
    env:
11
    - name: DB_HOST
12
      valueFrom:
13
        configMapKeyRef:
14
          name: cm-demo3
15
          key: db.host
16
    - name: DB_PORT
17
      valueFrom:
18
        configMapKeyRef:
19
          name: cm-demo3
20
          key: db.port
21
    envFrom:
22
    - configMapRef:
23
        name: cm-demo1
24
    resources:
25
      limits:
26
        memory: "128Mi"
27
        cpu: "500m"

展开收起

这个 Pod 运行后会输出如下所示的信息：

Terminal window

1
kubectl logs testcm1-pod -n default

image-20231106142922739

可以看到 DB_HOST 和 DB_PORT 都已经正常输出了，另外的环境变量是因为这里直接把 cm-demo1 给注入进来了，所以把它们的整个键值给输出出来了，这也是符合预期的。

另外也可以使用 ConfigMap来设置命令行参数，ConfigMap 也可以被用来设置容器中的命令或者参数值，如下 Pod:testcm2-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: testcm2-pod
5
spec:
6
  containers:
7
    - name: testcm2
8
      image: busybox
9
      command:
10
        - "/bin/sh"
11
        - "-c"
12
        - "echo $(DB_HOST) $(DB_PORT)"
13
      env:
14
        - name: DB_HOST
15
          valueFrom:
16
            configMapKeyRef:
17
              name: cm-demo3
18
              key: db.host
19
        - name: DB_PORT
20
          valueFrom:
21
            configMapKeyRef:
22
              name: cm-demo3
23
              key: db.port
24
      resources:
25
        limits:
26
          memory: "128Mi"
27
          cpu: "500m"

展开收起

image-20231106143809538

另外一种是非常常见的使用 ConfigMap 的方式：通过数据卷使用，在数据卷里面使用 ConfigMap，就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容，如下资源对象所示：testcm3-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: testcm3-pod
5
spec:
6
  volumes:
7
    - name: config-volume
8
      configMap:
9
        name: cm-demo2
10
  containers:
11
    - name: testcm3
12
      image: busybox
13
      command:
14
        - "/bin/sh"
15
        - "-c"
16
        - "cat /etc/config/redis.conf"
17
      volumeMounts:
18
        - name: config-volume
19
          mountPath: /etc/config
20
      resources:
21
        limits:
22
          memory: "128Mi"
23
          cpu: "500m"

展开收起

image-20231106144633482

也可以在 ConfigMap 值被映射的数据卷里去控制路径，如下 Pod 定义：testcm4-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: testcm4-pod
5
spec:
6
  volumes:
7
    - name: config-volume
8
      configMap:
9
        name: cm-demo1
10
        items:
11
          - key: mysql.conf
12
            path: path/to/mysql.conf
13
  containers:
14
    - name: testcm4
15
      image: busybox
16
      command:
17
        - "/bin/sh"
18
        - "-c"
19
        - "cat /etc/config/path/to/mysql.conf"
20
      volumeMounts:
21
        - name: config-volume
22
          mountPath: /etc/config
23
      resources:
24
        limits:
25
          memory: "128Mi"
26
          cpu: "500m"

展开收起

image-20231106145708602

另外需要注意的是，当 ConfigMap 以数据卷的形式挂载进 Pod 的时，这时更新 ConfigMap（或删掉重建ConfigMap），Pod 内挂载的配置信息会热更新。这时可以增加一些监测配置文件变更的脚本，然后重加载对应服务就可以实现应用的热更新。

使用注意<只有通过> Kubernetes API 创建的 Pod 才能使用 ConfigMap，其他方式创建的（比如静态 Pod）不能使用；ConfigMap 文件大小限制为 1MB（ETCD 的要求）。

Kubernetes-Secret

Mon, 06 Nov 2023 00:00:00 GMT

一般情况下 ConfigMap 是用来存储一些非安全的配置信息，如果涉及到一些安全相关的数据的话用 ConfigMap 就非常不妥了，因为 ConfigMap 是明文存储的，这个时候我们就需要用到另外一个资源对象了：Secret，Secret用来保存敏感信息，例如密码、OAuth 令牌和 ssh key 等等，将这些信息放在 Secret 中比放在 Pod 的定义中或者 Docker 镜像中要更加安全和灵活。

Secret 主要使用的有以下三种类型：

Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过 base64 –decode 解码得到原始数据，所有加密性很弱。
kubernetes.io/dockercfg: ~/.dockercfg 文件的序列化形式
kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息，~/.docker/config.json 文件的序列化形式
kubernetes.io/service-account-token：用于 ServiceAccount, ServiceAccount 创建时 Kubernetes 会默认创建一个对应的 Secret 对象，Pod 如果使用了 ServiceAccount，对应的 Secret 会自动挂载到 Pod 目录 /run/secrets/kubernetes.io/serviceaccount 中
kubernetes.io/ssh-auth：用于 SSH 身份认证的凭据
kubernetes.io/basic-auth：用于基本身份认证的凭据
bootstrap.kubernetes.io/token：用于节点接入集群的校验的 Secret

上面是 Secret 对象内置支持的几种类型，通过为 Secret 对象的 type 字段设置一个非空的字符串值，也可以定义并使用自己 Secret 类型。如果 type 值为空字符串，则被视为 Opaque 类型。Kubernetes 并不对类型的名称作任何限制，不过，如果要使用内置类型之一，则你必须满足为该类型所定义的所有要求。

Opaque#

Secret 资源包含2个键值对： data 和 stringData，data 字段用来存储 base64 编码的任意数据，提供 stringData 字段是为了方便，它允许 Secret 使用未编码的字符串。 data 和 stringData 的键必须由字母、数字、-，_ 或 . 组成。

比如创建一个用户名为 admin，密码为 admin321 的 Secret 对象，首先需要先把用户名和密码做 base64 编码：

Terminal window

1
echo -n "admin" | base64

Terminal window

1
echo -n "admin321" | base64

然后我们就可以利用上面编码过后的数据来编写一个 YAML 文件：secret-demo.yaml

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: mysecret
5
type: Opaque
6
data:
7
  username: YWRtaW4=
8
  password: YWRtaW4zMjE=

Terminal window

1
kubectl apply -f 6.secret-demo.yaml

Terminal window

1
kubectl describe secret mysecret -n default

Terminal window

1
kubectl get secret mysecret -n default

image-20231106153029910

对于某些场景，可能希望使用 stringData 字段，这字段可以将一个非 base64 编码的字符串直接放入 Secret 中，当创建或更新该 Secret 时，此字段将被编码。

比如当我们部署应用时，使用 Secret 存储配置文件，希望在部署过程中，填入部分内容到该配置文件。例如，如果应用程序使用以下配置文件:

1
apiUrl: "https://my.api.com/api/v1"
2
username: "<user>"
3
password: "<password>"

那么就可以使用以下定义将其存储在 Secret 中:secret-demo2.yaml

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: mysecret2
5
type: Opaque
6
stringData:
7
  config.yaml: |
8
    apiUrl: "https://my.api.com/api/v1"
9
    username: <user>
10
    password: <Password>

image-20231106153726907

创建好 Secret对象后，有两种方式来使用它：

以环境变量的形式
以Volume的形式挂载

环境变量#

首先来测试下环境变量的方式，使用一个简单的 busybox 镜像来测试下:secret1-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: secret1-pod
5
spec:
6
  containers:
7
    - name: secret1
8
      image: busybox
9
      command:
10
        - "/bin/sh"
11
        - "-c"
12
        - "env"
13
      env:
14
        - name: USERNAME
15
          valueFrom:
16
            secretKeyRef:
17
              name: mysecret
18
              key: username
19
        - name: PASSWORD
20
          valueFrom:
21
            secretKeyRef:
22
              name: mysecret
23
              key: password
24
      resources:
25
        limits:
26
          memory: "128Mi"
27
          cpu: "500m"

展开收起

image-20231106161019493

Volume挂载#

用一个 Pod 来验证下 Volume 挂载，创建一个 Pod 文件：secret2-pod.yaml

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: secret2-pod
5
spec:
6
  volumes:
7
    - name: secrets
8
      secret:
9
        secretName: mysecret
10
  containers:
11
    - name: secret2
12
      image: busybox
13
      command:
14
        - "/bin/sh"
15
        - "-c"
16
        - "ls /etc/secrets"
17
      volumeMounts:
18
        - name: secrets
19
          mountPath: /etc/secrets
20
      resources:
21
        limits:
22
          memory: "128Mi"
23
          cpu: "500m"

展开收起

image-20231106161817360

可以看到 Secret 把两个 key 挂载成了两个对应的文件。当然如果想要挂载到指定的文件上面，可以在 secretName 下面添加 items 指定 key 和 path。

kubernetes.io/dockerconfigjson#

除了上面的 Opaque 这种类型外，我们还可以来创建用户 docker registry 认证的 Secret，直接使用“kubectl create` 命令创建即可，如下：

Terminal window

1
kubectl create secret docker-registry myregistry --docker-server=DOCKER_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

除了上面这种方法之外，也可以通过指定文件的方式来创建镜像仓库认证信息，需要注意对应的 KEY 和 TYPE：

1
kubectl create secret generic myregistry --from-file=.dockerconfigjson=/root/.docker/config.json --type=kubernetes.io/dockerconfigjson

image-20231106163012987

注意看上面的 TYPE 类型，myregistry 对应的是 kubernetes.io/dockerconfigjson，同样的可以使用 describe 命令来查看详细信息：

Terminal window

1
kubectl describe secret myregistry -n default

image-20231106163540411

data.dockerconfigjson 下面的数据是 base64 编码后的结果。

如果需要拉取私有仓库中的 Docker 镜像的话就需要使用到上面的 myregistry 这个 Secret：

Terminal window

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: foo
5
spec:
6
  containers:
7
  - name: foo
8
    image: 192.168.1.100:5000/test:v1
9
  imagePullSecrets:
10
  - name: myregistry

IMAGEPULLSECRETS:ImagePullSecrets 与 Secrets 不同，因为 Secrets 可以挂载到 Pod 中，但是 ImagePullSecrets 只能由 Kubelet 访问。

拉取私有仓库镜像 192.168.1.100:5000/test:v1，就需要针对该私有仓库来创建一个如上的 Secret，然后在 Pod 中指定 imagePullSecrets。

除了设置 Pod.spec.imagePullSecrets 这种方式来获取私有镜像之外，还可以通过在 ServiceAccount 中设置 imagePullSecrets，然后就会自动为使用该 SA 的 Pod 注入 imagePullSecrets 信息：

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: default
5
  namespace: default
6
  resourceVersion: "332"
7
  selfLink: /api/v1/namespaces/default/serviceaccounts/default
8
  uid: cc37a719-c4fe-4ebf-92da-u92c3e24d5d4
9
secrets:
10
  - name: default-token-5ttg7
11
imagePullSecrets:
12
  - name: myregistry

kubernetes.io/basic-auth#

该类型用来存放用于基本身份认证所需的凭据信息，使用这种 Secret 类型时，Secret 的 data 字段（不一定）必须包含以下两个键（相当于是约定俗成的一个规定）：

username: 用于身份认证的用户名
password: 用于身份认证的密码或令牌

以上两个键的键值都是 base64 编码的字符串。也可以在创建 Secret 时使用 stringData 字段来提供明文形式的内容。下面的 YAML 是基本身份认证 Secret 的一个示例清单：secret-basic-auth.yaml

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: secret-basic-auth
5
type: kubernetes.io/basic-auth
6
stringData:
7
  username: admin
8
  password: adminbasicauth

提供基本身份认证类型的 Secret 仅仅是出于用户方便性考虑，也可以使用 Opaque 类型来保存用于基本身份认证的凭据，不过使用内置的 Secret 类型的有助于对凭据格式进行统一处理。

kubernetes.io/ssh-auth#

该类型用来存放 SSH 身份认证中所需要的凭据，使用这种 Secret 类型时，就必须在其 data（或 stringData）字段中提供一个 ssh-privatekey 键值对，作为要使用的 SSH 凭据。

如下所示是一个 SSH 身份认证 Secret 的配置示例：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: secret-ssh-auth
5
type: kubernetes.io/ssh-auth
6
data:
7
  ssh-privatekey: |
8
    MIIEpQIBAAKCAQEAulqb/Y ...

同样提供 SSH 身份认证类型的 Secret 也仅仅是出于用户方便性考虑，也可以使用 Opaque 类型来保存用于 SSH 身份认证的凭据，只是使用内置的 Secret 类型的有助于对凭据格式进行统一处理。

kubernetes.io/tls#

该类型用来存放证书及其相关密钥（通常用在 TLS 场合）。此类数据主要提供给 Ingress 资源，用以校验 TLS 链接，当使用此类型的 Secret 时，Secret 配置中的 data （或 stringData）字段必须包含 tls.key 和 tls.crt主键。下面的 YAML 包含一个 TLS Secret 的配置示例：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: secret-tls
5
type: kubernetes.io/tls
6
data:
7
  tls.crt: |
8
    MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
9
  tls.key: |
10
    MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

提供 TLS 类型的 Secret 仅仅是出于用户方便性考虑，也可以使用 Opaque 类型来保存用于 TLS 服务器与/或客户端的凭据。不过，使用内置的 Secret 类型的有助于对凭据格式进行统一化处理。当使用 kubectl 来创建 TLS Secret 时，可以像下面的例子一样使用 tls 子命令：

Terminal window

1
kubectl create secret tls my-tls-secret \
2
  --cert=path/to/cert/file \
3
  --key=path/to/key/file

需要注意的是用于 --cert 的公钥证书必须是 .PEM 编码的（Base64 编码的 DER 格式），且与 --key 所给定的私钥匹配，私钥必须是通常所说的 PEM 私钥格式，且未加密。对这两个文件而言，PEM 格式数据的第一行和最后一行（例如，证书所对应的 --------BEGIN CERTIFICATE----- 和 -------END CERTIFICATE----）都不会包含在其中。

kubernetes.io/service-account-token#

另外一种 Secret 类型就是 kubernetes.io/service-account-token，用于被 ServiceAccount 引用。ServiceAccout 创建时 Kubernetes 会默认创建对应的 Secret，如下所示创建一个 Pod：

Terminal window

1
kubectl run secret-pod3 --image nginx -n default

Terminal window

1
kubectl get pods -n default

Terminal window

1
kubectl describe pod secret-pod3 -n default

image-20231106165821857

当创建 Pod 的时候，如果没有指定 ServiceAccount，Pod 则会使用命名空间中名为 default 的 ServiceAccount，上面我们可以看到 spec.serviceAccountName 字段已经被自动设置了。

可以看到这里通过一个 projected 类型的 Volume 挂载到了容器的 /var/run/secrets/kubernetes.io/serviceaccount 的目录中，projected 类型的 Volume 可以同时挂载多个来源的数据，这里挂载了一个 downwardAPI 来获取 namespace，通过 ConfigMap 来获取 ca.crt 证书，然后还有一个 serviceAccountToken 类型的数据源。

在之前的版本（v1.20）中，是直接将 default（自动创建的）的 ServiceAccount 对应的 Secret 对象通过 Volume 挂载到了容器的 /var/run/secrets/kubernetes.io/serviceaccount 的目录中的，现在的版本提供了更多的配置选项，比如上面配置了 expirationSeconds 和 path 两个属性。

前面也提到了默认情况下当前 namespace 下面的 Pod 会默认使用 default 这个 ServiceAccount，对应的 Secret 会自动挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中，这样就可以在 Pod 里面获取到用于身份认证的信息了。

可以使用自动挂载给 Pod 的 ServiceAccount 凭据访问 API，也可以通过在 ServiceAccount 上设置 automountServiceAccountToken: false 来实现不给 ServiceAccount 自动挂载 API 凭据：

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: build-robot
5
automountServiceAccountToken: false
6
...

此外也可以选择不给特定 Pod 自动挂载 API 凭据：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: my-pod
5
spec:
6
  serviceAccountName: build-robot
7
  automountServiceAccountToken: false
8
  ...

如果 Pod 和 ServiceAccount 都指定了 automountServiceAccountToken 值，则 Pod 的 spec 优先于 ServiceAccount。

ServiceAccount Token 投影#

ServiceAccount 是 Pod 和集群 apiserver 通讯的访问凭证，传统方式下，在 Pod 中使用 ServiceAccount 可能会遇到如下的安全挑战：

ServiceAccount 中的 JSON Web Token (JWT) 没有绑定 audience 身份，因此所有 ServiceAccount 的使用者都可以彼此扮演，存在伪装攻击的可能
传统方式下每一个 ServiceAccount 都需要存储在一个对应的 Secret 中，并且会以文件形式存储在对应的应用节点上，而集群的系统组件在运行过程中也会使用到一些权限很高的 ServiceAccount，其增大了集群管控平面的攻击面，攻击者可以通过获取这些管控组件使用的 ServiceAccount 非法提权
ServiceAccount 中的 JWT token 没有设置过期时间，当上述 ServiceAccount 泄露情况发生时，只能通过轮转 ServiceAccount 的签发私钥来进行防范
每一个 ServiceAccount 都需要创建一个与之对应的 Secret，在大规模的应用部署下存在弹性和容量风险

为解决这个问题 Kubernetes 提供了 ServiceAccount Token 投影特性用于增强 ServiceAccount 的安全性，ServiceAccount 令牌卷投影可使 Pod 支持以卷投影的形式将 ServiceAccount 挂载到容器中从而避免了对 Secret 的依赖。

通过 ServiceAccount 令牌卷投影可用于工作负载的 ServiceAccount 令牌是受时间限制，受 audience 约束的,并且不与 Secret 对象关联。如果删除了 Pod 或删除了 ServiceAccount，则这些令牌将无效，从而可以防止任何误用，Kubelet 还会在令牌即将到期时自动旋转令牌，另外，还可以配置希望此令牌可用的路径。

为了启用令牌请求投射（此功能在 Kubernetes 1.12 中引入，Kubernetes v1.20 已经稳定版本），你必须为 kube-apiserver 设置以下命令行参数，通过 kubeadm 安装的集群已经默认配置了：

1
--service-account-issuer  # serviceaccount token 中的签发身份，即token payload中的iss字段。
2
--service-account-key-file # token 私钥文件路径
3
--service-account-signing-key-file  # token 签名私钥文件路径
4
--api-audiences (可选参数)  # 合法的请求token身份，用于apiserver服务端认证请求token是否合法。

配置完成后就可以指定令牌的所需属性，例如身份和有效时间，这些属性在默认 ServiceAccount 令牌上无法配置。当删除 Pod 或 ServiceAccount 时，ServiceAccount 令牌也将对 API 无效。

可以使用名为 ServiceAccountToken 的 ProjectedVolume 类型在 PodSpec 上配置此功能，比如要向 Pod 提供具有 “vault” 用户以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：

例如当 Pod 中需要使用 audience 为 vault 并且有效期为2个小时的 ServiceAccount 时，我们可以使用以下模板配置 PodSpec 来使用 ServiceAccount 令牌卷投影。

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: build-robot
5

6
---
7
apiVersion: v1
8
kind: Pod
9
metadata:
10
  name: nginx
11
spec:
12
  containers:
13
    - image: nginx
14
      name: nginx
15
      volumeMounts:
16
        - mountPath: /var/run/secrets/tokens
17
          name: vault-token
18
  serviceAccountName: build-robot
19
  volumes:
20
    - name: vault-token
21
      projected:
22
        sources:
23
          - serviceAccountToken:
24
              path: vault-token
25
              expirationSeconds: 7200
26
              audience: vault

展开收起

kubelet 组件会替 Pod 请求令牌并将其保存起来，通过将令牌存储到一个可配置的路径使之在 Pod 内可用，并在令牌快要到期的时候刷新它。 kubelet 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时的时候主动轮换它。应用程序负责在令牌被轮换时重新加载其内容。对于大多数使用场景而言，周期性地（例如，每隔 5 分钟）重新加载就足够了。

其他特性#

如果某个容器已经在通过环境变量使用某 Secret，对该 Secret 的更新不会被容器马上看见，除非容器被重启，当然可以使用一些第三方的解决方案在 Secret 发生变化时触发容器重启。

在 Kubernetes v1.21 版本提供了不可变的 Secret 和 ConfigMap 的可选配置[stable]，可以设置 Secret 和 ConfigMap 为不可变的，对于大量使用 Secret 或者 ConfigMap 的集群（比如有成千上万各不相同的 Secret 供 Pod 挂载）时，禁止变更它们的数据有很多好处：

可以防止意外更新导致应用程序中断
通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的 watch 操作，从而显著降低 kube-apiserver 的负载，提升集群性能

这个特性通过可以通过 ImmutableEmphemeralVolumes 特性门来进行开启，从 v1.19 开始默认启用，可以通过将 Secret 的 immutable 字段设置为 true 创建不可更改的 Secret。例如：

1
apiVersion: v1
2
kind: Secret
3
metadata: ...
4
data: ...
5
immutable: true # 标记为不可变

一旦一个 Secret 或 ConfigMap 被标记为不可更改，撤销此操作或者更改 data 字段的内容都是不允许的，只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点，所以建议重新创建这些 Pod。

Secret vs ConfigMap#

最后来对比下 Secret 和 ConfigMap这两种资源对象的异同点：

相同点#

key/value的形式
属于某个特定的命名空间
可以导出到环境变量
可以通过目录/文件形式挂载
通过 volume 挂载的配置信息均可热更新

不同点#

Secret 可以被 ServerAccount 关联
Secret 可以存储 docker register 的鉴权信息，用在 ImagePullSecret 参数中，用于拉取私有仓库的镜像
Secret 支持 Base64 加密
Secret 分为 kubernetes.io/service-account-token、kubernetes.io/dockerconfigjson、Opaque 三种类型，而 Configmap 不区分类型

**使用注意:**同样 Secret 文件大小限制为 1MB（ETCD 的要求）；Secret 虽然采用 Base64 编码，但是还是可以很方便解码获取到原始信息，所以对于非常重要的数据还是需要慎重考虑，可以考虑使用 Vault 来进行加密管理。

Kubernetes-OpenKruise

Fri, 03 Nov 2023 00:00:00 GMT

OpenKruise 是一个基于 Kubernetes 的扩展套件，主要聚焦于云原生应用的自动化，比如部署、发布、运维以及可用性防护。OpenKruise 提供的绝大部分能力都是基于 CRD 扩展来定义的，它们不存在于任何外部依赖，可以运行在任意纯净的 Kubernetes 集群中。Kubernetes 自身提供的一些应用部署管理功能，对于大规模应用与集群的场景这些功能是远远不够的，OpenKruise 弥补了 Kubernetes 在应用部署、升级、防护、运维等领域的不足。

OpenKruise 提供了以下核心能力：

增强版本的 Workloads

OpenKruise 包含了一系列增强版本的 Workloads（工作负载），比如 CloneSet、Advanced StatefulSet、Advanced DaemonSet、BroadcastJob 等。

它们不仅支持类似于 Kubernetes 原生 Workloads 的基础功能，还提供了如原地升级、可配置的扩缩容/发布策略、并发操作等。

其中，原地升级是一种升级应用容器镜像甚至环境变量的全新方式。它只会用新的镜像重建 Pod 中的特定容器，整个 Pod 以及其中的其他容器都不会被影响。因此它带来了更快的发布速度，以及避免了对其他 Scheduler、CNI、CSI 等组件的负面影响。
应用的旁路管理

OpenKruise 提供了多种通过旁路管理应用 sidecar 容器、多区域部署的方式，“旁路” 意味着你可以不需要修改应用的 Workloads 来实现它们。

比如，SidecarSet 能帮助你在所有匹配的 Pod 创建的时候都注入特定的 sidecar 容器，甚至可以原地升级已经注入的 sidecar 容器镜像、并且对 Pod 中其他容器不造成影响。

而 WorkloadSpread 可以约束无状态 Workload 扩容出来 Pod 的区域分布，赋予单一 workload 的多区域和弹性部署的能力。
高可用性防护

OpenKruise 在为应用的高可用性防护方面也做出了很多努力。

目前它可以保护你的 Kubernetes 资源不受级联删除机制的干扰，包括 CRD、Namespace、以及几乎全部的 Workloads 类型资源。

相比于 Kubernetes 原生的 PDB 只提供针对 Pod Eviction 的防护，PodUnavailableBudget 能够防护 Pod Deletion、Eviction、Update 等许多种 voluntary disruption 场景。
高级的应用运维能力

OpenKruise 也提供了很多高级的运维能力来帮助你更好地管理应用。

可以通过 ImagePullJob 来在任意范围的节点上预先拉取某些镜像，或者指定某个 Pod 中的一个或多个容器被原地重启。

系统架构#

下图是 OpenKruise 的整体架构：

架构

API#

所有 OpenKruise 的功能都是通过 Kubernetes API 来提供, 比如：

新的 CRD 定义，比如
Terminal window
```
1
kubectl get crd | grep kruise.io
```
image-20231103121557412

其中 Kruise-manager 是一个运行控制器和 webhook 的中心组件，它通过 Deployment 部署在 kruise-system 命名空间中。从逻辑上来看，如 cloneset-controller、sidecarset-controller 这些的控制器都是独立运行的，不过为了减少复杂度，它们都被打包在一个独立的二进制文件、并运行在 kruise-controller-manager-xxx 这个 Pod 中。除了控制器之外，kruise-controller-manager-xxx 中还包含了针对 Kruise CRD 以及 Pod 资源的 admission webhook。Kruise-manager 会创建一些 webhook configurations 来配置哪些资源需要感知处理、以及提供一个 Service 来给 kube-apiserver 调用。

从 v0.8.0 版本开始提供了一个新的 Kruise-daemon 组件，它通过 DaemonSet 部署到每个节点上，提供镜像预热、容器重启等功能。

安装#

从 v1.0.0 (alpha/beta) 开始，OpenKruise 要求在 Kubernetes >= 1.16 以上版本的集群中安装和使用。

添加 charts 仓库

Terminal window

1
helm repo add openkruise https://openkruise.github.io/charts/
2
helm repo update

执行下面的命令安装最新版本的应用：
Terminal window
```
1
helm install kruise openkruise/kruise --version 1.5.0
```
image-20231103112150632

该 charts 在模板中默认定义了命名空间为 kruise-system，所以在安装的时候可以不用指定，如果你的环境访问 DockerHub 官方镜像较慢，则可以使用下面的命令将镜像替换成阿里云的镜像：
Terminal window
```
1
helm upgrade --install kruise openkruise/kruise --set manager.image.repository=openkruise-registry.cn-hangzhou.cr.aliyuncs.com/openkruise/kruise-manager --version 1.5.0
```
应用部署完成后会在 kruise-system 命名空间下面运行 2 个 kruise-manager 的 Pod，同样它们之间采用 leader-election 的方式选主，同一时间只有一个提供服务，达到高可用的目的，此外还会以 DaemonSet 的形式启动 kruise-daemon 组件：
Terminal window
```
1
kubectl get pod -n kruise-system
```
image-20231103112229567

CloneSet#

CloneSet 控制器是 OpenKruise 提供的对原生 Deployment 的增强控制器，在使用方式上和 Deployment 几乎一致，如下所示是我们声明的一个 CloneSet 资源对象：cloneset-demo.yaml

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: CloneSet
3
metadata:
4
  name: cs-demo
5
spec:
6
  replicas: 3
7
  selector:
8
    matchLabels:
9
      app: cs
10
  template:
11
    metadata:
12
      labels:
13
        app: cs
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx
18
          imagePullPolicy: IfNotPresent
19
          ports:
20
            - containerPort: 80

展开收起

直接创建上面的这个 CloneSet 对象：

Terminal window

1
kubectl apply -f cloneset-demo.yaml

image-20231103122758723

Terminal window

1
kubectl describe cloneset cs-demo

1
Name:         cs-demo
2
Namespace:    default
3
Labels:       <none>
4
Annotations:  <none>
5
API Version:  apps.kruise.io/v1alpha1
6
Kind:         CloneSet
7
Metadata:
8
  Creation Timestamp:  2023-11-03T04:26:56Z
9
  Generation:          1
10
  Managed Fields:
11
    API Version:  apps.kruise.io/v1alpha1
12
    Fields Type:  FieldsV1
13
    fieldsV1:
14
      f:status:
15
        .:
16
        f:availableReplicas:
17
        f:collisionCount:
18
        f:currentRevision:
19
        f:expectedUpdatedReplicas:
20
        f:labelSelector:
21
        f:observedGeneration:
22
        f:readyReplicas:
23
        f:replicas:
24
        f:updateRevision:
25
        f:updatedReadyReplicas:
26
        f:updatedReplicas:
27
    Manager:      kruise-manager
28
    Operation:    Update
29
    Subresource:  status
30
    Time:         2023-11-03T04:26:56Z
31
    API Version:  apps.kruise.io/v1alpha1
32
    Fields Type:  FieldsV1
33
    fieldsV1:
34
      f:metadata:
35
        f:annotations:
36
          .:
37
          f:kubectl.kubernetes.io/last-applied-configuration:
38
      f:spec:
39
        .:
40
        f:replicas:
41
        f:selector:
42
          .:
43
          f:matchLabels:
44
            .:
45
            f:app:
46
        f:template:
47
          .:
48
          f:metadata:
49
            .:
50
            f:labels:
51
              .:
52
              f:app:
53
          f:spec:
54
            .:
55
            f:containers:
56
    Manager:         kubectl-client-side-apply
57
    Operation:       Update
58
    Time:            2023-11-03T04:26:56Z
59
  Resource Version:  32196
60
  UID:               3bdb4d0c-f298-42e6-ac32-85808e4be2c9
61
Spec:
62
  Replicas:                3
63
  Revision History Limit:  10
64
  Scale Strategy:
65
  Selector:
66
    Match Labels:
67
      App:  cs
68
  Template:
69
    Metadata:
70
      Creation Timestamp:  <nil>
71
      Labels:
72
        App:  cs
73
    Spec:
74
      Containers:
75
        Image:              nginx
76
        Image Pull Policy:  IfNotPresent
77
        Name:               nginx
78
        Ports:
79
          Container Port:  80
80
          Protocol:        TCP
81
        Resources:
82
        Termination Message Path:    /dev/termination-log
83
        Termination Message Policy:  File
84
      Dns Policy:                    ClusterFirst
85
      Restart Policy:                Always
86
      Scheduler Name:                default-scheduler
87
      Security Context:
88
      Termination Grace Period Seconds:  30
89
  Update Strategy:
90
    Max Surge:        0
91
    Max Unavailable:  20%
92
    Partition:        0
93
    Type:             ReCreate
94
Status:
95
  Available Replicas:         0
96
  Collision Count:            0
97
  Current Revision:           cs-demo-6599fc6cdd
98
  Expected Updated Replicas:  3
99
  Label Selector:             app=cs
100
  Observed Generation:        1
101
  Ready Replicas:             0
102
  Replicas:                   3
103
  Update Revision:            cs-demo-6599fc6cdd
104
  Updated Ready Replicas:     0
105
  Updated Replicas:           3
106
Events:
107
  Type    Reason            Age   From                 Message
108
  ----    ------            ----  ----                 -------
109
  Normal  SuccessfulCreate  40s   cloneset-controller  succeed to create pod cs-demo-8zbgl
110
  Normal  SuccessfulCreate  40s   cloneset-controller  succeed to create pod cs-demo-cc8hl
111
  Normal  SuccessfulCreate  40s   cloneset-controller  succeed to create pod cs-demo-mxzws

展开收起

Terminal window

1
kubectl get pods -l app=cs

image-20231103122915573

CloneSet 虽然在使用上和 Deployment 比较类似，但还是有非常多比 Deployment 更高级的功能:

扩缩容#

CloneSet 在扩容的时候可以通过 ScaleStrategy.MaxUnavailable 来限制扩容的步长，这样可以对服务应用的影响最小，可以设置一个绝对值或百分比，如果不设置该值，则表示不限制。

比如在上面的资源清单中添加如下所示数据：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: CloneSet
3
metadata:
4
  name: cs-demo
5
spec:
6
  minReadySeconds: 60
7
  scaleStrategy:
8
    maxUnavailable: 1
9
  replicas: 5
10
  ......

上面配置的 scaleStrategy.maxUnavailable 为 1，结合 minReadySeconds 参数，表示在扩容时，只有当上一个扩容出的 Pod 已经 Ready 超过一分钟后，CloneSet 才会执行创建下一个 Pod，比如这里我们扩容成 5 个副本，更新上面对象后查看 CloneSet 的事件：

image-20231103123852328

可以看到第一时间扩容了一个 Pod，由于配置了 minReadySeconds: 60，也就是新扩容的 Pod 创建成功超过 1 分钟后才会扩容另外一个 Pod，上面的 Events 信息也能表现出来，查看 Pod 的 AGE 也能看出来扩容的 2 个 Pod 之间间隔了 1 分钟左右：

image-20231103124011932

当 CloneSet 被缩容时，还可以指定一些 Pod 来删除，这对于 StatefulSet 或者 Deployment 来说是无法实现的， StatefulSet 是根据序号来删除 Pod，而 Deployment/ReplicaSet 目前只能根据控制器里定义的排序来删除。而 CloneSet 允许用户在缩小 replicas 数量的同时，指定想要删除的 Pod 名字，如下所示：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: CloneSet
3
metadata:
4
  name: cs-demo
5
spec:
6
  minReadySeconds: 60
7
  scaleStrategy:
8
    maxUnavailable: 1
9
    podsToDelete:
10
    - cs-demo-8zbgl
11
  replicas: 4
12
  ......

更新上面的资源对象后，会将应用缩到 4 个 Pod，如果在 podsToDelete 列表中指定了 Pod 名字，则控制器会优先删除这些 Pod，对于已经被删除的 Pod，控制器会自动从 podsToDelete 列表中清理掉。比如更新上面的资源对象后 cs-demo-8zbgl 这个 Pod 会被移除，其余会保留下来：

image-20231103124337612

如果只把 Pod 名字加到 podsToDelete，但没有修改 replicas 数量，那么控制器会先把指定的 Pod 删掉，然后再扩一个新的 Pod，另一种直接删除 Pod 的方式是在要删除的 Pod 上打 apps.kruise.io/specified-delete: true 标签。

相比于手动直接删除 Pod，使用 podsToDelete 或 apps.kruise.io/specified-delete: true 方式会有 CloneSet 的 maxUnavailable/maxSurge 来保护删除，并且会触发 PreparingDelete 生命周期的钩子。

升级#

CloneSet 一共提供了 3 种升级方式：

ReCreate: 删除旧 Pod 和它的 PVC，然后用新版本重新创建出来，这是默认的方式
InPlaceIfPossible: 会优先尝试原地升级 Pod，如果不行再采用重建升级
InPlaceOnly: 只允许采用原地升级，因此，用户只能修改上一条中的限制字段，如果尝试修改其他字段会被拒绝

这里有一个重要概念：原地升级，这也是 OpenKruise 提供的核心功能之一，当要升级一个 Pod 中镜像的时候，下图展示了重建升级和原地升级的区别：

原地升级

重建升级时会删除旧 Pod、创建新 Pod：

Pod 名字和 uid 发生变化，因为它们是完全不同的两个 Pod 对象（比如 Deployment 升级）
Pod 名字可能不变、但 uid 变化，因为它们是不同的 Pod 对象，只是复用了同一个名字（比如 StatefulSet 升级）
Pod 所在 Node 名字可能发生变化，因为新 Pod 很可能不会调度到之前所在的 Node 节点
Pod IP 发生变化，因为新 Pod 很大可能性是不会被分配到之前的 IP 地址

但是对于原地升级，仍然复用同一个 Pod 对象，只是修改它里面的字段：

可以避免如调度、分配 IP、挂载盘等额外的操作和代价
更快的镜像拉取，因为会复用已有旧镜像的大部分 layer 层，只需要拉取新镜像变化的一些 layer
当一个容器在原地升级时，Pod 中的其他容器不会受到影响，仍然维持运行

所以用原地升级方式来升级工作负载，对在线应用的影响是最小的。上面提到 CloneSet 升级类型支持 InPlaceIfPossible，这意味着 Kruise 会尽量对 Pod 采取原地升级，如果不能则退化到重建升级，以下的改动会被允许执行原地升级：

更新 workload 中的 spec.template.metadata.*，比如 labels/annotations，Kruise 只会将 metadata 中的改动更新到存量 Pod 上。
更新 workload 中的 spec.template.spec.containers[x].image，Kruise 会原地升级 Pod 中这些容器的镜像，而不会重建整个 Pod。
从 Kruise v1.0 版本开始，更新 spec.template.metadata.labels/annotations 并且 container 中有配置 env from 这些改动的 labels/anntations，Kruise 会原地升级这些容器来生效新的 env 值。

否则，其他字段的改动，比如 spec.template.spec.containers[x].env 或 spec.template.spec.containers[x].resources，都是会回退为重建升级。

比如将上面的应用升级方式设置为 InPlaceIfPossible，只需要在资源清单中添加 spec.updateStrategy.type: InPlaceIfPossible 即可：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: CloneSet
3
metadata:
4
  name: cs-demo
5
spec:
6
  updateStrategy:
7
    type: InPlaceIfPossible
8
  ......

升级前:

image-20231103135702286

image-20231103140413421

升级后:

image-20231103140440553

更新后可以发现 Pod 的状态并没有发生什么大的变化，名称、IP 都一样，唯一变化的是镜像 tag

这就是原地升级的效果，原地升级整体工作流程如下图所示：

原地升级流程

如果在安装或升级 Kruise 的时候启用了 PreDownloadImageForInPlaceUpdate 这个 feature-gate，CloneSet 控制器会自动在所有旧版本 pod 所在节点上预热你正在灰度发布的新版本镜像，这对于应用发布加速很有帮助。

默认情况下 CloneSet 每个新镜像预热时的并发度都是 1，也就是一个一个节点拉镜像，如果需要调整，你可以在 CloneSet annotation 上设置并发度：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: CloneSet
3
metadata:
4
  annotations:
5
    apps.kruise.io/image-predownload-parallelism: "5"

注意，为了避免大部分不必要的镜像拉取，目前只针对 replicas > 3 的 CloneSet 做自动预热。

此外 CloneSet 还支持分批进行灰度，在 updateStrategy 属性中可以配置 partition 参数，该参数可以用来保留旧版本 Pod 的数量或百分比，默认为 0：

如果是数字，控制器会将 (replicas - partition) 数量的 Pod 更新到最新版本
如果是百分比，控制器会将 (replicas * (100% - partition)) 数量的 Pod 更新到最新版本

将上面示例中的的 image 更新为 nginx:latest 并且设置 partition=2，更新后，过一会查看可以发现只升级了 2 个 Pod：

image-20231103141237212

Advanced StatefulSet#

该控制器在原生的 StatefulSet 基础上增强了发布能力，比如 maxUnavailable 并行发布、原地升级等，该对象的名称也是 StatefulSet，但是 apiVersion 是 apps.kruise.io/v1beta1，这个 CRD 的所有默认字段、默认行为与原生 StatefulSet 完全一致，除此之外还提供了一些 optional 字段来扩展增强的策略。因此，用户从原生 StatefulSet 迁移到 Advanced StatefulSet，只需要把 apiVersion 修改后提交即可：

1
-  apiVersion: apps/v1
2
+  apiVersion: apps.kruise.io/v1beta1
3
   kind: StatefulSet
4
   metadata:
5
     name: sample
6
   spec:
7
     #...

注意从 Kruise 0.7.0 开始，Advanced StatefulSet 版本升级到了 v1beta1，并与 v1alpha1 兼容。对于低于 v0.7.0 版本的 Kruise，只能使用 v1alpha1。

最大不可用#

Advanced StatefulSet 在滚动更新策略中新增了 maxUnavailable 来支持并行 Pod 发布，它会保证发布过程中最多有多少个 Pod 处于不可用状态。注意，maxUnavailable 只能配合 podManagementPolicy 为 Parallel 来使用。

这个策略的效果和 Deployment 中的类似，但是可能会导致发布过程中的 order 顺序不能严格保证，如果不配置 maxUnavailable，它的默认值为 1，也就是和原生 StatefulSet 一样只能串行发布 Pod，即使把 podManagementPolicy 配置为 Parallel 也是这样。

创建一个如下所示的 Advanced StatefulSet：asts-demo.yaml

1
apiVersion: apps.kruise.io/v1beta1
2
kind: StatefulSet
3
metadata:
4
  name: web
5
  namespace: default
6
spec:
7
  serviceName: "nginx-headless"
8
  podManagementPolicy: Parallel
9
  replicas: 5
10
  updateStrategy:
11
    type: RollingUpdate
12
    rollingUpdate:
13
      maxUnavailable: 3
14
      # partition: 4
15
  selector:
16
    matchLabels:
17
      app: nginx
18
  template:
19
    metadata:
20
      labels:
21
        app: nginx
22
    spec:
23
      containers:
24
        - name: nginx
25
          image: nginx
26
          ports:
27
            - containerPort: 80

展开收起

直接创建该对象，由于对象名称也是 StatefulSet，所以不能直接用 get sts 来获取了，要通过 get asts 获取：

Terminal window

1
kubectl apply -f asts-demo.yaml

Terminal window

1
kubectl get asts -n default

image-20231103142720075

该应用下有五个 Pod，假设应用能容忍 3 个副本不可用，当把 StatefulSet 里的 Pod 升级版本的时候，可以通过以下步骤来做：

设置 maxUnavailable=3
(可选) 如果需要灰度升级，设置 partition=4，Partition 默认的意思是 order 大于等于这个数值的 Pod 才会更新，在这里就只会更新 P4，即使我们设置了 maxUnavailable=3。
在 P4 升级完成后，把 partition 调整为 0，此时，控制器会同时升级 P1、P2、P3 三个 Pod。注意，如果是原生 StatefulSet，只能串行升级 P3、P2、P1。
一旦这三个 Pod 中有一个升级完成了，控制器会立即开始升级 P0。

把上面应用的镜像版本进行修改，更新后查看 Pod 状态，可以看到有 3 个 Pod 并行升级的：

Terminal window

1
kubectl get pods -l app=nginx

image-20231103143057229

原地升级#

Advanced StatefulSet 增加了 podUpdatePolicy 来允许用户指定重建升级还是原地升级。此外还在原地升级中提供了 graceful period 选项，作为优雅原地升级的策略。用户如果配置了 gracePeriodSeconds 这个字段，控制器在原地升级的过程中会先把 Pod status 改为 not-ready，然后等一段时间（gracePeriodSeconds），最后再去修改 Pod spec 中的镜像版本。这样，就为 endpoints-controller 这些控制器留出了充足的时间来将 Pod 从 endpoints 端点列表中去除。

如果使用 InPlaceIfPossible 或 InPlaceOnly 策略，必须要增加一个 InPlaceUpdateReady readinessGate，用来在原地升级的时候控制器将 Pod 设置为 NotReady，比如设置上面的应用为原地升级的方式：

1
apiVersion: apps.kruise.io/v1beta1
2
kind: StatefulSet
3
metadata:
4
  name: web
5
  namespace: default
6
spec:
7
  serviceName: "nginx-headless"
8
  podManagementPolicy: Parallel
9
  replicas: 5
10
  updateStrategy:
11
    type: RollingUpdate
12
    rollingUpdate:
13
      podUpdatePolicy: InPlaceIfPossible # 尽可能执行原地升级
14
      maxUnavailable: 3
15
      # partition: 4
16
  selector:
17
    matchLabels:
18
      app: nginx
19
  template:
20
    metadata:
21
      labels:
22
        app: nginx
23
    spec:
24
      readinessGates:
25
        - conditionType: InPlaceUpdateReady # 一个新的条件，可确保 Pod 在发生原地更新时保持在 NotReady 状态
26
      containers:
27
        - name: nginx
28
          image: nginx
29
          ports:
30
            - containerPort: 80

展开收起

这里设置 updateStrategy.rollingUpdate.podUpdatePolicy 为 InPlaceIfPossible 模式，表示尽可能使用原地升级的方式进行更新，此外在 Pod 模板中还添加了一个 readinessGates 属性，可以用来确保 Pod 在发生原地更新时保持在 NotReady 状态。比如现在使用上面资源清单更新应用，然后重新修改镜像的版本更新，则会进行原地升级：

Terminal window

1
kubectl describe asts web

image-20231103144122000

同样的 Advanced StatefulSet 也支持原地升级自动预热。

也可以通过设置 paused 为 true 来暂停发布，不过控制器还是会做 replicas 数量管理：

1
apiVersion: apps.kruise.io/v1beta1
2
kind: StatefulSet
3
spec:
4
  # ...
5
  updateStrategy:
6
    rollingUpdate:
7
      paused: true

另外 Advanced StatefulSet 还支持序号保留功能，通过在 reserveOrdinals 字段中写入需要保留的序号，Advanced StatefulSet 会自动跳过创建这些序号的 Pod，如果 Pod 已经存在，则会被删除。

注意，spec.replicas 是期望运行的 Pod 数量，spec.reserveOrdinals 是要跳过的序号。

1
apiVersion: apps.kruise.io/v1beta1
2
kind: StatefulSet
3
spec:
4
  # ...
5
  replicas: 4
6
  reserveOrdinals:
7
    - 1

比如上面的描述 replicas=4, reserveOrdinals=[1] 的 Advanced StatefulSet，表示实际运行的 Pod 序号为 [0,2,3,4]。

如果要把 Pod-3 做迁移并保留序号，则把 3 追加到 reserveOrdinals 列表中，控制器会把 Pod-3 删除并创建 Pod-5（此时运行中 Pod 为 [0,2,4,5]）。
如果只想删除 Pod-3，则把 3 追加到 reserveOrdinals 列表并同时把 replicas 减一修改为 3。控制器会把 Pod-3 删除（此时运行中 Pod 为 [0,2,4]）。

为了避免在一个新 Advanced StatefulSet 创建后有大量失败的 pod 被创建出来，从 Kruise v0.10.0 版本开始引入了在 scale strategy 中的 maxUnavailable 策略。

1
apiVersion: apps.kruise.io/v1beta1
2
kind: StatefulSet
3
spec:
4
  # ...
5
  replicas: 100
6
  scaleStrategy:
7
    maxUnavailable: 10% # percentage or absolute number

当这个字段被设置之后，Advanced StatefulSet 会保证创建 pod 之后不可用 pod 数量不超过这个限制值。比如说，上面这个 StatefulSet 一开始只会一次性创建 100*10%=10 个 pod，在此之后，每当一个 pod 变为 running、ready 状态后，才会再创建一个新 pod 出来。

注意，这个功能只允许在 podManagementPolicy 是 Parallel 的 StatefulSet 中使用。

Advanced DaemonSet#

这个控制器基于原生 DaemonSet 上增强了发布能力，比如灰度分批、按 Node label 选择、暂停、热升级等。同样的该对象的 Kind 名字也是 DaemonSet，只是 apiVersion 是 apps.kruise.io/v1alpha1，这个 CRD 的所有默认字段、默认行为与原生 DaemonSet 完全一致，除此之外还提供了一些 optional 字段来扩展增强的策略。

因此，用户从原生 DaemonSet 迁移到 Advanced DaemonSet，只需要把 apiVersion 修改后提交即可：

Terminal window

1
-  apiVersion: apps/v1
2
+  apiVersion: apps.kruise.io/v1alpha1
3
   kind: DaemonSet
4
   metadata:
5
     name: sample-ds
6
   spec:
7
     #...

升级#

Advanced DaemonSet 在 spec.updateStrategy.rollingUpdate 中有一个 rollingUpdateType 字段，标识了如何进行滚动升级：

Standard: 对于每个节点，控制器会先删除旧的 daemon Pod，再创建一个新 Pod，和原生 DaemonSet 行为一致。
Surging: 对于每个 node，控制器会先创建一个新 Pod，等它 ready 之后再删除老 Pod。

创建如下所示的资源对象：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: DaemonSet
3
metadata:
4
  name: nginx
5
  namespace: default
6
spec:
7
  updateStrategy:
8
    type: RollingUpdate
9
    rollingUpdate:
10
      rollingUpdateType: Standard
11
  selector:
12
    matchLabels:
13
      k8s-app: nginx
14
  template:
15
    metadata:
16
      labels:
17
        k8s-app: nginx
18
    spec:
19
      containers:
20
        - name: nginx
21
          image: nginx
22
          ports:
23
            - name: http
24
              containerPort: 80

展开收起

Terminal window

1
kubectl apply -f ads-demo.yaml

Terminal window

1
kubectl get daemon -n default

image-20231103145953642

我们这里只有3个 Work 节点，所以一共运行了 3 个 Pod，每个节点上一个，和默认的 DaemonSet 行为基本一致。此外这个策略还支持用户通过配置 node 标签的 selector，来指定灰度升级某些特定类型 node 上的 Pod，比如现在只升级 node1 节点的应用，则可以使用 selector 标签来标识：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: DaemonSet
3
spec:
4
  # ...
5
  updateStrategy:
6
    type: RollingUpdate
7
    rollingUpdate:
8
      rollingUpdateType: Standard
9
      selector:
10
        matchLabels:
11
          kubernetes.io/hostname: node1
12
# ...

更新应用后可以看到只会更新 node1 节点上的 Pod：

image-20231103150616177

和前面两个控制器一样，Advanced DaemonSet 也支持分批灰度升级，使用 Partition 进行配置，Partition 的语义是保留旧版本 Pod 的数量，默认为 0，如果在发布过程中设置了 partition，则控制器只会将 (status.DesiredNumberScheduled - partition) 数量的 Pod 更新到最新版本。

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: DaemonSet
3
spec:
4
  # ...
5
  updateStrategy:
6
    type: RollingUpdate
7
    rollingUpdate:
8
      partition: 10 #保留10个旧版本的pod
9
      paused: true # 暂停发布

同样 Advanced DaemonSet 也是支持原地升级的，只需要设置 rollingUpdateType 为支持原地升级的类型即可，比如这里将上面的应用升级方式设置为 InPlaceIfPossible 即可：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: DaemonSet
3
spec:
4
  # ...
5
  updateStrategy:
6
    type: RollingUpdate
7
    rollingUpdate:
8
      rollingUpdateType: InPlaceIfPossible

BroadcastJob#

这个控制器将 Pod 分发到集群中每个节点上，类似于 DaemonSet，但是 BroadcastJob 管理的 Pod 并不是长期运行的 daemon 服务，而是类似于 Job 的任务类型 Pod，在每个节点上的 Pod 都执行完成退出后，BroadcastJob 和这些 Pod 并不会占用集群资源。这个控制器非常有利于做升级基础软件、巡检等过一段时间需要在整个集群中跑一次的工作。

比如声明一个如下所示的 BroadcastJob 对象：bcj-demo.yaml

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: BroadcastJob
3
metadata:
4
  name: bcj-demo
5
  namespace: default
6
spec:
7
  template:
8
    spec:
9
      restartPolicy: Never
10
      containers:
11
        - name: counter
12
          image: busybox
13
          command:
14
            - /bin/sh
15
            - -c
16
            - for i in 9 8 7 6 5 4 3 2 1; do echo $i; done;

展开收起

Terminal window

1
kubectl apply -f bcj-demo.yaml

Terminal window

1
kubectl get bcj bcj-demo

Terminal window

1
kubectl get pod -n default -o wide

image-20231103152230069

可以看到创建了一个 BroadcastJob 对象后，同时启动了3个 Pod 任务，每个节点上一个，这和原生的 Job 是不太一样的。创建的 BroadcastJob 一共有以下几种状态：

Desired : 期望的 Pod 数量（等同于当前集群中匹配的节点数量）
Active: 运行中的 Pod 数量
SUCCEEDED: 执行成功的 Pod 数量
FAILED: 执行失败的 Pod 数量

此外在 BroadcastJob 对象中还可以配置任务完成后的一些策略，比如配置 completionPolicy.ttlSecondsAfterFinished: 30，表示这个 job 会在执行结束后 30s 被删除。

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: BroadcastJob
3
metadata:
4
  name: bcj-demo
5
  namespace: default
6
spec:
7
  template:
8
    spec:
9
      completionPolicy:
10
        type: Always
11
        ttlSecondsAfterFinished: 30
12
      restartPolicy: Never
13
      containers:
14
        - name: counter
15
          image: busybox
16
          command:
17
            - /bin/sh
18
            - -c
19
            - for i in 9 8 7 6 5 4 3 2 1; do echo $i; done;

展开收起

image-20231103152610543

配置 completionPolicy.activeDeadlineSeconds 为 10，表示这个 job 会在运行超过 10s 之后被标记为失败，并把下面还在运行的 Pod 删除掉。

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: BroadcastJob
3
metadata:
4
  name: bcj-demo
5
  namespace: default
6
spec:
7
  template:
8
    spec:
9
      completionPolicy:
10
        type: Always
11
        activeDeadlineSeconds: 10
12
      restartPolicy: Never
13
      containers:
14
        - name: counter
15
          image: busybox
16
          command:
17
            - /bin/sh
18
            - -c
19
            - for i in 9 8 7 6 5 4 3 2 1; do echo $i; done;

展开收起

completionPolicy 类型除了 Always 之外还可以设置为 Never，表示这个 job 会持续运行即使当前所有节点上的 Pod 都执行完成了。

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: BroadcastJob
3

4
spec:
5
  completionPolicy:
6
    type: Never
7
  # ......

AdvancedCronJob#

AdvancedCronJob 是对于原生 CronJob 的扩展版本，根据用户设置的 schedule 规则，周期性创建 Job 执行任务，而 AdvancedCronJob 的 template 支持多种不同的 job 资源：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: AdvancedCronJob
3
spec:
4
  template:
5
    # Option 1: use jobTemplate, which is equivalent to original CronJob
6
    jobTemplate:
7
      # ...
8
    # Option 2: use broadcastJobTemplate, which will create a BroadcastJob object when cron schedule triggers
9
    broadcastJobTemplate:
10
      # ...

jobTemplate：与原生 CronJob 一样创建 Job 执行任务
broadcastJobTemplate：周期性创建 BroadcastJob 执行任务

AdvancedCronJob

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: AdvancedCronJob
3
metadata:
4
  name: acj-demo
5
spec:
6
  schedule: "*/1 * * * *"
7
  template:
8
    broadcastJobTemplate:
9
      spec:
10
        completionPolicy:
11
          type: Always
12
          ttlSecondsAfterFinished: 30
13
        template:
14
          spec:
15
            restartPolicy: Never
16
            containers: # 一定不是一个常驻前台的进程，一定是一个任务，执行完成后需要退出的
17
              - name: counter
18
                image: busybox
19
                command:
20
                  - "/bin/sh"
21
                  - "-c"
22
                  - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"

展开收起

上述 YAML 定义了一个 AdvancedCronJob，每分钟创建一个 BroadcastJob 对象，这个 BroadcastJob 会在所有节点上运行一个 job 任务。

Terminal window

1
kubectl apply -f acj-demo.yaml

Terminal window

1
kubectl get acj

Terminal window

1
kubectl get bcj

Terminal window

1
kubectl get pod -n default

image-20231103161304819

image-20231103161316979

image-20231103161341673

SidecarSet#

SidecarSet 支持通过 admission webhook 来自动为集群中创建的符合条件的 Pod 注入 sidecar 容器，除了在 Pod 创建时候注入外，SidecarSet 还提供了为 Pod 原地升级其中已经注入的 sidecar 容器镜像的能力。SidecarSet 将 sidecar 容器的定义和生命周期与业务容器解耦，它主要用于管理无状态的 sidecar 容器，比如监控、日志等 agent。

比如定义一个如下所示的 SidecarSet 资源对象：sidecarset.yaml

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: SidecarSet
3
metadata:
4
  name: test-sidecarset
5
spec:
6
  selector:
7
    matchLabels:
8
      app: nginx
9
  updateStrategy:
10
    type: RollingUpdate
11
    maxUnavailable: 1
12
  containers:
13
    - name: sidecar1
14
      image: busybox
15
      command: ["sleep", "999d"]
16
      volumeMounts:
17
        - name: log-volume
18
          mountPath: /var/log
19
  volumes: # this field will be merged into pod.spec.volumes
20
    - name: log-volume
21
      emptyDir: {}

展开收起

直接创建这个资源对象:

Terminal window

1
kubectl apply -f sidecarset.yaml

Terminal window

1
kubectl get sidecarset -n default

image-20231103163124798

需要注意上面我们在定义 SidecarSet 对象的时候里面有一个非常终于的属性就是 label selector，会去匹配具有 app=nginx 的 Pod，然后向其中注入下面定义的 sidecar1 这个容器，比如定义如下所示的一个 Pod，该 Pod 中包含 app=nginx 的标签，这样可以和上面的 SidecarSet 对象匹配：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  labels:
5
    app: nginx # matches the SidecarSet's selector
6
  name: test-pod
7
spec:
8
  containers:
9
    - name: app
10
      image: nginx

image-20231103163323990

可以看到该 Pod 中有 2 个容器，被自动注入了上面定义的 sidecar1 容器：

Terminal window

1
kubectl get pod test-pod -n default -o yaml

image-20231103163512263

现在更新 SidecarSet 中的 sidecar 容器镜像替换成 busybox:1.35.0：

Terminal window

1
kubectl patch sidecarset test-sidecarset --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value": "busybox:1.35.0"}]'

image-20231103163703326

可以看到 Pod 中的 sidecar 容器镜像被原地升级成 busybox:1.35.0 了，对主容器没有产生任何影响。

同意特性#

需要注意的是 sidecar 的注入只会发生在 Pod 创建阶段，并且只有 Pod spec 会被更新，不会影响 Pod 所属的 workload template 模板。 spec.containers 除了默认的 k8s container 字段，还扩展了如下一些字段，来方便注入：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: SidecarSet
3
metadata:
4
  name: sidecarset
5
spec:
6
  selector:
7
    matchLabels:
8
      app: sample
9
  containers:
10
    # 默认的K8s容器字段
11
    - name: nginx
12
      image: nginx:alpine
13
      volumeMounts:
14
        - mountPath: /nginx/conf
15
          name: nginx.conf
16
      # 扩展的sidecar容器字段
17
      podInjectPolicy: BeforeAppContainer
18
      shareVolumePolicy:
19
        type: disabled | enabled
20
      transferEnv:
21
        - sourceContainerName: main
22
          envName: PROXY_IP
23
  volumes:
24
    - name: nginx.conf
25
      hostPath: /data/nginx/conf

展开收起

podInjectPolicy定义了容器注入到pod.spec.containers中的位置
- BeforeAppContainer：表示注入到 pod 原 containers 的前面（(默认) ）
- AfterAppContainer：表示注入到 pod 原 containers 的后面
数据卷共享
- 共享指定卷：通过 spec.volumes 来定义 sidecar 自身需要的 volume
- 共享所有卷：通过 spec.containers[i].shareVolumePolicy.type = enabled | disabled 来控制是否挂载 pod 应用容器的卷，常用于日志收集等 sidecar，配置为 enabled 后会把应用容器中所有挂载点注入 sidecar 同一路经下(sidecar 中本身就有声明的数据卷和挂载点除外）
环境变量共享：可以通过 spec.containers[i].transferEnv 来从别的容器获取环境变量，会把名为 sourceContainerName 容器中名为 envName 的环境变量拷贝到本容器

SidecarSet 不仅支持 sidecar 容器的原地升级，而且提供了非常丰富的升级、灰度策略。同样在 SidecarSet 对象中 updateStrategy 属性下面也可以配置 partition 来定义保留旧版本 Pod 的数量或百分比，默认为 0；同样还可以配置的有 maxUnavailable 属性，表示在发布过程中的最大不可用数量。

当 {matched pod}=100,partition=50,maxUnavailable=10，控制器会发布 50 个 Pod 到新版本，但是同一时间只会发布 10 个 Pod，每发布好一个 Pod 才会再找一个发布，直到 50 个发布完成。
当 {matched pod}=100,partition=80,maxUnavailable=30，控制器会发布 20 个 Pod 到新版本，因为满足 maxUnavailable 数量，所以这 20 个 Pod 会同时发布。

同样也可以设置 paused: true 来暂停发布，此时对于新创建的、扩容的 pod 依旧会实现注入能力，已经更新的 pod 会保持更新后的版本不动，还没有更新的 pod 会暂停更新。

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: SidecarSet
3
metadata:
4
  name: sidecarset
5
spec:
6
  # ...
7
  updateStrategy:
8
    type: RollingUpdate
9
    maxUnavailable: 20%
10
    partition: 10
11
    paused: true

金丝雀发布#

对于有金丝雀发布需求的业务，可以通过 selector 来实现，对于需要率先金丝雀灰度的 pod 打上固定的 [canary.release] = true 的标签，再通过 selector.matchLabels 来选中该 pod 即可。

比如现在有一个 3 副本的 Pod，也具有 app=nginx 的标签，如下所示:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx
5
  namespace: default
6
spec:
7
  replicas: 3
8
  revisionHistoryLimit: 3
9
  selector:
10
    matchLabels:
11
      app: nginx
12
  template:
13
    metadata:
14
      labels:
15
        app: nginx
16
    spec:
17
      containers:
18
        - name: ngx
19
          image: nginx
20
          ports:
21
            - containerPort: 80
22
          resources:
23
            limits:
24
              memory: "128Mi"
25
              cpu: "500m"

展开收起

创建后现在就具有 4 个 app=nginx 标签的 Pod 了，由于都匹配上面创建的 SidecarSet 对象，所以都会被注入一个 sidecar1 的容器，镜像为 busybox：

image-20231103165919504

现在如果想为 test-pod 这个应用来执行灰度策略，将 sidecar 容器镜像更新成 busybox:1.35.0，则可以在 updateStrategy 下面添加 selector.matchLabels 属性 canary.release: "true"：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: SidecarSet
3
metadata:
4
  name: test-sidecarset
5
spec:
6
  selector:
7
    matchLabels:
8
      app: nginx
9
  updateStrategy:
10
    type: RollingUpdate
11
    selector:
12
      matchLabels:
13
        canary.release: "true"
14
  containers:
15
    - name: sidecar1
16
      image: busybox:1.35.0
17
      command: ["sleep", "999d"]
18
      volumeMounts:
19
        - name: log-volume
20
          mountPath: /var/log
21
  volumes: # this field will be merged into pod.spec.volumes
22
    - name: log-volume
23
      emptyDir: {}

展开收起

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  labels:
5
    app: nginx # matches the SidecarSet's selector
6
    canary.release: "true"
7
  name: test-pod
8
spec:
9
  containers:
10
    - name: app
11
      image: nginx

image-20231103170718542

image-20231103170734043

热升级#

SidecarSet 原地升级会先停止旧版本的容器，然后创建新版本的容器，这种方式适合不影响 Pod 服务可用性的 sidecar 容器，比如说日志收集的 Agent。

但是对于很多代理或运行时的 sidecar 容器，例如 Istio Envoy，这种升级方法就有问题了，Envoy 作为 Pod 中的一个代理容器，代理了所有的流量，如果直接重启，Pod 服务的可用性会受到影响，如果需要单独升级 envoy sidecar，就需要复杂的优雅终止和协调机制，所以我们为这种 sidecar 容器的升级提供了一种新的解决方案。

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: SidecarSet
3
metadata:
4
  name: hotupgrade-sidecarset
5
spec:
6
  selector:
7
    matchLabels:
8
      app: hotupgrade
9
  containers:
10
    - name: sidecar
11
      image: openkruise/hotupgrade-sample:sidecarv1
12
      imagePullPolicy: Always
13
      lifecycle:
14
        postStart:
15
          exec:
16
            command:
17
              - /bin/sh
18
              - /migrate.sh
19
      upgradeStrategy:
20
        upgradeType: HotUpgrade
21
        hotUpgradeEmptyImage: openkruise/hotupgrade-sample:empty

展开收起

upgradeType: HotUpgrade 代表该 sidecar 容器的类型是热升级方案
hotUpgradeEmptyImage: 当热升级 sidecar 容器时，业务必须要提供一个 empty 容器用于热升级过程中的容器切换，empty 容器同 sidecar 容器具有相同的配置（除了镜像地址），例如：command、lifecycle、probe 等，但是它不做任何工作。
lifecycle.postStart: 在 postStart 这个 hook 中完成热升级过程中的状态迁移，该脚本需要由业务根据自身的特点自行实现，例如：nginx 热升级需要完成 Listen FD 共享以及 reload 操作。

整体来说热升级特性总共包含以下两个过程：

Pod 创建时，注入热升级容器
原地升级时，完成热升级流程

注入热升级容器

Pod 创建时，SidecarSet Webhook 将会注入两个容器：

{sidecarContainer.name}-1: 如下图所示 envoy-1，这个容器代表正在实际工作的 sidecar 容器，例如：envoy<1>.16.0
{sidecarContainer.name}-2: 如下图所示 envoy-2，这个容器是业务配置的 hotUpgradeEmptyImage 容器，例如：empty<1>.0，用于后面的热升级机制

注入热升级容器

这里以 OpenKruise 的官方示例来进行说明，首先创建上面的 hotupgrade-sidecarset 这个 SidecarSet。然后创建一个如下所示的 CloneSet 对象：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: CloneSet
3
metadata:
4
  labels:
5
    app: hotupgrade
6
  name: busybox
7
spec:
8
  replicas: 1
9
  selector:
10
    matchLabels:
11
      app: hotupgrade
12
  template:
13
    metadata:
14
      labels:
15
        app: hotupgrade
16
    spec:
17
      containers:
18
        - name: busybox
19
          image: openkruise/hotupgrade-sample:busybox

展开收起

创建完成后，CloneSet 管理的 Pod 已经注入 sidecar-1 和 sidecar-2 两个容器：

image-20231103175519470

Terminal window

1
kubectl describe pods busybox-hqvck

image-20231103175541234

busybox 主容器每 100 毫秒会请求一次 sidecar(version=v1)服务：

Terminal window

1
kubectl logs -f busybox-hqvck -c busybox

image-20231103175834893

升级 sidecar 容器，将镜像修改为 openkruise/hotupgrade-sample:sidecarv2：

Terminal window

1
kubectl patch sidecarset hotupgrade-sidecarset --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value": "openkruise/hotupgrade-sample:sidecarv2"}]'

image-20231103180037499

并且在更新过程中观察 busybox 容器仍然会不断请求 sidecar 服务，但是并没有失败的请求出现：

Terminal window

1
kubectl logs -f busybox-hqvck -c busybox

image-20231103180152789

Container Restart#

ContainerRecreateRequest 控制器可以帮助用户重启/重建存量 Pod 中一个或多个容器。和 Kruise 提供的原地升级类似，当一个容器重建的时候，Pod 中的其他容器还保持正常运行，重建完成后，Pod 中除了该容器的 restartCount 增加以外不会有什么其他变化。

为要重建容器的 Pod 提交一个 ContainerRecreateRequest 自定义资源（缩写 CRR）：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: ContainerRecreateRequest
3
metadata:
4
  namespace: pod-namespace
5
  name: xxx
6
spec:
7
  podName: pod-name
8
  containers: # 要重建的容器名字列表，至少要有 1 个
9
    - name: app
10
    - name: sidecar
11
  strategy:
12
    failurePolicy: Fail # 'Fail' 或 'Ignore'，表示一旦有某个容器停止或重建失败， CRR 立即结束
13
    orderedRecreate: false # 'true' 表示要等前一个容器重建完成了，再开始重建下一个
14
    terminationGracePeriodSeconds: 30 # 等待容器优雅退出的时间，不填默认用 Pod 中定义的
15
    unreadyGracePeriodSeconds: 3 # 在重建之前先把 Pod 设为 not ready，并等待这段时间后再开始执行重建
16
    minStartedSeconds: 10 # 重建后新容器至少保持运行这段时间，才认为该容器重建成功
17
  activeDeadlineSeconds: 300 # 如果 CRR 执行超过这个时间，则直接标记为结束（未结束的容器标记为失败）
18
  ttlSecondsAfterFinished: 1800 # CRR 结束后，过了这段时间自动被删除掉

展开收起

一般来说，列表中的容器会一个一个被停止，但可能同时在被重建和启动，除非 orderedRecreate 被设置为 true。 unreadyGracePeriodSeconds 功能依赖于 KruisePodReadinessGate 这个 feature-gate，后者会在每个 Pod 创建的时候注入一个 readinessGate，否则，默认只会给 Kruise workload 创建的 Pod 注入 readinessGate，也就是说只有这些 Pod 才能在 CRR 重建时使用 unreadyGracePeriodSeconds。

ImagePullJob#

NodeImage 和 ImagePullJob 是从 Kruise v0.8.0 版本开始提供的 CRD。Kruise 会自动为每个 Node 创建一个 NodeImage，它包含了哪些镜像需要在这个 Node 上做预热，比如我们这里 4 个节点，则会自动创建 4 个 NodeImage 对象：

Terminal window

1
kubectl get nodeimage

image-20231103181624762

查看 node1 节点上的 NodeImage 对象：

1
kubectl get nodeimage node1 -o yaml

image-20231103181718135

比如在这个节点上拉去一个 ubuntu:latest 镜像，则可以按照如下所示的去修改 spec：

Terminal window

1
......
2
spec:
3
  images:
4
    ubuntu:  # 镜像 name
5
      tags:
6
      - tag: latest  # 镜像 tag
7
        pullPolicy:
8
          ttlSecondsAfterFinished: 300  # [required] 拉取完成（成功或失败）超过 300s 后，将这个任务从 NodeImage 中清除
9
          timeoutSeconds: 600           # [optional] 每一次拉取的超时时间, 默认为 600
10
          backoffLimit: 3               # [optional] 拉取的重试次数，默认为 3
11
          activeDeadlineSeconds: 1200   # [optional] 整个任务的超时时间，无默认值

Terminal window

1
kubectl edit nodeimage node1
2

3
# 把spec: {}替换成上面的spec那一堆配置

image-20231103182410309

更新后可以从 status 中看到拉取进度以及结果，并且拉取完成 600s 后任务会被清除。

此外用户可以创建 ImagePullJob 对象，来指定一个镜像要在哪些节点上做预热。

ImagePullJob

比如创建如下所示的 ImagePullJob 资源对象：

1
apiVersion: apps.kruise.io/v1alpha1
2
kind: ImagePullJob
3
metadata:
4
  name: job-with-always
5
spec:
6
  image: nginx:1.9.1 # [required] 完整的镜像名 name:tag
7
  parallelism: 10 # [optional] 最大并发拉取的节点梳理, 默认为 1
8
  selector: # [optional] 指定节点的 名字列表 或 标签选择器 (只能设置其中一种)
9
    names:
10
      - node-1
11
      - node-2
12
    matchLabels:
13
      node-type: xxx
14
  # podSelector:         # [optional] pod label 选择器来在这些 pod 所在节点上拉取镜像, 与 selector 不能同时设置.
15
  #  pod-label: xxx
16
  completionPolicy:
17
    type: Always # [optional] 默认为 Always
18
    activeDeadlineSeconds: 1200 # [optional] 无默认值, 只对 Alway 类型生效
19
    ttlSecondsAfterFinished: 300 # [optional] 无默认值, 只对 Alway 类型生效
20
  pullPolicy: # [optional] 默认 backoffLimit=3, timeoutSeconds=600
21
    backoffLimit: 3
22
    timeoutSeconds: 300
23
  pullSecrets:
24
    - secret-name1
25
    - secret-name2

展开收起

可以在 selector 字段中指定节点的名字列表或标签选择器 (只能设置其中一种)，如果没有设置 selector 则会选择所有节点做预热。或者可以配置 podSelector 来在这些 pod 所在节点上拉取镜像，podSelector 与 selector 不能同时设置。

同时，ImagePullJob 有两种 completionPolicy 类型:

Always：表示这个 job 是一次性预热，不管成功、失败都会结束
activeDeadlineSeconds：整个 job 的 deadline 结束时间
ttlSecondsAfterFinished：结束后超过这个时间，自动清理删除 job
Never：表示这个 job 是长期运行、不会结束，并且会每天都会在匹配的节点上重新预热一次指定的镜像

同样如果预热的镜像来自私有仓库，则可以通过 pullSecrets 来指定仓库的 Secret 信息。

容器启动顺序#

Container Launch Priority 提供了控制一个 Pod 中容器启动顺序的方法。通常来说 Pod 容器的启动和退出顺序是由 Kubelet 管理的，Kubernetes 曾经有一个 KEP 计划在 container 中增加一个 type 字段来标识不同类型容器的启停优先级，但是由于sig-node 考虑到对现有代码架构的改动太大，所以将该提案拒绝了。

这个功能作用在 Pod 对象上，不管它的 owner 是什么类型的，因此可以适用于 Deployment、CloneSet 以及其他的 workload 种类。

比如我们可以设置按照容器顺序启动，只需要在 Pod 中定义一个 apps.kruise.io/container-launch-priority 的注解即可：

1
apiVersion: v1
2
kind: Pod
3
  annotations:
4
    apps.kruise.io/container-launch-priority: Ordered
5
spec:
6
  containers:
7
  - name: sidecar
8
    # ...
9
  - name: main
10
    # ...

Kruise 会保证前面的容器（sidecar）会在后面的容器（main）之前启动。

此外还可以按自定义顺序启动，但是需要在 Pod 容器中添加 KRUISE_CONTAINER_PRIORITY 这个环境变量:

1
apiVersion: v1
2
kind: Pod
3
spec:
4
  containers:
5
    - name: main
6
      # ...
7
    - name: sidecar
8
      env:
9
        - name: KRUISE_CONTAINER_PRIORITY
10
          value: "1"
11
      # ...

该环境变量值的范围在 [-2147483647, 2147483647]，不写默认是 0，权重高的容器，会保证在权重低的容器之前启动，但是需要注意相同权重的容器不保证启动顺序。

除了这些常用的增强控制器之外 OpenKruise 还有很多高级的特性，可以前往官网 https://openkruise.io 了解更多信息。

Kubernetes-CRD

Thu, 02 Nov 2023 00:00:00 GMT

Custom Resource Define 简称 CRD，是 Kubernetes（v1.7+）为提高可扩展性，让开发者去自定义资源的一种方式。CRD 资源可以动态注册到集群中，注册完毕后，用户可以通过 kubectl 来创建访问这个自定义的资源对象，类似于操作 Pod 一样。不过需要注意的是 CRD 仅仅是资源的定义而已，需要一个 Controller 去监听 CRD 的各种事件来添加自定义的业务逻辑。

定义#

如果说只是对 CRD 资源本身进行 CRUD 操作的话，不需要 Controller 也是可以实现的，相当于就是只有数据存入了 etcd 中，而没有对这个数据的相关操作而已。比如可以定义一个如下所示的 CRD 资源清单文件：crd-demo.yaml

1
apiVersion: apiextensions.k8s.io/v1
2
kind: CustomResourceDefinition
3
metadata:
4
  # name 必须匹配下面的spec字段：<plural>.<group>
5
  name: crontabs.stable.example.com
6
spec:
7
  # group 名用于 REST API 中的定义：/apis/<group>/<version>
8
  group: stable.example.com
9
  # 列出自定义资源的所有 API 版本
10
  versions:
11
    - name: v1beta1 # 版本名称，比如 v1、v2beta1 等等
12
      served: true # 是否开启通过 REST APIs 访问 `/apis/<group>/<version>/...`
13
      storage: true # 必须将一个且只有一个版本标记为存储版本
14
      schema: # 定义自定义对象的声明规范
15
        openAPIV3Schema:
16
          description: Define CronTab YAML Spec
17
          type: object
18
          properties:
19
            spec:
20
              type: object
21
              properties:
22
                cronSpec:
23
                  type: string
24
                image:
25
                  type: string
26
                replicas:
27
                  type: integer
28
  # 定义作用范围：Namespaced（命名空间级别）或者 Cluster（整个集群）
29
  scope: Namespaced
30
  names:
31
    # kind 是 sigular 的一个驼峰形式定义，在资源清单中会使用
32
    kind: CronTab
33
    # plural 名字用于 REST API 中的定义：/apis/<group>/<version>/<plural>
34
    plural: crontabs
35
    # singular 名称用于 CLI 操作或显示的一个别名
36
    singular: crontab
37
    # shortNames 相当于缩写形式
38
    shortNames:
39
      - ct

展开收起

这个地方的定义和定义普通的资源对象比较类似，可以随意定义一个自定义的资源对象，但是在创建资源的时候，肯定不是随意去编写 YAML 文件的，当把上面的 CRD 文件提交给 Kubernetes 之后，Kubernetes 会对提交的声明文件进行校验，从定义可以看出 CRD 是基于 OpenAPI v3 schem 进行规范的。当然这种校验只是对于字段的类型进行校验，比较初级，如果想要更加复杂的校验，这个时候就需要通过 Kubernetes 的 admission webhook 来实现了。关于校验的更多用法，可以前往官方文档查看。

同样现在我们可以直接使用 kubectl 来创建这个 CRD 资源清单：

Terminal window

1
kubectl apply -f crd-demo.yaml

image-20231102182137026

这个时候一个新的 namespace 级别的 RESTful API 就会被创建：

Terminal window

1
/apis/stable/example.com/v1beta1/namespaces/*/crontabs/...

然后就可以使用这个 API 端点来创建和管理自定义的对象，这些对象的类型就是上面创建的 CRD 对象规范中的 CronTab。

现在在 Kubernetes 集群中就多了一种新的资源叫做 crontabs.stable.example.com，可以使用它来定义一个 CronTab 资源对象了，这个自定义资源对象里面可以包含的字段在定义的时候通过 schema 进行了规范，比如现在创建一个如下所示的资源清单：crd-crontab-demo.yaml

1
apiVersion: stable.example.com/v1beta1
2
kind: CronTab
3
metadata:
4
  name: my-new-cron-object
5
spec:
6
  cronSpec: "* * * * */5"
7
  image: my-awesome-cron-image

直接创建这个对象：

Terminal window

1
kubectl apply -f crd-crontab-demo.yaml

image-20231102182642342

在使用 kubectl 的时候，资源名称是不区分大小写的，可以使用 CRD 中定义的单数或者复数形式以及任何简写。也可以查看创建的这个对象的原始 YAML 数据：

Terminal window

1
kubectl get ct -o yaml

1
apiVersion: v1
2
items:
3
  - apiVersion: stable.example.com/v1beta1
4
    kind: CronTab
5
    metadata:
6
      annotations:
7
        kubectl.kubernetes.io/last-applied-configuration: |
8
          {"apiVersion":"stable.example.com/v1beta1","kind":"CronTab","metadata":{"annotations":{},"name":"my-new-cron-object","namespace":"default"},"spec":{"cronSpec":"* * * * */5","image":"my-awesome-cron-image"}}
9
      creationTimestamp: "2023-11-02T10:26:09Z"
10
      generation: 1
11
      name: my-new-cron-object
12
      namespace: default
13
      resourceVersion: "736385"
14
      uid: 16c58521-b6b0-4e94-be7f-dfb8ac118f77
15
    spec:
16
      cronSpec: "* * * * */5"
17
      image: my-awesome-cron-image
18
kind: List
19
metadata:
20
  resourceVersion: ""
21
  selfLink: ""

展开收起

Controller#

自定义的资源创建完成了，但是也只是单纯的把资源清单数据存入到了 etcd 中而已，并没有什么其他用处，因为没有定义一个对应的 Controller 来处理它。

官方提供了一个自定义 Controller 的示例：https://github.com/kubernetes/sample-controller，实现了：

如何注册资源 Foo
如何创建、删除和查询 Foo 对象
如何监听 Foo 资源对象的变化情况

要想了解 Controller 的实现原理和方式，就需要了解下 client-go 这个库的实现，Kubernetes 部分代码也是基于这个库实现的，也包含了开发自定义控制器时可以使用的各种机制，这些机制在 client-go 源码的 tools/cache 目录下面有定义。

下图显示了 client-go 中的各个组件是如何工作的以及要编写自定义控制器代码的交互入口：

client-go controller interaction

client-go 组件：#

Reflector：通过 Kubernetes API 监控 Kubernetes 的资源类型采用 List/Watch 机制, 可以 Watch 任何资源包括 CRD 添加 object 对象到 FIFO 队列，然后 Informer 会从队列里面取数据
Informer：controller 机制的基础，循环处理 object 对象从 Reflector 取出数据，然后将数据给到 Indexer 去缓存，提供对象事件的 handler 接口，只要给 Informer 添加 ResourceEventHandler 实例的回调函数，去实现 OnAdd(obj interface{})、 OnUpdate(oldObj, newObj interface{}) 和 OnDelete(obj interface{}) 这三个方法，就可以处理好资源的创建、更新和删除操作了。
Indexer：提供 object 对象的索引，是线程安全的，缓存对象信息

controller 组件：#

Informer reference: controller 需要创建合适的 Informer 才能通过 Informer reference 操作资源对象
Indexer reference: controller 创建 Indexer reference 然后去利用索引做相关处理
Resource Event Handlers：Informer 会回调这些 handlers
Work queue: Resource Event Handlers 被回调后将 key 写到工作队列，这里的 key 相当于事件通知，后面根据取出事件后，做后续的处理
Process Item：从工作队列中取出 key 后进行后续处理，具体处理可以通过 Indexer reference controller 可以直接创建上述两个引用对象去处理，也可以采用工厂模式，官方都有相关示例

client-go/tool/cache/ 和自定义 Controller 的控制流(图片来源)：

client-go controller workflow

如上图所示主要有两个部分，一个是发生在 SharedIndexInformer 中，另外一个是在自定义控制器中。

Reflector 通过 Kubernetes APIServer 执行对象（比如 Pod）的 ListAndWatch 查询，记录和对象相关的三种事件类型Added、Updated、Deleted，然后将它们传递到 DeltaFIFO 中去。
DeltaFIFO 接收到事件和 watch 事件对应的对象，然后将它们转换为 Delta 对象，这些 Delta 对象被附加到队列中去等待处理，对于已经删除的，会检查线程安全的 store 中是否已经存在该文件，从而可以避免在不存在某些内容时排队执行删除操作。
Cache 控制器（不要和自定义控制器混淆）调用 Pop() 方法从 DeltaFIFO 队列中出队列，Delta 对象将传递到 SharedIndexInformer 的 HandleDelta() 方法中以进行进一步处理。
根据 Delta 对象的操作（事件）类型，首先在 HandleDeltas 方法中通过 indexer 的方法将对对象保存到线程安全的 Store 中，然后，通过 SharedIndexInformer 中的 sharedProcessor 的 distribution() 方法将这些对象发送到事件 handlers，这些事件处理器由自定义控制器通过 SharedInformer 的方法比如 AddEventHandlerWithResyncPeriod() 进行注册。
已注册的事件处理器通过添加或更新时间的 MetaNamespaceKeyFunc() 或删除事件的 DeletionHandingMetaNamespaceKeyFunc() 将对象转换为格式为 namespace/name 或只是 name 的 key，然后将这个 key 添加到自定义控制器的 workqueue 中，workqueues 的实现可以在 util/workqueue 中找到。
自定义的控制器通过调用定义的 handlers 处理器从 workqueue 中 pop 一个 key 出来进行处理，handlers 将调用 indexer 的 GetByKey() 从线程安全的 store 中获取对象，业务逻辑就是在这个 handlers 里面实现。

client-go 中也有自定义 Controller 的样例代码，位于：k8s.io/client-go/examples/workqueue/main.go。

Operator#

Operator 就可以看成是 CRD 和 Controller 的一种组合特例，Operator 是一种思想，它结合了特定领域知识并通过 CRD 机制扩展了 Kubernetes API 资源，使用户管理 Kubernetes 的内置资源（Pod、Deployment 等）一样创建、配置和管理应用程序，Operator 是一个特定的应用程序的控制器，通过扩展 Kubernetes API 资源以代表 Kubernetes 用户创建、配置和管理复杂应用程序的实例，通常包含资源模型定义和控制器，通过 Operator 通常是为了实现某种特定软件（通常是有状态服务）的自动化运维。

完全可以通过上面的方式编写一个 CRD 对象，然后去手动实现一个对应的 Controller 就可以实现一个 Operator，但是从头开始去构建一个 CRD 控制器并不容易，需要对 Kubernetes 的 API 有深入了解，并且 RBAC 集成、镜像构建、持续集成和部署等都需要很大工作量。为了解决这个问题，社区就推出了对应的简单易用的 Operator 框架，比较主流的是 kubebuilder 和 Operator Framework，这两个框架的使用基本上差别不大，可以根据自己习惯选择一个即可。

Kubernetes-DaemonSet控制器

Thu, 02 Nov 2023 00:00:00 GMT

通过该控制器的名称可以看出它的用法：Daemon，就是用来部署守护进程的，DaemonSet用于在每个 Kubernetes 节点中将守护进程的副本作为后台进程运行，说白了就是在每个节点部署一个 Pod 副本，当节点加入到 Kubernetes 集群中，Pod 会被调度到该节点上运行，当节点从集群中移除后，该节点上的这个 Pod 也会被移除，当然，如果删除 DaemonSet，所有和这个对象相关的 Pod 都会被删除。业务场景：

集群存储守护程序，如 glusterd、ceph 要部署在每个节点上以提供持久性存储；
节点监控守护进程，如 Prometheus 监控集群，可以在每个节点上运行一个 node-exporter 进程来收集监控节点的信息；
日志收集守护程序，如 fluentd 或 logstash，在每个节点上运行以收集容器的日志
节点网络插件，比如 flannel、calico，在每个节点上运行为 Pod 提供网络服务。

这里需要特别说明的一个就是关于 DaemonSet 运行的 Pod 的调度问题，正常情况下，Pod 运行在哪个节点上是由 Kubernetes 的调度器策略来决定的，然而，由 DaemonSet 控制器创建的 Pod 实际上提前已经确定了在哪个节点上了（Pod 创建时指定了.spec.nodeName），所以：

DaemonSet 并不关心一个节点的 unshedulable 字段。
DaemonSet 可以创建 Pod，即使调度器还没有启动。

使用一个示例来演示下，在每个节点上部署一个 Nginx Pod：nginx-ds.yaml

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: nginx-ds
5
  namespace: default
6
spec:
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx
18
          ports:
19
            - name: http
20
              containerPort: 80
21
          resources:
22
            limits:
23
              cpu: "500m"
24
              memory: "128Mi"

展开收起

Terminal window

1
kubectl apply -f nginx-ds.yaml

image-20231102102212812

观察发现除了 master 节点之外的 3 个节点上都有一个相应的 Pod 运行，因为 master 节点上默认被打上了污点，所以默认情况下不能调度普通的 Pod 到节点上去。

基本上可以用下图来描述 DaemonSet 的拓扑图：

DaemonSet

集群中的 Pod 和 Node 是一一对应的，而 DaemonSet 会管理全部机器上的 Pod 副本，负责对它们进行更新和删除。

DaemonSet 控制器是如何保证每个 Node 上有且只有一个被管理的 Pod ？

首先控制器从 Etcd 获取到所有的 Node 列表，然后遍历所有的 Node。
根据资源对象定义是否有调度相关的配置，然后分别检查 Node 是否符合要求。
在可运行 Pod 的节点上检查是否已有对应的 Pod，如果没有，则在这个 Node 上创建该 Pod；如果有，并且数量大于 1，那就把多余的 Pod 从这个节点上删除；如果有且只有一个 Pod，那就说明是正常情况。

DaemonSet也有对应的更新策略，有 OnDelete 和 RollingUpdate 两种方式，默认是滚动更新。

Kubernetes-HPA控制器

Thu, 02 Nov 2023 00:00:00 GMT

在前面使用了一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能，但是这个是完全手动操作的，要应对线上的各种复杂情况，需要能够做到自动化去感知业务，来自动进行扩缩容。为此，Kubernetes 也提供了这样的一个资源对象：Horizontal Pod Autoscaling（Pod 水平自动伸缩），简称 HPA，HPA通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量，这是 HPA 最基本的原理：

HPA

可以简单的通过 kubectl autoscale 命令来创建一个 HPA 资源对象，HPA Controller 默认30s轮询一次（可通过 kube-controller-manager 的--horizontal-pod-autoscaler-sync-period 参数进行设置），查询指定的资源中的 Pod 资源使用率，并且与创建时设定的值和指标做对比，从而实现自动伸缩的功能。

Metrics Server#

在 HPA 的第一个版本中，需要 Heapster 提供 CPU 和内存指标，在 HPA v2 之后就需要安装 Metrcis Server 了，Metrics Server 可以通过标准的 Kubernetes API 把监控数据暴露出来，有了 Metrics Server 之后，就完全可以通过标准的 Kubernetes API 来访问想要获取的监控数据了：

1
https://10.96.0.1/apis/metrics.k8s.io/v1beta1/namespaces/<namespace-name>/pods/<pod-name>

比如访问上面的 API 的时候，就可以获取到该 Pod 的资源数据，这些数据其实是来自于 kubelet 的 Summary API 采集而来的。不过需要说明的是这里可以通过标准的 API 来获取资源监控数据，并不是因为 Metrics Server 就是 APIServer 的一部分，而是通过 Kubernetes 提供的 Aggregator 汇聚插件来实现的，是独立于 APIServer 之外运行的。

HAP Metrics Server

安装#

本集群时通过kubekey安装的，只需要把配置里的 metrics_server.enabled 改成 true，等几分钟就可以了

1
metrics_server:
2
  enabled: true

image-20231102162825701

HPA对象#

用 Deployment 来创建一个 Nginx Pod，然后利用 HPA 来进行自动扩缩容。资源清单如下所示：hpa-demo.yaml

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: hpa-demo
5
spec:
6
  selector:
7
    matchLabels:
8
      app: nginx
9
  template:
10
    metadata:
11
      labels:
12
        app: nginx
13
    spec:
14
      containers:
15
        - name: nginx
16
          image: nginx
17
          resources:
18
            limits:
19
              memory: "128Mi"
20
              cpu: "500m"
21
          ports:
22
            - containerPort: 80

展开收起

然后直接创建 Deployment，注意一定先把之前创建的具有 app=nginx 的 Pod 先清除掉：

Terminal window

1
kubectl apply -f hpa-demo.yaml

Terminal window

1
kubectl get pods -n default -l app=nginx

image-20231102163302181

现在创建一个 HPA 资源对象，可以使用kubectl autoscale命令来创建：

Terminal window

1
kubectl autoscale deployment hpa-demo -n default --cpu-percent=10 --min=1 --max=10

image-20231102163443659

此命令创建了一个关联资源 hpa-demo 的 HPA，最小的 Pod 副本数为 1，最大为 10。HPA 会根据设定的 cpu 使用率（10%）动态的增加或者减少 Pod 数量。

依然还是可以通过创建 YAML 文件的形式来创建 HPA 资源对象。如果不知道怎么编写的话，可以查看上面命令行创建的 HPA 的 YAML 文件：

Terminal window

1
kubectl get hpa hpa-demo  -n default -o yaml

1
apiVersion: autoscaling/v2
2
kind: HorizontalPodAutoscaler
3
metadata:
4
  creationTimestamp: "2023-11-02T08:34:21Z"
5
  name: hpa-demo
6
  namespace: default
7
  resourceVersion: "712073"
8
  uid: 0016dc58-7224-4f17-a7ef-c37ef621f94e
9
spec:
10
  maxReplicas: 10
11
  metrics:
12
    - resource:
13
        name: cpu
14
        target:
15
          averageUtilization: 10
16
          type: Utilization
17
      type: Resource
18
  minReplicas: 1
19
  scaleTargetRef:
20
    apiVersion: apps/v1
21
    kind: Deployment
22
    name: hpa-demo
23
status:
24
  conditions:
25
    - lastTransitionTime: "2023-11-02T08:34:36Z"
26
      message:
27
        recent recommendations were higher than current one, applying the highest
28
        recent recommendation
29
      reason: ScaleDownStabilized
30
      status: "True"
31
      type: AbleToScale
32
    - lastTransitionTime: "2023-11-02T08:34:36Z"
33
      message:
34
        the HPA was able to successfully calculate a replica count from cpu resource
35
        utilization (percentage of request)
36
      reason: ValidMetricFound
37
      status: "True"
38
      type: ScalingActive
39
    - lastTransitionTime: "2023-11-02T08:34:36Z"
40
      message: the desired count is within the acceptable range
41
      reason: DesiredWithinRange
42
      status: "False"
43
      type: ScalingLimited
44
  currentMetrics:
45
    - resource:
46
        current:
47
          averageUtilization: 0
48
          averageValue: "0"
49
        name: cpu
50
      type: Resource
51
  currentReplicas: 1
52
  desiredReplicas: 1

展开收起

可以根据上面的 YAML 文件就可以自己来创建一个基于 YAML 的 HPA 描述文件了。查看下这个 HPA 对象的信息：

Terminal window

1
kubectl describe hpa hpa-demo -n default

image-20231102164015112

如果在事件信息里面出现了 failed to get cpu utilization: missing request for cpu 这样的错误信息。这是因为创建的 Pod 对象没有添加 request 资源声明，这样导致 HPA 读取不到 CPU 指标信息，所以如果要想让 HPA 生效，对应的 Pod 资源必须添加 requests 资源声明。

这是没有添加resources的事件信息:

image-20231102164340424

现在增大负载进行测试，创建一个 busybox 的 Pod，并且循环访问上面创建的 Pod：

Terminal window

1
kubectl get pod -n default -o wide

image-20231102170035336

Terminal window

1
kubectl run -it --image busybox test-hpa --restart=Never --rm /bin/sh

image-20231102170226578

可以看到CPU达到了29%且已经自动拉起了几个新的 Pod，查看资源 hpa-demo 的副本数量，副本数量已经从原来的 1 变成了 3 个：

image-20231102165809206

Terminal window

1
kubectl describe hpa hpa-demo -n default

image-20231102170506410

关掉 busybox 来减少负载，然后等待一段时间观察下 HPA 和 Deployment 对象：

image-20231102170609774

从 Kubernetes v1.12 版本开始可以通过设置 kube-controller-manager 组件的--horizontal-pod-autoscaler-downscale-stabilization 参数来设置一个持续时间，用于指定在当前操作完成后，HPA 必须等待多长时间才能执行另一次缩放操作。默认为5分钟，也就是默认需要等待5分钟后才会开始自动缩放。

内存#

要使用基于内存或者自定义指标进行扩缩容（现在的版本都必须依赖 metrics-server 这个项目）。再用 Deployment 来创建一个 Nginx Pod，然后利用 HPA 来进行自动扩缩容。资源清单如下所示：hpa-mem-demo.yaml

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: hpa-mem-demo
5
spec:
6
  selector:
7
    matchLabels:
8
      app: nginx
9
  template:
10
    metadata:
11
      labels:
12
        app: nginx
13
    spec:
14
      volumes:
15
        - name: increase-mem-script
16
          configMap:
17
            name: increase-mem-config
18
      containers:
19
        - name: nginx
20
          image: nginx
21
          resources:
22
            limits:
23
              memory: "50Mi"
24
              cpu: "50m"
25
          ports:
26
            - containerPort: 80
27
          volumeMounts:
28
            - name: increase-mem-script
29
              mountPath: /etc/script
30
          securityContext:
31
            privileged: true

展开收起

这里和前面普通的应用有一些区别，将一个名为 increase-mem-config 的 ConfigMap 资源对象挂载到了容器中，该配置文件是用于后面增加容器内存占用的脚本，配置文件如下所示：increase-mem-cm.yaml

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: increase-mem-config
5
data:
6
  increase-mem.sh: |
7
    #!/bin/bash
8
    mkdir /tmp/memory
9
    mount -t tmpfs -o size=40M tmpfs /tmp/memory
10
    dd if=/dev/zero of=/tmp/memory/block
11
    sleep 60
12
    rm /tmp/memory/block
13
    umount /tmp/memory
14
    rmdir /tmp/memory

由于这里增加内存的脚本需要使用到 mount 命令，这需要声明为特权模式，所以添加了 securityContext.privileged=true 这个配置。直接创建上面的资源对象即可：

Terminal window

1
kubectl apply -f increase-mem-cm.yaml

Terminal window

1
kubectl apply -f hpa-mem-demo.yaml

Terminal window

1
kubectl get pod -n default -l app=nginx

image-20231102172228859

然后需要创建一个基于内存的 HPA 资源对象：hpa-mem.yaml

1
apiVersion: autoscaling/v2
2
kind: HorizontalPodAutoscaler
3
metadata:
4
  name: hpa-mem-demo
5
spec:
6
  scaleTargetRef:
7
    apiVersion: apps/v1
8
    kind: Deployment
9
    name: hpa-mem-demo
10
  minReplicas: 1
11
  maxReplicas: 5
12
  metrics:
13
    - type: Resource
14
      resource:
15
        name: memory
16
        target:
17
          type: AverageValue
18
          averageUtilization: 30

展开收起

Terminal window

1
kubectl apply -f hpa-mem.yaml

Terminal window

1
kubectl get hpa -n default

image-20231102173342248

到这里证明 HPA 资源对象已经部署成功了，接下来对应用进行压测，将内存压上去，直接执行上面挂载到容器中的 increase-mem.sh 脚本即可：

Terminal window

1
kubectl exec -it hpa-mem-demo-fcff6c67-89pst -- /bin/bash

image-20231102174000384

可以看到内存使用已经超过了设定的 30% 这个阈值了，HPA 资源对象也已经触发了自动扩容，变成了 4 个副本了。

当内存释放掉后，controller-manager 默认 5 分钟过后会进行缩放，到这里就完成了基于内存的 HPA 操作。

Kubernetes-Job与CronJob

Thu, 02 Nov 2023 00:00:00 GMT

Job 负责处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。而CronJob 则就是在 Job 上加上了时间调度。

Job#

用 Job 这个资源对象来创建一个任务:job-demo.yaml

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: job-demo
5
spec:
6
  template:
7
    spec:
8
      restartPolicy: Never
9
      containers:
10
        - name: counter
11
          image: busybox
12
          command:
13
            - /bin/sh
14
            - -c
15
            - for i in 9 8 7 6 5 4 3 2 1; do echo $i; done

展开收起

Job 中也是一个 Pod 模板，和之前的 Deployment、StatefulSet 之类的是一致的，只是 Pod 中的容器要求是一个任务，而不是一个常驻前台的进程了，因为需要退出，另外值得注意的是 Job 的 RestartPolicy 仅支持 Never 和 OnFailure 两种，不支持 Always，我们知道 Job 就相当于来执行一个批处理任务，执行完就结束了，如果支持 Always 的话就陷入死循环了

直接创建这个 Job 对象：

Terminal window

1
kubectl apply -f job-demo.yaml

Terminal window

1
kubectl get job -n default

Terminal window

1
kubectl get pod -n default

Terminal window

1
kubectl describe job job-demo -n default

image-20231102111006796

image-20231102111026826

Job 任务对应的 Pod 在运行结束后，会变成 Completed 状态，但是如果执行任务的 Pod 因为某种原因一直没有结束，可以在 Job 对象中通过设置字段 spec.activeDeadlineSeconds 来限制任务运行的最长时间，比如：

1
spec:
2
  activeDeadlineSeconds: 100

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: job-demo
5
spec:
6
  template:
7
    spec:
8
      activeDeadlineSeconds: 100
9
      restartPolicy: Never
10
      containers:
11
        - name: counter
12
          image: busybox
13
          command:
14
            - /bin/sh
15
            - -c
16
            - sleep 600

展开收起

那么当我们的任务 Pod 运行超过了 100s 后，这个 Job 的所有 Pod 都会被终止，并且， Pod 的终止原因会变成 DeadlineExceeded。

1
Events:
2
  Type    Reason            Age                From               Message
3
  ----    ------            ----               ----               -------
4
  Normal  Scheduled         2m54s              default-scheduler  Successfully assigned default/job-demo1-wvdwr to node2
5
  Normal  Pulling           2m53s              kubelet            Pulling image "busybox"
6
  Normal  Pulled            2m51s              kubelet            Successfully pulled image "busybox" in 2.377149137s
7
  Normal  Created           2m51s              kubelet            Created container counter1
8
  Normal  Started           2m51s              kubelet            Started container counter1
9
  Normal  Killing           74s                kubelet            Stopping container counter1
10
  Normal  DeadlineExceeded  43s (x3 over 74s)  kubelet            Pod was active on the node longer than the specified deadline

如果的任务执行失败了，会怎么处理呢，这个和定义的 restartPolicy 有关系，比如定义如下所示的 Job 任务，定义 restartPolicy: Never 的重启策略：

image-20231102112011909

设置成 Never 重启策略的时候，Job 任务执行失败后会不断创建新的 Pod，但是不会一直创建下去，会根据 spec.backoffLimit 参数进行限制，默认为6，通过该字段可以定义重建 Pod 的次数，另外需要注意的是 Job 控制器重新创建 Pod 的间隔是呈指数增加的，即下一次重新创建 Pod 的动作会分别发生在 10s、20s、40s… 后。

image-20231102120729419

但是如果设置 restartPolicy: OnFailure 重启策略，则当 Job 任务执行失败后不会创建新的 Pod 出来，只会不断重启 Pod。

除此之外，还可以通过设置 spec.parallelism 参数来进行并行控制，该参数定义了一个 Job 在任意时间最多可以有多少个 Pod 同时运行。spec.completions 参数可以定义 Job 至少要完成的 Pod 数目。如下所示创建一个新的 Job 任务，设置允许并行数为2，至少要完成的 Pod 数为8：job-para-demo.yaml

1
apiVersion: batch/v1
2
kind: Job
3
metadata:
4
  name: job-para-test
5
spec:
6
  parallelism: 2
7
  completions: 8
8
  template:
9
    spec:
10
      containers:
11
        - name: test-job
12
          image: busybox
13
          command: ["echo", "test paralle job!"]
14
      restartPolicy: Never

Terminal window

1
kubectl apply -f para-demo.yaml

image-20231102121002977

可以看到一次可以有2个 Pod 同时运行，需要8个 Pod 执行成功，如果不是8个成功，那么会根据 restartPolicy 的策略进行处理，可以认为是一种检查机制。

CronJob#

CronJob 其实就是在 Job 的基础上加上了时间调度，可以在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。这个实际上和 Linux 中的 crontab 就非常类似了。

一个 CronJob 对象其实就对应中 crontab 文件中的一行，它根据配置的时间格式周期性地运行一个 Job，格式和 crontab 也是一样的。

crontab 的格式为：分时日月星期要运行的命令 。

第1列分钟 0～59
第2列小时 0～23
第3列日 1～31
第4列月 1～12
第5列星期 0～7（0和7表示星期天）
第6列要运行的命令

用 CronJob 来管理我们上面的 Job 任务，定义如下所示的资源清单：cronjob-demo.yaml

1
apiVersion: batch/v1
2
kind: CronJob
3
metadata:
4
  name: cronjob-demo
5
spec:
6
  schedule: "*/1 * * * *"
7
  jobTemplate:
8
    spec:
9
      template:
10
        spec:
11
          containers:
12
            - name: hello
13
              image: busybox
14
              command:
15
                - "bin/sh"
16
                - "-c"
17
                - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"
18
          restartPolicy: OnFailure

展开收起

这里的 Kind 变成了 CronJob 了，要注意的是 spec.schedule 字段是必须填写的，用来指定任务运行的周期，格式就和 crontab 一样，另外一个字段是 .spec.jobTemplate, 用来指定需要运行的任务，格式当然和 Job 是一致的。还有一些值得我们关注的字段 .spec.successfulJobsHistoryLimit(默认为3) 和 .spec.failedJobsHistoryLimit(默认为1)，表示历史限制，是可选的字段，指定可以保留多少完成和失败的 Job。然而，当运行一个 CronJob 时，Job 可以很快就堆积很多，所以一般推荐设置这两个字段的值，如果设置限制的值为 0，那么相关类型的 Job 完成后将不会被保留。

我们直接新建上面的资源对象：

Terminal window

1
kubectl apply -f cronjob-demo.yaml

稍微等一会儿查看可以发现多了几个 Job 资源对象，这个就是因为上面设置的 CronJob 资源对象，每1分钟执行一个新的 Job：

image-20231102122757357

这个就是 CronJob 的基本用法，一旦不再需要 CronJob，可以使用 kubectl 命令删除它：

Terminal window

1
kubectl delete cronjob cronjob-demo

需要注意的是这将会终止正在创建的 Job，但是运行中的 Job 将不会被终止，不会删除 Job 或它们的 Pod。

Kubernetes-StatefulSet控制器

Wed, 01 Nov 2023 00:00:00 GMT

在实际使用的过程中，Deployment 并不能编排所有类型的应用，对无状态服务编排是非常容易的，但是对于有状态服务就无能为力了。需要先明白一个概念：什么是有状态服务，什么是无状态服务。

无状态服务（Stateless Service）：该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的，比如WordPress 实例，可以同时启动多个实例，访问任意一个实例得到的结果都是一样，因为它唯一需要持久化的数据是存储在 MySQL 数据库中，所以可以说 WordPress 应用是无状态服务，但是 MySQL 数据库就不是了，因为它需要把数据持久化到本地。
有状态服务（Stateful Service）：就和上面的概念是对立的了，该服务运行的实例需要在本地存储持久化数据，比如上面的 MySQL 数据库，现在运行在节点 A，那么他的数据就存储在节点 A 上面的，如果这个时候把该服务迁移到节点 B 上的话，那么就没有之前的数据了，因为它需要去对应的数据目录里面恢复数据，而此时没有任何数据。

常见的 WEB 应用，是通过 Session 来保持用户的登录状态的，如果将 Session 持久化到节点上，那么该应用就是一个有状态的服务了，因为现在登录成功后 Session 持久化到节点 A 上了，下次登录的时候可能会将请求路由到节点 B 上去了，但是节点 B 上根本就没有当前的 Session 数据，就会被认为是未登录状态了，这样就导致前后两次请求得到的结果不一致了。所以一般为了横向扩展，都会把这类 WEB 应用改成无状态的服务，将 Session 数据存入一个公共的地方，比如 Redis 里面，对于一些客户端请求 API 的情况，就不使用 Session 来保持用户状态，改成用 Token 也是可以的。

无状态服务利用 Deployment 可以很好的进行编排，对于有状态服务，需要考虑的细节就要多很多了，容器化应用程序最困难的任务之一，就是设计有状态分布式组件的部署体系结构。由于无状态组件没有预定义的启动顺序、集群要求、点对点 TCP 连接、唯一的网络标识符、正常的启动和终止要求等，因此可以很容易地进行容器化。诸如数据库，大数据分析系统，分布式 key/value 存储、消息中间件需要有复杂的分布式体系结构，都可能会用到上述功能。为此，Kubernetes 引入了 StatefulSet 这种资源对象来支持这种复杂的需求。StatefulSet 类似于 ReplicaSet，但是它可以处理 Pod 的启动顺序，为保留每个 Pod 的状态设置唯一标识，具有以下几个功能特性：

稳定的、唯一的网络标识符
稳定的、持久化的存储
有序的、优雅的部署和缩放
有序的、优雅的删除和终止
有序的、自动滚动更新

Headless Service#

Service 是应用服务的抽象，通过 Labels 为应用提供负载均衡和服务发现，每个 Service 都会自动分配一个 cluster IP 和 DNS ，在集群内部可以通过该地址或者通过 FDQN 的形式来访问服务。比如，一个 Deployment 有 3 个 Pod，那么就可以定义一个 Service，有如下两种方式来访问这个 Service：

cluster IP 的方式，比如：当我访问 10.109.169.155 这个 Service 的 IP 地址时，10.109.169.155 其实就是一个 VIP，它会把请求转发到该 Service 所代理的 Endpoints 列表中的某一个 Pod 上。
Service 的 DNS 方式，比如我们访问“mysvc.mynamespace.svc.cluster.local”这条 DNS 记录，就可以访问到 mynamespace 这个命名空间下面名为 mysvc 的 Service 所代理的某一个 Pod。

对于 DNS 这种方式实际上也有两种情况：

第一种就是普通的 Service，我们访问“mysvc.mynamespace.svc.cluster.local”的时候是通过集群中的 DNS 服务解析到的 mysvc 这个 Service 的 cluster IP 的
第二种情况就是Headless Service，对于这种情况，我们访问“mysvc.mynamespace.svc.cluster.local”的时候是直接解析到 mysvc 代理的某一个具体的 Pod 的 IP 地址，中间少了 cluster IP 的转发，这就是二者的最大区别，Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 的记录方式解析到后面的 Pod 的 IP 地址。

比如定义一个如下的 Headless Service：(headless-svc.yaml)

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nignx
5
  namespace: default
6
  labels:
7
    app: nginx
8
spec:
9
  selector:
10
    app: nginx
11
  clusterIP: None
12
  ports:
13
    - port: 80
14
      targetPort: 80

实际上 Headless Service 在定义上和普通的 Service 几乎一致, 只是他的 clusterIP=None，所以，这个 Service 被创建后并不会被分配一个 cluster IP，而是会以 DNS 记录的方式暴露出它所代理的 Pod，而且还有一个非常重要的特性，对于 Headless Service 所代理的所有 Pod 的 IP 地址都会绑定一个如下所示的 DNS 记录：

Terminal window

1
<pod-name>.<svc-name>.<namespace>.svc.cluster.local

这个 DNS 记录正是 Kubernetes 集群为 Pod 分配的一个唯一标识，只要知道 Pod 的名字，以及它对应的 Service 名字，就可以组装出这样一条 DNS 记录访问到 Pod 的 IP 地址。

StatefulSet#

先创建两个存储卷(PV).yaml

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: pv001
5
spec:
6
  capacity:
7
    storage: 1Gi
8
  accessModes:
9
    - ReadWriteOnce
10
  hostPath:
11
    path: /tmp/pv001
12
---
13
apiVersion: v1
14
kind: PersistentVolume
15
metadata:
16
  name: pv002
17
spec:
18
  capacity:
19
    storage: 1Gi
20
  accessModes:
21
    - ReadWriteOnce
22
  hostPath:
23
    path: /tmp/pv002

展开收起

直接创建PV:

Terminal window

1
kubectl apply -f pv.yaml

image-20231101172050369

创建了两个 PV 对象，状态是：Available。

特性#

再声明一个 StatefulSet 资源清单：（nginx-sts.yaml）

1
apiVersion: apps/v1
2
kind: StatefulSet
3
metadata:
4
  name: web
5
  namespace: default
6
spec:
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  serviceName: nginx
11
  replicas: 2
12
  template:
13
    metadata:
14
      labels:
15
        app: nginx
16
    spec:
17
      containers:
18
        - name: nginx
19
          image: nginx
20
          ports:
21
            - containerPort: 80
22
              name: web
23
          volumeMounts:
24
            - name: www
25
              mountPath: /usr/share/nginx/html
26
  volumeClaimTemplates:
27
    - metadata:
28
        name: www
29
      spec:
30
        accessModes: ["ReadWriteOnce"]
31
        resources:
32
          requests:
33
            storage: 1Gi

展开收起

从上面的资源清单中可以看出和前面的 Deployment 基本上也是一致的，也是通过声明的 Pod 模板来创建 Pod 的，另外上面资源清单中和 volumeMounts 进行关联的不是 volumes 而是一个新的属性：volumeClaimTemplates，该属性会自动创建一个 PVC 对象，其实这里就是一个 PVC 的模板，和 Pod 模板类似，PVC 被创建后会自动去关联当前系统中和他合适的 PV 进行绑定。除此之外，还多了一个 serviceName: "nginx" 的字段，serviceName 就是管理当前 StatefulSet 的服务名称，该服务必须在 StatefulSet 之前存在，并且负责该集合的网络标识，Pod 会遵循以下格式获取 DNS/主机名：pod-specific-string.serviceName.default.svc.cluster.local，其中 pod-specific-string 由 StatefulSet 控制器管理。

StatefulSet

StatefulSet 的拓扑结构和其他用于部署的资源对象其实比较类似，比较大的区别在于 StatefulSet 引入了 PV 和 PVC 对象来持久存储服务产生的状态，这样所有的服务虽然可以被杀掉或者重启，但是其中的数据由于 PV 的原因不会丢失。

由于我们这里用 volumeClaimTemplates 声明的模板是挂载点的方式，并不是 volume，所有实际上相当于把 PV 的存储挂载到容器中，所以会覆盖掉容器中的数据，在容器启动完成后可以手动在 PV 的存储里面新建 index.html 文件来保证容器的正常访问，当然也可以进入到容器中去创建，这样更加方便：

Terminal window

1
for i in 0 1; do kubectl exec web-$i -- sh -c 'echo hello $(hostname) > /usr/share/nginx/html/index.html'; done

现在我们优先创建上面定义的 Headless Service：

Terminal window

1
kubectl apply -f headless-svc.yaml

Headless Service 创建完成后再创建对应的 StatefulSet 对象：

Terminal window

1
kubectl apply -f nginx-sts.yaml

可以看到这里通过 Volume 模板自动生成了两个 PVC 对象，也自动和 PV 进行了绑定。

仔细观察整个过程出现了两个 Pod：web-0 和 web-1，而且这两个 Pod 是按照顺序进行创建的，web-0 启动起来后 web-1 才开始创建。如同上面 StatefulSet 概念中所提到的，StatefulSet 中的 Pod 拥有一个具有稳定的、独一无二的身份标志。这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。Pod 的名称的形式为<statefulset name>-<ordinal index>。这里的对象拥有两个副本，所以它创建了两个 Pod 名称分别为：web-0 和 web-1，可以使用 kubectl exec 命令进入到容器中查看它们的 hostname：

Terminal window

1
kubectl exec web-0 hostname
2
kubectl exec web-1 hostname

image-20231101174823001

StatefulSet 中 Pod 副本的创建会按照序列号升序处理，副本的更新和删除会按照序列号降序处理。

这两个 Pod 的 hostname 与 Pod 名字是一致的，都被分配了对应的编号。查看一个 Pod 的描述信息：

Terminal window

1
kubectl describe pod web-0 -n default

1
Name:         web-0
2
Namespace:    default
3
Priority:     0
4
Node:         node2/10.168.1.22
5
Start Time:   Wed, 01 Nov 2023 17:37:21 +0800
6
Labels:       app=nginx
7
              controller-revision-hash=web-5f6745bd6f
8
              statefulset.kubernetes.io/pod-name=web-0
9
Annotations:  cni.projectcalico.org/containerID: 6dddce8afd55289006f55c8055f34c98becdef6e9a832959452f80f509ba86e4
10
              cni.projectcalico.org/podIP: 10.233.96.214/32
11
              cni.projectcalico.org/podIPs: 10.233.96.214/32
12
Status:       Running
13
IP:           10.233.96.214
14
IPs:
15
  IP:           10.233.96.214
16
Controlled By:  StatefulSet/web
17
Containers:
18
  nginx:
19
    Container ID:   containerd://6984b45869c0776cfe190c0d90dccde3238a154c39fa8bfb60f90508ac948f81
20
    Image:          nginx
21
    Image ID:       docker.io/library/nginx@sha256:45c1e269ef2eb8cb0fa91f875bb3ba3c7b92cf50b2e19ddc51bef0edabcb4cb6
22
    Port:           80/TCP
23
    Host Port:      0/TCP
24
    State:          Running
25
      Started:      Wed, 01 Nov 2023 17:37:24 +0800
26
    Ready:          True
27
    Restart Count:  0
28
    Environment:    <none>
29
    Mounts:
30
      /usr/share/nginx/html from www (rw)
31
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rzkfr (ro)
32
Conditions:
33
  Type              Status
34
  Initialized       True
35
  Ready             True
36
  ContainersReady   True
37
  PodScheduled      True
38
Volumes:
39
  www:
40
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
41
    ClaimName:  www-web-0
42
    ReadOnly:   false
43
  kube-api-access-rzkfr:
44
    Type:                    Projected (a volume that contains injected data from multiple sources)
45
    TokenExpirationSeconds:  3607
46
    ConfigMapName:           kube-root-ca.crt
47
    ConfigMapOptional:       <nil>
48
    DownwardAPI:             true
49
QoS Class:                   BestEffort
50
Node-Selectors:              <none>
51
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
52
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
53
Events:
54
  Type    Reason     Age   From               Message
55
  ----    ------     ----  ----               -------
56
  Normal  Scheduled  11m   default-scheduler  Successfully assigned default/web-0 to node2
57
  Normal  Pulling    11m   kubelet            Pulling image "nginx"
58
  Normal  Pulled     11m   kubelet            Successfully pulled image "nginx" in 1.964723252s
59
  Normal  Created    11m   kubelet            Created container nginx
60
  Normal  Started    11m   kubelet            Started container nginx

展开收起

可以看到Controlled By: StatefulSet/web，证明 Pod 是直接受到 StatefulSet 控制器管理的。

现在创建一个 busybox（该镜像中有一系列的工具）的容器，在容器中用 DNS 的方式来访问一下这个 Headless Service，由于这里只是单纯的为了测试，所以没必要写资源清单文件来声明，用kubectl run命令启动一个测试的容器即可：

Terminal window

1
kubectl run -it --image busybox:1.28.3 test --restart=Never --rm /bin/sh

这里使用 kubectl run 命令启动了一个以 busybox 为镜像的 Pod，--rm 参数意味着退出 Pod 后就会被删除，和之前的 docker run 命令用法基本一致，现在在这个 Pod 容器里面可以使用 nslookup 命令来尝试解析下上面我们创建的 Headless Service。

Terminal window

1
# nslookup nginx
2
Server:    10.96.0.10
3
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
4

5
Name:      nginx
6
Address 1: 10.244.1.175 web-1.nginx.default.svc.cluster.local
7
Address 2: 10.244.4.83 web-0.nginx.default.svc.cluster.local
8
/ # ping nginx
9
PING nginx (10.244.1.175): 56 data bytes
10
64 bytes from 10.244.1.175: seq=0 ttl=62 time=1.076 ms
11
64 bytes from 10.244.1.175: seq=1 ttl=62 time=1.029 ms
12
64 bytes from 10.244.1.175: seq=2 ttl=62 time=1.075 ms

直接解析 Headless Service 的名称，可以看到得到的是两个 Pod 的解析记录，但实际上如果通过nginx这个 DNS 去访问服务的话，并不会随机或者轮询背后的两个 Pod，而是访问到一个固定的 Pod，所以不能代替普通的 Service。如果分别解析对应的 Pod 呢？

Terminal window

1
$ / # nslookup web-0.nginx
2
Server:    10.96.0.10
3
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
4

5
Name:      web-0.nginx
6
Address 1: 10.244.4.83 web-0.nginx.default.svc.cluster.local
7
/ # nslookup web-1.nginx
8
Server:    10.96.0.10
9
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
10

11
Name:      web-1.nginx
12
Address 1: 10.244.1.175 web-1.nginx.default.svc.cluster.local

可以看到解析 web-0.nginx 的时候解析到了 web-0 这个 Pod 的 IP，web-1.nginx 解析到了 web-1 这个 Pod 的 IP，而且这个 DNS 地址还是稳定的，因为 Pod 名称就是固定的，这个时候删掉 web-0 和 web-1 这两个 Pod：

Terminal window

1
kubectl delete pod -l app=nginx
2
pod "web-0" deleted
3
pod "web-1" deleted

删除完成后才看 Pod 状态：

Terminal window

1
kubectl get pods -l app=nginx
2
NAME    READY   STATUS    RESTARTS   AGE
3
web-0   1/1     Running   0          42s
4
web-1   1/1     Running   0          39s

可以看到 StatefulSet 控制器仍然会安装顺序创建出两个 Pod 副本出来，而且 Pod 的唯一标识依然没变，所以这两个 Pod 的网络标识还是固定的，依然可以通过web-0.nginx去访问到web-0这个 Pod，虽然 Pod 已经重建了，对应 Pod IP 已经变化了，但是访问这个 Pod 的地址依然没变，并且它们依然还是关联的之前的 PVC，数据并不会丢失：

Terminal window

1
/ # nslookup web-0.nginx
2
Server:    10.96.0.10
3
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
4

5
Name:      web-0.nginx
6
Address 1: 10.244.3.98 web-0.nginx.default.svc.cluster.local
7
/ # nslookup web-1.nginx
8
Server:    10.96.0.10
9
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
10

11
Name:      web-1.nginx
12
Address 1: 10.244.1.176 web-1.nginx.default.svc.cluster.local

通过 Headless Service，StatefulSet 就保证了 Pod 网络标识的唯一稳定性，由于 Pod IP 并不是固定的，所以访问有状态应用实例的时候，就必须使用 DNS 记录的方式来访问了，所以偶尔有固定的 Pod IP 的需求，或许可以用这种方式来代替。

最后可以通过删除 StatefulSet 对象来删除所有的 Pod，仔细观察也会发现是按照倒序的方式进行删除的：

Terminal window

1
kubectl delete statefulsets web
2
statefulset.apps "web" deleted
3

4
kubectl get pods --watch
5
NAME    READY   STATUS    RESTARTS   AGE
6
web-1   1/1   Terminating   0     3h/31m
7
web-0   1/1   Terminating   0     3h/31m

管理策略#

对于某些分布式系统来说，StatefulSet 的顺序性保证是不必要或者不应该的，这些系统仅仅要求唯一性和身份标志。为了解决这个问题，只需要在声明 StatefulSet 的时候重新设置 spec.podManagementPolicy 的策略即可。

默认的管理策略是 OrderedReady，表示让 StatefulSet 控制器遵循上文演示的顺序性保证。除此之外，还可以设置为 Parallel 管理模式，表示让 StatefulSet 控制器并行的终止所有 Pod，在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。

更新策略#

在 StatefulSet 中支持两种升级策略：onDelete 和 RollingUpdate，同样可以通过设置 .spec.updateStrategy.type 进行指定。

OnDelete: 该策略表示当更新了 StatefulSet 的模板后，只有手动删除旧的 Pod 才会创建新的 Pod。
RollingUpdate：该策略表示当更新 StatefulSet 模板后会自动删除旧的 Pod 并创建新的 Pod，如果更新发生了错误，这次“滚动更新”就会停止。不过需要注意 StatefulSet 的 Pod 在部署时是顺序从 0n 的，而在滚动更新时，这些 Pod 则是按逆序的方式即 n0 一次删除并创建。

另外SatefulSet 的滚动升级还支持 Partitions的特性，可以通过.spec.updateStrategy.rollingUpdate.partition 进行设置，在设置 partition 后，SatefulSet 的 Pod 中序号大于或等于 partition 的 Pod 会在 StatefulSet 的模板更新后进行滚动升级，而其余的 Pod 保持不变，这个功能是不是可以实现灰度发布？可以去手动验证下。

在实际的项目中，其实还是很少会去直接通过 StatefulSet 来部署有状态服务的，对于一些特定的服务，可能会使用更加高级的 Operator 来部署，比如 etcd-operator、prometheus-operator 等等，这些应用都能够很好的来管理有状态的服务，而不是单纯的使用一个 StatefulSet 来部署一个 Pod 就行，因为对于有状态的应用最重要的还是数据恢复、故障转移等等。

Kubernetes-Deployment控制器

Tue, 31 Oct 2023 00:00:00 GMT

通过前面的 ReplicaSet 控制器，了解到ReplicaSet控制器是用来维护集群中运行的 Pod 数量的，但是往往在实际操作的时候，不会去直接使用 RS，而是会使用更上层的控制器，比如Deployment，Deployment 一个非常重要的功能就是实现了 Pod 的滚动更新，比如应用更新了，只需要更新容器镜像，然后修改 Deployment 里面的 Pod 模板镜像，那么 Deployment 就会用滚动更新（Rolling Update）的方式来升级现在的 Pod，这个能力是非常重要的，因为对于线上的服务需要做到不中断服务，所以滚动更新就成了必须的一个功能。而 Deployment 这个能力的实现，依赖的就是 ReplicaSet 这个资源对象，可以通俗的理解就是每个 Deployment 就对应集群中的一次部署，这样就更好理解了。

Deployment概述#

Deployment 资源对象的格式和 ReplicaSet 几乎一致，如下资源对象就是一个常见的 Deployment 资源类型：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deployment
5
  namespace: default
6
spec:
7
  replicas: 3
8
  selector:
9
    matchLabels:
10
      app: nginx
11
  template:
12
    metadata:
13
      labels:
14
        app: nginx
15
    spec:
16
      containers:
17
        - name: nginx
18
          image: nginx
19
          resources:
20
            limits:
21
              memory: "128Mi"
22
              cpu: "500m"
23
          ports:
24
            - containerPort: 80

展开收起

这里只是将类型替换成了 Deployment，先创建下这个资源对象：

Terminal window

1
kubectl apply -f nginx-deploy.yaml

创建完成后查看Pod状态:

Terminal window

1
kubectl get pod -n default -l app=nginx

image-20231031170428299

到这里发现和之前的 RS 对象似乎没有什么两样，都是根据spec.replicas来维持的副本数量，随意查看一个 Pod 的描述信息：

Terminal window

1
kubectl describe pod nginx-deployment-67d4bdd6f5-fcjlc -n default

1
Name:         nginx-deployment-67d4bdd6f5-fcjlc
2
Namespace:    default
3
Priority:     0
4
Node:         node3/10.168.1.23
5
Start Time:   Tue, 31 Oct 2023 17:03:32 +0800
6
Labels:       app=nginx
7
              pod-template-hash=67d4bdd6f5
8
Annotations:  cni.projectcalico.org/containerID: f7f32f957b7738e370941edff7ed5064ab0253287a2b8e237240bb1523a1c4c6
9
              cni.projectcalico.org/podIP: 10.233.92.110/32
10
              cni.projectcalico.org/podIPs: 10.233.92.110/32
11
Status:       Running
12
IP:           10.233.92.110
13
IPs:
14
  IP:           10.233.92.110
15
Controlled By:  ReplicaSet/nginx-deployment-67d4bdd6f5
16
Containers:
17
  nginx:
18
    Container ID:   containerd://c2e97a02a379cd8f0ec8cad42ca87e25bece7b1fd9de33b07217d89b1a082d97
19
    Image:          nginx
20
    Image ID:       docker.io/library/nginx@sha256:add4792d930c25dd2abf2ef9ea79de578097a1c175a16ab25814332fe33622de
21
    Port:           80/TCP
22
    Host Port:      0/TCP
23
    State:          Running
24
      Started:      Tue, 31 Oct 2023 17:03:35 +0800
25
    Ready:          True
26
    Restart Count:  0
27
    Limits:
28
      cpu:     500m
29
      memory:  128Mi
30
    Requests:
31
      cpu:        500m
32
      memory:     128Mi
33
    Environment:  <none>
34
    Mounts:
35
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-2jd4f (ro)
36
Conditions:
37
  Type              Status
38
  Initialized       True
39
  Ready             True
40
  ContainersReady   True
41
  PodScheduled      True
42
Volumes:
43
  kube-api-access-2jd4f:
44
    Type:                    Projected (a volume that contains injected data from multiple sources)
45
    TokenExpirationSeconds:  3607
46
    ConfigMapName:           kube-root-ca.crt
47
    ConfigMapOptional:       <nil>
48
    DownwardAPI:             true
49
QoS Class:                   Guaranteed
50
Node-Selectors:              <none>
51
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
52
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
53
Events:
54
  Type    Reason     Age   From               Message
55
  ----    ------     ----  ----               -------
56
  Normal  Scheduled  2m6s  default-scheduler  Successfully assigned default/nginx-deployment-67d4bdd6f5-fcjlc to node3
57
  Normal  Pulling    2m5s  kubelet            Pulling image "nginx"
58
  Normal  Pulled     2m3s  kubelet            Successfully pulled image "nginx" in 1.923662815s
59
  Normal  Created    2m3s  kubelet            Created container nginx
60
  Normal  Started    2m3s  kubelet            Started container nginx

展开收起

仔细查看其中有这样一个信息 Controlled By: ReplicaSet/nginx-deployment-67d4bdd6f5，表示当前这个 Pod 的控制器是一个 ReplicaSet 对象，不是创建的一个 Deployment 吗？为什么 Pod 会被 RS 所控制呢？再去看下这个对应的 RS 对象的详细信息如何呢：

Terminal window

1
kubectl describe rs nginx-deployment-67d4bdd6f5 -n default

1
Name:           nginx-deployment-67d4bdd6f5
2
Namespace:      default
3
Selector:       app=nginx,pod-template-hash=67d4bdd6f5
4
Labels:         app=nginx
5
                pod-template-hash=67d4bdd6f5
6
Annotations:    deployment.kubernetes.io/desired-replicas: 3
7
                deployment.kubernetes.io/max-replicas: 4
8
                deployment.kubernetes.io/revision: 1
9
Controlled By:  Deployment/nginx-deployment
10
Replicas:       3 current / 3 desired
11
Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
12
Pod Template:
13
  Labels:  app=nginx
14
           pod-template-hash=67d4bdd6f5
15
  Containers:
16
   nginx:
17
    Image:      nginx
18
    Port:       80/TCP
19
    Host Port:  0/TCP
20
    Limits:
21
      cpu:        500m
22
      memory:     128Mi
23
    Environment:  <none>
24
    Mounts:       <none>
25
  Volumes:        <none>
26
Events:
27
  Type    Reason            Age   From                   Message
28
  ----    ------            ----  ----                   -------
29
  Normal  SuccessfulCreate  5m9s  replicaset-controller  Created pod: nginx-deployment-67d4bdd6f5-wwql8
30
  Normal  SuccessfulCreate  5m9s  replicaset-controller  Created pod: nginx-deployment-67d4bdd6f5-fcjlc
31
  Normal  SuccessfulCreate  5m9s  replicaset-controller  Created pod: nginx-deployment-67d4bdd6f5-nd8fl

展开收起

其中有这样的一个信息：Controlled By: Deployment/nginx-deploy，意思就是 Pod 依赖的控制器 RS 实际上被 Deployment 控制着，可以用下图来说明 Pod、ReplicaSet、Deployment 三者之间的关系：

Deployment

通过上图可以很清楚的看到，定义了 3 个副本的 Deployment 与 ReplicaSet 和 Pod 的关系，就是一层一层进行控制的。ReplicaSet 作用和之前一样还是来保证 Pod 的个数始终保存指定的数量，所以 Deployment 中的容器 restartPolicy=Always 是唯一的就是这个原因，因为容器必须始终保证自己处于 Running 状态，ReplicaSet 才可以去明确调整 Pod 的个数。而 Deployment 是通过管理 ReplicaSet 的数量和属性来实现水平扩展/收缩以及滚动更新两个功能的。

水平伸缩#

水平扩展/收缩的功能比较简单，因为 ReplicaSet 就可以实现，所以 Deployment 控制器只需要去修改它缩控制的 ReplicaSet 的 Pod 副本数量就可以了。比如把 Pod 的副本调整到 4 个，那么 Deployment 所对应的 ReplicaSet 就会自动创建一个新的 Pod 出来，这样就水平扩展了，可以使用一个命令kubectl scale 命令来完成这个操作：

Terminal window

1
kubectl scale deployment nginx-deployment -n default --replicas=4

Terminal window

1
kubectl get rs -n default

image-20231031171315023

滚动更新#

如果只是水平扩展/收缩这两个功能，就完全没必要设计 Deployment 这个资源对象了，Deployment 最突出的一个功能是支持滚动更新，比如现在需要把应用容器更改为 nginx:1.20 版本，修改后的资源清单文件如下所示：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deployment
5
  namespace: default
6
spec:
7
  replicas: 3
8
  selector:
9
    matchLabels:
10
      app: nginx
11
  minReadySeconds: 5
12
  strategy:
13
    type: RollingUpdate
14
    rollingUpdate:
15
      maxSurge: 1
16
      maxUnavailable: 1
17
  template:
18
    metadata:
19
      labels:
20
        app: nginx
21
    spec:
22
      containers:
23
        - name: nginx
24
          image: nginx:1.20
25
          resources:
26
            limits:
27
              memory: "128Mi"
28
              cpu: "500m"
29
          ports:
30
            - containerPort: 80

展开收起

1
minReadySeconds: 5
2
strategy:
3
  type: RollingUpdate
4
  rollingUpdate:
5
    maxSurge: 1
6
    maxUnavailable: 1

minReadySeconds：表示 Kubernetes 在等待设置的时间后才进行升级，如果没有设置该值，Kubernetes 会假设该容器启动起来后就提供服务了，如果没有设置该值，在某些极端情况下可能会造成服务不正常运行，默认值就是 0。
type=RollingUpdate：表示设置更新策略为滚动更新，可以设置为Recreate和RollingUpdate两个值，Recreate表示全部重新创建，默认值就是RollingUpdate。
maxSurge：表示升级过程中最多可以比原先设置多出的 Pod 数量，例如：maxSurage=1，replicas=5，就表示 Kubernetes 会先启动一个新的 Pod，然后才删掉一个旧的 Pod，整个升级过程中最多会有5+1个 Pod。
maxUnavaible：表示升级过程中最多有多少个 Pod 处于无法提供服务的状态，当maxSurge不为 0 时，该值也不能为 0，例如：maxUnavaible=1，则表示 Kubernetes 整个升级过程中最多会有 1 个 Pod 处于无法服务的状态。

更新上面的 Deployment 资源对象：可以添加了一个额外的 --record 参数来记录下我们的每次操作所执行的命令，以方便后面查看。

Terminal window

1
kubectl apply -f nginx-deploy.yaml

更新后，可以执行下面的 kubectl rollout status 命令来查看我们此次滚动更新的状态

还可以执行如下的命令来暂停更新：

Terminal window

1
kubectl rollout pause deployment/nginx-deploy -n default

执行下面的命令恢复更新

Terminal window

1
kubectl rollout resume deployment/nginx-deploy -n default

这个时候我们的滚动更新就暂停了，此时我们可以查看下 Deployment 的详细信息：

Terminal window

1
kubectl describe deployment nginx-deployment -n default

image-20231031172846974

Deployment RollingUpdate

仔细观察 Events 事件区域的变化，上面用 kubectl scale 命令将 Pod 副本调整到了 4，现在更新的时候是不是声明又变成 3 了，所以 Deployment 控制器首先是将之前控制的 nginx-deployment-67d4bdd6f5 这个 RS 资源对象进行缩容操作，然后滚动更新开始了，可以发现 Deployment 为一个新的 nginx-deployment-7d745cff58 RS 资源对象首先新建了一个新的 Pod，然后将之前的 RS 对象缩容到 2 了，再然后新的 RS 对象扩容到 2，这个过程就是滚动更新的过程，启动一个新的 Pod，杀掉一个旧的 Pod，然后再启动一个新的 Pod，这样滚动更新下去，直到全都变成新的 Pod，这个时候系统中应该存在 4 个 Pod，因为设置的策略maxSurge=1，所以在升级过程中是允许的，而且是两个新的 Pod，两个旧的 Pod。

Terminal window

1
kubectl get rs -n default

image-20231031173335133

从上面可以看出滚动更新之前使用的 RS 资源对象的 Pod 副本数已经变成 0 了，而滚动更新后的 RS 资源对象变成了 3 个副本，可以导出之前的 RS 对象查看：

Terminal window

1
kubectl get rs nginx-deployment-67d4bdd6f5 -o yaml

1
apiVersion: apps/v1
2
kind: ReplicaSet
3
metadata:
4
  annotations:
5
    deployment.kubernetes.io/desired-replicas: "3"
6
    deployment.kubernetes.io/max-replicas: "4"
7
    deployment.kubernetes.io/revision: "1"
8
  creationTimestamp: "2023-10-31T09:03:32Z"
9
  generation: 5
10
  labels:
11
    app: nginx
12
    pod-template-hash: 67d4bdd6f5
13
  name: nginx-deployment-67d4bdd6f5
14
  namespace: default
15
  ownerReferences:
16
  - apiVersion: apps/v1
17
    blockOwnerDeletion: true
18
    controller: true
19
    kind: Deployment
20
    name: nginx-deployment
21
    uid: 2d833e78-bc5f-4f59-9057-028152ee70ce
22
  resourceVersion: "409993"
23
  uid: 2c5d1622-1e05-4239-8586-8b6b33e267cf
24
spec:
25
  replicas: 0
26
  selector:
27
    matchLabels:
28
      app: nginx
29
      pod-template-hash: 67d4bdd6f5
30
  template:
31
    metadata:
32
      creationTimestamp: null
33
      labels:
34
        app: nginx
35
        pod-template-hash: 67d4bdd6f5
36
    spec:
37
      containers:
38
      - image: nginx
39
        imagePullPolicy: Always
40
        name: nginx
41
        ports:
42
        - containerPort: 80
43
          protocol: TCP
44
        resources:
45
          limits:
46
            cpu: 500m
47
            memory: 128Mi
48
        terminationMessagePath: /dev/termination-log
49
        terminationMessagePolicy: File
50
      dnsPolicy: ClusterFirst
51
      restartPolicy: Always
52
      schedulerName: default-scheduler
53
      securityContext: {}
54
      terminationGracePeriodSeconds: 30
55
status:
56
  observedGeneration: 5
57
  replicas: 0

展开收起

仔细观察这个资源对象里面的描述信息除了副本数变成了 replicas=0 之外，和更新之前没有什么区别。有了这个 RS 的记录存在，就可以回滚了。而且还可以回滚到前面的任意一个版本，这个版本是如何定义的呢？可以通过命令 rollout history 来获取：

Terminal window

1
kubectl rollout history deployment nginx-deployment -n default

image-20231031174352623

其实 rollout history 中记录的 revision 是和 ReplicaSets 一一对应。如果手动删除某个 ReplicaSet，对应的rollout history就会被删除，也就无法回滚到这个revison了，同样还可以查看一个revison的详细信息：

Terminal window

1
kubectl rollout history deployment nginx-deployment -n default --revision=1

image-20231031174553069

要直接回退到当前版本的前一个版本，可以直接使用如下命令进行操作：

Terminal window

1
kubectl rollout undo deployment nginx-deployment -n default

也可以回退到指定的revision版本：

Terminal window

1
kubectl rollout undo deployment nginx-deployment -n default --to-revision=1

回滚的过程中我们同样可以查看回滚状态：

Terminal window

1
kubectl rollout status deployment/nginx-deployment -n default

image-20231031174755427

这个时候查看对应的 RS 资源对象可以看到 Pod 副本已经回到之前的 RS 里面去了:

Terminal window

1
kubectl get rs -n default -l app=nginx

image-20231031174829165

不过需要注意的是回滚的操作滚动的revision始终是递增的：

Terminal window

1
kubectl rollout history deployment nginx-deployment -n default

image-20231031174939152

在很早之前的 Kubernetes 版本中，默认情况下会暴露下所有滚动升级的历史记录，也就是 ReplicaSet 对象，但一般情况下没必要保留所有的版本，毕竟会存在 etcd 中，可以通过配置 spec.revisionHistoryLimit 属性来设置保留的历史记录数量，不过新版本中该值默认为 10，如果希望多保存几个版本可以设置该字段。

Kubernetes-Downward API

Tue, 31 Oct 2023 00:00:00 GMT

作为 Kubernetes 中最核心的资源对象、最基本的调度单元，可以发现 Pod 中的属性还是非常繁多的，前面使用过一个 volumes 的属性，表示声明一个数据卷，可以通过命令kubectl explain pod.spec.volumes去查看该对象下面的属性非常多，前面只是简单使用了 hostPath 和 emptyDir{} 这两种模式，其中还有一种模式叫做downward API，这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 Pod 里的容器能够直接获取到这个 Pod 对象本身的一些信息。

目前 Downward API 提供了两种方式用于将 Pod 的信息注入到容器内部：

环境变量：用于单个变量，可以将 Pod 信息和容器信息直接注入容器内部
Volume 挂载：将 Pod 信息生成为文件，直接挂载到容器内部中去

环境变量#

通过 Downward API 来将 Pod 的 IP、名称以及所对应的 namespace 注入到容器的环境变量中去，然后在容器中打印全部的环境变量来进行验证，对应资源清单文件如下：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: env-pod
5
  namespce: kube-system
6
spec:
7
  containers:
8
    - name: env-pod
9
      image: busybox
10
      command:
11
        - /bin/sh
12
        - -c
13
        - env
14
      env:
15
        - name: POD_NAME
16
          valueFrom:
17
            fieldRef:
18
              fieldPath: metadate.name
19
        - name: POD_NAMESPACE
20
          valueFrom:
21
            fieldRef:
22
              fieldPath: metadata.name
23
        - name: POD_IP
24
          valueFrom:
25
            fieldRef:
26
              fieldPath: status.podIP
27
      resources:
28
        limits:
29
          memory: "128Mi"
30
          cpu: "500m"

展开收起

上面使用了一种新的方式来设置 env 的值：valueFrom，由于 Pod 的 name 和 namespace 属于元数据，是在 Pod 创建之前就已经定下来了的，所以可以使用 metata 就可以获取到了，但是对于 Pod 的 IP 则不一样，因为 Pod IP 是不固定的，Pod 重建了就变了，它属于状态数据，所以使用 status 这个属性去获取。另外除了使用 fieldRef获取 Pod 的基本信息外，还可以通过 resourceFieldRef 去获取容器的资源请求和资源限制信息。

创建上面的Pod:

Terminal window

1
kubectl apply -f env-pod.yaml

Terminal window

1
kubectl logs env-pod -n kube-system |grep POD

Terminal window

1
kubectl logs env-pod -n kube-system

image-20231031110701074

上面打印 Pod 的环境变量可以看到有很多内置的变量，其中大部分是系统自动添加的，Kubernetes 会把当前命名空间下面的 Service 信息通过环境变量的形式注入到 Pod 中去

Volume挂载#

Downward API除了提供环境变量的方式外，还提供了通过 Volume 挂载的方式去获取 Pod 的基本信息。通过Downward API将 Pod 的 Label、Annotation 等信息通过 Volume 挂载到容器的某个文件中去，然后在容器中打印出该文件的值来验证，对应的资源清单文件如下所示：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: volume-pod
5
  namespace: kube-system
6
  labels:
7
    k8s-app: test-volume
8
    node-env: test
9
  annotations:
10
    own: tianch
11
    build: test
12
spec:
13
  volumes:
14
    - name: podinfo
15
      downwardAPI:
16
        items:
17
          - path: labels
18
            fieldRef:
19
              fieldPath: namespace.labels
20
          - path: annotations
21
            fieldRef:
22
              fieldPath: metadata.annotations
23
  containers:
24
    - name: volume-pod
25
      image: busybox
26
      args:
27
        - sleep
28
        - "3600"
29
      volumeMounts:
30
        - name: podinfo
31
          mountPath: /etc/podinfo
32
      resources:
33
        limits:
34
          memory: "128Mi"
35
          cpu: "500m"

展开收起

将元数据 labels 和 annotaions 以文件的形式挂载到了 /etc/podinfo 目录下，创建上面的 Pod：

Terminal window

1
kubectl apply -f volume-pod.yaml

创建成功后，进入到容器中查看元信息是不是已经存入到文件中：

Terminal window

1
kubectl exec -it volume-pod /bin/sh -n kube-system

image-20231031141338407

可以看到 Pod 的 Labels 和 Annotations 信息都被挂载到容器的 /etc/podinfo 目录下面的 lables 和 annotations 文件了。

目前，Downward API 支持的字段已经非常丰富了，比如：

Terminal window展开收起

1
1. 使用 fieldRef 可以声明使用:
2

3
spec.nodeName - 宿主机名字
4
status.hostIP - 宿主机IP
5
metadata.name - Pod的名字
6
metadata.namespace - Pod的Namespace
7
status.podIP - Pod的IP
8
spec.serviceAccountName - Pod的Service Account的名字
9
metadata.uid - Pod的UID
10
metadata.labels['<KEY>'] - 指定<KEY>的Label值
11
metadata.annotations['<KEY>'] - 指定<KEY>的Annotation值
12
metadata.labels - Pod的所有Label
13
metadata.annotations - Pod的所有Annotation
14

15
2. 使用 resourceFieldRef 可以声明使用:
16

17
容器的 CPU limit
18
容器的 CPU request
19
容器的 memory limit
20
容器的 memory request

展开收起

需要注意的是，Downward API 能够获取到的信息，一定是 Pod 里的容器进程启动之前就能够确定下来的信息。如果想要获取 Pod 容器运行后才会出现的信息，比如，容器进程的 PID，那就肯定不能使用 Downward API 了，而应该考虑在 Pod 里定义一个 sidecar 容器来获取了。

在实际应用中，如果应用有获取 Pod 的基本信息的需求，一般可以利用Downward API来获取基本信息，然后编写一个启动脚本或者利用initContainer将 Pod 的信息注入到容器中去，然后在应用中就可以正常的处理相关逻辑了。

除了通过 Downward API 可以获取到 Pod 本身的信息之外，其实我们还可以通过映射其他资源对象来获取对应的信息，比如 Secret、ConfigMap 资源对象，同样可以通过环境变量和挂载 Volume 的方式来获取它们的信息，但是，通过环境变量获取这些信息的方式，不具备自动更新的能力。所以，一般情况下，都建议使用 Volume 文件的方式获取这些信息，因为通过 Volume 的方式挂载的文件在 Pod 中会进行热更新。

Kubernetes-静态Pod

Tue, 31 Oct 2023 00:00:00 GMT

在 Kubernetes 集群中除了经常使用到的普通的 Pod 外，还有一种特殊的 Pod，叫做Static Pod，也就是静态Pod，静态Pod有什么特殊的地方呢？

静态 Pod 直接由节点上的 kubelet 进程来管理，不通过 master 节点上的 apiserver。无法与常用的控制器 Deployment 或者 DaemonSet 进行关联，它由 kubelet 进程自己来监控，当 pod 崩溃时会重启该pod，kubelet 也无法对他们进行健康检查。静态 pod 始终绑定在某一个 kubelet 上，并且始终运行在同一个节点上。kubelet会自动为每一个静态 pod 在 Kubernetes 的 apiserver 上创建一个镜像 Pod，因此可以在 apiserver 中查询到该pod，但是不能通过 apiserver 进行控制（例如不能删除）。

创建静态 Pod 有两种方式：配置文件和 HTTP 两种方式

配置文件

配置文件就是放在特定目录下的标准的 JSON 或 YAML 格式的 pod 定义文件。用 kubelet --pod-manifest-path=<the directory>来启动 kubelet 进程，kubelet 定期的去扫描这个目录，根据这个目录下出现或消失的 YAML/JSON 文件来创建或删除静态 pod。

比如在 node1 这个节点上用静态 pod 的方式来启动一个 nginx 的服务，配置文件路径为：

Terminal window

1
cat /var/lib/kubelet/config.yaml

image-20231030180348902

打开这个文件可以看到其中有一个属性为 staticPodPath 的配置，其实和命令行的 --pod-manifest-path 配置是一致的，所以如果通过 kubeadm 的方式来安装的集群环境，对应的 kubelet 已经配置了静态 Pod 文件的路径，默认地址为 /etc/kubernetes/manifests，所以只需要在该目录下面创建一个标准的 Pod 的 JSON 或者 YAML 文件即可，如果kubelet 启动参数中没有配置上面的--pod-manifest-path 参数的话，那么添加上这个参数然后重启 kubelet 即可。

Terminal window展开收起

1
cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: static-web
6
  labels:
7
    app: static
8
spec:
9
  containers:
10
    - name: web
11
      image: nginx
12
      ports:
13
        - name: web
14
          containerPort: 80
15
EOF

展开收起

通过 HTTP 创建静态 Pods

kubelet 周期地从 –manifest-url= 参数指定的地址下载文件，并且把它翻译成 JSON/YAML 格式的 pod 定义。此后的操作方式与–pod-manifest-path= 相同，kubelet 会不时地重新下载该文件，当文件变化时对应地终止或启动静态 pod。

kubelet 启动时，由 --pod-manifest-path= 或 --manifest-url= 参数指定的目录下定义的所有 pod 都会自动创建，例如，示例中的 static-web。

image-20231030181002778

image-20231030181118103

可以看到这里创建了一个新的镜像 Pod：

Terminal window

1
kubectl get pods

静态 pod 的标签会传递给镜像 Pod，可以用来过滤或筛选。需要注意的是，不能通过 API 服务器来删除静态 pod（例如，通过kubectl命令），kubelet 不会删除它。

Terminal window

1
kubectl delete pod static-web-node1 -n default

image-20231030181417585

静态 Pod 的动态增加和删除

运行中的 kubelet 周期扫描配置的目录（这个例子中就是 /etc/kubernetes/manifests）下文件的变化，当这个目录中有文件出现或消失时创建或删除 pods：

Terminal window

1
mv /etc/kubernetes/manifests/static-web.yaml /tmp

Terminal window

1
crictl ps

Terminal window

1
mv /tmp/static-web.yaml  /etc/kubernetes/manifests

Terminal window

1
crictl ps

image-20231030181724270

用 kubeadm 安装的集群，master 节点上面的几个重要组件都是用静态 Pod 的方式运行的，登录到 master 节点上查看/etc/kubernetes/manifests目录：

Terminal window

1
ls /etc/kubernetes/manifests
2
etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

现在明白了吧，这种方式将集群的一些组件容器化提供了可能，因为这些 Pod 都不会受到 apiserver 的控制，不然这里kube-apiserver怎么自己去控制自己呢？万一不小心把这个 Pod 删掉了呢？所以只能有kubelet自己来进行控制，这就是静态 Pod。

Kubernetes-Pod资源配置

Tue, 31 Oct 2023 00:00:00 GMT

实际上上面几个步骤就是影响一个 Pod 生命周期的大的部分，但是还有一些细节也会在 Pod 的启动过程进行设置，比如在容器启动之前还会为当前的容器设置分配的 CPU、内存等资源，可以通过 CGroup 来对容器的资源进行限制，同样的，在 Pod 中也可以直接配置某个容器的使用的 CPU 或者内存的上限。那么 Pod 是如何来使用和控制这些资源的分配的呢？

首先对于 CPU，计算机里 CPU 的资源是按“时间片”的方式来进行分配的，系统里的每一个操作都需要 CPU 的处理，所以，哪个任务要是申请的 CPU 时间片越多，那么它得到的 CPU 资源就越多，这个很容器理解。

然后还需要了解下 CGroup 里面对于 CPU 资源的单位换算：

Terminal window

1
1 CPU =  1000 millicpu（1 Core = 1000m）
2
0.5 CPU = 500 millicpu （0.5 Core = 500m）

这里的 m 就是毫、毫核的意思，Kubernetes 集群中的每一个节点可以通过操作系统的命令来确认本节点的 CPU 内核数量，然后将这个数量乘以1000，得到的就是节点总 CPU 总毫数。比如一个节点有四核，那么该节点的 CPU 总毫量为 4000m，如果你要使用0.5 core，则你要求的是 4000*0.5 = 2000m。在 Pod 里面我们可以通过下面的两个参数来限制和请求 CPU 资源：

spec.containers[].resources.limits.cpu：CPU 上限值，可以短暂超过，容器也不会被停止
spec.containers[].resources.requests.cpu：CPU请求值，Kubernetes 调度算法里的依据值，可以超过

这里需要明白的是，如果 resources.requests.cpu 设置的值大于集群里每个节点的最大 CPU 核心数，那么这个 Pod 将无法调度，因为没有节点能满足它。

到这里应该明白了，requests 是用于集群调度使用的资源，而 limits 才是真正的用于资源限制的配置，如果需要保证的你应用优先级很高，也就是资源吃紧的情况下最后再杀掉你的 Pod，那么你就把 requests 和 limits 的值设置成一致。

定义一个 Pod，给容器的配置如下的资源:

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: resource-demo1
5
spec:
6
  containers:
7
    - name: resource-demo1
8
      image: nginx
9
      ports:
10
        - containerPort: 80
11
      resources:
12
        requests:
13
          memory: 50Mi
14
          cpu: 50m
15
        limits:
16
          memory: 100Mi
17
          cpu: 100m

展开收起

这里，CPU 给的是 50m，也就是 0.05core，这 0.05core 也就是占了 1 CPU 里的 5% 的资源时间。而限制资源是给的是 100m，但是需要注意的是 CPU 资源是可压缩资源，也就是容器达到了这个设定的上限后，容器性能会下降，但是不会终止或退出。比如直接创建上面这个 Pod：

Terminal window

1
kubectl apply -f pod-resource-demo1.yaml

创建完成后，我们可以看到 Pod 被调度到 node2 这个节点上：

Terminal window

1
[root@master ~]# kubectl get pods -n default -o wide
2
NAME             READY   STATUS    RESTARTS   AGE     IP              NODE    NOMINATED NODE   READINESS GATES
3
resource-demo1   1/1     Running   0          2m34s   10.233.96.108   node2   <none>           <none>

然后我们到 node2 节点上去查看 Pod 里面启动的 resource-demo1 这个容器。

image-20231030173944436

实际上我们就可以看到这个容器的一些资源情况，Pod 上的资源配置最终也还是通过底层的容器运行时去控制 CGroup 来实现的，进入如下目录查看 CGroup 的配置，该目录就是 CGroup 父级目录，而 CGroup 是通过文件系统来进行资源限制的，所以上面限制容器的资源就可以在该目录下面反映出来：

image-20231030174518420

其中 cpu.cfs_quota_us 就是 CPU 的限制值，如果要查看具体的容器的资源，也可以进入到容器目录下面去查看即可。

了解下内存这块的资源控制，内存的单位换算比较简单：

1 MiB = 1024 KiB，内存这块在 Kubernetes 里一般用的是Mi单位，当然你也可以使用Ki、Gi甚至Pi，看具体的业务需求和资源容量。

单位换算: 这里注意的是MiB ≠ MB，MB 是十进制单位，MiB 是二进制，平时以为 MB 等于 1024KB，其实1MB=1000KB，1MiB才等于1024KiB。中间带字母 i 的是国际电工协会（IEC）定的，走1024乘积；KB、MB、GB 是国际单位制，走1000乘积。

这里要注意的是，内存是不可压缩性资源，如果容器使用内存资源到达了上限，那么会OOM，造成内存溢出，容器就会终止和退出。可以通过上面的方式去通过查看 CGroup 文件的值来验证资源限制。

Kubernetes-ReplicaSet控制器

Tue, 31 Oct 2023 00:00:00 GMT

在实际使用的时候并不会直接使用 Pod，而是会使用各种控制器，Kubernetes 中运行了一系列控制器来确保集群的当前状态与期望状态保持一致，它们就是 Kubernetes 的大脑。例如，ReplicaSet 控制器负责维护集群中运行的 Pod 数量；Node 控制器负责监控节点的状态，并在节点出现故障时及时做出响应。总而言之，在 Kubernetes 中，每个控制器只负责某种类型的特定资源。

控制器#

Kubernetes 控制器会监听资源的 创建/更新/删除 事件，并触发 Reconcile 调谐函数作为响应，整个调整过程被称作 “Reconcile Loop”（调谐循环） 或者 “Sync Loop”（同步循环）。Reconcile 是一个使用资源对象的命名空间和资源对象的名称来调用的函数，使得资源对象的实际状态与资源清单中定义的状态保持一致。调用完成后，Reconcile 会将资源对象的状态更新为当前实际状态。下面的一段伪代码来表示这个过程：

1
for {
2
  desired := getDesiredState()  // 期望的状态
3
  current := getCurrentState()  // 当前实际状态
4
  if current == desired {  // 如果状态一致则什么都不做
5
    // nothing to do
6
  } else {  // 如果状态不一致则调整编排，到一致为止
7
    // change current to desired status
8
  }
9
}

这个编排模型就是 Kubernetes 项目中的一个通用编排模式，即：控制循环（control loop）。

ReplicaSet#

假如现在有一个 Pod 正在提供线上的服务，想象一下可能会遇到的一些场景：

某次活动非常成功，网站访问量突然暴增
运行当前 Pod 的节点发生故障了，Pod 不能正常提供服务了

第一种情况，可能比较好应对，活动之前可以大概计算下会有多大的访问量，提前多启动几个 Pod 副本，活动结束后再把多余的 Pod 杀掉，虽然有点麻烦，但是还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的 Pod，问题可以解决。

但是如果都人工的去解决遇到的这些问题，似乎又回到了以前刀耕火种的时代了，如果有一种工具能够自动管理 Pod 就好了，Pod 挂了自动在合适的节点上重新启动一个 Pod，这样遇到上面的问题就不需要手动去解决了。

而 ReplicaSet 这种资源对象就可以来实现这个功能，ReplicaSet（RS） 的主要作用就是维持一组 Pod 副本的运行，保证一定数量的 Pod 在集群中正常运行，ReplicaSet 控制器会持续监听它所控制的这些 Pod 的运行状态，在 Pod 发送故障数量减少或者增加时会触发调谐过程，始终保持副本数量一定。

和 Pod 一样仍然还是通过 YAML 文件来描述 ReplicaSet 资源对象，如下 YAML 文件是一个常见的 ReplicaSet 定义：

1
apiVersion: apps/v1
2
kind: ReplicaSet
3
metadata:
4
  name: nginx-rs
5
  namespace: default
6
spec:
7
  replicas: 3 # 期望的Pod副本数量 默认是1
8
  selector: # Label Selector 必须匹配Pod模板中的标签
9
    matchLabels:
10
      app: nginx
11
  template:
12
    metadata:
13
      labels:
14
        app: nginx
15
    spec:
16
      containers:
17
        - name: nginx
18
          image: nginx
19
          ports:
20
            - containerPort: 80
21
          resources:
22
            limits:
23
              memory: "128Mi"
24
              cpu: "500m"

展开收起

上面的 YAML 文件结构和之前定义的 Pod 看上去没太大两样，有常见的 apiVersion、kind、metadata，在 spec 下面描述 ReplicaSet 的基本信息，其中包含 3 个重要内容：

replias：表示期望的 Pod 的副本数量
selector：Label Selector，用来匹配要控制的 Pod 标签，需要和下面的 Pod 模板中的标签一致
template：Pod 模板，实际上就是以前我们定义的 Pod 内容，相当于把一个 Pod 的描述以模板的形式嵌入到了 ReplicaSet 中来。

上面就是一个普通的 ReplicaSet 资源清单文件，ReplicaSet 控制器会通过定义的 Label Selector 标签去查找集群中的 Pod 对象：

replicaset top

直接来创建上面的资源对象：

Terminal window

1
kubectl apply -f nginx-rs.yaml

通过查看 RS 可以看到当前资源对象的描述信息，包括DESIRED、CURRENT、READY的状态值，创建完成后，可以利用如下命令查看 Pod 列表。

Terminal window

1
kubectl get rs -n default

Terminal window

1
kubectl get pod -n default -l app=nginx

可以看到现在有 3 个 Pod，这 3 个 Pod 就是在 RS 中声明的 3 个副本，删除其中一个 Pod，再次查看pod列表

Terminal window

1
kubectl delete pod nginx-rs-9ndjb -n default

image-20231031145719258

可以看到又重新出现了一个 Pod，这个就是上面说的 ReplicaSet 控制器做的工作，在 YAML 文件中声明了 3 个副本，然后删除了一个副本，变成了两个，这个时候 ReplicaSet 控制器监控到控制的 Pod 数量和期望的 3 不一致，就需要启动一个新的 Pod 来保持 3 个副本，这个过程就是上面说的调谐的过程。同样可以查看 RS 的描述信息来查看到相关的事件信息：

Terminal window

1
kubectl describe rs nginx-rs -n default

image-20231031150245567

可以发现最开始通过 ReplicaSet 控制器创建了 3 个 Pod，后面删除了 Pod 后， ReplicaSet 控制器又创建了一个 Pod，和上面的描述是一致的。如果这个时候把 RS 资源对象的 Pod 副本更改为 2 spec.replicas=2，这个时候再更新下资源对象：

Terminal window

1
kubectl apply -f nginx-rs.yaml

Terminal window

1
kubectl describe rs nginx-rs -n default

image-20231031150721916

image-20231031150840293

可以看到 Replicaset 控制器在发现资源声明中副本数变更为 2 后，就主动去删除了一个 Pod，这样副本数就和期望的始终保持一致了

随便查看一个 Pod 的描述信息可以看到这个 Pod 的所属控制器信息：

Terminal window

1
kubectl describe pod nginx-rs-r7hjv -n default

image-20231031151049324

另外被 ReplicaSet 持有的 Pod 有一个 metadata.ownerReferences 指针指向当前的 ReplicaSet，表示当前 Pod 的所有者，这个引用主要会被集群中的垃圾收集器使用以清理失去所有者的 Pod 对象。这个 ownerReferences 和数据库中的外键非常类似。可以通过将 Pod 资源描述信息导出查看：

Terminal window

1
kubectl get pod nginx-rs-r7hjv -n default -o yaml

image-20231031151315438

可以看到 Pod 中有一个 metadata.ownerReferences 的字段指向了 ReplicaSet 资源对象。如果要彻底删除 Pod，我们就只能删除 RS 对象：

Terminal window

1
kubectl delete rs nginx-rs -n default

image-20231031151518023

Replication Controller（可忽略）#

Replication Controller 简称 RC，实际上 RC 和 RS 的功能几乎一致，RS 算是对 RC 的改进，目前唯一的一个区别就是 RC 只支持基于等式的 selector（env=dev 或 environment!=qa），但 RS 还支持基于集合的 selector（version in (v1.0, v2.0)）。

比如上面资源对象如果要使用 RC 的话，对应的 selector 是这样的：

1
selector:
2
  app: nginx

RC 只支持单个 Label 的等式，而 RS 中的 Label Selector 支持 matchLabels 和 matchExpressions 两种形式：

1
selector:
2
  matchLabels:
3
    app: nginx
4
---
5
selector:
6
  matchExpressions: # 该选择器要求 Pod 包含名为 app 的标签
7
    - key: app
8
      operator: In
9
      values: # 并且标签的值必须是 nginx
10
        - nginx

总的来说 RS 是新一代的 RC，所以以后直接使用 RS 即可，它们的功能都是一致的，但是实际上在实际使用中不会直接使用 RS，而是使用更上层的类似于 Deployment 这样的资源对象。

Kubernetes-Pod生命周期

Mon, 30 Oct 2023 00:00:00 GMT

pod loap

上图展示了一个 Pod 的完整生命周期过程，其中包含 Init Container、Pod Hook、健康检查 三个主要部分，接下来分别介绍影响 Pod 生命周期的部分：

首先在介绍 Pod 的生命周期之前，需要先了解下 Pod 的状态，因为 Pod 状态可以反应出当前我们的 Pod 的具体状态信息，也是分析排错的一个必备的方式。

容器状态#

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样。你可以使用容器生命周期回调来在容器生命周期中的特定时间点触发事件。

一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为 Pod 创建容器。容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

要检查 Pod 中容器的状态，你可以使用 kubectl describe pod <pod 名称>。其输出中包含 Pod 中每个容器的状态。

每种状态都有特定的含义：

`Waiting` （等待）#

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。

`Running`（运行中）#

Running 状态表明容器正在执行状态并且没有问题发生。如果配置了 postStart 回调，那么该回调已经执行且已完成。如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时，你也会看到关于容器进入 Running 状态的信息。

`Terminated`（已终止）#

处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时，你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。

从 Kubernetes 1.27 开始，除了静态 Pod 和没有 Finalizer 的强制终止 Pod 之外，kubelet 会将已删除的 Pod 转换到终止阶段（Failed 或 Succeeded 具体取决于 Pod 容器的退出状态），然后再从 API 服务器中删除。

如果某节点死掉或者与集群中其他节点失联，Kubernetes 会实施一种策略，将失去的节点上运行的所有 Pod 的 phase 设置为 Failed。

Pod状况#

Pod 有一个 PodStatus 对象，其中包含一个 PodConditions 数组。Pod 可能通过也可能未通过其中的一些状况测试。 Kubelet 管理以下 PodCondition：

PodScheduled：Pod 已经被调度到某节点；
PodReadyToStartContainers：Pod 沙箱被成功创建并且配置了网络（Alpha 特性，必须被显式启用）；
ContainersReady：Pod 中所有容器都已就绪；
Initialized：所有的 Init 容器都已成功完成；
Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。

字段名称	描述
`type`	Pod 状况的名称
`status`	表明该状况是否适用，可能的取值有 “`True`”、“`False`” 或 “`Unknown`”
`lastProbeTime`	上次探测 Pod 状况时的时间戳
`lastTransitionTime`	Pod 上次从一种状态转换到另一种状态时的时间戳
`reason`	机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因
`message`	人类可读的消息，给出上次状态转换的详细信息

type：Condition 类型，包括以下方面：
- PodScheduled（Pod 已经被调度到其他 node 里）
- Ready（Pod 能够提供服务请求，可以被添加到所有可匹配服务的负载平衡池中）
- Initialized（所有的init containers已经启动成功）
- Unschedulable（调度程序现在无法调度 Pod，例如由于缺乏资源或其他限制）
- ContainersReady（Pod 里的所有容器都是 ready 状态）

Terminal window

1
kubectl explain pod.status.phase

image-20231020110315279

重启策略#

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。restartPolicy 指通过 kubelet 在同一节点上重新启动容器。通过 kubelet 重新启动的退出容器将以指数增加延迟（10s，20s，40s…）重新启动，上限为 5 分钟，并在成功执行 10 分钟后重置。不同类型的的控制器可以控制 Pod 的重启策略：

Job：适用于一次性任务如批量计算，任务结束后 Pod 会被此类控制器清除。Job 的重启策略只能是"OnFailure"或者"Never"。
ReplicaSet、Deployment：此类控制器希望 Pod 一直运行下去，它们的重启策略只能是"Always"。
DaemonSet：每个节点上启动一个 Pod，很明显此类控制器的重启策略也应该是"Always"。

初始化容器#

Pod 中最先启动的 Init Container，也就是常说的初始化容器。Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行。一个 Pod 里面的所有容器是共享数据卷和 Network Namespace 的，所以 Init Container 里面产生的数据可以被主容器使用到。从上面的 Pod 生命周期的图中可以看出初始化容器是独立与主容器之外的，只有所有的`初始化容器执行完之后，主容器才会被启动。初始化容器的应用场景：

等待其他模块 Ready：这个可以用来解决服务之间的依赖问题，比如有一个 Web 服务，该服务又依赖于另外一个数据库服务，但是在启动这个 Web 服务的时候我们并不能保证依赖的这个数据库服务就已经启动起来了，所以可能会出现一段时间内 Web 服务连接数据库异常。要解决这个问题的话我们就可以在 Web 服务的 Pod 中使用一个 InitContainer，在这个初始化容器中去检查数据库是否已经准备好了，准备好了过后初始化容器就结束退出，然后我们主容器的 Web 服务才被启动起来，这个时候去连接数据库就不会有问题了。
做初始化配置：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群。
其它场景：如将 Pod 注册到一个中央数据库、配置中心等。

比如实现一个功能，在 Nginx Pod 启动之前去重新初始化首页内容，如下所示的资源清单：（init-pod.yaml）

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: init-demo
5
spec:
6
  volumes:
7
    - name: workdir
8
      emptyDir: {}
9
  initContainers:
10
    - name: install
11
      image: busybox
12
      command:
13
        - wget
14
        - "-O"
15
        - "/work-dir/index.html"
16
        - http://www.baidu.com # https
17
      volumeMounts:
18
        - name: workdir
19
          mountPath: "/work-dir"
20
  containers:
21
    - name: web
22
      image: nginx
23
      ports:
24
        - containerPort: 80
25
      volumeMounts:
26
        - name: workdir
27
          mountPath: /usr/share/nginx/html
28
      resources:
29
        limits:
30
          memory: "128Mi"
31
          cpu: "500m"

展开收起

上面的资源清单中首先在 Pod 顶层声明了一个名为 workdir 的 Volume，前面我们用了 hostPath 的模式，这里我们使用的是 emptyDir{}，这个是一个临时的目录，数据会保存在 kubelet 的工作目录下面，生命周期等同于 Pod 的生命周期。

然后定义了一个初始化容器，该容器会下载一个 html 文件到 /work-dir 目录下面，但是由于又将该目录声明挂载到了全局的 Volume，同样的主容器 nginx 也将目录 /usr/share/nginx/html 声明挂载到了全局的 Volume，所以在主容器的该目录下面会同步初始化容器中创建的 index.html 文件。

直接创建上面的 Pod：

Terminal window

1
kubectl apply -f init-pod.yaml

可以查看 Pod 的详细信息：

Terminal window

1
kubectl describe pod init-demo -n default

1
[root@master ~]# kubectl describe pod init-demo -n default
2

3
Name:         init-demo
4
Namespace:    default
5
Priority:     0
6
Node:         node3/10.168.1.23
7
Start Time:   Fri, 20 Oct 2023 14:31:54 +0800
8
Labels:       <none>
9
Annotations:  cni.projectcalico.org/containerID: 8991143f9d34292f8f406f9f03db7843d8cc4835f6ee6ba935985c66fc81f79e
10
              cni.projectcalico.org/podIP: 10.233.92.55/32
11
              cni.projectcalico.org/podIPs: 10.233.92.55/32
12
Status:       Running
13
IP:           10.233.92.55
14
IPs:
15
  IP:  10.233.92.55
16
Init Containers:
17
  install:
18
    Container ID:  containerd://172ef7435b04804374ee827fff1b0185e9502434ac84f3e92e5ae0132b2fce1c
19
    Image:         busybox
20
    Image ID:      docker.io/library/busybox@sha256:3fbc632167424a6d997e74f52b878d7cc478225cffac6bc977eedfe51c7f4e79
21
    Port:          <none>
22
    Host Port:     <none>
23
    Command:
24
      wget
25
      -O
26
      /work-dir/index.html
27
      http://www.baidu.com
28
    State:          Terminated
29
      Reason:       Completed
30
      Exit Code:    0
31
      Started:      Fri, 20 Oct 2023 14:32:01 +0800
32
      Finished:     Fri, 20 Oct 2023 14:32:01 +0800
33
    Ready:          True
34
    Restart Count:  0
35
    Environment:    <none>
36
    Mounts:
37
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-2td7n (ro)
38
      /work-dir from workdir (rw)
39
Containers:
40
  web:
41
    Container ID:   containerd://5eadf1c2e3087ff66a039046d0c15757a4ea6dcfacb00a67e40135d30c2daa4d
42
    Image:          nginx
43
    Image ID:       docker.io/library/nginx@sha256:b4af4f8b6470febf45dc10f564551af682a802eda1743055a7dfc8332dffa595
44
    Port:           80/TCP
45
    Host Port:      0/TCP
46
    State:          Running
47
      Started:      Fri, 20 Oct 2023 14:32:05 +0800
48
    Ready:          True
49
    Restart Count:  0
50
    Limits:
51
      cpu:     500m
52
      memory:  128Mi
53
    Requests:
54
      cpu:        500m
55
      memory:     128Mi
56
    Environment:  <none>
57
    Mounts:
58
      /usr/share/nginx/html from workdir (rw)
59
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-2td7n (ro)
60
Conditions:
61
  Type              Status
62
  Initialized       True
63
  Ready             True
64
  ContainersReady   True
65
  PodScheduled      True
66
Volumes:
67
  workdir:
68
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
69
    Medium:
70
    SizeLimit:  <unset>
71
  kube-api-access-2td7n:
72
    Type:                    Projected (a volume that contains injected data from multiple sources)
73
    TokenExpirationSeconds:  3607
74
    ConfigMapName:           kube-root-ca.crt
75
    ConfigMapOptional:       <nil>
76
    DownwardAPI:             true
77
QoS Class:                   Burstable
78
Node-Selectors:              <none>
79
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
80
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
81
Events:
82
  Type    Reason     Age    From               Message
83
  ----    ------     ----   ----               -------
84
  Normal  Scheduled  5m27s  default-scheduler  Successfully assigned default/init-demo to node3
85
  Normal  Pulling    5m26s  kubelet            Pulling image "busybox"
86
  Normal  Pulled     5m20s  kubelet            Successfully pulled image "busybox" in 6.11876556s
87
  Normal  Created    5m20s  kubelet            Created container install
88
  Normal  Started    5m20s  kubelet            Started container install
89
  Normal  Pulling    5m19s  kubelet            Pulling image "nginx"
90
  Normal  Pulled     5m17s  kubelet            Successfully pulled image "nginx" in 1.85788456s
91
  Normal  Created    5m17s  kubelet            Created container web
92
  Normal  Started    5m16s  kubelet            Started container web

展开收起

从上面的描述信息里面可以看到初始化容器已经启动了，现在处于 Running 状态，等到初始化容器执行完成后退出初始化容器会变成 Completed 状态，然后才会启动主容器。待到主容器也启动完成后，Pod 就会变成Running 状态，然后我们去访问下 Pod 主页，验证下是否有我们初始化容器中下载的页面信息：

Terminal window

1
kubectl get pods -n default -o wide

image-20231020144101231

Pod Hook#

Pod 是 Kubernetes 集群中的最小单元，而 Pod 是由容器组成的，所以在讨论 Pod 的生命周期的时候可以先来讨论下容器的生命周期。实际上 Kubernetes 为我们的容器提供了生命周期的钩子Pod Hook，Pod Hook 是由 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook。

Kubernetes提供了两种钩子函数：

PostStart：这个钩子在容器创建后立即执行。但是并不能保证钩子将在容器 ENTRYPOINT 之前运行，因为没有参数传递给处理程序。主要用于资源部署、环境准备等。不过需要注意的是如果钩子花费太长时间以至于不能运行或者挂起，容器将不能达到 running 状态。
PreStop：这个钩子在容器终止之前立即被调用。它是阻塞的，意味着它是同步的，所以它必须在删除容器的调用发出之前完成。主要用于优雅关闭应用程序、通知其他系统等。如果钩子在执行期间挂起，Pod阶段将停留在 running状态并且永不会达到 failed 状态。

如果 PostStart 或者 PreStop 钩子失败，它会杀死容器。所以应该让钩子函数尽可能的轻量。当然有些情况下，长时间运行命令是合理的，比如在停止容器之前预先保存状态。

另外有两种方式来实现上面的钩子函数：

Exec - 用于执行一段特定的命令，不过要注意的是该命令消耗的资源会被计入容器。
HTTP - 对容器上的特定的端点执行 HTTP 请求。

以下示例中，定义了一个 Nginx Pod，其中设置了 PostStart 钩子函数，即在容器创建成功后，写入一句话到 /usr/share/message 文件中：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: hook-demo1
5
spec:
6
  containers:
7
    - name: hook-demo1
8
      image: nginx
9
      lifecycle:
10
        postStart:
11
          exec:
12
            command:
13
              - /bin/sh
14
              - -c
15
              - echo Hello from the postStart handler > /usr/share/message
16
      resources:
17
        limits:
18
          memory: "128Mi"
19
          cpu: "500m"

展开收起

创建上面的 Pod

Terminal window

1
kubectl apply -f pod-poststart.yaml

创建成功后可以查看容器中 /usr/share/message 文件是否内容正确

Terminal window

1
kubectl exec -it hook-demo1 -- cat /usr/share/message

image-20231020145249253

当用户请求删除含有 Pod 的资源对象时（如 Deployment 等），K8S 为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，再关闭软件），K8S 提供两种信息通知：

默认：K8S 通知 node 执行容器 stop 命令，容器运行时会先向容器中 PID 为 1 的进程发送系统信号 SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送 SIGKILL 的系统信号强行 kill 掉进程
使用 Pod 生命周期（利用 PreStop 回调函数），它在发送终止信号之前执行

默认所有的优雅退出时间都在 30 秒内，kubectl delete 命令支持 --grace-period=<seconds> 选项，这个选项允许用户用他们自己指定的值覆盖默认值，值0代表强制删除 pod。在 kubectl 1.5 及以上的版本里，执行强制删除时必须同时指定 --force --grace-period=0。

强制删除一个 pod 是从集群中还有 etcd 里立刻删除这个 pod，只是当 Pod 被强制删除时， APIServer 不会等待来自 Pod 所在节点上的 kubelet 的确认信息：pod 已经被终止。在 API 里 pod 会被立刻删除，在节点上， pods 被设置成立刻终止后，在强行杀掉前还会有一个很小的宽限期。

以下示例中，定义了一个 Nginx Pod，其中设置了 PreStop 钩子函数，即在容器退出之前，优雅的关闭 Nginx：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: hook-demo2
5
spec:
6
  containers:
7
    - name: hook-demo2
8
      image: nginx
9
      lifecycle:
10
        preStop:
11
          exec:
12
            command:
13
              - /usr/sbin/nginx
14
              - -s
15
              - quit
16
      resources:
17
        limits:
18
          memory: "128Mi"
19
          cpu: "500m"
20

21
---
22
apiVersion: v1
23
kind: Pod
24
metadata:
25
  name: hook-demo3
26
spec:
27
  volumes:
28
    - name: message
29
      hostPath:
30
        path: /tmp
31
  containers:
32
    - name: hook-demo3
33
      image: nginx
34
      ports:
35
        - containerPort: 80
36
      volumeMounts:
37
        - name: message
38
          mountPath: /usr/share
39
      lifecycle:
40
        preStop:
41
          exec:
42
            command:
43
              - /bin/sh
44
              - -c
45
              - echo Hello from the preStop Handler > /usr/share/message
46
      resources:
47
        limits:
48
          memory: "128Mi"
49
          cpu: "500m"

展开收起

上面定义的两个 Pod，一个是利用 preStop 来进行优雅删除，另外一个是利用 preStop 来做一些信息记录的事情，直接创建上面的 Pod：

Terminal window

1
kubectl apply -f pod-prestop.yaml

创建完成后，直接删除 hook-demo2 这个 Pod，在容器删除之前会执行 preStop 里面的优雅关闭命令，这个用法在后面的滚动更新的时候用来保证应用零宕机非常有用。第二个 Pod 声明了一个 hostPath 类型的 Volume，在容器里面声明挂载到了这个 Volume，所以当删除 Pod，退出容器之前，在容器里面输出的信息也会同样的保存到宿主机（一定要是 Pod 被调度到的目标节点）的 /tmp 目录下面，可以查看 hook-demo3 这个 Pod 被调度的节点：

Terminal window

1
kubectl describe pod hook-demo3 -n default

image-20231030160508981

删除 hook-demo3 这个 Pod，按照设定在容器退出之前会执行 preStop 里面的命令，也就是会往 message 文件中输出一些信息：

Terminal window

1
kubectl delete pod hook-demo3 -n default

image-20231030161150163

另外 Hook 调用的日志没有暴露给 Pod，所以只能通过 describe 命令来获取，如果有错误将可以看到 FailedPostStartHook 或 FailedPreStopHook 这样的 event。

Pod健康检查#

在 Kubernetes 集群当中，可以通过配置liveness probe（存活探针）和 readiness probe（可读性探针） 来影响容器的生命周期：

kubelet 通过使用 liveness probe 来确定应用程序是否正在运行，通俗点将就是是否还活着。一般来说，如果程序一旦崩溃了， Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而 liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，那么就重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。
kubelet 使用 readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了，现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态，因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态，那么我们就会将他从 Service 的 Endpoints 列表中移除出来，这样流量就不会被路由到这个 Pod 里面来了。

和前面的钩子函数一样的，这两个探针的支持下面几种配置方式：

exec：执行一段命令
http：检测某个 http 请求
tcpSocket：使用此配置，kubelet 将尝试在指定端口上打开容器的套接字。如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的。实际上就是检查端口。

首先用 exec 执行命令的方式来检测容器的存活，如下：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: liveness-exec
5
spec:
6
  containers:
7
    - name: liveness
8
      image: busybox
9
      args:
10
        - /bin/sh
11
        - -c
12
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
13
      livenessProbe:
14
        exec:
15
          command:
16
            - cat
17
            - /tmp/healthy
18
        initialDelaySeconds: 5
19
        periodSeconds: 5
20
      resources:
21
        limits:
22
          memory: "128Mi"
23
          cpu: "500m"

展开收起

periodSeconds：表示让 kubelet 每隔 5 秒执行一次存活探针，也就是每 5 秒执行一次上面的 cat /tmp/healthy 命令，如果命令执行成功了，将返回 0，那么 kubelet 就会认为当前这个容器是存活的，如果返回的是非 0 值，那么 kubelet 就会把该容器杀掉然后重启它。默认是 10 秒，最小 1 秒。
initialDelaySeconds：表示在第一次执行探针的时候要等待 5 秒，这样能够确保容器能够有足够的时间启动起来。如果第一次执行探针等候的时间太短，很有可能容器还没正常启动起来，所以存活探针很可能始终都是失败的，这样就会无休止的重启下去。

容器启动的时候，执行了如下命令：

Terminal window

1
/bin/sh -c "touch /tmp/healthy; sleep 120; rm -rf /tmp/healthy; sleep 600"

在容器最开始的 30 秒内创建了一个 /tmp/healthy 文件，在这 30 秒内执行 cat /tmp/healthy 命令都会返回一个成功的返回码。30 秒后，删除这个文件，现在执行 cat /tmp/healthy 就会失败了（默认检测失败 3 次会认为失败），所以这个时候就会重启容器了。

创建该 Pod，然后在 30 秒内，查看 Pod 的 Event：

Terminal window

1
kubectl apply -f liveness-exec.yaml

Terminal window

1
kubectl describe pod liveness-exec -n default

image-20231030163801253

image-20231030163824473

image-20231030164005984

还可以使用HTTP GET请求来配置我们的存活探针，我们这里使用一个 liveness 镜像来验证演示下：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: liveness-http
5
spec:
6
  containers:
7
    - name: liveness
8
      image: cnych/liveness
9
      args:
10
        - /server
11
      livenessProbe:
12
        httpGet:
13
          path: /healthz
14
          port: 8080
15
          httpHeaders:
16
            - name: X-Custom-Header
17
              value: Awesome
18
        initialDelaySeconds: 3
19
        periodSeconds: 3
20
      resources:
21
        limits:
22
          memory: "128Mi"
23
          cpu: "500m"

展开收起

根据 periodSeconds 属性可以知道 kubelet 需要每隔 3 秒执行一次 liveness Probe，该探针将向容器中的 server 的 8080 端口发送一个 HTTP GET 请求。如果 server 的 /healthz 路径的 handler 返回一个成功的返回码，kubelet 就会认定该容器是活着的并且很健康，如果返回失败的返回码，kubelet 将杀掉该容器并重启它。initialDelaySeconds 指定 kubelet 在该执行第一次探测之前需要等待 3 秒钟。

返回码<通常来说>，任何大于200小于400的状态码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。

healthz 的实现：

1
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
2
    duration := time.Now().Sub(started)
3
    if duration.Seconds() > 10 {
4
        w.WriteHeader(500)
5
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
6
    } else {
7
        w.WriteHeader(200)
8
        w.Write([]byte("ok"))
9
    }
10
})

大概意思就是最开始前 10s 返回状态码 200，10s 过后就返回状态码 500。所以当容器启动 3 秒后，kubelet 开始执行健康检查。第一次健康检查会成功，因为是在 10s 之内，但是 10 秒后，健康检查将失败，因为现在返回的是一个错误的状态码了，所以 kubelet 将会杀掉和重启容器。

创建下该 Pod 测试下效果，10 秒后，查看 Pod 的 event，确认 liveness probe 失败并重启了容器：

Terminal window

1
kubectl apply -f liveness-http.yaml

image-20231030165523842

除了上面的 exec 和 httpGet 两种检测方式之外，还可以通过 tcpSocket 方式来检测端口是否正常。

另外前面提到了探针里面有一个 initialDelaySeconds 的属性，可以来配置第一次执行探针的等待时间，对于启动非常慢的应用这个参数非常有用，比如 Jenkins、Gitlab 这类应用，但是如何设置一个合适的初始延迟时间呢？这个就和应用具体的环境有关系了，所以这个值往往不是通用的，这样的话可能就会导致一个问题，资源清单在别的环境下可能就会健康检查失败了，为解决这个问题，在 Kubernetes v1.16 版本官方特地新增了一个 startupProbe（启动探针），该探针将推迟所有其他探针，直到 Pod 完成启动为止，使用方法和存活探针一样：

1
startupProbe:
2
  httpGet:
3
    path: /healthz
4
    port: 8080
5
  failureThreshold: 30 # 尽量设置大点
6
  periodSeconds: 10

比如上面这里的配置表示慢速容器最多可以有 5 分钟（30 个检查 * 10 秒= 300s）来完成启动。

有的时候，应用程序可能暂时无法对外提供服务，例如，应用程序可能需要在启动期间加载大量数据或配置文件。在这种情况下，不想杀死应用程序，也不想对外提供服务。那么这个时候就可以使用 readiness probe 来检测和减轻这些情况，Pod 中的容器可以报告自己还没有准备，不能处理 Kubernetes 服务发送过来的流量。readiness probe 的配置跟 liveness probe 基本上一致的，唯一的不同是使用 readinessProbe 而不是 livenessProbe，两者如果同时使用的话就可以确保流量不会到达还未准备好的容器，准备好过后，如果应用程序出现了错误，则会重新启动容器。

另外除了上面的 initialDelaySeconds 和 periodSeconds 属性外，探针还可以配置如下几个参数：

timeoutSeconds：探测超时时间，默认 1 秒，最小 1 秒。
successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功，默认是 1，但是如果是 liveness 则必须是 1。最小值是 1。
failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败，默认是 3，最小值是 1。

Kubernetes-Pod的基本原理

Fri, 20 Oct 2023 00:00:00 GMT

pod demo

Pod 是 Kubernetes 集群中最基本的调度单元，在集群中部署的应用都是以 Pod 为单位的，而并不是我们熟知的容器

为什么需要Pod#

假设 Kubernetes 中调度的基本单元就是容器，对于一个非常简单的应用可以直接被调度直接使用，没有什么问题，但是往往还有很多应用程序是由多个进程组成的，那把这些进程都打包到一个容器中去不就可以了吗？理论上是可以实现的，但是容器运行时管理的进程是 pid=1 的主进程，其他进程死掉了就会成为僵尸进程，没办法进行管理了，这种方式本身也不是容器推荐的运行方式，一个容器最好只干一件事情，所以在真实的环境中不会使用这种方式。

那么把这个应用的进程进行拆分，拆分成一个一个的容器总可以了吧？但是不要忘记一个问题，拆分成一个一个的容器后，就有可能出现一个应用下面的某个进程容器被调度到了不同的节点上，往往应用内部的进程与进程间通信（通过 IPC 或者共享本地文件之类）都是要求在本地进行的，也就是需要在同一个节点上运行。

所以需要一个更高级别的结构来将这些容器绑定在一起，并将他们作为一个基本的调度单元进行管理，这样就可以保证这些容器始终在同一个节点上面，这也就是 Pod 设计的初衷。

Pod原理#

在一个 Pod 里面运行几个关系非常密切的容器进程，这样一来这些进程本身又可以受到容器的管控，又具有几乎一致的运行环境，也就完美解决了上面提到的问题。

其实 Pod 也只是一个逻辑概念，真正起作用的还是 Linux 容器的 Namespace 和 Cgroup 这两个最基本的概念，Pod 被创建出来其实是一组共享了一些资源的容器而已。首先 Pod 里面的所有容器，都是共享的同一个 Network Namespace，但是涉及到文件系统的时候，默认情况下 Pod 里面的容器之间的文件系统是完全隔离的，但是可以通过声明来共享同一个 Volume。

可以指定新创建的容器和一个已经存在的容器共享一个 Network Namespace，在运行容器（docker 容器）的时候只需要指定 --net=container:目标容器名 这个参数就可以了，但是这种模式有一个明显的问题那就是容器的启动有先后顺序问题，那么 Pod 是怎么来处理这个问题的呢？那就是加入一个中间容器（没有什么架构是加一个中间件解决不了的？），这个容器叫做 Infra 容器，而且这个容器在 Pod 中永远都是第一个被创建的容器，这样是不是其他容器都加入到这个 Infra 容器就可以了，这样就完全实现了 Pod 中的所有容器都和 Infra 容器共享同一个 Network Namespace 了，如下图所示：

pod infra container

所以当部署完成 Kubernetes 集群的时候，首先需要保证在所有节点上可以拉取到默认的 Infra 镜像，目前默认情况下 Infra 镜像地址为 k8s.gcr.io/pause:3.6，这个容器占用的资源非常少，但是这个镜像默认是需要科学上网的，所以很多时候在部署应用的时候一直处于 Pending状态或者报sandbox image` 相关的错误信息，大部分是因为所有 Pod 最先启动的容器镜像都拉不下来，肯定启动不了，启动不了其他容器肯定也就不能启动了：

Terminal window

1
kubelet --help |grep infra

image-20231018150743083

从上面图中可以看出普通的容器加入到了 Infra 容器的 Network Namespace 中，所以这个 Pod 下面的所有容器就是共享同一个 Network Namespace 了，普通容器不会创建自己的网卡，配置自己的 IP，而是和 Infra 容器共享 IP、端口范围等，而且容器之间的进程可以通过 lo 网卡设备进行通信：

也就是容器之间是可以直接使用 localhost 进行通信的；
看到的网络设备信息都是和 Infra 容器完全一样的；
也就意味着同一个 Pod 下面的容器运行的多个进程不能绑定相同的端口；
而且 Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。

对于文件系统 Kubernetes 是怎么实现让一个 Pod 中的容器共享的呢？默认情况下容器的文件系统是互相隔离的，要实现共享只需要在 Pod 的顶层声明一个 Volume，然后在需要共享这个 Volume 的容器中声明挂载即可。

pod containers share volumes

比如下面的示例:

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: counter
5
  labels:
6
    name: counter
7
spec:
8
  volumes:
9
    - name: varlog
10
      hostPath:
11
        path: /var/log/counter
12
  containers:
13
    - name: count
14
      image: busybox
15
      args:
16
        - /bin/sh
17
        - -c
18
        - >
19
          i=0; while true; do
20
            echo "$i: $(date)" >> /var/log/1.log;
21
            i=$((i+1));
22
            sleep 1;
23
          done
24
      volumeMounts:
25
        - name: varlog
26
          mountPath: /var/log
27
      resources:
28
        limits:
29
          memory: "128Mi"
30
          cpu: "500m"
31
    - name: count-log
32
      image: busybox
33
      args: [/bin/sh, -c, "tail -n+1 -f /opt/log/1.log"]
34
      volumeMounts:
35
        - name: varlog
36
          mountPath: /opt/log
37
      resources:
38
        limits:
39
          memory: "128Mi"
40
          cpu: "500m"

展开收起

count容器是挂载的/var/log目录 count-log容器挂载的是/opt/log 实际挂载的pod所在宿主机hostPath的docker所在文件目录的/var/log/counter 而非pod所在机器的/var/log/counter

image-20231020102115480

Terminal window

1
kubectl get pod -n default -o wide|grep counter
2
kubectl logs  counter -c count-log --tail 5
3
ssh node2
4
find / -name 1.log
5
tail -n 5 /var/lib/kubelet/pods/63fa7261-bcd3-4ac0-98bb-9c8a869d2601/volumes/kubernetes.io~empty-dir/varlog/1.log

示例中在 Pod 的顶层声明了一个名为 varlog 的 Volume，这个 Volume 的类型是 hostPath，也就意味这个宿主机的Docker文件目录下的 /var/log/counter 目录将被这个 Pod 共享，共享给谁呢？在需要用到这个数据目录的容器上声明挂载即可，也就是通过 volumeMounts 声明挂载的部分，这样这个 Pod 就实现了共享容器的 /var/log 目录，而且数据被持久化到了宿主机目录上。

这个方式也是 Kubernetes 中一个非常重要的设计模式：sidecar 模式的常用方式。典型的场景就是容器日志收集，比如上面的这个应用，其中应用的日志是被输出到容器的 /var/log 目录上的，这个时候我们可以把 Pod 声明的 Volume 挂载到容器的 /var/log 目录上，然后在这个 Pod 里面同时运行一个 sidecar 容器，他也声明挂载相同的 Volume 到自己容器的 /var/log （或其他）目录上，这样我们这个 sidecar 容器就只需要从 /var/log 目录下面不断消费日志发送到日志系统中存储起来就完成了最基本的应用日志的基本收集工作了。

除了这个应用场景之外使用更多的还是利用 Pod 中的所有容器共享同一个 Network Namespace 这个特性，这样就可以把 Pod 网络相关的配置和管理也可以交给一个 sidecar 容器来完成，完全不需要去干涉用户容器，这个特性在现在非常火热的 Service Mesh（服务网格）中应用非常广泛，典型的应用就是 Istio。

如何划分Pod#

上面介绍了 Pod 的实现原理，了解了应该把关系紧密的容器划分到同一个 Pod 中运行，那么怎么来区分“关系紧密”呢？举一个简单的示例，比如Wordpress 应用，是一个典型的前端服务器和后端数据服务的应用，那么你认为应该使用一个 Pod 还是两个 Pod 呢？

如果在同一个 Pod 中同时运行服务器程序和后端的数据库服务这两个容器，理论上肯定是可行的，但是不推荐这样使用，一个 Pod 中的所有容器都是同一个整体进行调度的，但是对于这个应用 Wordpress 和 MySQL 数据库一定需要运行在一起吗？当然不需要，甚至可以将 MySQL 部署到集群之外，所以 Wordpress 和 MySQL 即使不运行在同一个节点上也是可行的，只要能够访问到即可。

pod wordpress demo1

但是如果非要强行部署到同一个 Pod 中呢？从某个角度来说是错误的，比如现在应用访问量非常大，一个 Pod 已经满足不了需求了，怎么办呢？扩容！但是扩容的目标也是 Pod，并不是容器，比如再添加一个 Pod，这个时候就有两个 Wordpress 的应用和两个 MySQL 数据库了，而且这两个 Pod 之间的数据是互相独立的，因为 MySQL 数据库并不是简单的增加副本就可以共享数据了，所以这个时候就得分开部署了，采用第二种方案，这个时候我们只需要单独扩容 Wordpress 的这个 Pod，后端的 MySQL 数据库并不会受到扩容的影响。

pod wordpress demo2

将多个容器部署到同一个 Pod 中的最主要参考就是应用可能由一个主进程和一个或多个的辅助进程组成，比如上面日志收集的 Pod，需要其他的 sidecar 容器来支持日志的采集。所以当判断是否需要在 Pod 中使用多个容器的时候，可以按照如下的几个方式来判断：

这些容器是否一定需要一起运行，是否可以运行在不同的节点上
这些容器是一个整体还是独立的组件
这些容器一起进行扩缩容会影响应用吗

基本上上面的几个问题就能够判断是否需要在 Pod 中运行多个容器了。

Containerd命令行工具-nerdctl

Mon, 16 Oct 2023 00:00:00 GMT

习惯了使用 docker cli，ctr 使用起来可能还是不太顺手，为了能够让大家更好的转到 containerd 上面来，社区提供了一个新的命令行工具：nerdctl。nerdctl 是一个与 docker cli 风格兼容的 containerd 客户端工具，而且直接兼容 docker compose 的语法的.

安装#

Terminal window

1
wget https://github.com/containerd/nerdctl/releases/download/v1.6.2/nerdctl-1.6.2-linux-amd64.tar.gz
2
# 如果有限制，也可以替换成下面的 URL 加速下载
3
# wget https://download.fastgit.org/containerd/nerdctl/releases/download/v1.6.2/nerdctl-1.6.2-linux-amd64.tar.gz
4

5
# 最下化安装
6
tar Cxzvvf /usr/local/bin nerdctl-1.6.2-linux-amd64.tar.gz

image-20231016101552884

命令#

run#
nerdctl run和 docker run 类似可以使用 nerdctl run 命令运行容器
Terminal window
```
1
nerdctl run -d -p 80:80 --name=nginx --restart=always nginx:alpine
```
image-20231016102757105
exec#
Terminal window
```
1
nerdctl exec -it nginx /bin/sh
```
image-20231016103856190
ps#
使用 nerdctl ps 命令可以列出所有容器
Terminal window
```
1
nerdctl ps
```
image-20231016104003495
同样可以使用 -a 选项显示所有的容器列表，默认只显示正在运行的容器，不过需要注意的是 nerdctl ps 命令并没有实现 docker ps 下面的 --filter、--format、--last、--size 等选项
inspect#
显示结果和 docker inspect 基本一致
Terminal window
```
1
nerdctl inspect nginx
```
logs#
—tail 5 : 从最后5行开始显示
Terminal window
```
1
nerdctl logs -f nginx --tail 5
```
image-20231016104515183
stop#
Terminal window
```
1
nerdctl stop nginx
```
image-20231016104614294
rm#
Terminal window
```
1
nerdctl rm nginx
```
image-20231016104726339
rm不能直接杀掉正在运行的容器要想杀掉正在运行的容器需要加上-f强制删除
images
Terminal window
```
1
nerdctl images
```
image-20231016104955438
pull#
Terminal window
```
1
nerdctl pull busybox
```
image-20231016105131475

tag#

Terminal window

1
nerdctl tag busybox registry.cn-hangzhou.aliyuncs.com/tianchunhui/busybox:231016

image-20231016105501575

push#
推送镜像之前也可以使用 nerdctl login 命令登录到镜像仓库，然后再执行 push 操作
Terminal window
```
1
nerdctl push registry.cn-hangzhou.aliyuncs.com/tianchunhui/busybox:231016
```
image-20231016105551521
image-20231016105623053

save#

Terminal window

1
nerdctl save -o busybox.tar.gz busybox:latest

image-20231016105742772

rmi#
Terminal window
```
1
nerdctl rmi busybox
```
image-20231016105920930
load#
使用 -i 或 --input 选项指定需要导入的压缩包
Terminal window
```
1
nerdctl load -i busybox.tar.gz
```
image-20231016110015340
build#
ctr 并没有构建镜像的命令，而现在又不使用 Docker 了， nerdctl 提供了 nerdctl build 这样的镜像构建命令
1. 新建一个如下的Dockerfile文件
  1 FROM nginx 2 RUN echo 'Hello Nerdctl From Containerd' > /usr/share/nginx/html/index.html
2. 在文件所在目录执行镜像构建命令
  Terminal window
  1 nerdctl build -t nginx:nerdctl -f Dockerfile .
  image-20231016110417256
  
  可以看到有一个错误提示，需要安装 buildctl 并运行 buildkitd，这是因为 nerdctl build 需要依赖 buildkit 工具
  
  buildkit 项目也是 Docker 公司开源的一个构建工具包，支持 OCI 标准的镜像构建。它主要包含以下部分:
  - 服务端 buildkitd：当前支持 runc 和 containerd 作为 worker，默认是 runc，我们这里使用 containerd
  - 客户端 buildctl：负责解析 Dockerfile，并向服务端 buildkitd 发出构建请求
  buildkit 是典型的 C/S 架构，客户端和服务端是可以不在一台服务器上，而 nerdctl 在构建镜像的时候也作为 buildkitd 的客户端，所以需要我们安装并运行 buildkitd。
3. 安装 buildkit
  Terminal window
  1 mkdir -p /opt/nerdctl 2 cd /opt/nerdctl 3 wget https://github.com/moby/buildkit/releases/download/v0.12.2/buildkit-v0.12.2.linux-amd64.tar.gz 4 tar -zxvf buildkit-v0.12.2.linux-amd64.tar.gz 5 cp buildctl /usr/local/bin 6 cp buildkitd /usr/local/bin
  使用 Systemd 来管理 buildkitd，创建如下所示的 systemd unit 文件：
  1 vim /etc/systemd/system/buildkit.service 2 3 [Unit] 4 Description=BuildKit 5 Documentation=https://github.com/moby/buildkit 6 7 [Service] 8 ExecStart=/usr/local/bin/buildkitd --oci-worker=false --containerd-worker=true 9 10 [Install] 11 WantedBy=multi-user.target
  启动 buildkitd
  Terminal window
  1 systemctl daemon-reload 2 systemctl enable buildkit --now 3 systemctl status buildkit
  image-20231016134709582
4. 重新执行构建命令
  Terminal window
  1 nerdctl build -t nginx:nerdctl -f Dockerfile .
  image-20231016135200764
单机环境下使用 Docker Compose，在 containerd 模式下，也可以使用 nerdctl 来兼容该功能。同样可以使用 nerdctl compose、nerdctl compose up、nerdctl compose logs、nerdctl compose build、nerdctl compose down 等命令来管理 Compose 服务。这样使用 containerd、nerdctl 结合 buildkit 等工具就完全可以替代 docker 在镜像构建、镜像容器方面的管理功能了。

YAML文件格式以及如何编写Kubernetes的YAML类型的资源清单文件

Mon, 16 Oct 2023 00:00:00 GMT

YAML 文件#

YAML 是专门用来写配置文件的语言，非常简洁和强大，远比 JSON 格式方便。YAML语言（发音 /ˈjæməl/）的设计目标，就是方便人类读写。它实质上是一种通用的数据串行化格式。

它的基本语法规则如下：

大小写敏感
使用缩进表示层级关系
缩进时不允许使用Tab键，只允许使用空格
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
# 表示注释，从这个字符一直到行尾，都会被解析器忽略

在 Kubernetes 中，只需要了解两种结构类型就行了：

Maps（字典）
Lists（列表）

Maps#

Map 是字典，就是一个 key 的键值对，Maps 可以更加方便的去书写配置信息，例如：

1
---
2
apiVersion: v1
3
kind: Pod

第一行的---是分隔符，是可选的，在单一文件中，可用连续三个连字号---区分多个文件。这里可以看到有两个键：kind 和 apiVersion，他们对应的值分别是：v1 和 Pod。上面的 YAML 文件转换成 JSON 格式如下：

1
{
2
  "apiVersion": "v1",
3
  "kind": "pod"
4
}

在创建一个相对复杂一点的 YAML 文件，创建一个 KEY 对应的值不是字符串而是一个 Maps

1
---
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: tianch
6
  labels:
7
    app: web

上面的 YAML 文件，metadata 这个 KEY 对应的值就是一个 Maps ，而且嵌套的 labels 这个 KEY 的值又是一个 Map，可以根据自己的情况进行多层嵌套。

YAML 处理器是根据行缩进来知道内容之间的关联性的。比如我们上面的 YAML 文件，用两个空格作为缩进，空格的数量并不重要，但是得保持一致，并且至少要求一个空格（什么意思？就是别一会缩进两个空格，一会缩进 4 个空格）。可以看到 name 和 labels 是相同级别的缩进，所以 YAML 处理器就知道了它们属于同一个 Map，而 app 是 labels 的值所以 app 的缩进更大。

!!! warning “注意”

1
注意：在 YAML 文件中绝对不要使用 tab 键来进行缩进。

将上面的 YAML 文件转换成 JSON 文件：

1
{
2
  "apiVersion": "v1",
3
  "kind": "Pod",
4
  "metadata": {
5
    "name": "tianch",
6
    "labels": {
7
      "app": "web"
8
    }
9
  }
10
}

Lists#

Lists就是列表，说白了就是数组，在 YAML 文件中可以这样定义

1
args
2
- Cat
3
- Dog
4
- Fish

可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，与父元素之间可以缩进也可以不缩进。对应的 JSON 格式如下：

1
{
2
  "args": ["Cat", "Dog", "Fish"]
3
}

Lists 的子项也可以是 Maps，Maps 的子项也可以是 Lists 如下所示

1
---
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: tianch
6
  labels:
7
    app: web
8
spec:
9
  containers:
10
    - name: nginx-demo
11
      image: nginx
12
      ports:
13
        - containerPort: 80
14
    - name: busybox-demo
15
      image: busybox
16
      ports:
17
        - containerPort: 5000

展开收起

上面这个 YAML 文件定义了一个叫 containers 的 List 对象，每个子项都由 name、image、ports 组成，每个 ports 都有一个 key 为 containerPort 的 Map 组成，可以转成如下 JSON 格式文件：

1
{
2
  "apiVersion": "v1",
3
  "kind": "Pod",
4
  "metadata": {
5
    "name": "tianch",
6
    "labels": {
7
      "app": "web"
8
    }
9
  },
10
  "spec": {
11
    "containers": [
12
      {
13
        "name": "nginx-demo",
14
        "image": "nginx",
15
        "ports": [
16
          {
17
            "containerPort": "80"
18
          }
19
        ]
20
      },
21
      {
22
        "name": "busybox-demo",
23
        "image": "busybox",
24
        "ports": [
25
          {
26
            "containerPort": "5000"
27
          }
28
        ]
29
      }
30
    ]
31
  }
32
}

展开收起

如何编写YAML资源清单文件#

最简单的方法就是查找 Kubernetes API 文档，比如我们现在使用的是 v1.22.2 版本的集群，可以通过地址https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/查找到对应的 API 文档，在这个文档中我们可以找到所有资源对象的一些字段

比如要了解创建一个 Deployment 资源对象需要哪些字段，我们可以打开上面的 API 文档页面，在左侧侧边栏找到 Deployment v1 apps，就能找到 Deployment 需要提交的 Body 参数

image-20231016183744336

可以看到创建 Deployment 需要的一些字段，比如 apiVersion、kind、metadata、spec 等，而且每个字段都有对应的文档说明，要了解 DeploymentSpec 下面有哪些字段，继续点击进去查看就行

image-20231016183838537

每个字段具体什么含义以及每个字段下面是否还有其他字段都可以这样去追溯。

但是如果平时编写资源清单的时候都这样去查找文档势必会效率低下，Kubernetes 也考虑到了这点，可以直接通过 kubectl 命令行工具来获取这些字段信息，要获取 Deployment 的字段信息，可以通过 kubectl explain 命令来了解

Terminal window

1
kubectl explain deployment

1
KIND:     Deployment
2
VERSION:  apps/v1
3

4
DESCRIPTION:
5
     Deployment enables declarative updates for Pods and ReplicaSets.
6

7
FIELDS:
8
   apiVersion  <string>
9
     APIVersion defines the versioned schema of this representation of an
10
     object. Servers should convert recognized schemas to the latest internal
11
     value, and may reject unrecognized values. More info:
12
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
13

14
   kind  <string>
15
     Kind is a string value representing the REST resource this object
16
     represents. Servers may infer this from the endpoint the client submits
17
     requests to. Cannot be updated. In CamelCase. More info:
18
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
19

20
   metadata  <Object>
21
     Standard object's metadata. More info:
22
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
23

24
   spec  <Object>
25
     Specification of the desired behavior of the Deployment.
26

27
   status  <Object>
28
     Most recently observed status of the Deployment.

展开收起

上面的信息和 API 文档中基本一致，比如其中 spec 字段是一个 <Object> 类型的，证明该字段下面是一个对象，可以继续去查看这个字段下面的详细信息

Terminal window

1
kubectl explain deployment.spec

1
KIND:     Deployment
2
VERSION:  apps/v1
3

4
RESOURCE: spec <Object>
5

6
DESCRIPTION:
7
     Specification of the desired behavior of the Deployment.
8

9
     DeploymentSpec is the specification of the desired behavior of the
10
     Deployment.
11

12
FIELDS:
13
   minReadySeconds  <integer>
14
     Minimum number of seconds for which a newly created pod should be ready
15
     without any of its container crashing, for it to be considered available.
16
     Defaults to 0 (pod will be considered available as soon as it is ready)
17

18
   paused  <boolean>
19
     Indicates that the deployment is paused.
20

21
   progressDeadlineSeconds  <integer>
22
     The maximum time in seconds for a deployment to make progress before it is
23
     considered to be failed. The deployment controller will continue to process
24
     failed deployments and a condition with a ProgressDeadlineExceeded reason
25
     will be surfaced in the deployment status. Note that progress will not be
26
     estimated during the time a deployment is paused. Defaults to 600s.
27

28
   replicas  <integer>
29
     Number of desired pods. This is a pointer to distinguish between explicit
30
     zero and not specified. Defaults to 1.
31

32
   revisionHistoryLimit  <integer>
33
     The number of old ReplicaSets to retain to allow rollback. This is a
34
     pointer to distinguish between explicit zero and not specified. Defaults to
35
     10.
36

37
   selector  <Object> -required-
38
     Label selector for pods. Existing ReplicaSets whose pods are selected by
39
     this will be the ones affected by this deployment. It must match the pod
40
     template's labels.
41

42
   strategy  <Object>
43
     The deployment strategy to use to replace existing pods with new ones.
44

45
   template  <Object> -required-
46
     Template describes the pods that will be created.

展开收起

如果一个字段显示的是 required，就证明该字段是必填的，也就是在创建这个资源对象的时候必须声明这个字段，每个字段的类型也都进行了说明，所以有了 kubectl explain 这个命令完全可以写出一个不熟悉的资源对象的清单文件。

在Kubernetes集群上创建第一个容器化应用

Mon, 16 Oct 2023 00:00:00 GMT

YAML 资源清单文件#

Kubernetes 集群已经搭建成功了，现在就可以在集群里面来跑应用了。要在集群里面运行应用，首先需要知道几个概念。

第一个是应用的镜像，因为在集群中运行的是容器，所以首先需要将应用打包成镜像。镜像准备好了，Kubernetes 集群也准备好了，就可以把应用部署到集群中了。但是镜像到集群中运行这个过程如何完成呢？必然有一个地方可以来描述我们的应用，然后把这份描述告诉集群，然后集群按照这个描述来部署应用。

在之前 Docker 环境下面是直接通过命令 docker run 来运行应用的，在 Kubernetes 环境下面同样也可以用类似 kubectl run 这样的命令来运行应用，但是在 Kubernetes 中却是不推荐使用命令行的方式，而是希望使用称为资源清单的东西来描述应用，资源清单可以用 YAML 或者 JSON 文件来编写，一般来说 YAML 文件更方便阅读和理解。

通过一个资源清单文件来定义好一个应用后，就可以通过 kubectl 工具来直接运行它：

Terminal window

1
kubectl create -f xxxx.yaml

kubectl 是直接操作 APIServer 的，所以就相当于把资源清单提交给了 APIServer，然后集群获取到清单描述的应用信息后存入到 etcd 数据库中，然后 kube-scheduler 组件发现这个时候有一个 Pod 还没有绑定到节点上，就会对这个 Pod 进行一系列的调度，把它调度到一个最合适的节点上，然后把这个节点和 Pod 绑定到一起（写回到 etcd），然后节点上的 kubelet 组件这个时候 watch 到有一个 Pod 被分配过来了，就去把这个 Pod 的信息拉取下来，然后根据描述通过容器运行时把容器创建出来，最后当然同样把 Pod 状态再写回到 etcd 中去，这样就完成了一整个的创建流程。

第一个容器化应用#

通过 YAML 文件编写了一个如下的资源清单，命名为 first-demo.yaml

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

展开收起

应用yaml文件

Terminal window

1
kubectl apply -f first-demo.yaml

查看创建的pod

Terminal window

1
kubectl get pod -n default

根据标签查看创建的pod

Terminal window

1
kubectl get pod -l app=nginx -n default

根据标签查看创建的deployment

Terminal window

1
kubectl get deployment -l chapter=first-app -n default

image-20231016174103937

查看某一个pod的详细信息

Terminal window

1
kubectl describe pod nginx-deploy-6d777db949-22r26 -n default

1
[C:\~]$ kubectl describe pod nginx-deploy-6d777db949-22r26 -n default
2
Name:             nginx-deploy-6d777db949-22r26
3
Namespace:        default
4
Priority:         0
5
Service Account:  default
6
Node:             node2/10.168.1.22
7
Start Time:       Mon, 16 Oct 2023 17:12:42 +0800
8
Labels:           app=nginx
9
                  pod-template-hash=6d777db949
10
Annotations:      cni.projectcalico.org/containerID: e46e5e8727a8c9bc31eef509b627035a6139dfbd60bc99dd0b23cb6483bfae30
11
                  cni.projectcalico.org/podIP: 10.233.96.30/32
12
                  cni.projectcalico.org/podIPs: 10.233.96.30/32
13
Status:           Running
14
IP:               10.233.96.30
15
IPs:
16
  IP:           10.233.96.30
17
Controlled By:  ReplicaSet/nginx-deploy-6d777db949
18
Containers:
19
  nginx:
20
    Container ID:   containerd://868fe141d9e9caf702df468e792288138a94c0110029f8908874abbb6d25e9d1
21
    Image:          nginx:1.20
22
    Image ID:       docker.io/library/nginx@sha256:38f8c1d9613f3f42e7969c3b1dd5c3277e635d4576713e6453c6193e66270a6d
23
    Port:           <none>
24
    Host Port:      <none>
25
    State:          Running
26
      Started:      Mon, 16 Oct 2023 17:13:31 +0800
27
    Ready:          True
28
    Restart Count:  0
29
    Environment:    <none>
30
    Mounts:
31
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-96zwq (ro)
32
Conditions:
33
  Type              Status
34
  Initialized       True
35
  Ready             True
36
  ContainersReady   True
37
  PodScheduled      True
38
Volumes:
39
  kube-api-access-96zwq:
40
    Type:                    Projected (a volume that contains injected data from multiple sources)
41
    TokenExpirationSeconds:  3607
42
    ConfigMapName:           kube-root-ca.crt
43
    ConfigMapOptional:       <nil>
44
    DownwardAPI:             true
45
QoS Class:                   BestEffort
46
Node-Selectors:              <none>
47
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
48
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
49
Events:
50
  Type     Reason       Age   From               Message
51
  ----     ------       ----  ----               -------
52
  Normal   Scheduled    27m   default-scheduler  Successfully assigned default/nginx-deploy-6d777db949-22r26 to node2
53
  Warning  FailedMount  27m   kubelet            MountVolume.SetUp failed for volume "kube-api-access-96zwq" : failed to sync configmap cache: timed out waiting for the condition
54
  Normal   Pulling      27m   kubelet            Pulling image "nginx:1.20"
55
  Normal   Pulled       27m   kubelet            Successfully pulled image "nginx:1.20" in 46.065135121s
56
  Normal   Created      27m   kubelet            Created container nginx
57
  Normal   Started      27m   kubelet            Started container nginx

展开收起

可以看到看到很多这个 Pod 的详细信息，比如调度到的节点、状态、IP 等，一般比较关心的是下面的 Events 部分，就是我们说的事件。

在 Kubernetes 创建资源对象的过程中，对该对象的一些重要操作，都会被记录在这个对象的 Events 里面，可以通过 kubectl describe 指令查看对应的结果。所以这个指令也会是以后排错过程中会经常使用的命令。比如上面描述的这个 Pod，可以看到它被创建之后，被调度器调度（Successfully assigned）到了 node2 节点上，然后指定的镜像在该节点上不存在，然后去拉取镜像，然后创建我们定义的 nginx 容器，最后启动定义的容器。

另外一个方面如果应用进行升级的话应该怎么办呢？这个操作在我们日常工作中还是非常常见的，而在 Kubernetes 里也是非常简单的，只需要修改资源清单文件即可，比如把镜像升级到最新版本 nginx:latest

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deploy
5
  labels:
6
    chapter: first-app
7
spec:
8
  selector:
9
    matchLabels:
10
      app: nginx
11
  replicas: 2
12
  template:
13
    metadata:
14
      labels:
15
        app: nginx
16
    spec:
17
      containers:
18
        - name: nginx
19
          image: nginx:latest # 这里被从 1.20 修改为latest

展开收起

可以通过kubectl apply命令来直接更新，这个命令也是推荐使用的，不必关心当前的操作是创建还是更新，执行的命令始终是 kubectl apply，Kubernetes 则会根据 YAML 文件的内容变化，自动进行具体的处理，所以无论是创建还是更新都可以直接使用这个命令

Terminal window

1
kubectl apply -f first-demo.yaml

命令就可以来更新应用了，由于这里使用的是一个 Deployment 的控制器，所以会滚动更新应用，可以通过在命令后面加上 --watch 参数来查看 Pod 的更新过程,过程是从下往上看

Terminal window

1
kubectl get pods -l app=nginx -n default --watch

image-20231016175247637

更新过程是先杀掉了一个 Pod，然后又重新创建了一个新的 Pod，然后又杀掉一个旧的 Pod，再创建一个新的 Pod，这样交替替换的，最后剩下两个新的 Pod，这就是滚动更新，滚动更新对于应用持续提供服务是非常重要的手段，在日常工作中更新应用肯定会采用这种方式。

最后，如果需要把应用从集群中删除掉，可以用 kubectl delete 命令来清理

Terminal window

1
kubectl delete -f first-demo.yaml

Containerd的安装和使用

Sun, 15 Oct 2023 00:00:00 GMT

containerd 架构

安装#

我的系统是 CentOS 7.9

安装 `seccomp` 依赖：#

缺少依赖或依赖版本过低后面启动容器会报错

image-20231015233431916

【报错原因】缺少依赖包libseccomp（2.4以上版本）

【解决办法】安装libseccomp 2.5.1

Terminal window

1
# 查看是否安装libseccomp
2
rpm -qa |grep libseccomp
3

4
# 卸载2.3.1版本
5
yum remove libseccomp -y
6

7
# 安装2.5.1
8
wget http://rpmfind.net/linux/centos/8-stream/BaseOS/x86_64/os/Packages/libseccomp-2.5.1-1.el8.x86_64.rpm
9
rpm -ivh libseccomp-2.5.1-1.el8.x86_64.rpm

安装Containerd#

由于 containerd 需要调用 runc，所以需要先安装 runc，不过 containerd 提供了一个包含相关依赖的压缩包 cri-containerd-cni-${VERSION}.${OS}-${ARCH}.tar.gz，可以直接使用这个包来进行安装。release页面

Terminal window

1
yum install -y wget
2

3
wget https://github.com/containerd/containerd/releases/download/v1.7.7/cri-containerd-cni-1.7.7-linux-amd64.tar.gz
4
# 如果有限制，也可以替换成下面的 URL 加速下载
5
# wget https://download.fastgit.org/containerd/containerd/releases/download/v1.7.7/cri-containerd-cni-1.7.7-linux-amd64.tar.gz

可以通过 tar 的 -t 选项直接看到压缩包中包含哪些文件：

Terminal window展开收起

1
tar -tf cri-containerd-cni-1.7.7-linux-amd64.tar.gz
2

3
cri-containerd.DEPRECATED.txt
4
etc/
5
etc/cni/
6
etc/cni/net.d/
7
etc/cni/net.d/10-containerd-net.conflist
8
etc/crictl.yaml
9
etc/systemd/
10
etc/systemd/system/
11
etc/systemd/system/containerd.service
12
usr/
13
usr/local/
14
usr/local/sbin/
15
usr/local/sbin/runc
16
usr/local/bin/
17
usr/local/bin/ctd-decoder
18
usr/local/bin/critest
19
usr/local/bin/containerd-shim-runc-v1
20
usr/local/bin/containerd-stress
21
usr/local/bin/containerd-shim-runc-v2
22
usr/local/bin/containerd
23
usr/local/bin/containerd-shim
24
usr/local/bin/ctr
25
usr/local/bin/crictl
26
opt/
27
opt/cni/
28
opt/cni/bin/
29
opt/cni/bin/host-device
30
opt/cni/bin/macvlan
31
opt/cni/bin/host-local
32
opt/cni/bin/vlan
33
opt/cni/bin/bandwidth
34
opt/cni/bin/tuning
35
opt/cni/bin/dhcp
36
opt/cni/bin/ptp
37
opt/cni/bin/portmap
38
opt/cni/bin/dummy
39
opt/cni/bin/vrf
40
opt/cni/bin/loopback
41
opt/cni/bin/static
42
opt/cni/bin/ipvlan
43
opt/cni/bin/firewall
44
opt/cni/bin/bridge
45
opt/cni/bin/sbr
46
opt/containerd/
47
opt/containerd/cluster/
48
opt/containerd/cluster/gce/
49
opt/containerd/cluster/gce/env
50
opt/containerd/cluster/gce/cloud-init/
51
opt/containerd/cluster/gce/cloud-init/master.yaml
52
opt/containerd/cluster/gce/cloud-init/node.yaml
53
opt/containerd/cluster/gce/cni.template
54
opt/containerd/cluster/gce/configure.sh
55
opt/containerd/cluster/version

展开收起

将压缩包解压到系统目录

Terminal window

1
tar -C / -xzf cri-containerd-cni-1.7.7-linux-amd64.tar.gz

将 /usr/local/bin 和 /usr/local/sbin 追加到 ~/.bashrc 文件的 PATH 环境变量中

Terminal window

1
vim ~/.bashrc
2

3
# 将下面这行代码追加到文件最后一行
4
export PATH=$PATH:/usr/local/bin:/usr/local/sbin

立即生效

Terminal window

1
source ~/.bashrc

containerd 的默认配置文件为 /etc/containerd/config.toml，通过命令生成一个默认的配置

Terminal window

1
mkdir -p /etc/containerd
2
containerd config default > /etc/containerd/config.toml

version =2 ：这个是新本版基本默认的选项。
root：containerd保存元数据的地方。
state: containerd的状态目录，重启数据就会刷新，就一个临时目录。
address: 这个指的是containerd监听的套接字。
plugins: 其中sandbox_image配置的是cni的插件，
以及配置的cni的二进制目录和初始化目录；还有配置的私有库的地址，证书，访问的用户密码
path: container的二进制文件路径
interval
runtime：这部分配置需要的运行时runc,containerd-shim这个垫片可以选择用或者不用

下载的 containerd 压缩包中包含一个 etc/systemd/system/containerd.service 的文件，这样我们就可以通过 systemd 来配置 containerd 作为守护进程运行了，内容如下

Terminal window展开收起

1
cat /etc/systemd/system/containerd.service
2

3
# Copyright The containerd Authors.
4
#
5
# Licensed under the Apache License, Version 2.0 (the "License");
6
# you may not use this file except in compliance with the License.
7
# You may obtain a copy of the License at
8
#
9
#     http://www.apache.org/licenses/LICENSE-2.0
10
#
11
# Unless required by applicable law or agreed to in writing, software
12
# distributed under the License is distributed on an "AS IS" BASIS,
13
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
14
# See the License for the specific language governing permissions and
15
# limitations under the License.
16

17
[Unit]
18
Description=containerd container runtime
19
Documentation=https://containerd.io
20
After=network.target local-fs.target
21

22
[Service]
23
#uncomment to enable the experimental sbservice (sandboxed) version of containerd/cri integration
24
#Environment="ENABLE_CRI_SANDBOXES=sandboxed"
25
ExecStartPre=-/sbin/modprobe overlay
26
ExecStart=/usr/local/bin/containerd
27

28
Type=notify
29
Delegate=yes
30
KillMode=process
31
Restart=always
32
RestartSec=5
33
# Having non-zero Limit*s causes performance problems due to accounting overhead
34
# in the kernel. We recommend using cgroups to do container-local accounting.
35
LimitNPROC=infinity
36
LimitCORE=infinity
37
LimitNOFILE=infinity
38
# Comment TasksMax if your systemd version does not supports it.
39
# Only systemd 226 and above support this version.
40
TasksMax=infinity
41
OOMScoreAdjust=-999
42

43
[Install]
44
WantedBy=multi-user.target

展开收起

这里有两个重要的参数：

Delegate: 这个选项允许 containerd 以及运行时自己管理自己创建容器的 cgroups。如果不设置这个选项，systemd 就会将进程移到自己的 cgroups 中，从而导致 containerd 无法正确获取容器的资源使用情况。
KillMode: 这个选项用来处理 containerd 进程被杀死的方式。默认情况下，systemd 会在进程的 cgroup 中查找并杀死 containerd 的所有子进程。KillMode 字段可以设置的值如下。
- control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
- process：只杀主进程
- mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
- none：没有进程会被杀掉，只是执行服务的 stop 命令

需要将 KillMode 的值设置为 process，这样可以确保升级或重启 containerd 时不杀死现有的容器。

启动Containerd 并设置成开机启动#

Terminal window

1
systemctl enable containerd --now

查看和验证#

启动完成后就可以使用 containerd 的本地 CLI 工具 ctr 了，比如查看版本

1
ctr -v
2
ctr version

image-20231015223026051

配置文件解析#

生成的默认配置文件/etc/containerd/config.toml

每一个顶级配置块的命名都是 plugins."io.containerd.xxx.vx.xxx" 这种形式，每一个顶级配置块都表示一个插件，其中 io.containerd.xxx.vx 表示插件的类型，vx 后面的 xxx 表示插件的 ID，我们可以通过 ctr 查看插件列表:

Terminal window

1
ctr plugin ls

image-20231015223702053

顶级配置块下面的子配置块表示该插件的各种配置，比如 cri 插件下面就分为 containerd、cni 和 registry 的配置，而 containerd 下面又可以配置各种 runtime，还可以配置默认的 runtime。比如现在我们要为镜像配置一个加速器，那么就需要在 cri 配置块下面的 registry 配置块下面进行配置 registry.mirrors：

Terminal window

1
[plugins."io.containerd.grpc.v1.cri".registry]
2
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
3
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
4
      endpoint = ["https://akqgo94r.mirror.aliyuncs.com"]
5
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."k8s.gcr.io"]
6
      endpoint = ["https://registry.aliyuncs.com/k8sxio"]

registry.mirrors."xxx": 表示需要配置 mirror 的镜像仓库，例如 registry.mirrors."docker.io" 表示配置 docker.io 的 mirror。
endpoint: 表示提供 mirror 的镜像加速服务，比如我们可以注册一个阿里云的镜像服务来作为 docker.io 的 mirror。

另外在默认配置中还有两个关于存储的配置路径：

Terminal window

1
root = "/var/lib/containerd"
2
state = "/run/containerd"

其中 root 是用来保存持久化数据，包括 Snapshots, Content, Metadata 以及各种插件的数据，每一个插件都有自己单独的目录，Containerd 本身不存储任何数据，它的所有功能都来自于已加载的插件。

而另外的 state 是用来保存运行时的临时数据的，包括 sockets、pid、挂载点、运行时状态以及不需要持久化的插件数据。

Containerd的使用#

帮助#
Terminal window
```
1
ctr
```
image-20231015224611650
拉取镜像#
拉取镜像可以使用 ctr image pull 来完成，比如拉取 Docker Hub 官方镜像 nginx:alpine，需要注意的是镜像地址需要加上 docker.io Host 地址
Terminal window
```
1
ctr image pull docker.io/library/nginx:alpine
```
image-20231015224830196
镜像列表

images可以简写成image 或者直接简写成i

list可以简写成ls
Terminal window
```
1
ctr images list
2
ctr image list
3
ctr i list
4

5
ctr images ls
6
ctr image ls
7
ctr i ls
```
image-20231015225437782

使用 -q（--quiet） 选项可以只打印镜像名称
Terminal window
```
1
ctr images list -q
2
ctr image list -q
3
ctr i list -q
4

5
ctr images ls -q
6
ctr image ls -q
7
ctr i ls -q
```
image-20231015225642753
检测本地镜像#
主要查看其中的 STATUS，complete 表示镜像是完整可用的状态
Terminal window
```
1
ctr i check
```
image-20231015225748148

重新打Tag#

Terminal window

1
ctr image tag docker.io/library/nginx:alpine harbor.k8s.local/tianch/nginx:alpine

image-20231015225953125

image-20231015230027828

删除镜像#
不需要使用的镜像也可以使用 ctr image rm 进行删除
Terminal window
```
1
ctr image rm harbor.k8s.local/tianch/nginx:alpine
```
image-20231015230146446
加上 --sync 选项可以同步删除镜像和所有相关的资源
将镜像挂载到主机目录#
Terminal window
```
1
ctr image mount docker.io/library/nginx:alpine /mnt
2
tree -L 1 /mnt
```
没有tree命令使用yum安装一下
Terminal window
```
1
yum install -y tree
```
image-20231015230356220
将镜像从主机目录卸载#
Terminal window
```
1
ctr image unmount /mnt
```
image-20231015230633929
镜像导出#
Terminal window
```
1
ctr image export --all-platforms nginx.tar.gz docker.io/library/nginx:alpine
```
可能会出现类似于 ctr: content digest sha256:xxxxxx not found 的错误，解决办法需要 pull 所有平台镜像
image-20231015230924372
Terminal window
```
1
ctr i pull --all-platforms docker.io/library/nginx:alpine
```
再重新执行导出命令
image-20231015231153565
镜像导入#
Terminal window
```
1
ctr i import nginx.tar.gz
```
image-20231015231648205
创建容器#
containers可以简写为container或者c
Terminal window
```
1
ctr c create docker.io/library/nginx:alpine nginx
```
容器列表#
Terminal window
```
1
ctr c ls
```
同样可以加上 -q 选项精简列表内容
image-20231015232054569
查看容器详细配置#
类似于 docker inspect 功能
Terminal window
```
1
ctr c info nginx
```
删除容器#
rm也可换成remove delete del
Terminal window
```
1
ctr c rm nginx
```
image-20231015232301141
启动容器#
tasks可以写成task 或者t
通过 container create 命令创建的容器，并没有处于运行状态，只是一个静态的容器。一个 container 对象只是包含了运行一个容器所需的资源及相关配置数据，表示 namespaces、rootfs 和容器的配置都已经初始化成功了，只是用户进程还没有启动。
一个容器真正运行起来是由 Task 任务实现的，Task 可以为容器设置网卡，还可以配置工具来对容器进行监控等。
Task 相关操作可以通过 ctr task 获取，如下我们通过 Task 来启动容器
Terminal window
```
1
ctr task start -d nginx
```
image-20231015233813044
进入容器#
Terminal window
```
1
ctr task exec -t --exec-id 0 nginx sh
```
image-20231015234004576
必须要指定 --exec-id 参数，这个 id 可以随便写，只要唯一就行
暂停容器#
和 docker pause 类似
Terminal window
```
1
ctr task pause nginx
```
image-20231015234137929
恢复容器#
Terminal window
```
1
ctr task resume nginx
```
image-20231015234228568
ctr 没有 stop 容器的功能，只能暂停或者kill掉容器
杀掉容器#
Terminal window
```
1
ctr task kill nginx
```
image-20231015234414953
限额与使用量#
Terminal window
```
1
ctr task metrics nginx
```
image-20231015235005852
还可以使用 task ps 命令查看容器中所有进程在宿主机中的 PID
Terminal window
```
1
ctr t ps nginx
```
image-20231015235111771
其中第一个 PID 就是容器中的 1 号进程

命名空间#

namespaces可以简写成namespace ns 如果不指定，ctr 默认使用的是 default 空间

Docker 其实也是默认调用的 containerd，事实上 Docker 使用的 containerd 下面的命名空间默认是 moby，而不是 default，所以用 docker 启动容器，可以通过 ctr -n moby 来定位下面的容器

Terminal window

1
ctr -n moby container ls

image-20231016000255901

同样 Kubernetes 下使用的 containerd 默认命名空间是 k8s.io，所以我们可以使用 ctr -n k8s.io 来查看 Kubernetes 下面创建的容器

查看命名空间#
Terminal window
```
1
ctr ns ls
```
image-20231015235354973
创建命名空间#
create可以简写成c
Terminal window
```
1
ctr ns create tianch
```
image-20231015235539993
删除命名空间#
remove可以简写成rm
Terminal window
```
1
ctr ns remove tianch
```
image-20231015235800678
指定命名空间#
Terminal window
```
1
ctr -n default image ls -q
```
image-20231015235944352

使用KubeKey安装Kubernetes集群

Fri, 13 Oct 2023 00:00:00 GMT

创建主机#

主机IP	主机名称	角色
10.168.1.20	master	master, etcd
10.168.1.21	node1	worker
10.168.1.22	node2	worker
10.168.1.23	node3	worker
10.168.1.100	nfs	nfs-server

创建NFS持久化存储服务器#

关闭防火墙#

Terminal window

1
systemctl stop firewalld.service
2
systemctl disable firewalld.service

安装nfs#

Terminal window

1
yum -y install nfs-utils rpcbind

配置共享目录#

Terminal window

1
mkdir -p /opt/nfs
2
chmod 755 /opt/nfs

配置nfs#

nfs 的默认配置文件在 /etc/exports 文件下，在该文件中添加下面的配置信息

Terminal window

1
vim /etc/exports
2
/opt/nfs  10.168.1.0/24(rw,sync,no_root_squash)

配置说明：

/opt/nfs：是共享的数据目录
*：表示任何人都有权限连接，当然也可以是一个网段，一个 IP，也可以是域名这里写10.168.1.0/24 我的内网网段
rw：读写的权限
sync：表示文件同时写入硬盘和内存
no_root_squash：当登录 NFS 主机使用共享目录的使用者是 root 时，其权限将被转换成为匿名使用者，通常它的 UID 与 GID，都会变成 nobody 身份

启动服务#

nfs 需要向 rpc 注册，rpc 一旦重启了，注册的文件都会丢失，向他注册的服务都需要重启注意启动顺序，先启动 rpcbind

启动rpcbind服务#

Terminal window

1
systemctl start rpcbind.service
2
systemctl enable rpcbind
3
systemctl status rpcbind

image-20231013164935829

看到上面的 active 证明启动成功了

启动nfs服务#

Terminal window

1
systemctl start nfs.service
2
systemctl enable nfs
3
systemctl status nfs

image-20231013165243369

看到上面的 active 证明启动成功了

查看目录挂载权限#

Terminal window

1
cat /var/lib/nfs/etab

image-20231013165418547

在各个节点安装nfs客户端#

关闭防火墙#

Terminal window

1
systemctl stop firewalld.service
2
systemctl disable firewalld.service

安装nfs#

Terminal window

1
yum -y install nfs-utils rpcbind

启动服务#

nfs 需要向 rpc 注册，rpc 一旦重启了，注册的文件都会丢失，向他注册的服务都需要重启注意启动顺序，先启动 rpcbind

启动rpcbind服务#

Terminal window

1
systemctl start rpcbind.service
2
systemctl enable rpcbind
3
systemctl status rpcbind

image-20231013164935829

看到上面的 active 证明启动成功了

启动nfs服务#

Terminal window

1
systemctl start nfs.service
2
systemctl enable nfs
3
systemctl status nfs

image-20231013165243369

看到上面的 active 证明启动成功了

挂载数据目录#

Terminal window

1
showmount -e 10.168.1.100

image-20231013165832419

创建nfs存储配置文件#

Terminal window

1
vim nfs-client.yaml

1
nfs:
2
  server: "10.168.1.100" # This is the server IP address. Replace it with your own.
3
  path: "/opt/nfs" # Replace the exported directory with your own.
4
storageClass:
5
  defaultClass: false

下载KubeKey#

Terminal window

1
# 国内最好使用国内镜像 能访问GitHub和Googleapis则不需要执行`export KKZONE=cn`这条命令
2
export KKZONE=cn
3

4
# 下载最新稳定版本的KubeKey
5
curl -sfL https://get-kk.kubesphere.io | sh -
6

7
# 如果要下载指定版本的KubeKey 则通过VERSION执行版本 例如下载v3.1.0-alpha.5版本的KubeKey
8
# kubernetes版本过新的话需要使用最新开发版 去https://github.com/kubesphere/kubekey/releases里找
9
# 不然会出现 No SHA256 found for kubeadm. v1.26.9 is not supported 类似的错误
10
curl -sfL https://get-kk.kubesphere.io | VERSION=v3.1.0-alpha.5 sh -

image-20231013161100943

安装Kubernetes和KubeSphere#

给`kk`添加可执行权限#

Terminal window

1
chmod +x kk

创建配置文件#

Terminal window

1
./kk create config --with-kubernetes v1.23.10  --with-kubesphere v3.3.2

如果不指定配置文静名称默认为config-sample.yaml

备注

安装 KubeSphere 3.4 的建议 Kubernetes 版本：v1.20.x、v1.21.x、_ v1.22.x、_ v1.23.x、_ v1.24.x、_ v1.25.x 和 * v1.26.x。带星号的版本可能出现边缘节点部分功能不可用的情况。因此，如需使用边缘节点，推荐安装 v1.21.x。如果不指定 Kubernetes 版本，KubeKey 将默认安装 Kubernetes v1.23.10。有关受支持的 Kubernetes 版本的更多信息，请参见支持矩阵。
如果您在这一步的命令中不添加标志 --with-kubesphere，则不会部署 KubeSphere，只能使用配置文件中的 addons 字段安装，或者在您后续使用 ./kk create cluster 命令时再次添加这个标志。
如果您添加标志 --with-kubesphere 时不指定 KubeSphere 版本，则会安装最新版本的 KubeSphere。

编辑配置文件#

Terminal window

1
vim config-sample.yaml

1
apiVersion: kubekey.kubesphere.io/v1alpha2
2
kind: Cluster
3
metadata:
4
  name: sample
5
spec:
6
  hosts:
7
    - {
8
        name: master,
9
        address: 10.168.1.20,
10
        internalAddress: 10.168.1.20,
11
        user: root,
12
        password: "root",
13
      }
14
    - {
15
        name: node1,
16
        address: 10.168.1.21,
17
        internalAddress: 10.168.1.21,
18
        user: root,
19
        password: "root",
20
      }
21
    - {
22
        name: node2,
23
        address: 10.168.1.22,
24
        internalAddress: 10.168.1.22,
25
        user: root,
26
        password: "root",
27
      }
28
    - {
29
        name: node3,
30
        address: 10.168.1.23,
31
        internalAddress: 10.168.1.23,
32
        user: root,
33
        password: "root",
34
      }
35
  roleGroups:
36
    etcd:
37
      - master
38
    control-plane:
39
      - master
40
    worker:
41
      - node1
42
      - node2
43
      - node3
44
  controlPlaneEndpoint:
45
    ## Internal loadbalancer for apiservers
46
    # internalLoadbalancer: haproxy
47

48
    domain: lb.kubesphere.local
49
    address: ""
50
    port: 6443
51
  kubernetes:
52
    version: v1.23.10
53
    clusterName: cluster.local
54
    autoRenewCerts: true
55
    containerManager: containerd
56
  etcd:
57
    type: kubekey
58
  network:
59
    plugin: calico
60
    kubePodsCIDR: 10.233.64.0/18
61
    kubeServiceCIDR: 10.233.0.0/18
62
    ## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
63
    multusCNI:
64
      enabled: false
65
  registry:
66
    privateRegistry: ""
67
    namespaceOverride: ""
68
    registryMirrors: []
69
    insecureRegistries: []
70
  addons:
71
    - name: nfs-client
72
      namespace: kube-system
73
      sources:
74
        chart:
75
          name: nfs-client-provisioner
76
          repo: https://charts.kubesphere.io/main
77
          valuesFile: /root/nfs-client.yaml
78

79
---
80
apiVersion: installer.kubesphere.io/v1alpha1
81
kind: ClusterConfiguration
82
metadata:
83
  name: ks-installer
84
  namespace: kubesphere-system
85
  labels:
86
    version: v3.3.2
87
spec:
88
  persistence:
89
    storageClass: ""
90
  authentication:
91
    jwtSecret: ""
92
  zone: ""
93
  local_registry: ""
94
  namespace_override: ""
95
  # dev_tag: ""
96
  etcd:
97
    monitoring: false
98
    endpointIps: localhost
99
    port: 2379
100
    tlsEnable: true
101
  common:
102
    core:
103
      console:
104
        enableMultiLogin: true
105
        port: 30880
106
        type: NodePort
107
    # apiserver:
108
    #  resources: {}
109
    # controllerManager:
110
    #  resources: {}
111
    redis:
112
      enabled: false
113
      volumeSize: 2Gi
114
    openldap:
115
      enabled: false
116
      volumeSize: 2Gi
117
    minio:
118
      volumeSize: 20Gi
119
    monitoring:
120
      # type: external
121
      endpoint: http://prometheus-operated.kubesphere-monitoring-system.svc:9090
122
      GPUMonitoring:
123
        enabled: false
124
    gpu:
125
      kinds:
126
        - resourceName: "nvidia.com/gpu"
127
          resourceType: "GPU"
128
          default: true
129
    es:
130
      # master:
131
      #   volumeSize: 4Gi
132
      #   replicas: 1
133
      #   resources: {}
134
      # data:
135
      #   volumeSize: 20Gi
136
      #   replicas: 1
137
      #   resources: {}
138
      logMaxAge: 7
139
      elkPrefix: logstash
140
      basicAuth:
141
        enabled: false
142
        username: ""
143
        password: ""
144
      externalElasticsearchHost: ""
145
      externalElasticsearchPort: ""
146
  alerting:
147
    enabled: false
148
    # thanosruler:
149
    #   replicas: 1
150
    #   resources: {}
151
  auditing:
152
    enabled: false
153
    # operator:
154
    #   resources: {}
155
    # webhook:
156
    #   resources: {}
157
  devops:
158
    enabled: false
159
    # resources: {}
160
    jenkinsMemoryLim: 8Gi
161
    jenkinsMemoryReq: 4Gi
162
    jenkinsVolumeSize: 8Gi
163
  events:
164
    enabled: false
165
    # operator:
166
    #   resources: {}
167
    # exporter:
168
    #   resources: {}
169
    # ruler:
170
    #   enabled: true
171
    #   replicas: 2
172
    #   resources: {}
173
  logging:
174
    enabled: false
175
    logsidecar:
176
      enabled: true
177
      replicas: 2
178
      # resources: {}
179
  metrics_server:
180
    enabled: false
181
  monitoring:
182
    storageClass: ""
183
    node_exporter:
184
      port: 9100
185
      # resources: {}
186
    # kube_rbac_proxy:
187
    #   resources: {}
188
    # kube_state_metrics:
189
    #   resources: {}
190
    # prometheus:
191
    #   replicas: 1
192
    #   volumeSize: 20Gi
193
    #   resources: {}
194
    #   operator:
195
    #     resources: {}
196
    # alertmanager:
197
    #   replicas: 1
198
    #   resources: {}
199
    # notification_manager:
200
    #   resources: {}
201
    #   operator:
202
    #     resources: {}
203
    #   proxy:
204
    #     resources: {}
205
    gpu:
206
      nvidia_dcgm_exporter:
207
        enabled: false
208
        # resources: {}
209
  multicluster:
210
    clusterRole: none
211
  network:
212
    networkpolicy:
213
      enabled: false
214
    ippool:
215
      type: none
216
    topology:
217
      type: none
218
  openpitrix:
219
    store:
220
      enabled: false
221
  servicemesh:
222
    enabled: false
223
    istio:
224
      components:
225
        ingressGateways:
226
          - name: istio-ingressgateway
227
            enabled: false
228
        cni:
229
          enabled: false
230
  edgeruntime:
231
    enabled: false
232
    kubeedge:
233
      enabled: false
234
      cloudCore:
235
        cloudHub:
236
          advertiseAddress:
237
            - ""
238
        service:
239
          cloudhubNodePort: "30000"
240
          cloudhubQuicNodePort: "30001"
241
          cloudhubHttpsNodePort: "30002"
242
          cloudstreamNodePort: "30003"
243
          tunnelNodePort: "30004"
244
        # resources: {}
245
        # hostNetWork: false
246
      iptables-manager:
247
        enabled: true
248
        mode: "external"
249
        # resources: {}
250
      # edgeService:
251
      #   resources: {}
252
  terminal:
253
    timeout: 600

展开收起

安装#

Terminal window

1
./kk create cluster -f config-sample.yaml

安装日志查看

Terminal window

1
kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f

image-20231013181549212

到这里安装完成

Kubernetes 简介

Wed, 11 Oct 2023 00:00:00 GMT

Kubernetes（简称 K8S）的出现是容器化技术发展的必然结果，容器化是应用程序级别的虚拟化，运行单个内核上有多个独立的用户空间实例，这些实例就是容器；容器提供了将应用程序的代码、运行时、系统工具、系统库和配置打包到一个实例中的标准方法，而且容器是共享一个内核的；由于容器技术的兴起，导致大量的容器应用出现，所以就出现了一些用来支持应用程序容器化部署和组织的容器编排技术，一些流行的开源容器编排工具有 Docker Swarm、Kubernetes 等，但是在发展过程中 Kubernetes 现在已经成为了容器编排领域事实上的一个标准了。

kubernetes

Kubernetes 是 Google 团队发起的一个开源项目，它的目标是管理跨多个主机的容器，用于自动部署、扩展和管理容器化的应用程序，主要实现语言为 Go 语言，他的理论基础来源与 Google 内部的 Borg 项目，所以 Kubernetes 项目的理论基础就比其他开源项目要“先进”很多，因为 Borg 系统一直依赖就被称为 Google 公司内部最强大的“私密武器”。

架构#

Kubernetes 项目依托着 Borg 项目的理论优势，确定了一个如下图所示的全局架构图：

kubernetes arch

从上面我们可以看出 Kubernetes 由 Master 和 Node 两种节点组成，这两种角色分别对应着控制节点和工作节点（可以理解为老板和员工）。

其中 Master 节点由三个独立的组件组成，它们分别是负责整个集群通信的 API 服务的 kube-apiserver、负责容器调度的 kube-scheduler 以及负责维护集群状态的 kube-controller-manager 组件。整个集群的数据都是通过 kube-apiserver 保存到 etcd 数据库中的，而其他所有组件的通信也都是通过 kube-apiserver 和 etcd 数据库进行通信的，都不会直接和 etcd 进行通信。

工作节点上最核心的组件就是 kubelet，当然还有底层的容器运行时，比如 Docker，其中 kubelet 就是主要来实现和底层的容器运行时进行通信的，这个通信的过程也被 Kubernetes 抽象成了一个 CRI（Container Runtime Interface）的远程调用接口，这个接口里面定义了容器运行时的所有标准操作，比如创建容器、删除容器等等。所以对于 Kubernetes 来说他根本不关心你部署的到底是什么容器运行时，只要你这个容器运行时可以实现 CRI 接口就可以被 Kubernetes 来管理。

kubelet 的另外一个重要功能就是调用网络插件（CNI）和存储插件（CSI）为容器配置网络和存储功能，同样的 kubelet 也是把这两个重要功能通过接口暴露给外部了，所以如果我们想要实现自己的网络插件，只需要使用 CNI 就可以很方便的对接到 Kubernetes 集群当中去。

可能下面的架构图看上去更清晰一些：

kubernetes high level component archtecture

组件#

kube-apiserver#

API Server 提供了资源对象的唯一操作入口，其它所有组件都必须通过它提供的 API 来操作资源数据。只有 API Server 会与 etcd 进行通信，其它模块都必须通过 API Server 访问集群状态。API Server 作为 Kubernetes 系统的入口，封装了核心对象的增删改查操作。API Server 以 RESTFul 接口方式提供给外部客户端和内部组件调用，API Server 再对相关的资源数据（全量查询 + 变化监听）进行操作，以达到实时完成相关的业务功能。以 API Server 为 Kubernetes 入口的设计主要有以下好处：

保证了集群状态访问的安全
API Server 隔离了集群状态访问和后端存储实现，这样 API Server 状态访问的方式不会因为后端存储技术 Etcd 的改变而改变，让后端存储方式选择更加灵活，方便了整个架构的扩展

kube-controller-manager#

kube-controller-manager

Controller Manager 用于实现 Kubernetes 集群故障检测和恢复的自动化工作。主要负责执行各种控制器：

Replication Controller：主要是定期关联 Replication Controller (RC) 和 Pod，以保证集群中一个 RC (一种资源对象) 所关联的 Pod 副本数始终保持为与预设值一致。
Node Controller：Kubelet 在启动时会通过 API Server 注册自身的节点信息，并定时向 API Server 汇报状态信息。API Server 在接收到信息后将信息更新到 Etcd 中。Node Controller 通过 API Server 实时获取 Node 的相关信息，实现管理和监控集群中的各个 Node 节点的相关控制功能。
ResourceQuota Controller：资源配额管理控制器用于确保指定的资源对象在任何时候都不会超量占用系统上物理资源。
Namespace Controller：用户通过 API Server 可以创建新的 Namespace 并保存在 Etcd 中，Namespace Controller 定时通过 API Server 读取这些 Namespace 信息来操作 Namespace。比如：Namespace 被 API 标记为优雅删除，则将该 Namespace 状态设置为 Terminating 并保存到 Etcd 中。同时 Namespace Controller 删除该 Namespace 下的 ServiceAccount、Deployment、Pod 等资源对象。
Service Account Controller：服务账号控制器主要在命名空间内管理 ServiceAccount，以保证名为 default 的 ServiceAccount 在每个命名空间中存在。
Token Controller：令牌控制器作为 Controller Manager 的一部分，主要用作：监听 serviceAccount 的创建和删除动作以及监听 secret 的添加、删除动作。
Service Controller：服务控制器主要用作监听 Service 的变化。比如：创建的是一个 LoadBalancer 类型的 Service，Service Controller 则要确保外部的云平台上对该 Service 对应的 LoadBalancer 实例被创建、删除以及相应的路由转发表被更新。
Endpoint Controller：Endpoints 表示了一个 Service 对应的所有 Pod 副本的访问地址，而 Endpoints Controller 是负责生成和维护所有 Endpoints 对象的控制器。Endpoint Controller 负责监听 Service 和对应的 Pod 副本的变化。定期关联 Service 和 Pod (关联信息由 Endpoint 对象维护)，以保证 Service 到 Pod 的映射总是最新的。

kube-scheduler#

Scheduler 是负责整个集群的资源调度的，主要的职责如下所示：

主要用于收集和分析当前 Kubernetes 集群中所有 Node 节点的资源 (包括内存、CPU 等) 负载情况，然后依据资源占用情况分发新建的 Pod 到 Kubernetes 集群中可用的节点
实时监测 Kubernetes 集群中未分发和已分发的所有运行的 Pod
实时监测 Node 节点信息，由于会频繁查找 Node 节点，所以 Scheduler 同时会缓存一份最新的信息在本地
在分发 Pod 到指定的 Node 节点后，会把 Pod 相关的 Binding 信息写回 API Server，以方便其它组件使用

kubelet #

kubelet 是负责容器真正运行的核心组件，主要的职责如下所示：

负责 Node 节点上 Pod 的创建、修改、监控、删除等全生命周期的管理
定时上报本地 Node 的状态信息给 API Server
kubelet 是 Master 和 Node 之间的桥梁，接收 API Server 分配给它的任务并执行
kubelet 通过 API Server 间接与 Etcd 集群交互来读取集群配置信息
kubelet 在 Node 上做的主要工作具体如下：
1. 设置容器的环境变量、给容器绑定 Volume、给容器绑定 Port、根据指定的 Pod 运行一个单一容器、给指定的 Pod 创建 Network 容器
2. 同步 Pod 的状态
3. 在容器中运行命令、杀死容器、删除 Pod 的所有容器

kube-proxy #

kube-proxy 是为了解决外部网络能够访问集群中容器提供的应用服务而设计的，Proxy 运行在每个 Node 上。

每创建一个 Service，kube-proxy 就会从 API Server 获取 Services 和 Endpoints 的配置信息，然后根据其配置信息在 Node 上启动一个 Proxy 的进程并监听相应的服务端口。

当接收到外部请求时，kube-proxy 会根据 Load Balancer 将请求分发到后端正确的容器处理。

kube-proxy 不但解决了同一宿主机相同服务端口冲突的问题，还提供了 Service 转发服务端口对外提供服务的能力。

kube-proxy 后端使用随机、轮循等负载均衡算法进行调度。

kubectl #

Kubectl 是 Kubernetes 的集群管理命令行客户端工具集。通过 Kubectl 命令对 API Server 进行操作，API Server 响应并返回对应的命令结果，从而达到对 Kubernetes 集群的管理

核心资源对象 #

上面我们都是在架构层面了解 Kubernetes，但是似乎没有发现关于容器的说明，Kubernetes 作为容器编排引擎，那么他是怎么去对容器进行编排的呢？在 Kubernetes 集群中抽象了很多集群内部的资源对象，我们可以通过这些资源对象去操作容器的编排工作。

Pod #

Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace，是 Kubernetes 调度的基本单位。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。我们知道容器本质上就是进程，那么 Pod 实际上就是进程组了，只是这一组进程是作为一个整体来进行调度的。

kubernetes pod

在 Kubernetes 中，所有资源对象都使用资源清单（yaml 或 json）来定义，比如我们可以定义一个简单的 nginx 服务，它包含一个镜像为 nginx 的容器：(nginx-pod.yaml)

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: nginx
5
  labels:
6
    app: nginx
7
spec:
8
  containers:
9
    - name: nginx
10
      image: nginx
11
      ports:
12
        - containerPort: 80

定义了这样一个资源清单文件后，我们就可以利用上面我们提到的 Kubectl 工具将这个 Pod 创建到 Kubernetes 集群中：

Terminal window

1
kubectl apply -f nginx-pod.yaml

Pod 在 Kubernetes 集群中被创建的基本流程如下所示：

k8s pod process

用户通过 REST API 创建一个 Pod
apiserver 将其写入 etcd
scheduluer 检测到未绑定 Node 的 Pod，开始调度并更新 Pod 的 Node 绑定
kubelet 检测到有新的 Pod 调度过来，通过 container runtime 运行该 Pod
kubelet 通过 container runtime 取到 Pod 状态，并更新到 apiserver 中

Label #

Label 标签在 Kubernetes 资源对象中使用很多，也是非常重要的一个属性，Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）上面我们定义的 Nginx 的 Pod 就添加了一个 app=nginx 的 Label 标签。Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 Label 来标志具体的应用。Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 Label 的对象（比如 Service 用 Label 来选择一组 Pod）。Label Selector 支持以下几种方式：

等式，如 app=nginx 和 env!=production
集合，如 env in (production, qa)
多个 Label（它们之间是AND关系），如app=nginx,env=test

Namespace #

Namespace（命名空间）是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 Pods、Services、Deployments 等都是属于某一个 Namespace 的（默认是 default），比如上面我们的 Nginx Pod 没有指定 namespace，则默认就在 default 命名空间下面，而 Node, PersistentVolumes 等资源则不属于任何 Namespace，是全局的。

注意它并不是 Linux Namespace，二者没有任何关系，它只是 Kubernetes 划分不同工作空间的一个逻辑单位。

Deployment #

我们说了 Pod 是 Kubernetes 集群中的最基本的调度单元，但是如果想要创建同一个容器的多份拷贝，需要一个一个分别创建出来么，那么能否将 Pods 划到一个逻辑组里面呢？Deployment 就是来管理 Pod 的资源对象。

Deployment 确保任意时间都有指定数量的 Pod“副本”在运行。如果为某个 Pod 创建了 Deployment 并且指定 3 个副本，它会创建 3 个 Pod，并且持续监控它们。如果某个 Pod 不响应，那么 Deployment 会替换它，始终保持总数为 3。

如果之前不响应的 Pod 恢复了，现在就有 4 个 Pod 了，那么 Deployment 会将其中一个终止保持总数为 3。如果在运行中将副本总数改为 5，Deployment 会立刻启动 2 个新 Pod，保证总数为 5。持回滚和滚动升级。

当创建 Deployment 时，需要指定两个东西：

Pod 模板：用来创建 Pod 副本的模板
Label 标签：Deployment 需要监控的 Pod 的标签。

现在已经创建了 Pod 的一些副本，那么这些副本上如何进行负载呢？如何把这些 Pod 暴露出去呢？这个时候我们就需要用到 Service 这种资源对象了。

Service #

Service 是应用服务的抽象，通过 Labels 为应用提供负载均衡和服务发现。匹配 Labels 的 Pod IP 和端口列表组成 Endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 Endpoints 上。

每个 Service 都会自动分配一个 cluster IP（仅在集群内部可访问的虚拟地址）和 DNS 名，其他容器可以通过该地址或 DNS 来访问服务，而不需要了解后端容器的运行。

k8s service

docker-compose安装 Nginx Proxy Manager

Mon, 09 Oct 2023 00:00:00 GMT

官网：https://nginxproxymanager.com/

1. 安装Docker #

2.安装Docker-Compose #

3.创建`docker-compose.yml`文件#

Terminal window

1
mkdir -p ~/data/docker_data/nginxproxymanager   # 创建一个 npm 的文件夹
2

3
cd ~/data/docker_data/nginxproxymanager    # 进入该文件夹
4

5
vim docker-compose.yml

1
version: "3.8"
2
services:
3
  app:
4
    image: "jc21/nginx-proxy-manager:latest"
5
    restart: unless-stopped
6
    ports:
7
      - "80:80"
8
      - "81:81"
9
      - "443:443"
10
    volumes:
11
      - ./data:/data
12
      - ./letsencrypt:/etc/letsencrypt

4.启动并修改用户名密码#

Terminal window

1
# -d 表示后台运行
2
docker-compose up -d

image-20231009145929408

登录协议必须是https

默认登陆的用户名：admin@example.com 密码：changeme

首次次登陆会提示更改用户名和密码

Nginx Proxy Manager 1

Nginx Proxy Manager 2

5.代理配置#

image-20231009150441368

Domain Names ：填自己网站的域名，先做好 DNS 解析
Scheme ：默认 http 即可，除非你有自签名证书
Forward Hostname/IP ：填入服务器的 IP，或者 Docker 容器内部的 IP（如果 NPM 和网站搭建在同一台服务器上的话）
Forward Port：网站映射出的端口
Cache Assets ：缓存，可以选择打开
Block Common Exploits：阻止常见的漏洞，可以选择打开
Websockets Support ：WS 支持，可以选择打开
Access List：这个是 NPM 自带的一个限制访问功能

6.申请SSL证书#

可以申请一张 SSL 证书，让我们的网站支持 https 访问

Nginx Proxy Manager 6

Nginx Proxy Manager 7

不出意外，你将成功申请到 SSL 证书，证书会三个月自动续期

部分内容和图片来自Halo官网

Linux使用netstat命令查看并发连接数

Mon, 09 Oct 2023 00:00:00 GMT

提示没有netstat命令的先安装工具软件

Terminal window

1
yum install -y net-tools

Terminal window

1
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

Terminal window展开收起

1
解释:
2

3
返回结果示例：
4
LAST_ACK 5   (正在等待处理的请求数)
5
SYN_RECV 30
6
ESTABLISHED 1597 (正常数据传输状态)
7
FIN_WAIT1 51
8
FIN_WAIT2 504
9
TIME_WAIT 1057 (处理完毕，等待超时结束的请求数)
10

11
状态：描述
12
CLOSED：无连接是活动的或正在进行
13
LISTEN：服务器在等待进入呼叫
14
SYN_RECV：一个连接请求已经到达，等待确认
15
SYN_SENT：应用已经开始，打开一个连接
16
ESTABLISHED：正常数据传输状态
17
FIN_WAIT1：应用说它已经完成
18
FIN_WAIT2：另一边已同意释放
19
ITMED_WAIT：等待所有分组死掉
20
CLOSING：两边同时尝试关闭
21
TIME_WAIT：另一边已初始化一个释放
22
LAST_ACK：等待所有分组死掉

展开收起

使用这上面的命令是可以查看服务器的种连接状态，其中ESTABLISHED 就是并发连接状态的显示数的了。如果你不想查看到这么多连接状态，而仅仅只是想查看并发连接数，可以简化一下命令，即：

Terminal window

1
netstat -nat|grep ESTABLISHED|wc -l

nvm实现nodejs多版本管理及切换

Mon, 09 Oct 2023 00:00:00 GMT

nvm实现nodejs多版本管理及切换#

1.下载nvm#

nvm官网

image-20231009152217250

2.安装nvm#

nvm安装

image-20231009152648186

3.使用nvm安装nodejs#

Terminal window

1
nvm arch：显示node是运行在32位还是64位。
2
nvm install <version> [arch] ：安装node， version是特定版本也可以是最新稳定版本latest。可选参数arch指定安装32位还是64位版本，默认是系统位数。可以添加--insecure绕过远程服务器的SSL。
3
nvm list [available] ：显示已安装的列表。可选参数available，显示可安装的所有版本。list可简化为ls。
4
nvm on ：开启node.js版本管理。
5
nvm off ：关闭node.js版本管理。
6
nvm proxy [url] ：设置下载代理。不加可选参数url，显示当前代理。将url设置为none则移除代理。
7
nvm node_mirror [url] ：设置node镜像。默认是https://nodejs.org/dist/。如果不写url，则使用默认url。设置后可至安装目录settings.txt文件查看，也可直接在该文件操作。
8
nvm npm_mirror [url] ：设置npm镜像。https://github.com/npm/cli/archive/。如果不写url，则使用默认url。设置后可至安装目录settings.txt文件查看，也可直接在该文件操作。
9
nvm uninstall <version> ：卸载指定版本node。
10
nvm use [version] [arch] ：使用制定版本node。可指定32/64位。
11
nvm root [path] ：设置存储不同版本node的目录。如果未设置，默认使用当前目录。
12
nvm version ：显示nvm版本。version可简化为v。

Terminal window

1
nvm list available

image-20231009152924109

安装nodejs最新版本
Terminal window
```
1
nvm install latest
```
安装nodejs指定版本
Terminal window
```
1
nvm install 18.18.0
```
查看已安装nodejs版本
Terminal window
```
1
nvm list
2
nvm ls
```
image-20231009153240638
切换nodejs版本
Terminal window
```
1
nvm use 16.19.0
```

CentOS7更新Yum源

Sun, 08 Oct 2023 00:00:00 GMT

更新为阿里yum源#

Terminal window

1
1.安装wget
2
yum install -y wget
3

4
2.备份配置文件
5
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
6

7
3.下载阿里yum源文件
8
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
9

10
4.清理缓存
11
yum clean all
12

13
5.重新生成缓存
14
yum makecache

更新为华为yum源#

Terminal window

1
1.安装wget
2
yum install -y wget
3

4
2.备份配置文件
5
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
6

7
3.下载华为yum源文件
8
wget -O /etc/yum.repos.d/CentOS-Base.repo https://repo.huaweicloud.com/repository/conf/CentOS-7-reg.repo
9

10
4.清理缓存
11
yum clean all
12

13
5.重新生成缓存
14
yum makecache

kubesphere+k8s下devops使用maven-jdk11镜像

Sat, 14 May 2022 00:00:00 GMT

将配置-配置字典-jenkins-casc-config里面maven的image改成

1
image: "kubespheredev/builder-maven:v3.2.0jdk11"

直接使用helm方式安装operator

Fri, 13 May 2022 00:00:00 GMT

下载nacos-k8s#

Terminal window

1
https://github.com/nacos-group/nacos-k8s.git

安装nacos-operator #

Terminal window

1
helm install nacos-operator ./chart/nacos-operator
2

3
# 如果没有helm, 使用kubectl进行安装, 默认安装在default下面
4
kubectl apply -f chart/nacos-operator/nacos-operator-all.yaml

配置数据库#

去github上下载对应版本的包执行里面的sql文件导入到数据库即可

https://github.com/alibaba/nacos/releases

修改部署文件-使用自己的MySQL#

nacos-k8s/nacos-k8s-master/operator/config/samples/nacos_cluster_mysql.yaml

1
apiVersion: nacos.io/v1alpha1
2
kind: Nacos
3
metadata:
4
  name: nacos
5
  namespace: demo-project
6
spec:
7
  type: cluster
8
  image: nacos/nacos-server:v2.1.0
9
  replicas: 3
10
  resources:
11
    requests:
12
      cpu: 100m
13
      memory: 512Mi
14
    limits:
15
      cpu: 1
16
      memory: 2Gi
17
  database:
18
    type: mysql
19
    mysqlHost: 127.0.0.1
20
    mysqlDb: nacos
21
    mysqlUser: tianch
22
    mysqlPort: "3306"
23
    mysqlPassword: "123456"

展开收起

创建集群#

Terminal window

1
kubectl apply -f nacos-k8s/nacos-k8s-master/operator/config/samples/nacos_cluster_mysql.yaml

image-20220513151754058

SpringBoot+Redis+ELK日志集中存储和查询

Fri, 13 May 2022 00:00:00 GMT

安装Elasticsearch#

http://www.tianch.xyz/archives/%E4%BD%BF%E7%94%A8docker-compose%E5%AE%89%E8%A3%85skywalking%E5%92%8Celasticsearchmd

增加一些配置

进入elasticsearch容器
Terminal window
```
1
docker exec -it elasticsearch bash
```

编辑config/elasticsearch.yml 追加配置

1
http.cors.enabled: true
2
http.cors.allow-origin: "*"
3
http.cors.allow-headers: Authorization
4
xpack.security.enabled: true
5
xpack.security.transport.ssl.enabled: true

重启
Terminal window
```
1
docker restart elasticsearch
```

设置密码

Terminal window

1
bin/elasticsearch-setup-passwords interactive

再重启
Terminal window
```
1
docker restart elasticsearch
```

设置分片-进到容器中先

Terminal window

1
curl -XPUT -u elastic -H "Content-Type:application/json" http://localhost:9200/_cluster/settings -d '{ "persistent": { "cluster": { "max_shards_per_node": 10000 } } }'

安装Kibana#

拉取镜像
Terminal window
```
1
docker pull kibana:7.6.2
```

运行容器

Terminal window

1
docker run --name kibana --link=elasticsearch --net skywalking_skywalking  -p 5601:5601 -d kibana:7.6.2

修改配置

Terminal window

1
docker exec -it kibana bash
2
cd config
3
vi kibana.yml

1
# Default Kibana configuration for docker target
2
server.name: kibana
3
server.host: "0"
4
elasticsearch.hosts: ["http://elasticsearch:9200"]
5
xpack.monitoring.ui.container.elasticsearch.enabled: true
6
i18n.locale: "zh-CN"
7
elasticsearch.username: "elastic"
8
elasticsearch.password: "123456"

重启
Terminal window
```
1
docker restart kibana
```

安装Logstash#

拉取镜像
Terminal window
```
1
docker pull logstash:7.6.2
```

编辑配置文件

Terminal window

1
mkdir -p /data/elk/logstash
2
vim /data/elk/logstash/logstash.yml

1
http.host: "0.0.0.0"
2
xpack.monitoring.elasticsearch.hosts: ["http://192.168.0.233:9200"]
3
xpack.monitoring.elasticsearch.username: "logstash_system"
4
xpack.monitoring.elasticsearch.password: "77589910"
5
#path.config: /data/elk/logstash/conf.d/*.conf
6
path.config: /data/docker/logstash/conf.d/*.conf
7
path.logs: /var/log/logstash

编辑conf文件就testlog.conf

Terminal window

1
mkdir /data/elk/logstash/conf.d
2
vim /data/elk/logstash/conf.d/testlog.conf

1
input {
2
    redis {
3
        codec => json
4
        data_type => "list"
5
        key => "logstash-list"
6
        host => "192.168.0.233"
7
        port => "6379"
8
        password => "123456"
9
        batch_count => 100
10
        threads => 1
11
    }
12
}
13

14
output {
15
  elasticsearch {
16
    hosts => ["192.168.0.233:9200"]
17
    index => "platform-log-%{+YYYY.MM}"
18
    user => "elastic"
19
    password => "77589910"
20
  }
21
}

展开收起

编辑本地rsyslog配置增加

Terminal window

1
vim /etc/rsyslog.conf #增加下面一行
2
*.* @@192.168.0.233:5044

重启服务使配置生效
Terminal window
```
1
systemctl restart rsyslog
```

创建容器

Terminal window

1
docker run -d --restart=always --log-driver json-file --log-opt max-size=1000m --log-opt max-file=30 -p 5044:5044 --name logstash -v /data/elk/logstash/logstash.yml:/usr/share/logstash/config/logstash.yml -v /data/elk/logstash/conf.d/:/data/docker/logstash/conf.d/ logstash:7.6.2

发送日志到redis#

需要的依赖

1
<dependency>
2
    <groupId>de.idealo.logback</groupId>
3
    <artifactId>logback-redis</artifactId>
4
</dependency>
5

6
<dependency>
7
    <groupId>com.yomahub</groupId>
8
    <artifactId>tlog-all-spring-boot-starter</artifactId>
9
</dependency>
10

11
<dependency>
12
    <groupId>com.yomahub</groupId>
13
    <artifactId>tlog-logstash-logback</artifactId>
14
</dependency>

设置logback-spring.xml

1
<?xml version="1.0" encoding="UTF-8"?>
2
<configuration>
3

4
    <appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
5
        <!--这里替换成AspectLogbackEncoder-->
6
        <encoder class="com.yomahub.tlog.core.enhance.logback.AspectLogbackEncoder">
7
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n</pattern>
8
        </encoder>
9
    </appender>
10

11
    <!-- 获取yml中的配置 -->
12
    <springProperty scope="context" name="redis-host" source="spring.redis.host"/>
13
    <springProperty scope="context" name="redis-port" source="spring.redis.port"/>
14
    <springProperty scope="context" name="redis-password" source="spring.redis.password"/>
15

16
    <!--程序关闭时关闭redis批处理的钩子-->
17
    <shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook"/>
18
    <appender name="Logstash" class="net.logstash.logback.appender.LoggingEventAsyncDisruptorAppender">
19
        <ringBufferSize>131072</ringBufferSize>
20
        <appender class="de.idealo.logback.appender.RedisBatchAppender">
21
            <connectionConfig>
22
                <!--redis node-->
23
                <scheme>NODE</scheme>
24
                <host>${redis-host}</host>
25
                <port>${redis-port}</port>
26
                <password>${redis-password}</password>
27
                <key>logstash-list</key>
28
                <timeout>20000</timeout>
29
            </connectionConfig>
30
            <maxBatchMessages>1000</maxBatchMessages>
31
            <maxBatchSeconds>10</maxBatchSeconds>
32
            <encoder charset="UTF-8" class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
33
                <providers>
34
                    <provider class="com.yomahub.tlog.logstash.logback.TLogLogstashLogbackProvider"/>
35
                    <!--格式化输出：%d表示日期，%thread表示线程名，%-5level：级别从左显示5个字符宽度%msg：日志消息，%n是换行符-->
36
                    <pattern>
37
                        <pattern>
38
                            {
39
                            "level": "%level",
40
                            "thread": "%thread",
41
                            "class": "%logger{40}",
42
                            "message": "%message",
43
                            "stack_trace": "%exception{10}",
44
                            "client_time": "%d{yyyy-MM-dd HH:mm:ss.SSS}"
45
                            }
46
                        </pattern>
47
                    </pattern>
48
                    <stackTrace>
49
                        <throwableConverter class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
50
                            <maxDepthPerThrowable>10</maxDepthPerThrowable>
51
                            <maxLength>4096</maxLength>
52
                            <shortenedClassNameLength>20</shortenedClassNameLength>
53
                            <rootCauseFirst>true</rootCauseFirst>
54
                        </throwableConverter>
55
                    </stackTrace>
56
                </providers>
57
            </encoder>
58
        </appender>
59
    </appender>
60

61
    <appender name="Async" class="ch.qos.logback.classic.AsyncAppender">
62
        <neverBlock>true</neverBlock>
63
        <appender-ref ref="Logstash"/>
64
    </appender>
65

66
    <logger name="org.springframework" level="ERROR"/>
67
    <logger name="com.alibaba.cloud.dubbo.metadata.repository.DubboServiceMetadataRepository" level="ERROR"/>
68
    <logger name="org.springframework.boot.autoconfigure" level="ERROR"/>
69
    <logger name="org.springframework.data.redis" level="ERROR"/>
70
    <logger name="com.alibaba" level="ERROR"/>
71
    <logger name="ch.qos.logback" level="ERROR"/>
72
    <logger name="com.tianch" level="DEBUG"/>
73
    <root level="INFO">
74
        <appender-ref ref="Console"/>
75
        <appender-ref ref="Async"/>
76
    </root>
77
</configuration>

展开收起

dubbo微服务之间的隐式数据传递

Sun, 20 Feb 2022 00:00:00 GMT

利用dubbo的Attachment做隐式传递#

在做全链路压测插件时,如何让流量标识在dubbo远程RPC调用时进行传递是一个需要解决的问题,就可以用dubbo的Attachment做隐式传递,服务A） —> （服务B —> ）（服务C）等等.

上下文类

1
public class WormholeContextHolder {
2

3
    private static final InheritableThreadLocal<WormholeContext> wormholeContextThreadLocal = new InheritableThreadLocal<>();
4

5
    /**
6
     * 上下文流量标识
7
     */
8
    public static final String WORMHOLE_REQUEST_MARK = "X-Wormhole-Header-Request";
9

10
    /**
11
     * @return com.hoolai.wormhole.core.context.WormholeContext
12
     * @description 获取上下文
13
     */
14
    public static WormholeContext getContext() {
15
        return wormholeContextThreadLocal.get();
16
    }
17

18
    /**
19
     * @param key key
20
     * @return java.lang.String
21
     * @description 获取上下文中的属性
22
     */
23
    public static String getProperty(String key) {
24
        WormholeContext wormholeContext = getContext();
25
        if (wormholeContext != null) {
26
            return wormholeContext.toString();
27
        }
28
        return null;
29
    }
30

31
    /**
32
     * @param context context
33
     * @description 设置上下文
34
     */
35
    public static void setContext(WormholeContext context) {
36
        wormholeContextThreadLocal.set(context);
37
    }
38

39
    public static void setContext(String contextStr) {
40
        if (StringUtils.isNotEmpty(contextStr)) {
41
            setContext(new WormholeContext(contextStr));
42
        }
43
    }
44

45
    /**
46
     * @description 将上下文进行失效
47
     */
48
    public static void invalidContext() {
49
        wormholeContextThreadLocal.remove();
50
    }
51

52
}

展开收起

消费者

1
import org.apache.dubbo.common.constants.CommonConstants;
2
import org.apache.dubbo.common.extension.Activate;
3
import org.apache.dubbo.rpc.*;
4

5
@Activate(group = CommonConstants.CONSUMER)
6
public class ParamConsumerFilter implements Filter {
7

8
    @Override
9
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
10
        WormholeContext wormholeContext = WormholeContextHolder.getContext();
11
        if (wormholeContext != null) {
12
            RpcContext.getContext().setAttachment(WormholeContextHolder.WORMHOLE_REQUEST_MARK, wormholeContext.getWormholeValue());
13
        }
14
        return invoker.invoke(invocation);
15
    }
16
}

展开收起

生产者

1
import org.apache.dubbo.common.constants.CommonConstants;
2
import org.apache.dubbo.common.extension.Activate;
3
import org.apache.dubbo.rpc.*;
4

5
@Activate(group = CommonConstants.PROVIDER)
6
public class ParamProviderFilter implements Filter {
7

8
    @Override
9
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
10
        String wormholeContext = RpcContext.getContext().getAttachment(WormholeContextHolder.WORMHOLE_REQUEST_MARK);
11
        if (StringUtils.isNotBlank(wormholeContext)) {
12
            RpcContext.getContext().setAttachment(WormholeContextHolder.WORMHOLE_REQUEST_MARK, wormholeContext);
13
            WormholeContextHolder.setContext(wormholeContext);
14
        }
15
        return invoker.invoke(invocation);
16
    }
17
}

展开收起

过滤器的SPI配置

在资源文件夹下创建一个3层的文件夹 — dubbo — internal ,注意不要一块写中间加.分隔的形式,这样创建的是META-INF.dubbo.internal,变成了一个文件夹.

文件夹下创建一个名为org.apache.dubbo.rpc.Filter的文件.配置这一块可以参考dubbo源码的过滤器部分

文件内容如下,名称=类名
```
1
paramConsumerFilter=com.tianch.wormhole.component.dubbo.ParamConsumerFilter
2
paramProviderFilter=com.tianch.wormhole.component.dubbo.ParamProviderFilter
```

K8S下基于尚医通项目的devops的流水线

Sat, 19 Feb 2022 00:00:00 GMT

Terminal window展开收起

1
pipeline {
2
  agent {
3
    node {
4
      label 'maven'
5
    }
6
  }
7
  stages {
8

9
    stage('拉取代码') {
10
      agent none
11
      steps {
12
        container('maven') {
13
          git(url: 'https://codeup.aliyun.com/6014de608deaa14d9e02ce14/tianch/yygh-parent.git', credentialsId: 'yunxiao-git-id', branch: 'master', changelog: true, poll: false)
14
          sh 'ls -al'
15
        }
16
      }
17
    }
18

19
    stage('项目编译') {
20
      agent none
21
      steps {
22
        container('maven') {
23
          sh 'ls -al'
24
          sh 'mvn clean package -Dmaven.test.skip=true'
25
        }
26
      }
27
    }
28

29
    stage('构建镜像') {
30
      parallel {
31
        stage('构建hospital-manage镜像') {
32
          agent none
33
          steps {
34
            container('maven') {
35
              sh 'ls hospital-manage/target'
36
              sh 'docker build -t hospital-manage:latest -f hospital-manage/Dockerfile  ./hospital-manage/'
37
            }
38
          }
39
        }
40

41
        stage('构建server-gateway镜像') {
42
          agent none
43
          steps {
44
            container('maven') {
45
              sh 'ls server-gateway/target'
46
              sh 'docker build -t server-gateway:latest -f server-gateway/Dockerfile  ./server-gateway/'
47
            }
48
          }
49
        }
50

51
        stage('构建service-cmn镜像') {
52
          agent none
53
          steps {
54
            container('maven') {
55
              sh 'ls service/service-cmn/target'
56
              sh 'docker build -t service-cmn:latest -f service/service-cmn/Dockerfile  ./service/service-cmn/'
57
            }
58

59
          }
60
        }
61

62
        stage('构建service-hosp镜像') {
63
          agent none
64
          steps {
65
            container('maven') {
66
              sh 'ls service/service-hosp/target'
67
              sh 'docker build -t service-hosp:latest -f service/service-hosp/Dockerfile  ./service/service-hosp/'
68
            }
69

70
          }
71
        }
72

73
        stage('构建service-order镜像') {
74
          agent none
75
          steps {
76
            container('maven') {
77
              sh 'ls service/service-order/target'
78
              sh 'docker build -t service-order:latest -f service/service-order/Dockerfile  ./service/service-order/'
79
            }
80

81
          }
82
        }
83

84
        stage('构建service-oss镜像') {
85
          agent none
86
          steps {
87
            container('maven') {
88
              sh 'ls service/service-oss/target'
89
              sh 'docker build -t service-oss:latest -f service/service-oss/Dockerfile  ./service/service-oss/'
90
            }
91

92
          }
93
        }
94

95
        stage('构建service-sms镜像') {
96
          agent none
97
          steps {
98
            container('maven') {
99
              sh 'ls service/service-sms/target'
100
              sh 'docker build -t service-sms:latest -f service/service-sms/Dockerfile  ./service/service-sms/'
101
            }
102

103
          }
104
        }
105

106
        stage('构建service-statistics镜像') {
107
          agent none
108
          steps {
109
            container('maven') {
110
              sh 'ls service/service-statistics/target'
111
              sh 'docker build -t service-statistics:latest -f service/service-statistics/Dockerfile  ./service/service-statistics/'
112
            }
113

114
          }
115
        }
116

117
        stage('构建service-task镜像') {
118
          agent none
119
          steps {
120
            container('maven') {
121
              sh 'ls service/service-task/target'
122
              sh 'docker build -t service-task:latest -f service/service-task/Dockerfile  ./service/service-task/'
123
            }
124

125
          }
126
        }
127

128
        stage('构建service-user镜像') {
129
          agent none
130
          steps {
131
            container('maven') {
132
              sh 'ls service/service-user/target'
133
              sh 'docker build -t service-user:latest -f service/service-user/Dockerfile  ./service/service-user/'
134
            }
135

136
          }
137
        }
138

139
      }
140
    }
141

142
    stage('推送镜像') {
143
      parallel {
144
        stage('推送hospital-manage镜像') {
145
          agent none
146
          steps {
147
            container('maven') {
148
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
149
                sh '''#!/bin/sh
150
while [ 0 -eq 0 ]
151
do
152
    echo ".................. docker login begin  ..................."
153

154
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
155
    # check and retry
156

157
    if [ $? -eq 0 ]; then
158
        echo "--------------- docker login complete ---------------"
159
        break;
160
    else
161
        echo "...............docker login error, retry in 2 seconds .........."
162
        sleep 2
163
    fi
164
done'''
165
                sh 'docker tag hospital-manage:latest $REGISTRY/$DOCKERHUB_NAMESPACE/hospital-manage:SNAPSHOT-$BUILD_NUMBER'
166
                sh '''#!/bin/sh
167
while [ 0 -eq 0 ]
168
do
169
    echo ".................. docker push begin  ..................."
170

171
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/hospital-manage:SNAPSHOT-$BUILD_NUMBER
172
    # check and retry
173

174
    if [ $? -eq 0 ]; then
175
        echo "---------------  docker push complete ---------------"
176
        break;
177
    else
178
        echo "............... docker push error occur, retry in 2 seconds .........."
179
        sleep 2
180
    fi
181
done
182
echo "success"'''
183
              }
184

185
            }
186

187
          }
188
        }
189

190
        stage('推送server-gateway镜像') {
191
          agent none
192
          steps {
193
            container('maven') {
194
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
195
                sh '''#!/bin/sh
196
while [ 0 -eq 0 ]
197
do
198
    echo ".................. docker login begin  ..................."
199

200
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
201
    # check and retry
202

203
    if [ $? -eq 0 ]; then
204
        echo "--------------- docker login complete ---------------"
205
        break;
206
    else
207
        echo "...............docker login error, retry in 2 seconds .........."
208
        sleep 2
209
    fi
210
done'''
211
                sh 'docker tag server-gateway:latest $REGISTRY/$DOCKERHUB_NAMESPACE/server-gateway:SNAPSHOT-$BUILD_NUMBER'
212
                sh '''#!/bin/sh
213
while [ 0 -eq 0 ]
214
do
215
    echo "..................  docker push begin  ..................."
216

217
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/server-gateway:SNAPSHOT-$BUILD_NUMBER
218
    # check and retry
219

220
    if [ $? -eq 0 ]; then
221
        echo "---------------  docker push complete ---------------"
222
        break;
223
    else
224
        echo "............... docker push error occur, retry in 2 seconds .........."
225
        sleep 2
226
    fi
227
done
228
echo "success"'''
229
              }
230

231
            }
232

233
          }
234
        }
235

236
        stage('推送service-cmn镜像') {
237
          agent none
238
          steps {
239
            container('maven') {
240
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
241
                sh '''#!/bin/sh
242
while [ 0 -eq 0 ]
243
do
244
    echo ".................. docker login begin  ..................."
245

246
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
247
    # check and retry
248

249
    if [ $? -eq 0 ]; then
250
        echo "--------------- docker login complete ---------------"
251
        break;
252
    else
253
        echo "...............docker login error, retry in 2 seconds .........."
254
        sleep 2
255
    fi
256
done'''
257
                sh 'docker tag service-cmn:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-cmn:SNAPSHOT-$BUILD_NUMBER'
258
                sh '''#!/bin/sh
259
while [ 0 -eq 0 ]
260
do
261
    echo "..................  docker push begin  ..................."
262

263
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-cmn:SNAPSHOT-$BUILD_NUMBER
264
    # check and retry
265

266
    if [ $? -eq 0 ]; then
267
        echo "---------------  docker push complete ---------------"
268
        break;
269
    else
270
        echo "............... docker push error occur, retry in 2 seconds .........."
271
        sleep 2
272
    fi
273
done
274
echo "success"'''
275
              }
276

277
            }
278

279
          }
280
        }
281

282
        stage('推送service-hosp镜像') {
283
          agent none
284
          steps {
285
            container('maven') {
286
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
287
                sh '''#!/bin/sh
288
while [ 0 -eq 0 ]
289
do
290
    echo ".................. docker login begin  ..................."
291

292
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
293
    # check and retry
294

295
    if [ $? -eq 0 ]; then
296
        echo "--------------- docker login complete ---------------"
297
        break;
298
    else
299
        echo "...............docker login error, retry in 2 seconds .........."
300
        sleep 2
301
    fi
302
done'''
303
                sh 'docker tag service-hosp:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-hosp:SNAPSHOT-$BUILD_NUMBER'
304
                sh '''#!/bin/sh
305
while [ 0 -eq 0 ]
306
do
307
    echo "..................  docker push begin  ..................."
308

309
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-hosp:SNAPSHOT-$BUILD_NUMBER
310
    # check and retry
311

312
    if [ $? -eq 0 ]; then
313
        echo "---------------  docker push complete ---------------"
314
        break;
315
    else
316
        echo "............... docker push error occur, retry in 2 seconds .........."
317
        sleep 2
318
    fi
319
done
320
echo "success"'''
321
              }
322

323
            }
324

325
          }
326
        }
327

328
        stage('推送service-order镜像') {
329
          agent none
330
          steps {
331
            container('maven') {
332
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
333
                sh '''#!/bin/sh
334
while [ 0 -eq 0 ]
335
do
336
    echo ".................. docker login begin  ..................."
337

338
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
339
    # check and retry
340

341
    if [ $? -eq 0 ]; then
342
        echo "--------------- docker login complete ---------------"
343
        break;
344
    else
345
        echo "...............docker login error, retry in 2 seconds .........."
346
        sleep 2
347
    fi
348
done'''
349
                sh 'docker tag service-order:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-order:SNAPSHOT-$BUILD_NUMBER'
350
                sh '''#!/bin/sh
351
while [ 0 -eq 0 ]
352
do
353
    echo "..................  docker push begin  ..................."
354

355
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-order:SNAPSHOT-$BUILD_NUMBER
356
    # check and retry
357

358
    if [ $? -eq 0 ]; then
359
        echo "---------------  docker push complete ---------------"
360
        break;
361
    else
362
        echo "............... docker push error occur, retry in 2 seconds .........."
363
        sleep 2
364
    fi
365
done
366
echo "success"'''
367
              }
368

369
            }
370

371
          }
372
        }
373

374
        stage('推送service-oss镜像') {
375
          agent none
376
          steps {
377
            container('maven') {
378
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
379
                sh '''#!/bin/sh
380
while [ 0 -eq 0 ]
381
do
382
    echo ".................. docker login begin  ..................."
383

384
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
385
    # check and retry
386

387
    if [ $? -eq 0 ]; then
388
        echo "--------------- docker login complete ---------------"
389
        break;
390
    else
391
        echo "...............docker login error, retry in 2 seconds .........."
392
        sleep 2
393
    fi
394
done'''
395
                sh 'docker tag service-oss:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-oss:SNAPSHOT-$BUILD_NUMBER'
396
                sh '''#!/bin/sh
397
while [ 0 -eq 0 ]
398
do
399
    echo "..................  docker push begin  ..................."
400

401
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-oss:SNAPSHOT-$BUILD_NUMBER
402
    # check and retry
403

404
    if [ $? -eq 0 ]; then
405
        echo "---------------  docker push complete ---------------"
406
        break;
407
    else
408
        echo "............... docker push error occur, retry in 2 seconds .........."
409
        sleep 2
410
    fi
411
done
412
echo "success"'''
413
              }
414

415
            }
416

417
          }
418
        }
419

420
        stage('推送service-sms镜像') {
421
          agent none
422
          steps {
423
            container('maven') {
424
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
425
                sh '''#!/bin/sh
426
while [ 0 -eq 0 ]
427
do
428
    echo ".................. docker login begin  ..................."
429

430
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
431
    # check and retry
432

433
    if [ $? -eq 0 ]; then
434
        echo "--------------- docker login complete ---------------"
435
        break;
436
    else
437
        echo "...............docker login error, retry in 2 seconds .........."
438
        sleep 2
439
    fi
440
done'''
441
                sh 'docker tag service-sms:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-sms:SNAPSHOT-$BUILD_NUMBER'
442
                sh '''#!/bin/sh
443
while [ 0 -eq 0 ]
444
do
445
    echo "..................  docker push begin  ..................."
446

447
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-sms:SNAPSHOT-$BUILD_NUMBER
448
    # check and retry
449

450
    if [ $? -eq 0 ]; then
451
        echo "---------------  docker push complete ---------------"
452
        break;
453
    else
454
        echo "............... docker push error occur, retry in 2 seconds .........."
455
        sleep 2
456
    fi
457
done
458
echo "success"'''
459
              }
460

461
            }
462

463
          }
464
        }
465

466
        stage('推送service-statistics镜像') {
467
          agent none
468
          steps {
469
            container('maven') {
470
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
471
                sh '''#!/bin/sh
472
while [ 0 -eq 0 ]
473
do
474
    echo ".................. docker login begin  ..................."
475

476
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
477
    # check and retry
478

479
    if [ $? -eq 0 ]; then
480
        echo "--------------- docker login complete ---------------"
481
        break;
482
    else
483
        echo "...............docker login error, retry in 2 seconds .........."
484
        sleep 2
485
    fi
486
done'''
487
                sh 'docker tag service-statistics:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-statistics:SNAPSHOT-$BUILD_NUMBER'
488
                sh '''#!/bin/sh
489
while [ 0 -eq 0 ]
490
do
491
    echo "..................  docker push begin  ..................."
492

493
    # ...... call your command here 在这里调用你的命令 ......
494
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-statistics:SNAPSHOT-$BUILD_NUMBER
495
    # check and retry
496

497
    if [ $? -eq 0 ]; then
498
        echo "---------------  docker push complete ---------------"
499
        break;
500
    else
501
        echo "............... docker push error occur, retry in 2 seconds .........."
502
        sleep 2
503
    fi
504
done
505
echo "success"'''
506
              }
507

508
            }
509

510
          }
511
        }
512

513
        stage('推送service-task镜像') {
514
          agent none
515
          steps {
516
            container('maven') {
517
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
518
                sh '''#!/bin/sh
519
while [ 0 -eq 0 ]
520
do
521
    echo ".................. docker login begin  ..................."
522

523
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
524
    # check and retry
525

526
    if [ $? -eq 0 ]; then
527
        echo "--------------- docker login complete ---------------"
528
        break;
529
    else
530
        echo "...............docker login error, retry in 2 seconds .........."
531
        sleep 2
532
    fi
533
done'''
534
                sh 'docker tag service-task:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-task:SNAPSHOT-$BUILD_NUMBER'
535
                sh '''#!/bin/sh
536
while [ 0 -eq 0 ]
537
do
538
    echo "..................  docker push begin  ..................."
539

540
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-task:SNAPSHOT-$BUILD_NUMBER
541
    # check and retry
542

543
    if [ $? -eq 0 ]; then
544
        echo "---------------  docker push complete ---------------"
545
        break;
546
    else
547
        echo "............... docker push error occur, retry in 2 seconds .........."
548
        sleep 2
549
    fi
550
done
551
echo "success"'''
552
              }
553

554
            }
555

556
          }
557
        }
558

559
        stage('推送service-user镜像') {
560
          agent none
561
          steps {
562
            container('maven') {
563
              withCredentials([usernamePassword(credentialsId : 'harbor-docker-registry' ,usernameVariable : 'DOCKER_USER_VAR' ,passwordVariable : 'DOCKER_PWD_VAR' ,)]) {
564
                sh '''#!/bin/sh
565
while [ 0 -eq 0 ]
566
do
567
    echo ".................. docker login begin  ..................."
568

569
    echo "$DOCKER_PWD_VAR" | docker login $REGISTRY_URL -u "$DOCKER_USER_VAR" --password-stdin
570
    # check and retry
571

572
    if [ $? -eq 0 ]; then
573
        echo "--------------- docker login complete ---------------"
574
        break;
575
    else
576
        echo "...............docker login error, retry in 2 seconds .........."
577
        sleep 2
578
    fi
579
done'''
580
                sh 'docker tag service-user:latest $REGISTRY/$DOCKERHUB_NAMESPACE/service-user:SNAPSHOT-$BUILD_NUMBER'
581
                sh '''#!/bin/sh
582
while [ 0 -eq 0 ]
583
do
584
    echo "..................  docker push begin  ..................."
585

586
    docker push  $REGISTRY/$DOCKERHUB_NAMESPACE/service-user:SNAPSHOT-$BUILD_NUMBER
587
    # check and retry
588

589
    if [ $? -eq 0 ]; then
590
        echo "---------------  docker push complete ---------------"
591
        break;
592
    else
593
        echo "............... docker push error occur, retry in 2 seconds .........."
594
        sleep 2
595
    fi
596
done
597
echo "success"'''
598
              }
599

600
            }
601

602
          }
603
        }
604

605
      }
606
    }
607
  }
608
  environment {
609
    DOCKER_CREDENTIAL_ID = 'dockerhub-id'
610
    GITHUB_CREDENTIAL_ID = 'github-id'
611
    KUBECONFIG_CREDENTIAL_ID = 'demo-kubeconfig'
612
    REGISTRY_URL = 'harbor.tianch.xyz'
613
    REGISTRY = 'harbor.tianch.xyz'
614
    DOCKERHUB_NAMESPACE = 'tianch'
615
    GITHUB_ACCOUNT = 'kubesphere'
616
    APP_NAME = 'devops-java-sample'
617
  }
618
  parameters {
619
    string(name: 'TAG_NAME', defaultValue: '', description: '')
620
  }
621
}

展开收起

之所以加上while循环,是因为在弱网环境下容易出现网络闪断导致流水线执行失败

注意<此流水线还未加上部署到k8s的stage>;流水线中的一些参数取值一部分来自环境变量,另一部分需要在kubesphere后台添加(或者使用k8s的命令添加)

使用docker-compose安装skywalking和elasticsearch

Sat, 19 Feb 2022 00:00:00 GMT

安装docker-compose(已安装好docker)#

下载最新版的docker-compose文件

Terminal window

1
sudo curl -L https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

赋予可执行权限
Terminal window
```
1
chmod +x /usr/local/bin/docker-compose
```
验证版本
Terminal window
```
1
docker-compose --version
```

编辑docker-compose文件#

1
version: "3.3"
2
services:
3
  elasticsearch:
4
    image: elasticsearch:7.6.2
5
    container_name: elasticsearch
6
    restart: always
7
    privileged: true
8
    hostname: elasticsearch
9
    ports:
10
      - 9200:9200
11
      - 9300:9300
12
    environment:
13
      - discovery.type=single-node
14
      - bootstrap.memory_lock=true
15
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
16
      - TZ=Asia/Shanghai
17
    networks:
18
      - skywalking
19
    ulimits:
20
      memlock:
21
        soft: -1
22
        hard: -1
23
  elasticsearch-hq:
24
    image: elastichq/elasticsearch-hq
25
    container_name: elasticsearch-hq
26
    restart: always
27
    privileged: true
28
    hostname: elasticsearch-hq
29
    ports:
30
      - 5000:5000
31
    environment:
32
      - TZ=Asia/Shanghai
33
    networks:
34
      - skywalking
35
  oap:
36
    image: apache/skywalking-oap-server:8.3.0-es7
37
    container_name: oap
38
    hostname: oap
39
    privileged: true
40
    depends_on:
41
      - elasticsearch
42
    links:
43
      - elasticsearch
44
    restart: always
45
    ports:
46
      - 11800:11800
47
      - 12800:12800
48
    environment:
49
      SW_STORAGE: elasticsearch7
50
      SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200
51
      TZ: Asia/Shanghai
52
    volumes:
53
      - ./config/alarm-settings.yml:/skywalking/config/alarm-settings.yml
54
    networks:
55
      - skywalking
56
  ui:
57
    image: apache/skywalking-ui:8.3.0
58
    container_name: ui
59
    privileged: true
60
    depends_on:
61
      - oap
62
    links:
63
      - oap
64
    restart: always
65
    ports:
66
      - 8080:8080
67
    environment:
68
      SW_OAP_ADDRESS: oap:12800
69
      TZ: Asia/Shanghai
70
    networks:
71
      - skywalking
72

73
networks:
74
  skywalking:
75
    driver: bridge

展开收起

执行安装#

Terminal window

1
docker-compose up -d

Docker安装Harbor私有镜像仓库

Wed, 16 Feb 2022 00:00:00 GMT

1.安装docker环境#

安装／升级Docker客户端

仅适用于公网环境

Terminal window

1
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

配置镜像加速器

去阿里云控制台-容器镜像服务-镜像加速器-找到你的加速地址

Terminal window

1
sudo mkdir -p /etc/docker
2
sudo tee /etc/docker/daemon.json <<-'EOF'
3
{
4
  "registry-mirrors": ["https://xxxx.mirror.aliyuncs.com"]
5
}
6
EOF
7
sudo systemctl daemon-reload
8
sudo systemctl restart docker

2.申请(免费)证书#

自己申请

证书pem转crt

Terminal window

1
openssl x509 -in xxx.pem -out xxx.crt

3.域名解析#

自己申请域名自己解析

4.安装Docker-compose#

去github下载最新安装文件

移动并授权

Terminal window

1
cp docker-compose-linux-x86_64 /usr/local/bin/
2
cd /usr/local/bin
3
mv docker-compose-linux-x86_64 docker-compose
4
chmod +x docker-compose
5
docker-compose --version

5.安装Harbor#

下载并上传证书到服务器

下载在线安装包并解压

Terminal window

1
yum install -y wget
2
wget https://github.com/goharbor/harbor/releases/download/v2.4.1/harbor-online-installer-v2.4.1.tgz
3
tar -xvf harbor-online-installer-v2.4.1.tgz

配置Harbor

cd 到解压后的文件夹

复制一份配置文件
Terminal window
```
1
cp harbor.yml.tmpl harbor.yml
```

编辑配置文件

Terminal window

1
vim harbor.yml

1
# Configuration file of Harbor
2

3
# The IP address or hostname to access admin UI and registry service.
4
# DO NOT use localhost or 127.0.0.1, because Harbor needs to be accessed by external clients.
5
hostname: 你的harbor域名
6

7
# http related config
8
http:
9
  # port for http, default is 80. If https enabled, this port will redirect to https port
10
  port: 80
11

12
# https related config
13
https:
14
  # https port for harbor, default is 443
15
  port: 443
16
  # The path of cert and key files for nginx
17
  certificate: pem或crt文件的路径
18
  private_key: key文件的路径
19

20
# # Uncomment following will enable tls communication between all harbor components
21
# internal_tls:
22
#   # set enabled to true means internal tls is enabled
23
#   enabled: true
24
#   # put your cert and key files on dir
25
#   dir: /etc/harbor/tls/internal
26

27
# Uncomment external_url if you want to enable external proxy
28
# And when it enabled the hostname will no longer used
29
# external_url: https://reg.mydomain.com:8433
30

31
# The initial password of Harbor admin
32
# It only works in first time to install harbor
33
# Remember Change the admin password from UI after launching Harbor.
34
harbor_admin_password: Harbor12345
35

36
# Harbor DB configuration
37
database:
38
  # The password for the root user of Harbor DB. Change this before any production use.
39
  password: 最好改一下
40
  # The maximum number of connections in the idle connection pool. If it <=0, no idle connections are retained.
41
  max_idle_conns: 100
42
  # The maximum number of open connections to the database. If it <= 0, then there is no limit on the number of open connections.
43
  # Note: the default number of connections is 1024 for postgres of harbor.
44
  max_open_conns: 900

展开收起

启动
Terminal window
```
1
./install.sh
```

安装完成后访问https://你的域名

默认账号密码/Harbor12345

image-20220216104738377

k8s+helm安装Elasticsearch集群

Thu, 27 Jan 2022 00:00:00 GMT

添加仓库

Terminal window

1
helm repo add elastic https://helm.elastic.co

创建工作目录并进入工作目录
Terminal window
```
1
mkdir -p /opt/elasticsearch
2
cd /opt/elasticsearch
```

下载安装包

Terminal window

1
helm pull helm pull elastic/elasticsearch --version 7.5.1

解压安装包
Terminal window
```
1
tar -xvf elasticsearch-7.5.1.tgz
```
进入解压后的目录
Terminal window
```
1
cd elasticsearch
```
编辑values.yaml文件
Terminal window
```
1
vim values.yaml
```
基本不用改什么东西

安装

Terminal window

1
helm install elasticsearch . -n demo-project

k8s+helm安装skywalking

Thu, 27 Jan 2022 00:00:00 GMT

添加仓库

Terminal window

1
helm repo add skywalking https://apache.jfrog.io/artifactory/skywalking-helm

创建工作目录
Terminal window
```
1
mkdir -p /opt/skywalking
```
下载包
Terminal window
```
1
helm pull skywalking/skywalking
```
解压安装包并进入解压后的目录

我安装时的最新版本是封装的4.2.0版本注意你下载时的版本
Terminal window
```
1
tar -xvf skywalking-4.2.0.tgz
2
cd skywalking
```

安装

Deploy SkyWalking 8.8.1 & Elasticsearch 7.5.1

Terminal window

1
helm install skywalking skywalking/skywalking -n demo-project \
2
  --set oap.image.tag=8.8.1 \
3
  --set oap.storageType=elasticsearch \
4
  --set ui.image.tag=8.8.1 \
5
  --set elasticsearch.imageTag=7.5.1

Deploy SkyWalking 8.8.1 & Elasticsearch 6.8.6

Terminal window

1
helm install skywalking skywalking/skywalking -n demo-project \
2
  --set oap.image.tag=8.8.1 \
3
  --set oap.storageType=elasticsearch \
4
  --set ui.image.tag=8.8.1 \
5
  --set elasticsearch.imageTag=6.8.6

自定义
1. 编辑values.yaml
2. 执行命令安装在values.yaml所在文件夹下执行
  Terminal window
```
1
helm install skywalking skywalking/skywalking . -n demo-project
```
  注意命令中有个点,.代表当前目录

k8s+helm安装skywalking(使用已经存在的Elasticsearch )

Thu, 27 Jan 2022 00:00:00 GMT

添加仓库

Terminal window

1
helm repo add skywalking https://apache.jfrog.io/artifactory/skywalking-helm

创建工作目录
Terminal window
```
1
mkdir -p /opt/skywalking
```
下载包
Terminal window
```
1
helm pull skywalking/skywalking
```
解压安装包并进入解压后的目录

我安装时的最新版本是封装的4.2.0版本注意你下载时的版本
Terminal window
```
1
tar -xvf skywalking-4.2.0.tgz
2
cd skywalking
```

编辑values-my-es.yaml文件

host填写你的host和port以及用户名和密码

Terminal window展开收起

1
oap:
2
  image:
3
    tag: 8.8.1
4
  storageType: elasticsearch
5

6
ui:
7
  image:
8
    tag: 8.8.1
9

10
elasticsearch:
11
  enabled: false
12
  config:               # For users of an existing elasticsearch cluster,takes effect when `elasticsearch.enabled` is false
13
    host: elasticsearch-master.demo-project
14
    port:
15
      http: 9200
16
    user: ""         # [optional]
17
    password: ""     # [optional]

展开收起

安装
Terminal window
```
1
helm install skywalking . -n demo-project -f values-my-es.yaml
```
.表示当前目录

-n demo-project表示指定命名空间demo-project

IDEA控制台Tomcat乱码的问题解决

Wed, 26 Jan 2022 00:00:00 GMT

配置idea64.exe.vmoptions文件
```
1
-Dfile.encoding=UTF-8
```
image-20220126173835082
IDEA全局编码设置成UTF-8

image-20220126174205707
IDEA项目配置

在Tomcat配置项VM options文本框中输入-Dfile.encoding=UTF-8

image-20220126174427034
配置Tomcat的配置文件logging.properties

百度上面很多只有前3种,我都试了还是乱码,最后发现这里配置的是GBK,改成UTF-8控制台就不再乱码了.
```
1
java.util.logging.ConsoleHandler.encoding = UTF-8
```
image-20220126174648760

kubesphere+k8s+helm安装RabbitMQ集群+镜像模式

Sun, 23 Jan 2022 00:00:00 GMT

1.安装k8s多节点集群#

使用kubekey安装k8skubesphere 使用此方式会自动安装helm

1.下载Rabbitmq的chart包#

添加bitnamid仓库

Terminal window

1
helm repo add bitnami https://charts.bitnami.com/bitnami

查询chart
Terminal window
```
1
helm search repo bitnami
```
创建rabbitmq的工作目录
Terminal window
```
1
mkdir -p /opt/rabbitmq
```
使用helm拉取rabbitmq
Terminal window
```
1
helm pull bitnami/rabbitmq
```

解压

Terminal window

1
tar -xvf 拉取的文件名-版本变更会导致文件名变化

2.编辑配置文件#

设置管理员密码

配置文件方式

1
auth:
2
  ## @param auth.username RabbitMQ application username
3
  ## ref: https://github.com/bitnami/bitnami-docker-rabbitmq#environment-variables
4
  ##
5
  username: admin
6

7
  ## @param auth.password RabbitMQ application password
8
  ## ref: https://github.com/bitnami/bitnami-docker-rabbitmq#environment-variables
9
  ##
10
  password: "77589910"
11
  ## @param auth.existingPasswordSecret Existing secret with RabbitMQ credentials (must contain a value for `rabbitmq-password` key)
12
  ## e.g:
13
  ## existingPasswordSecret: name-of-existing-secret
14
  ##
15
  existingPasswordSecret: ""
16

17
  ## @param auth.erlangCookie Erlang cookie to determine whether different nodes are allowed to communicate with each other
18
  ## ref: https://github.com/bitnami/bitnami-docker-rabbitmq#environment-variables
19
  ##
20
  erlangCookie: "secretcookie123"
21
  ## @param auth.existingErlangSecret Existing secret with RabbitMQ Erlang cookie (must contain a value for `rabbitmq-erlang-cookie` key)
22
  ## e.g:
23
  ## existingErlangSecret: name-of-existing-secret
24
  ##
25
  existingErlangSecret: ""

展开收起

image-20220123203354564

安装时set方式指定

Terminal window

1
--set auth.username=admin,auth.password=77589910,auth.erlangCookie=secretcookie123

设置启动副本数
Terminal window
```
1
replicaCount: 3
```
image-20220123204103644

设置持久化存储

1
persistence:
2
  ## @param persistence.enabled Enable RabbitMQ data persistence using PVC
3
  ##
4
  enabled: true
5

6
  ## @param persistence.storageClass PVC Storage Class for RabbitMQ data volume
7
  ## If defined, storageClassName: <storageClass>
8
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
9
  ## If undefined (the default) or set to null, no storageClassName spec is
10
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
11
  ##   GKE, AWS & OpenStack)
12
  ##
13
  storageClass: "local"
14
  ## @param persistence.selector Selector to match an existing Persistent Volume
15
  ## selector:
16
  ##   matchLabels:
17
  ##     app: my-app
18
  ##
19
  selector: {}
20
  ## @param persistence.accessMode PVC Access Mode for RabbitMQ data volume
21
  ##
22
  accessMode: ReadWriteOnce
23

24
  ## @param persistence.existingClaim Provide an existing PersistentVolumeClaims
25
  ## The value is evaluated as a template
26
  ## So, for example, the name can depend on .Release or .Chart
27
  ##
28
  existingClaim: ""
29

30
  ## @param persistence.size PVC Storage Request for RabbitMQ data volume
31
  ## If you change this value, you might have to adjust `rabbitmq.diskFreeLimit` as well
32
  ##
33
  size: 60Gi
34

35
  ## @param persistence.volumes Additional volumes without creating PVC
36
  ##  - name: volume_name
37
  ##    emptyDir: {}
38
  ##
39
  volumes: []
40
  ## @param persistence.annotations Persistence annotations. Evaluated as a template
41
  ## Example:
42
  ## annotations:
43
  ##   example.io/disk-volume-type: SSD
44
  ##
45
  annotations: {}

展开收起

image-20220123204323840

设置集群访问方式
```
1
service:
2
  ## @param service.type Kubernetes Service type
3
  ##
4
  type: NodePort
```
在实操中我发现,如果service.type设置成ClusterIP,等待集群启动完成后,再手动添加NodePort的访问方式,手动删除一个容器后,容器在自动恢复时会报错,然后就是不停的重启

设置集群意外宕机强制重启

当rabbitmq启用持久化存储时，若rabbitmq所有pod同时宕机，将无法重新启动，因此有必要提前开启clustering.forceBoot

Terminal window展开收起

1
clustering:
2
  ## @param clustering.enabled Enable RabbitMQ clustering
3
  ##
4
  enabled: true
5
  ## @param clustering.addressType Switch clustering mode. Either `ip` or `hostname`
6
  ##
7
  addressType: hostname
8
  ## @param clustering.rebalance Rebalance master for queues in cluster when new replica is created
9
  ## ref: https://www.rabbitmq.com/rabbitmq-queues.8.html#rebalance
10
  ##
11
  rebalance: false
12

13
  ## @param clustering.forceBoot Force boot of an unexpectedly shut down cluster (in an unexpected order).
14
  ## forceBoot executes 'rabbitmqctl force_boot' to force boot cluster shut down unexpectedly in an unknown order
15
  ## ref: https://www.rabbitmq.com/rabbitmqctl.8.html#force_boot
16
  ##
17
  forceBoot: true
18

19
  ## @param clustering.partitionHandling Switch Partition Handling Strategy. Either `autoheal` or `pause-minority` or `pause-if-all-down` or `ignore`
20
  ## ref: https://www.rabbitmq.com/partitions.html#automatic-handling
21
  ##
22
  partitionHandling: autoheal

展开收起

image-20220123205045975

指定时区

Terminal window

1
extraEnvVars:
2
  - name: TZ
3
    value: "Asia/Shanghai"

3.部署RabbitMQ#

在kubesphere后台创建命名空间demo-project

使用kubectl命令创建的在kubesphere后台可能会不显示
安装
- 使用配置文件中配置的管理员账号密码
  Terminal window
```
1
helm install rabbitmq -n demo-project .
```
  helm install后的rabbitmq只是一个名称,起什么名称都可以
  
  命令最后有一个点
- 通过set指定管理员账号密码—后期upgrade时也须指定上参数
  Terminal window
```
1
helm install rabbitmq -n demo-project . \
2
--set auth.username=admin,auth.password=77589910,auth.erlangCookie=secretcookie123
```
image-20220123205912776
查看安装状态
- 查看安装进度
  Terminal window
```
1
kubectl get pod -n demo-project -w
```
  image-20220123210139110
- 查看svc
  Terminal window
```
1
kubectl get svc -n demo-project
```
- 查看集群状态
  - 进入pod
    Terminal window
    1 kubectl exec -it -n demo-project rabbitmq-0 -- bash
  - 查看集群状态
    Terminal window
    1 rabbitmqctl cluster_status
  - 查看当前策略
    Terminal window
    1 rabbitmqctl list_policies
  - 设置集群名称
    Terminal window
    1 rabbitmqctl set_cluster_name [cluster_name]

4.配置镜像模式实现高可用#

使用命令

Terminal window

1
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all" , "ha-sync-mode":"automatic"}'

使用控制台

image-20220121183803914

image-20220121183850796

5.清理RabbitMQ集群#

卸载

Terminal window

1
helm uninstall rabbitmq -n demo-project

删除pvc

Terminal window

1
kubectl delete pvc -n demo-project data-rabbitmq-0 data-rabbitmq-1 data-rabbitmq-2

6.参考文献#

https://blog.csdn.net/qq_14999375/article/details/119085363

使用kubeKey安装k8s+kubesphere

Sun, 23 Jan 2022 00:00:00 GMT

以下内容均参考kubesphere官网

1.准备主机(略)#

2.下载kubeKey#

如果网络不能访问GitHub,务必执行下面的命令
Terminal window
```
1
export KKZONE=cn
```

下载kubeKey

Terminal window

1
curl -sfL https://get-kk.kubesphere.io | VERSION=v1.2.1 sh -

添加可执行权限
Terminal window
```
1
chmod +x kk
```

3.创建集群#

创建配置文件

Terminal window

1
./kk create config --with-kubesphere v3.2.1 --with-kubernetes v1.21.5 -f config-sample.yaml

编辑调整配置文件-以下内容来自官网(仅供参考)

1
#vi ~/config-sample.yaml
2
apiVersion: kubekey.kubesphere.io/v1alpha1
3
kind: Cluster
4
metadata:
5
  name: config-sample
6
  spec:
7
    hosts:
8
    - {name: master1, address: 172.24.107.72, internalAddress: 172.24.107.72, user: root, password: QWEqwe123}
9
    - {name: master2, address: 172.24.107.73, internalAddress: 172.24.107.73, user: root, password: QWEqwe123}
10
    - {name: master3, address: 172.24.107.74, internalAddress: 172.24.107.74, user: root, password: QWEqwe123}
11
    - {name: node1, address: 172.24.107.75, internalAddress: 172.24.107.75, user: root, password: QWEqwe123}
12
    - {name: node2, address: 172.24.107.76, internalAddress: 172.24.107.76, user: root, password: QWEqwe123}
13
    - {name: node3, address: 172.24.107.77, internalAddress: 172.24.107.77, user: root, password: QWEqwe123}
14
    roleGroups:
15
      etcd:
16
      - master1
17
      - master2
18
      - master3
19
      master:
20
      - master1
21
      - master2
22
      - master3
23
      worker:
24
      - node1
25
      - node2
26
      - node3
27
    controlPlaneEndpoint:
28
      domain: lb.kubesphere.local
29
      address: "39.104.82.170"
30
      port: 6443
31
    kubernetes:
32
      version: v1.17.9
33
      imageRepo: kubesphere
34
      clusterName: cluster.local
35
      masqueradeAll: false  # masqueradeAll tells kube-proxy to SNAT everything if using the pure iptables proxy mode. [Default: false]
36
      maxPods: 110  # maxPods is the number of pods that can run on this Kubelet. [Default: 110]
37
      nodeCidrMaskSize: 24  # internal network node size allocation. This is the size allocated to each node on your network. [Default: 24]
38
      proxyMode: ipvs  # mode specifies which proxy mode to use. [Default: ipvs]
39
    network:
40
      plugin: calico
41
      calico:
42
        ipipMode: Always  # IPIP Mode to use for the IPv4 POOL created at start up. If set to a value other than Never, vxlanMode should be set to "Never". [Always | CrossSubnet | Never] [Default: Always]
43
        vxlanMode: Never  # VXLAN Mode to use for the IPv4 POOL created at start up. If set to a value other than Never, ipipMode should be set to "Never". [Always | CrossSubnet | Never] [Default: Never]
44
        vethMTU: 1440  # The maximum transmission unit (MTU) setting determines the largest packet size that can be transmitted through your network. [Default: 1440]
45
      kubePodsCIDR: 10.233.64.0/18
46
      kubeServiceCIDR: 10.233.0.0/18
47
    registry:
48
      registryMirrors: []
49
      insecureRegistries: []
50
    addons: []
51

52
···
53
# 其它配置可以在安装后之后根据需要进行修改

展开收起

持久化存储配置-待研究暂时默认(OpenEBS)

安装集群

Terminal window

1
./kk create cluster -f config-sample.yaml

查看 KubeSphere 安装日志

Terminal window

1
kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=ks-install -o jsonpath='{.items[0].metadata.name}') -f

kubesphere+k8s安装RabbitMQ集群+镜像模式

Fri, 21 Jan 2022 00:00:00 GMT

1.安装krew#

从krew官网进去,再进入安装文档页

image-20220121145706361

安装git
Terminal window
```
1
yum install -y git
```

执行黑框里的命令

Terminal window

1
(
2
  set -x; cd "$(mktemp -d)" &&
3
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
4
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
5
  KREW="krew-${OS}_${ARCH}" &&
6
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
7
  tar zxvf "${KREW}.tar.gz" &&
8
  ./"${KREW}" install krew
9
)

将下面的语句添加到环境变量中
- 当前窗口执行改命令只在当前窗口有效新开的窗口无效
  Terminal window
```
1
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
```
- 全局生效
  Terminal window
```
1
vim ~/.bashrc
```
  在最后一行添加上诉命令,新开一个窗口即可
安装检查
Terminal window
```
1
kubectl krew
```
image-20220121150302092

2.在kubesphere后台创建一个项目(命名空间)#

为什么这么做呢?因为在操作过程中,通过命令直接安装后,kubesphere后台不显示

image-20220121160719885

3.安装插件#

Terminal window

1
kubectl krew install rabbitmq

image-20220121160020782

3.安装rabbitmq-cluster-operator#

可以使用kubectl rabbitmq -h查询可以携带的参数这里默认

Terminal window

1
kubectl rabbitmq install-cluster-operator

image-20220121161008387

4.创建集群#

Terminal window

1
kubectl rabbitmq -n demo-project create rabbitmq-cluster --replicas 3 --service ClusterIP --image rabbitmq:3.9.13-management

Terminal window

1
-n 指定命名空间
2
rabbitmq-cluster 是实例名称
3
--replicas 副本数
4
--service 创建的服务类型
5
--image 使用的镜像

image-20220121163844833

5.设置NodePort外网访问#

image-20220121164816700

image-20220121164901757

image-20220121164921619

用户名密码从保密字段里找

image-20220121165040917

image-20220121165228493

6.通过任意终端添加用户#

查看集群状态
Terminal window
```
1
rabbitmqctl cluster_status
```
添加用户，用户名为admin，密码为admin
Terminal window
```
1
rabbitmqctl add_user admin admin
```
查看用户列表
Terminal window
```
1
rabbitmqctl list_users
```
给admin用户设置管理员权限
Terminal window
```
1
rabbitmqctl set_user_tags admin administrator
```

其它命令

Terminal window

1
rabbitmqctl delete_user admin # 删除admin用户
2
rabbitmq-server -detached # 启动rabbitmq服务，该命令可以启动erlang虚拟机和rabbitmq服务

将某一节点从硬盘模式改为内存模式
Terminal window
```
1
rabbitmqctl stop_app
2
rabbitmqctl change_cluster_node_type ram
3
rabbitmqctl start_app
```
image-20220121172015118

7.配置镜像集群#

方式一：通过命令行设置

针对某一个队列去配置其对应的镜像其实比较简单，我们只需要去添加一个镜像策略即可：

Terminal window

1
rabbitmqctl set_policy [-p <vhost>] [--priority <priority>] [--apply-to <apply-to>] <name> <pattern> <definition>

Terminal window

1
#设置/交换机的策略名称为ha 对所有队列生效  镜像队列模式为节点 镜像队列消息的同步方式为automatic
2
rabbitmqctl set_policy -p / ha "^" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

image-20201018175458781

image-20201018175533620

方式二：通过后台管理设置

image-20220121183803914

image-20220121183850796

kubesphere+k8s安装nacos2.0集群版

Thu, 20 Jan 2022 00:00:00 GMT

1. 下载源码或者安装包#

从 Github 上下载源码方式
```
1
https://github.com/alibaba/nacos.git
```

下载编译后压缩包(二选一)

1
https://github.com/alibaba/nacos/releases/download/2.0.4/nacos-server-2.0.3.zip

1
https://github.com/alibaba/nacos/releases/download/2.0.4/nacos-server-2.0.3.tar.gz

2.准备好MySQL#

安装MySQL(略)

进入到配置文件目录

Terminal window

1
unzip nacos-server-2.0.3.zip
2
cd nacos-server-2.0.3/nacos/conf

导入数据库

1
/*
2
 * Copyright 1999-2018 Alibaba Group Holding Ltd.
3
 *
4
 * Licensed under the Apache License, Version 2.0 (the "License");
5
 * you may not use this file except in compliance with the License.
6
 * You may obtain a copy of the License at
7
 *
8
 *      http://www.apache.org/licenses/LICENSE-2.0
9
 *
10
 * Unless required by applicable law or agreed to in writing, software
11
 * distributed under the License is distributed on an "AS IS" BASIS,
12
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13
 * See the License for the specific language governing permissions and
14
 * limitations under the License.
15
 */
16

17
/******************************************/
18
/*   数据库全名 = nacos_config   */
19
/*   表名称 = config_info   */
20
/******************************************/
21
CREATE TABLE `config_info` (
22
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
23
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
24
  `group_id` varchar(255) DEFAULT NULL,
25
  `content` longtext NOT NULL COMMENT 'content',
26
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
27
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
28
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
29
  `src_user` text COMMENT 'source user',
30
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
31
  `app_name` varchar(128) DEFAULT NULL,
32
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
33
  `c_desc` varchar(256) DEFAULT NULL,
34
  `c_use` varchar(64) DEFAULT NULL,
35
  `effect` varchar(64) DEFAULT NULL,
36
  `type` varchar(64) DEFAULT NULL,
37
  `c_schema` text,
38
  PRIMARY KEY (`id`),
39
  UNIQUE KEY `uk_configinfo_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
40
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info';
41

42
/******************************************/
43
/*   数据库全名 = nacos_config   */
44
/*   表名称 = config_info_aggr   */
45
/******************************************/
46
CREATE TABLE `config_info_aggr` (
47
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
48
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
49
  `group_id` varchar(255) NOT NULL COMMENT 'group_id',
50
  `datum_id` varchar(255) NOT NULL COMMENT 'datum_id',
51
  `content` longtext NOT NULL COMMENT '内容',
52
  `gmt_modified` datetime NOT NULL COMMENT '修改时间',
53
  `app_name` varchar(128) DEFAULT NULL,
54
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
55
  PRIMARY KEY (`id`),
56
  UNIQUE KEY `uk_configinfoaggr_datagrouptenantdatum` (`data_id`,`group_id`,`tenant_id`,`datum_id`)
57
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='增加租户字段';
58

59
/******************************************/
60
/*   数据库全名 = nacos_config   */
61
/*   表名称 = config_info_beta   */
62
/******************************************/
63
CREATE TABLE `config_info_beta` (
64
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
65
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
66
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
67
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
68
  `content` longtext NOT NULL COMMENT 'content',
69
  `beta_ips` varchar(1024) DEFAULT NULL COMMENT 'betaIps',
70
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
71
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
72
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
73
  `src_user` text COMMENT 'source user',
74
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
75
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
76
  PRIMARY KEY (`id`),
77
  UNIQUE KEY `uk_configinfobeta_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
78
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info_beta';
79

80
/******************************************/
81
/*   数据库全名 = nacos_config   */
82
/*   表名称 = config_info_tag   */
83
/******************************************/
84
CREATE TABLE `config_info_tag` (
85
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
86
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
87
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
88
  `tenant_id` varchar(128) DEFAULT '' COMMENT 'tenant_id',
89
  `tag_id` varchar(128) NOT NULL COMMENT 'tag_id',
90
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
91
  `content` longtext NOT NULL COMMENT 'content',
92
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
93
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
94
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
95
  `src_user` text COMMENT 'source user',
96
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
97
  PRIMARY KEY (`id`),
98
  UNIQUE KEY `uk_configinfotag_datagrouptenanttag` (`data_id`,`group_id`,`tenant_id`,`tag_id`)
99
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info_tag';
100

101
/******************************************/
102
/*   数据库全名 = nacos_config   */
103
/*   表名称 = config_tags_relation   */
104
/******************************************/
105
CREATE TABLE `config_tags_relation` (
106
  `id` bigint(20) NOT NULL COMMENT 'id',
107
  `tag_name` varchar(128) NOT NULL COMMENT 'tag_name',
108
  `tag_type` varchar(64) DEFAULT NULL COMMENT 'tag_type',
109
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
110
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
111
  `tenant_id` varchar(128) DEFAULT '' COMMENT 'tenant_id',
112
  `nid` bigint(20) NOT NULL AUTO_INCREMENT,
113
  PRIMARY KEY (`nid`),
114
  UNIQUE KEY `uk_configtagrelation_configidtag` (`id`,`tag_name`,`tag_type`),
115
  KEY `idx_tenant_id` (`tenant_id`)
116
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_tag_relation';
117

118
/******************************************/
119
/*   数据库全名 = nacos_config   */
120
/*   表名称 = group_capacity   */
121
/******************************************/
122
CREATE TABLE `group_capacity` (
123
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
124
  `group_id` varchar(128) NOT NULL DEFAULT '' COMMENT 'Group ID，空字符表示整个集群',
125
  `quota` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值',
126
  `usage` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '使用量',
127
  `max_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值',
128
  `max_aggr_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数，，0表示使用默认值',
129
  `max_aggr_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值',
130
  `max_history_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量',
131
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
132
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
133
  PRIMARY KEY (`id`),
134
  UNIQUE KEY `uk_group_id` (`group_id`)
135
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='集群、各Group容量信息表';
136

137
/******************************************/
138
/*   数据库全名 = nacos_config   */
139
/*   表名称 = his_config_info   */
140
/******************************************/
141
CREATE TABLE `his_config_info` (
142
  `id` bigint(64) unsigned NOT NULL,
143
  `nid` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
144
  `data_id` varchar(255) NOT NULL,
145
  `group_id` varchar(128) NOT NULL,
146
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
147
  `content` longtext NOT NULL,
148
  `md5` varchar(32) DEFAULT NULL,
149
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
150
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
151
  `src_user` text,
152
  `src_ip` varchar(50) DEFAULT NULL,
153
  `op_type` char(10) DEFAULT NULL,
154
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
155
  PRIMARY KEY (`nid`),
156
  KEY `idx_gmt_create` (`gmt_create`),
157
  KEY `idx_gmt_modified` (`gmt_modified`),
158
  KEY `idx_did` (`data_id`)
159
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='多租户改造';
160

161
/******************************************/
162
/*   数据库全名 = nacos_config   */
163
/*   表名称 = tenant_capacity   */
164
/******************************************/
165
CREATE TABLE `tenant_capacity` (
166
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
167
  `tenant_id` varchar(128) NOT NULL DEFAULT '' COMMENT 'Tenant ID',
168
  `quota` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值',
169
  `usage` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '使用量',
170
  `max_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值',
171
  `max_aggr_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数',
172
  `max_aggr_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值',
173
  `max_history_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量',
174
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
175
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
176
  PRIMARY KEY (`id`),
177
  UNIQUE KEY `uk_tenant_id` (`tenant_id`)
178
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='租户容量信息表';
179

180
CREATE TABLE `tenant_info` (
181
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
182
  `kp` varchar(128) NOT NULL COMMENT 'kp',
183
  `tenant_id` varchar(128) default '' COMMENT 'tenant_id',
184
  `tenant_name` varchar(128) default '' COMMENT 'tenant_name',
185
  `tenant_desc` varchar(256) DEFAULT NULL COMMENT 'tenant_desc',
186
  `create_source` varchar(32) DEFAULT NULL COMMENT 'create_source',
187
  `gmt_create` bigint(20) NOT NULL COMMENT '创建时间',
188
  `gmt_modified` bigint(20) NOT NULL COMMENT '修改时间',
189
  PRIMARY KEY (`id`),
190
  UNIQUE KEY `uk_tenant_info_kptenantid` (`kp`,`tenant_id`),
191
  KEY `idx_tenant_id` (`tenant_id`)
192
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='tenant_info';
193

194
CREATE TABLE `users` (
195
  `username` varchar(50) NOT NULL PRIMARY KEY,
196
  `password` varchar(500) NOT NULL,
197
  `enabled` boolean NOT NULL
198
);
199

200
CREATE TABLE `roles` (
201
  `username` varchar(50) NOT NULL,
202
  `role` varchar(50) NOT NULL,
203
  UNIQUE INDEX `idx_user_role` (`username` ASC, `role` ASC) USING BTREE
204
);
205

206
CREATE TABLE `permissions` (
207
    `role` varchar(50) NOT NULL,
208
    `resource` varchar(255) NOT NULL,
209
    `action` varchar(8) NOT NULL,
210
    UNIQUE INDEX `uk_role_permission` (`role`,`resource`,`action`) USING BTREE
211
);
212

213
INSERT INTO users (username, password, enabled) VALUES ('nacos', '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu', TRUE);
214

215
INSERT INTO roles (username, role) VALUES ('nacos', 'ROLE_ADMIN');

展开收起

3.从kubesphere上安装#

添加配置application.properties

修改配置文件中的数据库信息-修改成自己的

1
#
2
# Copyright 1999-2021 Alibaba Group Holding Ltd.
3
#
4
# Licensed under the Apache License, Version 2.0 (the "License");
5
# you may not use this file except in compliance with the License.
6
# You may obtain a copy of the License at
7
#
8
#      http://www.apache.org/licenses/LICENSE-2.0
9
#
10
# Unless required by applicable law or agreed to in writing, software
11
# distributed under the License is distributed on an "AS IS" BASIS,
12
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13
# See the License for the specific language governing permissions and
14
# limitations under the License.
15
#
16

17
#*************** Spring Boot Related Configurations ***************#
18
### Default web context path:
19
server.servlet.contextPath=/nacos
20
### Default web server port:
21
server.port=8848
22

23
#*************** Network Related Configurations ***************#
24
### If prefer hostname over ip for Nacos server addresses in cluster.conf:
25
# nacos.inetutils.prefer-hostname-over-ip=false
26

27
### Specify local server's IP:
28
# nacos.inetutils.ip-address=
29

30
#*************** Config Module Related Configurations ***************#
31
### If use MySQL as datasource:
32
spring.datasource.platform=mysql
33

34
### Count of DB:
35
db.num=1
36

37
### Connect URL of DB:
38
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
39
db.user.0=nacos
40
db.password.0=nacos
41

42
### Connection pool configuration: hikariCP
43
db.pool.config.connectionTimeout=30000
44
db.pool.config.validationTimeout=10000
45
db.pool.config.maximumPoolSize=20
46
db.pool.config.minimumIdle=2
47

48
#*************** Naming Module Related Configurations ***************#
49
### Data dispatch task execution period in milliseconds: Will removed on v2.1.X, replace with nacos.core.protocol.distro.data.sync.delayMs
50
# nacos.naming.distro.taskDispatchPeriod=200
51

52
### Data count of batch sync task: Will removed on v2.1.X. Deprecated
53
# nacos.naming.distro.batchSyncKeyCount=1000
54

55
### Retry delay in milliseconds if sync task failed: Will removed on v2.1.X, replace with nacos.core.protocol.distro.data.sync.retryDelayMs
56
# nacos.naming.distro.syncRetryDelay=5000
57

58
### If enable data warmup. If set to false, the server would accept request without local data preparation:
59
# nacos.naming.data.warmup=true
60

61
### If enable the instance auto expiration, kind like of health check of instance:
62
# nacos.naming.expireInstance=true
63

64
### will be removed and replaced by `nacos.naming.clean` properties
65
nacos.naming.empty-service.auto-clean=true
66
nacos.naming.empty-service.clean.initial-delay-ms=50000
67
nacos.naming.empty-service.clean.period-time-ms=30000
68

69
### Add in 2.0.0
70
### The interval to clean empty service, unit: milliseconds.
71
# nacos.naming.clean.empty-service.interval=60000
72

73
### The expired time to clean empty service, unit: milliseconds.
74
# nacos.naming.clean.empty-service.expired-time=60000
75

76
### The interval to clean expired metadata, unit: milliseconds.
77
# nacos.naming.clean.expired-metadata.interval=5000
78

79
### The expired time to clean metadata, unit: milliseconds.
80
# nacos.naming.clean.expired-metadata.expired-time=60000
81

82
### The delay time before push task to execute from service changed, unit: milliseconds.
83
# nacos.naming.push.pushTaskDelay=500
84

85
### The timeout for push task execute, unit: milliseconds.
86
# nacos.naming.push.pushTaskTimeout=5000
87

88
### The delay time for retrying failed push task, unit: milliseconds.
89
# nacos.naming.push.pushTaskRetryDelay=1000
90

91
### Since 2.0.3
92
### The expired time for inactive client, unit: milliseconds.
93
# nacos.naming.client.expired.time=180000
94

95
#*************** CMDB Module Related Configurations ***************#
96
### The interval to dump external CMDB in seconds:
97
# nacos.cmdb.dumpTaskInterval=3600
98

99
### The interval of polling data change event in seconds:
100
# nacos.cmdb.eventTaskInterval=10
101

102
### The interval of loading labels in seconds:
103
# nacos.cmdb.labelTaskInterval=300
104

105
### If turn on data loading task:
106
# nacos.cmdb.loadDataAtStart=false
107

108
#*************** Metrics Related Configurations ***************#
109
### Metrics for prometheus
110
#management.endpoints.web.exposure.include=*
111

112
### Metrics for elastic search
113
management.metrics.export.elastic.enabled=false
114
#management.metrics.export.elastic.host=http://localhost:9200
115

116
### Metrics for influx
117
management.metrics.export.influx.enabled=false
118
#management.metrics.export.influx.db=springboot
119
#management.metrics.export.influx.uri=http://localhost:8086
120
#management.metrics.export.influx.auto-create-db=true
121
#management.metrics.export.influx.consistency=one
122
#management.metrics.export.influx.compressed=true
123

124
#*************** Access Log Related Configurations ***************#
125
### If turn on the access log:
126
server.tomcat.accesslog.enabled=true
127

128
### The access log pattern:
129
server.tomcat.accesslog.pattern=%h %l %u %t "%r" %s %b %D %{User-Agent}i %{Request-Source}i
130

131
### The directory of access log:
132
server.tomcat.basedir=
133

134
#*************** Access Control Related Configurations ***************#
135
### If enable spring security, this option is deprecated in 1.2.0:
136
#spring.security.enabled=false
137

138
### The ignore urls of auth, is deprecated in 1.2.0:
139
nacos.security.ignore.urls=/,/error,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-ui/public/**,/v1/auth/**,/v1/console/health/**,/actuator/**,/v1/console/server/**
140

141
### The auth system to use, currently only 'nacos' and 'ldap' is supported:
142
nacos.core.auth.system.type=nacos
143

144
### If turn on auth system:
145
nacos.core.auth.enabled=false
146

147
### worked when nacos.core.auth.system.type=ldap，{0} is Placeholder,replace login username
148
# nacos.core.auth.ldap.url=ldap://localhost:389
149
# nacos.core.auth.ldap.userdn=cn={0},ou=user,dc=company,dc=com
150

151
### The token expiration in seconds:
152
nacos.core.auth.default.token.expire.seconds=18000
153

154
### The default token:
155
nacos.core.auth.default.token.secret.key=SecretKey012345678901234567890123456789012345678901234567890123456789
156

157
### Turn on/off caching of auth information. By turning on this switch, the update of auth information would have a 15 seconds delay.
158
nacos.core.auth.caching.enabled=true
159

160
### Since 1.4.1, Turn on/off white auth for user-agent: nacos-server, only for upgrade from old version.
161
nacos.core.auth.enable.userAgentAuthWhite=false
162

163
### Since 1.4.1, worked when nacos.core.auth.enabled=true and nacos.core.auth.enable.userAgentAuthWhite=false.
164
### The two properties is the white list for auth and used by identity the request from other server.
165
nacos.core.auth.server.identity.key=serverIdentity
166
nacos.core.auth.server.identity.value=security
167

168
#*************** Istio Related Configurations ***************#
169
### If turn on the MCP server:
170
nacos.istio.mcp.server.enabled=false
171

172
#*************** Core Related Configurations ***************#
173

174
### set the WorkerID manually
175
# nacos.core.snowflake.worker-id=
176

177
### Member-MetaData
178
# nacos.core.member.meta.site=
179
# nacos.core.member.meta.adweight=
180
# nacos.core.member.meta.weight=
181

182
### MemberLookup
183
### Addressing pattern category, If set, the priority is highest
184
# nacos.core.member.lookup.type=[file,address-server]
185
## Set the cluster list with a configuration file or command-line argument
186
# nacos.member.list=192.168.16.101:8847?raft_port=8807,192.168.16.101?raft_port=8808,192.168.16.101:8849?raft_port=8809
187
## for AddressServerMemberLookup
188
# Maximum number of retries to query the address server upon initialization
189
# nacos.core.address-server.retry=5
190
## Server domain name address of [address-server] mode
191
# address.server.domain=jmenv.tbsite.net
192
## Server port of [address-server] mode
193
# address.server.port=8080
194
## Request address of [address-server] mode
195
# address.server.url=/nacos/serverlist
196

197
#*************** JRaft Related Configurations ***************#
198

199
### Sets the Raft cluster election timeout, default value is 5 second
200
# nacos.core.protocol.raft.data.election_timeout_ms=5000
201
### Sets the amount of time the Raft snapshot will execute periodically, default is 30 minute
202
# nacos.core.protocol.raft.data.snapshot_interval_secs=30
203
### raft internal worker threads
204
# nacos.core.protocol.raft.data.core_thread_num=8
205
### Number of threads required for raft business request processing
206
# nacos.core.protocol.raft.data.cli_service_thread_num=4
207
### raft linear read strategy. Safe linear reads are used by default, that is, the Leader tenure is confirmed by heartbeat
208
# nacos.core.protocol.raft.data.read_index_type=ReadOnlySafe
209
### rpc request timeout, default 5 seconds
210
# nacos.core.protocol.raft.data.rpc_request_timeout_ms=5000
211

212
#*************** Distro Related Configurations ***************#
213

214
### Distro data sync delay time, when sync task delayed, task will be merged for same data key. Default 1 second.
215
# nacos.core.protocol.distro.data.sync.delayMs=1000
216

217
### Distro data sync timeout for one sync data, default 3 seconds.
218
# nacos.core.protocol.distro.data.sync.timeoutMs=3000
219

220
### Distro data sync retry delay time when sync data failed or timeout, same behavior with delayMs, default 3 seconds.
221
# nacos.core.protocol.distro.data.sync.retryDelayMs=3000
222

223
### Distro data verify interval time, verify synced data whether expired for a interval. Default 5 seconds.
224
# nacos.core.protocol.distro.data.verify.intervalMs=5000
225

226
### Distro data verify timeout for one verify, default 3 seconds.
227
# nacos.core.protocol.distro.data.verify.timeoutMs=3000
228

229
### Distro data load retry delay when load snapshot data failed, default 30 seconds.
230
# nacos.core.protocol.distro.data.load.retryDelayMs=30000

展开收起

image-20220120105455342

image-20220120105544787

image-20220120110258708

添加cluster.conf配置

ip规则是<工作负载-编号>.服务名.项目名.svc.cluster.local

1
#
2
# Copyright 1999-2018 Alibaba Group Holding Ltd.
3
#
4
# Licensed under the Apache License, Version 2.0 (the "License");
5
# you may not use this file except in compliance with the License.
6
# You may obtain a copy of the License at
7
#
8
#      http://www.apache.org/licenses/LICENSE-2.0
9
#
10
# Unless required by applicable law or agreed to in writing, software
11
# distributed under the License is distributed on an "AS IS" BASIS,
12
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13
# See the License for the specific language governing permissions and
14
# limitations under the License.
15
#
16

17
#it is ip
18
#example
19
nacos-v1-0.nacos.demo-project.svc.cluster.local:8848
20
nacos-v1-1.nacos.demo-project.svc.cluster.local:8848
21
nacos-v1-2.nacos.demo-project.svc.cluster.local:8848

展开收起

image-20220120112046328

创建服务

image-20220120112327902

image-20220120132547817

image-20220120132708373

image-20220120133027957

image-20220120133558415

image-20220120133622790

image-20220120133656474

启动效果

image-20220120134635330
暴露外网访问

image-20220120134739184

image-20220120134805937

image-20220120134845709

image-20220120134935001

image-20220120135013034

image-20220120135039296

访问效果

image-20220120140304585

docker安装nacos2.0MySQL单机版

Thu, 16 Dec 2021 00:00:00 GMT

下载nacos源码包我下载的2.0.3版本,上传到服务器上

Terminal window

1
tar -xvf nacos-docker-2.0.3.tar.gz

Terminal window

1
mkdir -p /usr/local/docker/nacos-server
2
mkdir -p /usr/local/docker/nacos-server/env
3
mkdir -p /usr/local/docker/nacos-server/logs
4
mkdir -p /usr/local/docker/nacos-server/init.d

Terminal window

1
cp example/custom.properties /usr/local/docker/nacos-server/init.d/
2
cp env/nacos-standlone-mysql.env /usr/local/docker/nacos-server/env/

Terminal window

1
cd /usr/local/docker/nacos-server

Terminal window

1
vim env/nacos-standlone-mysql.env

1
PREFER_HOST_MODE=hostname
2
MODE=standalone
3
SPRING_DATASOURCE_PLATFORM=mysql
4
MYSQL_SERVICE_HOST=192.168.0.233
5
MYSQL_SERVICE_DB_NAME=nacos
6
MYSQL_SERVICE_PORT=3306
7
MYSQL_SERVICE_USER=root
8
MYSQL_SERVICE_PASSWORD=root
9

10
JVM_XMS=512m
11
JVM_XMX=512m
12
JVM_XMN=256m

Terminal window

1
docker run -p 8848:8848 -p 9848:9848 -p 9849:9849 --restart=always --name nacos --env-file=/usr/local/docker/nacos-server/env/nacos-standlone-mysql.env -v /usr/local/docker/nacos-server/logs:/home/nacos/logs -v /usr/local/docker/nacos-server/init.d/custom.properties:/home/nacos/init.d/custom.properties -d nacos/nacos-server:2.0.3

dubbo服务提供者无法捕捉自定义异常的问题解决

Thu, 16 Dec 2021 00:00:00 GMT

一、问题#

Dubbo服务调用过程中抛出的自定义异常捕获不到，总是抛出了一个RuntimeException包装了自定义异常，导致全局异常处理器捕捉不到自定义异常。

经过断点可知:

image-20211216143614030

自定义异常确实被包装成了RuntimeException异常。

经过断点调试跳转到ExceptionFilter这个类,在org.apache.dubbo.rpc.filter下,贴出源码版本2

7.8

1
package org.apache.dubbo.rpc.filter;
2

3
import org.apache.dubbo.common.constants.CommonConstants;
4
import org.apache.dubbo.common.extension.Activate;
5
import org.apache.dubbo.common.logger.Logger;
6
import org.apache.dubbo.common.logger.LoggerFactory;
7
import org.apache.dubbo.common.utils.ReflectUtils;
8
import org.apache.dubbo.common.utils.StringUtils;
9
import org.apache.dubbo.rpc.Filter;
10
import org.apache.dubbo.rpc.Invocation;
11
import org.apache.dubbo.rpc.Invoker;
12
import org.apache.dubbo.rpc.Result;
13
import org.apache.dubbo.rpc.RpcContext;
14
import org.apache.dubbo.rpc.RpcException;
15
import org.apache.dubbo.rpc.service.GenericService;
16

17
import java.lang.reflect.Method;
18

19
/**
20
 * ExceptionInvokerFilter
21
 * <p>
22
 * Functions:
23
 * <ol>
24
 * <li>unexpected exception will be logged in ERROR level on provider side. Unexpected exception are unchecked
25
 * exception not declared on the interface</li>
26
 * <li>Wrap the exception not introduced in API package into RuntimeException. Framework will serialize the outer exception but stringnize its cause in order to avoid of possible serialization problem on client side</li>
27
 * </ol>
28
 */
29
@Activate(group = CommonConstants.PROVIDER)
30
public class ExceptionFilter implements Filter, Filter.Listener {
31
    private Logger logger = LoggerFactory.getLogger(ExceptionFilter.class);
32

33
    @Override
34
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
35
        return invoker.invoke(invocation);
36
    }
37

38
    @Override
39
    public void onResponse(Result appResponse, Invoker<?> invoker, Invocation invocation) {
40
        if (appResponse.hasException() && GenericService.class != invoker.getInterface()) {
41
            try {
42
                Throwable exception = appResponse.getException();
43

44
                // directly throw if it's checked exception
45
                // 检查是否是RuntimeException或者Exception 我的自定义异常继承自RuntimeException 不满足此条件
46
                if (!(exception instanceof RuntimeException) && (exception instanceof Exception)) {
47
                    return;
48
                }
49
                // directly throw if the exception appears in the signature
50
                // 方法上也没有声明我的自定义异常 不满足此条件
51
                try {
52
                    Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());
53
                    Class<?>[] exceptionClassses = method.getExceptionTypes();
54
                    for (Class<?> exceptionClass : exceptionClassses) {
55
                        if (exception.getClass().equals(exceptionClass)) {
56
                            return;
57
                        }
58
                    }
59
                } catch (NoSuchMethodException e) {
60
                    return;
61
                }
62

63
                // for the exception not found in method's signature, print ERROR message in server's log.
64
                logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception);
65

66
                // directly throw if exception class and interface class are in the same jar file.
67
                // 如果异常类和接口类在同一jar文件中，则直接抛出 接口和异常不在同一个jar包中 不满足
68
                String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());
69
                String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());
70
                if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)) {
71
                    return;
72
                }
73
                // directly throw if it's JDK exception
74
                // 如果是JDK异常 直接抛出 我的是自定义异常  不满足
75
                String className = exception.getClass().getName();
76
                if (className.startsWith("java.") || className.startsWith("javax.")) {
77
                    return;
78
                }
79
                // directly throw if it's dubbo exception
80
                // 如果是dubbo的异常 直接抛出 我的自定义异常 不满足
81
                if (exception instanceof RpcException) {
82
                    return;
83
                }
84

85
                // otherwise, wrap with RuntimeException and throw back to the client
86
                // 这里就说明了,其它异常会包装成一个RuntimeException并返回给客户端
87
                appResponse.setException(new RuntimeException(StringUtils.toString(exception)));
88
            } catch (Throwable e) {
89
                logger.warn("Fail to ExceptionFilter when called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
90
            }
91
        }
92
    }
93

94
    @Override
95
    public void onError(Throwable e, Invoker<?> invoker, Invocation invocation) {
96
        logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
97
    }
98

99
    // For test purpose
100
    public void setLogger(Logger logger) {
101
        this.logger = logger;
102
    }
103
}

展开收起

二、解决方案#

在方法上声明自定义异常也就是throws 自定义异常
将异常和接口放到同一个包下
重写一个ExceptionFilter替代dubbo的ExceptionFilter

这里说下方案3 代码就是复制的ExceptionFilter的代码需要在里面把我们的自定义异常处理一下顺便把otherwise下面的包装成我们的自定义异常,不让它再包装成RuntimeException

1
import com.tianch.platform.common.log.exception.PException;
2
import com.tianch.platform.common.log.exception.enmus.PExceptionEnum;
3
import lombok.extern.slf4j.Slf4j;
4
import org.apache.dubbo.common.constants.CommonConstants;
5
import org.apache.dubbo.common.extension.Activate;
6
import org.apache.dubbo.common.utils.ReflectUtils;
7
import org.apache.dubbo.rpc.*;
8
import org.apache.dubbo.rpc.service.GenericService;
9

10
import java.lang.reflect.Method;
11

12
@Slf4j
13
@Activate(group = CommonConstants.PROVIDER)
14
public class DubboProviderFilter implements Filter, Filter.Listener {
15

16
    @Override
17
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws org.apache.dubbo.rpc.RpcException {
18
        return invoker.invoke(invocation);
19
    }
20

21
    @Override
22
    public void onResponse(Result appResponse, Invoker<?> invoker, Invocation invocation) {
23
        if (appResponse.hasException() && GenericService.class != invoker.getInterface()) {
24
            try {
25
                Throwable exception = appResponse.getException();
26

27
                // directly throw if it's checked exception
28
                if (!(exception instanceof RuntimeException) && (exception instanceof Exception)) {
29
                    return;
30
                }
31
                // directly throw if the exception appears in the signature
32
                try {
33
                    Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());
34
                    Class<?>[] exceptionClassses = method.getExceptionTypes();
35
                    for (Class<?> exceptionClass : exceptionClassses) {
36
                        if (exception.getClass().equals(exceptionClass)) {
37
                            return;
38
                        }
39
                    }
40
                } catch (NoSuchMethodException e) {
41
                    return;
42
                }
43

44
                // for the exception not found in method's signature, print ERROR message in server's log.
45
                log.error("Got unchecked and undeclared exception which called by " + org.apache.dubbo.rpc.RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception);
46

47
                // directly throw if exception class and interface class are in the same jar file.
48
                String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());
49
                String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());
50
                if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)) {
51
                    return;
52
                }
53
                // directly throw if it's JDK exception
54
                String className = exception.getClass().getName();
55
                if (className.startsWith("java.") || className.startsWith("javax.")) {
56
                    return;
57
                }
58
                // directly throw if it's dubbo exception
59
                if (exception instanceof RpcException) {
60
                    return;
61
                }
62

63
                // 如果是我们的自定义异常
64
                if (exception instanceof PException) {
65
                    return;
66
                }
67

68
                 // otherwise, 包装成我们的自定义异常
69
                String application = invoker.getUrl().getParameter(CommonConstants.APPLICATION_KEY);
70
                PException pException = new PException(application, PExceptionEnum.SYSTEM_EXCEPTION.getCode(), exception.getMessage());
71
                appResponse.setException(pException);
72
            } catch (Throwable e) {
73
                log.warn("Fail to ExceptionFilter when called by " + org.apache.dubbo.rpc.RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
74
            }
75
        }
76
    }
77

78
    @Override
79
    public void onError(Throwable e, Invoker<?> invoker, Invocation invocation) {
80
        log.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
81
    }
82

83
}

展开收起

和dubbo一样,利用SPI机制加载我们的异常过滤器

image-20211216152335306

仿照这个文件写一个把我们自己的异常过滤器声明出来

image-20211216152515977

在配置里去掉dubbo的异常过滤器并加上我们自己的异常过滤器

image-20211216152639390

注意-是排除

nacos升级2.x之后 9848连接超时异常问题解决

Thu, 16 Dec 2021 00:00:00 GMT

首先说明我的nacos采用docker方式部署,只开放了8848端口.nacos从1.4升级到2.0之后,客户端连接总是报9948端口无法连接的问题,看遍了配置文件也没有找到任何关于9848的配置,我擦泪,于是就去看了官网

https://nacos.io/zh-cn/docs/2.0.0-compatibility.html

官网的解释如下

新版本部署#

Nacos2.0版本相比1.X新增了gRPC的通信方式，因此需要增加2个端口。新增端口是在配置的主端口(server.port)基础上，进行一定偏移量自动生成。

端口	与主端口的偏移量	描述
9848	1000	客户端gRPC请求服务端端口，用于客户端向服务端发起连接和请求
9849	1001	服务端gRPC请求服务端端口，用于服务间同步等

使用VIP/nginx请求时，需要配置成TCP转发，不能配置http2转发，否则连接会被nginx断开。

客户端拥有相同的计算逻辑，用户如同1.X的使用方式，配置主端口(默认8848)，通过相同的偏移量，计算对应gRPC端口(默认9848)。

因此如果客户端和服务端之前存在端口转发，或防火墙时，需要对端口转发配置和防火墙配置做相应的调整。

兼容性#

Nacos2.0的服务端完全兼容1.X客户端。Nacos2.0客户端由于使用了gRPC，无法兼容Nacos1.X服务端，请勿使用2.0以上版本客户端连接Nacos1.X服务端。

功能完成度及旧版本客户端适配情况：#

配置中心#

JAVA SDK#

完全兼容1.X客户端所有API接口方法；
完全实现2.0客户端所有API接口方法。

其他语言 SDK#

完全兼容

openAPI#

完全兼容所有配置中心相关openAPI。

服务发现#

JAVA SDK#

完全兼容1.X客户端所有API接口方法；
完全兼容2.0客户端所有API接口方法；

其他语言 SDK#

完全兼容所有服务发现相关openAPI。

最终将9848和9849端口也开放之后,再启动服务就不报错了,并且也正常注册上去了

完美解决IDEA自定义方法注释没有参数列表问题

Thu, 16 Dec 2021 00:00:00 GMT

只有截图和关键配置

image-20211216153557366

1
/**

image-20211216153609274

1
*
2
* $param$
3
* @return $return$
4
* @description TODO 描述
5
* @author tianch
6
* @date $date$
7
*/

image-20211216153726066

1
groovyScript("if(\"${_1}\".length() == 2) {return '';} else {def result='*'; def params=\"${_1}\".replaceAll('[\\\\[|\\\\]|\\\\s]', '').split(',').toList(); for(i = 0; i < params.size(); i++) { if(i==0) result='@param ' + params[i] + ' ' + params[i] + '\\n'; else result+=' * @param ' + params[i] + ' ' + params[i] + ((i < params.size() - 1) ? '\\n' : '')}; return result}", methodParameters())

1
methodReturnType()

1
date("yyyy/MM/dd HH:mm")

无效的目标发行版 11 的问题解决办法

Thu, 16 Dec 2021 00:00:00 GMT

安装了JDK11之后，将原本基于java8的项目换成了java11，然而在maven打包的时候报错：无效的目标发行版 11。

百度上查，千篇一律写的都是修改项目设置：将JDK的版本从8改成11,然后修改模块SDK设置,将JDK8改成JDK11

然而以上操作并没有什么卵用,最终在一篇文章中找到了解决方案,特此记录一下:

image-20211216142646897

Nginx设置keepalive提升吞吐量

Wed, 14 Jul 2021 00:00:00 GMT

在 nginx 中, 对于 http1.0 和 http1.1 是支持长连接的, http 请求是基于 tcp 协议之上的, 那么当客户端发起请求前, 需要先与服务器建立 tcp 连接, 而每次的 tcp 连接是需要三次握手来确定的, 如果客户端与服务端之间的网络差了一点, 那么这三次握手的时间消耗就比较多, 同时也会带来不必要的流量消耗,当然断开连接还要有四次的挥手端开的交互;
在 HTTP 协议中, 请求是请求与应答的模式, 如果我们可以在一个连接上; 响应多个请求, 那么这个就是所谓的长连接;
我们来看看 HTTP协议在响应的主体 body 的长度的描述
http1.0: 如果请求中有 Content-Length 头, 则以 Content-length 的数值作为 body的长度, 客户端在接收完 body 时, 就可以依照这个长度来接收数据, 接收完就表示这个请求完成了, 如果没有这个字段来标示, 那么客户端会一直接收数据, 直到服务器主动关闭连接
http1.1: 如果响应头中的 Transfer-encoding 为 chunked 传输, 则表示 body 是流式传输, body 会被分割为多个 chunk; 每个chunk的开始会标识出当前块的长度, 此时body 不需要通过长度来制定了, 如果是非chunked 传输, 而且有content-length 的字段, 那么就会按照这个字段的长度来接收数据, 如果不是 chunked, 又没有 Content-length 这个字段, 那么就会一直接收到服务器主动关闭连接
当服务器传输完 body 之后, 会考虑使用长连接, 能否使用短连接, 也有条件限制, 如果客户端的请求头中的 connection 为 close; 则标识客户端需要关闭长连接, 如果为 keep-alive; 则客户端需要打开长连接, 如果请求头中没有这个字段, 根据协议: 1.0 默认为 close; 1.1 默认为 keep-alive; 那么nginx 在传输完响应体后, 会设置当前连接的 keepalive 属性, 然后等待客户端下一次请求, 当然 nginx 不可能会一直的等待, 当 nginx 设置 keepalive 等待下一次的请求时, 会设置一个最大的等待时间, 通过 keepalive_timeout 来配置, 如果配置为 0 ; 则表示关闭 keepalive; 此时 http 版本不管是 1.0, 还是 1.1; 客户端的 connection 不管是 close 还是 keepalive; 都会强制设置为 close
如果 connection 为 close; 那么在 nginx 响应完数据后, 会主动关闭连接, 那么对请求比较大的 nginx 来说, 关掉 keepalive 最后会产生比较多的 time-wait 状态的 socket; 一般来说, 当客户端的一次访问, 需要多次访问同一个 server 时, 打开 keepalive 的优势非常大

nginx 使用反向代理时保持长连接

长连接的优势就是在一个 tcp 连接上可以传输多个 HTTP 请求, 减少建立连接和关闭连接的消耗和延迟

当 nginx 作为反向代理时

从 Client 到 Nginx 的连接是长连接 \

1
http {
2
    # 客户端连接的超时时间, 为 0 时禁用长连接,
3
    keepalive_timeout 120s;
4
    # 在一个长连接上可以服务的最大请求数目, 当达到最大请求数目且所有已有请求结束后, 连接被关闭, 默认为 100, 即每个连接的最大请求数
5
    keepalive_request 10000;
6
}

Nginx 到 Server(upstream) 的长连接

1
upstream mytest {
2
    server 192.168.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;
3
    server 192.168.0.2:8080 weight=1 max_fails=2 fail_timeout=30s;
4
    # 这个参数非常重要
5
    keepalive 300
6
}

1
server {
2
    listen 80;
3
    server_name www.tianch.xyz;
4
    location / {
5
        proxy_pass http://mytest;
6
        proxy_http_version 1.1;
7
     proxy_set_header Connection "";
8
    }
9
}

keepalive: 这个参数是 nginx 连接后端的连接池中的最大空闲连接数, 比如: 设置为 300; 如果 nginx 为了满足请求的 qps; 创建了 1000 个连接的连接池, 这个时候只有 500 个请求多来, 那么 1000- 500 = 500; 那么就会多出 500 个空闲的连接, 那么 500 > 300; 那么 nginx 就会根据这个配置; 断开 200 个请求连接; 那么这个时候就只有 800 个连接的连接池, 如果下次过来了 1000 个请求, 那么 nginx 又会开始创建连接; 所有这个数值的配置要小心配置

参考链接：https://www.jianshu.com/p/394a7883a139

Nginx解决跨域问题、配置静态防盗链

Mon, 12 Jul 2021 00:00:00 GMT

跨域问题的解决

现象 location / { #允许带上cookie请求 add_header ‘Access-Control-Allow-Credentials’ ‘true’; #允许跨域请求的域，*代表所有 add_header Access-Control-Allow-Origin ; #允许请求的方法，比如 GET/POST/PUT/DELETE add_header Access-Control-Allow-Methods ‘GET, POST, OPTIONS’; #允许请求的header add_header Access-Control-Allow-Headers ''; } `

设置静态资源防盗链

配置一个静态资源

server { listen 81; server_name localhost;

1
location /img {
2

3
    root   html;
4
    index  index.html index.htm;
5
}

} ` 未开启防盗链效果 server { listen 81; server_name localhost;

1
location /img {
2

3
    #对源站点验证
4
    valid_referers *.tianch.xyz;
5
    #非法引入会进入下方判断
6
    if ($invalid_referer) {
7
        return 403;
8
    }
9

10
    root   html;
11
    index  index.html index.htm;
12
}

} ` 开启防盗链效果

事务的传播行为

Fri, 02 Jul 2021 00:00:00 GMT

1.什么是事务传播行为？

事务传播行为用来描述由某一个事务传播行为修饰的方法被嵌套进另一个方法的时事务如何传播。

即然是传播，那么至少有两个东西，才可以发生传播。单体不存在传播这个行为。

事务传播行为（propagation behavior）指的就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行。

1
public void methodA(){
2
    methodB();
3
    //doSomething
4
}
5

6
@Transaction(Propagation=XXX)
7
public void methodB(){
8
    //doSomething
9
}

代码中methodA()方法嵌套调用了methodB()方法，methodB()的事务传播行为由@Transaction(Propagation=XXX)设置决定。这里需要注意的是methodA()并没有开启事务，某一个事务传播行为修饰的方法并不是必须要在开启事务的外围方法中调用。

Spring中七种事务传播行为

事务传播行为类型说明

PROPAGATION_REQUIRED如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这也是默认的传播行为。 PROPAGATION_SUPPORTS支持当前事务，如果当前没有事务，就以非事务方式执行。 PROPAGATION_MANDATORY使用当前的事务，如果当前没有事务，就抛出异常。 PROPAGATION_REQUIRES_NEW新建事务，如果当前存在事务，把当前事务挂起。 PROPAGATION_NOT_SUPPORTED以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 PROPAGATION_NEVER以非事务方式执行，如果当前存在事务，则抛出异常。 PROPAGATION_NESTED如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

3.验证

准备工作

创建表

1
CREATE TABLE `user1` (
2
  `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
3
  `name` VARCHAR(45) NOT NULL DEFAULT '',
4
  PRIMARY KEY(`id`)
5
)
6
ENGINE = InnoDB;
7

8
CREATE TABLE `user2` (
9
  `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
10
  `name` VARCHAR(45) NOT NULL DEFAULT '',
11
  PRIMARY KEY(`id`)
12
)
13
ENGINE = InnoDB;

实体类

1
public class User1 {
2
    private Integer id;
3
    private String name;
4
   //get和set方法省略...
5
}
6

7
public class User2 {
8
    private Integer id;
9
    private String name;
10
   //get和set方法省略...
11
}

Mapper类

1
public interface User1Mapper {
2
    int insert(User1 record);
3
    User1 selectByPrimaryKey(Integer id);
4
    //其他方法省略...
5
}
6

7
public interface User2Mapper {
8
    int insert(User2 record);
9
    User2 selectByPrimaryKey(Integer id);
10
    //其他方法省略...
11
}

1.PROPAGATION_REQUIRED (抛出的异常一定得是运行时异常)

1
@Service
2
public class User1ServiceImpl implements User1Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.REQUIRED)
6
    public void addRequired(User1 user){
7
        user1Mapper.insert(user);
8
    }
9
}
10

11
@Service
12
public class User2ServiceImpl implements User2Service {
13
    //省略其他...
14
    @Override
15
    @Transactional(propagation = Propagation.REQUIRED)
16
    public void addRequired(User2 user){
17
        user2Mapper.insert(user);
18
    }
19
    @Override
20
    @Transactional(propagation = Propagation.REQUIRED)
21
    public void addRequiredException(User2 user){
22
        user2Mapper.insert(user);
23

24
        throw new RuntimeException();
25
    }
26

27
}

展开收起

1.1 外围方法不开启事务

验证方法1:

1
@Override
2
public void notransaction_exception_required_required(){
3
    User1 user1=new User1();
4
    user1.setName("张三");
5
    user1Service.addRequired(user1);
6

7
    User2 user2=new User2();
8
    user2.setName("李四");
9
    user2Service.addRequired(user2);
10

11
    throw new RuntimeException();
12
}

验证方法2:

1
@Override
2
public void notransaction_required_required_exception(){
3
    User1 user1=new User1();
4
    user1.setName("张三");
5
    user1Service.addRequired(user1);
6

7
    User2 user2=new User2();
8
    user2.setName("李四");
9
    user2Service.addRequiredException(user2);
10
}

结果 :

验证方法序号数据库结果结果分析

1“张三”、“李四”均插入。外围方法未开启事务，插入“张三”、“李四”方法在自己的事务中独立运行，外围方法异常不影响内部插入“张三”、“李四”方法独立的事务。 2“张三”插入，“李四”未插入。外围方法没有事务，插入“张三”、“李四”方法都在自己的事务中独立运行,所以插入“李四”方法抛出异常只会回滚插入“李四”方法，插入“张三”方法不受影响。

结论：通过这两个方法我们证明了在外围方法未开启事务的情况下Propagation.REQUIRED修饰的内部方法会新开启自己的事务，且开启的事务相互独立，互不干扰。

1.2 外围方法开启事务

验证方法1:

1
@Override
2
@Transactional(propagation = Propagation.REQUIRED)
3
public void transaction_exception_required_required(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addRequired(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addRequired(user2);
11

12
    throw new RuntimeException();
13
}

验证方法2:

1
@Override
2
@Transactional(propagation = Propagation.REQUIRED)
3
public void transaction_required_required_exception(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addRequired(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addRequiredException(user2);
11
}

验证方法3:

1
@Transactional
2
@Override
3
public void transaction_required_required_exception_try(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addRequired(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    try {
11
        user2Service.addRequiredException(user2);
12
    } catch (Exception e) {
13
        System.out.println("方法回滚");
14
    }
15
}

展开收起

结果:

验证方法序号数据库结果结果分析

1“张三”、“李四”均未插入。外围方法开启事务，内部方法加入外围方法事务，外围方法回滚，内部方法也要回滚。 2“张三”、“李四”均未插入。外围方法开启事务，内部方法加入外围方法事务，内部方法抛出异常回滚，外围方法感知异常致使整体事务回滚。 3“张三”、“李四”均未插入。外围方法开启事务，内部方法加入外围方法事务，内部方法抛出异常回滚，即使方法被catch不被外围方法感知，因为使用的是同一个事务,整个事务依然回滚。

结论：以上试验结果我们证明在外围方法开启事务的情况下Propagation.REQUIRED修饰的内部方法会加入到外围方法的事务中，所有Propagation.REQUIRED修饰的内部方法和外围方法均属于同一事务，只要一个方法回滚，整个事务均回滚。

2.PROPAGATION_REQUIRES_NEW

1
@Service
2
public class User1ServiceImpl implements User1Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.REQUIRES_NEW)
6
    public void addRequiresNew(User1 user){
7
        user1Mapper.insert(user);
8
    }
9
}

1
@Service
2
public class User2ServiceImpl implements User2Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.REQUIRES_NEW)
6
    public void addRequiresNew(User2 user){
7
        user2Mapper.insert(user);
8
    }
9

10
    @Override
11
    @Transactional(propagation = Propagation.REQUIRES_NEW)
12
    public void addRequiresNewException(User2 user){
13
        user2Mapper.insert(user);
14
        throw new RuntimeException();
15
    }
16
}

展开收起

2.1 外围方法不开启事务

验证方法1:

1
@Override
2
public void notransaction_exception_requiresNew_requiresNew(){
3
    User1 user1=new User1();
4
    user1.setName("张三");
5
    user1Service.addRequiresNew(user1);
6

7
    User2 user2=new User2();
8
    user2.setName("李四");
9
    user2Service.addRequiresNew(user2);
10

11
    throw new RuntimeException();
12

13
}

验证方法2:

1
@Override
2
public void notransaction_requiresNew_requiresNew_exception(){
3
    User1 user1=new User1();
4
    user1.setName("张三");
5
    user1Service.addRequiresNew(user1);
6

7
    User2 user2=new User2();
8
    user2.setName("李四");
9
    user2Service.addRequiresNewException(user2);
10
}

结果：

验证方法序号数据库结果结果分析

1“张三”插入，“李四”插入。外围方法没有事务，插入“张三”、“李四”方法都在自己的事务中独立运行,外围方法抛出异常回滚不会影响内部方法。 2“张三”插入，“李四”未插入外围方法没有开启事务，插入“张三”方法和插入“李四”方法分别开启自己的事务，插入“李四”方法抛出异常回滚，其他事务不受影响。

结论：通过这两个方法我们证明了在外围方法未开启事务的情况下Propagation.REQUIRES_NEW修饰的内部方法会新开启自己的事务，且开启的事务相互独立，互不干扰。

2.2 外围方法开启事务

验证方法1:

1
@Override
2
@Transactional(propagation = Propagation.REQUIRES_NEW)
3
public void transaction_exception_required_requiresNew_requiresNew(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addRequired(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addRequiresNew(user2);
11

12
    User2 user3=new User2();
13
    user3.setName("王五");
14
    user2Service.addRequiresNew(user3);
15

16
    throw new RuntimeException();
17
}

展开收起

验证方法2:

1
@Override
2
@Transactional(propagation = Propagation.REQUIRES_NEW)
3
public void transaction_required_requiresNew_requiresNew_exception(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addRequired(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addRequiresNew(user2);
11

12
    User2 user3=new User2();
13
    user3.setName("王五");
14
    user2Service.addRequiresNewException(user3);
15
}

展开收起

验证方法3:

1
@Override
2
@Transactional(propagation = Propagation.REQUIRES_NEW)
3
public void transaction_required_requiresNew_requiresNew_exception_try(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addRequired(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addRequiresNew(user2);
11

12
    User2 user3=new User2();
13
    user3.setName("王五");
14
    try {
15
        user2Service.addRequiresNewException(user3);
16
    } catch (Exception e) {
17
        System.out.println("回滚");
18
    }
19
}

展开收起

结果：

验证方法序号数据库结果结果分析

1“张三”未插入，“李四”插入，“王五”插入。外围方法开启事务，插入“张三”方法和外围方法一个事务，插入“李四”方法、插入“王五”方法分别在独立的新建事务中，外围方法抛出异常只回滚和外围方法同一事务的方法，故插入“张三”的方法回滚。 2“张三”未插入，“李四”插入，“王五”未插入。外围方法开启事务，插入“张三”方法和外围方法一个事务，插入“李四”方法、插入“王五”方法分别在独立的新建事务中。插入“王五”方法抛出异常，首先插入 “王五”方法的事务被回滚，异常继续抛出被外围方法感知，外围方法事务亦被回滚，故插入“张三”方法也被回滚。 3“张三”插入，“李四”插入，“王五”未插入。外围方法开启事务，插入“张三”方法和外围方法一个事务，插入“李四”方法、插入“王五”方法分别在独立的新建事务中。插入“王五”方法抛出异常，首先插入“王五”方法的事务被回滚，异常被catch不会被外围方法感知，外围方法事务不回滚，故插入“张三”方法插入成功。

结论：在外围方法开启事务的情况下Propagation.REQUIRES_NEW修饰的内部方法依然会单独开启独立事务，且与外部方法事务也独立，内部方法之间、内部方法和外部方法事务均相互独立，互不干扰。

3.PROPAGATION_NESTED

1
@Service
2
public class User1ServiceImpl implements User1Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.NESTED)
6
    public void addNested(User1 user){
7
        user1Mapper.insert(user);
8
    }
9
}

1
@Service
2
public class User2ServiceImpl implements User2Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.NESTED)
6
    public void addNested(User2 user){
7
        user2Mapper.insert(user);
8
    }
9

10
    @Override
11
    @Transactional(propagation = Propagation.NESTED)
12
    public void addNestedException(User2 user){
13
        user2Mapper.insert(user);
14
        throw new RuntimeException();
15
    }
16
}

展开收起

3.1 外围方法不开启事务

验证方法1:

1
@Override
2
public void notransaction_exception_nested_nested(){
3
    User1 user1=new User1();
4
    user1.setName("张三");
5
    user1Service.addNested(user1);
6

7
    User2 user2=new User2();
8
    user2.setName("李四");
9
    user2Service.addNested(user2);
10

11
    throw new RuntimeException();
12
}

验证方法2:

1
@Override
2
public void notransaction_nested_nested_exception(){
3
    User1 user1=new User1();
4
    user1.setName("张三");
5
    user1Service.addNested(user1);
6

7
    User2 user2=new User2();
8
    user2.setName("李四");
9
    user2Service.addNestedException(user2);
10
}

结果：

验证方法序号数据库结果结果分析

结论：通过这两个方法我们证明了在外围方法未开启事务的情况下Propagation.NESTED和Propagation.REQUIRED作用相同，修饰的内部方法都会新开启自己的事务，且开启的事务相互独立，互不干扰。

3.2 外围方法开启事务

验证方法1:

1
@Transactional(propagation = Propagation.NESTED)
2
@Override
3
public void transaction_exception_nested_nested(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addNested(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addNested(user2);
11

12
    throw new RuntimeException();
13
}

验证方法2:

1
@Transactional(propagation = Propagation.NESTED)
2
@Override
3
public void transaction_nested_nested_exception(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addNested(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addNestedException(user2);
11
}

验证方法3:

1
@Transactional(propagation = Propagation.NESTED)
2
@Override
3
public void transaction_nested_nested_exception_try(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addNested(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    try {
11
        user2Service.addNestedException(user2);
12
    } catch (Exception e) {
13
        System.out.println("方法回滚");
14
    }
15
}

展开收起

结果：

验证方法序号数据库结果结果分析

1“张三”、“李四”均未插入。外围方法开启事务，内部事务为外围事务的子事务，外围方法回滚，内部方法也要回滚。 2“张三”、“李四”均未插入。外围方法开启事务，内部事务为外围事务的子事务，内部方法抛出异常回滚，且外围方法感知异常致使整体事务回滚。 3“张三”插入、“李四”未插入。外围方法开启事务，内部事务为外围事务的子事务，插入“李四”内部方法抛出异常，可以单独对子事务回滚。

结论：以上试验结果我们证明在外围方法开启事务的情况下Propagation.NESTED修饰的内部方法属于外部事务的子事务，外围主事务回滚，子事务一定回滚，而内部子事务可以单独回滚而不影响外围主事务和其他子事务

4.PROPAGATION_MANDATORY

1
@Service
2
public class User1ServiceImpl implements User1Service {
3
  //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.MANDATORY)
6
    public void addMandatory(User1 user) {
7
        user1Mapper.insert(user);
8
    }
9
}

1
@Service
2
public class User2ServiceImpl implements User2Service {
3
  //省略其他...
4
    @Override
5
    public void addMandatory(User2 user) {
6
        user2Mapper.insert(user);
7
    }
8
}

4.1 外围方法不开启事务

验证方法1:

1
  @Override
2
  public void notransaction_mandatory() {
3
      User1 user1 = new User1();
4
      user1.setName("张三");
5
      user1Service.addMandatory(user1);
6

7
      User2 user2 = new User2();
8
      user2.setName("李四");
9
      user2Service.addMandatory(user2);
10
  }

4.2 外围方法开启事务

验证方法2:

1
  @Override
2
  @Transactional
3
  public void transaction_mandatory() {
4
      User1 user1 = new User1();
5
      user1.setName("张三");
6
      user1Service.addMandatory(user1);
7
      User2 user2 = new User2();
8
      user2.setName("李四");
9
      user2Service.addMandatory(user2);
10
  }

结果：

验证方法序号数据库结果结果分析

1“张三”、“李四”均未插入。外围方法没有开启事务,张三设置成MANDATORY,李四未设置,李四报异常.springframework.transaction.IllegalTransactionStateException: No existing transaction found for transaction marked with propagation ‘mandatory’ 不能正常插入,受异常影响,张三也不能插入 2“张三”、“李四”均插入。外围方法开启事务，且传播行为不能是PROPAGATION_MANDATORY ,数据都可以正常插入

结论：外围方法调用开启了PROPAGATION_MANDATORY的方法时,自身必须开启事务,且自身事务的传播行为不能是PROPAGATION_MANDATORY,否则会报异常

5.PROPAGATION_NEVER

1
  @Service
2
  public class User1ServiceImpl implements User1Service {
3
    //省略其他...
4
      @Override
5
      public void addNever(User1 user) {
6
          user1Mapper.insert(user);
7
      }
8
  }

1
  @Service
2
  public class User2ServiceImpl implements User2Service {
3
    //省略其他...
4
      @Override
5
      @Transactional(propagation = Propagation.NEVER)
6
      public void addNever(User2 user) {
7
          user2Mapper.insert(user);
8
      }
9
  }

5.1 外围方法不开启事务

验证方法1:

1
@Override
2
public void notransaction_never() {
3
    User1 user1 = new User1();
4
    user1.setName("张三");
5
    user1Service.addNever(user1);
6

7
    User2 user2 = new User2();
8
    user2.setName("李四");
9
    user2Service.addNever(user2);
10
}

5.2 外围方法开启事务

验证方法2:

1
@Override
2
@Transactional
3
public void transaction_never() {
4
    User1 user1 = new User1();
5
    user1.setName("张三");
6
    user1Service.addNever(user1);
7

8
    User2 user2 = new User2();
9
    user2.setName("李四");
10
    user2Service.addNever(user2);
11
}

结果：

验证方法序号数据库结果结果分析

1“张三”、“李四”均插入。外围方法没有开启事务,数据正常插入 2“张三”、“李四”均未插入。外围方法开启事务，李四的传播行为是NEVER,报异常org.springframework.transaction.IllegalTransactionStateException: Existing transaction found for transaction marked with propagation ‘never’,李四不能插入,受异常影响,张三也不能插入

结论：开启了事务的方法不能调用开启PROPAGATION_NEVER的方法,否则会报异常

6.PROPAGATION_SUPPORTS

1
@Service
2
public class User1ServiceImpl implements User1Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.SUPPORTS)
6
    public void addSupports(User1 user) {
7
        user1Mapper.insert(user);
8
    }
9
}
10

11
@Service
12
public class User2ServiceImpl implements User2Service {
13
    //省略其他...
14
    @Override
15
    @Transactional(propagation = Propagation.SUPPORTS)
16
    public void addSupports(User2 user) {
17
        user2Mapper.insert(user);
18
    }
19

20
    @Override
21
    @Transactional(propagation = Propagation.SUPPORTS)
22
    public void addSupportsException(User2 user) {
23
        user2Mapper.insert(user);
24
        throw new RuntimeException();
25
    }
26

27
}

展开收起

6.1 外围方法不开启事务

验证方法1:

1
@Override
2
public void notransaction_exception_supports_supports() {
3
    User1 user1 = new User1();
4
    user1.setName("张三");
5
    user1Service.addSupports(user1);
6

7
    User2 user2 = new User2();
8
    user2.setName("李四");
9
    user2Service.addSupports(user2);
10

11
    throw new RuntimeException();
12
}

验证方法2:

1
@Override
2
public void notransaction_supports_supports_exception() {
3
    User1 user1 = new User1();
4
    user1.setName("张三");
5
    user1Service.addSupports(user1);
6

7
    User2 user2 = new User2();
8
    user2.setName("李四");
9
    user2Service.addSupportsException(user2);
10
}

结果 :

验证方法序号数据库结果结果分析

1“张三”、“李四”均插入。外围方法未开启事务，则插入“张三”、“李四”方法以无事务方式运行，外围方法异常不影响内部插入 2“张三”、“李四”均插入。外围方法未开启事务，则插入“张三”、“李四”方法以无事务方式运行,内部异常没有事务李四也不会回滚

结论：通过这两个方法我们证明了在外围方法未开启事务的情况下Propagation.SUPPORTS修饰的内部方法会以非事务的方式运行，插入成功后出现异常，数据不会因异常回滚

6.2 外围方法开启事务

验证方法1:

1
@Override
2
@Transactional
3
public void transaction_exception_supports_supports(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addSupports(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addSupports(user2);
11

12
    throw new RuntimeException();
13
}

验证方法2:

1
@Override
2
@Transactional
3
public void transaction_supports_supports_exception(){
4
    User1 user1 = new User1();
5
    user1.setName("张三");
6
    user1Service.addSupports(user1);
7

8
    User2 user2 = new User2();
9
    user2.setName("李四");
10
    user2Service.addSupportsException(user2);
11
}

验证方法3:

1
@Transactional
2
@Override
3
public void transaction_supports_supports_exception_try(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addSupports(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    try {
11
        user2Service.addSupportsException(user2);
12
    } catch (Exception e) {
13
        System.out.println("方法回滚");
14
    }
15
}

展开收起

结果:

验证方法序号数据库结果结果分析

1“张三”、“李四”均未插入。外围方法开启事务，内部方法支持当前事务，外围方法回滚，内部方法也要回滚。 2“张三”、“李四”均未插入。外围方法开启事务，内部方法支持当前事务，内部方法抛出异常回滚，外围方法感知异常致使整体事务回滚。 3“张三”、“李四”均未插入。外围方法开启事务，内部方法加入外围方法事务，内部方法抛出异常回滚，即使方法被catch不被外围方法感知，因为使用的是同一个事务,整个事务依然回滚。

结论：以上试验结果我们证明在外围方法开启事务的情况下Propagation.SUPPORTS修饰的内部方法会加入到外围方法的事务中，所有Propagation.SUPPORTS修饰的内部方法和外围方法均属于同一事务，只要一个方法回滚，整个事务均回滚。

7.PROPAGATION_NOT_SUPPORTED

1
@Service
2
public class User1ServiceImpl implements User1Service {
3
    //省略其他...
4
    @Override
5
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
6
    public void addNotSupported(User1 user) {
7
        user1Mapper.insert(user);
8
    }
9
}
10

11
@Service
12
public class User2ServiceImpl implements User2Service {
13
    //省略其他...
14
    @Override
15
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
16
    public void addNotSupported(User2 user) {
17
        user2Mapper.insert(user);
18
    }
19

20
    @Override
21
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
22
    public void addNotSupportedException(User2 user) {
23
        user2Mapper.insert(user);
24
        throw new RuntimeException();
25
    }
26

27
}

展开收起

7.1 外围方法不开启事务

验证方法1:

1
@Override
2
public void notransaction_exception_notSupported_notSupported() {
3
    User1 user1 = new User1();
4
    user1.setName("张三");
5
    user1Service.addNotSupported(user1);
6

7
    User2 user2 = new User2();
8
    user2.setName("李四");
9
    user2Service.addNotSupported(user2);
10

11
    throw new RuntimeException();
12
}

验证方法2:

1
@Override
2
public void notransaction_supports_supports_exception() {
3
    User1 user1 = new User1();
4
    user1.setName("张三");
5
    user1Service.addSupports(user1);
6

7
    User2 user2 = new User2();
8
    user2.setName("李四");
9
    user2Service.addSupportsException(user2);
10
}

结果 :

验证方法序号数据库结果结果分析

1“张三”、“李四”均插入。外围方法未开启事务，外围方法异常不影响内部插入 2“张三”、“李四”均插入。外围方法未开启事务，内部异常没有事务李四也不会回滚

结论：通过这两个方法我们证明了在外围方法未开启事务的情况下Propagation.NOT_SUPPORTED修饰的内部方法没有事务可挂起也会以没有事务的方式运行，插入成功后出现异常，数据不会因异常回滚

7.2 外围方法开启事务

验证方法1:

1
@Override
2
@Transactional
3
public void transaction_exception_supports_supports(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addSupports(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    user2Service.addSupports(user2);
11

12
    throw new RuntimeException();
13
}

验证方法2:

1
@Override
2
@Transactional
3
public void transaction_supports_supports_exception(){
4
    User1 user1 = new User1();
5
    user1.setName("张三");
6
    user1Service.addSupports(user1);
7

8
    User2 user2 = new User2();
9
    user2.setName("李四");
10
    user2Service.addSupportsException(user2);
11
}

验证方法3:

1
@Transactional
2
@Override
3
public void transaction_supports_supports_exception_try(){
4
    User1 user1=new User1();
5
    user1.setName("张三");
6
    user1Service.addSupports(user1);
7

8
    User2 user2=new User2();
9
    user2.setName("李四");
10
    try {
11
        user2Service.addSupportsException(user2);
12
    } catch (Exception e) {
13
        System.out.println("方法回滚");
14
    }
15
}

展开收起

结果:

验证方法序号数据库结果结果分析

1“张三”、“李四”均插入。外围方法开启事务，内部方法挂起当前事务，外围方法异常不影响内部插入 2“张三”、“李四”均插入。外围方法开启事务，内部方法挂起当前事务，外围方法异常不影响内部插入，内部异常没有事务李四也不会回滚 3“张三”、“李四”均插入。外围方法开启事务，内部方法挂起当前事务，李四没有事务,李四方法抛出异常也不会回滚

结论：以上试验结果我们证明在外围方法开启事务的情况下Propagation.NOT_SUPPORTED修饰的内部方法会挂起外围方法的事务中，所有Propagation.NOT_SUPPORTED修饰的内部方法会以没有事务的方式运行，即使发生了异常也不会回滚。

参考文章

源码地址

Springboot 事务回滚不生效可能出现的原因

Thu, 01 Jul 2021 00:00:00 GMT

1.数据库是否为InnoDB引擎：InnoDB支持事务 MyISAM不支持事务

2.配置文件中是否开启

1
transaction:
2
  rollback-on-commit-failure: true

3.是否在启动类中加入注解（此项可忽略，spring boot 默认开启了事务）

1
1.点进去 @SpringBootApplication
2
2.再点进去 @EnableAutoConfiguration
3
3.可以看到类上的注解 有一个 @Import(AutoConfigurationImportSelector.class) 自动装配的选择器
4
4.进入AutoConfigurationImportSelector类中 可以看到有个getAutoConfigurationEntry()方法
5
   AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(annotationMetadata);
6
5.方法中又调用了 getCandidateConfigurations()方法
7
6.在getCandidateConfigurations()方法中可以很清楚的看到有一个断言
8
    Assert.notEmpty(configurations, "No auto configuration classes found in META-INF/spring.factories. If you "
9
        + "are using a custom packaging, make sure that file is correct.");
10
重点就在于 META-INF/spring.factories 文件
11
7.进入到jar包中找到该文件 大概130行
12
    org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
13
8.进入TransactionAutoConfiguration类中可以看到一下源码 有这个一个注解 @EnableTransactionManagement
14

15
@Configuration(proxyBeanMethods = false)
16
@ConditionalOnBean(TransactionManager.class)
17
@ConditionalOnMissingBean(AbstractTransactionManagementConfiguration.class)
18
public static class EnableTransactionManagementConfiguration {
19
  @Configuration(proxyBeanMethods = false)
20
  @EnableTransactionManagement(proxyTargetClass = false)
21
  @ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false",
22
      matchIfMissing = false)
23
  public static class JdkDynamicAutoProxyConfiguration {
24
  }
25
  @Configuration(proxyBeanMethods = false)
26
  @EnableTransactionManagement(proxyTargetClass = true)
27
  @ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
28
      matchIfMissing = true)
29
  public static class CglibAutoProxyConfiguration {
30
  }
31
}

展开收起

4.@Transactional注解位置：

1
@Transactional注解必须和抛出异常的位置在一起
2

3
在Service中加入的事务注解，手动抛出异常时要在Service中抛出，才能看到效果
4

5
如果Controller中，调用两个不同Service的方法并开启了事务回滚，要想事务生效，则需要在Controller也加入@Transactional注解

5.@Transactional注解默认只能拦截RuntimeException和Error，如果自定义的Exception，需要设置rollbackFor 属性值，如下。也可以让自定义异常继承自RuntimeException。

1
@Transactional(rollbackFor = Exception.class)

6.使用了try，catch捕获并处理了异常

1
事务回滚的原理就是捕获异常然后回滚，这个时候异常被干掉了，事务管理觉察不到了
2
在使用@Transactional标注的方法中不要手动捕获异常，可以直接统一抛出异常，交给全局异常处理器处理

注意：添加@Transactional的方法必须是public

阿里云SLB不能负载到ECS的解决

Thu, 24 Jun 2021 00:00:00 GMT

新加的机器ECS,通过SLB居然负载不上去,网上百度了很多方法,甚至还求助了阿里云内部工作人员,无果.最后想到之前申请的机器都会执行一个脚本,修改一些配置.之后搜索了一些相关文章,发现了其中的问题.

对于添加到负载均衡实例后端的ECS，原则上不需要进行特别的配置。如果针对关联到负载均衡4层（TCP协议）服务的Linux系统的ECS，如果发现无法正常访问，需要确保系统配置文件/etc/sysctl.conf的以下三项为0

Terminal window

1
net.ipv4.conf.default.rp_filter = 0
2
net.ipv4.conf.all.rp_filter = 0
3
net.ipv4.conf.eth0.rp_filter = 0

如果部署在同一内网网段下的ECS之间有通信需求，且发现有无法通信的情况存在，那么需要检查如下参数的配置是否正确

Terminal window

1
net.ipv4.conf.default.arp_announce =2
2
net.ipv4.conf.all.arp_announce =2

更新配置

Terminal window

1
sysctl -p

脚本分享

Terminal window展开收起

1
#######main
2

3
#install tools
4
install_tools()
5
{
6
echo -e "\033[32m \037Begin install tools,please waiting........\033[0m"
7

8
yum install -y setuptool vim wget ntp ftp telnet openssh-clients make dstat ncurses-devel gcc gcc-c++ make libtool lrzsz >/dev/null 2>&1
9

10
if [ $? -eq 0 ];then
11
  echo -e "\033[32m \037The tools install finshed...\033[0m"
12
fi
13
}
14

15
selinux()
16
{
17
#being selinux config
18
SELINUX_STATUS=`cat /etc/selinux/config  |grep '^SELINUX\>' |cut -d "=" -f2`
19
if [[ $SELINUX_STATUS == enforcing || $SELINUX_STATUS == permissive ]];then
20
  sed -i "s/SELINUX=$SELINUX_STATUS/SELINUX=disabled/g" /etc/selinux/config
21
    echo -e "Now selinux status is: \033[1;31m disable\033[0m."
22
else
23
    echo -e "No change.The selinux status is: \033[1;35m disable\033[0m."
24
fi
25
}
26

27
Time()
28
{
29
#time zone
30
TIME_ZONE=`cat /etc/sysconfig/clock |grep '^ZONE' |cut -d "=" -f2`
31
if [ $TIME_ZONE != \"Asia/Shanghai\" ];then
32
cat > /etc/sysconfig/clock <<EOF
33
ZONE="Asia/Shanghai"
34
UTC=false
35
ARC=false
36
EOF
37

38
  TIME_ZONE=`cat /etc/sysconfig/clock |grep '^ZONE' |cut -d "=" -f2`
39
  echo -e "Now Time zone set success ,Zone now is: \"\033[1;31m$TIME_ZONE\033[0m\"."
40
else
41
    echo -e "No change.Time zone is: \"\033[1;35m$TIME_ZONE\033[0m\"."
42
fi
43

44
}
45

46
##time sync
47
time_sync()
48
{
49
time_dns='pool.ntp.org'
50
/usr/sbin/ntpdate  -s $time_dns
51
TIME=`date +%Y-%m-%d_%T`
52
export LANG=C
53
if [ $? -eq 0 ];then
54
  echo -e "Sync time success.Now the time is: \"\033[1;32m$TIME\033[0m\""
55
fi
56
#sync time for bios
57
hwclock --systohc
58

59
}
60

61
ssh_port()
62
{
63
#change ssh login port
64
DE_SH=`cat /etc/ssh/sshd_config |grep 'Port\>' |head -c1`
65
DE_SH_PORT=`cat /etc/ssh/sshd_config |grep 'Port\>'`
66
if [ $DE_SH == \# ];then
67
  sed -i s/"$DE_SH_PORT"/"Port 3322"/ /etc/ssh/sshd_config
68
  SSH_PORT=`cat /etc/ssh/sshd_config |grep 'Port\>' |awk '{print $2}'`
69
  if [ $SSH_PORT == 3322 ];then
70
    echo -e "Now SSH port set success,port is: \"\033[1;31m$SSH_PORT\033[0m.\""
71
  fi
72
else
73
    SSH_PORT=`cat /etc/ssh/sshd_config |grep 'Port\>' |awk '{print $2}'`
74
    if [ $SSH_PORT != 3322 ];then
75
        sed -i s/"Port $SSH_PORT"/"Port 3322"/ /etc/ssh/sshd_config
76
        echo -e "Now SSH port \"\033[1;31m$SSH_PORT\033[0m\" has change \"\033[1;31m63999\033[0m\"."
77
    else
78
      echo -e "No change SSH port is: \"\033[1;35m63999\033[0m\""
79
    fi
80
fi
81
}
82

83
ssh_root()
84
{
85
#delay root login
86
DEF_PER=`cat /etc/ssh/sshd_config |grep 'PermitRootLogin'   |grep -v 'without-password' |head -c 1`
87
DEF_PER_CON=`cat /etc/ssh/sshd_config |grep 'PermitRootLogin'   |grep -v 'without-password'`
88
if [ $DEF_PER == \# ];then
89
  sed -i s/"$DEF_PER_CON"/"PermitRootLogin no"/ /etc/ssh/sshd_config
90
    DEF_PER_CON1=`cat /etc/ssh/sshd_config |grep 'PermitRootLogin'   |grep -v 'without-password'`
91
    echo -e "Now Root login permit set success.Now is: \"\033[1;31m$DEF_PER_CON1\033[0m\" ."
92
else
93
    LOGIN_PER=`cat /etc/ssh/sshd_config |grep 'PermitRootLogin'   |grep -v 'without-password' |cut -d" " -f2`
94
    if [ $LOGIN_PER == yes ];then
95
       sed -i s/"PermitRootLogin yes"/"PermitRootLogin no"/ /etc/ssh/sshd_config
96
       DEF_PER_CON2=`cat /etc/ssh/sshd_config |grep 'PermitRootLogin'   |grep -v 'without-password'`
97
       echo -e "Now The permit is: \"\033[1;31m$DEF_PER_CON2\033[0m\" ."
98
    else
99
       echo -e "No change.The root login permit is: \"\033[1;35m no\033[0m\"."
100
    fi
101
fi
102
}
103

104
ssh_zip()
105
{
106
#open ssh zip
107
DEF_ZIP=`cat /etc/ssh/sshd_config |grep Compression  |head -c 1`
108
ZIP_STAT=`cat /etc/ssh/sshd_config |grep 'Compression'`
109
if [ $DEF_ZIP == \# ];then
110
  sed -i s/"$ZIP_STAT"/"Compression yes"/  /etc/ssh/sshd_config
111
  ZIP_STAT=`cat /etc/ssh/sshd_config |grep 'Compression'`
112
  echo -e "Open zip for scp success.status is: \"\033[1;31m$ZIP_STAT\033[0m.\""
113
else
114
  ZIP_STATUS=`cat /etc/ssh/sshd_config |grep 'Compression' |awk '{print $2}'`
115
  if [ $ZIP_STATUS != yes ];then
116
     sed -i s/"Compression $ZIP_STATUS"/"Compression yes"/  /etc/ssh/sshd_config
117
    echo -e "Scp zip status: \"\033[1;31m$ZIP_STATUS\033[0m\" has change \"\033[1;31myes\033[0m\"."
118
  else
119
    echo -e "No change scp commpression status: \"\033[1;35myes\033[0m\""
120
  fi
121
fi
122
}
123

124
ssh_dns()
125
{
126
#close dns for ssh con
127
DEF_DNS=`cat /etc/ssh/sshd_config |grep 'UseDNS' |head -c 1`
128
DNS_STAT=`cat /etc/ssh/sshd_config |grep 'UseDNS'`
129
if [ $DEF_DNS == \# ];then
130
  sed -i s/"$DNS_STAT"/"UseDNS no"/  /etc/ssh/sshd_config
131
  DNS_STAT=`cat /etc/ssh/sshd_config |grep 'UseDNS'`
132
  echo -e "Close dns for ssh.status is: \"\033[1;31m$DNS_STAT\033[0m.\""
133
else
134
  DNS_STATUS=`cat /etc/ssh/sshd_config |grep 'UseDNS' |awk '{print $2}'`
135
  if [ $ZIP_STATUS != no ];then
136
     sed -i s/"Compression $ZIP_STATUS"/"Compression no"/  /etc/ssh/sshd_config
137
    echo -e "DNS status: \"\033[1;31m$DNS_STATUS\033[0m\" has change \"\033[1;31mno\033[0m\"."
138
  else
139
    echo -e "No change UseDNS status: \"\033[1;35mno\033[0m\""
140
  fi
141
fi
142
}
143

144
ssh_startup()
145
{
146
#max start
147
START_MAX=`cat /etc/ssh/sshd_config |grep MaxStartups |head -c 1`
148
MAX_STAT=`cat /etc/ssh/sshd_config |grep MaxStartups`
149
if [ $DEF_DNS == \# ];then
150
  sed -i s/"$MAX_STAT"/"MaxStartups 5"/  /etc/ssh/sshd_config
151
  MAX_STAT=`cat /etc/ssh/sshd_config |grep MaxStartups`
152
  echo -e "The max startups status is : \"\033[1;31m$MAX_STAT\033[0m.\""
153
fi
154
}
155

156
ssh_emptypasswd()
157
{
158
#refuse empty passwd login
159
DEF_EMPTY=`cat /etc/ssh/sshd_config |grep PermitEmptyPasswords |head -c 1`
160
EMPTY_STAT=`cat /etc/ssh/sshd_config |grep PermitEmptyPasswords`
161
if [ $DEF_EMPTY == \# ];then
162
  sed -i s/"$EMPTY_STAT"/"PermitEmptyPasswords no"/  /etc/ssh/sshd_config
163
  EMPTY_STAT=`cat /etc/ssh/sshd_config |grep PermitEmptyPasswords`
164
  echo -e "PermitEmptyPasswords status is: \"\033[1;31m$EMPTY_STAT\033[0m.\""
165
else
166
  EMPTY_STATUS=`cat /etc/ssh/sshd_config |grep 'PermitEmptyPasswords' |awk '{print $2}'`
167
  if [ $EMPTY_STATUS != no ];then
168
     sed -i s/"PermitEmptyPasswords $EMPTY"/"PermitEmptyPasswords no"/  /etc/ssh/sshd_config
169
    echo -e "PermitEmptyPasswords status: \"\033[1;31m$EMPTY_STATUS\033[0m\" has change \"\033[1;31mno\033[0m\"."
170
  else
171
    echo -e "No change PermitEmptyPasswords status: \"\033[1;35mno\033[0m\""
172
  fi
173
fi
174

175
}
176

177
ssh_restart()
178
{
179
echo -e "\033[1;32m Begin restart sshd process....\033[0m"
180
systemctl restart sshd.service >/dev/null
181
if [ $? -eq 0 ];then
182
  echo -e "\033[1;31m sshd_config set success. \033[0m"
183
fi
184

185
}
186

187
set_user()
188
{
189
#beging set user
190
NAME_COU=`cat /etc/passwd |grep '^test\>' |wc -l`
191
if [ $NAME_COU -eq 1 ];then
192
    echo 'test123' | passwd --stdin "test" > /dev/null
193
    echo -e "No change . The user name \"\033[1;35m test\033[0m \" exist,passwd has set again. please check out."
194
else
195
   useradd test
196
   echo 'test123' | passwd --stdin "test" > /dev/null
197
   echo -e "Now Create username \"\033[1;31m test \033[0m\" && set passwd success."
198
fi
199

200
#set root passwd
201
echo 'testroot' | passwd --stdin "root" > /dev/null
202
echo -e "Now \033[1;31m Root\033[0m passwd set success.."
203

204
}
205

206
profile_hist()
207
{
208
#begin set add time format for history
209
PRO_COUNT=`cat /etc/profile |grep 'HISTTIMEFORMAT' |wc -l`
210
if [ $PRO_COUNT -eq 0 ];then
211
    /bin/sed -i "/^export PATH/a\export HISTTIMEFORMAT" /etc/profile
212
    /bin/sed -i "/^HISTSIZE/a\HISTTIMEFORMAT=\"%Y-%m-%d %H:%M:%S: \"" /etc/profile
213
    export HISTTIMEFORMAT
214
    echo -e "Now The\033[1;31m history timeformat\033[0m set success now."
215
else
216
    echo -e "No change.The\033[1;35m history timeformat\033[0m has setted ."
217
fi
218
}
219

220
profile_other()
221
{
222
echo "TMOUT=1800" >> /etc/profile
223
echo "alias vi='vim'" >>/etc/profile
224
echo "unset MAILCHECK" >> /etc/profile
225
source /etc/profile
226
}
227

228
run_level()
229
{
230
#begin set runlevel
231
RUNLEVEL=`cat /etc/inittab |grep '^id:.:initdefaul' |cut -d":" -f2`
232
if [ $RUNLEVEL != 3 ];then
233
    /bin/sed -i  s/"id:$RUNLEVEL"/"id:3"/ /etc/inittab
234
    NOW_RUNLEVEL=`cat /etc/inittab |grep '^id:.:initdefaul' |cut -d":" -f2`
235
    echo -e "Now the runlevel is \"\033[1;31m$NOW_RUNLEVEL\033[0m\"."
236
else
237
    echo -e "No change .The runlevel is \"\033[1;35m$RUNLEVEL\033[0m\"."
238
fi
239
}
240

241
iptables()
242
{
243
##begin set iptables start levle
244
systemctl disable  firewalld.service > /dev/null
245
echo -e "Now default \033[1;31m iptables\033[0m start runlevel all set off "
246
systemctl stop firewalld.service > /dev/null
247
}
248

249
unnecessary_service()
250
{
251
#begin turn off unnecessary services
252
export LANG=C
253
echo -e "\e[32m begin turn off unnecessary services.....\e[0m"
254
for close_list in `chkconfig --list |awk '($5~/on/ || $7~/on/) {print $1}' | grep -vE "atd|crond|cpuspeed|irqbalance|lvm2-monitor|network|smartd|sshd|syslog|sysstat"`
255
do
256
  echo $close_list
257
  /sbin/chkconfig --level 2345 $close_list off
258
  /sbin/service $close_list stop >/dev/null
259
done
260
echo -e "Now The \033[1;31m unnecessary services \033[0m turn off now."
261
#echo -e "\e[32m----------------End  system initialization ---------------\e[0m"
262
}
263

264
##set sysctl.conf
265

266
sysctl_set()
267
{
268
cat >> /etc/sysctl.conf <<EOF
269
###################################################
270
vm.overcommit_memory = 1
271
###################################################
272
net.netfilter.nf_conntrack_max=1000000
273
###################################################
274
net.core.rmem_default = 126976
275
net.core.wmem_default = 126976
276
net.core.wmem_max = 16777216
277
net.core.rmem_max = 16777216
278
net.ipv4.tcp_mem = 8192 87380 16777216
279
net.ipv4.tcp_wmem = 8192 65536 16777216
280
net.ipv4.tcp_rmem = 8192 87380 16777216
281
###################################################
282
net.core.netdev_max_backlog = 2500
283
net.core.somaxconn = 100000
284
###################################################
285
net.ipv4.tcp_no_metrics_save = 0
286
net.ipv4.tcp_moderate_rcvbuf = 1
287
net.ipv4.tcp_orphan_retries= 1
288
net.ipv4.tcp_fin_timeout = 5
289
net.ipv4.tcp_keepalive_time = 300
290
net.ipv4.tcp_syncookies = 1
291
net.ipv4.tcp_sack = 1
292
net.ipv4.tcp_tw_reuse = 1
293
net.ipv4.tcp_tw_recycle = 1
294
net.ipv4.ip_local_port_range = 10250 65000
295
net.ipv4.tcp_max_syn_backlog = 81920
296
net.ipv4.tcp_max_tw_buckets = 1600000
297
net.ipv4.tcp_synack_retries = 2
298
net.ipv4.tcp_syn_retries = 2
299
net.ipv4.tcp_retries2 = 2
300
net.ipv4.tcp_window_scaling = 1
301
net.ipv4.tcp_timestamps = 1
302
###################################################
303
fs.file-max = 1024000
304
EOF
305

306
sysctl -p >/dev/null 2>1&
307

308
}
309

310
#limit file
311
limit_file()
312
{
313
cat >> /etc/security/limits.conf <<EOF
314
*                hard    nofile         1024000
315
*                soft    nofile         1024000
316
*                hard    nproc          1024000
317
*                soft    nproc          1024000
318
EOF
319
}
320

321
sudu_log()
322
{
323
touch /var/log/sudo.log
324
cat >> /etc/sudoers <<EOF
325
LocoJoyUser    ALL=(ALL)       NOPASSWD: /bin/sh
326
Defaults logfile=/var/log/sudo.log
327
EOF
328

329
cat >> /etc/rsyslog.conf <<EOF
330
local8.debug    /var/log/sudo.log
331
EOF
332
}
333

334
echo -e "\e[32m----------------Begin  system initialization ---------------\e[0m"
335
echo
336
install_tools
337
selinux
338
#Time
339
time_sync
340
ssh_port
341
ssh_root
342
ssh_zip
343
ssh_dns
344
ssh_startup
345
ssh_emptypasswd
346
ssh_restart
347
set_user
348
profile_hist
349
profile_other
350
#run_level
351
iptables
352
#unnecessary_service
353
sysctl_set
354
limit_file
355
sudu_log
356
echo
357
echo -e "\e[32m----------------End  system initialization ---------------\e[0m"

展开收起

Java8 stream 求两个List集合取交集、并集、差集、去重并集

Thu, 24 Jun 2021 00:00:00 GMT

1
import java.util.ArrayList;
2
import java.util.List;
3
import static java.util.stream.Collectors.toList;
4

5
public class Test {
6

7
    public static void main(String[] args) {
8
        List<String> list1 = new ArrayList<String>();
9
        list1.add("1");
10
    list1.add("2");
11
    list1.add("3");
12
    list1.add("5");
13
    list1.add("6");
14

15
        List<String> list2 = new ArrayList<String>();
16
        list2.add("2");
17
    list2.add("3");
18
    list2.add("7");
19
    list2.add("8");
20

21
        // 交集
22
        List<String> intersection = list1.stream().filter(item -> list2.contains(item)).collect(toList());
23
        System.out.println("---交集 intersection---");
24
        intersection.parallelStream().forEach(System.out :: println);
25

26
        // 差集 (list1 - list2)
27
        List<String> reduce1 = list1.stream().filter(item -> !list2.contains(item)).collect(toList());
28
        System.out.println("---差集 reduce1 (list1 - list2)---");
29
        reduce1.parallelStream().forEach(System.out :: println);
30

31
        // 差集 (list2 - list1)
32
        List<String> reduce2 = list2.stream().filter(item -> !list1.contains(item)).collect(toList());
33
        System.out.println("---差集 reduce2 (list2 - list1)---");
34
        reduce2.parallelStream().forEach(System.out :: println);
35

36
        // 并集
37
        List<String> listAll = list1.parallelStream().collect(toList());
38
        List<String> listAll2 = list2.parallelStream().collect(toList());
39
        listAll.addAll(listAll2);
40
        System.out.println("---并集 listAll---");
41
        listAll.parallelStream().forEachOrdered(System.out :: println);
42

43
        // 去重并集
44
        List<String> listAllDistinct = listAll.stream().distinct().collect(toList());
45
        System.out.println("---得到去重并集 listAllDistinct---");
46
        listAllDistinct.parallelStream().forEachOrdered(System.out :: println);
47

48
        System.out.println("---原来的List1---");
49
        list1.parallelStream().forEachOrdered(System.out :: println);
50
        System.out.println("---原来的List2---");
51
        list2.parallelStream().forEachOrdered(System.out :: println);
52

53
    }
54
}

展开收起

原网址:https://juejin.cn/post/6844903833726894093

OpenResty+nginx+lua+redis实现二级缓存

Thu, 24 Jun 2021 00:00:00 GMT

下载OpenResty镜像
Terminal window
```
1
docker pull openresty/openresty
```

运行镜像

Terminal window

1
docker run -d -p 880:80 --name openresty --restart always -v /etc/localtime:/etc/localtime openresty/openresty

进入容器
Terminal window
```
1
docker exec -it openresty /bin/bash
```

安装lua

1
apt-get update -y
2
apt-get install -y gcc
3
apt-get install -y curl
4
apt-get install -y make
5
apt-get install -y vim
6
apt-get install libreadline-dev -y
7
curl -R -O http://www.lua.org/ftp/lua-5.3.5.tar.gz
8
tar -zxf lua-5.3.5.tar.gz
9
cd lua-5.3.5
10
make linux test
11
make install

编写lua脚本并上传到服务器

1
ngx.header.content_type = "application/json;charset=utf8"
2

3
--获取本地缓存
4
local cache_ngx = ngx.shared.dis_cache;
5
-- 获取本地缓存数据
6
local ngCache = cache_ngx:get('lua:application-data')
7
if ngCache == "" or ngCache == nil then
8
    --引入redis库
9
    local cjson = require("cjson")
10
    local redis = require("resty.redis")
11
    local red = redis:new()
12
    red:set_timeout(2000)
13

14
    local ip = "127.0.0.1"
15
    local port = 6379
16
    red:connect(ip, port)
17
    red:auth("123456")
18

19
    local redCache = red:get("lua:application-data")
20
    if redCache == ngx.null or redCache == "" or redCache == nil then
21
        --引入mysql库
22
        local mysql = require("resty.mysql")
23
        local db = mysql:new()
24
        db:set_timeout(3000)
25
        local props = {
26
            host = "127.0.0.1",
27
            port = 3306,
28
            database = "test",
29
            user = "root",
30
            password = "root"
31
        }
32

33
        local res = db:connect(props)
34
        local select_sql = "SELECT xxx from tb_level where xxx"
35
        res = db:query(select_sql)
36
        db:close()
37
        red:set("lua:application-data", cjson.encode(res))
38
        red:close()
39
        --将redis中获取到的数据存入nginx本地缓存10分钟 测试阶段先1分钟
40
        cache_ngx:set('lua-game-milk-tea:level-data', cjson.encode(res), 1 * 60)
41
        ngx.say("{\"code\":0,\"message\":\"sql success\",\"data\":" .. cjson.encode(res) .. "}")
42
    else
43
        --将redis中获取到的数据存入nginx本地缓存10分钟 测试阶段先1分钟
44
        cache_ngx:set('lua:application-data', redCache, 1 * 60)
45
        ngx.say("{\"code\":0,\"message\":\"redis success\",\"data\":" .. redCache .. "}")
46
    end
47
else
48
    ngx.say("{\"code\":0,\"message\":\"nginx success\",\"data\":" .. ngCache .. "}")
49
end

展开收起

特别说明

1
lua读取redis数据返回结果为空时，返回的结果不是nil而是userdata类型的ngx.null

在http节点下开启nginx共享内存

Terminal window

1
vim /usr/local/openresty/nginx/conf/nginx.conf

1
lua_shared_dict dis_cache 10m;

在server节点添加lua配置

1
location /lua {
2
    content_by_lua_file /opt/lua/cache.lua;
3
    add_header Access-Control-Allow-Origin *;
4
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
5
    add_header Access-Control-Allow-Headers '*';
6
}

1624507084958

1624507099317

1624507152639

SpringBoot配置文件中数据库密码加密

Thu, 24 Jun 2021 00:00:00 GMT

jasypt 加解密 (亲测)#

引入maven依赖

1
<!--数据库账号密码加密-->
2
<dependency>
3
    <groupId>com.github.ulisesbocchio</groupId>
4
    <artifactId>jasypt-spring-boot-starter</artifactId>
5
    <version>3.0.3</version>
6
</dependency>

配置文件设置盐

1
jasypt:
2
  encryptor:
3
    password: salt(混淆的盐 不是数据库密码)

添加测试用例

1
@Autowired
2
StringEncryptor encryptor;
3

4
@Test
5
public void jacketEncrypt() {
6
    //加密
7
    String username = encryptor.encrypt("root");
8
    String password = encryptor.encrypt("root");
9
    System.out.println("name 密文: " + username);
10
    System.out.println("password 密文: " + password);
11

12
    //解密
13
    String decryptUsername = encryptor.decrypt(username);
14
    String decryptPassword = encryptor.decrypt(password);
15
    System.out.println(decryptUsername + ":" + decryptPassword);
16
}

展开收起

执行结果

1
username 密文: 4JemeydjoOcwvCq2o2bDbzwcHxQr/sH+oO+7A6+r7cEnyNDTPbyRrMrZIVqDekmU
2
password 密文: xxdvFS4od9nOskblLD7nyfjt5WEQ2V/8kMHxPfX8LrzMP4h0s6K9Z6XTlYtdwCHv
3
root:root

修改配置文件

1
spring:
2
  datasource:
3
    url: jdbc:xxxx
4
    username: ENC(4JemeydjoOcwvCq2o2bDbzwcHxQr/sH+oO+7A6+r7cEnyNDTPbyRrMrZIVqDekmU)
5
    password: ENC(xxdvFS4od9nOskblLD7nyfjt5WEQ2V/8kMHxPfX8LrzMP4h0s6K9Z6XTlYtdwCHv)

启动类添加注解开启加解密功能
```
1
@EnableEncryptableProperties
```

SpringBoot配置文件中数据库密码加密

Thu, 24 Jun 2021 00:00:00 GMT

jasypt 加解密 (亲测)#

引入maven依赖

1
<!-- swagger2增强，官方ui太low ， 访问地址： /doc.html  -->
2
<!-- 只想换个皮就用1.9.6版本 2.0以上是增强版本  -->
3
<dependency>
4
    <groupId>com.github.xiaoymin</groupId>
5
    <artifactId>knife4j-spring-boot-starter</artifactId>
6
    <!-- <version>1.9.6</version>-->
7
    <version>3.0.2</version>
8
</dependency>

配置文件设置盐

1
jasypt:
2
  encryptor:
3
    password: salt

添加测试用例

1
@Autowired
2
private StringEncryptor encryptor;
3

4
@Test
5
void getPass() {
6
    String url = encryptor.encrypt("root");
7
    String username = encryptor.encrypt("root");
8
    String password = encryptor.encrypt("root");
9
    System.out.println("url:" + url);
10
    System.out.println("username:" + username);
11
    System.out.println("password:" + password);
12
}

执行结果

1
url:ilrFIJcIWHMzDvah77RlYAtmMmhMAPRLygVKHLg807gl6e4ZP7IO7B68hlXdr8Ir
2
username:GaQi3DPmmV6wGzvD+rlZY+lXt+ZBDo49vu44wyaDttPdwDZKvfO74rQvWIwbiP3A
3
password:3wvbr1LmdsZb79dpwSzgufgzFkh8XyYDNo1stEr8UHYsegKIJlpYgIxZ/5uO5KML

修改配置文件

1
spring:
2
  datasource:
3
    url: ENC(ilrFIJcIWHMzDvah77RlYAtmMmhMAPRLygVKHLg807gl6e4ZP7IO7B68hlXdr8Ir)
4
    username: ENC(GaQi3DPmmV6wGzvD+rlZY+lXt+ZBDo49vu44wyaDttPdwDZKvfO74rQvWIwbiP3A)
5
    password: ENC(3wvbr1LmdsZb79dpwSzgufgzFkh8XyYDNo1stEr8UHYsegKIJlpYgIxZ/5uO5KML)

spring-plugin异常的解决办法

Sat, 20 Feb 2021 00:00:00 GMT

在学习ES的过程中，本着有最新就用最新的想法，使用了springboot2.3.x的版本，在实操过程中遇到了配置和方法过时的情况，于是将springboot版本降级为2.1.13，诡异的事情发生了，原本能正常启动的项目起不来了，报错如下：

1
*************************** APPLICATION FAILED TO START
2
*************************** Description: An attempt was made to call a method
3
that does not exist. The attempt was made from the following location:
4
springfox.documentation.schema.plugins.SchemaPluginsManager.viewProvider(SchemaPluginsManager.java:95)
5
The following method did not exist:
6
org.springframework.plugin.core.PluginRegistry.getPluginFor(Ljava/lang/Object;)Ljava/util/Optional;
7
The method's class, org.springframework.plugin.core.PluginRegistry, is available
8
from the following locations:
9
jar:file:/D:/repository/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar!/org/springframework/plugin/core/PluginRegistry.class
10
It was loaded from the following location:
11
file:/D:/repository/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
12
Action: Correct the classpath of your application so that it contains a single,
13
compatible version of org.springframework.plugin.core.PluginRegistry

百度了一下问题，遇到了类似问题的帖子，就试了试

一开始使用了1.2.0的版本，但是问题依旧存在，又把帖子往下划拉了划拉，试了试2.0.0版本的，嘿，还真好使了

问题原因：版本冲突

1
<dependency>
2
    <groupId>org.springframework.plugin</groupId>
3
    <artifactId>spring-plugin-core</artifactId>
4
    <version>2.0.0.RELEASE</version>
5
</dependency>
6
<dependency>
7
    <groupId>org.springframework.plugin</groupId>
8
    <artifactId>spring-plugin-metadata</artifactId>
9
    <version>2.0.0.RELEASE</version>
10
</dependency>

参考：https://ask.csdn.net/questions/754747

Linux安装Java环境

Sun, 17 Jan 2021 00:00:00 GMT

Linux安装Java环境

1、下载

https://www.oracle.com/java/technologies/javase/javase-jdk8-downloads.html

2、上传

新建目录

Terminal window

1
mkdir /usr/local/jdk
2
cd /usr/local/jdk

安装上传软件

Terminal window

1
yum install -y lrzsz

拖拽上传jdk文件

解压

Terminal window

1
tar -xvf jdk-8u161-linux-x64.tar.gz

配置环境变量

Terminal window

1
vim /etc/profile

Terminal window

1
# 在文件末尾添加下面的配置 注意：JAVA_HOME的路径是你实际解压后的JDK的路径，千万别写错了
2
export JAVA_HOME=/usr/local/jdk/jdk1.8.0_161
3
export PATH=$JAVA_HOME/bin:$PATH
4
export CLASSPATH=.:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
5
export PATH=$PATH:$JAVA_HOME/bin

生效环境变量

Terminal window

1
source /etc/profile

验证安装

Terminal window

1
java
2
javac
3
java -version

MySQL高级系列-数据库锁

Tue, 05 Jan 2021 00:00:00 GMT

1.锁的分类#

按对数据的操作类型分
- 读锁（共享锁）
  
  针对同一份数据，多个读操作可以同时进行而不会相互影响
- 写锁（排它锁）
  
  当前写操作没有完成前，它会阻断其它写锁或读锁
按对数据的操作粒度分
- 表锁
- 行锁

2.表锁#

特点

偏向MyISAM存储引擎，开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高。并发度偏低。

建表

1
-- 注意引擎是MyISAM
2
CREATE TABLE `mylock` (
3
  `id` int(11) NOT NULL AUTO_INCREMENT,
4
  `name` varchar(20) DEFAULT NULL,
5
  PRIMARY KEY (`id`)
6
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
7

8
insert into mylock values
9
(null,'a1'),
10
(null,'a2'),
11
(null,'a3'),
12
(null,'a4'),
13
(null,'a5'),
14
(null,'a6');

查看表上加过的锁
```
1
show open tables;
```

手动增加表锁

1
-- 可以一次锁定多个表
2
lock table 表名1 read/write,表名2 read/write,...;

1609745668728

手动解锁
```
1
unlock tables;
```
1609745757808
开启两个会话：session1、session2
- session1给mylock表加读锁，session1只可读mylock，session2可读mylock，也可读其它未锁定的表
  
  1609746106011
- session1给mylock表加读锁，session1不可修改
  
  1609746472750
- session1给mylock表加读锁，session1不可以再去读其它表
  
  1609746600294
- session1给mylock表加读锁，session2执行更新操作会锁等待，session1释放锁后，session2才会执行
  
  1609746835749
  
  1609746877526
- 给session1解锁
```
1
unlock tables;
```
- session1给mylock表加写锁，session1可读，可写，不写操作其它表
  
  1609747902152
- session1给mylock表加写锁，sseeion2读写mylock都要等待，session2可读写其它表。
  
  1609748138024
- session1释放写锁，session2才可读mylock
  
  1609750010503
结论

MyISAM在执行查询语句之前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。MySQL的表级锁有两种模式：
- 表共享读锁（Table Read Lock）
- 表独占写锁（Table Write Lock）
锁类型可否兼容读锁写锁
读锁是是否
写锁是否否

结合上表，对MyISAM表进行操作，会有以下情况
1. 对MyISAM表进行读操作（加读锁），不会阻塞其它进程对同一表的读请求，但会阻塞对同一表的写请求，只有当读锁释放后，才能执行其它进程的写操作。
2. 对MyISAM表的写操作（加写锁），会阻塞其它进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。
简而言之，就是读锁会阻塞写，但是不会阻塞读。写锁读和写都会阻塞。
表锁分析
- 查看哪些表被锁（上面有提到）
```
1
show open tables;
```
- 如何分析表锁定
  
  可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定
```
1
show status like 'table%';
```
  1609751134481
  
  这里有两个状态变量记录MySQL内部表级锁定的情况：
  
  Table_locks_immediate：产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1
  
  Table_locks_waited：出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次锁值加1），此值高则说明存在较严重的表级锁争用情况。
  
  此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎。因为写锁后，其它线程不能进行任何操作，大量的更新会使得查询很难得到锁，从而造成永远阻塞。

锁类型	可否兼容	读锁	写锁
读锁	是	是	否
写锁	是	否	否

3.行锁#

特点

偏向InnoDB引擎，开销大，加锁慢，会出现死锁，锁的粒度小，发生锁冲突的概率最低，并发度也最高。

InnoDB与MyISAM最大的不同有两点：
1. InnoDB支持事务
2. InnoDB采用了行级锁
事务

事务是由一组SQL语句组成的逻辑处理单元，具有以下4个属性，简称事务的ACID属性：
1. 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改要么全都执行，要么全都不执行。
2. 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性，事务结束时，所有的内存数据结构（如B树索引或双向链表）也都必须是正确的。
3. 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的独立执行环节。这意味着事务处理过程的中间状态对外部是不可见的，反之亦然。
4. 持久性（Durable）：事务完成后，它对数据的修改时永久性的，即使出现系统故障也能够保持。
并发事务带来的问题：
- 丢失更新（Lost Update）
  
  当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其它事务的存在，就会发生丢失更新的问题，最后的更新覆盖了由其它事务所做的更新。
- 脏读（Dirty Reads）
  
  一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态，这时，另一个事务，这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些脏数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做脏读。
  
  换句话说就是，事务A读到了事务B已修改但尚未提交的数据，还在这个数据上进行了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性的要求。
- 不可重复读（Non-Repeatable Reads）
  
  一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现读出的数据已经发生了改变、或某些记录已经被删除了。这种现象就叫做不可重复读；
  
  换句话说就是，事务A读到了事务B已经提交的修改数据，不符合隔离性。
- 幻读（Phantom Reads）
  
  一个事务按相同的条件重新读取以前检索过的数据，却发现其它事务插入了满足其查询条件的新数据，这种现象被叫做幻读；
  
  换句话说就是，事务A读到了事务B提交的新增数据，不符合隔离性。
幻读和脏读有点类似，但也不同：脏读是事务B里面修改了数据，幻读是事务B里面新增了数据。
事务的隔离级别

脏读、不可重复读、幻读，其实都是数据读一致性问题，必须由数据库提供一定的事务隔离机制来解决。

隔离级别丢失更新脏读不可重复读幻读
Read uncommitted × √ √ √
Read committed × × √ √
Repeatable read(默认) × × × √
Serializable × × × ×

查看当前数据的事务隔离级别：
```
1
show variables like 'tx_isolation';
```
1609810639608

隔离级别	丢失更新	脏读	不可重复读	幻读
Read uncommitted	×	√	√	√
Read committed	×	×	√	√
Repeatable read(默认)	×	×	×	√
Serializable	×	×	×	×

建表

1
CREATE TABLE `test_innodb_lock` (
2
  `a` int(11) DEFAULT NULL,
3
  `b` varchar(16) DEFAULT NULL
4
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
5

6
insert into test_innodb_lock values(1,'b2');
7
insert into test_innodb_lock values(3,'3');
8
insert into test_innodb_lock values(4,'4000');
9
insert into test_innodb_lock values(5,'5000');
10
insert into test_innodb_lock values(6,'6000');
11
insert into test_innodb_lock values(7,'7000');
12
insert into test_innodb_lock values(8,'8000');
13
insert into test_innodb_lock values(9,'9000');
14
insert into test_innodb_lock values(1,'b1');
15

16
create index idx_innodb_a on test_innodb_lock(a);
17
create index idx_innodb_b on test_innodb_lock(b);

展开收起

演示—开启session1，session2
- 全部关闭数据库自动提交
```
1
set autocommit = 0;
```
- session1更新但不提交，session2读到的还是原来的数据
  
  1609813474705
- session1提交更新
  
  1609813552489
- session1先更新但不提交，session2更新同一条数据会阻塞
  
  1609813737890
- session1提交，session2才能执行更新操作，session2更新要生效需要commit
  
  1609813820832
  
  1609813894787
- session1、session2不更新同一条数据，不会发生阻塞
  
  1609814038543
- session1、session2提交之后
  
  1609814092178
索引失效—行锁变表锁

1609815234498

1609815267088
数据还原

1609815375879
间隙锁

1609815624504

1609815664130

当我们用范围条件而不是相等条件检索数据，并请求共享或排它锁时，InnoDB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范围内但并不存在的记录叫做间隙（GAP）。InnoDB也会对这个间隙加锁，这种锁机制就是间隙锁（Next-Key锁）；

危害：

因为Query执行过程中通过范围查找的话，它会锁定整个范围内所有的键值，即使这个键值不存在。

间隙锁有一个比较致命的弱点，就是当锁定一个范围键值后，即使某些不存在的键值也会被无辜锁定，而造成在锁定的时候无法插入键值范围内的任何数据，在某些场景下可能会对性能造成很大的危害。
如何锁定一行

select xxx for update锁定某一行后，其它的操作会被阻塞，知道锁定行的会话执行commit操作。

1609816892763

结论

InnoDB存储引擎实现了行级锁定，虽然在锁机制的实现方面带来的性能损耗可能比表级锁要高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定。当系统并发量较高的时候，InnoDB的整体性能和MyISAM相比就会有明显的优势了。但是，当我们使用不当的时候，也可能会让InnoDB的整体性能表现不及MyISAM高，甚至可能会更差。

如何分析表锁定

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

1
show status like 'innodb_row_lock%';

1609818301081

字段	含义
Innodb_row_lock_current_waits	当前正在等待锁定的数量
Innodb_row_lock_time	从系统启动到现在锁定总时长
Innodb_row_lock_time_avg	没每次等待所花平均时间
Innodb_row_lock_time_max	从系统启动到现在等待最长的一次所花的时间
Innodb_row_lock_waits	吃从系统启动到现在总共等待次数

当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为何会出现如此多的等待，然后分析结果着手制定优化计划。

优化建议
- 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
- 合理设计索引，尽量缩小锁的范围
- 尽可能减少检索条件，避免间隙锁
- 尽量控制事务大小，减少锁定资源和时间长度
- 尽可能低级别事务隔离

4.页锁（了解）#

开销和加锁时间界于表锁和行锁之间，会出现死锁，锁定粒度界于表锁和行锁之间，并发度一般。

Xshell连接虚拟机特别慢的解决方案

Tue, 05 Jan 2021 00:00:00 GMT

习惯了云服务器Xshell几乎秒连，最近遇到Xshell连接虚拟机贼慢，可以说是龟速…，于是乎，百度查了一下，还真有同样问题的，遂按照网上说的动手操作，还别说，居然解决了：

修改配置 /etc/ssh/sshd_config

Terminal window

1
yum install -y vim
2
vim /etc/ssh/sshd_config
3

4
#配置文件中有这样一行配置
5
#UseDNS yes
6

7
# 解开注释 将yes改为no
8

9
UseDNS no

重启ssh服务
Terminal window
```
1
systemctl restart sshd
```

参考连接

MySQL高级系列-查询分析

Mon, 04 Jan 2021 00:00:00 GMT

1.查询优化#

永远小表驱动大表（类似嵌套循环）

优化原则：小表驱动大表，即小的数据集驱动大的数据集
```
1
select * from A where id in(select id from B)
2
-- 等价于
3
for select id from B
4
for select * from A where A.id = B.id
```
当B表的数据集小于A表的数据集时，用in优于exists
```
1
select * from A where exists (select 1 from B where B.id = A.id)
2
-- 等价于
3
for select * from A
4
for select * from B where B.id = A.id
```
当A表的数据集小于B表的数据集时，用exists优于in

注意：A表与B表的id字段应建立索引
- EXISTS
```
1
select ... from table where exists(subquery)
2
-- 该语法可以理解为：将主查询的数据，放到子查询中做条件验证，根据验证结果（TRUE或FALSE）来决定主查询的数据结果是否得以保留。
```
- 提示
  1. exists(subquery)只返回TRUE或FALSE，因此子查询中的select *也可以是select 1或其它。官方的说法是实际执行时会忽略select清单，因此没有区别
  2. exists子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比，如果担忧效率问题，可进行实际检验以确定是否有效率问题。
  3. exists子查询往往也可以用条件表达式、其它子查询或者join来替代，何种最优要具体问题具体分析。

2.order by 优化#

order by子句，尽量使用index方式排序，避免使用filesort方式排序
```
1
CREATE TABLE `tblA` (
2
  `age` int(11) DEFAULT NULL,
3
  `birth` timestamp NULL DEFAULT NULL
4
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
5

6
INSERT INTO tblA(age,birth) VALUES(22,NOW());
7
INSERT INTO tblA(age,birth) VALUES(23,NOW());
8
INSERT INTO tblA(age,birth) VALUES(24,NOW());
9

10
create index idx_age_birth on tblA(age,birth);
```
image-20210102204958813

image-20210102205439401

MySQL支出两种方式的排序：filesort和index，index效率高，它指MySQL扫描索引本身完成排序。filesort效率低。

order by满足两种情况，会使用index方式排序：
1. order by语句使用索引最左前列
2. 使用where子句与order by子句条件组合满足索引最左前缀
所以，要尽可能在索引列上完成排序操作，遵照最左前缀原则。

如果不在索引列上，filesort有两种算法：
- 双路排序
  
  MySQL4.1之前是使用双路排序，字面意思就是两次扫描磁盘，最终得到数据。读取行指针和orderby列，对它们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出。从磁盘读取排序字段，在buffer进行排序，再从磁盘读取其它字段。
  
  取一批数据，要对磁盘进行两次扫描，I/O是很耗时的，所以在MySQL4.1之后，出现可第二种改进的算法，就是单路排序。
- 单路排序
  
  从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行行输出，避免了第二次读取数据，它的效率更快一些。并且把随机IO变成了顺序IO，但是他会使用更多的空间，因为它把每一行都保存在了内存中。
由于单路是后出的，总体而言好过双路，但是单路也存在一定的问题：

在sort_buffer中，单路排序比多路排序要多占用很多空间，因为单路排序是把所有字段都取出，所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能读取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再去取sort_buffer容量大小的数据，再排序…，从而多次IO。
优化策略
- 增大sort_buffer_size参数的设置值
- 增大max_length_for_sort_data参数的设置
优化策略解释
- order by时，select * 是大忌，只query需要的字段，这点非常重要，在这里影响的是：
  1. 当query的字段大小总和小于max_length_for_sort_data而且排序字段不是TEXT|BLOG类型时，会用单路排序算法，否则会使用多路排序算法。
  2. 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次IO，但是用单路排序的风险会更大一些，所以要提高sort_buffe的参数配置。
- 尝试提高sort_buffer_size
  
  不管使用哪种算法，提高这个参数都会提高效率，当然要根据系统的能力去提高，因为这个参数是针对每个进程的
- 尝试提高max_length_for_sort_data
  
  提高这个参数，会增加使用单路排序算法的概率。但是如果设置的太大，数据的总容量超出sort_buffer_size的概率就会增大，明显症状就是高的磁盘IO活动和低的处理器使用率。

总结

MySQL两种排序方式：文件排序、索引排序
MySQL能为排序和查询使用相同的索引

Index idx_a_b_c(a,b,c)

order by能使用索引最左前缀

1
order by a
2
order by a,b
3
order by a,b,c
4
order by a DESC,b DESC,c DESC

如果where使用索引的最左前缀定义为常量，则order by能使用索引

1
where a = const order by b,c
2
where a = const and b = const order by c
3
where a = const and b > const order by b,c

不能使用索引进行排序

1
order by a ASC,b DESC,c DESC  -- 排序升降不一致
2
where g = const order by b,c  -- 丢失a索引
3
where a = const order by c    -- 丢失b索引
4
where a = const order by a,d  -- d不是索引的一部分
5
where a in(...) order by b,c  -- 对于排序来说，多个相等条件也是范围查询

3.group by优化#

group实质是先排序后进行分组，遵照索引建的最佳左前缀

当无法使用索引列时，增大max_length_for_sort_data参数的设置+增大sort_buffer_zize参数的设置

where高于having，能写在where限定的条件就不要去having限定。

4.慢查询日志#

MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阈值的语句，具体指运行时间超过long_query_time值的SQL，会被记录在慢查询日志中。long_query_time的默认值为10，单位是秒，默认不开启。由它来查看哪些SQL是慢SQL，结合explain进行全面分析。

查看是否开启

1
show variables like '%slow_query_log%';

image-20210103151820625

开启
```
1
-- 只对当前数据库生效 MySQL重启后失效
2
set global slow_query_log = 1;
```
image-20210103152051680

如果要永久生效，需要修改MySQL配置文件，在[mysqld]下增加或修改参数，注意文件名称的主机名是你自己的。
```
1
slow_query_log = 1
2
slow_query_log_file = /var/lib/mysql/tianch-slow.log
```
开启慢查询日志后，什么样的SQL会被记录到慢查询日志中

这个是由参数long_query_time控制，默认long_query_time的值是10秒。可以使用命令修改，也可在配置文件中修改。注意，只有大于long_query_time的SQL才会被记录下来，而非大于等于。
```
1
show variables like '%long_query_time%';
```
image-20210103152706758
设置慢查询日志时间
```
1
set global long_query_time = 3;
```
image-20210103154847814
- 为什么设置后没变化呢？
  
  需要重新开启一个会话才能看到修改的值
  
  image-20210103155009767
慢查询日志记录

使用sleep模拟慢查询
```
1
select sleep(4);
```
image-20210103155409999
查看慢查询日志
Terminal window
```
1
cd /var/lib/mysql/
2
cat tianch-slow.log
```
image-20210103155524039
查询当前系统中有多少条慢查询日志
```
1
show global status like '%Slow_queries%';
```
image-20210103155810350

MySQL慢查询日志永久生效的配置（会有性能损耗）

[mysqld]下配置

1
slow_query_log = 1
2
slow_query_log_file = /var/lib/mysql/tianch-slow.log
3
long_query_time = 3
4
log_output=FILE

慢查询日志分析工具-mysqldumpslow
- mysqldumpslow —help
  
  s<表示按照何种方式进行排序>
  
  c<访问次数>
  
  l<锁定时间>
  
  r<返回记录>
  
  t<查询时间>
  
  al<平均锁定时间>
  
  ar<平均返回记录数>
  
  t<返回前面多少条的数据>
  
  g<后面搭正则匹配模式>，大小写不敏感
- 得到返回记录集最多的10个SQL
  Terminal window
```
1
mysqldumpslow -s r -t 10 /var/lib/mysql/tianch-slow.log
```
- 道道访问次数最多的10个SQL
  Terminal window
```
1
mysqldumpslow -s c -t 10 /var/lib/mysql/tianch-slow.log
```
- 得到按照时间排序的前10条里面含有左连接的查询语句
  Terminal window
```
1
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/tianch-slow.log
```
- 建议在使用这些命令时结合|more使用，否则可能出现爆屏情况
  Terminal window
```
1
mysqldumpslow -s r -t 10 /var/lib/mysql/tianch-slow.log |more
```

批量插入数据

建表

1
use bigdata;
2

3
CREATE TABLE `dept` (
4
  `id` int(11) NOT NULL AUTO_INCREMENT,
5
  `deptno` mediumint(8) unsigned DEFAULT '0',
6
  `dname` varchar(20) DEFAULT NULL,
7
  `loc` varchar(13) DEFAULT NULL,
8
  PRIMARY KEY (`id`)
9
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
10

11
CREATE TABLE `emp` (
12
`id` int(11) NOT NULL AUTO_INCREMENT,
13
  `empno` mediumint(8) unsigned DEFAULT '0' COMMENT '编号',
14
  `ename` varchar(20) DEFAULT NULL COMMENT '名字',
15
  `job` varchar(9) DEFAULT NULL COMMENT '工作',
16
  `mgr` mediumint(8) unsigned DEFAULT '0' COMMENT '上级编号',
17
  `hiredate` date DEFAULT NULL COMMENT '入职时间',
18
  `sal` decimal(7,2) DEFAULT NULL COMMENT '薪水',
19
  `comm` decimal(7,2) DEFAULT NULL COMMENT '红利',
20
  `deptno` mediumint(8) unsigned DEFAULT '0' COMMENT '部门编号',
21
  PRIMARY KEY (`id`)
22
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

展开收起

设置参数log_bin_trust_function_creators

创建参数时，如果报错：This function has none of DETERMINISTIC…

由于开启过慢查询日志，并且我们开启了bin_log，我们就必须为我们的function指定一个参数
```
1
-- 查看
2
show variables like 'log_bin_trust_function_creators%';
3
-- 开启
4
set global log_bin_trust_function_creators = 1;
```
image-20210103194847774

这样设置，MySQL重启之后，设置会失效，永久设置需要修改配置文件：

[mysqld]下添加log_bin_trust_function_creators = 1

创建函数，保证每条数据都不同

delimiter :将换行符修改为:将换行符修改为:将换行符修改为

随机产生字符串

1
delimiter $$
2
create function random_string(n int) returns VARCHAR(255)
3
begin
4
 DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
5
 DECLARE return_str varchar(255) DEFAULT '';
6
 DECLARE i int DEFAULT 0;
7
 WHILE i<n DO
8
    set return_str = CONCAT(return_str,substring(chars_str,FLOOR(1+RAND()*52),1));
9
    set i=i+1;
10
 END WHILE;
11
 RETURN return_str;
12
end $$

随机产生部门编号

1
    delimiter $$
2
    create function random_dept_no() returns int(10)
3
    begin
4
     DECLARE i int DEFAULT 0;
5
     set i = FLOOR(100+RAND()*10);
6
     RETURN i;
7
    end $$
8
    ```

创建存储过程

创建往emp表中插入数据的存储过程

1
  delimiter $$
2
  create procedure insert_emp(in start int, in max_num int)
3
  begin
4
   DECLARE i int DEFAULT 0;
5
   set autocommit=0;
6
   REPEAT
7
      set i=i+1;
8
      insert into emp values (null,(start+i),random_string(6),'SALESMAN',0001,CURDATE(),2000,400,random_dept_no());
9
    UNTIL i = max_num
10
   END REPEAT;
11
   COMMIT;
12
  end $$

创建往dept表中插入数据的存储过程

1
  delimiter $$
2
  create procedure insert_dept(in start int,in int_max int)
3
  begin
4
  DECLARE i int default 0;
5
  set autocommit =0;
6
  REPEAT
7
      set i = i+1;
8
      insert into dept values(null,(start+i),random_string(10),random_string(8));
9
  UNTIL i=int_max END REPEAT;
10
  commit;
11
  end $$

调用存储过程

将换行符改为分号
```
1
  delimiter ;
```
调用dept存储过程
```
1
  call insert_dept(100,10);
```

调用emp存储过程

1
  -- 往emp表添加1000w条数据
2
  call insert_emp(100001,10000000);

5.profile#

是MySQL提供的可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL调优的测量。默认设置是关闭，并保存最近15次的运行结果。

查看当前版本是否支持

1
show variables like 'profiling'; -- 默认关闭

1609724119282

开启
```
1
set profiling=on;
```
1609724190472
执行一些SQL

1609731595870

诊断SQL

1
show profiles;

字段	含义
Status	SQL语句的执行状态
Duration	SQL执行过程中每一步的耗时
CPU_user	当前用户占有的cpu
CPU_system	系统占有的cpu

字段	含义
all	显示所有的开销信息
cpu	显示用户CPU时间、系统CPU时间开销信息
block io	显示块IO相关开销
context switches	显示上下文切换开销，不管是主动还是被动
page faults	显示页错误的相关开销
ipc	显示发送和接收的开销信息
source	显示和Source_function、Source_file、Source_line相关的开销信息
memory	显示内存相关的开销信息
swaps	显示SWAP的次数

诊断具体项的性能开销如COU、IO

1
show profile cpu,block io for query Query_ID

日常开发需要注意的结论
- converting HEAP to MyISAM：查询结果太大，内存都不够用了，往磁盘上搬。
- Creating tmp table<创建临时表>
  - 拷贝数据到临时表
  - 用完后删除
- Copying to tmp table on disk：把内存中的临时表复制到磁盘，极其危险！
- locked：锁

6.全局查询日志-永远不要再生产环境开启这个功能#

开启

通过配置

1
-- kaiq
2
general_log = 1
3
-- 日志路径
4
general_log_file = /path/logfile
5
-- 输出格式
6
log_output = FILE

通过命令

1
set global general_log = 1;
2
set global log_output = 'TABLE';

开启后，你所编写的SQL语句，将会记录到MySQL库里的general_log表，可以用下面的命令查看：

1
select * from mysql.general_log;

MySQL高级系列-索引

Sat, 02 Jan 2021 00:00:00 GMT

1.什么是索引#

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构（有序）。所以，就可以得到索引的本质：索引是有序的数据结构。

索引的目的在于提高查找效率，可类比字典。

2.索引的优势劣势#

优势
1. 类似大学图书馆建数目索引。提高数据检索效率，降低数据库的IO成本。
2. 通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。
劣势
1. 实际上索引也是一张表，该表保存了主键与索引字段，并执行实体表的记录，所以索引列也是要占用空间的。
2. 虽然索引大大提高了查询速度，同时却降低了更新表的速度。如对表进行INSERT UPDATE DELETE。因为更新表时，MySQL不仅要保存数据，还要保存索引文件每次更新添加了索引列的字段，都会调整因为更新带来的键值变化后的索引信息。
3. 索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花大量时间研究建立最优秀的索引或者优化查询。索引是在不断的分析、建立（建了删删了建 …）逐步优化出来的，索引的建立不是一朝一夕的，它需要根据业务场景等诸多因素。

3.索引的分类#

主键索引

设置为主键的列会自动创建索引，InnoDB为聚簇索引。
单值索引

一个索引只包含单个列，一个表可以有多个单列索引。
唯一索引

索引列的值必须唯一，但允许有NULL值（注意是NULL值不能是空字符串）
复合索引

一个索引可以包含多个列

4.索引的创建删除查看#

创建

1
-- tableName()中可以是一个列也可以是多个列 []表示可选
2
CREATE [UNIQUE] INDEX indexName ON tableName(columnname(length));
3
ALTER tableName ADD [UNIQUE] INDEX [indexName](columnname(length));

4种索引创建的alter命令

1
-- 给表添加一个主键,这意味着索引值必须是唯一的,且不能为null
2
alter table 表名 add primary key (主键字段);
3

4
-- 创建索引的值必须是唯一的(除了null外,null可能会出现多次修改)
5
alter table 表名 add unique 表名(表字段);
6

7
-- 添加普通索引 索引值可出现多次
8
alter table 表名 add index 表名(字段);
9

10
-- 全文索引
11
alter table 表名 add fulltext 表名(字段);

删除
```
1
drop index indexName on tableName;
```

查看

1
-- \G 将结果按列打印 每个字段单独一行
2
show index from 表名\G;

5.MySQL的索引结构#

BTree索引

img
- 初始化介绍
一颗B+树，浅蓝色的块，我们称之为一个磁盘块，可以看成每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。

真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。

非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
- 查找过程
  
  如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中使用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相对于磁盘IO来说）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计3次IO。
真实情况是，3层的B+树可以表示上百万的数据，如果上百万的数据查找只需要3次IO，性能提升将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常高。
Hash索引
full-text全文索引
R-Tree索引

6.哪些情况需要建立索引#

主键自动建立唯一索引
频繁作为查询条件的字段应该建立索引
查询中与其它表关联的字段，外键关系建立索引。
单值/复合索引的选择问题（在高并发下倾向于建立复合索引）
查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度。
查询中统计或者分组的字段

7.哪些情况不要创建索引#

表记录太少
频繁更新的字段不适合创建索引（简单的说就是每次更新不仅仅要更新数据记录，还需要更新索引）
where条件里用不到的字段不创建索引
过滤性不好的字段不适合创建索引
数据重复且分布平均的字段不适合创建索引。

注意: 如果某个数据列包含许多重复的内容,为它建立索引就没有太大的实际效果

假如一个表中有10万行数据,有一个字段A只有 T和 F 两种值,且每个值的分布概率大约为 50%,那么对这种表A字段建立索引一般不会提高数据库的查询速度。

索引的选择性是指索引列中不同值的数目与表中记录数的比。如果一个表中2000条记录,表索引列有1980个不同的值,那么这个索引的选择性就是 1980/2000 =0.99，一个索引的选择越接近1，这个索引的效率就越高。

8.索引优化#

单表优化

建表

1
CREATE TABLE `article` (
2
  `id` int(10) NOT NULL AUTO_INCREMENT,
3
  `author_id` int(10) DEFAULT NULL,
4
  `category_id` int(10) DEFAULT NULL,
5
  `views` int(10) DEFAULT NULL,
6
  `comments` int(10) DEFAULT NULL,
7
  `title` varchar(255) DEFAULT NULL,
8
  `content` text NOT NULL,
9
  PRIMARY KEY (`id`)
10
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
11

12
INSERT INTO `tianch`.`article`(`id`, `author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES (1, 1, 1, 1, 1, '1', '1');
13
INSERT INTO `tianch`.`article`(`id`, `author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES (2, 2, 2, 2, 2, '2', '2');
14
INSERT INTO `tianch`.`article`(`id`, `author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES (3, 1, 1, 3, 3, '3', '3');

查看执行计划

1
-- 查询category_id为1且comments大于1的情况下 views最多的id
2
SELECT id,author_id FROM `article` WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;

1609400071535

很显然，type是ALl，即最坏的情况。Extra里还出现了Using filesort，也是最坏的情况，优化是必须的。

开始第一次优化
- 建立索引
```
1
create index idx_article_ccv on article(category_id,comments,views);
```
- 再次查看执行计划
  
  1609401329445
  
  全表扫描的问题解决了，但是文件排序的问题没有解决，因为范围查询后面的索引失效了。
- 结论
  
  type变成了range是可以接受的，但是Extra里使用了Using filesort是无法接受的。
  
  但是我们已经建立了索引，为什么没有效果呢？
  
  这是因为按照B+树索引的工作原理：
  
  先排序category_id
  
  如果遇到相同的category_id，再排序comments
  
  如果遇到相同的comments，再排序views。
  
  当comments字段再联合索引中处于中间位置是
  
  因为comments>1条件是一个范围值
  
  MySQL无法利用索引再对后面的views部分进行检索，也就是说range类型查询字段后面的索引无效。
开始第二次优化
- 删除原来的索引
```
1
drop index idx_article_ccv on article;
```
- 建立新的索引
```
1
create index idx_article_cv on article(category_id,views);
```
- 查看执行计划
  
  1609402052773
- 结论
  
  type变成了ref，Extra中的Using filesort也消失了，索引优化有效。

两表优化

建表

1
CREATE TABLE `class` (
2
  `id` int(10) NOT NULL AUTO_INCREMENT,
3
  `card` int(10) NOT NULL,
4
  PRIMARY KEY (`id`)
5
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
6

7
CREATE TABLE `book` (
8
  `bookid` int(10) NOT NULL AUTO_INCREMENT,
9
  `card` int(10) NOT NULL,
10
  PRIMARY KEY (`bookid`)
11
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
12
-- 各表创建20条
13
INSERT INTO class(card) VALUES(FLOOR(1 +(RAND() * 20)));
14
INSERT INTO book(card) VALUES(FLOOR(1 +(RAND() * 20)));

查看执行计划

1
select * from class left join book on class.card = book.card;

1609403144783

type有ALL

给book(右表)表添加索引
```
1
create index idx_book on book(card);
```
1609403338525

删除book表索引给class表添加索引

1
drop index idx_book on book;
2
create index idx_class on class(card);

再次查看执行计划

1609403699268
结论

左连接查询时，在给book表添加索引之后，type变成了ref，rows也变了，优化比较明显。在给class添加索引之后，只有type变成了index。

这是由左连接的特性决定的。left join 条件用于确定如何从右表搜索行，左边一定都有，所以右表是关键，一定要建立索引。

同理，右连接时，左表一定要建立索引。

三表优化
- 建表删除之前两表创建的索引
```
1
CREATE TABLE `phone` (
2
  `phoneid` int(10) NOT NULL AUTO_INCREMENT,
3
  `card` int(10) NOT NULL,
4
  PRIMARY KEY (`phoneid`)
5
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
6

7
-- 创建20条
8
INSERT INTO phone(card) VALUES(FLOOR(1 +(RAND() * 20)));
```
- 查看执行计划
```
1
select * from class left join book on class.card = book.card left join phone on book.card = phone.card;
```
  1609404781815
- 根据两表的结论给两个右表(book，phone)添加索引
```
1
create index idx_book on book(card);
2
create index idx_phone on phone(card);
```
- 再次查看执行计划
  
  1609404922740
- 结论
  
  尽可能减少join语句中嵌套循环的循环总次数：永远用小的结果集驱动大的结果集；
  
  优先优化嵌套循环的内层循环；
  
  保证join语句中被驱动表上join条件字段已经被索引；
  
  当无法保证被驱动表的join条件字段被索引且内存资源充足的前提下，增大JoinBuffer的值。

9.索引失效（应该避免）#

建表

1
CREATE TABLE `staffs` (
2
  `id` int(11) NOT NULL AUTO_INCREMENT,
3
  `name` varchar(24) NOT NULL,
4
  `age` int(10) NOT NULL DEFAULT '0',
5
  `pos` varchar(20) NOT NULL,
6
  `add_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
7
  PRIMARY KEY (`id`)
8
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
9

10
INSERT INTO staffs(NAME,age,pos,add_time)VALUES('z3',22,'manager',NOW());
11
INSERT INTO staffs(NAME,age,pos,add_time)VALUES('July' ,23,'dev',NOW());
12
INSERT INTO staffs(NAME,age,pos,add_time)VALUES('2000',23,'dev',NOW());

MySQL高级系列-性能分析

Thu, 31 Dec 2020 00:00:00 GMT

1.MySQL Query Optimizer#

MySQL中有专门负责优化SELECT语句的优化器模块，主要功能：通过计算分析系统中搜集到的统计信息，为客户端请求的Query提供它认为最优执行计划（它认为最优的数据检索方式，但不见得是DBA认为是最优的）。

当客户端向MySQL请求一条Query，命令解析器完成请求分类，区分出是SELECT并转发给MySQL Query Optimizer，MySQL Query Optimizer首先会对整条Query进行优化，处理掉一些常见表达式的预算，直接换算成常量值，并对Query中的查询条件进行简化和转换，如去掉一些无用或显而易见的条件、结果调整等。然后分析Query中的Hint信息（如果有），看显示Hint信息是否可以完全确定该Query的执行计划，如果没有Hint或Hint信息还不足以完全确定执行计划，则会读取所涉及对象的统计信息，根据Query进行相应的计算分析，然后再得出最后的执行计划。

2.MySQL常见瓶颈#

CPU
IO<磁盘i>/O瓶颈发生在装入数据远大于内存容量的时候
服务器硬件的性能瓶颈

3.EXPLAIN-查看执行计划#

使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的查询语句或是表结构的性能瓶颈。

1609379301128

id 表的读取顺序

select查询的顺序号，包含一组数字，表示查询中执行select子句或操作表的顺序，有以下3中情况：
1. id相同执行顺序由上至下
  
  1609379656843
2. id不同如果是子查询，id的序号会递增，id值越大，优先级越高，越先被执行
  
  1609379861574
3. id相同又不同
  
  1609381208805
  
  id如果相同，可以认为是一组，从上往下顺序执行。在所有组中，id值越大，优先级越高，越先执行
select_type 数据读取操作的操作类型
1. SIMPLE 简单的select查询，查询中不包含子查询或union
2. PRIMARY 查询中若包含任何复杂的子部分，最外层查询则被标记为PRIMARY
3. SUBQUERY 在select或where列表中包含了子查询
4. DERIVED 在from列表中包含的子查询被标记为DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表里
5. UNION 若第二个select出现在union之后，则被标记为union，若union包含在from子句的子查询中，外层select将被标记为DERIVED。
6. UNION RESULT 从UNION表获取结果的select
table 表示这一行的数据是哪张表的
type 访问类型

从最好到最差依次是：system>const>eq_ref>ref>range>index>ALL
- system 表只有一行记录（等于系统表），是const类型的特例，平时不会出现，可以忽略不计
- const 表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量。
- eq_ref 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描
- ref 非唯一索引扫描，返回匹配某个单独值的所有行，本质上也是一中索引访问。
- range 只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪些索引。一般就是在你的where语句中出现了between 、<、>、in等的查询。这种范围扫描，索引扫描比全表扫描要好，因为它只需要开始于索引的某一个点，而结束于另一个点，不用扫描全部索引。
- index Full Index Scan，index与ALL的区别在于index类型只遍历索引树，这通常比ALL快，因为索引文件通常比数据文件小。也就是说ALL和index都是读全表，但index是从索引中读取的，而ALL是从硬盘中读的。
- ALL Full Table Scan 将遍历全表找到匹配的行。
- possible_keys 显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则索引将会被列出，但不一定被实际使用。
- key 实际使用的索引，如果为NULL，则没用使用索引。查询中若使用了覆盖索引，则该索引仅出现在key列表中。
  
  1609396321797
- key_len 表示索引中使用字节数，可通过该列计算查询中使用的索引的长度，在不损失精确性的前提下，长度越短越好。key_len显示的值是索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。
- ref 显示索引的哪一列被使用了，如果可能的话，最好是一个常数。哪些列或常量被用于查找索引列上的值。
  
  1609396472580
- rows 根据表统计信息及索引选用情况，大致估算出找到所需记录时需要读取的行数。
- Extra 包含不适合在其它列显示但十分重要的额外信息
  - Using filesort 说明MySQL会对数据使用一个外部的索引排序，而不是按照表内的索引进行读取。MySQL中无法利用索引完成的排序操作称为文件排序。
    
    1609396715492
  - Using temporary 使用了临时表保存中间结果，MySQL在对查询结果排序时使用了临时表。常见于排序order by和分组查询group by。
    
    1609397609062
    
    1609397705806
  - Using index 表示响应的select操作使用了覆盖索引，避免访问了表的数据行。如果同时出现了 Using where，表明索引被用来执行索引键值的查找。如果没有同时出现Using where，表明索引来读取数据而非执行查找动作。
    
    1609397845979
  - Using where 表明使用了where过滤
    
    1609397989156
  - Using join buffer 使用了连接缓存
  - Impossible where where子句的值总是false，不能用来获取元组
    
    1609398028340

MySQL高级系列-7种join理论

Wed, 30 Dec 2020 00:00:00 GMT

1. SQL JOINS#

img

2. 创建表#

1
-- 部门表
2
CREATE TABLE `tbl_dept` (
3
  `id` int(11) NOT NULL AUTO_INCREMENT,
4
  `deptName` varchar(30) DEFAULT NULL,
5
  `locAdd` varchar(40) DEFAULT NULL,
6
  PRIMARY KEY (`id`)
7
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
8

9
-- 员工表
10
CREATE TABLE `tbl_emp` (
11
  `id` int(11) NOT NULL AUTO_INCREMENT,
12
  `name` varchar(20) DEFAULT NULL,
13
  `deptId` int(11) DEFAULT NULL,
14
  PRIMARY KEY (`id`),
15
  KEY `deptId` (`deptId`)
16
  # CONSTRAINT `tbl_emp_ibfk_1` FOREIGN KEY (`deptId`) REFERENCES `tbl_dept` (`id`)
17
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
18

19
INSERT INTO tbl_dept(deptName,locAdd) VALUES('RD',11);
20
INSERT INTO tbl_dept(deptName,locAdd) VALUES('HR',12);
21
INSERT INTO tbl_dept(deptName,locAdd) VALUES('MK',13);
22
INSERT INTO tbl_dept(deptName,locAdd) VALUES('MIS',14);
23
INSERT INTO tbl_dept(deptName,locAdd) VALUES('FD',15);
24

25
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (1, 'z3', 1);
26
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (2, 'z4', 1);
27
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (3, 'z5', 1);
28
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (4, 'w5', 2);
29
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (5, 'w6', 2);
30
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (6, 's7', 3);
31
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (7, 's8', 4);
32
INSERT INTO `tbl_emp`(`id`, `name`, `deptId`) VALUES (8, 's9', 51);

展开收起

3.join查询#

内连接（图中间查询两张表的公有部分）

1609314437480
左连接（图左上查询员工表的全部部门表没有补NULL）

1609314590154
右连接（图右上查询部门表的全部员工表没有补NULL）

1609314880228
左外连接（图左中查询员工表独有的数据）

1609315308259
右外连接（图右中查询部门表独有的数据）

1609315456130
全连接（图下中 MySQL不支持 FULL OUTER JOIN 需要曲线救国）

1609315912507

1609316048196

MySQL高级系列-SQL性能下降的原因及执行顺序

Wed, 30 Dec 2020 00:00:00 GMT

1.SQL性能下降的原因#

根本原因
- 执行时间长
- 等待时间长
主要原因
- SQL写的烂
- 索引失效
- 关联查询太多join
- 服务器调优及各个参数设置（缓冲、线程数等）

2.SQL的执行顺序#

手写

1
select distinct 查询字段
2
from 表名1
3
[left]/[right]/[inner] join 表名2
4
on 表1.字段=表2.字段
5
where 查询条件
6
group by 分组字段
7
having 分组后判断条件
8
order by 排序字段 [asc|desc]
9
limit 分页字段

机读

1
1.执行 from 表名1
2
2.执行 on 关联条件得到它们的交集
3
3.执行 [left|right|inner] join 表名2
4
4.执行 where 判断条件
5
5.执行 group by 进行分组
6
6.执行 having 对结果再次进行筛选
7
7.执行 select
8
8.执行 order by 进行排序
9
9.执行 limit

总结

1609310274000

1
1.from 笛卡尔集
2
2.on 主表保留
3
3.join 不符合on也添加
4
4.where 非聚合,非select 别名
5
5.grouip by 改变对表的引用
6
6.having 只作用分组后
7
7.select distrinct
8
8.order by 可使用select 别名
9
9.limit rows offiset

田小晖的博客

FRP v0.68.0 内网穿透完整教程

Nginx 反代模式 | 域名 aaa.example.com | Linux服务器 + Windows内网80端口#

一、整体架构说明#

二、下载 FRP#

下载地址#

下载包选择#

三、Linux 公网服务器端配置#

步骤 1：上传并解压 FRP#

步骤 2：编写 frps.toml 配置文件#

步骤 3：防火墙端口放行#

CentOS / RHEL (firewalld)#

Ubuntu / Debian (ufw)#

使用 iptables#

步骤 4：前台启动测试（必须先做！）#

步骤 5：配置 systemd 服务（后台运行 + 开机自启）#

步骤 6：配置 Nginx 反向代理（核心步骤）#

步骤 7：验证并重载 Nginx#

步骤 8：配置 DNS 域名解析#

四、Windows 内网客户端配置#

步骤 1：解压并准备目录#

步骤 2：编写 frpc.toml 客户端配置文件#

步骤 3：确认本地 80 端口服务正常#

步骤 4：前台启动 frpc 测试（必须先做！）#

步骤 5：外网访问验证测试#

步骤 6：配置 Windows 系统服务（开机自启 + 后台运行）#

6.1 下载 NSSM#

6.2 安装系统服务#

6.3 启动并验证服务#

6.4 NSSM 常用命令速查#

五、完整验证流程图#

六、常用运维命令速查表#

6.1 Linux 服务器端#

6.2 Windows 客户端#

七、常见问题排查 FAQ#

Q1. 访问 http://aaa.example.com 返回 404 Not Found#

Q2. 返回 502 Bad Gateway#

Q3. 返回 504 Gateway Timeout#

Q4. frpc 日志显示 connection timed out 连不上 frps#

Q5. frps Dashboard 打不开（IP<7500> 拒绝连接）#

Q6. 图片加载慢 / 大文件上传失败 / 视频卡顿#

Q7. 修改了 frpc.toml 后配置没生效#

Q8. 使用 Cloudflare CDN 后穿透异常（521 / 522 错误）#

Q9. frpc 每隔一段时间就断开重连（连接不稳定）#

八、进阶：启用 HTTPS（Let’s Encrypt 免费证书）#

方式 A：Certbot 自动申请 + 自动配置 Nginx（推荐 Debain/Ubuntu）#

方式 B：Certbot 独立模式 / CentOS#

方式 C：其他面板（宝塔/1Panel/AppNode）#

九、配置文件模板汇总#

📄 frps.toml 最简生产版#

📄 frpc.toml 最简生产版#

📄 frps.service systemd 单元#

📄 Nginx 反代配置（HTTP + Dashboard）#

十、安全加固建议（生产必做）#

Apollo生产环境分布式部署

一、准备工作#

1.1 运行时环境#

1.1.1 OS#

1.1.2 Java#

1.2 MySQL#

1.3 Docker部署#

二、部署步骤#

2.1 创建数据库#

2.1.1 创建ApolloPortalDB#

2.1.1.1 手动导入SQL创建#

2.1.1.3 验证#

2.1.2 创建ApolloConfigDB#

2.1.2.1 手动导入SQL#

2.1.2.3 验证#

2.1.3 调整服务端配置#

2.1.3.1 调整ApolloPortalDB配置#

1.apollo.portal.envs - 可支持的环境列表#

3.superAdmin - Portal超级管理员#

4.consumer.token.salt - consumer token salt#

5.wiki.address#

6.admin.createPrivateNamespace.switch#

7. emergencyPublish.supported.envs#

8. configView.memberOnly.envs#

9. role.create-application.enabled - 是否开启创建项目权限控制#

10. role.manage-app-master.enabled - 是否开启项目管理员分配权限控制#

Q1. 访问 `http://aaa.example.com` 返回 404 Not Found#

Q4. frpc 日志显示 `connection timed out` 连不上 frps#