其中等待的那个过程非常非常漫长，比拜登那漫长而响亮的屁要漫长的多，建议睡觉前运行，睡醒了可能会做好。
最终结果如下：
起因
自从意识到在互联网上有成千上万的扫描器 24 小时不停的扫扫扫，以及在 Censys.io 网络空间搜索引擎里几乎能搜索到关于本人服务器上运行的业务的近乎一切详情后，我开始怕了。服务器上暴露端口可能导致各种被入侵，被当肉鸡，或者暴露源站 ip，不同机子之间的关联信息。所以一年前开始我就特别注重服务器防火墙的配置。
妈的，直到上个月我才发现一个怪事，就是 Docker 容器暴露出来的端口不会受 UFW 的规则影响，手动 deny 掉也照样可以访问，无大语了。
原因
当你在使用 Docker 时，它会创建一个虚拟网络接口（通常是名为 docker0 的网桥），并使用 Linux 的网络命名空间来隔离容器的网络环境，这些操作是通过 iptables 修改系统网络功能实现的
UFW（Uncomplicated Firewall）是一个简化了防火墙配置的前端工具，它使用 iptables 来管理 Linux 系统的防火墙规则。当你在使用 UFW 时，其实是它根据你的配置再设置 iptables 规则来限制网络流量。
然而，Docker 会修改系统的 iptables 规则，以便容器之间可以相互通信，并且容器可以与主机和外部网络进行通信。而且这些修改的优先级高于 UFW 这样的 iptables 规则管理程序，导致 UFW 的规则失效。 Docker 直接操作了 iptables 规则，而不是通过 UFW。
具体现象是：
在一个对外提供服务的服务器上启用了 UFW，并且默认阻止所有未被允许的传入连接。
运行了一个 Docker 容器，并且使用 -p 选项来把该容器的某个端口发布到服务器的所有 IP 地址上。比如：docker run -d --name httpd -p 0.0.0.0:8080:80 httpd:alpine 将会运行一个 httpd 服务，并且将容器的 80 端口发布到服务器的 8080 端口上。
UFW 将不会阻止所有对 8080 端口访问的请求，用命令 ufw deny 8080 也无法阻止外部访问这个端口。
这个问题其实挺严重的，这意味着本来只是为了在内部提供服务的一个端口被暴露在公共网络上。
解决办
在使用tailscale混合组网时，部分只有IPv6的节点无法访问docker、github等源站获取镜像，导致无法部署pod。尽管可以使用warp-cli让本机获取访问IPv4网络资源的能力，但仍然无法让这些只有IPv6的节点在k3s集群内部正确拉取IPv4 only的Image镜像。
解决方案：
为了解决这个问题，可以采取以下步骤：
- 安装warp-cli并启用socks5代理，指定端口；
- 使用环境变量来配置节点的网络设置；
- 重启k3s或k3s-agent，应用设置；
优化使用tailscale混合组网时只有IPv6节点无法访问docker和github的问题
在只有IPv6的节点上执行以下命令，安装并注册warp-cli：
apt update && apt install lsb-release gpg curl wgetcurl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpgecho "deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/cloudflare-client.listapt update && apt install cloudflare-warp -ywarp-cli register -y
执行以下命令，配置warp为proxy模式，并指定系统代理：
warp-cli add-excluded-route ::0/0#warp-cli set-mode warpwarp-cli set-mode proxywarp-cli set-proxy-port 9091warp-cli
2024-03-28 14:28:36
20
0
0
起因
由于 LXC 容器无法使用 overlay2 存储层，为了保持与 Docker 的兼容性，默认存储层一直采用 vfs。vfs 存储层的劣势很明显，目前的 lxc 虽然只部署 7 个 Docker 项目，但 /var/lib/docker 目录空间占用高达 70GB，因此迫切需要为 vfs 存储层寻找替代品，查阅众多资料后发现 fuse-overlayfs 可以解决这个问题，但lxc有些系统无法通过apt直接安装 fuse-overlayfs，因此就有了这篇文章，详细记录了 lxc 切换 vfs 存储层驱动为 fuse-overlayfs 的详细过程。
Docker 存储层
Docker容器分层
Docker 容器采用分层结构，其层级如同洋葱般逐一累加（layers、RUN、COPY、ADD）。这意味着 Dockerfile 中的每个命令将在容器内创建一个新层。每一层仅存储相较于上一层新增的修改内容，从而实现容器间的层级共享，降低存储空间占用和下载时间。然而，需要注意的是，这些层是可以访问的，因此不可通过增加额外层级来保护敏感信息。
在典型的系统环境中，Docker 使用联合文件系统（基于 MergerFS）透明地合并了所需的层级。Docker 将此称为 overlay2（默认存储驱动程序）。这样就创建了一个由所有层级共同组成的单个文件系统，而无需复制文件。容器看到的是一个完整的文件系统，但它实质是由多个文件系统组合而成。
LXC中的容器分层
在 LXC 中运行 Docker 时，默认的 overlay2 存储驱动程序不可用，因为 LXC 无法挂载这些高级的 overlay 文件系统（它们是内核构建的）。相反，LXC 使用 vfs，虽然较简单，但也存在一些重大问题。vfs 不会像 overlay2 那样仅更改写入磁盘，而是对现有的整个文件系统进行深度复制，以便在上一层基础上创建下一层。这意味着容器会消耗更多的空间，因为许多基础操作系统文件将在每个层中重复出现，从而显著增加磁盘使用率。因此，多个容器也无法共享相同的底层。强制使用 overlay2 也不会改善这种情况：
ERRO[2021-09-30T09:24:56.9
定位问题
rancher部署的k3s集群无法加入新的etcd节点，查询日志发现报错，etcd群组中出现本应该已被删除的节点prepaid-de，此节点已经被删除，但却错误的留在了etcd member list中，导致etcd服务无法正常验证。
解决思路
移除已经无效的节点prepaid-de，恢复etcd集群的可用性。
解决方案
在k3s集群主控节点安装etcdctl工具。
一、安装etcdctl
方法一：可以使用apt install命令直接进行安装
apt install etcd-client
方法二：下载对应etcd版本的etcdctl工具手动安装
首先查询获取etcd的版本
curl -L --cacert /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --cert /var/lib/rancher/k3s/server/tls/etcd/server-client.crt --key /var/lib/rancher/k3s/server/tls/etcd/server-client.key <https://127.0.0.1:2379/version>
修改ETCD-VER=v 之后的版本号为之前获取到的数字，运行以下命令安装对应版本etcdctl
ETCD_VER=v3.5.0
# choose either URL
GOOGLE_URL=https://storage.googleapis.com/etcd
GITHUB_URL=https://github.com/etcd-io/etcd/releases/download
DOWNLOAD_URL=${GOOGLE_URL}
rm -f /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gzrm -rf /tmp/etcd-download-test && mkdir -p /tmp/etcd-download-test
curl -L ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gztar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.
pve
2023-12-08 15:04:59
110
0
0
1、合并存储 删除local-lvm存储空间
lvremove lvremove pve/data lvextend -l +100%FREE -r pve/root
2、web界面删除local-lvm
数据中心-存储-删除local-lvm 编辑local，内容里添加 磁盘映像和容器
2023-12-08 15:04:59
143
0
0
K3s、ZFS
不幸的是，在从 ext4 迁移到 ZFS 之后，我发现k3s由于缺少对overlayfsZFS 的支持而导致崩溃。
在解决这个问题之前，我升级到 Debian bullseye。
k3s, ZFS 和 overlayfs
k3s目前不支持 ZFS 快照程序。可以通过三种方法解决此问题：
- 使用外部 containerd 和 ZFS 快照程序（
containerd支持 ZFS）。然而，我就没那么幸运了，几个小时后我就放弃了。 使用
native snapshotter，它速度较慢并且消耗更多磁盘（将产生很多重复文件），但它可以工作。- 只需编辑
/etc/systemd/system/k3s.service并添加--snapshotter native到k3s server项目之后。
- 只需编辑
- 为k3s ”agent” 创建专用的ext4分区格式的ZVOL卷 。这是我最终选择的解决方案，因为它速度更快且占用空间更少。
为k3s创建ZVOL
我们将利用 ZFS 的 ZVOL 功能来创建一个 ext4 卷以用作 overlayfs 的后端。ZVOL 是 ZFS 可以向系统公开的块设备（与作为 ZFS 文件系统的数据集相反）。这些 ZVOL 可以像普通块设备一样使用：我们将创建其中一个，用 ext4 格式化它并用它来托管 k3s agent目录。
# use zfs list see the zfs root path name and the space of disk, in my server which on PVE7 it's "rpool"zfs list# Create a sparse (-s) zvol (-V).# "Sparse" means that the volume will be allocated as data is written into the# volume. So this ZVOLs will grow over time, when needed, until 90Gzfs create -s -V 90GB rpool/k3s-agent# Format the ZVOL as ext4mkfs.ext4 /dev/zvol/rpool/k3s-agent# Now you nee
pve
2023-12-08 15:04:59
90
0
0
之前用卷组的方法也可以，而且其实性能是一样的。
此方法只适用于Linux，而windows上应该是没办法的，至少我没想到什么办法通过DD的方式来整个软raid 0出来。
过程如下：