Chemmy's Blog

chengming0916@outlook.com

发表于 更新于

1. K3s指定集群管理IP

在k3s.service中添加启动参数

1
--advertise-address=<192.168.x.x>

详细参考官方文档以及 基于K3s搭建GitOps环境1-K3s安装

查看当前Context

1
kubectl config current-context

2. 配置集群信息

查看context列表

1
kubectl config get-contexts

输出中带有*的Context表示当前活动的Context

切换到指定Context

1
2
3
4
5
kubectl config use-context <context_name>

# 示例：切换到dev-ctx
kubectl config use-context dev-ctx

在指定Context中执行命令，一般用于临时使用

1
2
3
4
kubectl  --context=<context_name> <exec_cmd>

# 示例：在dev-ctx下执行get pods
kubectl --context=dev-ctx get pods

3. 合并配置文件

在 Kubernetes 环境中，使用 kubectl 管理多个集群非常常见。通过配置 kubeconfig 文件，可以轻松切换和管理多个集群。以下是实现方法的详细步骤。

方法 1: 合并多个配置文件

  • 准备配置文件 假设已有两个集群的配置文件：_/.kube/config1_ 和 _/.kube/config2_。

  • 合并配置文件 使用以下命令将多个配置文件合并为一个：

KUBECONFIG=/.kube/config1:/.kube/config2 kubectl config view –merge –flatten > ~/.kube/config

  • 验证合并结果 查看合并后的配置：

kubectl config view

方法 2: 配置环境变量

  • 设置环境变量 将多个配置文件路径添加到 KUBECONFIG 环境变量中：

export KUBECONFIG=/.kube/config:/.kube/test-config

  • 验证配置 执行以下命令查看所有集群信息：

kubectl config get-contexts

方法 3: 手动编辑配置文件

  • 打开配置文件 编辑 ~/.kube/config 文件，将其他集群的 cluster_、_context 和 user 信息粘贴到现有配置中。

  • 格式示例：

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

apiVersion: v1

clusters:

- cluster:

server: https://127.0.0.1:6443

name: cluster1

- cluster:

server: https://192.168.0.1:6443

name: cluster2

contexts:

- context:

cluster: cluster1

user: user1

name: context1

- context:

cluster: cluster2

user: user2

name: context2

current-context: context1

切换集群上下文

  • 查看当前上下文：

    1
    kubectl config current-context

  • 切换到其他上下文：

    1
    2

    kubectl config use-context <context_name>

    最佳实践

  • 使用合并或环境变量的方法更高效，避免手动编辑出错。

  • 定期备份 kubeconfig 文件，防止误操作导致数据丢失。

  • 确保每个集群的访问凭证和权限正确无误。

通过以上方法，您可以轻松管理多个 Kubernetes 集群，提高运维效率。

大家好！在 云原生 的世界里，和 Kubernetes 打交道是家常便饭。如果我们像我一样，需要同时管理多个 Kubernetes 集群——比如一个用于严谨发布的 生产环境 ，一个用于大胆实验的 测试环境 ，甚至还有本地开发环境——那么高效、安全地在它们之间切换就成了必备技能。

很多朋友（包括我自己有时也会！）可能会因为一段时间没用而忘记 kubectl 中那些用于切换配置的命令。别担心，这很正常！今天，我们就来系统地回顾一下 kubectl 配置管理的核心概念—— 上下文（Context） ，以及如何利用它在不同集群间自如切换。

核心概念：kubeconfig 文件与上下文（Context）

kubectl 的所有配置信息都存储在一个或多个 YAML 文件中，默认情况下是 $HOME/.kube/config 。这个文件我们通常称为 kubeconfig 文件。把它想象成我们的 Kubernetes “护照”，里面记录了我们能访问哪些集群，用什么身份访问。

一个 kubeconfig 文件通常包含三个主要部分：

  1. Clusters（集群） ：定义了我们要连接的 Kubernetes 集群的信息，比如 API Server 的地址和集群的 CA 证书。
  2. Users（用户） ：定义了访问集群所使用的凭证，可能是用户名/密码、Token 或客户端证书。
  3. Contexts（上下文） ：这是连接 集群 和 用户 的桥梁。一个 Context 定义了使用哪个 User 凭证去访问哪个 Cluster。

关键点： 我们可以通过切换 Context 来改变 kubectl 当前操作的目标集群和使用的身份。

管理 kubeconfig 的常用 kubectl config 命令

kubectl 提供了一套 config 子命令来帮助我们查看和管理 kubeconfig 文件。以下是几个最核心、最常用的命令：

1. 查看当前配置：kubectl config view

这个命令会显示我们当前的 kubeconfig 文件内容（或者合并后的内容，如果我们配置了多个文件）。它会隐藏敏感信息（如证书和 Token 的具体内容），非常适合快速检查配置概览。

1
2
kubectl config view
bash1

如果我们想看某个特定 Context 的详细信息，可以加上 --context 参数：

1
2
3
# 查看名为 'prod-cluster' 的 context 细节
kubectl config view --context=prod-cluster
bash12
2. 列出所有可用的上下文：kubectl config get-contexts

这是 最常用 的命令之一，它会列出我们在 kubeconfig 文件中定义的所有 Context。当前正在使用的 Context 会在名称前用星号 * 标记。

1
2
3
4
5
6
7
kubectl config get-contexts
# 输出示例：
# CURRENT   NAME                 CLUSTER              AUTHINFO             NAMESPACE
# * test-cluster         kubernetes-test      user-test
#           prod-cluster         kubernetes-prod      user-prod            production
#           docker-desktop       docker-desktop       docker-desktop
bash123456

从上面的输出可以清晰地看到：

  • 当前激活的 Context 是 test-cluster 。
  • 还有名为 prod-cluster 和 docker-desktop 的 Context 可供切换。
3. 查看当前使用的上下文：kubectl config current-context

如果我们只想快速确认当前 kubectl 命令会作用于哪个 Context（哪个集群），这个命令最直接：

1
2
3
4
kubectl config current-context
# 输出示例：
# test-cluster
bash123
4. 切换上下文：kubectl config use-context <context-name>

这绝对是 核心中的核心 ！当我们需要将 kubectl 的操作目标从一个集群切换到另一个集群时，就使用这个命令。

假设我们想从当前的 test-cluster 切换到 prod-cluster ：

1
2
3
4
kubectl config use-context prod-cluster
# 输出示例：
# Switched to context "prod-cluster".
bash123

切换成功后，我们可以再次使用 kubectl config current-context 或 kubectl config get-contexts 来验证当前上下文是否已更改。

1
2
3
4
5
6
7
8
9
10
11
kubectl config current-context
# 输出示例：
# prod-cluster

kubectl config get-contexts
# 输出示例：
# CURRENT   NAME                 CLUSTER              AUTHINFO             NAMESPACE
#           test-cluster         kubernetes-test      user-test
# * prod-cluster         kubernetes-prod      user-prod            production
#           docker-desktop       docker-desktop       docker-desktop
bash12345678910

现在，所有后续的 kubectl 命令（如 kubectl get pods, kubectl apply -f ... 等）都会默认发送到 prod-cluster 所定义的集群，并使用 user-prod 的身份进行认证。

实践场景：在生产和测试集群间切换

假设我们的 kubeconfig 文件中已经配置好了代表生产环境和 测试环境 的 Context，可能分别命名为 production 和 testing 。

我们的日常操作流程可能是这样的：

  1. 检查当前在哪： 
    1
    2
    kubectl config current-context
    bash1
    或者看列表： 
    1
    2
    kubectl config get-contexts
    bash1
  2. 需要操作测试环境： 
    1
    2
    3
    4
    5
    6
    kubectl config use-context testing
    # 验证一下（可选但推荐）
    kubectl config current-context
    # 现在可以对测试环境执行操作了
    kubectl get pods -n test-namespace
    bash12345
  3. 需要紧急处理生产环境问题： 
    1
    2
    3
    4
    5
    6
    kubectl config use-context production
    # 验证一下
    kubectl config current-context
    # 操作生产环境（请务必小心！）
    kubectl get deployment -n critical-app
    bash12345
  4. 完成生产环境操作，切回测试环境继续工作： 
    1
    2
    kubectl config use-context testing
    bash1

