本文主要从实际工程开发入手，从多个细节角度记录 Xilinx 在淘汰基于 Eclipse/Java 的 Vitis Classic 后推出的基于 Eclipse Theia 的全新 IDE 的开发流程。

基本概念

Vitis 有几个关键地概念需要了解，以便于对整个开发流程有一个深入的认识。

• Platform（平台）
  • 目标平台（或称平台）是由硬件组件（XSA）和软件组件（域/BSP、FSBL 之类的启动组件等）组合而成。存储库内的平台不可编辑。工作空间内的平台可编辑，称为平台组件。
• System Project（系统工程）
  • 同时运行的一个或多个 Application。若只有一个 Application 时，系统工程不是必须的。
• Domain（域）
  • 域即板级支持包（BSP）或操作系统（OS），其中包含软件驱动程序集合，可在其中构建自己的应用。
• Application（应用程序）
  • 即在 PS 端处理器上运行的软件，最终编译和生成二进制输出文件（ELF）。

Platform 和 Application；Vitis 将硬件平台与应用程序工程分隔开，可方便地将不同的硬件平台与应用程序工程组合而无需对各组合创建各自独立的工程，以尽可能地减少冗杂的开发流程。

从 Vivado 导出硬件并创建 Vitis 软件项目

导出硬件并创建 Platform

Extensible Vitis Platform -> File/Export Platform
不使用该选项，否则会在 Vitis/Flow 中找不到 Run/Debug 的功能。
（因为 Extensible Vitis Platform 不会自动创建包含 Run/Debug 命令的 launch.json 配置文件）

Extensible Vitis Platform (Deselected) -> File/Export Hardware
导出硬件描述文件 xsa，用于在 Vitis 中创建 Platform 时定义硬件细节使用

创建 Platform 时步骤包含 Domain 的自动创建，根据需要选择 standalone/freertos/linux 以及绑定的内核。

创建 Application

一般使用 Template 来扩展，方便项目框架的快速搭建。

注意：部分 Template 需要特殊的 3rd-party 库（例如 lwip），需要在 Domain 下的 Board Support Package 中找到并启用对应库、根据 Template 的需要配置后，Regenerate BSP 并在 Flow 中 Build Platform 后再从 Template 页面中创建 Application:

更新与切换 Platform

若在 Vivado 端对 PL 的硬件部分做过修改，需重新综合实现生成 bitstream 并导出硬件至 xsa 文件后，重新加载 xsa 文件到 Platform：

另外，Vitis 支持方便地对 Platform 进行切换。
例如你想在多个支持同一套固件地不同 Platform 间进行测试，可在 Application Component Settings 下进行 Platform 地切换。

注意:

1. 给 Application 切换 Platform 时，由于没有经过从 Template 创建 Application 的流程，因此不会进行 BSP 依赖的检查，所以需要手动保证 Template 的依赖库以及配置的正确性。
2. 若切换 Platform 后没有生效，可以尝试 重启 Vitis 大法（
3. 最近及附近版本（2025.1）在导出时建议使用同一个 xsa 文件名称（可以选择备份原 xsa 文件后覆盖导出），因为 Vitis 目前有一个切换不同名称 xsa 时自动从仓库中删除平台的 bug，而且还添加不上，非常浪费时间

CMake 集成

Vitis CMake 项目集成的逻辑是：IDE 负责维护 UserConfig.cmake 文件，这个文件主要是以 UI 界面的形式辅助生成一堆以 USER_ 开头的用户定义变量和编译与链接器参数，常用的例如 USER_COMPILE_DEFINITIONS USER_INCLUDE_DIRECTORIES 和 USER_COMPILE_SOURCES，以及添加库常用的 -l 参数：

这些变量最后都由 CMakeLists.txt 文件读取并应用在编译和链接上。
每次新建源文件后都需要手动添加文件到这些变量中略显麻烦，可以在 CMakeLists.txt 中添加 aux_source_directory 指令来批量添加同一路径下的所有源文件；例如若需将 main.c 同一路径下的所有源文件添加到 sources 中，可把

list (APPEND _sources ${USER_COMPILE_SOURCES})

改为

aux_source_directory(. DIR_SRCS)
list (APPEND _sources ${USER_COMPILE_SOURCES} ${DIR_SRCS})

即可。

P.S. 不要在 UserConfig.cmake 文件中实现，每次从 Vitis 中删除源文件时这个文件会自动更新并把更改覆盖掉。

编译

默认情况下，在 Flow 下点击 Build 进行编译时会弹出对话框确认是否在编译 Application 前自动编译 Platform BSP。建议选择手动分别编译（因为 Platform BSP 没有更改时也会 Clean build dir 然后重新进行编译，着实浪费时间）。
如果想在之后更改这项配置，可通过 ctrl+, 快捷键打开设置，找到 Vitis/Application - Platform Build Dependency：

P.S. 项目的路径名称不能过长，否则编译时 obj 文件不能正确地生成；下面是一个实际的例子：

CMake Warning in libsrc/freertos10_xilinx/src/CMakeLists.txt:
   The object file directory
     C:/Users/usrlibzy/Documents/Xilinx/ModSpotFlow/ModSpotFlow.vitis_test/TestHardware/ps7_cortexa9_0/freertos_ps7_cortexa9_0/bsp/libsrc/build_configs/gen_bsp/libsrc/freertos10_xilinx/src/CMakeFiles/freertos.dir/./
   has 210 characters.  The maximum full path to an object file is 250
   characters (see CMAKE_OBJECT_PATH_MAX).  Object file
     Source/portable/GCC/ARM_CA9/portASM.S.obj
   cannot be safely placed under this directory.  The build may not work
   correctly.

由于上述 obj 文件没有正确生成，在构建 BSP 时便会失败：

[ERROR] C:/Users/usrlibzy/Documents/Xilinx/ModSpotFlow/ModSpotFlow.vitis_test/TestHardware/ps7_cortexa9_0/freertos_ps7_cortexa9_0/bsp/libsrc/freertos10_xilinx/src/Source/portable/GCC/ARM_CA9/port_asm_vectors.S:144: fatal error: opening dependency file libsrc\freertos10_xilinx\src\CMakeFiles\freertos.dir\Source\portable\GCC\ARM_CA9\port_asm_vectors.S.obj.d: No such file or directory

Warning 中也给了提示，给环境变量 CMAKE_OBJECT_PATH_MAX 赋个更高的值。或者参考 这个回答 将 Windows API 的 MAX-PATH 限制设置更大一些。
不用浪费时间咯，实际测试检验上述方法根本没用（至少对 CMake.exe 是无效的）。

最终我使用系统自带的 虚拟驱动器映射 功能（subst 命令）来规避这个问题。
例如，使用下面这个命令将整个 Xilinx 工程映射至一个虚拟驱动器上：

subst W: C:\Users\usrlibzy\Documents\Xilinx\VirtualSource\

然后重新使用 Vitis 打开其中的 Workspace C:\Users\usrlibzy\Documents\Xilinx\VirtualSource\VirtualSource.vitis，现在映射到虚拟驱动器路径则是 W:\VirtualSource.vitis。
注意不要直接映射 Vitis 项目所在的文件夹，Vitis Unfied IDE 不能直接打开根目录作为 Workspace。
后续如果需要移除这个虚拟驱动器，可以使用 subst /d W: 命令实现。

程序下载与PS/PL联合调试

默认情况下，Application 配置的 launch.json 只是配置了 PS 端程序（.elf）的下载以及处理器的复位。若需要进行 PS 与 PL 的联调，可编辑该配置文件，手动添加最新硬件的 bitstream 文件，然后勾选 Program Device 即可：

配置界面的最下方贴心地提示了这个 launch 配置的运行流程。大致概括如下：

1. 复位整个系统，清除 PL 端逻辑
2. 使用配置的 bitstream 文件来编程 PL 端逻辑
3. 加载并运行 ps7_init tcl 脚本来复位 PS 处理器
4. 加载配置的 elf 文件到 PS 处理器并运行

注意检查用于初始化 ps 的 tcl 脚本应为 ps7_init.tcl；当工程中存在 IP 核时，Vitis 会选错为 IP 核中的脚本。

如果在 PL 端添加了 ILA 来观察波形，可运行上述的 launch 流程配置好 PS/PL 后，再回到 Vivado 打开 Hardware Manager/Logic Analyzer 来访问 ILA。

参考

1. Xilinx 官方文档 UG1400
2. How can I use ILA if I program my board with Vitis?

本篇继续来记录 k3s 集群的基础设施维护。
接 上篇文章 完成了对宿舍设施的升级后，准备集中解决下几个痛点；总结起来就是（还是）网络问题。

集群网络问题

域控制器 与 主/从 DNS

DNS 作为集群中的基础，其稳定性保证各项服务的质量，因此需要一个良好易实施与维护的方案。

在这之前，我所有的域名都在 Cloudflare 上配置解析，其中也包括内网中的部分。在实际使用时就会发现这是不太方便的做法：将内网的服务地址往外暴露不仅配置麻烦，而且没有必要（暂且不说明安全方面也会有一定的隐患）。
因为现在有了 NAS，为了方便 SMB 共享的用户验证，我搭建了 Windows Server 用做 Active Directory 服务器的同时，发现域控本身就是在 DNS 基础上实现的，于是就顺便将域控的 DNS 用作集群的内部 DNS。当然也可以不使用 Windows Server 的 DNS 实现，而选择广泛使用的 bind9 作为替代；具体的做法就不在这里展开了。（熟悉嘛，直接抄的上篇文章😝）

首先打开 DNS 管理器，将要配置为次级 DNS 的服务器解析记录（A/AAAA）添加到主 DNS 上，然后右键正向查找区域中的区域名称（例如我的域名为 plam.toay.io），在属性中的名称服务器选项卡中添加上次级 DNS 即可：

然后在 区域传送 选项卡中允许向次级 DNS 服务器传送解析的副本：

接着在将要用做次级 DNS 的 Linux 服务器上安装 Bind9：

apt install bind9 bind9utils bind9-doc

编辑配置文件 /etc/bind/named.conf.options；先在 options 块中配置 listen-on 指定监听的 host：

options {
    //...

    listen-on {
        100.120.4.9;
    };
}

后在文件末尾添加区域配置：

zone "plam.toay.io" { // Zone Domain
    type slave;
    masters {
        100.120.32.67; // primary dns 1
        100.120.32.68; // primary dns 2
    };
    allow-query { any; };
    allow-notify {
        100.120.32.67; // primary dns 1
        100.120.32.68; // primary dns 2
    };
    notify no;
    file "/var/lib/bind/slaves/plam.toay.io.hosts"; // slave hosts file
};

systemctl restart bind9 重启 bind9 服务，就可以在日志中找到 zone transfer 的记录了。这时可使用 nslookup 尝试一下能否正常解析区域内的名称。

P.S. 1: 此时你可能会发现只有区域内的名称可以解析，因为目前的操作仅配置了 bind9 作为次级 DNS。如果要让它解析区域外的名称，还要额外配置转发。
在同一个配置文件中的 options 块里添加转发器：

