背景

1. 为什么要将插件分进程

   原有的dde-dock经常因为插件问题导致假死崩溃卡顿等问题，插件与dock在相同进程就避免不了因为插件代码质量等导致的同生共死，所以有将插件独立进程出去将插件的影响范围降低到最小，只影响自己。

2. 分进程有什么好处与坏处

   分进程后带来的好处可以从以下几个方面体现：

    1. 兼容性：只要确定了插件进程与dock进程通信的方式，可以使用这种通信方式都可以被dock当作插件加载上来。无论widget，qml，qt5/6还是其他语言等。
   
    2. 流畅性：dock自身更加专注于dock本身的业务逻辑，不需要发生变化时去更新插件的状态，也不会被插件阻塞住。
   
    3. 稳定性：dock进程只有dock自身，不再受插件的影响。
   

   缺点方面：

    最主要的一点就是总体的系统资源占用会比之前稍高。
    开发复杂度和维护复杂度都会上升。
   

3. 怎么去分进程

   插件的主要作用：

    1. 用于显示，显示插件的UI部分。
    2. 获取输入，获取用户的鼠标或者键盘输入，并作出对应的响应。
   

   确定一种通信方式可以让 dock 和插件通信，直接使用 socket 方式不能通信UI相关的信息，共享 buffer 来实现显示 = 换个类似的上层封装，可以接受 UI 相关 —“显示服务器！”

   linux上的显示服务器有xorg，wayland等。采用 wayland 的原因是现代化，方便扩展，并且 Qt 做好了 qt-wayland 的上层封装很方便开发者去开发Wayland相关。

wayland 简单介绍

1. wayland 是什么

   wayland 是x11的取代品，wayland是一套应用程序用于获取用户输入和显示的协议。wayland

   正好与插件的需求相切合，用于显示和获取输入。

   显示和输入的两方面问题

   wayland中如何显示？ surface

   如何暴露插件属性和插件交互？ shell-surface

2. wayland 有什么好处

   1. 更现代化的设计
   2. 更低的延迟
   3. 更好的性能
   4. 更好的安全性
   5. 更简单的代码库

3. shell-surface介绍

   显示比较好理解，surface 是wayland中需要渲染的一片区域。

   那 shell-surface 是什么呢？

   shell-surface 是具有元数据属性的 surface。它可以具有各种属性比如窗管中定义的窗口标题，窗口类型，窗口状态等，还具有布局和排列的能力和交互响应等。

dock 插件接口介绍

1. dock 提供给插件的接口

   pluginproxyinterface.h

2. 插件提供给dock的接口

   pluginsiteminterface.h

3. 之前的工作流程

   dock 通过 pluginloader 将插件加载到 pluginmanager，然后对插件进行初始化。

   dock 再根据 pluginmanager 加载进来的插件，去加载对应类型区域的部分。

   比如：

   • 工作区预览（Fixed类型插件） 将显示在 dock 定义的 Fixed 区域
   • 电源按键（system类型插件）显示在 dock 定义的 System 区域
   • 回收站（Tools类型插件）显示在 dock 定义的 Tool 区域
   • 托盘（tray类型）显示在 dock 定义的 Tray 区域
   • 快捷面板将被快捷面板加载，获取到各个插件的快捷面板里面的UI。

4. shell-surafce 与 插件的相似之处

   插件需要按照一定的顺序显示，shell-surface 可以根据窗口的属性进行布局和排列。

   插件需要响应用户的输入，shell-surface 具有交互性和事件处理。

   所以接下来需要定一个自定义类型的 shell surface 来实现dock 插件管理的需求。

通过 shell surface 实现插件加载和通信流程

1. wayland 协议介绍

   wayland 是一套应用程序用于获取用户输入和显示的协议。wayland

   现有的wayland显示协议都不满足dock插件管理的要求，所以定义一套dock的插件管理协议，用于dock插件的显示和响应。

2. 确定对应的shell-surface和对应的wayland协议

   根据上面的内容，输入转换

    插件向dock的接口    ->      wayland request
    dock向插件的接口    ->      wayland event
   

   得出下面一份简单的 Wayland 协议，仍有需要补充部分

3. 制定协议后的工作流程

   1. 加载流程

      1. widget 插件由 widget 的loader进行初始化

      2. 实现一个 widgetplugin 将初始化后的插件和协议的具体实现连接起来。

      3. 将 每个widget 初始化称独立窗口，使用窗口的显示和隐藏控制 shell-surface 的创建和隐藏达到控制插件的注册后的显示与否。

   2. 通信流程

      1. 插件通过 wayland 的request 向 dock 发送插件提供的接口

      2. dock 通过 wayland 的 event 向插件发送 dock 提供的能力

      比如点击事件：

        1. 点击 dock 上面的 item， item 通过 wayland 产生一个自定的 event
      
        2. 该 event 通过 wayland 发送到协议的客户端实现，调用对应的event 处理接口，将事件发送到 widgetplugin实现中。
      
        3. widgetplugin收到转发后的 点击事件，调用插件对应的点击接口
      
        4. 插件响应对应的点击行为。
      

   3. 通过 wayland 后的插件时序图

   

使用Qt wayland 实现协议

0. 工具 qtwayland-scanner 根据协议生成胶水代码

   1.1 客户端自动填充好 request 相关接口的调用逻辑，需要实现收到对应 event 后的处理和 request 如何暴露对外的方式。

   对于 dock 插件来说， event 一般就是 dock 的状态变更，将其关联到对应的信号处理即可，将协议定义的 request 与旧插件接口相关的调用关联起来即可。

   1.2 服务端自动填充好 event 相关接口的调用逻辑，需要实现收到对应的 reqeust 后的处理逻辑和 event 暴露对外的方式。