提升效率的小贴士

  1. 清晰命名 Context ：给我们的 Context 起一个能清晰表明环境和用途的名字，比如 gke-prod-eu, eks-dev-us, local-minikube 等。避免使用模糊不清的名字。
  2. 使用 Shell 别名 ：很多人喜欢为 kubectl 设置别名，比如 alias k=kubectl 。这样我们的命令可以更短： k config get-contexts, k config use-context my-context 。
  3. 考虑使用辅助工具 ：社区有一些流行的小工具可以让我们更方便地切换 Context 和 Namespace，例如：
    • kubectx (用于切换 Context)
    • kubens (用于切换 Namespace)
      这些工具通常提供交互式选择或更简洁的命令，可以显著提高效率。可以通过包管理器（如 Homebrew, apt, yum）或直接下载二进制文件来安装它们。
  4. 注意 kubeconfig 文件的安全性 ： kubeconfig 文件包含了访问集群的凭证，务必妥善保管，不要泄露给未授权的人员。

总结

管理多个 Kubernetes 集群配置并不复杂，核心就在于理解和运用 kubeconfig 文件中的 Context 概念。通过掌握 kubectl config 的几个关键子命令：

  • view: 查看配置概览
  • get-contexts: 列出所有可用上下文
  • current-context: 显示当前激活的上下文
  • use-context <context-name>: 切换到指定的上下文

我们就能轻松地在不同的 Kubernetes 环境（如生产和测试）之间安全、高效地切换了。希望这篇回顾能帮我们重新找回操作 kubectl 多集群配置的熟悉感！

发表于 更新于

概述

本文详细介绍如何在qBittorrent中通过安装插件和集成Jackett实现更强大的BT资源搜索功能。Jackett是一个支持BT/磁力资源聚合搜索的神器，聚合了400多个Public Trackers、Semi-Private Trackers、Private Trackers，可以称得上市面上最为全面的磁力资源聚合器。

一、qBittorrent原生搜索插件配置

1.1 环境准备

qBittorrent的插件是通过Python实现的，因此需要先安装Python3环境。如果使用linuxserver/qbittorrent镜像，系统已经集成了Python3，无需额外安装。

1.2 安装搜索插件

  1. 进入qBittorrent主界面 → 搜索 → 搜索插件 → 安装新插件
  2. 访问qBittorrent插件官网，选择喜爱的磁力搜索引擎
  3. 拷贝对应插件后面的插件下载链接地址，填入插件链接，点击OK即可添加

1.3 插件资源

如果因网络问题无法访问官网，可以使用以下插件包：

插件包类型 插件数量 下载地址
官方版 10个插件 下载链接
非官方版 51个插件 下载链接

替代安装方法：直接将插件脚本放入qBittorrent安装目录下的nova3/engines文件夹中，重启qb服务即可。

1.4 代理配置

由于很多搜索引擎被墙，建议在qBittorrent中配置代理：

  • 菜单 → 工具 → 选项 → 连接 → 代理服务
  • 或使用系统全局代理

二、Jackett一站式资源搜索服务

2.1 Jackett简介

Jackett是一个跨平台的资源聚合搜索工具，支持Windows、macOS、Linux系统。它聚合了400多个Tracker，是目前最全面的磁力资源聚合器。

2.2 Docker部署Jackett

docker-compose配置脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
version: "2.1"
networks:
  dllcnx:
    external: true
services:
  jackett:
    image: lscr.io/linuxserver/jackett:latest
    container_name: jackett
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - AUTO_UPDATE=true #optional
    volumes:
      - /docker/jackett/config:/config   #配置路径
      - /docker/jackett/downloads:/downloads   #下载路径
    ports:
      - 9117:9117
    restart: unless-stopped

启动与访问

  1. 启动容器：docker-compose up -d
  2. 访问地址：http://IP:9117

2.3 Jackett基础配置

主要设置参数：

  • Admin password：如果安装Jackett的机器有公网地址，请设置管理员密码
  • Proxy type、Proxy URL、Proxy port：在此处设置代理服务器信息，则qBittorrent中无需再设置

2.4 添加磁力搜索引擎

引擎类型说明：

  • Public：公开Tracker，无需账号
  • Semi-Private：半私有Tracker
  • Private：私有Tracker，需要邀请码或注册

添加步骤：

  1. 点击”Add indexer”添加磁力搜索引擎
  2. 配置参数：
    • categories：资源类型
    • type：引擎是否公开
    • Language：搜索资源引擎语言
  3. 点击”+”即可添加

推荐引擎示例：

  • 1337x：热门资源站
  • 0Magnet：磁力链接搜索

2.5 测试与验证

  1. 添加完成后，点击”Test All”测试所有搜索引擎
  2. 点击”Manual Search”进行搜索测试

三、qBittorrent集成Jackett

3.1 获取Jackett API Key

  1. 访问Jackett Web界面
  2. 在右上角找到并复制API Key

3.2 修改qBittorrent配置

  1. 找到qBittorrent配置文件：nova3/engines/jackett.json
  2. 修改配置文件内容：
    1
    2
    3
    4
    5
    {
        "api_key": "你的API Key",
        "tracker_first": false,
        "url": "http://IP:9117"
    }

3.3 启用与测试

  1. 在qBittorrent中确认Jackett插件已启用
  2. 进行搜索测试验证集成效果

四、搜索效果对比

4.1 原生插件搜索效果

原生插件搜索效果

4.2 Jackett集成后搜索效果

Jackett集成搜索效果

五、优势与特点

5.1 Jackett优势

  1. 资源全面：聚合400+个Tracker，覆盖广泛
  2. 跨平台支持：Windows、macOS、Linux全平台
  3. 中文资源支持：相比原生插件，支持更多中文资源站
  4. 配置灵活：支持代理、API集成等多种配置方式

5.2 组合优势

  • qBittorrent + Jackett：构建完整的一站式资源搜索下载服务
  • 跨平台兼容：两者都支持多平台，组合使用无平台限制
  • 功能互补：Jackett提供强大搜索，qBittorrent提供稳定下载

六、注意事项

6.1 安全考虑

  1. 公网访问：如果Jackett部署在公网，务必设置管理员密码
  2. Private Tracker：谨慎添加Private Tracker，确保遵守相关规则
  3. 代理配置：合理使用代理，避免IP被封

6.2 性能优化

  1. 引擎选择：根据需求选择合适的Tracker，避免添加过多无用引擎
  2. 定期测试：定期测试各搜索引擎的可用性
  3. 缓存清理：定期清理不必要的缓存数据

6.3 维护建议

  1. 定期更新：保持Jackett和qBittorrent为最新版本
  2. 备份配置：定期备份配置文件
  3. 监控日志：关注系统日志，及时发现并解决问题

七、常见问题解决

7.1 插件安装失败

  • 问题：无法从官网下载插件
  • 解决：使用提供的插件包进行本地安装

7.2 搜索无结果

  • 问题：搜索时显示无结果
  • 解决：
    1. 检查网络连接和代理配置
    2. 测试单个搜索引擎是否正常工作
    3. 检查API Key配置是否正确

7.3 连接超时

  • 问题：连接Jackett时超时
  • 解决：
    1. 检查Jackett服务是否正常运行
    2. 确认防火墙设置
    3. 检查网络连通性

八、总结

通过本文的配置指南，您可以成功搭建qBittorrent + Jackett的一站式资源搜索下载服务。这种组合方案具有以下特点：

  1. 功能强大：结合了qBittorrent的优秀下载能力和Jackett的全面搜索能力
  2. 配置灵活：支持多种部署方式和配置选项
  3. 资源丰富：覆盖国内外大量资源站点
  4. 跨平台：支持主流操作系统