options {
    //...

    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
    recursion yes;
    allow-recursion { any; };
    allow-query { any; };
}

转发作为默认配置，在具有显式配置的区域中不会生效，因此不会影响次级 DNS 的正常解析。

P.S. 2: 这里有一个小提示：当你在使用 Tailscale 的 exit-node 时，DNS 的解析是在 出口节点 上进行的。因此若使用 exit-node 的机器出现域名解析异常，可考虑从出口节点开始问题的排查。

如果你在 Tailscale 控制台中配置了下面的 DNS 自动分流的功能，这个问题可能就不会出现：

Tailscale 的客户端会在解析域名时自动将属于内网的部分发送至你配置的内网 DNS 上进行解析（因此叫做 Split DNS），你不再需要为要访问内网服务的设备手动配置内网 DNS 了。

P.S. 3: 最后一个建议，对于大陆部署的服务器应当将域控 DNS 的上级配置为 可信 DNS （例如自建 DNS）上，避免部分机器没能使用到 Tailscale DNS 时遇到的域名污染问题。
当然，这个配置也是非常简单的啦：

PVE - Intel 网卡 大流量假死问题

PVE 总的来说非常稳定，之前的 PN61 连续 7*24 运行四五个月没有丝毫一点问题。
但是在最近更新最新系统后，在遇到大流量情况时会出现 intel 网卡假死的现象，具体来说就是物理机的网络完全断开，将网线拔下重插后立刻恢复；在 PVE 系统日志中可以找到以下的记录：

Jun 18 14:58:08 cubelets.plam.toay kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
  TDH                  <1d>
  TDT                  <7a>
  next_to_use          <7a>
  next_to_clean        <1d>
buffer_info[next_to_clean]:
  time_stamp           <1326d01db>
  next_to_watch        <1e>
  jiffies              <138cb45c0>
  next_to_watch.status <0>
MAC Status             <40080083>
PHY Status             <796d>
PHY 1000BASE-T Status  <3c00>
PHY Extended Status    <3000>
PCI Status             <10>

网上搜了下，在 PVE 的官方论坛上找到了 解决方法：关闭 ~~rx/tx checksumming~~
这个方法在生效一段时间后，

先使用 ethtool -k eno1 命令审查开启的选项，可以使用 grep 查找 checksumming 相关的配置：

 ~  ethtool -k eno1
Features for eno1:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]

...

确认开启了校验后，可以使用下面的命令来关闭校验：

~ ethtool -K eno1 tx off rx off
Actual changes:
tx-checksum-ip-generic: off
tx-tcp-segmentation: off [not requested]
tx-tcp6-segmentation: off [not requested]
rx-checksum: off

配置是立刻生效的，在这之后便不会在大流量时挂机了。然而配置在重启后会失效，因此需要额外的配置以在启动时应用。

根据官方论坛上 另一条帖子 的记录，可以编辑 /etc/network/interfaces 文件，在 iface eno1 inet manual 后添加一条 post up 命令 post-up /sbin/ethtool -K eno1 tx off rx off 即可。

参考链接

1. https://www.reddit.com/r/sysadmin/comments/pls8zf/is_it_possible_to_connect_a_linux_bind_dns_server/
2. https://vswitchzero.com/2021/02/24/linux-and-bind9-as-a-dns-secondary-for-active-directory/

从去年夏天开始，寝室里一直运行着一台 华硕 pn61s 小主机，上面用 PVE 作为 Hypervisor 跑着几个虚拟机。
这个机器是由在京东二手买的带 八代移动端 i5 的准系统，外加闲鱼入的低价 16g*2 ddr4、拆机西数黑盘 500g hdd 和一块西数蓝盘 1t m2 组成的。特点就是非常小巧，115mm x 115mm x 49mm 的体积在哪都能找个地方容纳。这里还有 刚到手时的记录，那时是挺高兴的（算是当时用过的最高的配置的服务器了，能不高兴嘛）。后面由于气温越来越高，于是去淘宝找了个散热支架将它包围起来，就像这样。

pn61s 的主要用途是跑从云上搬下来的自建 GitLab（那就是 git.toay 啦，话说 Java 真得巨占内存，憋再继续浪费我资源呐），以及用做 k3s 跨云集群的一个 control plane 节点，顺便还可以用 Pydio 搭个简易的 WebDAV 网盘利用一下剩余的硬盘空间。

在除了供电故障外稳定运行一年多得时间后，pn61s 却在上个月中旬的一次寝室停电后突然就罢工了。
于是出差时得空闲时间就在调研，打算搞台算力强些的 桌面级 u 小主机用做主力服务器。最后在闲鱼上收了一台 ThinkStation P340 Tiny 准系统，然后去淘宝买了块散片，以及到京东把内存拉满。
将从 pn61s 上取下的固态直接装上并一次性点亮后，要不干脆就直接升级成数据中心吧， 抱着 一步到位能用服役年限拉低平均成本 的心态顺便搞了台 MikroTik RB5009UG，一台 TerraMaster D5 Hybrid 硬盘柜 和一块 8T 的酷狼 3.5 SATA。。。
最后趁 618 打折再准备了一台 APC BK650 UPS，避免寝室突然断电硬关机造成的硬盘与数据丢失问题，以及一个 100 出头就能入手的机柜，然后就把所有的设备整理在角落里了：

P.S.1 看得出来我非常喜欢联想的工业设计。除了完全贴合我审美的简约外观外，p340 tiny 的散热效果真的逆天。刚开始在等待机架时放在桌边测试了几天，一米外基本上听不见一点声音；而在虚拟机开满的情况下能听到的声音很低沉，像是呼吸一般，根本谈不上是“噪声”。放在一起对比之下，pn61s 不加外部散热时不仅有个频率更高些、明显给人带来厌烦感的噪声，严重的积热使我怀疑它是否能承受长时间的开机。

P.S.2 pn61s 现在已经复工了，大概只是纽扣电池没电导致断电后 BIOS 配置丢失+内存重新 training，同时华硕默认的 Windows 安全启动不能正常地拉起 GRUB 进行 PVE 的引导，但在当时几次三番长达十几分钟的黑屏后掉电的经历让我误以为低价的自组装内存已经准备就此退役le ^_^"）

那就组成集群吧！

配置与组成

简单整理一下，现在集群的配置大概是这样的：

上面的大概就是一个 All in One 的组合，去年的 pn61s 就不算在这里面了。

话说硬盘真贵啊，硬盘柜和硬盘加起来基本上就是 p340 无盘系统的价格了，况且我小主机所有配件选的还是成色非常好的。。。
但怎么说呢我觉得还是挺值得的：首先是有了相机后对存储的要求突增了许多；另外科研上的各种资料项目工程文件越来越多，除了网盘外还是得有一个离线的备份方案。

基础设施

画了张图，能够清楚地描述整个小 dc 的组成；其他只是与 dc 相关而并不隶属的部分我就简单概括一下咯：（话说 draw.io 挺好用的）

其中部分系统服务的编排，我认为是能保证集群稳定运行的比较好的实践，接下来我简要地说明下，供大家参考。

PVE

即 Proxmox Virtual Environment，是在 Debian 的下游开发的虚拟化平台。PVE 的好处是非常稳定，24*7 连续运行时基本上宿主系统不会出现什么大问题，非常可靠。相比另一个常用的虚拟化平台 VMWare ESXi 更多的驱动和更完善的折腾记录和参考。自带的集群管理功能可以很方便地集中管理，或者在 host 之间迁移数据，而其它各项功能就跟 VMWare Workstation 在 Windows 上的操作一样（或者说虚拟化平台之间的功能都差不太多），就不再具体说明了。

DNS

DNS 作为集群网络中的基础设施，其稳定性保证几乎所有服务的质量，因此需要一个良好易实施与维护的方案。

在这之前，我所有的域名都在 Cloudflare 上配置解析，其中也包括内网中的部分。在实际使用时就会发现这是不太方便的做法：将内网的服务地址往外暴露不仅配置麻烦，而且没有必要（暂且不说明安全方面也会有一定的隐患）。
因为现在有了 NAS，为了方便 SMB 共享的用户验证，我搭建了 Windows Server 用做 Active Directory 服务器的同时，发现域控本身就是在 DNS 基础上实现的，于是就顺便将域控的 DNS 用作集群的内部 DNS。当然你也可以不使用 Windows Server 的 DNS 实现，而选择广泛使用的 bind9 作为替代。

使用 Windows Server 在同一个域中搭建多个 DNS 服务器时域配置会自动同步，因此可以轻松地实现高可用。
对于 DNS 这种需要保证稳定性的服务，建议再搭建几个次级 DNS 放在公网的云服务器上（但只开放内网访问）。bind9 能够很方便的完成次级 DNS 的配置，将域中的主 DNS 记录完整地同步过来。

待 DNS 部署完成后，可在 Tailscale 控制台中开启 Split DNS 功能，Tailscale 的客户端会在解析域名时自动将属于内网的部分发送至你配置的内网 DNS 上进行解析：

这算是 Tailscale 一大便利功能，因为配置完成之后，你不再需要为要访问内网服务的设备手动配置内网 DNS 了。

网络代理

集群中的代理主要分为两种：一种是给集群中所有的机器进行镜像拉取、软件包脚本下载等使用的内部代理，配置 http proxy 即可；另一种是给自己的设备使用的外部代理，具体的角色设定为旁路由。

在 之前的文章 有介绍过我解决大陆服务器网络问题的策略：不使用 Tailscale exit-node，而是在多个外网节点搭建简单的 http-proxy （http proxy over wireguard ¿） 后通过 openwrt+openclash 中继的方式实现 failover/load balancing。

流量入口与负载均衡

如架构图所示，虽然所有的虚拟机都通过网桥直接连接在路由器上，但访问应用程序的流量均通过固定的 Load Balancer 进入。

这样做的好处是很明显的：

1. 不会再出现 main-server:9100, sidecar:9090, nas:8080 之类乱七八糟的访问地址，转而由 prometheus.plam.toay.io, insight.plam.toay.io, cells.attic.plam.toay.io 替代并开启 https，让自己看起来更像是 Saas 提供商。😝
2. 统一管理所有的域名和证书；这一点通过 通配符解析 和 acme.sh 就可以完美实现。
3. 仅将服务通过指定的一两台机器暴露出去，大大减少可能的安全问题。访问日志、流量统计、WAF、统一缓存什么的很轻松就能部署。
4. 负载均衡，特别是对于使用 k3s 部署的微服务，load balancing+traefik ingress+动态缩扩容非常方便。

这个任务 Nginx 可以轻松承担。
另外，若想把服务暴露给公网，可以再在带宽稍高点的云服务器上部署一个 Nginx 来负责外网流量的导入，就像我在 git.toay.io 上做的那样。

状态监测

状态监测（包括 Metrics 和 Logging）是维护集群稳定的必要方式以及出现问题后排查与解决的参考来源。

• Grafana: 可视化 Web 应用
• Prometheus: 从 *_exporter 采集指标数据
• Loki: 日志数据采集
• *_exporter: 指标数据收集与统一 expose
• promtail: 收集与提交日志数据至 Loki