1. server端（也就是dock本体的合成器）实现

   server 是作为一个 QWaylandCompositorExtension 实现，需要将PluginManager暴露到QML中用于注册到 wayland 合成器中作为受支持的协议。并且需要关联 dock 对应的属性到上面，用于发送对应的 dock 状态变化后的事件。

   通过 Qt的 QML_ELEMENT 和 Q_COMPOSITOR_DECLARE_QUICK_EXTENSION_CLASS() 宏注册到 QML 中作为QWaylandCompositorExtension

   PluginSurface 是由 PluginManager 控制创建，不需要 QML 中创建暴露，但是 PluginSurface 需要响应对应的输入行为，所以一些输入行为接口需要设置成 Q_INVOKABLE 由 QML 直接调用。

   细节：

   1. 实现 DockPluginManager

      class DockPluginManager : public QWaylandCompositorExtensionTemplate<DockPluginManager>, public QtWaylandServer::dock_plugin_manager_v1
      

   2. 实现胶水代码中的虚函数，暴露属性并关联到 event 上，用于向插件通知 dock 的状态变更。

   3. 实现 surface 创建流程，根据 QWaylandSurface 和 QWaylandResource 创建 PluginSurface。

   4. 实现 PluginSurface

      class PluginSurface : public QWaylandShellSurfaceTemplate<PluginSurface>, public QtWaylandServer::dock_plugin_surface
      

   5. 定义对应的属性和对外暴露，用于接收插件上报的属性。

   6. 定义对应的信号，用于插件发生对应的 request 后转发给 dock。

   7. 实现对外的接口，将输入事件转成对应的 event 发送给插件。

2. client端（也就是插件）实现

   由于 widget 插件是使用 Qt5 编写，所以注册方式采用 Qt5 的方式。

   将 PluginManager 通过 QWaylandShellIntegration 和 QWaylandShellIntegrationPlugin 注册到 wayland 的createSurface上。

   当有对应类型的 surface 创建时，便会调用里面的接口。实现 PluginSurface 的创建和 wayland 合成器端的bingding。

   widget 插件将通过 客户端封装的接口来调用 实现后的request 和接受对应的 event。

   细节：

   1. 作为一个 wayland-shell-integration 插件实现

   2. 实现一个 QWaylandShellIntegrationPlugin 和 QWaylandShellIntegration 将 DockPluginManager 的创建和 PluginSurface 的创建注册到 wayland 中

   3. 定义 DockPlugin 作为 QWindow 和 shell-surafce 的桥梁。QWindow， DockPlugin 和 DockPluginSurface 一一对应。

   4. 实现 DockPluginManager

      class DockPluginManager : public QObject, public QtWayland::dock_plugin_manager_v1
      

   5. 将 event 转成对应的信号对外暴露，实现属性关联 request。

   6. 实现 createPluginSurface 接口，创建DockPluginSurface

   7. 实现 DockPluginSurface 并根据 DockPlugin 将对应的 QWindow 关连起来。

      class DockPluginSurface : public QtWaylandClient::QWaylandShellSurface, public QtWayland::dock_plugin_surface
      

   8. 将 event 转成对应的信号暴露给 DockPlugin，并将 DockPlugin 的信号关联到 DockPluginSurface 调用 request 的槽上。

3. widget 插件的接口转到实现的协议上

   widget 插件是一个旧接口对接到新协议的中间类。他通过实现 proxy 的接口来让插件认为它就是 dock 本体。又通过和 dock 插件管理协议的关联，将插件的请求通过 wayland 转发给 dock。

   在 main 中通过 PluginLoader 将插件进行加载，成功加载后构造对应的widgetplugin 对象， widgetplugin 将旧接口 pluginsiteminterface 和 pluginproxyinterface 通过 DockPlugin 接口类与协议关联起来，实现将对应的 wayland event/request 转成 dock 的接口相关。

4. dock 又是如何"抓取"插件

   插件注册到 wayland 合成器后，在dock 的 DockCompositoer 中根据 surface 中定义的 type 属性，将 surface 存入到不同的 Model 中。然后 dock 对应的部分（比如tray部分）将对应的Model（traySurfaceModel）用于 tray 区域的显示，并使用 Qt 提供的 ShellSurfaceItem 将对应的 surface 显示出来。在 dock 上的布局和排列就可以按照 shell-surface 上定义的属性来实现。

   但是对于插件的 tooltip 和 popup 处理特殊一下，主要有两种思路：

   1. tooltip 和 popup 按需提供，需要将对应的 hover 事件转到客户端，然后调用插件接口产生 tooltip/popup 的窗口出来，然后将该窗口贴到 tooltip 和 popup 上去。

   2. tooltip 和popup 上来就注册到wayland中，dock 按需将对应的 item 贴到 dock 的 tooltip/popup 上去。

   目前采用的是第二种方案，但是对于网络插件自身有判断，不能同时产生 tooltip 和 popup，两者只可存在一个，导致目前网络插件没有对应的 tooltip 产生。

实现后的效果

dde-shell 中插件与dock分进程，目前托盘插件正常显示和响应对应输入，tooltip和popup正常处理。

所有插件各自独立进程

畅想和待做

1. 对于有输入插件（比如网络插件，输入情况的支持需要确认，应该是需要添加输入法协议的支持）