建议根据实际需求选择合适的配置方案，并定期维护更新，以获得最佳的使用体验。对于家庭NAS用户或需要大量下载资源的用户，这套方案将大大提高工作效率和资源获取能力。

发表于 更新于

一、 问题背景

连接使用自签名证书的 HTTPS 远程仓库时，Git 默认校验失败并拒绝连接。可通过以下两种方案解决：

  • 方案一（推荐）：将自签名证书加入 Git 信任库，保持 SSL 校验。
  • 方案二（临时）：针对特定仓库 URL 关闭 SSL 校验。

二、 方案一：信任特定自签名证书（安全）

  1. 导出证书

    • 浏览器访问仓库 HTTPS 地址。
    • 点击地址栏锁图标 -> 证书详情 -> 导出为 .pem 或 .crt 格式。
    • 保存至本地固定路径，如 /path/to/certificate.pem。

  2. 配置 Git CA Bundle

    1
    2
    3
    4
    5
    6
    7
    8
    # 全局生效（推荐）
    git config --global http.sslCAInfo /path/to/certificate.pem

    # 仅当前仓库生效
    git config http.sslCAInfo /path/to/certificate.pem

    # 验证配置路径
    git config --global http.sslCAInfo

三、 方案二：针对特定仓库禁用 SSL 验证（便捷）

适用于内网测试或临时调试，不推荐用于生产环境。

1
2
3
4
5
# 针对特定远程 URL 全局禁用验证
git config --global http.https://example.com.sslVerify false

# 仅当前仓库禁用验证
git config http.sslVerify false

四、 验证配置

1
2
3
4
5
# 克隆仓库
git clone https://example.com/repository.git

# 拉取更新
git pull origin main

执行无 SSL certificate problem 报错即表示配置生效。

五、 注意事项

  • 自签名证书无法验证服务器真实身份，存在中间人攻击风险。
  • 仓库级配置 (git config) 优先级高于全局配置 (--global)。
  • 生产环境建议申请受信任的 CA 证书，或使用企业内网 CA 统一签发。

发表于 更新于

概述

VNC（Virtual Network Computing）通过 RFB 协议实现远程控制。客户端/服务器模型：

  • VNC 客户端：本地计算机
  • VNC 服务器：远程系统，传输显示画面副本

安装 VNC 服务器

1
2
sudo apt update
sudo apt -y install tightvncserver

安装桌面环境

使用 Xfce 桌面环境：

1
sudo apt install xfce4 xfce4-goodies

配置 VNC 服务器

设置密码

1
2
3
vncpasswd
Password:
Verify:

启动 VNC 服务器

1
vncserver :1

输出示例：

1
2
3
4
New 'ubuntu-01:1 (user)' desktop is ubuntu-01:1
Creating default startup script /home/user/.vnc/xstartup
Starting applications specified in /home/user/.vnc/xstartup
Log file is /home/user/.vnc/ubuntu-01:1.log

终止 VNC 服务器

1
vncserver -kill :1

配置桌面环境

编辑 VNC 启动脚本：

1
vim ~/.vnc/xstartup

添加内容：

1
exec /usr/bin/startxfce4 &

启动参数说明

参数 含义 示例值
:1 显示编号 :1
-geometry 分辨率 800x600
-depth 颜色深度 24

启动示例：

1
vncserver :1 -geometry 800x600 -depth 24

连接 VNC 桌面

SSH 隧道

创建安全隧道：

1
ssh <username>@<vncserver-ip> -C -L 5901:127.0.0.1:5901

安装客户端

Ubuntu：

1
sudo apt install tigervnc-viewer

Arch Linux：

1
sudo pacman -S tigervnc

连接

SSH 隧道运行后，连接 localhost:5901，输入 VNC 密码。

配置 Systemd 服务

停止现有实例

1
vncserver -kill :1

创建服务文件

1
sudo vim /etc/systemd/system/vncserver@1.service

写入配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target

[Service]
Type=forking
User=your_username
Group=your_username
WorkingDirectory=/home/your_username
PIDFile=/home/your_username/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

注意：将 your_username 替换为实际用户名。

启用服务

1
2
sudo systemctl daemon-reload
sudo systemctl enable --now vncserver@1

检查状态

1
systemctl status vncserver@1

安全建议

VNC 密码传输无加密，推荐使用：

  • VPN：加密连接，隐藏服务器位置
  • SSH 隧道：如上述配置
  • 防火墙：限制 5900 端口访问

总结

完成以下步骤即可在 Ubuntu 上运行 VNC 服务器：

  1. 安装 tightvncserver 和 Xfce 桌面
  2. 配置密码和 xstartup 脚本
  3. 设置 SSH 隧道保证连接安全
  4. 配置 Systemd 服务实现开机自启

发表于 更新于

概述

TensorRT 是 NVIDIA 官方推出的深度学习推理优化工具，专为 NVIDIA GPU 设计，可显著提升模型推理速度并减少内存占用。支持 TensorFlow、PyTorch 等主流框架，通过 ONNX 实现跨框架模型转换。

一、安装TensorRT

1.1 官方包安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 下载匹配CUDA版本的deb包（需NVIDIA账号）
sudo dpkg -i nv-tensorrt-repo-${os}-${tag}_1-1_amd64.deb
sudo apt-key add /var/nv-tensorrt-repo-${os}-${tag}/7fa2af80.pub
sudo apt-get update
sudo apt-get install tensorrt

# Python依赖
python3 -m pip install numpy
sudo apt-get install python3-libnvinfer-dev

# ONNX支持（可选）
python3 -m pip install numpy onnx
sudo apt-get install onnx-graphsurgeon

# PyCUDA（必需）
python3 -m pip install 'pycuda<2021.1'

1.2 验证安装

1
2
3
4
5
6
7
8
9
# 检查系统包
dpkg -l | grep TensorRT

# 验证Python环境
python3 -c "
import tensorrt
print(tensorrt.__version__)
assert tensorrt.Builder(tensorrt.Logger())
"

注意：Anaconda虚拟环境中需额外执行：

1
python3 -m pip install --upgrade nvidia-tensorrt

二、PyTorch → TensorRT 转换流程

2.1 PyTorch → ONNX

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import torch
import torchvision.models as models

# 加载预训练模型
model = models.resnext50_32x4d(pretrained=True)
dummy_input = torch.randn(32, 3, 224, 224)  # BATCH_SIZE=32

# 导出ONNX
torch.onnx.export(
    model, 
    dummy_input, 
    "resnet50_onnx_model.onnx",
    verbose=False
)

替代方案：直接从 ONNX Model Zoo 下载预训练模型

2.2 ONNX → TensorRT

使用 trtexec 命令行工具（位于 /usr/src/tensorrt/bin/）：

1
2
3
4
5
6
7
8
9
10
11
# 基础转换
./trtexec --onnx=resnet50_onnx_model.onnx \
          --saveEngine=resnet_engine.trt

# 推荐参数（固定batch + FP16）
./trtexec --onnx=resnet50_onnx_model.onnx \
          --saveEngine=resnet_engine.trt \
          --explicitBatch \
          --inputIOFormats=fp16:chw \
          --outputIOFormats=fp16:chw \
          --fp16

关键参数说明：

参数 作用
--explicitBatch 固定输入batch size（与ONNX导出时一致）
--fp16 启用FP16精度（加速+省显存）
--inputIOFormats 指定输入数据格式

精度选项：TF32/FP32（默认）/FP16/INT8（需校准）

三、TensorRT 推理实现

3.1 Runtime选择

Runtime 适用场景 性能
C++ API 通用高性能需求 ★★★★
TF-TRT TensorFlow专用 ★★
Triton 多框架服务化 ★★★

推荐：PyTorch模型选用 C++ API（通过Python绑定）