这里推荐一个用于 MikroTik 设备数据与日志收集的工具 mktxp，可收集各种运行时产生的数据用于分析：

UPS

对于寝室这种可能会突然断电的环境，如果你想让你的设备在役时间更长久一些，UPS 可以说是必须准备的物件了。
APC 的 UPS 貌似全平台都有各种官方的/开源的上位机控制软件的支持；在 Linux 下官方的上位机守护程序 apcupsd 直接用 apt 安装即可。

虽然 BK650 通过 USB 仅直接连接到一台物理机上，但是这台机器上运行的 apcupsd 可以开启一个 Network Information Server 作为 Master 给其他主机的 apcupsd 作为 Slave 来使用，可以实现 UPS 在电量即将耗尽之前将所有的物理机关机，那就非常方便了。

k3s+rancher

k3s 用于除了 NAS 相关、以及部分重要的基础设施之外服务的编排，部署在云服务器上的 Rancher 则作为远程可视化管理工具，可以方便的跟自动化工具联合。

虽然这个集群主要是为 k3s 构建的，但是我的博客已经花了不少篇幅介绍他们，这里也不再赘述了；更多内容可以通过下面的专栏链接来了解。

基础设施的介绍差不多就到这了；这里只是简要地介绍我的方案。如果想要了解更详细的部署步骤和实际遇到问题的细节说明，可以移步专栏 k3s 集群维护笔记。接下来就介绍下我部署的各种有意思的服务啦。😊

各种有意思的服务

目前两个小主机上加起来跑了十个左右的虚拟机，主要是软路由、反向代理、k3s 集群节点、NAS、Linux 开发环境，以及用于远程桌面、做域控和 DNS 的 Windows Server。

Git.Toay

Git.Toay 应该是 PlamNet 中寿命最长的一项了，也是截止目前使用的最多的一项；我将我绝大多数暂不公开的项目存在其中，有时也会从 GitHub 上 clone 一些有意思的项目下来做存档。GitLab 自带 CI/CD 工具和容器镜像库功能，现在也在探索中，之后会将其与 Rancher 集成，尝试构建部署全流程的自动化。

为了保证数据安全（针对于数据丢失的风险），特别为它启用了完善的备份措施：每天凌晨由 GitLab 自动创建备份到 p340 tiny 内置 sata 机械盘中，然后每周从机械盘增量备份至 NAS 中。
现在打算整理一下 Dropbox，按重要性筛选将较低的大文件下载到 NAS 中，然后在 NAS 中部署 rclone，每周将备份文件夹中的资料推到 Dropbox 备份；大概是我能/需要做到的备份计划之极限了吧？

NAS

对于 NAS 的实现，我的方案是：系统方面选择使用 OpenZFS 文件系统的 TrueNAS，并将硬盘盒直通到 TrueNAS 虚拟机中。

虚拟机里运行的服务主要有以下几类：

1. SMB 服务器
2. 作为网盘使用的 Pydio / Nextcloud
3. 作为文件同步备份用的 Resilio Sync / Syncthing
4. 作为网络相册的 Photoprism
5. 作为辅助工具/基础设施的 n8n/nginx proxy manager

Gallery.Attic

网络相册是我认为购买硬盘/硬盘盒凑 NAS 后效益最大的一项功能。在之前，我整理照片的流程是在工作站上直接使用 Lightroom CC 导入 SD 卡内的照片到存在移动硬盘里的库中。由于我习惯拍照时都是自动保存 DNG 原片，因此每个快门都会产生一百多兆的数据；时间一长，我的 1T 小移动硬盘就招架不住了。

而现在，我的流程转为：将相机连接到小主机后，通过 Windows Server 远程桌面使用 Lightroom CC 将 DNG 原片导入到 TrueNAS 的 SMB 网络驱动器中，而只是保存预览和修改描述文件的库则通过 Resilio Sync 进行几大设备间的同步。另外，照片保存到 NAS 中的同时，Photoprism 也会自动导入并生成索引以供快速搜索与查看。因此我可以在空闲的时候将 Gallery.Attic 打开，将自认为尚可的照片挑选出来，一并导出到博客中来，而不是就尘封在移动硬盘中，直到自己都忘记曾拍过什么照片。

SMB 服务器

除此之外，SMB 服务器实现了“无线大容量硬盘”的功能。
备份数据什么的就不用说了，将其挂在到 Windows Server 上还可以用来 24h 挂机下载。下载完成后不需要拷贝到电脑上观看，能轻松跑满千兆的网络可以直接使用流传输；这个算是附带效益吧。

iSCSI/NFS 服务器

NAS 能提供的最高级的服务可能就是 为 k3s 集群提供存储支撑 了。有了 iSCSI/NFS 这两种 k3s/rancher 原生支持的选项，可以完美地实现 compute 与 storage 资源的分离，体验私有云效果的同时还能将资源分配利用率最大化。（简单举个例子，将价格低稳定性较差些但还有使用价值的硬盘用于虚拟机启动盘的存储，就算挂掉后数据仍在 NAS 中，换块差不多的硬盘用模板重新启动就可以了）

由于之前 k3s 的存储一直使用的 bind-mount，这种存储方式现在还在探索中。在我实践出经验后将会把经历记录在 k3s 维护 专栏中。

Bonus

感谢看到最后 (｡•ᴗ-)_
既然看起来已经像模像样了，要不简单地回顾一下折腾史吧。

最早从线上（云服务器）折腾到线上线下双管齐下时当回溯到高一的暑假了。其实这么多年过去了博客上还保留着那时的记录。 当初的想法和现在也相差无几（要不把 06 年的 惠普畅游人 拿来搭个家庭媒体系统吧，大概），而在 17 年时 家用 NAS 应该是非常小众的。后来因为维护麻烦、噪声高利用率低等诸多原因，再加上长期不在家回校后根本用不上只得关机，于是断断续续累计运行总时不到一年就没再使用了。现在回想起来，Linux 的入门实践大概都是在那台古董上进行的。

后来接触到树莓派这种单板机，在宿舍角落挂几个 Home Assistant/OpenClash/Mqtt 容器什么的，顺便用 GPIO 与串口控制用单片机做成的不带任何界面的“隐形门锁”，就这么玩到本科毕业。然而在去年，在价格媲美 x86 而性能堪比 riscv 的 raspberry pi 5 出现后，我大概是放弃树莓派了，等几年后知识储备到位时会研究下自己的 Arm 板子。

弃坑之后，本文的内容便开始了。

GitHub 上可以搜到一些移植完成的项目，基本上都是 v2 版本，极少数的 ORB-SLAM3 使用的都是 v0.x rc 版本。而且就算这样也都没有一个移植过程的记录，展示下 进行摄像头在线联调 的结果。是没调出来嘛还是不愿意分享呢，这我就不知道了🙁。

考虑到项目有稳定与安全性方面的要求，我最终选择 ORB-SLAM3 使用最新版本、所有依赖库均使用官方 Release 的方式来构建项目。构建完成的项目会放到 GitHub 上，但还是建议过一遍本文的流程，了解移植时在什么地方做了什么修改有什么坑，触类旁通的同时还能便于以后在 ORB-SLAM3 库更新版本时及时跟上。

移植前准备

工具链

构建工具链大版本一致就不会有什么问题，但我还是把我的版本放在这里：

• CMake v3.31.4
• MSVC 2022 v14.43.34808 on Windows 11

依赖库与驱动

ORB-SLAM3 有着众多的依赖包。除了 Repo 里 Thirdparty 文件夹中自带的魔改过的 DBoW2、g2o 和 Sophus 外，其它的均需要手动下载编译。这里先列个清单，附上我在编译时实际使用的参考版本及下载地址：

• ORB-SLAM3 v1.0
• OpenCV v4.10.0
• boost v1.87.0
• eigen v3.4.0
• Pangolin v0.6
• Win64OpenSSL v3.4.1 x64
• OpenNI2 v1.02.2.0.33 Beta x64

示例数据集

由于我使用的是 Orbbec Astra 2，这是一个奥比中光推出的 带 IMU 的单目结构光深度相机，因此选择的示例数据为 RGB-D 类型。
这是 RGB-D 数据集下载地址：cvg.cit.tum.de/data/datasets/rgbd-dataset/download。由于 ORB-SLAM3 Repo 中的 Examples 文件夹自带有 associations 文件（关联 RGB 与 Depth 图片的 txt 文件），因此不用再下载 associate.py 脚本来生成。

其它类型（单目、双目等）可在这篇知乎专栏中找到：https://zhuanlan.zhihu.com/p/625605417。

ORB-SLAM3 库 构建流程

unistd.h

unistd.h 文件在 Unix 类系统中的作用类似于 Windows 中的 Windows.h 文件。从 Linux 移植到 Windows 平台的程序大多需要手动创建一个，避免编译时出现 无法打开源文件 的错误。

在 msvc include 文件夹（...\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.43.34808\include）中添加一个 unistd.h 文件：

/** This file is part of the Mingw32 package.
unistd.h maps (roughly) to io.h
*/
#ifndef _UNISTD_H
#define _UNISTD_H
#include <io.h>
#include <process.h>
#endif /* _UNISTD_H */

注意⚠️：文件末尾需留有一行空行，否则编译时会报 Unexpected end of file 错误。

P.S. MSVC 工具链升级更新后 Visual Studio 会在原版本工具链的文件夹下保留该文件，需要手动移动至新版本工具链的 include 目录中。

OpenCV 安装

直接下载后解压安装到 Thirdparty 子文件夹即可。

• OpenCV_DIR 目录为 .\build

Win32OpenSSL 安装

ORB-SLAM3 使用到了 md5 相关函数。如果缺少该库，在其编译时会出现 无法打开包括文件: “openssl/md5.h”: No such file or directory 的错误。

直接下载后安装到 C:\Program Files 即可。

• include 目录为 .\include
• lib 目录为 .\lib\VC\x64\MT

OpenNI2 安装

OpenNI2 是 Pangolin 和 ORB-SLAM3 的依赖，因其包含驱动，故直接下载安装到 C:\Program Files 即可。

Boost 编译

v1.87.0 版本的 Boost 可直接双击 bootstrap.bat 脚本即可生成 Boost 专用的构建工具 b2.exe（Boost-Build）。
然后使用下面的命令来生成 debug/release 版本的动态与静态库：

.\b2.exe stage --stagedir=".\stage" link=static runtime-link=shared runtime-link=static threading=multi debug release

• Boost_DIR 目录为 .\stage\lib

若在链接时不能指定正确的链接库，则会在构建 ORB-SLAM3 和 Demo 时报大量的未定义符号错误；因此这里要介绍一下 Boost 编译得到的链接库命名规则：

libboost_serialization-vc143-mt-sgd-x64-1_87.lib
---  b   -------------   d   --  f  ---  h
 a -----       c       ----- e  ---  g  ----