2. 不同类型的插件需要准备多种loader

待做：

1. 实现一个 QML loader 并完善 QML的支持，用于编写 QML 插件。

k3s 调度问题

k8s 默认调度器不会更具节点的实际负载进行调度，只会根据request中申请的资源来。所以会导致多数的部署都是往一台比较强劲的节点上，或者新加入的节点不会有任何的pod分配过来。

metrics-server

使用 k8s 默认的metrics-server 来获取节点资源使用情况

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

load-watcher

为 trimaran 打分时提供当前node的资源使用情况数据。 上游项目地址: https://github.com/paypal/load-watcher 镜像: https://github.com/tsic404/docker-images/pkgs/container/load-watcher

为了 load-watcher 方便读取集群各个节点的资源使用信息，将kubeconfig作为configmap传递到容器中，并指定 KUBE_CONFIG 环境变量。

--- # kube-config configmap
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-config
  labels:
    app: load-watcher
  namespace: loadwatcher
immutable: true
data:
  kube-config: |
    xxxxx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: load-watcher-deployment
  namespace: loadwatcher
  labels:
    app: load-watcher
spec:
  replicas: 1
  selector:
    matchLabels:
      app: load-watcher
  template:
    metadata:
      labels:
        app: load-watcher
    spec:
      containers:
      - name: load-watcher
        image: ghcr.io/tsic404/load-watcher:latest
        env:
         - name: KUBE_CONFIG
           value: /kube-config
        ports:
        - containerPort: 2020
        volumeMounts:
          - name: kube-config
            mountPath: /kube-config
            subPath: kube-config
      volumes:
        - name: kube-config
          configMap:
            name: kube-config
            items:
              - key: kube-config
                path: kube-config
---
apiVersion: v1
kind: Service
metadata:
  namespace: loadwatcher
  name: load-watcher
  labels:
    app: load-watcher
spec:
  type: ClusterIP
  ports:
  - name: http
    port: 2020
    targetPort: 2020
    protocol: TCP
  selector:
    app: load-watcher

scheduler-plugins

采用 helm install as a second scheduler 使用 trimaran 插件来根据当前 node 的实际资源占用情况来进行调度。 values.yaml

scheduler:
  name: trimaran
  image: registry.k8s.io/scheduler-plugins/kube-scheduler:v0.26.7
  replicaCount: 1
  leaderElect: false

controller:
  name: scheduler-plugins-controller
  image: registry.k8s.io/scheduler-plugins/controller:v0.26.7
  replicaCount: 1

plugins:
  enabled: ["TargetLoadPacking"]
  disabled: ["NodeResourcesBalancedAllocation", "NodeResourcesLeastAllocated"]

pluginConfig:
- name: TargetLoadPacking
  args:
    watcherAddress: http://load-watcher.loadwatcher.svc.cluster.local:2020

helm install scheduler-plugins as-a-second-scheduler/ --create-namespace --namespace scheduler-plugins -f values.yaml

descheduler

k8s 中pod一旦绑定了节点就不会在进行调度，但是pod运行过程中，pod使用的资源可能会不断变化，这样分配时的平衡就会被打破。所以引入重平衡工具descheduler，让其找到可以可以移除的pod并驱逐他们，重新触发k8s的调度。

helm install descheduler --namespace kube-system descheduler/descheduler --set kind=Deployment

depolyment

由于采用的是将 trimaran 安装成第二调度器，所以需要在 deployment 中显示指明调度器名称

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      schedulerName: trimaran

k3s with multus cni

最近在家部署了一个k3s，用于管理一些家用服务比如jellyfin，homeassistant等，在使用homeassistant时，遇到一些网络问题，在了解k8s一点网络架构后，需要在k8s中安装multus cni，为pod创建额外网口来解决我的问题。

一、安装multus

拉取官方git仓库git clone https://github.com/k8snetworkplumbingwg/multus-cni.git

然后打开code multus-cni

修改deployments/multus-daemonset.yml

需要修改有三处

1. cniVersion

k3s 默认采用的 flannel 的 cniVersion 已经升级到 1.0.0 版本，为了 multus 可以正确生成 flannel 相关配置，需要把cniVersion提高到 1.0.0

2. kubeconfig

multus 默认读取 kubeconfig 的路径为 /etc/cni/net.d/multus.d/multus.kubeconfig，但是 k3s 将相关配置保存在 /var/lib/rancher/k3s/agent/etc/ 中，导致 cni 相关的配置（下面volume）会改动到此，所以需要修改 kubeconfig 路径到 /var/lib/rancher/k3s/agent/etc/cni/net.d/multus.d/multus.kubeconfig

3. volume

为了配置 k3s 资源的默认保存路径 将 /etc/cni/net.d 修改为 /var/lib/rancher/k3s/agent/etc/cni/net.d 将 /opt/multus/bin 修改为 /var/lib/rancher/k3s/data/current/bin

生成的diff文件

diff --git a/deployments/multus-daemonset.yml b/deployments/multus-daemonset.yml
index ab626a66..28eb48af 100644
--- a/deployments/multus-daemonset.yml
+++ b/deployments/multus-daemonset.yml
@@ -125,7 +125,7 @@ data:
       },
       "delegates": [
         {
-          "cniVersion": "0.3.1",
+          "cniVersion": "1.0.0",
           "name": "default-cni-network",
           "plugins": [
             {
@@ -145,7 +145,7 @@ data:
           ]
         }
       ],
-      "kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig"
+      "kubeconfig": "/var/lib/rancher/k3s/agent/etc/cni/net.d/multus.d/multus.kubeconfig"
     }
 ---
 apiVersion: apps/v1