3.2 Python推理代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
import numpy as np
import tensorrt as trt
import pycuda.driver as cuda
import pycuda.autoinit
import time

# 配置参数
BATCH_SIZE = 32
USE_FP16 = True
target_dtype = np.float16 if USE_FP16 else np.float32

# 加载引擎
with open("resnet_engine.trt", "rb") as f:
    runtime = trt.Runtime(trt.Logger(trt.Logger.WARNING))
    engine = runtime.deserialize_cuda_engine(f.read())
    context = engine.create_execution_context()

# 内存分配
input_batch = np.random.randn(BATCH_SIZE, 224, 224, 3).astype(target_dtype)
output = np.empty([BATCH_SIZE, 1000], dtype=target_dtype)
d_input = cuda.mem_alloc(input_batch.nbytes)
d_output = cuda.mem_alloc(output.nbytes)
bindings = [int(d_input), int(d_output)]
stream = cuda.Stream()

# 预处理函数
def preprocess_input(input_data):
    # (224,224,3) → (3,224,224)
    result = torch.from_numpy(input_data).transpose(0,2).transpose(1,2)
    return np.array(result, dtype=target_dtype)

# 推理函数
def predict(batch):
    cuda.memcpy_htod_async(d_input, batch, stream)
    context.execute_async_v2(bindings, stream.handle, None)  # 异步推理
    cuda.memcpy_dtoh_async(output, d_output, stream)
    stream.synchronize()
    return output

# 执行推理
preprocessed_inputs = np.array([
    preprocess_input(inp) for inp in input_batch
])
print("Warming up...")
pred = predict(preprocessed_inputs)
print("Done warming up!")

t0 = time.time()
pred = predict(preprocessed_inputs)
print(f"Prediction cost {time.time()-t0:.4f}s")

关键点：

  • 输入/输出内存需在GPU上分配
  • 数据格式需与导出时一致（CHW vs HWC）
  • 异步推理（execute_async_v2）性能优于同步

四、性能验证

测试模型：SlowFast 行为识别
输入尺寸：(1,1,3,32,256,256)
结果：TensorRT 相比原生 PyTorch 推理速度显著提升（具体数据见原文图表）

参考资源

官方文档

社区资源

发表于 更新于

一、 概述与核心概念

1.1 什么是 CoreDNS？

CoreDNS 是一个用 Go 语言编写的、高度可扩展和插件化的 DNS 服务器。它来自云原生计算基金会（CNCF），是 Kubernetes 的默认 DNS 服务器，其设计目标是易于使用且功能强大。

核心特点：

  • 插件化架构：几乎所有功能都通过插件实现，可以灵活组合，适用于传统 DNS、服务发现、负载均衡等多种场景。
  • 高性能与可靠性：基于 Go 语言，性能优异。支持自动重试、健康检查和负载均衡。
  • 易于配置：使用简单易懂的 Caddyfile 格式配置文件。
  • Kubernetes 原生：深度集成 K8s，用于集群内服务发现。
1.2 CoreDNS 与传统 DNS（如 BIND）的区别

传统 DNS 服务器功能固定且庞大。CoreDNS 则像一个“DNS 功能总线”，通过加载不同的插件来实现特定功能，这使得它更轻量、更灵活。正如其官方所说：CoreDNS is powered by plugins.

1.3 核心配置文件：Corefile

CoreDNS 的行为由 Corefile 定义。其基本结构如下：

1
2
3
4
5
# ZONE: 定义服务器负责的区，PORT 默认为 53
ZONE:[PORT] {
  # PLUGIN: 定义要加载的插件及其参数
  [PLUGIN] [PLUGIN_ARGUMENTS]...
}

示例：

1
2
3
4
5
6
7
.:53 {
    whoami
}

weiyigeek.top {
    file db.weiyigeek.top
}

二、 安装与基础配置

2.1 安装 CoreDNS

方式一：二进制安装（推荐）

1
2
3
4
COREDNS_VERSION="1.11.1"
wget https://github.com/coredns/coredns/releases/download/v${COREDNS_VERSION}/coredns_${COREDNS_VERSION}_linux_amd64.tgz
tar xf coredns_${COREDNS_VERSION}_linux_amd64.tgz -C /usr/local/bin/
ln -s /usr/local/bin/coredns /usr/bin/coredns

方式二：从源码编译

1
2
3
4
5
git clone -b v1.11.1 https://github.com/coredns/coredns
cd coredns
make
# 或使用 Docker 环境编译
docker run --rm -i -t -v $PWD:/v -w /v golang:1.21 make
2.2 系统服务化部署
  1. 创建专用用户和目录：
    1
    2
    3
    useradd coredns -s /sbin/nologin
    mkdir -p /etc/coredns/
    chown -R coredns /etc/coredns/
  2. 创建 Systemd 服务文件 (/usr/lib/systemd/system/coredns.service)：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    [Unit]
    Description=CoreDNS DNS server
    Documentation=https://coredns.io
    After=network.target

    [Service]
    LimitNOFILE=1048576
    User=coredns
    WorkingDirectory=/etc/coredns
    ExecStart=/usr/bin/coredns -conf=/etc/coredns/Corefile
    ExecReload=/bin/kill -SIGUSR1 $MAINPID
    Restart=on-failure

    [Install]
    WantedBy=multi-user.target
1
2
systemctl daemon-reload
systemctl enable coredns
  1. 配置防火墙：
    1
    2
    firewall-cmd --permanent --add-service=dns
    firewall-cmd --reload
2.3 基础配置文件示例

创建 /etc/coredns/Corefile，配置一个简单的 DNS 服务器，使用 hosts 插件进行本地解析，并转发未知查询到上游 DNS。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
.:53 {
    bind 0.0.0.0
    hosts {
        # 自定义本地解析
        192.168.1.2 www.weiyigeek.top
        192.168.1.3 blog.weiyigeek.top
        ttl 60
        reload 1m
        fallthrough # 未匹配时继续执行下一个插件
    }
    # 转发未知查询到公共 DNS
    forward . 223.6.6.6 114.114.114.114
    cache 120 # 缓存
    log       # 记录日志
    errors    # 记录错误
}
  1. 启动并测试：
    1
    2
    3
    systemctl start coredns
    dig www.weiyigeek.top @localhost
    dig google.com @localhost # 应被转发解析

三、 插件系统详解

3.1 插件概述与工作模式

CoreDNS 的功能完全由插件驱动。插件分为两类：

  • Normal 插件：参与请求处理逻辑，并出现在插件链中（如 hosts, file, forward）。
  • Other 插件：不参与请求逻辑，仅修改服务器配置（如 health, ready, prometheus）。

插件链执行逻辑：

  1. 请求进入匹配的 Server Zone。
  2. 按 plugin.cfg 定义的顺序依次执行插件链上的插件。
  3. 每个插件决定如何处理请求：直接响应、传递 (fallthrough)、或添加信息后继续传递。

查看可用插件：coredns -plugins

3.2 常用插件详解
hosts 插件

用于从 /etc/hosts 风格的文件或内联配置提供 A/AAAA/PTR 记录。适合少量静态记录。

  • 语法：
    1
    2
    3
    4
    5
    6
    hosts [FILE] {
    	[INLINE_ENTRIES]
    	ttl SECONDS
    	reload DURATION
    	fallthrough [ZONES...]
    }
  • 示例：
    1
    2
    3
    4
    5
    6
    7
    8
    .:53 {
    	hosts {
    		192.168.1.10 api.internal
    		192.168.1.11 db.internal
    		fallthrough
    	}
    	forward . 8.8.8.8
    }
file 插件