• a: 静态库以 lib 开头，动态库则无此前缀
• b: boost 库前缀
• c: 库子类名，serialization 库
• d: 编译器版本，visual c++ 14.3
• e: mt=multi-threaded，单线程则没有此段；可使用 BOOST_LIB_THREAD_OP 参数指定
• f: s=static 静态链接，gd=debug 构建类型为调试； 可使用 BOOST_LIB_RT_OPT 参数指定
• g: 平台架构名 x86；可使用 BOOST_LIB_ARCH_AND_MODEL_OPT 参数指定
• h: Boost 版本 v1.87；可使用 BOOST_LIB_VERSION 参数指定

DBoW2 编译

从这个依赖开始，下面的都需要使用 CMake GUI 来进行项目的生成和编译了。
步骤大致都相同，这里先详细列出，后面基本相同的地方便不再赘述：

1. 在待编译项目的根目录下创建一个 build 文件夹
2. 打开 CMake GUI，Where is the source code 填写 CMakeLists.txt 所在位置（都是根目录），Where to build the binaries 填写刚创建的 build 文件夹位置
3. 点击 Configure 后，在弹出的对话框中选择使用的 MSVC 编译器版本，多次点击 Configure 和填写 CMakeLists 中空缺的变量值（大多都是类似 OpenCV / Boost 等依赖库所在的位置），DBoW2 需要填写 OpenCV CMake 文件所在路径：

4. 填写完依赖路径之后，填写 CMAKE_INSTALL_PREFIX 为 .\build\install，以避免部分未指定输出路径变量的库直接将构建产物安装在系统路径 program files 下而混淆可能存在的其它版本：

6. 再次点击 Configure 确认不再有错误后，点击 Generate 以检查并生成项目。若在生成时出现 Invalid escape sequence \U 的错误，可将路径中的反斜杠替换为斜杠，例如：C:\ => C:/
7. 成功生成项目后点击 Open Project 以在 Visual Studio 中打开
8. 根据需要的构建类型，更改顶部菜单栏选择为 Debug/Release（建议一次性地将 Debug/Release 版本的 静态/动态链接库 构建好）
9. 右键项目名(DBoW2)->属性->VC++目录 添加需要的依赖项：

• 包含目录：添加依赖项的 include 路径；如 DBoW2 需要添加 boost 库的 include 路径为 ..\..\..\Thirdparty\boost;
• 库目录：添加依赖项的 lib 路径；如 DBoW2 需要添加 boost 库的 lib 路径为 ..\..\..\Thirdparty\boost\stage\lib;

10. 由于 除了 ORB-SLAM3 本体外 编译的几个依赖库库都使用 静态链接 的方式生成（Linux GCC 移植到 Windows MSVC 时绝大部分库缺少 动态链接库导出符号需要的显式声明，后编译 ORB-SLAM3 时有详细介绍），因此需要在项目属性中配置：

• 常规->配置类型 选择 静态库(.lib)
• 高级->目标文件扩展名 更改为 .lib
• 根据需要选择 MSVC 运行库版本为 静态链接（MT/MTd） 或 动态链接 （MD/MDd），整个项目 需保持一致；C/C++->代码生成->运行库 若构建类型为 Debug 则选择 多线程调试(/MTd) 或 多线程调试 DLL(/MDd)，若为 Release 则选择 多线程(/MT) 或 多线程 DLL(/MD)

10. 右键 ALL_BUILD->生成

需要填写的 CMake 变量值：

• OpenCV_DIR: C:\Users\usrlibzy\Documents\Visual Studio 2022\Projects\ORB_SLAM3\Thirdparty\opencv\build

由于是使用 MSVC 编译，gcc 标准库中的 stdint-gcc.h 头文件自然是找不到的，但由于里面的类型由 MSVC 的其它头文件定义过，因此可以直接注释掉 Thirdparty\DBoW2\DBoW2\FORB.cpp 文件中的 include 引用：

//--//#include <stdint-gcc.h>

最终构建产物位于 Thirdparty\DBoW2\lib。

Eigen3 生成

作为 g2o 的依赖的 Eigen3，其依赖 Boost 库只需在 CMake 配置时提供其 include 路径即可：

• Boost_INCLUDE_DIR: ../../boost
  然后打开工程，右键 INSTALL 生成即可。此生成只包含头文件与 CMake 文件供 g2o 编译使用，不产生实际二进制文件。

Eigen3_DIR 目录为 .\build\artifacts\share\eigen3\cmake。

g2o 编译

g2o 在使用 CMake GUI 生成项目时需配置其依赖 Eigen3 的 include 路径参数 G2O_EIGEN3_INCLUDE 为 ../eigen/build/artifacts/include/eigen3。

g2o 的 CMakeLists.txt 中警告层级 -W 参数没有值，在 gcc 下为默认打印所有警告，而 MSVC 下必须显示赋值，因此手动去掉或修改为 -W1 即可；而其后的优化等级 -O3 以及平台优化 -march=native 均为 gcc/clang 特有参数，此处可直接删去以使用默认即可：

#-- Explicitly set Warning param
%(AdditionalOptions) -W1

平台优化选项 -march=native 将在下一篇文章点云地图重建中引入 PCL 库 时介绍，此处只需先不使能其对应于 MSVC 的替代，即项目属性->C/C++->代码生成->启用增强指令集 高级矢量扩展2 /arch:AVX2。

项目中有以下几个文件的 unordered_map 和 shared_ptr 使用的还是 较高版本编译器已移除的 std::tr1 命名空间，可以选择手动将 std::tr1::unordered_map 和 std::tr1::shared_ptr 分别替换为 std::unordered_map 和 std::shared_ptr：

• core/hyper_graph.h
• core/estimate_propagator.h
• core/marginal_covariance_cholesky.h
• core/robust_kernel.h
• core/sparse_block_matrix_ccs.h

项目属性->C/C++->预处理器->预处理器定义 中需要添加一项 WINDOWS; （等价于在所有源文件中添加 #define WINDOWS 宏定义），否则会出现 vasprintf 未定义符号 的问题。

最终构建产物位于 Thirdparty\g2o\build\Release 和 Thirdparty\g2o\build\Debug。

Pangolin 编译

Pangolin 建议严格使用 v0.6 版本（release date 与 ORB-SLAM3 v1.0 最近）。

Pangolin 在使用 CMake GUI 生成项目时需配置其依赖 Eigen3 的 include 路径参数 EIGEN_INCLUDE_DIR 为 C:/.../Thirdparty/eigen/build/artifacts/include/eigen3。
注意：Pangolin 的 EIGEN_INCLUDE_DIR 与 CMAKE_INSTALL_PREFIX 参数均需使用绝对路径。

Pangolin v0.6 存在一个 已知问题 #609，在编译过程中会出现大量类似于 没有可用于扩展的参数包、使用类模板需要模板参数列表 的错误。
解决方法为，打开 include\mpark\variant.hpp 文件：

#if defined(__cpp_constexpr) && __cpp_constexpr >= 201304
//-- Commenting out line for Known-Issue: https://github.com/stevenlovegrove/Pangolin/issues/609#issuecomment-645653656
//--//#define MPARK_CPP14_CONSTEXPR
#endif

将中间的 define MPARK_CPP14_CONSTEXPR 行注释掉即可。
然后即可右键 ALL_BUILD->生成 以构建 Pangolin 依赖的静态库。生成结束后，可右键 INSTALL->生成 pangolin.lib。

注意⚠️：右键 INSTALL->生成 Pangolin.lib 时，生成的 Debug/Release 版本的 pangolin.lib 以及 jpeg.lib 名称相同会相互覆盖。建议先配置构建版本为 Debug，将这两个库的文件名末尾添加代表 debug 的字符 d 后，再切换为 Release 生成。最终当前目录下的所有库应该都是 Debug/Release 成对的。

最终构建产物位于 Thirdparty\Pangolin\build\artifacts。

ORB-SLAM3 编译

先对 CMakeLists.txt 进行修改。

第 #27 行，由于 MSVC 跳过 C++11 直接支持的 C++14，因此这里注释掉 FATAL_ERROR：

# Check C++11 or C++0x support
include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
if(COMPILER_SUPPORTS_CXX11)
···
#-- Commenting out for compiling with MSVC C++14 support
#--#else()
#--#   message(FATAL_ERROR "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
endif()

找到刚才 Thirdparty 中编译出的静态链接库位置，然后编辑 CMakeLists.txt 第 #221 行处的 target_link_libraries：

target_link_libraries(${PROJECT_NAME}
${OpenCV_LIBS}
${EIGEN3_LIBS}
${Pangolin_LIBRARIES}
#-- Update thirdparty dependencies static libs
${PROJECT_SOURCE_DIR}/Thirdparty/DBoW2/lib/Release/DBoW2.lib
${PROJECT_SOURCE_DIR}/Thirdparty/g2o/build/Release/g2o.lib
)

另外，由于 C++ 实现的不同以及平台更换后标准库间的差异，需要对 ORB-SLAM3 库项目 源码进行修改：

MSVC 特性：

打开 MapPoint.cc 文件，找到第 #371 行:

//-- Replacing float 2d-array with vector for MSVC not supporting dynamic-length array.
//--//float Distances[N][N];
vector<vector<float> > Distances(N, vector<float>(N));

将 float Distances[N][N]; 替换为 vector<vector<float> > Distances(N, vector<float>(N));。

以及同一个文件第 #388 行:

//--//vector<int> vDists(Distances[i],Distances[i]+N);
vector<int> vDists(Distances[i].begin(), Distances[i].end());

