前言 最近需要写一个自动轮询生成指定域名的最快 IP 的工具，本身是一个小工具的属性，直接是用 Ruby 调试加上编写花费了三个小时完成了部分功能，过程比我想象地要难一点，这里直接放出来代码给大家参考 同时我也参考了这段 Gist ：https://gist.github.com/jvns/1e5838a53520e45969687e2f90199770 效果 代码和部分讲解 # frozen_string_literal: true require 'socket' require 'stringio' DNS_TYPES = { 1 => "A", 2 => "NS", 5 => "CNAME", } class DNSEncapsulationOfWriteOperations # fixed format, just hardcode private def make_question_header(query_id) [query_id, 0x0100, 0x0001, 0x0000, 0x0000, 0x0000].pack('nnnnnn') end public def make_dns_query(domain, query_id) question = domain.split('.').map { |label| [label.length, label].pack('Ca*') }.join + "\x00" question << [0x0001, 0x0001].pack('nn') # query type and class make_question_header(query_id) + question end end class DNSEncapsulationOfReadOperations def read_domain_name(buf) domain = [] loop do label_length = buf....

前言 Kured（Kubernetes Reboot Daemon）是一个针对 Kubernetes 的守护程序，其功能是在底层操作系统的软件包管理系统指示需要重新启动时，进行安全的自动节点重启 该守护程序通过监视重启标志文件（例如 /var/run/reboot-required）或监测特定的哨兵命令是否成功运行来确定是否需要进行重启操作。它会持续不断地观察这些指示，并在需要时采取相应的行动 为了确保在进行节点重启时的平稳运行，Kured 利用了 Kubernetes 的 APIServer 中的锁机制，以保证一次只有一个节点进行重启。这种锁机制确保了在集群中同一时间只有一个节点被重启，并避免了重启操作之间的冲突 此外，Kured 还提供了一些可选功能，例如在存在活动的 Prometheus 警报或特定的 Pod 时，可以推迟执行重启操作。这样可以避免在系统处于故障状态或关键服务正在运行时进行重启，从而确保整个集群的稳定性和可用性 总体来说，这个项目整体难度不算太高，通过对这个项目的二开可以加深对于集群的理解，具体的代码可以参考 https://github.com/kubereboot/kured ，截止目前，最新版本为 1.15.1 Kured 代码流程简述 主流程 它的 flags 使用了 cobra 库，同时在 Run 形参里面声明了 Root 函数为主要的执行函数，注意不要被 Execute 的调用所疑惑了 window, err := timewindow.New(rebootDays, rebootStart, rebootEnd, timezone) 这里使用了从 flags 中声明的重启时间，其中的 rebootDays 根据上下文来看，是个 []string 类型，推测估计是直接填写日期字符串 buildHostCommand(1, restartCommand) 这个方法实际上是将外部的宿主机的控制权限映射到了内部的容器控制点（当然必须事先声明 hostPID:true 和 privileged:true这两个选项允许容器进程获取额外的权限），如果我们进入函数内部进行查看，可以看到它是使用了 Linux 的 Nsenter 命令，这个命令会进入宿主机的命名空间（特别是在这里指定了 -m 选项，与之和宿主机的 PID 为 1 的进程做挂载）。这样，随后追加的 command 就会在宿主机上执行，而不是在容器内部...

前篇 关于 TCP 拥塞的控制算法，入门知识可以从 《TCP拥塞控制算法BBR的原理和改进实践》开始过一遍 Brutal 算法的核心代码剖析 static void brutal_update_rate(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); struct brutal *brutal = inet_csk_ca(sk); u64 sec = tcp_sock_get_sec(tp); u64 min_sec = sec - PKT_INFO_SLOTS; u32 acked = 0, losses = 0; u32 ack_rate; // Scaled by 100 (100=1.00) as kernel doesn't support float u64 rate = brutal->rate; u32 cwnd; u32 mss = tp->mss_cache; u32 rtt_ms = (tp->srtt_us >> 3) / USEC_PER_MSEC; if (!...

前言 这篇博客是属于对《Kubernetes Operator 进阶开发》的初步章节一个笔记总结，作为 2023 第一篇博文，也作为重新深入梳理 K8s 的基础，往后会逐步将之前的坑给填上 Operator的基本概念 作为最入门的篇章，我们将从写一个 Demo 开始，在这里将默认已经存在了一个可用的集群环境，当然如果在开始学习之前，你能有一些 Client-Go 基础那就再好不过了 控制器模式 控制器模式在日常生活中的应用非常广泛，也是根据原书的例子进行举例，当然这里缩减了非常多，也加入了些个人的想法 夏天我们需要调整空调制冷，现在过程如下： 空调启动后设置一个温度，例如 25 度 空调检测室温，确定室温是否高于目标值 如果高于目标阈值，例如室温 27 度，则开始制冷操作 如果低于目标阈值，保持静默到下一个探测周期 这其实就是控制器模式典型的工作流程，外部输入一个 “期望值”，期间一个 “控制器” 不断按照 “周期” 观测 “环境状态” 的 “实际值” 和 “期望值” 之间的差异，然后不断调整两者，以便维持平衡，这个过程则被称为 “调谐” Kubernetes中的控制器 Kubernetes 中通过 “声明式API” 定义了一系列的资源对象，然后通过许多的 Controllers 来 “调谐” 这些资源对象的实际状态以向期待状态靠拢，从而实现整个集群 “尽可能” 靠拢配置中声明的期望状态 一个Deployment的创建 我们都知道集群中有个组件，叫做 Kube-Controller-Manager，这个组件就是一系列控制器的集合，现在可以重新梳理一下这个面试中经常被问到的问题了 在编辑好一个 Deployment YAML 配置文件并使用 Kubectl 提交后，这个资源声明就被传递给了 Kube-ApiServer，接着 Kube-Controller-Manager 中的 Deployment 控制器监听到了消息，注意 K8s 中的组件传递原则 — 是上层组件先将自身置于被修改后的状态，即先假设资源已经被创建，而下层组件监听到了上游变化后，将自身或者环境状态 “调谐” 为上游一致，在这里 Deployment Controller 根据 Spec 字段的定义创建对应的 ReplicaSet 资源，而 RS Controller 监听到了 RS 的变化，并也根据 Spec 字段中声明创建了 Pod，这里其实还有一个 Kubelet 的环节在中间，只是这里被我们抽象掉了...