用于从符合 RFC 1035 标准的主区域文件提供 DNS 服务。适合大量记录或需要标准区域文件管理的场景。

  • 语法：
    1
    2
    3
    file DBFILE [ZONES...] {
    	reload DURATION
    }
  • 示例：
    1
    2
    3
    weiyigeek.top {
    	file /etc/coredns/db.weiyigeek.top
    }
    *区域文件示例 (/etc/coredns/db.weiyigeek.top)*：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    $TTL 86400
    @   IN  SOA  ns1.weiyigeek.top. admin.weiyigeek.top. (
    				2023082501 ; Serial
    				7200       ; Refresh
    				3600       ; Retry
    				1209600    ; Expire
    				3600 )     ; Negative Cache TTL
    ;
    @   IN  NS   ns1
    ns1 IN  A    192.168.1.100
    www IN  A    192.168.1.101
forward 插件

将查询转发到上游 DNS 服务器。是构建递归解析器或指定上游的关键插件。

  • 语法：
    1
    forward . UPSTREAM_DNS...
  • 示例：
    1
    2
    3
    4
    .:53 {
    	forward . 8.8.8.8:53 1.1.1.1:53 /etc/resolv.conf
    	cache 60
    }
cache 插件

缓存 DNS 响应，减少上游查询，提升性能。

  • 语法：
    1
    2
    3
    4
    cache [TTL] {
    	success CAPACITY [TTL]
    	denial CAPACITY [TTL]
    }
  • 示例：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    .:53 {
    	forward . 8.8.8.8
    	cache 120 # 缓存所有响应120秒
    	# 或更精细控制
    	cache {
    		success 5000 300
    		denial 1000 60
    	}
    }
3.3 Kubernetes 集成插件 (kubernetes)

CoreDNS 在 K8s 中的核心插件，用于服务发现（将 Service 名称解析为 ClusterIP）。

  • 典型 K8s 配置：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    .:53 {
    	errors
    	health
    	kubernetes cluster.local in-addr.arpa ip6.arpa {
    		pods verified
    		fallthrough in-addr.arpa ip6.arpa
    	}
    	prometheus :9153
    	forward . /etc/resolv.conf
    	cache 30
    	loop
    	reload
    	loadbalance
    }

四、 高级配置与实战

4.1 多区域与复杂配置

一个 Corefile 可以定义多个服务器块，处理不同域或端口的请求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 处理内部域
internal.company {
    file /etc/coredns/db.internal
    log
}

# 处理外部域，监听在5300端口
example.com:5300 {
    forward . 8.8.8.8
    cache 300
}

# 默认处理所有其他查询
.:53 {
    forward . 1.1.1.1 9.9.9.9
    cache 60
    errors
    log
}
4.2 DNSSEC 配置

CoreDNS 支持动态 DNSSEC 签名。

  1. 生成 DNSSEC 密钥：
    1
    2
    3
    cd /etc/coredns
    dnssec-keygen -a ECDSAP256SHA256 -f KSK weiyigeek.top
    # 生成 Kweiyigeek.top.+013+12345.key 和 .private 文件
  2. 使用 dnssec 插件（动态签名响应）：
    1
    2
    3
    4
    5
    6
    weiyigeek.top {
    	file /etc/coredns/db.weiyigeek.top
    	dnssec {
    		key file /etc/coredns/Kweiyigeek.top.+013+12345.key
    	}
    }
  3. 使用 sign 插件（预签名区域文件）：
    1
    2
    3
    4
    5
    6
    weiyigeek.top {
    	sign /etc/coredns/db.weiyigeek.top {
    		key file /etc/coredns/Kweiyigeek.top.+013+12345.key
    		directory /var/lib/coredns
    	}
    }
    签名后的区域文件将保存在 /var/lib/coredns/db.weiyigeek.top.signed。
4.3 TSIG 配置（事务签名）

用于验证和签名 DNS 请求/响应，常用于区域传输（AXFR/IXFR）安全。

  1. 生成 TSIG 密钥：
    1
    tsig-keygen -a hmac-sha256 dns-tsig-key. > /etc/coredns/dns-tsig.secrets
  2. 配置 tsig 插件：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    weiyigeek.top {
    	file /etc/coredns/db.weiyigeek.top
    	tsig {
    		secrets /etc/coredns/dns-tsig.secrets
    		require AXFR IXFR # 要求区域传输必须签名
    	}
    	transfer {
    		to * # 允许向任何请求者传输（生产环境应限制IP）
    	}
    }
4.4 使用 etcd 插件实现动态服务发现

可以将服务记录存储在 etcd 中，CoreDNS 从中读取。

1
2
3
4
5
6
7
8
9
etcd-weiyigeek.local:53 {
    etcd {
        path /skydns
        endpoint http://172.22.50.98:2379
        fallthrough
    }
    cache 160
    log
}

在 etcd 中存储记录：

1
etcdctl put /skydns/local/etcd-weiyigeek/www '{"host":"172.22.50.100","ttl":60}'

查询：dig www.etcd-weiyigeek.local

五、 故障排查与性能优化

  • 查看日志：确保配置中启用了 log 和 errors 插件。
  • 检查插件顺序：插件链顺序很重要，例如 cache 应在 forward 之后。
  • 监控：启用 prometheus 插件（默认在 :9153 端口）以获取指标。
  • 性能调优：
    • 合理设置 cache 插件的 TTL 和容量。
    • 根据负载调整 forward 插件中的上游 DNS 服务器列表。
    • 使用 loadbalance 插件实现上游 DNS 的轮询负载均衡。

六、 总结

CoreDNS 凭借其插件化、高性能和易配置的特性，已成为从传统 DNS 到云原生服务发现的理想选择。通过灵活组合 hosts、file、forward、cache 等插件，可以轻松构建出满足各种需求的 DNS 架构。对于 Kubernetes 环境，它更是不可或缺的核心组件。

官方资源：

提示：生产环境部署时，请务必关注安全最佳实践，如使用非 root 用户运行、配置适当的防火墙规则、为区域传输启用 TSIG、以及定期更新 CoreDNS 版本。

发表于 更新于

1 背景与演进

1.1 为什么需要分布式文件系统

阶段 特点 优缺点
单机时代 项目目录下建立静态文件夹 简单但文件与代码耦合，流量大时影响业务
独立文件服务器 图片服务器 + Nginx 独立部署 性能分离但存在单机瓶颈
分布式文件系统 存储 + 仲裁 + 容灾三系统配合 高可用、可扩展，但复杂度较高

1.2 适用场景

FastDFS 特别适合以中小文件（建议范围：4KB < file_size < 500MB）为载体的在线服务：

  • 相册网站
  • 视频网站
  • 网盘、社区、广告等业务存储

2 FastDFS 概述

2.1 核心特性

  • 轻量级：纯 C 实现，支持 Linux、FreeBSD 等 UNIX 系统
  • 文件一对一：文件不分块存储，与 OS 文件系统一一对应
  • 去重：相同内容文件只保存一份，节约磁盘空间
  • HTTP 支持：内置 Web Server 或配合 Nginx/Apache
  • 在线扩容：支持动态扩展存储容量
  • 主从文件：支持主从文件机制
  • 高性能：V2.0 采用 libevent 网络通信，支持大并发

2.2 架构定位

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌─────────────────────────────────────────────────────┐
│                    Client                            │
│              (业务请求发起方)                          │
└─────────────────────┬───────────────────────────────┘
                      │
              ┌───────▼───────┐
              │   Tracker     │
              │   (调度中心)   │
              └───────┬───────┘
                      │
        ┌─────────────┼─────────────┐
        │             │             │
   ┌────▼────┐   ┌────▼────┐   ┌────▼────┐
   │Storage 1│   │Storage 2│   │Storage N│
   │ (Group1)│   │ (Group1)│   │ (Group2)│
   └─────────┘   └─────────┘   └─────────┘

3 核心概念

3.1 服务角色

角色 职责 特点
Tracker Server 调度、负载均衡 内存记录所有 storage 状态，无持久化，易扩展
Storage Server 文件存储 以组为单位组织，文件属性（meta-data）一并保存
Client 业务请求发起 通过专有 API 与 tracker/storage 交互

3.2 核心术语