打开 Tracking.cc 文件，找到第 #3544 行:

    //-- Modofied to fix vector iterators incompatible. Source: https://www.cnblogs.com/jiangym1998/p/13673145.html
    // Include also some not-already-included keyframes that are neighbors to already-included keyframes
    //--// for(vector<KeyFrame*>::const_iterator itKF=mvpLocalKeyFrames.begin(), itEndKF=mvpLocalKeyFrames.end(); itKF!=itEndKF; itKF++)
    for(int i=0; i<mvpLocalKeyFrames.size(); i++)
    {
        // Limit the number of keyframes
        if(mvpLocalKeyFrames.size()>80) // 80
            break;

        //-- Modofied to fix vector iterators incompatible
        //--//KeyFrame* pKF = *itKF;
        KeyFrame* pKF = mvpLocalKeyFrames[i];

将 for(vector<KeyFrame*>::const_iterator itKF=mvpLocalKeyFrames.begin(), itEndKF=mvpLocalKeyFrames.end(); itKF!=itEndKF; itKF++) 替换为 for(int i=0; i<mvpLocalKeyFrames.size(); i++)，以及 KeyFrame* pKF = *itKF; 替换为 KeyFrame* pKF = mvpLocalKeyFrames[i];。

标准库符号缺失：
编译时会出现大量 “usleep”: 找不到标识符 的问题，可使用 StackOverflow 上一个回答中的一个 usleep 实现。
新建文件 __port.cc，添加函数定义：

void usleep(__int64 usec) 
{ 
    HANDLE timer; 
    LARGE_INTEGER ft; 

    ft.QuadPart = -(10*usec); // Convert to 100 nanosecond interval, negative value indicates relative time

    timer = CreateWaitableTimer(NULL, TRUE, NULL); 
    SetWaitableTimer(timer, &ft, 0, NULL, NULL, 0); 
    WaitForSingleObject(timer, INFINITE); 
    CloseHandle(timer); 
}

新建文件 __port.h，添加函数签名：

//-- Added usleep implementation. Source: http://stackoverflow.com/questions/5801813/c-usleep-is-obsolete-workarounds-for-windows-mingw
void usleep(__int64 usec);

然后再在下面各文件中 include __port.h：

• Viewer.cc
• Tracking.cc
• System.cc
• LocalMapping.cc
• LoopClosing.cc
• MapPoint.cc
• Atlas.cc

与前面相同的原因，需要在 ORBmatcher.cc 文件中直接注释掉 #include <stdint-gcc.h>。

项目属性->C/C++->预处理器->预处理器定义 中需要添加一项 COMPILEDWITHC11; （等价于在所有源文件中添加 #define COMPILEDWITHC11 宏定义），否则会出现 "monotonic_clock": 不是 "std::chrono" 的成员 及类似的编译期错误。
最后就可以右键 ORB_SLAM3 项目->生成。可能会看到许多的 Warning，但最终是能够构建成功的。
如果在链接时报错 无法解析的外部符号 MD5_Init 等 MD5 相关错误，则链接器未找到 OpenSSL 库，可手动添加 OpenSSL-Win64\lib\VC\x64\MT\libcrypto.lib 。

注意⚠️：ORB-SLAM3 需要编译为 与 OpenCV 同类型 的链接方式。由于 OpenCV 项目较大，静态链接出的 .lib 文件巨大，因此选择直接安装动态链接的 OpenCV 库。如果 ORB-SLAM3 在这里选择使用静态的方式来链接，能够正常运行 TUM 数据集，但 Port 到摄像头时便会出现 Debug Assertion Failed! Expression: __acrt_first_block == header 的问题：

StackOverflow 上有对此问题的详细解释，大概可以总结为：给动态链接库和静态链接库的分配的是不同的堆内存，因此可能出现 alloc 与 dealloc 并非同一堆内存 的问题。

导出符号：
由于 MSVC 对于 动态链接库的生成 需要通过 __declspec(dllexport) 声明 或使用 def 文件枚举 的方式 显式指定导出符号，才能正确生成包含这些符号的 DLL。因此还需要最后一步：将 需要在自己的项目中引用的符号（即 ORB-SLAM3 的接口） 使用宏定义的方式声明。
在上一步创建的 __port.h 文件中添加宏定义：

//-- Macro Declarations for exporting symbols
#ifdef ORB_SLAM3_BUILD
#define ORB_SLAM3_API __declspec(dllexport)
#else
#define ORB_SLAM3_API __declspec(dllimport)
#endif

然后在 System.h 文件中找到 System 类，在所有需要调用的函数前面添加 ORB_SLAM3_API，例如

ORB_SLAM3_API Sophus::SE3f TrackRGBD(const cv::Mat &im, const cv::Mat &depthmap, const double &timestamp, const vector<IMU::Point>& vImuMeas = vector<IMU::Point>(), string filename="");

最后在 项目属性->C/C++->预处理器->预处理器定义 中添加一项 ORB_SLAM3_BUILD; 即可。

最终构建产物位于 .\build\Release 和 .\build\Debug。

Demo 构建流程

最后准备编译 RGB-D Example 来验证移植结果：

1. 同样地，需要右键 rgbd_tum 项目->属性->C/C++->预处理器->预处理器定义 中添加一项 COMPILEDWITHC11;（等价于在所有源文件中添加 #define COMPILEDWITHC11 宏定义），否则会出现 "monotonic_clock": 不是 "std::chrono" 的成员 及类似的编译期错误
2. 链接器->高级->导入库 删除所有项
3. 尝试右键项目->生成，若出现找不到链接库的错误时，可再打开项目属性，在链接器->输入->附加依赖项中添加即可

P.S. 若在链接时出现 error LNK2038: 检测到“RuntimeLibrary”的不匹配项 问题时，先查看是否更改 项目属性->C/C++->代码生成->运行库 是否一致（在本例中为 多线程 /MT），然后查看 报错的动态运行时链接库所对应的静态运行时链接库是否在 链接器->输入->附加依赖项 中出现。若未出现，应手动添加。

构建完成后，可打开 Examples/RGB-D/Release 文件夹，将生成的文件连同 ORB-SLAM3 自带的 TUM1 配置文件、associations 文件夹和下载的数据集，以及 OpenCV 动态链接库 复制到单独的文件夹中，然后右键打开 Terminal，执行命令：

.\rgbd_tum.exe ..\..\Vocabularies\ORBvoc.txt ..\..\Vocabularies\ORBvoc.txt .\tum\TUM1.yaml ..\..\Datasets\rgbd_dataset_freiburg1_room\ ..\..\Datasets\associations\fr1_room.txt

等待几秒 Vocabulary 的加载后，demo 大概是能成功运行起来咯：

完全按照文章流程的步骤，是可以正常加载 Debug 符号进行调试的：

Happy debugging😛

后记

后面还会有一篇来详细记录下密集点云建图的实现
（因为搜到了几篇很有意思的论文所以）打算开一个专题，专门记录三维建图算法的学习折腾。今天先这样啦😊

一些有用的参考链接

1. github.com/UZ-SLAMLab/ORB_SLAM3/pull/53
2. github.com/lydieusang/orbslam3-windows
3. zhuanlan.zhihu.com/p/625605417
4. cnblogs.com/oloroso/p/8574936.html
5. blog.csdn.net/xp178171640/article/details/102371279
6. learn.microsoft.com/zh-cn/cpp/build/determining-which-exporting-method-to-use
7. learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport
8. cnblogs.com/jiangym1998/p/13673145.html

拥有一个能稳定运行的 k3s/k8s 集群可能并不太容易（所以这只会是一个系列中的一篇😝）。我将在这个系列中记录我爬坑的过程，既为我之后重建x，也为可能存在的读者作一定的参考。
对于文章中的内容，如果有错误，或是你有更好的方案，欢迎在文末提出。😊

网络

网络可以说是集群维护中最头痛的一件事了，特别是在大陆部署服务器时：国内服务器带宽小且贵，多数 registry、repository、api 不是太慢就是 connection reset、dns 污染。总之，部署在大陆的服务器有一个离不开的一个问题，如何让外网流量正常地进出？

之前我的方案是 使用 openwrt 作为软路由 的方式透明代理所有流量，但因为 clash 分流配置复杂存在内存泄漏需要定时重启、软路由会增加 Tailscale 直连难度等问题，最后现在选用 自建 dns + http/socks proxy via Tailscale 的方式，完美解决了长期的痛点。

DNS

目前采用的方案是在国内服务器集群内多节点部署 AdGuard-Home （一般三个就足够了，而且用着还算稳定可靠），并指向 可信上游 dns （可在大陆外再搭一台只做上游，或仅使用 doh 然后把缓存拉满，运营商的那些统统丢掉），systemd-resolved 会自动 Failover，那在每台机器上都填完整就好了。

镜像拉取/临时终端代理方案

要在 docker 拉取时应用代理，可编辑 /etc/docker/daemon.json 文件来配置：

{
  "proxies": {
    "no-proxy": "*.local, localhost, 127.0.0.0/8, 10.24.0.0/16, 100.64.0.0/10, 10.42.0.0/16",
    "http-proxy": "http://<user>:<password>@<proxy-address>:<http-port>",
    "https-proxy": "http://<user>:<password>@<proxy-address>:<http-port>"
  }
}

而对于平常终端中使用时，可以添加一个简单的 bash 命令：

use_proxy () {
        export HTTP_PROXY=http://<user>:<password>@<proxy-address>:<http-port>
        export HTTPS_PROXY=http://<user>:<password>@<proxy-address>:<http-port>
        export ALL_PROXY=socks5://<user>:<password>@<proxy-address>:<socks5-port>
}

然后在需要时（例如进行软件包安装，或者调用远程脚本等）键入 use_proxy 并回车即可。

容器流量代理方案

现在得到正确的 ip 已有了可靠的保证，接下来就该部署代理了。 
目前采用的方案是在 线路稍好 的国外服务器上部署一个 只 bind Tailnet 地址的 v2ray http/socks5 proxy（如果国外节点多的话可以用 nginx 做负载均衡），然后向需要用到代理的主机、容器什么的添加环境变量就好了。

为 k3s 容器添加环境变量最方便的方式为：单独将代理参数存入一个 configmap 中： 

apiVersion: v1 
data: 
  ALL_PROXY: socks5://<user>:<password>@<proxy-address>:<socks5-port>

  HTTP_PROXY: http://<user>:<password>@<proxy-address>:<http-port>

  HTTPS_PROXY: http://<user>:<password>@<proxy-address>:<http-port>

  NO_PROXY: >- 
    .local, *.local, localhost, 127.0.0.0/8, 100.64.0.0/10, 10.42.0.0/16, 10.43.0.0/16

  all_proxy: socks5://<user>:<password>@<proxy-address>:<socks5-port>

  http_proxy: http://<user>:<password>@<proxy-address>:<http-port>

  https_proxy: http://<user>:<password>@<proxy-address>:<http-port>

  no_proxy: >- 
    .local, *.local, localhost, 127.0.0.0/8, 100.64.0.0/10, 10.42.0.0/16, 10.43.0.0/16

kind: ConfigMap 

其中 NO_PROXY/no_proxy 将使下列目标绕过代理：

• .local, *.local: 集群域名
• localhost, 127.0.0.0/8: lo
• 100.64.0.0/10: Tailnet
• 10.42.0.0/16, 10.43.0.0/16: k3s 集群 pod cidr 和 service cidr

然后在创建 deployment 时引用这个 configmap 即可。

注意：

• 配置代理的环境变量共8条，最好一条都不少（不同的程序对大小写有不一样的要求¿）
• 使用代理参数后，所有没在 NO_PROXY/no_proxy 中出现的目标流量将经过代理；因此按照上述的配置后，容器内的服务需要使用完整的集群内域名以保证命中规则，例如 service prometheus.prometheus 应该使用 prometheus.prometheus.svc.cluster.local
• 大多数情况下可通过进入容器使用 curl -vvv 来判断是否走了代理，如下所示：

grafana-57968c8758-s9b52:/usr/share/grafana$ curl prometheus.prometheus.svc.cluster.local:9090 -vvv
07:55:46.701660 [0-x] == Info: [READ] client_reset, clear readers
07:55:46.701800 [0-x] == Info: Uses proxy env variable no_proxy == '.local, *.local, localhost, 127.0.0.0/8, 10.24.0.0/16, 100.64.0.0/10, 10.42.0.0/16, 10.43.0.0/16'
07:55:46.900827 [0-0] == Info: Host prometheus.prometheus.svc.cluster.local:9090 was resolved.
07:55:46.900978 [0-0] == Info: IPv6: (none)
07:55:46.901066 [0-0] == Info: IPv4: 10.43.110.251
07:55:46.901166 [0-0] == Info: [SETUP] added
07:55:46.901292 [0-0] == Info:   Trying 10.43.110.251:9090...
07:55:46.901590 [0-0] == Info: Connected to prometheus.prometheus.svc.cluster.local (10.43.110.251) port 9090
07:55:46.901808 [0-0] == Info: using HTTP/1.x
07:55:46.902026 [0-0] => Send header, 108 bytes (0x6c)

k3s datastore

之前 有强调过 k3s datastore 的重要性，然而当预算不足时只能在两个代价之间找平衡点。我给出的折中方案为 MariaDB Galera 集群；为了让数据库能够稳定高可用，这里将给出一些数据库集群的使用 techniques 供参考。

负载均衡 & Failover

首先，应使用互联延迟低、运行稳定的机器作数据库节点；然后使用 TCP Loadbalancer 来实现 Failover，可以固定频繁读写节点，有效地减少数据库冲突发生可能性的同时保证单个数据库节点宕机时能平滑切换，从而达到数据库高可用的目的。

Nginx 只需要几行 即可方便地配置为 TCP Loadbalancer，但貌似 free 版本（非 plus 版）需要手动编译带 --with-stream 参数来添加 ngx_stream_core_module 模块 以支持四层负载均衡。随后我又经过了一番广泛的搜索，最后 发现了性能更高的 HAProxy。

1:2 分裂 crash recovery

接下来我将参考 官方文档，记录 典型三节点全主数据库集群 遇到一些常见情形时的 crash recovery 流程。

集群分裂大致是由网络掉线或电源中断造成：前者相较于后者，其掉线后可能还在继续写事务，即可能产生冲突。因此集群分裂后恢复时最主要的步骤是 确认拥有最新状态的节点，使用其作为 集群恢复的 bootstrap 节点 以便于其它节点能通过 Incremental State Transfer 来 以增量形式 同步状态。
最新状态序列号（recovery position state sequence）可通过 sudo -u mysql mysqld --wsrep-recover 命令来得到。

例如，通过在节点一执行上述命令，得到其 recovery position 为 3864673：

 ~  sudo -u mysql mysqld --wsrep-recover                                                                                                
2025-01-04  5:03:47 0 [Note] Starting MariaDB 10.11.8-MariaDB-0ubuntu0.24.04.1 source revision 3a069644682e336e445039e48baae9693f9a08ee as process 1272794
2025-01-04  5:03:47 0 [Note] InnoDB: Compressed tables use zlib 1.3
2025-01-04  5:03:47 0 [Note] InnoDB: Number of transaction pools: 1
2025-01-04  5:03:47 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2025-01-04  5:03:47 0 [Note] InnoDB: Using liburing
2025-01-04  5:03:47 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2025-01-04  5:03:47 0 [Note] InnoDB: Completed initialization of buffer pool
2025-01-04  5:03:47 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
2025-01-04  5:03:47 0 [Note] InnoDB: End of log at LSN=8179900673
2025-01-04  5:03:47 0 [Note] InnoDB: 128 rollback segments are active.
2025-01-04  5:03:47 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-01-04  5:03:47 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-01-04  5:03:47 0 [Note] InnoDB: log sequence number 8179900673; transaction id 7569239
2025-01-04  5:03:47 0 [Warning] InnoDB: Skipping buffer pool dump/restore during wsrep recovery.
2025-01-04  5:03:47 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-01-04  5:03:47 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
2025-01-04  5:03:47 0 [Note] Server socket created on IP: '100.120.32.65'.
2025-01-04  5:03:47 0 [Note] WSREP: Recovered position: 93114f49-c453-11ef-b5ed-5b52f2d6eaa1:3864673

节点二与节点一相同，而节点三为 3694624：

 ~  sudo -u mysql mysqld --wsrep-recover                                                                                                     
2025-01-04 13:04:45 0 [Note] Starting MariaDB 10.11.8-MariaDB-0ubuntu0.24.04.1 source revision 3a069644682e336e445039e48baae9693f9a08ee as process 249409
2025-01-04 13:04:45 0 [Note] InnoDB: Compressed tables use zlib 1.3
2025-01-04 13:04:45 0 [Note] InnoDB: Number of transaction pools: 1
2025-01-04 13:04:45 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2025-01-04 13:04:45 0 [Note] InnoDB: Using liburing
2025-01-04 13:04:45 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2025-01-04 13:04:45 0 [Note] InnoDB: Completed initialization of buffer pool
2025-01-04 13:04:45 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
2025-01-04 13:04:45 0 [Note] InnoDB: End of log at LSN=7281719277
2025-01-04 13:04:45 0 [Note] InnoDB: 128 rollback segments are active.
2025-01-04 13:04:45 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-01-04 13:04:45 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-01-04 13:04:45 0 [Note] InnoDB: log sequence number 7281719277; transaction id 6622581
2025-01-04 13:04:45 0 [Warning] InnoDB: Skipping buffer pool dump/restore during wsrep recovery.
2025-01-04 13:04:45 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-01-04 13:04:45 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
2025-01-04 13:04:45 0 [Note] Server socket created on IP: '100.120.3.9'.
2025-01-04 13:04:45 0 [Note] WSREP: Recovered position: 93114f49-c453-11ef-b5ed-5b52f2d6eaa1:3694624

由于状态序列号 3694624 < 3864673，即节点三的状态没跟得上节点一与二（因为上述事例是因为节点三断电导致）。此时即可编辑 bootstrap 节点（即节点一或二）上的 /var/lib/mysql/grastate.dat 文件，将原本为 0 的 safe_to_bootstrap 改为 1，然后执行 galera_new_cluster 来重置集群。

注意：节点一和二脱离节点三，需要在重置集群前先 sudo mysql 后执行 SET GLOBAL wsrep_provider_options='pc.bootstrap=true'; 来 手动使能 primary component。

Monitoring

最后，为了能保证集群的稳定，在宕机之前做好监控与预警是有必要的。
以前使用过 ELK stack，虽然用起来非常舒服，但由于 elasticsearch 是做全文索引，再加上它还是用 memory hogger 写的，集群 内外存的资源开销 都过于庞大。因此最后换成了最早尝试使用的 prometheus stack。

先给几张实际截图看看。

Grafana logs:

Grafana node metrics:

prometheus stack 的主要组成为:

• Grafana: 可视化 Web 应用
• Prometheus: 从 *_exporter 采集指标数据
• Loki: 日志数据采集
• *_exporter: 指标数据收集与统一 expose
• promtail: 收集与提交日志数据至 Loki

这个 stack 中只有 Grafana、Prometheus 和 Loki 集中部署，后两者部署在所有需要收集数据的机器上，类似于 elastic-agent；总体来说非常好安装啦。

对于 node_exporter 和 promtail 这两个 agent 来说，有个部署的小技巧：若要在集群内中的所有节点上均部署，可以在编写 deployment 时指定 pod 副本数为 节点数、pod 调度中指定 反亲和性拓扑键为 kubernetes.io/hostname，然后在每个节点下初始化完各自的配置文件，最后 kubectl apply -f，k3s 便会自动在每个节点上都部署一个 pod。下面是 deployment.yaml 中的一个示例片段：

spec:
  replicas: 2
  strategy:
    type: Recreate
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector: {}
              topologyKey: kubernetes.io/hostname    

值得注意的一点是，对于 promtail 来说，它是主动推送日志数据至 loki，因此不需要额外的配置。而对于 node_exporter，它需要使用 host network 而不是 service 来暴露服务，否则从不同节点端口采集到的都是相同的、来自任意 pod 的数据。

对于家中（寝室？学校/实验室？）有自建 NAS 、树莓派/服务器等 Homelab 设施，以及在多个云服务商部署有云服务器这种更为常见场景的我来说，为了设法充分利用这些资源，我在这之后又探索了各种能够实现分布式高可用 k3s 集群的搭建。
对于这种应用场景下的集群，为了保证稳定和可靠性，要反复斟酌的主要有这几个点：

1. 如何为处于不同网络环境下的机器完成互联？
   即使是分布在不同的运营商，让拥有公网 IP 的云服务器之间互联也很容易（例如用 WireGuard 组网，甚至不组网直接使用 IPv6 亦可）。但如何将他们和 Homelab 里没有公网 IP 的机器互联呢？
2. 在可能出现延迟突升甚至机器掉线的情况下，使用 k3s 作为集群服务部署工具，该选取哪种 datastore 方案（嵌入式 SQLite / 嵌入式 Etcd / 外置 Etcd 集群 / 外置 Mysql Postgres）呢？

最终经过多次反复试错和尝试，我的部署方案停留在 使用 自建 MariaDB Galera 集群的多 Server 节点高可用部署 和 通过 Tailscale NAT 穿透 建立跨云内网实现跨云 k3s 集群。本文在 k3s 跨云的各种坑中摸爬滚打后，给出如下的能够较完美运行的配置方案供大家参考。
那么我们就开始吧☺️

WireGuard 与 Tailscale

在正式的部署流程前，先给大家简要介绍下 WireGuard VPN 和 Tailscale 这个强大的组网工具。

WireGuard 是一个用于替代 OpenVPN、L2TP/IPsec 这类传统 VPN 的高性能、现代化且安全的 VPN 协议（官网是这么描述的），它与这些传统 VPN 的主要区别有：

• WireGuard 在保证核心功能 “加密隧道” 实现的同时切割掉了许多不必要的功能，因此它相当的简洁（代码只有几千行），还有着非常简单的配置步骤
• WireGuard 可以运行在内核态，避免了与用户态之间来回切换，因此速度非常快，且可以支持很高的带宽
• WireGuard 没有 Server/Client 之分，连线的两端地位是对等的，因此非常适合用来进行各种拓扑组网

知乎 上有一篇文章详细介绍了 WireGuard 是如何对传统 VPN 进行精简化的；后面我也会看看源码学习学习，毕竟我对能简洁优雅地实现核心功能的东西相当感兴趣。

Tailscale 是一个基于 Wireguard 实现的 mesh 网络构建器。它大致是通过一个集中式 control plane 记录与分发不同节点之间的 wireguard 连接配置，以及一些灵活的打洞黑科技来实现的。
对于大多数用户来说，Tailscale 的主要功能即通过搭建 mesh vpn，将处于不同网络的设备连接在同一个网络下。

使用 Tailscale 为集群跨云互联组建虚拟内网

首先要在这里说明的一点是：k3s 在较新版本中自带有 Tailscale 支持（详见 Distributed hybrid or multicloud cluster），但是并不建议使用：

• 对于每个节点，用于 k3s 网络基础设施维护的 flannel 会创建一个 cidr 子网。
  比如说节点 A 下的所有 pod 会分配 10.42.0.0/16 的地址，节点 B 下的所有 pod 会分配 10.42.1.0/16 的地址。
  Tailscale 需要 为每个节点创建一个 Subnet Router 来完成 跨节点间 pod 网络的互联 （例如 10.42.0.31 <-> 10.42.1.56）。免费版只有一个 router 的额度，自建 Headscale 的话稳定性可能得不到较好的保障，因此不考虑自建。
• 这个方案需要让 k3s 接管该节点的 Tailscale 的运行，虽然可以传自定义参数进去，倘若在集群运行时对 Tailscale 进行配置的话，可能玩着玩着集群就炸了😊

其次还要再提醒一下，本文的方案是 在每个节点上都跑 Tailscale 来组网，但在经过一段时间的运行后发现，就算所有设备均始终处在校园网这个大内网中，Tailscale 也并不是随时都能打通直连的喔，特别是在 类似于 site2site 拓扑 的网络架构时，有较小几率出现一边只有一台机器能够直连而其他机器走代理的现象，V 站上也存在这样的讨论（可以搜搜，地址嚒我不记得了）。这种情况就建议在本城开个 derp 做个最低延迟的中转咯；要不就 site2site，参考官方文档 Site-to-site networking。当然，这个也需要两个或以上的 Subnet Router。

网络基础设施配置

网络基础设施的准备主要分为两个方面：搭建分布式网络，以及大陆用户绕不开的完整互联网访问。

先使用下面的命令在各个节点上安装好 Tailscale：

curl -fsSL https://tailscale.com/install.sh | sh

然后执行 tailscale up，点击提示中的链接登录即可。
集群中所有节点均安装完成后，可以进入 Tailscale Admin Console 为节点配置各自的 IP。

P.S. 这里出现了第一个坑，注意 不要使用 Exit Node，这将会导致 flannel 10.42.0.0/16 所有的包都丢被到出口节点上，就算加上 --exit-node-allow-lan-access flag 也行不通（因为 10.42.0.0/16 并不在 Tailscale 定义的 Lan 段内）。

由于跑的许多服务都需要例如 Google API 等服务的支持，我之前在大陆内单台服务器的做法都是直接使用出口节点将包转发到境外机器上。

对于现在的部署方案，这种做法就行不通咯。截止目前，我暂时还没有找到能够正确部署这个路由规则的方法（只要这句话还在本文当中，就说明我还没能有时间来研究😭）。此外，Tailscale 打洞的难度会随着两个 peer 间 hop 数量的增加而增加，因此使用 openwrt 软路由 + openclash 透明代理的方式不仅会为 Tailscale 添堵，而且会让机器对软路由的正常工作状态产生强依赖性，似乎也不太可取。

最后，我似乎已经找到目前来说最佳的替代方法：在境外机器上部署 dns 服务器作中继杜绝 dns 污染，以及 仅对内网地址开放 http 或 socks proxy 供境内服务器代理流量。我在 plamnet 中使用的是 AdGuard Home + v2ray 多机器负载均衡，能够非常稳定地提供基础的网络服务。

使用自建外置 MariaDB Galera 集群为 k3s 提供 datastore

Galera 是 Codership 公司为 Mysql 开发的 多主集群插件。MariaDB 在 10.4 版本后提供其官方支持，因此我便计划从 Mysql 迁移至 MariaDB。

通过网上资料的查找，国内使用 Galera 方案的人好像有点少啊。
你也许会疑惑，etcd 作为 kubernetes 原生 datastore 方案，那为什么不直接在 k3s 中使用呢？（当然是因为懒，学不动啦

因为对于我这种非专业运维来说，Mysql 已经用了很多年了，比 Etcd 熟悉得多，挂了能更迅速找到问题并及时解决；就算解决不了，Mysql 数据库的备份恢复易如反掌，能在较短时间恢复集群。
其次，新搭好的这个 Mysql(MariaDB) 集群 还可以用来存其他生产应用的数据，为它们提供数据库 高可用+多地备份 的特性，而这正是我从中学时代就想要得到的方案。

由于 datastore 作为 k3s 集群的核心，这里特地标明几个要点，其关系着搭建的集群是否能稳定使用（而不是浪费大量没必要的时间来折腾 ⚠️ ：

1. 经过网上大量博客、笔记和论坛资料的调研，我得到的结论是 k3s + 由云服务商提供的 MySQL 服务 能够最有效的避免集群宕机。
2. Galera 集群搭建的主要目的为数据库备份，其次为高可用性。由于分布式数据库集群容易出现冲突的问题，严重的话可能会使整个数据库不可用，因此我的方案 不是在所有 k3s master 节点上安装 MariaDB，而是 选取几个网络延迟低、运行稳定的服务器安装 + 使用 TCP 负载均衡器做 Failover 来固定频繁读写的节点，从而尽量避免冲突问题的发生。
3. Galera 集群至少需要三个节点；若只有两个节点时需要额外的配置才能保证其中一个节点掉线时集群还能正常运行，因此这里以三个节点为例。

数据库迁移

P.S. 这个环节非必须。

如果你跟我一样准备从 单节点 Mysql 迁移至 MariaDB Galera 集群，虽然很简单，但有几点提示可能会有些许帮助：

数据迁移前务必在 k3s 集群的 所有节点 上停止 k3s/k3s-agent。
然后可以准备导出数据库了。我习惯在集群中使用 phpmyadmin，在浏览器中就能很方便地导出下载单个数据库至 sql 文件并导入。
当然，如果你没有 phpmyadmin，也可直接使用 mysqldump 工具进行导出。

要注意的一点是，如果你是从 Mysql-5 迁移至 MariaDB-10 (对应 Mysql-8 的 API)，因为版本兼容问题，在集群安装配置完成后，数据库导入前需要打开导出文件作如下更改：

• utf8mb4_0900_ai_ci 替换为 utf8_general_ci
• utf8mb4 替换为 utf8

MariaDB 安装与集群配置

以下的命令均在 root 权限下执行。

安装前确保本地 Mysql 服务器已关闭：

systemctl stop mysql
systemctl disable mysql

在所有节点上执行：

apt install mariadb-server mariadb-client mariadb-backup galera-4 

打开 /etc/mysql/mariadb.conf.d/ 文件夹，根据下面叙述仿照着更改 60-galera.cnf 配置文件：

[galera]
# Mandatory settings
wsrep_on                 = ON
wsrep_provider           = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name       = "carton.plam"
wsrep_cluster_address    = gcomm://100.120.32.65,100.120.3.9,100.120.16.65
binlog_format            = row
default_storage_engine   = InnoDB
innodb_autoinc_lock_mode = 2

# Allow server to accept connections on all interfaces.
bind-address = 100.120.32.65

# Optional settings
#wsrep_slave_threads = 1
#innodb_flush_log_at_trx_commit = 0
wsrep_node_name          = coord.plam.toay
wsrep_node_address       = 100.120.32.65

简要描述几个重要的：

• wsrep_provider wsrep 为 Galera 4 核心组件，确保这个 provider 动态链接库存在
• wsrep_cluster_address 在这里补充上 MariaDB Galera 集群 中所有节点的 Tailnet IP 地址
• bind-address 仅在 Tailnet 地址监听连接

所有节点均配置完成存盘退出后，在其中一个节点上执行 galera_new_cluster 来初始化集群。
MariaDB 会自动启动，等待命令成功退出后可 mysql -u root 通过 SQL 查询状态来检查集群节点数量：

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+
1 row in set (0.001 sec)

集群节点数为 1，表明集群已创建成功，且当前节点已成功加入。
此时再在其他节点启动 MariaDB 即可自动加入集群：

systemctl enable mariadb
systemctl restart mariadb

然后再次通过 SQL 查询状态，可观察到与节点数相同的正确集群大小。至此，datastore 已为 k3s 准备完成。

部署 k3s 至集群

配置好网络和 datastore 后，可以正式开始 k3s 的安装了。
由于 datastore 只是从 Mysql 切换至同类的 MariaDB，故 k3s 的安装配置与上篇文章几乎完全一致，故这里不再给出详细安装流程。

需要留意的一点是，现在集群使用 Tailscale 作为其网络基础，因此需要在 配置并初始化集群中所有的节点后 在每个节点 （包括 k3s 和 k3s-agent） 的启动参数中添加一项 --flannel-iface tailscale0 来指定 flannel 的接口。
初始化集群前不要添加这个参数，会导致 Waiting for CRD helmchartconfigs.helm.cattle.io to become available 从而无法正常初始化集群。

连接集群至 Rancher 实现远程可视化管理

P.S. 同样地，这个环节非必须。

如果你和我一样习惯使用 Rancher 来管理 kubernetes 集群，可以从 Rancher Web 界面添加导入集群，然后复制粘贴命令到 control-plane 节点终端中执行，然后回到 Rancher 等待集群状态 Ready。

在此过程中可通过 sudo kubectl get pod -n cattle-system 命令查看 cattle cluster agent 的状态。若 pod 反复重启，然后在日志中遇到 pod 内 dns 不能正常解析的错误，可以尝试修改 deployment 的 dnsPolicy 为 ClusterFirst：

修改前：

NAME                                    READY   STATUS    RESTARTS      AGE
cattle-cluster-agent-569cc46d9c-66pdb   1/1     Running   0             83s
cattle-cluster-agent-569cc46d9c-pkljj   0/1     Error     2 (40s ago)   81s
rancher-webhook-5b5665c649-rsx9s        1/1     Running   0             4h30m

修改后：

NAME                                    READY   STATUS    RESTARTS   AGE
cattle-cluster-agent-57ccdb69b4-9q7bl   1/1     Running   0          13s
cattle-cluster-agent-57ccdb69b4-p882r   1/1     Running   0          15s
rancher-webhook-5b5665c649-rsx9s        1/1     Running   0          4h35m

All Done.

等待几分钟，然后到 rancher 上查看集群状态，接下来就能进行应用和服务的部署啦。

你也可以尝试使一个节点掉线，观察 k3s 能否正常地将服务转移至其他节点，毕竟这是我们搭建集群想要实现的最主要功能。

例如，实验室每天晚上都会断电，因此我一般会将 worker 部署到位于实验室主机中的虚拟机节点（threadpool.plam.toay）上。

当断电时，k3s 会自动对节点进行污点标记（node.kubernetes.io/unreachable=:NoSchedule 和 node.kubernetes.io/unreachable=:NoExecute）：

以及 pod 部署转移（threadpool.plam.toay => coordinator.plam.toay）：

从而保证了服务的高可用。

关于后续对 k3s 集群维护的相关内容，我特意新建了一个专栏 k3s 集群维护笔记 来记录，欢迎关注😊。

Bonus

最后，Tailscale 实现了一些非常好用的便捷功能，这里简单做个摘要：

Taildrop

使用 Taildrop 可以非常方便地实现 Tailnet 中文件的传递，从此可以不再使用 SFTP 咯😋。

从 Linux 端发送：

tailscale file cp <src-file-loc> <dst-device>:

然后从 Linux 端接收：

tailscale file get <dst-dir>

Subnet Router

免费版仅有的一个 Subnet Router 也可以利用起来，通过一行命令实现从你的 Tailnet 访问 LAN 网中的所有设备：

sudo tailscale up advertise-routes=10.24.1.1/24

使用 Exit Node

可以使用 Exit Node 来代理全部流量，实现一键接入完整互联网的功能：

Server 节点：

sudo tailscale up --advertise-exit-node

Client 节点：

sudo tailscale up --exit-node=<exit-node-ip>

目前 Tailscale 貌似还没打算实现复杂的分流功能😭。
若要跳过 局域网流量（仅 LAN 而已） 的代理，可添加 --exit-node-allow-lan-access=true 参数来实现。

一些非常值得参考的链接

1. The long wondrous life of a Tailscale packet
2. Kubernetes flannel网络分析
3. cattle-cluster-agent pod内不能解析 解决方法 - Github issue
4. 如何设置一个生产级别的高可用etcd集群
5. WireGuard到底好在哪？

因为要使用到 Apple Music/YouTube Music 流媒体应用需要 Google Play 框架，所以要给国行版播放器刷上国际版的系统。
之前在 YouTube 上的一个视频（Channel @杰哥Jason_Vlog）了解到给 NW-ZX505 国行版本刷国际版系统的方法，成功地通过下载系统更新固件包，使用系统自带的“系统更新”应用我的 NW-A105 上升级为国际版系统，后面也在对下载地址作了小调整后也成功地升级了我的 NW-Z706。今天发现系统更新到版本2.0了看看有什么优化没有，但不知道为什么，原视频好像随频道一起不见了，于是在这里记录一下以方便后面有需要的人找到正确的方法。

安装包下载

首先是找到正确的下载地址得到响应的系统更新包：先通过 Sony Support 官网 找到最新的固件版本号，然后通过下面的链接拼接规则得到（猜到）正确的下载地址。

对于 NW-Z500 和 NW-A100 系列播放器：

https://info.update.sony.net/PA001/<NW-Z500 或 NW-A100>Series_<地区代码>/contents/<版本自增序号>/NW-A100_<地区代码>_V<5位版本编号>_NW_WM_FW.UPG

如 V4.06.00(V4_06_00)、日版(0000)系统的下载地址：

https://info.update.sony.net/PA001/NW-A100Series_0000/contents/0015/NW-A100_0000_V4_06_00_NW_WM_FW.UPG

对于 NW-ZX700 系列播放器，升级包的名称有了小变动（增加了 Series 字符串）：

https://info.update.sony.net/PA001/NW-ZX700Series_<地区代码>/contents/<版本自增序号>/NW-ZX700Series_<地区代码>_V<5位版本编号>_NW_WM_FW.UPG

如 V2.01.00(V2_01_00)、日版(0000)系统的下载地址：

https://info.update.sony.net/PA001/NW-ZX700Series_0000/contents/0004/NW-ZX700Series_0000_V2_01_00_NW_WM_FW.UPG

上面这个规则是 YouTube 频道 @杰哥Jason_Vlog 发现的，大概是通过官方升级时抓包改 URI 猜出来的😊。
对于黑砖金砖来说规律应该是差不多的，但我没有就没尝试过，可以自己试一下😋。

P.S. 这里分享一个Dropbox链接，里面有我使用过后备份的一些版本的日区固件升级安装包：
https://www.dropbox.com/scl/fo/lcfe8sl08ugqjhm4aezsl/AJHT0Ng98jDTiGxuRacZsjI?rlkey=u31kb5fo1atynyndmu8tat7po&st=lrmlw78b&dl=0

使用“系统更新”应用升级

将下载好的安装包放在 Android 系统根目录下，然后进入 设置->系统->系统更新，检测到根目录下的安装包后点击 开始更新 即可。

一个需要注意的是：若是新机首次使用，建议在更新完最新版本系统，即成功从国行系统升级至国际版系统后，再进行一次 恢复出厂设置 的操作，以清除可能造成冲突的国行版系统残余的系统组件（例如我的 NWZ706 在升级成国际版后 Gboard 始终闪退，最终在恢复出厂设置后得以解决）：设置->系统->重置选项->清除所有数据（恢复出厂设置）；需要注意的是，刷成国际版后恢复出厂设置时的开机初始化需要通过 WiFi 设置代理服务器或软路由的方式配置网络以登录 Google 账号。

另外，将播放器刷成国际版后，日后所有的更新均需要通过上述的方式手动下载正确的更新包进行升级，不可使用自带的“系统更新”应用，否则又会给更新回国行版系统（据说是通过序列号来判断区域的，这个貌似改不了咯）。

先使用 fdisk -l 命令查看所有检测到的磁盘与分区，找到新添加磁盘的路径：

Disk /dev/sdb: 256 GiB, 274877906944 bytes, 536870912 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

对新添加的磁盘进行分区：

 ~  sudo fdisk /dev/sdb                                                                                                                                         

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x08c3917d.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-268435455, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-268435455, default 268435455):

