Posts

背景 为什么要将插件分进程 原有的dde-dock经常因为插件问题导致假死崩溃卡顿等问题，插件与dock在相同进程就避免不了因为插件代码质量等导致的同生共死，所以有将插件独立进程出去将插件的影响范围降低到最小，只影响自己。 分进程有什么好处与坏处 分进程后带来的好处可以从以下几个方面体现： 1. 兼容性：只要确定了插件进程与dock进程通信的方式，可以使用这种通信方式都可以被dock当作插件加载上来。无论widget，qml，qt5/6还是其他语言等。 2. 流畅性：dock自身更加专注于dock本身的业务逻辑，不需要发生变化时去更新插件的状态，也不会被插件阻塞住。 3. 稳定性：dock进程只有dock自身，不再受插件的影响。 缺点方面： 最主要的一点就是总体的系统资源占用会比之前稍高。 开发复杂度和维护复杂度都会上升。 怎么去分进程 插件的主要作用： 1. 用于显示，显示插件的UI部分。 2. 获取输入，获取用户的鼠标或者键盘输入，并作出对应的响应。 确定一种通信方式可以让 dock 和插件通信，直接使用 socket 方式不能通信UI相关的信息，共享 buffer 来实现显示 = 换个类似的上层封装，可以接受 UI 相关 —“显示服务器！” linux上的显示服务器有xorg，wayland等。采用 wayland 的原因是现代化，方便扩展，并且 Qt 做好了 qt-wayland 的上层封装很方便开发者去开发Wayland相关。 wayland 简单介绍 wayland 是什么 wayland 是x11的取代品，wayland是一套应用程序用于获取用户输入和显示的协议。wayland 正好与插件的需求相切合，用于显示和获取输入。 显示和输入的两方面问题 wayland中如何显示？ surface 如何暴露插件属性和插件交互？ shell-surface wayland 有什么好处 更现代化的设计 更低的延迟 更好的性能 更好的安全性 更简单的代码库 shell-surface介绍 显示比较好理解，surface 是wayland中需要渲染的一片区域。 那 shell-surface 是什么呢？ shell-surface 是具有元数据属性的 surface。它可以具有各种属性比如窗管中定义的窗口标题，窗口类型，窗口状态等，还具有布局和排列的能力和交互响应等。 dock 插件接口介绍 dock 提供给插件的接口...

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....

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 需要修改有三处 cniVersion k3s 默认采用的 flannel 的 cniVersion 已经升级到 1.0.0 版本，为了 multus 可以正确生成 flannel 相关配置，需要把cniVersion提高到 1.0.0 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 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....

树莓派使用网络启动 pi 通过 tftp 和 dhcp 拉取 boot 分区的内容。然后把拉取的 boot 分区中的 initramfs 加载到内存，通过 内核启动参数（nfsroot，iscsi）和iniramfs 完成网络启动过程。 其他比如 rock5b 不支持 tftp, 但是可以用后面 initramfs 和内核参数。所以理论上可以做到本地 sd 卡只存放 boot 分区，然后通过网络启动 rootfs。 一、 tftp-hpa 安装 tftp-hpa sudo apt install tftp-hpa 修改配置文件 sudo vim /etc/default/tftpd-hpa 修改一下配置 # /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/data/pxe/" TFTP_ADDRESS=":69" TFTP_OPTIONS="--secure" 重启 tftp-hpa 服务 sudo systemctl restart tftp-hpa 在 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....

零. 前言 部署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...