术语 说明
Group / Volume 卷/组，同组内服务器文件完全相同，互为备份
Meta-data 文件属性，Key-Value 键值对（如：width=1024）
FID File ID，文件唯一标识

3.3 Storage 组织结构

1
2
3
4
5
6
7
8
9
Storage Server
├── /data/disk1/     # 数据存储目录1
│   ├── 00/
│   │   ├── 00/
│   │   ├── 01/
│   │   └── ...
│   └── FF/
├── /data/disk2/     # 数据存储目录2
└── ...
  • 每个存储目录创建 2 级子目录（每级 256 个）
  • 总共 65536 个文件目录
  • 文件按 hash 路由到对应子目录

4 上传机制

4.1 上传流程

1
2
3
4
5
6
┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
│  Client  │────▶│ Tracker  │────▶│ Storage  │────▶│ 写入磁盘  │
└──────────┘     └──────────┘     └──────────┘     └──────────┘
                      │                │
                      ▼                ▼
               返回 ip:port      生成 file_id

4.2 选择策略

1. 选择 Group

规则 说明
Round robin 所有 group 间轮询
Specified group 指定确定 group
Load balance 剩余空间多的 group 优先

2. 选择 Storage Server

规则 说明
Round robin group 内所有 storage 间轮询
First server ordered by IP 按 IP 排序
First server ordered by priority 按优先级排序

3. 选择 Storage Path

规则 说明
Round robin 多个存储目录间轮询
剩余空间优先 剩余存储空间最多的目录优先

4.3 FileId 生成

1
FileId = base64(storage_ip + 文件创建时间 + 文件大小 + crc32 + 随机数)

4.4 文件名组成

1
文件名 = group + 虚拟磁盘路径 + 两级子目录 + file_id + 文件后缀

示例：

1
group1/M00/00/00/wKgBaE9u4O6Ab7SDAAvgG5Q3vw428.jpg

5 下载机制

5.1 下载流程

1
2
3
┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
│  Client  │────▶│ Tracker  │────▶│ Storage  │────▶│ 返回文件  │
└──────────┘     └──────────┘     └──────────┘     └──────────┘

5.2 Storage 选择策略

Tracker 按以下优先级选择可读的 storage：

优先级 条件 说明
1 源头 storage 文件上传时的源服务器，肯定包含文件
2 同步完成 文件创建时间 + 最大同步时间 < 当前时间
3 同步时间戳 文件创建时间 < storage 同步时间戳
4 延迟阈值 当前时间 - 文件创建时间 > 同步延迟阈值

6 同步机制

6.1 同步原理

1
2
3
4
5
6
┌──────────┐      binlog       ┌──────────┐
│Storage A │ ───────────────▶ │Storage B │
└──────────┐                   └──────────┘
     │                               │
     └─────────── 上报 ──────────────┘
                   Tracker
  • Storage 写文件后，后台异步同步到同组其他 server
  • 同步信息以 binlog 形式记录（不包含文件数据）
  • 同步进度以时间戳方式记录

6.2 时钟同步要求

集群内所有服务器时钟必须保持同步，否则同步进度计算会出错。

7 文件定位（FID）

7.1 FID 组成

1
FID = group + 虚拟磁盘路径 + 两级子目录 + file_id + 文件后缀

7.2 快速定位原理

步骤 操作 说明
1 解析 group tracker 定位到目标 storage group
2 解析路径 根据虚拟磁盘路径定位存储目录
3 解析目录 根据两级子目录定位具体目录
4 查找文件 根据文件名定位文件

8 集群部署

8.1 典型架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
                ┌─────────────────────────────────────┐
                │              Nginx                  │
                │         (负载均衡/静态资源)           │
                └─────────────────┬───────────────────┘
                                  │
       ┌──────────────────────────┼──────────────────────────┐
       │                          │                          │
┌──────▼──────┐           ┌──────▼──────┐           ┌──────▼──────┐
│   Tracker1  │           │   Tracker2  │           │   Tracker3  │
└──────┬──────┘           └──────┬──────┘           └──────┬──────┘
       │                          │                          │
┌──────┴──────┐           ┌──────┴──────┐           ┌──────┴──────┐
│   Group1    │           │   Group2    │           │   Group3    │
│ S1  S2  S3  │           │ S4  S5  S6  │           │ S7  S8  S9  │
└─────────────┘           └─────────────┘           └─────────────┘

8.2 部署建议

配置项 建议
Tracker 数量 至少 2 台，实现高可用
Group 内 Storage 3 台以上，互为备份
存储目录 多磁盘挂载，充分利用空间
时钟同步 所有节点配置 NTP 服务

9 Java 客户端使用

9.1 Maven 依赖

1
2
3
4
5
<dependency>
    <groupId>org.csource</groupId>
    <artifactId>fastdfs-client-java</artifactId>
    <version>1.29-RELEASE</version>
</dependency>

9.2 配置文件

1
2
3
fastdfs.tracker_list=192.168.1.100:22122,192.168.1.101:22122
fastdfs.connect_timeout_in_seconds=5
fastdfs.network_timeout_in_seconds=30

9.3 上传示例

1
2
3
4
5
6
7
8
TrackerClient trackerClient = new TrackerClient();
TrackerServer trackerServer = trackerClient.getConnection();
StorageServer storageServer = null;

StorageClient storageClient = new StorageClient(trackerServer, storageServer);
String[] result = storageClient.upload_file("/path/to/file.jpg", "jpg", null);
System.out.println("Group: " + result[0]);
System.out.println("Path: " + result[1]);

10 总结

10.1 核心优势

  • 高性能：轻量级设计，支持高并发
  • 高可用：多 tracker、多 storage 集群支持
  • 可扩展：在线扩容，灵活增加存储节点
  • 低成本：开源免费，硬件要求低

10.2 适用场景

  • 中小文件为主的在线服务
  • 需要高可用存储的业务系统
  • 对成本敏感但需要分布式存储的场景

10.3 参考资源

资源 链接
官方 GitHub https://github.com/happyfish100/
配置文档 https://github.com/happyfish100/fastdfs/wiki/
Java 客户端 https://github.com/happyfish100/fastdfs-client-java

发表于 更新于

一、GlusterFS 概述

1.1 简介

GlusterFS 是开源的分布式文件系统，主要由存储服务器（Brick Server）、客户端及 NFS/Samba 存储网关组成。支持数 PB 存储容量和数千客户端，横向扩展能力强。

与传统分布式文件系统的区别：

  • 传统分布式文件系统依赖元数据服务器，存在单点故障风险
  • GlusterFS 采用无元服务器设计，通过弹性哈希算法定位数据

1.2 核心特点

特点 说明
扩展性和高性能 Scale-Out 架构，高速网络互联（TCP/IP、InfiniBand RDMA）
高可用性 自动复制、自我修复功能
全局统一命名空间 多节点整合为虚拟存储池
弹性卷管理 在线增加/移除节点、扩缩容
标准协议 支持 NFS、CIFS、HTTP、FTP、SMB、Gluster 原生协议

1.3 核心术语

术语 说明
Brick 基本存储单元，格式为 SERVER:EXPORT（如 192.168.80.10:/data/sdb1）
Volume 逻辑卷，一组 Brick 的集合，类似 LVM
FUSE 内核模块，允许用户创建自定义文件系统
VFS 内核空间对用户空间提供的磁盘访问接口
Glusterd 后台管理进程，每个节点必须运行

二、架构与工作原理

2.1 模块化堆栈式架构

  • 模块称为 Translator，通过组合实现复杂功能
  • Replicate 模块 → RAID1
  • Stripe 模块 → RAID0
  • 两者组合 → RAID10

2.2 工作流程

1
2
客户端访问 → VFS API → FUSE 内核文件系统 → GlusterFS Client → 
    网络传输 → GlusterFS Server → 存储设备