Created a new partition 1 of type 'Linux' and of size 128 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

再次查看所有磁盘与分区：

Disk /dev/sdb: 128 GiB, 137438953472 bytes, 268435456 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x08c3917d

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1        2048 268435455 268433408  128G 83 Linux

格式化分区：

~  sudo mkfs -t ext4 /dev/sdb1
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 8388352 4k blocks and 2097152 inodes
Filesystem UUID: 9eb32519-8f2b-4296-be89-c0e7589410b1
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

挂载：

sudo mkdir /data
sudo mount /dev/sdb1 /data

查看空间占用：

 ~  sudo df -Th                                                                                                                                                 
Filesystem                        Type   Size  Used Avail Use% Mounted on
tmpfs                             tmpfs  197M  1.2M  196M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv ext4    61G  5.9G   53G  11% /
tmpfs                             tmpfs  982M     0  982M   0% /dev/shm
tmpfs                             tmpfs  5.0M     0  5.0M   0% /run/lock
/dev/sda2                         ext4   2.0G  251M  1.6G  14% /boot
tmpfs                             tmpfs  197M  4.0K  197M   1% /run/user/1000
/dev/sdb1                         ext4   126G   24K  120G   1% /data

添加至 /etc/fstab 以实现开机自动挂载：
使用 blkid 或 ls -l /dev/disk/by-uuid/ 命令得到分区的 uuid，然后向 /etc/fstab 文件末尾追加一行：