@@ -183,8 +183,8 @@ spec:
         command: ["/thin_entrypoint"]
         args:
         - "--multus-conf-file=auto"
-        - "--multus-autoconfig-dir=/host/etc/cni/net.d"
-        - "--cni-conf-dir=/host/etc/cni/net.d"
+        - "--cni-version=1.0.0"
+        - "--multus-kubeconfig-file-host=/var/lib/rancher/k3s/agent/etc/cni/net.d/multus.d/multus.kubeconfig"
         resources:
           requests:
             cpu: "100m"
@@ -222,10 +222,10 @@ spec:
       volumes:
         - name: cni
           hostPath:
-            path: /etc/cni/net.d
+            path: /var/lib/rancher/k3s/agent/etc/cni/net.d
         - name: cnibin
           hostPath:
-            path: /opt/cni/bin
+            path: /var/lib/rancher/k3s/data/current/bin
         - name: multus-cfg
           configMap:
             name: multus-cni-config

修改完后，部署 multus cni 的 daemonset 即可。

二、配置 cni 网络

根据我家的网络情况，我需要在homeassistant中访问lan和iot两个网段。所以定义了两个NetworkAttachmentDefinition。 一个 macvlan 对 lan 的访问，一个 vlan 对 iot 的访问。 cni中更多网络介绍 https://www.cni.dev/plugins/current/main/。

kind: NetworkAttachmentDefinition
metadata:
  name:  lan
  namespace: homeassistant
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "type": "macvlan",
      "master": "eth0",
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.18.0/24",
        "rangeStart": "192.168.18.32",
        "rangeEnd": "192.168.18.100",
        "routes": [
          { "dst": "192.168.18.0/24" }
        ]
      }
    }
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name:  iot
  namespace: homeassistant
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "type": "vlan",
      "master": "eth0",
      "vlanId": 2,
      "linkInContainer": false,
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.32.0/24",
        "rangeStart": "192.168.32.3",
        "rangeEnd": "192.168.32.100",
        "routes": [
          { "dst": "192.168.32.0/24" }
        ]
      }
    }

三、使用 multus

使用前需要注意，k3s 中不包含一些 cni 比如vlan，使用时会报vlan找不到的错误。 此时需要自己拉取 cni plugins 的仓库，编译对应的 cni。 git clone https://github.com/containernetworking/plugins 并将编译好的二进制放到 k3s data 下的 bin 里面。 然后在 pod 中加上下面内容即可。

metadata:
    annotations:
        k8s.v1.cni.cncf.io/networks: |
        [
            {
                "name": "lan",
                "ips": ["192.168.18.32/24"],
                "namespace": "homeassistant",
                "interface": "net1",
                "mac": "32:44:0b:5a:0e:2e"
            },
            {
                "name": "iot",
                "ips": ["192.168.32.3/24"],
                "namespace": "homeassistant",
                "interface": "net1.2",
                "mac": "00:e0:4c:68:02:3d"
            }
        ]

这样homeassistant 就会有 loopback，eth0，net1，net1.2 四个网口。

四、一些问题的处理方式

1. 遇到不断加 ip 到 net1 和 eth0。从 rangeStart 直到 rangeEnd 为止。

将 multus daemonset停下，清理各个节点 multus 相关的配置，重新部署 multus。

2. 报 loopback 或者 macvlan 等非 链式调用。

在对应节点上运行 k3s check-config。查看 cni 相关的(md5sum, link)是否正常。

树莓派使用网络启动

pi 通过 tftp 和 dhcp 拉取 boot 分区的内容。然后把拉取的 boot 分区中的 initramfs 加载到内存，通过 内核启动参数（nfsroot，iscsi）和iniramfs 完成网络启动过程。

其他比如 rock5b 不支持 tftp, 但是可以用后面 initramfs 和内核参数。所以理论上可以做到本地 sd 卡只存放 boot 分区，然后通过网络启动 rootfs。

一、 tftp-hpa

1. 安装 tftp-hpa

sudo apt install tftp-hpa

2. 修改配置文件

sudo vim /etc/default/tftpd-hpa

修改一下配置

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/data/pxe/"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"

3. 重启 tftp-hpa 服务

sudo systemctl restart tftp-hpa

4. 在 TFTP_DIRECTORY 放置对应的网络启动文件。

将 pi img 中 boot 分区相关的文件放到对应的目录下，下文修改 boot 相关内容时，需要同步 tftp server中。

root@rock5b:~# ls /data/pxe/
rapi4-1_boot  rapi4-2_boot  rapi4-3_boot rpi4-1-root.img  rpi4-2-root.img  rpi4-3-root.img

二、 nfsroot

相关链接： https://docs.kernel.org/admin-guide/nfs/nfsroot.html

1. 安装nfs服务

sudo apt install nfs-kernel-server

2. 生成nfs路径

mkdir /data/pxe/nfsroot1

vim /etc/exportfs

加入以下内容

# rootfs
/data/pxe/nfsroot1    192.168.28.1/24(rw,no_root_squash,async,insecure)

# boot
/data/pxe/ 192.168.28.1/24(rw,no_root_squash,async,insecure)

然后在 pi 上尝试挂载 nfs，并将 rootfs 同步到nfs中。

mount 192.168.18.14:/data/pxe/nfsroot1 /mnt
rsync -avz --exclude /mnt --exclude /sys --exclude /proc --exclude /run --exclude /boot / /mnt