2.3 弹性 HASH 算法

  • 基于 Davies-Meyer 算法，生成 32 位整数 hash 值
  • 将 hash 空间划分为 N 个子空间，每个对应一个 Brick
  • 优点：数据平均分布、解决元数据服务器依赖、无单点故障

三、卷类型详解

卷类型 说明 冗余性 适用场景
分布式卷 文件级 RAID0，按 HASH 分布到不同 Brick 无 容量扩展
条带卷 文件分块轮询分布，类似 RAID0 无 大文件读写
复制卷 文件同步副本，类似 RAID1 有 高可用
分布式条带卷 分布式 + 条带组合 无 大文件 + 容量
分布式复制卷 分布式 + 复制组合 有 高可用 + 容量
条带复制卷 条带 + 复制组合，类似 RAID10 有 高性能高可用
分布式条带复制卷 三种组合 有 MapReduce 类应用

创建命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 分布式卷（默认）
gluster volume create dis-volume node1:/data/sdb1 node2:/data/sdb1 force

# 条带卷
gluster volume create stripe-volume stripe 2 node1:/data/sdc1 node2:/data/sdc1 force

# 复制卷
gluster volume create rep-volume replica 2 node3:/data/sdb1 node4:/data/sdb1 force

# 分布式条带卷（需 4 台服务器）
gluster volume create dis-stripe stripe 2 node1:/data/sdd1 node2:/data/sdd1 node3:/data/sdd1 node4:/data/sdd1 force

# 分布式复制卷
gluster volume create dis-rep replica 2 node1:/data/sde1 node2:/data/sde1 node3:/data/sde1 node4:/data/sde1 force

四、部署步骤

4.1 实验环境

节点 IP 磁盘 挂载点
node1 192.168.80.10 /dev/sdb1~sde1 /data/sdb1~sde1
node2 192.168.80.11 /dev/sdb1~sde1 /data/sdb1~sde1
node3 192.168.80.12 /dev/sdb1~sde1 /data/sdb1~sde1
node4 192.168.80.13 /dev/sdb1~sde1 /data/sdb1~sde1
客户端 192.168.80.14 - -

4.2 环境准备（所有 Node）

1
2
3
4
5
6
# 关闭防火墙
systemctl stop firewalld
setenforce 0

# 磁盘分区挂载脚本
vim /opt/fdisk.sh
1
2
3
4
5
6
7
8
9
10
#!/bin/bash
NEWDEV=`ls /dev/sd* | grep -o 'sd[b-z]' | uniq`
for VAR in $NEWDEV
do
   echo -e "n\np\n\n\n\nw\n" | fdisk /dev/$VAR &> /dev/null
   mkfs.xfs /dev/${VAR}"1" &> /dev/null
   mkdir -p /data/${VAR}"1" &> /dev/null
   echo "/dev/${VAR}1 /data/${VAR}1 xfs defaults 0 0" >> /etc/fstab
done
mount -a &> /dev/null
1
2
3
4
5
# 配置 hosts
echo "192.168.80.10 node1" >> /etc/hosts
echo "192.168.80.11 node2" >> /etc/hosts
echo "192.168.80.12 node3" >> /etc/hosts
echo "192.168.80.13 node4" >> /etc/hosts

4.3 安装 GlusterFS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 配置本地 repo
mkdir repo.bak && mv *.repo repo.bak

cat > /etc/yum.repos.d/glfs.repo <<EOF
[glfs]
name=glfs
baseurl=file:///opt/gfsrepo
gpgcheck=0
enabled=1
EOF

yum clean all && yum makecache
yum -y install glusterfs glusterfs-server glusterfs-fuse glusterfs-rdma

systemctl start glusterd.service
systemctl enable glusterd.service

4.4 构建信任池

1
2
3
4
5
6
7
8
# 仅需在 node1 执行
gluster peer probe node1
gluster peer probe node2
gluster peer probe node3
gluster peer probe node4

# 查看状态
gluster peer status

4.5 创建并启动卷

1
2
3
4
5
6
7
8
9
10
11
12
13
gluster volume create dis-volume node1:/data/sdb1 node2:/data/sdb1 force
gluster volume create stripe-volume stripe 2 node1:/data/sdc1 node2:/data/sdc1 force
gluster volume create rep-volume replica 2 node3:/data/sdb1 node4:/data/sdb1 force
gluster volume create dis-stripe stripe 2 node1:/data/sdd1 node2:/data/sdd1 node3:/data/sdd1 node4:/data/sdd1 force
gluster volume create dis-rep replica 2 node1:/data/sde1 node2:/data/sde1 node3:/data/sde1 node4:/data/sde1 force

gluster volume start dis-volume
gluster volume start stripe-volume
gluster volume start rep-volume
gluster volume start dis-stripe
gluster volume start dis-rep

gluster volume list

4.6 客户端部署

1
2
3
4
5
6
7
8
9
10
11
12
# 安装客户端
yum -y install glusterfs glusterfs-fuse

# 创建挂载点
mkdir -p /test/{dis,stripe,rep,dis_stripe,dis_rep}

# 挂载
mount.glusterfs node1:dis-volume /test/dis
mount.glusterfs node1:stripe-volume /test/stripe
mount.glusterfs node1:rep-volume /test/rep
mount.glusterfs node1:dis-stripe /test/dis_stripe
mount.glusterfs node1:dis-rep /test/dis_rep

五、破坏性测试结果

卷类型 故障节点 结果
分布式卷 node2 demo5.log 丢失（数据不安全）
条带卷 node2 无法访问（无冗余）
复制卷 node2 + node4 正常访问（数据安全）
分布式条带卷 node2 无法访问（无冗余）
分布式复制卷 node2 正常访问（数据安全）

结论：带复制功能的卷具备高可用性，数据更安全。

六、维护命令

1
2
3
4
5
6
gluster volume list              # 查看所有卷
gluster volume info              # 查看卷详情
gluster volume status            # 查看卷状态
gluster volume stop <volname>    # 停止卷
gluster volume delete <volname>   # 删除卷（需先停止）
gluster volume set <volname> auth.allow 192.168.80.*  # 访问控制

待补充

  • 与 Kubernetes PV/PVC 集成
  • 性能调优参数
  • 故障恢复流程

发表于 更新于 分类于

本文介绍了Linux系统中常用的五种串口终端工具：cu、screen、minicom、putty和tip。这些工具适用于不同的场景和需求，能够帮助用户快速建立并配置串口连接。

1. cu 指令

cu（Call Unix）是一个简单的串行通信程序，用于建立串口连接。

基本用法

1
$ cu -l /dev/device -s baud-rate-speed

示例

1
$ cu -l /dev/ttyS0 -s 19200

退出方式

输入 ~.（波浪号后跟点号）即可退出连接。

特点

  • 简单易用，适合快速测试
  • 命令行界面，无需复杂配置
  • 支持基本的串口参数设置

2. screen 指令

screen是一个终端多路复用器，也可以用于串口通信，功能强大且灵活。

基本用法

1
$ screen /dev/device baud-rate

示例

1
2
$ screen /dev/ttyS0 19200
$ screen /dev/ttyUSB0 19200,cs8

常用参数

  • /dev/ttyS0 - 串口设备文件
  • 19200 - 波特率
  • cs8 - 8位数据位（可选）

退出方式

  • 按 Ctrl+A，然后按 K，再按 Y 确认退出
  • 或按 Ctrl+A，然后按 D 分离会话（后台运行）

特点

  • 支持会话管理，可后台运行
  • 可同时管理多个终端会话
  • 支持窗口分割和滚动历史

3. minicom 指令

minicom是一个功能完整的串口通信程序，具有菜单驱动的配置界面。

基本用法

1
$ minicom

配置方法

首次运行需要配置：

1
$ minicom -s

主要功能

  1. 串口参数配置 - 波特率、数据位、停止位、奇偶校验
  2. 文件传输 - 支持多种协议（Xmodem、Ymodem、Zmodem）
  3. 脚本功能 - 可编写自动化脚本
  4. 日志记录 - 支持会话日志保存

