/ Recent content on RenovZ's Notes Hugo -- gohugo.io en-us Mon, 30 Mar 2026 19:02:07 +0800 /posts/sqlite-wal-design/ Mon, 30 Mar 2026 19:02:07 +0800 /posts/sqlite-wal-design/ SQLite WAL (Write-Ahead Logging) 设计原理详解 一、源码文件位置 核心实现文件 src/wal.c - WAL 主实现 (约 4700 行代码) src/pager.c - WAL 相关的 Pager 层逻辑 配套文件 src/wal.h - WAL 接口定义 src/os_unix.c / src/os_win.c - 平台特定的 WAL 实现 源码注释位置 文件开头部分 (行 1-250) 有详细的 WAL 格式说明文档 二、WAL 核心数据结构 2.1 WAL Header (32 字节) struct { u32 magic; /* 0: 0x377f0682 (小端) 或 0x377f0683 (大端) */ u32 version; /* 4: 文件格式版本，当前 3007000 */ u32 pageSize; /* 8: 数据库页面大小，如 1024、4096 等 */ u32 ckptSeq; /* 12: Checkpoint 序列号 */ u32 salt1; /* 16: Salt-1，随机整数，每次 checkpoint 递增 */ u32 salt2; /* 20: Salt-2，随机整数，每次 checkpoint 随机化 */ u32 checksum1; /* 24: 头部校验和 - 第一部分 */ u32 checksum2; /* 28: 头部校验和 - 第二部分 */ } WalIndexHdr; 属性说明： /posts/how-to-alter-table-in-sqlite/ Tue, 26 Nov 2024 15:49:35 +0800 /posts/how-to-alter-table-in-sqlite/ Create temp table, then do migration The old table CREATE TABLE "users" ( "id" INTEGER NOT NULL, "created_at" INTEGER NOT NULL DEFAULT CURRENT_TIMESTAMP, "password" TEXT NOT NULL, PRIMARY KEY("id" AUTOINCREMENT) ); Rename table ALTER TABLE "users" RENAME TO "users_old"; The new table CREATE TABLE "users" ( "id" INTEGER NOT NULL, "created_at" TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, "password" TEXT NOT NULL, PRIMARY KEY("id" AUTOINCREMENT) ); Migrate data from old table INSERT INTO "users" (id, created_at, password) SELECT id, created_at, password FROM "users_old"; Delete old table DROP TABLE "users_old"; Confirm data Double check if the created_at type is TIMESTAMP /posts/how-to-use-build.rs/ Sun, 24 Nov 2024 11:14:21 +0800 /posts/how-to-use-build.rs/ cargo:rustc-link-lib 用于指定要链接的库。 格式： // kind（可选）：指定库类型，如 static（静态库）、dylib（动态库，默认值）。 // name：库的名称，例如 virt。 println!("cargo:rustc-link-lib={kind}={name}"); eg: println!("cargo:rustc-link-lib=virt"); // 链接动态库 libvirt println!("cargo:rustc-link-lib=static=foo"); // 链接静态库 libfoo.a cargo:rustc-link-search 用于指定 Cargo 搜索库文件的路径。 格式： // kind（可选）：路径类型，如 native（默认值）。 // path：库所在的路径。 println!("cargo:rustc-link-search={kind}={path}"); eg: println!("cargo:rustc-link-search=/opt/homebrew/lib"); // 在该路径下搜索库 println!("cargo:rustc-link-search=native=/custom/path"); // 指定为 native 类型路径 cargo:rerun-if-changed 告诉 Cargo，当指定的文件改变时，重新运行 build.rs。 格式： println!("cargo:rerun-if-changed={file}"); eg: println!("cargo:rerun-if-changed=build.rs"); // 当 build.rs 发生改变时重新运行 println!("cargo:rerun-if-changed=src/lib.rs"); // 监视其他文件 cargo:rerun-if-env-changed 当指定的环境变量改变时，重新运行 build.rs。 eg: println!("cargo:rerun-if-env-changed=MY_ENV_VAR"); pkg-config 或其他工具输出的指令 如果使用 pkg-config，它会自动输出 cargo:rustc-link-lib 和 cargo:rustc-link-search 的指令。例如： fn main() { pkg_config::Config::new() . /posts/what-is-cidr/ Fri, 19 Apr 2024 16:23:59 +0800 /posts/what-is-cidr/ CIRD 是一个无类别域间路由的IP分配方法。 IP地址格式 有类地址 A类，IPv4地址有8个网络前缀位，可分配16777214个IP地址。如：192.0.0.1，其中192是网络地址，0.0.1是主机地址 B类，IPv4地址有16个网络前缀位，可分配65534个IP地址。如：192.168.0.1，其中192.168是网络地址，0.1是主机地址 C类，IPv4地址有24个网络前缀位，可分配254个IP地址。如：192.168.1.100，其中192.168.1是网络地址，100是主机地址 无类地址 该方式使用可变长度子网掩码（VLSM）来改变IP地址中网络地址和主机地址位之间的比率。子网掩码是一组标识符，通过将主机地址变为0，从IP地址返回网络地址的值。 VLSM序列允许网络管理员将IP地址空间分解位不同大小的子网，每个子网可以有灵活的主机数量和有限的IP地址数量。CIDR IP地址在普通IP地址的基础上加了一个后缀值，说明网络地址前缀位数。 如：192.168.0.0/24是一个IPv4 CIDR地址，其中前24位（192.168.0）是网络地址。 CIDR 优势 减少IP地址浪费，如用户需要一个包含300个IP地址的网段，如果使用有类地址，需要分配一个B类(65534=256*256-2)地址，但是这会造成极大的资源浪费。如果使用CIDR的IP分配方式，如：192.168.0.0/23，则可以避免这类问题。具体的ip地址范围，可是使用ipcalc来查看对应的IP地址范围 快速传输数据。因为CIDR策略可以有效的将IP地址组织成多个子网，子网存在与网路中的较小网络，减少了路由器的路由次数，进一步也就减少了数据拷贝的次数，因而效率更高。 创建虚拟私有云（VPC）。允许用户在隔离且安全的环境中配置工作负载，但这种需求使用有类地址也可以做到。 灵活创建超网。超网是一组具有相似网络前缀的子网，CIDR允许灵活创建超网，这在传统的掩码架构（即有类地址）中使不可能的。如：192.168.1/23与192.168.0/23，这种方式将255.255.254.0的子网掩码应用于IP地址，该IP地址将返回前23位作为网络地址，路由器只需要一个路由表条目即可管理子网设备之间的数据包。 CIDR 工作原理 CIDR允许网络路由器根据指定的子网将数据包路由到相应的设备。路由器不是根据类别对IP地址分类，而是检索CIDR后缀指定的网络和主机地址。 CIDR块 CIDR数据块是共享相同网络前缀和位数的IP地址集合。一个大数据块有更多IP地址和一个小后缀组成。如： master CIDR Block: 10.10.0.0/16 subnet 1: 10.10.1.0/24 subnet 2: 10.10.2.0/24 subnet 3: 10.10.3.0/24 subnet 4: 10.10.4.0/24 subnet 5: 10.10.5.0/24 ... /posts/change-the-cidr-for-running-kubernetes/ Tue, 16 Apr 2024 18:31:17 +0800 /posts/change-the-cidr-for-running-kubernetes/ First of first This operation will lead the kube cluster unavailable for some minutes. Take care. Releated files and kube objects /etc/kubernetes/manifest/kube-apiserver.yaml kubectl -n kube-system edit svc/kube-dns /var/lib/kubelet/config.yaml kubectl -n kube-system edit cm kubelet-config Update kube-apiserver manifest # vim /etc/kubernetes/manifests/kube-apiserver.yaml ... spec: containers: - command: - kube-apiserver ... - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --service-cluster-ip-range=100.96.0.0/12 # Change - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt ... Edit kube-dns service # kubectl -n kube-system edit svc kube-dns ... # in the service YAML, modify the 'strategy'. /posts/qemu-usage/ Wed, 10 Apr 2024 20:25:41 +0800 /posts/qemu-usage/ qemu-img snapshot # list the snapshots qemu-img disk_image.qcow2 snapshot -l # create snapshot qemu-img disk_image.qcow2 snapshot -c snapshot_name # apply a snapshot qemu-img disk_image.qcow2 snapshot -a snapshot_name /posts/policies/ Tue, 09 Apr 2024 09:48:38 +0800 /posts/policies/ kubernetes 策略是管理其他配置或运行时行为的一些配置。kubernetes 提供了各种形式的策略： 使用 API 对象应用策略 NetworkPolicy 用于限制工作负载的出入站流量 LimitRange 管理多个不同对象类别的资源分配约束 ResourceQuota 限制命名空间的资源消耗 使用准入控制器应用策略 准入控制器允许在 API 服务器上，可以验证或变更 API 请求，某些准入控制器用于应用策略。例如：AlwaysPullImages 准入控制会将 Pod 中容器的镜像拉取策略设置为 Always 使用 ValidatingAdmissionPolicy 应用策略 允许使用表达式语言 CEL 在 API 服务器中执行可配置的验证检查。如：ValidatingAdmissionPolicy 用于禁止使用 latest 镜像标签 使用动态准入控制 提供给用户自定义准入控制的一种方式，用户可以自定义自己的准入控制，然后在运行时动态加载到 kube-apiserver 的准入控制验证或变更中。 kubewarden 基于 Wasm 的准入控制，允许用户通过自定义策略检查 kubernetes 对象，如 Pod，Deployment，Service 等的创建，更新和删除请求，并在请求被接受或拒绝时执行这些策略 kyverno 用于实施声明式的策略管理，允许 kubernetes 用户定义和实施基于资源的策略 OPA Gatekeeper 用于执行和管理策略 Polaris 提供对集群健康和最佳实践的自动化检查和建议，可以帮助用户识别和解决潜在的问题 使用 kubelet 配置应用策略，kubernetes 允许每个节点上配置 kubelet，一些 kubelet 配置可以视为策略。 进程 ID 限制和保留：限制或保留可分配的 PID 节点资源管理器：为低延迟和高吞吐量的工作负载管理 CPU，内存和其他设备资源 LimitRange 默认情况下，kubernetes 集群上的容器运行使用的计算资源没有限制。使用命名空间资源配额，可以限制命名空间的资源使用上限；使用 LimitRange 可以限制一个 Pod 可以使用的资源上限和下限。LimitRange 提供限制能力包括： /posts/authorization/ Sun, 07 Apr 2024 20:03:24 +0800 /posts/authorization/ kubernetes 内置 RBAC，ABAC，Node Authorization 等授权模式，然后使用kube-apiserver --authorization-mode=<AUTH MODE>,RBAC开启对应的授权模式，其中 RBAC 是必选项。 RBAC 基于角色的访问控制，通过集群管理员指定用户拥有的权限，使用时经过授权模块赋予对应的权限。 支持权限的降级，但不支持权限的升级，如 RoleBinding（作用域为 namespace）可以绑定到 ClusterRole，但是不能将 ClusterRoleBinding（作用域为 cluster）绑定到 Role。 对于普通用户名或用户组的限制，其中前缀是system:为 kubernetes 系统保留的，禁止用户使用前缀为此的用户名称或组名称。 对于服务账户和服务账户组，分别需要包含system:serviceaccount:和system:serviceaccounts:前缀。 对于需要修改用户或组的 RoleBinding 或者 ClusterRoleBinding，系统不支持修改，需要删除后重新添加。 默认的 Roles 和 RoleBindings 对集群默认角色、名称、以及绑定关系的修改，都将可能导致集群无法工作，需要格外小心。 集群中以system:为前缀的，用以标识对应资源是直接由集群控制面管理的。 所有默认的 ClusterRole 和 ClusterRoleBinding 都有kubernetes.io/bootstrapping=rbac-defaults标签 自动协商机制保证，每次集群启动时，kube-apiserver 都会更新默认 ClusterRole 以添加各类缺失的权限，并更新 ClusterRoleBinding 以添加各类缺失的主体，可修复一些不小心发生的修改，并有助于保证角色和角色绑定在新的发行版中保持最新状态。 kube-apiserver 发现角色 默认的角色绑定赋予所有人（包括匿名用户）可以访问对于被集群认为是安全公开的 API，如果要禁用匿名用户访问可以配置kube-apiserver --anonymous-auth=false。 默认 ClusterRole 默认 ClusterRoleBinding 说明 system:basic-user system:authenticated 组 允许用户以只读的方式去访问他们自己的基本信息。在 v1.14 之前，默认也绑定 system:unauthenticated system:discovery system:authenticated 组 允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。v1.14 之前，默认也绑定 system:unauthenticated system:public-info-viewer system:authenticated, system:unauthenticated 组 允许对集群的非敏感信息进行只读访问，此角色在 v1. /posts/admission-controllers/ Sun, 07 Apr 2024 12:22:39 +0800 /posts/admission-controllers/ 准入控制器是一段代码，会在请求通过认证和授权之后、对象被持久化之前拦截到达 kube-apiserver 的请求。 准入控制器可以执行 Validating 和 Mutating 操作。准入控制器限制创建、删除、修改对象的请求，也可以阻止自定义 verbs，如通过 api 代理服务器连接到 Pod 的请求。准入控制器不能阻止 get、watch 或 list 对象的请求。 有 2 个特殊的准入控制器：MutatingAdmissionController 和 ValidatingAdmissionController，分别执行变更和验证准入控制 Webhook。 准入控制阶段 运行 MutatingAdmissionControl 运行 ValidatingAdmissionControl 某些 AdmissionController 即是 MutatingAdmissionController，又是 ValidatingAdmissionController。 如果某个请求在 2 个阶段的其中一个被拒绝，则整个请求立即被拒绝，并返回错误。 准入控制器有其他副作用，将相关资源作为请求处理的一部分进行变更。如增加资源配额。任何一个准入控制器都无法确定其他准入控制器的需求，只有当请求符合所有的准入控制器的要求，才会被 kube-apiserver 正确处理。 启用准入控制器 kube-apiserver --enable-admission-plugins=NamespaceLifeCycle,LimitRanger ... 关闭准入控制器 kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... 默认启用的准入控制器 CertificateApproval CertificateSigning CertificateSubjectRestriction DefaultIngressClass DefaultTolerationSeconds LimitRanger MutatingAdmissionWebhook NamespaceLifeCycle PersistentVolumeClaimResize PodSecurity Priority ResourceQuota ServiceAccount StorageObjectInUseProtection TaintNodesByCondition ValidatingAdmissionPolicy ValidatingAdmissionWebhook 每个准入控制器的作用 LimitRanger: 监测传入的请求，确保不会违反 Namespace 中 LimitRange 对象所设置的任何约束；还可以用于将默认资源配额应用到没有设定资源配额的 Pod NamespaceLifeCycle：会禁止在一个正在被删除的 Namespace 中创建新对象，并确保针对不存在的 Namespace 的请求被拒绝；会禁止删除系统中的保留命名空间：default,kube-system,kube-public 准入控制器列表 推荐的准入控制器 /posts/%E8%AF%81%E4%B9%A6%E4%B8%8E%E8%AF%81%E4%B9%A6%E7%AD%BE%E5%90%8D%E8%AF%B7%E6%B1%82/ Sun, 07 Apr 2024 10:10:46 +0800 /posts/%E8%AF%81%E4%B9%A6%E4%B8%8E%E8%AF%81%E4%B9%A6%E7%AD%BE%E5%90%8D%E8%AF%B7%E6%B1%82/ kubernetes 证书和 trust bundle API 可以通过为 kube-apiserver 的客户端提供编程接口，实现X.509证书的请求并获取证书颁发机构的自动化制备。 证书签名 etcd 不会保存签名请求，相应的会有以下几种状态： 已签发的请求：会在 1 个小时后自动被垃圾回收器删除 拒绝的请求：会在 1 个小时后自动被垃圾回收器删除 失败的请求：会在 1 个小时后自动被垃圾回收器删除 所有的请求：已签发证书会在失效以后自动被垃圾回收器删除 Signer 任何要在特定集群以外提供的签名者都应该提供关于签名者工作方式的信息。 信任分发：信任锚点（CA 证书或证书包） 许可的主体 许可的 x509 扩展：包括 IP subjectAltNames，DNS subjectAltNames, Email subjectAltNames, URL subjectAltNames 等 许可的/扩展的密钥用途 过期时间/证书有效期：可以由签名者确定、管理员配置，或者 CSR 请求中spec.expirationSeconds字段指定 允许/不允许 CA 位：若 CSR 包含一个签名者并不允许的 CA 证书时，相应的应对手段 内置的 Signer kubernetes.io/kube-apiserver-client 签名的证书将被 kube-apiserver 视为客户端证书，不会被 kube-controller-manager 自动批准 kubernetes.io/kube-apiserver-client-kubelet 签名的证书将被 kube-apiserver 视为 kubelet 的客户端证书，可以被 kube-controller-manager 自动批准 kubernetes.io/kubelet-serving 签名的证书将被视为有效的 kubelet 服务端证书，不会被 kube-controller-manager 自动批准 kubernetes.