修改 nfsroot 中的 fstab(/mnt/etc/fstab)，将一些 tmp 和 log 挂载为 tmpfs 节省网络资源。

proc            /proc           proc    defaults          0       0
192.168.18.14:/data/pxe/rapi4-1_boot/ /boot nfs defaults,vers=4.1,proto=tcp 0 0
tmpfs   /tmp         tmpfs   rw,nodev,nosuid,size=2G,mode=777          0  0
tmpfs   /var/log         tmpfs   rw,nodev,nosuid,size=2G,mode=777          0  0
tmpfs   /var/tmp         tmpfs   rw,nodev,nosuid,size=2G,mode=777          0  0

3. 修改pi内核启动参数

生成initramfs。

update-initramfs -u -k `uname -r`

然后修改boot/config.txt, 加载initramfs。

vim /boot/config.txt

加入以下内容，注意修改成对应的 iniramfs 文件。

initramfs initrd.img-6.1.21-v8+ followkernel

修改内核参数 /boot/cmdline.txt

console=serial0,115200 console=tty1 ip=192.168.18.15::192.168.18.1:255.255.255.0:rpi4-1:eth0:off root=/dev/nfs nfsroot=192.168.18.14:/data/pxe/nfsroot1,tcp,rw rootfstype=nfs rootwait elevator=deadline cgroup_memory=1 cgroup_enable=memory cgroup_enable=cpuset

注意将修改后的 boot 同步到 tftp server pxe 上。

三、 bootcmd

1. 查看当前bootloader配置

root@rpi4-1:~# vcgencmd bootloader_config
[all]
BOOT_UART=0

2. 提取配置文件

cp /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2023-05-11.bin pieeprom.bin
rpi-eeprom-config pieeprom.bin > bootconf.txt

3. 设置配置文件

# bootconf.txt

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=4000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=192.168.18.14
TFTP_PREFIX=1
BOOT_ORDER=0x21
SD_BOOT_MAX_RETRIES=3
NET_BOOT_MAX_RETRIES=5
TFTP_PREFIX_STR=rapi4-1_boot/

4. 一些配置说明

• BOOT_UART

  设置为1，表示使能GPIO 14和 15的输出，也就是我们可以连接串口打开信息。其串口参数为波特率115200，8位，无奇偶校验位，1位的停止位。

• TFTP_PREFIX

  0 - Use the serial number e.g. “9ffefdef/”

  1 - Use the string specified by TFTP_PREFIX_STR

  2 - Use the MAC address e.g. “DC-A6-32-01-36-C2/”

  Default: 0

  自己定义TFTP_PREFIX_STR，方便识别 pi，所以设置成 1。

• TFTP_PREFIX_STR

  当TFTP_PREFIX设置为1的时候，可以设置TFTP_PREFIX_STR的路径。这样每个 pi 通过有不同的 TFTP_PREFIX_STR 从而启动不同的 rootfs 中去。

• TFTP_IP

  设置TFTP服务器的IP地址，树莓派的IP地址是通过DHCP自动获取的。

• BOOT_ORDER

  该参数配置了不同的启动模式：

  • 0x0 - NONE (stop with error pattern)
  • 0x1 - SD CARD
  • 0x2 - NETWORK

5. 将配置写回到pieeprom.bin

rpi-eeprom-config --out pieeprom-new.bin --config bootconf.txt pieeprom.bin

6. 更新eeprom

sudo rpi-eeprom-update -d -f ./pieeprom-new.bin

四、 iscsi

nfs方式无法支持docker的overlyfs。

iscsi 搭建 https://www.cnblogs.com/pipci/p/11617680.html

1. 搭建iscsi 安装tgt sudo apt install -y tgt

2. 创建 rootfs img 文件

dd if=/dev/zero of=/data/pxe/rpi4-1-root.img bs=1G count=128 status=progress

root@rock5b:~# cat /etc/tgt/conf.d/rpi.conf 
default-driver iscsi

<target iqn.cluster.tsic.top:rpi4.rootfs1>
        backing-store /data/pxe/rpi4-1-root.img
</target>

<target iqn.cluster.tsic.top:rpi4.rootfs2>
        backing-store /data/pxe/rpi4-2-root.img
</target>

<target iqn.cluster.tsic.top:rpi4.rootfs3>
        backing-store /data/pxe/rpi4-3-root.img
</target>

然后使用 iscsiadm 加载iscsi 磁盘。

iscsiadm -m discovery -t st -p 192.168.18.14
iscsiadm --mode node --targetname "iqn.cluster.tsic.top:rpi4.rootfs2" --portal 192.168.18.14 --login

lsblk即可看到一个 sdX 磁盘。然后为该磁盘分区，将 / 内容同步到磁盘中即可。

2. 修改pi内核启动参数

分区时会有相关输出，或者使用 blkid 查询分区的 UUID。 root=UUID=xxxxxxxxxxxxxxxxxxx

console=serial0,115200 console=tty1 root=UUID=c48523b6-8262-416c-a5da-9dbe6656ac70 ip=192.168.18.15::192.168.18.1:255.255.255.0:rpi4-1:eth0:off ISCSI_INITIATOR=iqn.2016-04.com.open-iscsi:ca33685ee2a ISCSI_TARGET_NAME=iqn.cluster.tsic.top:rpi4.rootfs1 ISCSI_TARGET_IP=192.168.18.14 ISCSI_TARGET_PORT=3260 rw rootfstype=ext4 fsck.repair=yes rootwait elevator=deadline cgroup_memory=1 cgroup_enable=memory cgroup_enable=cpuset