常用快捷键

  • Ctrl+A + Z - 显示帮助菜单
  • Ctrl+A + O - 配置菜单
  • Ctrl+A + X - 退出minicom

特点

  • 功能全面，适合专业调试
  • 支持多种文件传输协议
  • 可保存配置，方便重复使用

4. putty 指令

putty是一个跨平台的SSH、Telnet和串口客户端，具有图形界面。

安装方法

1
$ sudo apt-get install putty

图形界面使用

  1. 启动putty：$ putty
  2. 选择”Serial”连接类型
  3. 配置串口参数：
    • Serial line: /dev/ttyS0（串口设备）
    • Speed: 19200（波特率）
  4. 点击”Open”建立连接

命令行使用

1
$ putty -serial /dev/ttyS0 -sercfg 19200

特点

  • 图形界面，操作直观
  • 支持多种连接协议
  • 可保存会话配置
  • 跨平台支持（Windows/Linux）

5. tip 指令

tip是一个简单的串口通信程序，语法简洁。

基本用法

1
$ tip -19200 device

示例

1
2
$ tip -19200 s0
$ tip -19200 ttys0

参数说明

  • -19200 - 波特率（前面带减号）
  • s0 - 串口设备简写（对应/dev/ttyS0）
  • ttys0 - 完整设备名

退出方式

输入 ~. 退出连接。

特点

  • 语法简单，易于记忆
  • 适合快速测试和简单通信
  • 轻量级，资源占用少

工具对比

工具 界面类型 主要特点 适用场景
cu 命令行 简单快速，适合测试 快速连接测试
screen 命令行 会话管理，多任务 长时间连接，多任务处理
minicom 菜单驱动 功能全面，支持文件传输 专业调试，文件传输
putty 图形界面 操作直观，跨平台 图形界面操作，多协议支持
tip 命令行 语法简洁，轻量级 简单通信，快速测试

使用建议

1. 快速测试

  • 使用 cu 或 tip 进行快速连接测试
  • 命令简单，无需复杂配置

2. 日常调试

  • 使用 screen 进行日常串口调试
  • 支持会话管理，可随时断开和重连

3. 专业开发

  • 使用 minicom 进行专业级串口调试
  • 支持文件传输、脚本自动化等高级功能

4. 图形界面需求

  • 使用 putty 获得图形界面体验
  • 适合不熟悉命令行的用户

常见问题

1. 权限问题

1
$ sudo chmod 666 /dev/ttyS0

或将自己加入dialout组：

1
$ sudo usermod -a -G dialout $USER

2. 设备识别

查看可用串口设备：

1
2
3
$ ls /dev/ttyS*
$ ls /dev/ttyUSB*
$ dmesg | grep tty

3. 参数配置

串口通信需要正确配置以下参数：

  • 波特率（Baud Rate）：115200、19200、9600等
  • 数据位（Data Bits）：5、6、7、8
  • 停止位（Stop Bits）：1、1.5、2
  • 奇偶校验（Parity）：None、Even、Odd
  • 流控制（Flow Control）：None、Hardware、Software

总结

Linux系统提供了多种串口终端工具，各有特点和适用场景。用户可以根据具体需求选择合适的工具：

  • 简单测试：选择 cu 或 tip
  • 日常使用：选择 screen（轻量且功能强大）
  • 专业调试：选择 minicom（功能全面）
  • 图形界面：选择 putty（操作直观）

掌握这些工具的使用方法，能够大大提高在Linux环境下进行串口通信和调试的效率。建议根据实际工作流程和个人偏好，选择1-2个主要工具进行深入学习和使用。

发表于 更新于

STM32上可用的SM2、SM3、SM4国密算法

本文详细介绍了在STM32平台上实现国密算法SM2、SM3、SM4的方法，包括代码示例和关键步骤解析，适用于嵌入式安全应用。

概述

国密算法是中国自主研发的商用密码算法，包括SM2（椭圆曲线公钥密码算法）、SM3（密码杂凑算法）和SM4（分组密码算法）。在嵌入式设备上实现这些算法需要考虑资源限制和性能要求。

SM2算法实现

SM2算法基于椭圆曲线密码学，涉及复杂的数理计算，需要数学运算库支持。在STM32上实现主要有两种方法：移植OpenSSL或MIRACL库，或使用硬件加密芯片。

本文采用移植MIRACL库的方式实现，编译所需文件为lib库，在工程中引用。

核心代码结构

主要文件包括：

  • sm2.c - SM2算法主实现文件
  • sm2.h - SM2算法头文件
  • miracl.h - MIRACL库头文件
  • mirdef.h - MIRACL编译器/硬件定义

关键功能函数

  1. 密钥生成 - sm2_keygen()

    • 生成SM2公私钥对
    • 公钥包含X、Y坐标，私钥为32字节

  2. 加密函数 - sm2_encrypt()

    • 使用公钥加密数据
    • 输出密文长度为明文长度 + 96字节

  3. 解密函数 - sm2_decrypt()

    • 使用私钥解密数据
    • 输出明文长度为密文长度 - 96字节

  4. 密钥派生函数 - kdf()

    • 用于密钥派生计算

编译配置

mirdef.h文件需要针对STM32平台进行配置：

1
2
3
4
5
6
7
8
9
10
11
#define MIRACL 32
#define MR_LITTLE_ENDIAN
#define mr_utype int
#define MR_IBITS 32
#define mr_dltype __int64
#define mr_unsign32 unsigned int
#define mr_unsign64 unsigned __int64
#define MAXBASE ((mr_small)1<<(MIRACL-1))
#define MR_STATIC 20
#define MR_GENERIC_MT
#define MR_NOASM

预编译库

提供直接编译好的lib库，下载地址：https://download.csdn.net/download/weixin_44522056/12483974

SM3算法实现

SM3是密码杂凑算法，输出为256位哈希值。

核心代码结构

  • sm3.c - SM3算法实现
  • sm3.h - SM3算法头文件

算法特点

  1. 消息填充 - 支持任意长度消息
  2. 压缩函数 - 64轮迭代处理
  3. 常量定义 - 使用固定初始值和常量

主要函数

  • SM3Calc() - 主计算函数
  • SM3Init() - 初始化上下文
  • SM3ProcessMessageBlock() - 处理消息块

SM4算法实现

SM4是分组密码算法，分组长度128位，密钥长度128位。

核心代码结构

  • sm4.c - SM4算法实现
  • sm4.h - SM4算法头文件

工作模式

  1. ECB模式 - 电子密码本模式
  2. CBC模式 - 密码分组链接模式
  3. PKCS7填充 - 支持数据填充

关键函数

  1. 基础加解密

    • sm4_crypt_ecb_old() - ECB模式基础加解密
    • sm4_crypt_cbc_old() - CBC模式基础加解密

  2. 带填充的加解密

    • sm4_crypt_ecb() - ECB模式 + PKCS7填充
    • sm4_crypt_cbc() - CBC模式 + PKCS7填充

算法参数

  • S盒：8位输入到8位输出的非线性变换
  • 轮密钥：32个32位轮密钥
  • 固定参数：FK和CK常量

使用注意事项

  1. 内存管理 - 嵌入式环境需注意内存分配和释放
  2. 随机数生成 - SM2需要可靠的随机数源
  3. 性能优化 - 根据具体STM32型号调整算法实现
  4. 安全性 - 确保密钥的安全存储和管理

测试验证

提供测试函数验证算法正确性：

  • SM2加解密测试
  • SM3哈希计算测试
  • SM4加解密测试

总结

本文提供了在STM32平台上实现国密算法的完整方案，包括SM2、SM3、SM4的C语言实现代码。这些实现经过优化，适合嵌入式环境使用，可直接集成到STM32项目中。

代码中可能存在未测试到的边界情况，欢迎在实际使用中发现并反馈问题，共同完善这些实现。

0%