UUID=10fd13d0-5d0f-42cc-9c14-331858bbcf01 /data ext4 defaults 0 2

最后重启系统。

附加磁盘扩容

使用 df -Th 查看当前磁盘分区容量、挂载信息：

/dev/sdc1                         ext4     126G   90G   30G  76% /data

首先通过 hypervisor （这里我使用的是 pve，其他虚拟机软件同理）直接配置扩展磁盘大小。pve 可以方便地进行在线容量扩展，不需要进行关机或重新挂载磁盘的操作。

进入系统，输入 fdisk -l 查看所有磁盘及分区，可以观察到硬盘有分区表大小不匹配的警告：

GPT PMBR size mismatch (268435455 != 536870911) will be corrected by write.
The backup GPT table is not on the end of the device.

先使用 parted -l 解决分区表不匹配问题：

Warning: Not all of the space available to /dev/sdc appears to be used, you can
fix the GPT to use all of the space (an extra 268435456 blocks) or continue with
the current setting?
Fix/Ignore? Fix
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sdc: 275GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  137GB  137GB  ext4

接下来的操作就很简单了，直接使用 cfdisk /dev/sdc 命令进行 resize，然后使用 resize2fs /dev/sdc1 命令同步系统容量到内核。

再次使用 df -Th 查看当前磁盘分区容量：

 /dev/sdc1                         ext4     252G   90G  151G  38% /data