其他一些参数 iscsi 认证相关 ISCSI_USERNAME= ISCSI_PASSWORD=

零. 前言

部署home nas已经有段时间了，将之前踩过的的一些坑梳理一下，做下总结。

一. 硬件

1. x86 硬件

• aio

cpu: i5-11500t

ram: 32G x 2

nic: x540-T2 x 1(10G x 2),RTL8125 2.5GbE x 1

disk: 2t nvme x 1, 4T HHD x 6

• Game Station

cpu: i5-11500

ram: 16G x 4

nic: RTL8125 2.5GbE x 1, ax210 x 1

disk: 1t nvme x 1, 2T SSD x 2

gpu: RTX 3060 mini

2. arm64 硬件

• sev:

  cpu: rk3588

  disk: 1t nvme

  ram: 16G

• rpi4 x 2:

  cpu: Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.8GHz ram: 4G

3. 交换机

ikuai 2.5G router 支持 2.5G x 8 和万兆光上行

4. qnap 301w

满血wifi6, 10G x 2, 1G x 4

二. 网络拓扑

家用主要将访客，物联网和日常网段划分使用。未对存储和业务划分对应专属网段（没必要？）。

lan: 192.168.18.1/24

Iot: 192.168.32.1/24

Guest: 192.168.100.1/24

其中lan 区域

• 192.168.18.1 主软路由
• 192.168.18.2 lan AP地址
• 192.168.18.7 aio pve地址
• 192.168.18.13 master k8s master地址
• 192.168.18.14 rock5b k8s rock5b node 地址
• 192.168.18.15 rpi4-1 k8s rpi4-1 node 地址
• 192.168.18.16 rpi4-2 k8s rpi4-2 node 地址
• 192.168.18.25 truenas nas地址
• 192.168.18.32 homeassistant hass 地址
• 192.168.18.100-200 lan dhcp 地址

IOT 区域

• 192.168.32.2 IOT AP地址
• 192.168.32.3 hass 地址
• 192.168.32.100-200 IOT dhcp 地址

Guest 区域

• 192.168.100.2 Guest AP地址
• 192.168.100.100-200 Guest dhcp 地址

VPN 区域

• 172.28.0.0/16

VPN 路由规则

• 192.168.18.0/24 via 172.28.168.8

三. 底层系统安装

1. pve 安装(x86)

1. 下载ISO
2. BIOS修改相关设置
   • Secure Boot
   • SRIOV
   • FastBoot
3. 刷写ISO到U盘，或者使用ventoy
4. 按正常步骤安装pve
5. 开启iommu vim /etc/default/grub 在GRUB_CMDLINE_LINUX_DEFAULT中加入下面内容 intel_iommu=on iommu=pt
6. 开启sriov

检查网卡是否支持sriov

lspci -s 02:00.0 -vvv | grep Capabilities 
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
        Capabilities: [a0] Express (v2) Endpoint, MSI 00
        Capabilities: [e0] Vital Product Data
        Capabilities: [100 v2] Advanced Error Reporting
        Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
        Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
        Capabilities: [1d0 v1] Access Control Services

存在Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)即支持sriov。

使用systemd service在开机时启动nic的sriov vim /etc/systemd/system/sriov.service填入以下内容

注意：

1. enp2s0f0 是我pc的网卡，需要修改成自己pc的对应网卡

[Unit]
Description=Script to enable SR-IOV on boot

[Service]
Type=simple
ExecStartPre=/usr/bin/bash -c '/usr/bin/echo 6 > /sys/class/net/enp2s0f0/device/sriov_numvfs'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 up'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 vf 0 mac fe:eb:98:20:68:77'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 vf 1 mac 32:ec:28:b3:f8:36'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 vf 2 mac 1a:2c:d1:69:e4:66'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 vf 3 mac 4e:39:21:92:5f:00'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 vf 4 mac 92:32:89:31:0b:9a'
ExecStartPre=/usr/bin/bash -c '/usr/bin/ip link set enp2s0f0 vf 5 mac 6a:a0:55:be:ca:11'
ExecStart=/usr/bin/bash -c '/usr/bin/echo done'
Restart=on-failure

[Install]
WantedBy=multi-user.target

1. openwrt 虚拟机安装

pve创建虚拟机，不选择iso media然后使用qm import disk 导入 openwrt 的镜像。

qm disk import 100 ./openwrt-xxx-xxx-generic-squashfs-combined-efi.img local-lvm

pci 直通一个sriov网卡作为LAN口。

pci 直通RTL8125 2.5G 网口作为WAN口。

OP vlan划分

在OP网桥设置

VLAN 1: 在LAN上未Untag，默认加入到18网段

VLAN 2: 在LAN上打Tag

VLAN 3: 在LAN上打Tag

2. truenas 安装

安装truenas scale，基于debain系统可方便开启Qemu User Agent

配置LAN地址192.168.18.25

3. k3s master in lxc

首先开启 pve 的转发功能

sysctl net.ipv4.ip_forward=1
sysctl net.ipv6.conf.all.forwarding=1
sed -i 's/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/g' /etc/sysctl.conf
sed -i 's/#net.ipv6.conf.all.forwarding=1/net.ipv6.conf.all.forwarding=1/g' /etc/sysctl.conf

创建lxc容器后修改lxc配置

cat /etc/pve/lxc/200.conf

