Intel核显vGPU实践
一、前言 目前来说，个人能获得的最低的GPU就是蓝厂的核心显卡了。虽然用来打游戏有点鸡肋，但是其编解码性能可以说是相当无敌，用来进行视频转码、人脸识别等小规模应用非常安逸。 但是，绝大多是人的性价比选择当然是ALL IN BOOM咯，对于显卡就有直通Passthrough和单根虚拟化SR-IOV两条路子，所以到这里就不得不再掰扯一下虚拟化能力了。Passthrough的好处就是100%的性能，而缺点就是一个设备只能被一个虚拟机独占。SR-IOV则可以将一个设备变成多个VF，类似于分身，只是性能强弱由分出的VF多少来决定，每个VF都具备本体的功能且每个都能通过直通的方式分配给不同虚拟机，同时物理机上仍然有显卡本体可供使用，但是但是但是，蓝厂家只有12代及以上的CPU核显是支持SR-IOV的；绿厂的卡原则上只有专业卡的Grid驱动支持vGPU，但20系及以下可以通过vgpu_unlock实现，30系列及以上只是有消息（Nvidia vGPU技术防线被攻破，30/40系解锁已成）但是未公开方法；而农企更不用说了。 目标：在PVE上开启核显SR-IOV并直通给虚拟机，再将虚拟机配置为k...
K3S再进化
一、前言 自从上次折腾k3s已经过去很久了，当初在部署完成后也尝试将常用服务容器化统一管理，但是无奈于部署文件编写工作量巨大、硬件平台性能捉襟见肘且部署的应用数量很少以至于看上去完全像是为了这碟醋包了顿饺子。快进到现在的2025年，一切都不同于往日了。硬件方面首先焕然一新，有独立120+T的存储服务器，有独立的应用服务器，也有独立的防火墙及万兆交换机。所以在这一切的加持下，一切的复杂系统都变得可能。 目前应用完全使用docker在跑，不完全统计已经有50个以上的容器在运行。带来的问题也日益凸显，管理不便、配置等文件分散、监控困难、无高可用迁移能力等等。所以在这个时间点，又想起来老朋友----k3s。 所以本次的计划也是进行一个完备的集群部署。首先是实现多服务器节点，将节点分布在3台物理服务器上（PVE作为底层），数据统一由集中的存储负责；其次对于集群，需要有负载均衡器，以支持故障转移，需要有分布式存储卷；针对编解码需求，建立vGPU节点。 k3s所有节点均以虚拟机形式部署，版本就选择最新的。其他配置如下： Cilium：作为网络插件CNI，启用Ingress功能，代替kube...
自动化运维之Cloud-Init
一、前言 在PVE中进行测试或者部署集群时，经常需要一次性启动大量虚拟机，如果一台一台手动安装费时费力还容易出错。有没有什么法子可以自动化进行安装？有的有的，cloud-init负责配置虚拟机，terraform负责实现一键部署虚拟机。 本文使用环境配置为： 虚拟化平台：PVE 9.0.6 自动化运维工具：terraform 系统初始化工具：cloud-init 虚拟机系统：Debian 13 参考文章： 基于Cloud-init定制化虚拟机 Terraform PVE Provider文档 二、什么是Cloud-Init 在生产环境，尤其是云服务供应商的大规模生产环境中，如何快速启动一个已初始化的虚拟机是个很重要的问题。针对此需求，cloud-init应运而生，该方案可以快速启动多个虚拟机且同时完成IP、软件源、用户等等配置，开箱即用无需手动一台台安装虚拟机。 使用clolud-init需要有两个先决条件： 虚拟机的系统镜像支持cloud-init且未启动过，即首次启动过程中会查找是否有数据源并进行自动配置 虚拟机有可访问的配置数据源，将按配置初始化系统 1....
私人网盘之NextCloud
5G来了，千兆家宽也有了，但是6aidu网盘还是万年不变的100k/s！！这谁顶得住？其他网盘虽然速度可以，但是依旧存在种种限制，且文件不在自己手里，还得防和谐。自己的数据自己掌控，何不试试自己搭建私人网盘呢？毕竟数据是自己的，就得自己说了算，也不用去忍受小灵通下载速度。（P.S. 2023年5月似乎OneDriver也和谐了） 开源网盘有OwnCloud、青阳网络文件传输系统kiftd、Seafile、蓝眼云盘、NextCloud等选择。Seafile支持企业级协作，功能也极为丰富；Kiftd较为简洁，适合单人共享文件；而NextCloud流传较为广泛，支持插件，功能也极为丰富。我个人的网盘就选择了NextCloud，使用OnlyOffice处理文档等。 部署 Docker 直接上docker！ 由于App较多，不能一个App就起一个数据库，所以这里的数据库是位于另一台虚拟机里的，所有App统一使用，方便维护。 1234567891011121314151617181920212223242526272829303132333435363738394041424344454...
全自动观影追剧
受够了爱优腾的付费？受够了费劲满世界找资源还得等下载？受够了下载的视频只能在电脑上看？那不如试试自动化追剧这一堆玩意～ 总体上说，通过这一套系统，可以通过ombi网页选择想看的电影or电视剧，后台自动下载视频文件、修改成标准命名并按需下载字幕。随后就可以在emby网页上或者客户端上观看，并且支持多用户多设备。而且顺便可以自动做种，自动刷PT。 结构 总体系统如图所示 由下到上进行说明功能： Indexer Manager(索引管理器)：Jackett、Prowlarr二选一，Prowlarr比较新，支持自动将合适的indexer推送到各个PVR。由于各个BT、PT、NZB资源站都不统一格式且不提供api，所以索引管理器就是将不同资源站点暴露为统一接口，方便其他程序调用以获取资源信息（种子、磁链等），基本就是个干些脏活累活的爬虫。当然这也是一切资源的源头，建议随时保持更新。 PVR(Personal Video Recorder): Sonarr电影集管理、Radarr剧集管理。PVR通过索引管理器提供的各个indexer搜索目标电影、剧集并获取种子，然后调用下载器下载。待下...
Headscale优雅异地组网
之前写过使用netmaker的组网，今天就推荐类似的基于wireguard的另一个更优雅的组网工具开源版tailscale–>headscale。根据官网介绍可以支持内网打洞，经过实际使用后感觉打洞成功率还是可以的，移动、电信均成功打洞。严格来说headscale是tailscale的开源服务端（这个名字有点恶趣味2333），不过支持了绝大部分功能。 客户端连接的前几个数据包默认通过derp server进行中转，所以无论打洞成功与否都能保证网络网络联通。同时，客户端会尝试进行打洞，成功后两个客户端间即可P2P直连。 部署Headscale服务端 Tailscale的中继节点称为DERP Server，官方提供了免费节点但是都在国外。。。而Headscale内置了derp server，所以可以直接部署在同一服务器上。DERP Server需要自己来处理TLS，而如caddy、nginx等一般都只处理七层的http，对于4层的TLS(TCP)无法做到反向代理。而Let’s Encrypt自动TLS证书需要绑定443或者80端口，这就导致了如果作为DERP节点的服务器要么只...
自己动手编译OpenvSwitch-DPDK
一直眼馋三层交换机，而且自己无论使用RouterOS还是OpenWrt配置三层路由进行跨VLAN通信都一直搞不起来，在路由内部每个VLAN都可以访问，然而外部进来的流量就不行。在搜索解决方案的时候无意间发现了OpenvSwitch这个SDN项目，该项目目前主要用在数据中心等地方，完整的方案叫OpenStack，而且囊括进三层之后还有个OpenvNetwork这个项目。经过测试后发现OpenvSwitch完全可以做到我需要的三层功能，而且还便宜不需要其他硬件支持跑在虚拟机上即可。 OpenvSwitch简称OVS，根据数据包不同的转发路径分为普通用户空间转发、内核数据路径转发（kernel datapath）、DPDK驱动转发三种，速度也是由低到高排序的。第一种数据路径的OVS安装较为简单，直接使用系统自带包管理器安装即可，具体参考官方文档。剩下两种里基本都是涉及到内核与驱动的，所以自己编译OVS在所难免。 这里记录下OVS-DPDK的编译流程。我所使用的编译环境是centos-8.5，最小化安装，因为有关内核驱动所以以后的机器也都是这么配置。宿主机是ESXI-6.7。 upda...
OpenWrt IPv6配置
都说国家在大力推行IPv6了不是，咱们怎么也得整上一个不是。国内三大运营商应该基本都分配IPv6了，但是得把光猫设置成桥接模式才可以让内网的设备获得IP，如果运营商没给IPv6的话应该可以打电话问问。除此以外各大高校基本都是有教育网IPv6的，而且有的学校还不限流量。IPv6的存在是为了解决IPv4地址耗尽的问题，理论上IPv6地址可以给地球上每一个沙子都整一个hhh，设计的挺美好但是实际应用中感知并不那么强烈。而且鉴于以上的设计，IPv6是没有NAT的，虽然有NAT66的实现，但是一般也不推荐使用。 本人目前在宿舍可以直接DHCPv6获取到v6的IP，但是猜测学校是为了响应一人终端一号的安全要求，分配的IP竟然是/64的，这种情况也就是所谓的无PD（Prefix Delegation）。正常情况下IPv6应该给分配一个地址前缀，然后你自己的路由设备给局域网内的设备分配这个前缀下的子IP。而无PD后这个IP就算到头了，不可以再往下分配了，这就导致了只可以单个设备使用（实在不想吐槽1202年了宿舍竟然还只能一个设备上个看视频都卡的网），所以解决这个问题的方法也简单，那就是IPv6 ...
k8s部署frps
虽然已经基于WireGuard将家里的本地网络同云服务器连接在了一起，但是由于内网穿透始终不是wg的强项，且一些情况下依旧需要P2P形式的内网穿透，所以目光就又回到了老朋友frp上来了，毕竟我的需求比较简单且frp用着习惯感觉也很稳定。 类似的内网穿透软件还有Ngrok、n2n等，都是大同小异的中心服务器架构，区别在支持的功能以及是否有官方节点等服务。当然非官方的服务还是有挺多的，只是简单的用一用可以考虑。 frp的server即frps，需要部署在具备公网ip的环境下。回到Homelab的结构，一个master和worker都有公网ip，所以当然就要部署在这个公网worker上。 而在怎么把frps服务暴露出去这个问题上属实折腾了很久，说到底还是对k8s的service不理解所致。frps支持几乎常用的所有协议，基本使用情境下就仅聚焦于TCP、UDP以及HTTP就行了，其中HTTP视作TCP流量即可。集群ingress使用的是ingress-nginx，文档中提及可以做L4的lb，但是不推荐，尝试后发现一个的lb类型的ingress的svc仅可以支持一种协议，即TCP和UDP不...
自建helm chart repo
无论本地储存或者把helm chart文件直接放在项目里面多少有点显得臃肿不方便，尤其对于我这种洁癖的来说就很烦。虽然有着类似helmMuseum的开源chart repo，但是搭建一个自己的还是更加舒服不是吗？而且继续薅Github的羊毛不香么？而且看官方说明也是支持薅羊毛的？？？ Helm chart repo原理很简单。首先，index.yaml文件里存储着这个helm repo里所有的chart的各版本信息以及地址，helm cli添加repo的操作就是获取这个index.yaml内信息；部署一个chart的时候就从index.yaml指示的地址获取到chart的压缩包进行部署就完成了。所以对应过来，我们需要一个网络服务器使得index.yaml可以被访问，还需要一个对象存储类似的储存各个chart的压缩包；这里白嫖方法也就是使用Github Pages来发布index.yaml，使用Github Release来发布各个压缩包，发布流程可以选择本地推送打包好的chart也可以直接使用Github Action进行打包并推送。当然我们这就选择将白嫖进行到底咯～ 建立Gi...