前前言 这是一篇杂谈，意味着不会像其他技术博文一样要求思路很严谨，也或者里面会有些错误或者不可靠的地方，欢迎探讨。 前言 再又一次看到谷歌搜索的人机认证后，我叹了口气。 自从高二有了自己第一台电脑后，怀着对 Linux 极大的兴趣，通过折腾 VPS 逐渐初次接触到了 “翻墙” 这个概念，才恍然意识，原来英文互联网能获取那么多一针见血的教程/知识，原来 Youtube （那时候对哔哩哔哩还没感兴趣）的视频那么好看，加上 Google 针对百度压倒性的搜索质量等等，让我从 “简中局域网居民”（不含贬义） 逐渐变成了一位 “国际互联网公民”。 那时候 Shadowsocks 横空出世，机场的概念还没兴起，自建梯子是当时的主流，支持 AliPay 的 Vultr 凭借着最低 35 元/月的最低套餐，变成了不知道多少 “年轻人的第一台 VPS”，我犹记得刚刚开始的时候，Vultr 东京 NTT 线路节点到深圳也才 45ms，学着教程部署一套 SS 后畅游外网似乎是一套那么理所当然的操作。 然而 Vultr 被人挤满后，当时夸张到需要连开五台机器，才能找出可以正常没有被墙的 IP，只要识别到了该 IDC 东京网段，网站会屏蔽你的服务，这就是因为低门槛导致不可控的因素极具增多，不是每个人都是一名合格的邻居，爬虫/垃圾邮件/DDOS/反动内容充斥着这里时候，我们意识到是时候找条新路子了。 一年亦或者是两年后，一方面是对持续维护翻墙服务器感到了厌烦，SS/SSR 在当时属于不断升级对抗阶段，如果更新不及时被 GFW 发现协议特征（最为经典就是 TCP 重放探测了），你会发现服务器 IP 被墙并不是件很意外的事情。另一方面，机场的概念被提出，只需要一台最低价格套餐就能享受到数以十计的节点，速度拉满，这简直不要太舒服。 机场时期 机场模式将会是目前以及未来的主流。 机场模式伴随度过大学时光，Stackoverflow / Github / Google 学术等等也是借着机场的便利才得以顺通，对于大部分人来说，机场完完全全可以当成最优解，只需要刷刷 Ins 或者谷歌搜索这种用途，又何必用其他的手段呢。 然而事情的便利都是有代价的，机场低廉的价格意味着需要进行超售才能维持成本，一条号称全 BGP 线路机场套餐 300G 才 10 元，一个出口 IP 被几百人使用，注意一个合格的机场是不会直连国外落地节点的，客户线路太不可控，万一效果不理想炸起来口碑就没了。一般都是在国内放置一个 BGP 入口，可以是阿里云/腾讯云等等，三网客户汇聚后转发到对于 BGP 节点优秀的出口线路。例如 PCCW / CN2 这些。...

KVM 是一种让 Linux 变成虚拟机监控程序的技术，它可以让多个虚拟机在同一台物理机上运行。为了让虚拟机正常运行，KVM 需要一些操作系统的组件，如内存管理器、进程调度程序、输入/输出堆栈、设备驱动程序、安全管理器和网络堆栈等，这些组件都包含在 KVM 中。每个虚拟机都像一个 Linux 进程一样运行，使用虚拟的硬件设备，如网卡、图形适配器、CPU、内存和磁盘等。 初始化和安装软件依赖 由于 KVM 和 Linux 内核紧密相关，所以为了保持文档的一致性，我们这里使用 5.15 版本的 Ubuntu 内核 $ uname -a Linux sxueck-server 5.15.0-1034-realtime #37-Ubuntu SMP PREEMPT_RT Wed Mar 1 20:50:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux $ sudo apt update $ sudo apt upgrade $ sudo apt -y install bridge-utils cpu-checker libvirt-clients libvirt-daemon qemu qemu-kvm genisoimage libguestfs-tools linux-tools-common $ echo 1024 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # 启用hugepages 在进行任务之前，我们需要对前置条件进行检查...