arch: amd64
cores: 6
features: fuse=1,mknod=1,mount=nfs;cifs,nesting=1
hostname: master
memory: 8192
ostype: debian
rootfs: local-lvm:vm-200-disk-0,size=128G
swap: 0
tty: 1
lxc.net.0.type: phys
lxc.net.0.name: eth0
lxc.net.0.link: enp2s0f0v5
lxc.apparmor.profile: unconfined
lxc.cap.drop: 
lxc.mount.auto: "proc:rw sys:rw"
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

k3s 需要一下配置

lxc.apparmor.profile: unconfined
lxc.cap.drop:
lxc.mount.auto: "proc:rw sys:rw"
lxc.cgroup2.devices.allow: c 10:200 rwm

然后在lxc中开启宿主机挂载点共享

echo '#!/bin/sh -e
ln -s /dev/console /dev/kmsg
mount --make-rshared /' > /etc/rc.local
chmod +x /etc/rc.local
reboot

最后开始安装k3s

2. pve 安装(arm64)(暂时未安装arm64 pve)

首先按照rock5b官方指导刷写debian系统到nvme中，刷写spi到sd卡。

然后使用foxi的pve-arm64仓库安装pve-manager

1. arm64 hass 安装

创建虚拟机不使用iso且不创建默认启动磁盘，arm64虚拟机需要uefi引导，需要efi disk。 然后使用下面命令导入下载的hass镜像

qm disk import

扩容到16G

2. k3s in lxc

同x86

3. rpi4 网络启动

参考 Rpi4 Diskless

四. hass 接入与个人 cloud game

hass 俩ip

192.168.32.3 IOT网段链接

192.168.18.32 LAN网段访问

1. windows唤醒与关机

WOL与RPC shutdown

BIOS 开启 WOL，windows 网卡配置开启WOL与魔术包唤醒

hass 创建一个 package

注： 1. 官方 ha 中不包含 samba 相关组件，所以无法调用 net rpc 相关命令

windows:
  switch:
    - platform: wake_on_lan
      name: windows_game
      mac: D8:BB:C1:59:7A:17
      host: 192.168.18.154
      turn_off:
        service: shell_command.windows_shutdown
        data:
          ip: 192.168.18.154
          user: !secret windows_tsic

  shell_command:
    windows_shutdown: net rpc shutdown -I {{ ip }} -U {{ user }} -t 60 -C "Home Assistant is shutting down this PC. This cannot be canceled. Please save your work!"

  homeassistant:
    customize:
      switch.windows_game:
        friendly_name: Game Station
        icon: mdi:microsoft-windows

2. 串流方案

sunshine + moonlight

parsec

3. 远程桌面

Microsoft Remote Desktop

五. 常用服务部署

1. zerotier VPN使用

1. 注册zerotier
2. 创建一个网络
3. 对应设备安装zerotier，然后加入该网络中
4. 创建路由规则，让访问lan的流量从OP转发。

2. jellyfin 搭建

1. lxc 支持 dri 挂载
2. 编写 k8s 配置
3. 部署 jellyfin
4. Live TV

LiveTV项目地址

EPG格式TV信息

3. trilium note 搭建

OBS 介绍

open build service简称OBS，是openSUSE主导开发的通用构建系统，用于从源码的自动构建和包分发。

假设读者已经了解debian系打包📦相关。本文中对osc的介绍主要作为OBS的CLI接口，本地构建方面可参考osc 本地构建。

OBS 打包流程

本文以deepin(debian系)构建，deepin OBS实例为例

1. 创建Project 每个普通账号只有自己的home project。比如：home:tsic404

   也可以可以在Subprojects一栏，创建subproject。比如创建 home:tsic404:ddeOnDebian。 然后

   osc co home:tsic404:ddeOnDebian
   

   home:tsic项目内容不会包含home:tsic:ddeOnDebian,两个是各自 “相对独立” 的project。

2. 添加构建仓库 在OBS web界面点击Repository，然后add一个Repository到该Project中。 如上图add debian sid repo。

   或者使用osc meta prj修改project使用的仓库。

   <project name="home:tsic404:ddeOnDebian">
      <title/>
      <description/>
      <person userid="tsic" role="maintainer"/>
      <repository name="Debian_Sid">
         <path project="Debian:Sid" repository="standard"/>
         <path project="Debian:ddeExtra" repository="Debian_Sid"/>
         <arch>x86_64</arch>
      </repository>
   </project>
   

3. 创建Package 可以在web点击create package或者使用osc

   cd home:tsic404:ddeOnDebian
   osc mkpac dtkcore
   