磁盘的容量已成功扩大并应用。

主分区磁盘扩容

类似地，先使用 cfdisk resize 磁盘并更新分区表。

然后，若直接 resize2fs:

 ~  sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv                                                                                                     
resize2fs 1.46.5 (30-Dec-2021)
The filesystem is already 7863296 (4k) blocks long.  Nothing to do!

先使用 pvresize 命令 resize，再使用 lvresize 扩大文件系统：

 ~  sudo pvresize /dev/sda3                                                                                                                                     
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
 ~  sudo lvresize -l  +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv                                                                                               
  Size of logical volume ubuntu-vg/ubuntu-lv changed from <30.00 GiB (7679 extents) to <62.00 GiB (15871 extents).
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.

再次使用 fdisk -l 命令查看，则观察到分区由：

Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 62 GiB, 66567798784 bytes, 130015232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

变为：

Disk /dev/mapper/ubuntu--vg-ubuntu--lv: 254 GiB, 272726228992 bytes, 532668416 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

最后使用 resize2fs 应用更改：

 ~  sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv                                                                                                            
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/mapper/ubuntu--vg-ubuntu--lv is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 8
The filesystem on /dev/mapper/ubuntu--vg-ubuntu--lv is now 16251904 (4k) blocks long.

=>

 ~  sudo df -Th                                                                                                                                                 ok | twikor@sodium
Filesystem                        Type   Size  Used Avail Use% Mounted on
tmpfs                             tmpfs  197M  1.2M  196M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv ext4    61G  5.9G   53G  11% /
tmpfs                             tmpfs  982M     0  982M   0% /dev/shm
tmpfs                             tmpfs  5.0M     0  5.0M   0% /run/lock
/dev/sda2                         ext4   2.0G  251M  1.6G  14% /boot
tmpfs                             tmpfs  197M  4.0K  197M   1% /run/user/1000

参考链接

1. https://www.reddit.com/r/Proxmox/comments/12ubr84/ive_increased_a_vms_partition_size_but_the_lvm/
2. http://linux.51yip.com/

本文永久短链接：zyi.io/143-1
经过了3年疫情的阻拦，2023/03/11，143终于策划了第一次的集体活动。

雷洞坪

金顶

缆车上的日出

明与暗的境界线

寺院屋檐上柔滑的雪

金顶全景

金顶中心全景

金顶索道全景

未完待续。。。

先来张图展示一下最终产品吧：

在嘉立创上打的板，分上下两层，板之间用排针连接。上层板放欧姆龙的大按键，并将调试线引出。下层板放电池和稳压芯片、OLED、十轴陀螺仪、摇杆、蓝牙模块和 STM32 核心板。
顺便一提，摇杆也有两种：一种是方形限位的摇杆，一般用来做航模遥控的油门；一种是圆形限位的，游戏机用的大多都是这种摇杆。淘宝上搜 XBox 手柄替换摇杆就可搜出一大堆，便宜而且手感非常好，不知比 Switch Joy-Con 上的摇杆舒服到哪里去。

你可能要问了，为什么不直接搞个 F103 上去？其实最开始做这个项目的时候还留有了小游戏机的需求的，一直想要复刻几个远古时期的老游戏练练手，就直接上的F411的芯片。而最近 STM32F411 的芯片价格炒上天了，立创商城上每片要卖一两百，这怎么承担得起。。。（还不是因为没钱）要知道这块 WeAct 工作室的核心板才 42 左右（现在已经绝版了，官方淘宝只有国产 GD32 的核心板了，幸好我还留有一块全新的做备用😊）。

不过做成模块化的话也有个好处，这个核心板的引脚排布与 Bluepill 的排布大致相同；若要考虑直接使用 Bluepill 做主控的话直接替换也行。