4. 上传打包文件 点击dtkcore，然后点击add local file。选择dtkcore相关打包文件。即可上传到OBS的Project中。 或者使用 osc

   cd dtkcore
   cp xxxx/dtkcore/* ./
   osc add *
   osc ci -m "init"
   

5. OBS开始构建 在dtkcore右侧即可看到对应的状态 点击对应仓库的架构即可看到构建日志，或者使用osc 也可以查看构建日志。

   osc buildlog Debian_Sid x86_64
   

总结：

使用OBS进行打包，首先先创建Project，添加构建使用的仓库，然后上传需要打包的package到project中，等待OBS构建完成。Project + 构建仓库决定OBS publish的一个仓库。

OBS 打包优化(service)及SCM集成

传统方式需要用户自己手动上传打包需要的全部文件xxxx.org.tar.gz xxx.debain.tar.gz xxxx.dsc三件套，这个过程比较麻烦。我们可以使用OBS的service来生成这些必要的文件。

OBS service介绍

service 简单来说就是一些辅助型的脚本，来协助生成和修改打包所需要的文件。

比如:

使用obs_gbp为git仓库生成debian构建需要的dsc等。

使用set_version动态修改版本号。

使用download_url从指定的url(比如release)下载压缩包等。

service有自己的mode(运行的时机) service的runmode有

注：

1. 在对应时间运行service时，需要此时安装该service。比如trylocal需要本机，server需要server安装，buildtime需要worker安装。比如选择buildtime，但是worker没有对应service的依赖时，构建就会处于unresolvable状态。

2. build.deepin.com提供了download_files,download_url,obs_gbp，obs_scm，tar_scm，set_version，tar几种服务。

使用service过程

cd home:tsic404:ddeOnDebain
vim _service

加入以下内容

<services>
   <service name="obs_gbp">
      <param name="url">https://github.com/linuxdeepin/dtkcore.git</param>
      <param name="scm">git</param>
      <param name="exclude">.git</param>
      <param name="exclude">.github</param>
      <param name="versionformat">@CHANGELOG@@DEEPIN_OFFSET@</param>
      <param name="gbp-dch-release-update">enable</param>
   </service>
</services>

osc add _service
osc commit -m "init"

然后web看到service is running的提示，等待service运行完毕，即可看到对应文件的生成。

使用service可以极大方便使用源代码服务器(git等)的项目打包构建。

workflow介绍

注：OBS-api需要在2.11版本之后才有workflow功能

workflow 的步骤有

1. branch_package

   test_build:
      steps:
         - branch_package:
            source_project: deepin:Develop:main
            source_package: %{SCM_REPOSITORY_NAME} 
            target_project: deepin:CI
      filters: 
         event: pull_request
   

2. link_package

   test_build:
      steps:
         - link_package:
            source_project: deepin:Develop:main
            source_package: %{SCM_REPOSITORY_NAME} 
            target_project: deepin:CI
   
         - configure_repositories:
            project: deepin:CI
            repositories:
               - name: deepin_develop
                 paths:
                  - target_project: deepin:CI
                    target_repository: deepin_develop
                 architectures:
                  - x86_64
                  - aarch64
   
      filters:
         event: pull_request
   

3. configure_repositories

   configure_repositories 如上面所示，用于配置link_package后的project构建仓库。

4. set_flag

   支持的flag有

   • lock (default status disable)
   • build (default status enable)
   • publish (default status enable)
   • debuginfo (default status disable)
   • useforbuild (default status enable)
   • binarydownload (default status enable)
   • sourceaccess (default status enable)
   • access (default status enable)

5. trigger_service

   commit_build:
      steps:
         - trigger_services:
            project: deepin:Develop:community
            package: %{SCM_REPOSITORY_NAME}
   

   重新trigger 该package的service，用于更新commit仓库的代码。

6. rebuild_package

   触发pacakge的rebuild。

使用service与workflow

1. SCM + service 持续集成 osc token 创建SCM token github 填写对应的webhook 推送.obs/workflows.yml到仓库中，该文件定义了OBS workflow的步骤。

OBS 集成姿势

在package 左侧点击Submit Package。 然后填写如下内容。 submit 提交。将生成一个request，等待管理员审核。

project管理员在tasks看到所有的请求

点击对应请求，approve或者reject request。

approve后 package将提交到target project中。

osc 本地构建

deepin 20环境

sudo apt install osc obs-build rpm debugedit=4.14.2.1+dfsg1.1-1+dde

把obs-build设置免密。

sudo visudo

加入以下内容

LOGIN    ALL = NOPASSWD: /usr/bin/build
LOGIN    ALL = NOPASSWD: /usr/bin/osc

osc co deepin:Develop:main apt
cd deepin\:Develop\:main/apt
osc build xxxxx.dsc

即可使用OBS上的仓库进行构建。

deepin OBS SCM一些常见问题

1. GitHub webhooks未触发

   大概率是网络问题导致，需要在 GitHub webhook 配置中redeliver该次失败的请求。

2. GitHub webhooks传递过来但是没有对应仓库和架构的情况返回

   需要到OBS看看是不是构建前的准备工作出现问题，比如service失败，依赖处于 unresolvable，broken。只有成功构建的 succeeded 和失败的 failed 才会返回到GitHub。

备注

参考文档

1. OBS 用户手册

   1. https://openbuildservice.org/help/manuals/obs-user-guide/
   2. https://openbuildservice.org/files/manuals/obs-user-guide.pdf
   3. https://openbuildservice.org/files/manuals/obs-user-guide.epub

2. OBS 管理员手册

   1. https://openbuildservice.org/help/manuals/obs-admin-guide/
   2. https://openbuildservice.org/files/manuals/obs-admin-guide.pdf
   3. https://openbuildservice.org/files/manuals/obs-admin-guide.epub

3. suse wiki

   1. https://zh.opensuse.org/Category:构建服务
   2. https://en.opensuse.org/Category:Build_Service

4. osc https://en.opensuse.org/openSUSE:Build_Service_Tutorial

5. OBS 调度 https://wiki.tizen.org/OBS_scheduler_internals

6. OBS 开发 wiki https://github.com/openSUSE/open-build-service/wiki

方法

在promox ve forum中找到了隐藏虚拟机标识的配置。

args: -cpu 'host,-hypervisor,+kvm_pv_unhalt,+kvm_pv_eoi,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,kvm=off,hv_vendor_id=intel'