[{"content":"前言 一个好用的 Shell 配置，不应该只是“看起来很酷”。它更应该做到三件事：\n启动快：进入终端后立刻可输入命令，而不是等待一堆插件初始化。 提示准：当前目录、Git 状态、命令执行结果、语言环境等信息一眼可见。 操作顺手：常用命令短、路径跳转快、补全和历史建议足够智能。 这篇文章记录我的 Zsh 配置思路。整体方案是：Zinit 管理插件，Powerlevel10k 负责提示符，Oh My Zsh 提供成熟插件生态，再配合 eza、yazi 等工具优化日常开发体验。\n整体结构 我的 Zsh 配置主要由两个文件组成：\n~/.zshrc # 主配置：环境变量、zinit、插件、别名、函数 ~/.p10k.zsh # Powerlevel10k 主题配置 加载顺序大致如下：\n启动 Zsh | v Powerlevel10k instant prompt | v 基础环境变量与 Shell options | v 加载 zinit | v 加载 OMZ library / Powerlevel10k / 插件 | v source ~/.p10k.zsh | v 注册 alias / function / PATH 这种拆分的好处是：.zshrc 保持“启动流程与插件管理”，.p10k.zsh 专注“提示符长什么样”。以后更换主题时，也不会影响插件和别名体系。\n用 instant prompt 提升启动体验 配置最顶部是 Powerlevel10k 的 instant prompt：\nif [[ -r \u0026#34;${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh\u0026#34; ]]; then source \u0026#34;${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh\u0026#34; fi 它的作用是：在完整配置加载完成之前，先显示一个临时 Prompt，让终端看起来“秒开”。\n同时我设置了：\ntypeset -g POWERLEVEL9K_INSTANT_PROMPT=quiet 这样可以减少 instant prompt 对启动时输出内容的干扰。对于需要频繁打开新终端、tmux pane 或远程会话的人来说，这一点体验提升很明显。\n基础环境与 Zsh options path=(~/.local/bin $path) typeset -x XDG_CONFIG_HOME=\u0026#34;${XDG_CONFIG_HOME:-$HOME/.config}\u0026#34; setopt correct setopt interactive_comments 这里做了几个基础设定：\n配置 作用 ~/.local/bin 前置到 PATH 优先使用用户级安装的命令 XDG_CONFIG_HOME 统一配置目录，默认指向 ~/.config setopt correct 命令输错时给出纠正建议 setopt interactive_comments 交互式 Shell 中也允许使用 # 注释 interactive_comments 很适合在终端里临时记录命令意图，比如粘贴多行命令时可以保留注释说明。\n为什么选择 Zinit 插件管理器我使用的是 Zinit：\nZINIT_HOME=\u0026#34;${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git\u0026#34; [[ ! -d \u0026#34;${ZINIT_HOME}\u0026#34; ]] \u0026amp;\u0026amp; mkdir -p \u0026#34;$(dirname \u0026#34;${ZINIT_HOME}\u0026#34;)\u0026#34; [[ ! -d \u0026#34;${ZINIT_HOME}/.git\u0026#34; ]] \u0026amp;\u0026amp; git clone https://gh-proxy.org/https://github.com/zdharma-continuum/zinit.git \u0026#34;${ZINIT_HOME}\u0026#34; source \u0026#34;${ZINIT_HOME}/zinit.zsh\u0026#34; Zinit 的核心价值是：可以精细控制插件加载时机。比如有些插件必须同步加载，有些插件可以延迟 1 秒、2 秒、3 秒再加载；对于启动速度敏感的 Shell 配置来说，这比简单地 source 一堆脚本更可控。\n配置里还使用了 GitHub 代理地址，主要是为了在国内网络环境下更稳定地安装 Zinit。你也可以按自己的网络情况替换为官方仓库地址。\n先加载 Oh My Zsh 的基础库 我没有直接使用完整的 Oh My Zsh 框架，而是通过 Zinit 按需加载其中的 library 和 plugin。\n同步加载的 OMZ library：\nfor i in theme-and-appearance.zsh git.zsh prompt_info_functions.zsh history.zsh; do zinit snippet \u0026#34;OMZL::${i}\u0026#34; done 延迟加载的 OMZ library：\nfor i in completion.zsh key-bindings.zsh; do zinit ice lucid wait=\u0026#34;1\u0026#34; zinit snippet \u0026#34;OMZL::${i}\u0026#34; done 这里的思路是：\n类型 加载策略 原因 theme / git / prompt / history 同步加载 主题和提示符依赖，越早越好 completion / key-bindings 延迟加载 对首屏 Prompt 不是硬依赖 补全初始化则交给：\nzpcompinit zpcdreplay 这样可以配合 Zinit 的补全 replay 机制，让插件延迟加载后仍然能正确注册补全。\nPowerlevel10k：两行式 Prompt 主题使用 Powerlevel10k：\nzinit ice depth=1 zinit light romkatv/powerlevel10k [[ ! -f ~/.p10k.zsh ]] || source ~/.p10k.zsh depth=1 可以减少 clone 体积，只拉取必要历史。\n我的 .p10k.zsh 是通过 p10k configure 生成的 rainbow 风格配置，主要特点是：\n项目 配置 字体 Nerd Font v3 风格 powerline + rainbow Prompt 两行式 分隔符 angled separators 图标 small icons / many icons 显示密度 sparse、concise 左侧 Prompt 保留最核心的信息：\nPOWERLEVEL9K_LEFT_PROMPT_ELEMENTS=( os_icon dir vcs newline prompt_char ) 右侧 Prompt 则放一些上下文信息，例如命令状态、执行耗时、后台任务、Python 虚拟环境、Kubernetes context、Terraform workspace、云 CLI profile、时间等。\n这种布局的优点是：左边只显示当前操作最常用的信息，右边显示“有就看、没有也不影响”的上下文。两行式 Prompt 也能避免路径太长时挤压命令输入区域。\n插件设计：按“必要程度”延迟加载 我的插件并不是一股脑同步加载，而是按使用频率和必要程度分层。\n插件 加载方式 用途 command-not-found wait=0 命令不存在时提示可安装的软件包 colored-man-pages wait=3 彩色 man 页面 fast-syntax-highlighting async 命令行语法高亮 zsh-autosuggestions async + atload 基于历史记录的命令建议 sudo wait=2 双击 Esc 给当前命令加 sudo z wait=1 根据访问频率跳转目录 git wait=1 Git 常用别名与函数 extract wait=1 一条命令解压多种格式 kubectl wait=1 Kubernetes 别名、补全与辅助函数 其中最影响交互体验的是两个插件：\nzinit light zdharma-continuum/fast-syntax-highlighting zinit light zsh-users/zsh-autosuggestions fast-syntax-highlighting：输入命令时实时高亮，能提前发现命令、路径、参数是否写错。 zsh-autosuggestions：根据历史记录给出灰色建议，按右方向键即可补全。 这两个插件会让命令行从“纯文本输入框”变成“带反馈的交互环境”。\n文件列表：eza 优先，ls 兜底 我把常用 ls 系列命令封装成了别名，如果系统安装了 eza，就优先使用 eza：\nif [[ -n \u0026#34;$(command -v eza)\u0026#34; ]]; then DISABLE_LS_COLORS=true alias ls=\u0026#39;eza --color=auto\u0026#39; alias l=\u0026#39;eza -lbah --icons=auto\u0026#39; alias la=\u0026#39;eza -labgh --icons=auto\u0026#39; alias ll=\u0026#39;eza -lbg --icons=auto\u0026#39; alias lt=\u0026#39;eza -lTbg --icons=auto\u0026#39; alias lsa=\u0026#39;eza -lbagR --icons=auto\u0026#39; alias lst=\u0026#39;eza -lTabgh --icons=auto\u0026#39; else alias ls=\u0026#39;ls --color=auto\u0026#39; alias l=\u0026#39;ls -lah\u0026#39; alias la=\u0026#39;ls -lAh\u0026#39; alias ll=\u0026#39;ls -lh\u0026#39; alias lsa=\u0026#39;ls -lah\u0026#39; alias lst=\u0026#39;tree -pCsh\u0026#39; fi 常用别名含义如下：\n别名 作用 l 长列表，显示隐藏文件、人类可读大小、图标 la 类似 l，但更适合查看权限和分组信息 ll 简洁长列表 lt 树状展示目录 lsa 递归列出所有文件 lst 树状递归展示并包含隐藏文件 这里的关键是“有增强工具就增强，没有就优雅降级”。配置可以在新机器上直接使用，不会因为缺少 eza 导致 Shell 启动失败。\n路径跳转与目录历史 alias ...=../.. alias ....=../../.. alias .....=../../../.. alias ......=../../../../.. alias 1=\u0026#39;cd -\u0026#39; alias 2=\u0026#39;cd -2\u0026#39; alias 3=\u0026#39;cd -3\u0026#39; # ...一直到 9 这组别名解决两个常见问题：\n多级返回目录时不用反复输入 cd ../../..。 在多个目录之间来回切换时，可以直接用 1 到 9 访问目录栈。 配合 OMZ 的 z 插件，可以覆盖两类跳转场景：\n已知相对路径：使用 ...、....。 经常访问的目录：使用 z \u0026lt;keyword\u0026gt;。 yazi：退出文件管理器后自动 cd 配置中有一个很实用的 y() 函数：\nfunction y() { local tmp cwd tmp=\u0026#34;$(mktemp -t yazi-cwd.XXXXXX)\u0026#34; yazi \u0026#34;$@\u0026#34; --cwd-file=\u0026#34;$tmp\u0026#34; cwd=\u0026#34;$(cat -- \u0026#34;$tmp\u0026#34;)\u0026#34; if [[ -n \u0026#34;$cwd\u0026#34; \u0026amp;\u0026amp; \u0026#34;$cwd\u0026#34; != \u0026#34;$PWD\u0026#34; ]]; then builtin cd -- \u0026#34;$cwd\u0026#34; fi rm -f -- \u0026#34;$tmp\u0026#34; } 普通文件管理器的问题是：你在里面进入了某个目录，但退出后 Shell 仍然停留在原目录。这个函数通过 --cwd-file 记录 yazi 退出时所在目录，然后让当前 Shell 自动 cd 过去。\n实际体验就是：\ny # 在 yazi 中进入目标目录 # 退出 yazi 后，Shell 自动切换到那个目录 这比在终端里反复 cd、ls、再 cd 要顺手很多。\nGit、解压、sudo 与搜索 除了视觉和补全，我还保留了一些非常实用的小别名：\nalias _=\u0026#39;sudo \u0026#39; alias gc1=\u0026#39;git clone --recursive --depth=1\u0026#39; alias md=\u0026#39;mkdir -p\u0026#39; alias rd=\u0026#39;rmdir\u0026#39; alias afind=\u0026#39;ack -il\u0026#39; alias grep=\u0026#39;grep --color=auto\u0026#39; alias egrep=\u0026#39;egrep --color=auto\u0026#39; alias fgrep=\u0026#39;fgrep --color=auto\u0026#39; 别名 用途 _ 快速给命令加 sudo 前缀 gc1 浅克隆并递归拉取子模块 md 创建多级目录 rd 删除空目录 afind 用 ack 搜索包含关键词的文件 grep 系列 默认开启彩色输出 此外 OMZ 的 extract 插件也很省心：不需要记住 tar.gz、zip、xz、bz2 等格式分别怎么解压，统一用 extract 即可。\n代理开关：为国内网络环境准备 alias proxy-on=\u0026#39;export http_proxy=http://127.0.0.1:7890 https_proxy=http://127.0.0.1:7890\u0026#39; alias proxy-off=\u0026#39;unset http_proxy https_proxy\u0026#39; 这两个别名适合临时让命令行工具走本地代理，例如拉取 GitHub 仓库、安装依赖、访问国外 API 等。\nproxy-on # 执行需要代理的命令 proxy-off 我没有把代理永久写进环境变量，因为那样容易影响内网服务、容器网络和一些只需要直连的命令。按需开启更可控。\n依赖清单 这套配置推荐安装的依赖如下：\n依赖 必需 用途 zsh ✅ Shell 本体 git ✅ 安装 zinit、拉取插件 zinit ✅ 插件管理器 powerlevel10k ✅ Prompt 主题 Nerd Font ✅ 正确显示图标和 powerline 符号 eza 可选 更现代的 ls 替代品 tree 可选 eza 不存在时作为树状列表兜底 ack 可选 afind 搜索别名 yazi 可选 终端文件管理器 kubectl 可选 Kubernetes 补全与别名 command-not-found 可选 命令不存在时提示安装包 最小安装只需要：zsh、git、Nerd Font。其他工具可以按需补齐。 可复用的安装步骤 如果要在新机器上复用这套配置，可以按这个流程：\n# 1. 安装基础依赖 sudo apt update sudo apt install -y zsh git # 2. 可选增强工具 sudo apt install -y tree ack # 3. 安装 eza / yazi 等增强工具 # 不同发行版包名可能不同，可按实际系统调整 # 4. 放置配置文件 cp .zshrc ~/.zshrc cp .p10k.zsh ~/.p10k.zsh # 5. 切换默认 Shell chsh -s \u0026#34;$(command -v zsh)\u0026#34; 首次进入 Zsh 时，配置会自动安装 Zinit，并通过 Zinit 拉取 Powerlevel10k 和插件。\n我的取舍 这套配置没有追求“插件越多越好”，而是围绕日常使用做了几个取舍：\n不完整引入 Oh My Zsh：只按需加载 OMZ library 和 plugin，减少框架开销。 Prompt 信息分层：左侧保留目录与 Git，右侧显示环境上下文。 增强工具必须有 fallback：eza 不存在就退回 ls，避免新机器启动失败。 代理手动开关：避免代理污染所有命令。 插件延迟加载：把首屏可交互时间放在第一优先级。 总结 我的 Zsh 配置可以概括为：\nZinit：负责插件安装、延迟加载和补全 replay。 Powerlevel10k：提供高信息密度、低干扰的两行 Prompt。 OMZ snippets：按需复用 Oh My Zsh 的成熟插件生态。 eza / yazi / z / autosuggestions：提升文件浏览、目录跳转和命令输入效率。 终端配置是一个长期迭代的系统。最好的配置不是最复杂的配置，而是能让你在每天打开终端时少想一步、少敲几个字、少等几百毫秒的配置。\n","permalink":"https://hugo.luochen570.cn/posts/my-zsh-terminal-setup/","summary":"\u003ch2 id=\"前言\"\u003e前言\u003c/h2\u003e\n\u003cp\u003e一个好用的 Shell 配置，不应该只是“看起来很酷”。它更应该做到三件事：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e启动快\u003c/strong\u003e：进入终端后立刻可输入命令，而不是等待一堆插件初始化。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e提示准\u003c/strong\u003e：当前目录、Git 状态、命令执行结果、语言环境等信息一眼可见。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e操作顺手\u003c/strong\u003e：常用命令短、路径跳转快、补全和历史建议足够智能。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e这篇文章记录我的 Zsh 配置思路。整体方案是：\u003cstrong\u003eZinit 管理插件，Powerlevel10k 负责提示符，Oh My Zsh 提供成熟插件生态，再配合 eza、yazi 等工具优化日常开发体验\u003c/strong\u003e。\u003c/p\u003e","title":"我的 Zsh 终端配置：Zinit、Powerlevel10k 与日常效率优化"},{"content":"前言 本文记录在多台服务器上部署 k3s 高可用集群的完整过程。集群架构为 3 Server + 1 Agent，通过 Tailscale 组建 overlay 网络，只有一台节点具有公网 IP，其余节点通过 HAProxy 代理访问。\n网络拓扑 Internet x.x.x.x:6443 | v +-----------------------------+ | agent-ali | | +-----------------------+ | | | HAProxy | | | | bind *:6443 | | | | -\u0026gt; roundrobin | | | +----------+-------------+ | +-------------+----------------+ | Tailscale | 100.100.x.x +---------------+----------------+ | | | v v v +----------------+ +----------------+ +----------------+ | server-jz | | server-jz2 | | server-zen | | CP + etcd | | CP + etcd | | CP + etcd | | 私有云 | | 私有云 | | 私有云 | +----------------+ +----------------+ +----------------+ 只有 agent-ali 有公网 IP，其余节点均通过 Tailscale 内网互通 HAProxy 运行在 agent-ali 上，将外部的 k3s API 请求负载均衡到 3 个 Server 节点 所有节点通过 Tailscale VPN 组网（100.100.x.x 网段） 节点规划 节点角色 节点名 Tailscale IP 公网 位置 Server (etcd + control-plane) server-jz 100.100.1.12 ❌ 私有云 Server (etcd + control-plane) server-jz2 100.100.1.13 ❌ 私有云 Server (etcd + control-plane) server-zen 100.100.1.11 ❌ 私有云 Agent agent-ali 100.100.1.10 ✅ 公有云 前置准备 获取 Tailscale 密钥 在 Tailscale 管理后台 生成一个 Auth Key：\n进入 Settings → Keys 点击 Generate auth key 勾选 Reusable（可重用）和 Ephemeral（可选） 复制生成的密钥，格式为 tskey-auth-xxxxx 该密钥用于节点自动加入 Tailscale 网络，无需手动登录。\nServer 节点：依赖安装 所有 Server 节点需要安装 Tailscale：\ncurl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up --auth-key=tskey-auth-xxxxx 确认节点上线：\ntailscale status 第一步：在 agent-ali 上配置 HAProxy 在 agent-ali 上安装 HAProxy，将外部流量转发到 3 个 Server 节点的 k3s API：\n# 安装 HAProxy sudo apt update \u0026amp;\u0026amp; sudo apt install -y haproxy 配置 /etc/haproxy/haproxy.cfg：\nfrontend k3s-frontend bind *:6443 mode tcp option tcplog default_backend k3s-backend backend k3s-backend mode tcp option tcp-check balance roundrobin default-server inter 10s downinter 5s server server-zen 100.100.1.11:6443 check server server-jz 100.100.1.12:6443 check server server-jz2 100.100.1.13:6443 check 启动 HAProxy：\nsudo systemctl enable --now haproxy 这样外部的 kubectl 只需要连接 agent-ali:6443，由 HAProxy 转发到健康的 Server 节点。\n第二步：初始化第一个 Server 节点 curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \\ INSTALL_K3S_MIRROR=cn \\ K3S_NODE_NAME=server-jz2 \\ sh -s server \\ --embedded-registry \\ --data-dir /www/k3s \\ --cluster-init \\ --node-ip=100.100.1.13 \\ --advertise-address=100.100.1.13 \\ --tls-san=100.100.1.13 \\ --tls-san=x.x.x.x \\ --vpn-auth=\u0026#34;name=tailscale,joinKey=tskey-auth-xxxxx\u0026#34; 关键参数说明：\n参数 说明 INSTALL_K3S_MIRROR=cn 使用国内镜像源 --embedded-registry 启用内置镜像仓库（zot），本地缓存镜像 --cluster-init 初始化集群（仅第一个节点需要） --data-dir /www/k3s 指定数据目录 --tls-san 添加证书 SAN，包含公网 IP（x.x.x.x） --vpn-auth 集成 Tailscale 自动加入网络 安装完成后获取节点 Token：\nsudo cat /www/k3s/server/node-token 第三步：加入其余 Server 节点 # server-jz curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \\ INSTALL_K3S_MIRROR=cn \\ K3S_NODE_NAME=server-jz \\ sh -s server \\ --embedded-registry \\ --data-dir /www/k3s \\ --token K101fe... \\ --server https://100.100.1.13:6443 \\ --node-ip=100.100.1.12 \\ --advertise-address=100.100.1.12 \\ --vpn-auth=\u0026#34;name=tailscale,joinKey=tskey-auth-xxxxx\u0026#34; # server-zen curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \\ INSTALL_K3S_MIRROR=cn \\ K3S_NODE_NAME=server-zen \\ sh -s server \\ --embedded-registry \\ --data-dir /www/k3s \\ --token K101fe... \\ --server https://100.100.1.13:6443 \\ --node-ip=100.100.1.11 \\ --advertise-address=100.100.1.11 \\ --vpn-auth=\u0026#34;name=tailscale,joinKey=tskey-auth-xxxxx\u0026#34; 第四步：加入 Agent 节点 curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \\ INSTALL_K3S_MIRROR=cn \\ K3S_NODE_NAME=agent-ali \\ K3S_URL=https://100.100.1.13:6443 \\ K3S_TOKEN=K101fe... \\ sh -s - agent \\ --node-ip=100.100.1.10 \\ --node-external-ip=100.100.1.10 \\ --vpn-auth=\u0026#34;name=tailscale,joinKey=tskey-auth-xxxxx\u0026#34; 配置 kubeconfig 从任意 Server 节点复制 kubeconfig 到本地：\n# 复制配置文件 sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config # 将 server 地址改为 HAProxy 的公网地址 kubectl config set-cluster default --server=https://x.x.x.x:6443 # 验证 export KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get pods --all-namespaces helm ls --all-namespaces HAProxy 会将请求负载均衡到 3 个 Server 节点，即使单个 Server 宕机也不影响 API 访问。\n配置镜像加速 在中国大陆部署时，镜像拉取是最大的痛点。通过配置 registries.yaml 解决：\nsudo mkdir -p /etc/rancher/k3s sudo cat \u0026gt; /etc/rancher/k3s/registries.yaml \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; mirrors: docker.io: endpoint: - \u0026#34;https://docker.1ms.run\u0026#34; - \u0026#34;https://docker.xuanyuan.me\u0026#34; - \u0026#34;https://docker.m.daocloud.io\u0026#34; - \u0026#34;https://docker.chenby.cn\u0026#34; - \u0026#34;https://registry.aliyuncs.com\u0026#34; - \u0026#34;https://mirror.ccs.tencentyun.com\u0026#34; - \u0026#34;https://hub.luochen570.top\u0026#34; quay.io: endpoint: - \u0026#34;https://quay.m.daocloud.io\u0026#34; - \u0026#34;https://quay.tencentcloudcr.com\u0026#34; - \u0026#34;https://quay.registry.cyou\u0026#34; - \u0026#34;https://quay.chenby.cn\u0026#34; - \u0026#34;https://quay.luochen570.top\u0026#34; registry.k8s.io: endpoint: - \u0026#34;https://k8s.m.daocloud.io\u0026#34; - \u0026#34;https://registry.aliyuncs.com/google_containers\u0026#34; - \u0026#34;https://registry.lank8s.cn\u0026#34; - \u0026#34;https://lank8s.cn\u0026#34; - \u0026#34;https://k8s.registry.cyou\u0026#34; - \u0026#34;https://k8s.chenby.cn\u0026#34; - \u0026#34;https://k8s.luochen570.top\u0026#34; ghcr.io: endpoint: - \u0026#34;https://ghcr.m.daocloud.io\u0026#34; - \u0026#34;https://ghcr.registry.cyou\u0026#34; - \u0026#34;https://ghcr.chenby.cn\u0026#34; - \u0026#34;https://ghcr.luochen570.top\u0026#34; EOF 每个节点都需要配置，然后重启 k3s 服务：\nsudo systemctl restart k3s # Server 节点 sudo systemctl restart k3s-agent # Agent 节点 卸载节点 # 卸载 Server 节点 /usr/local/bin/k3s-uninstall.sh # 卸载 Agent 节点 /usr/local/bin/k3s-agent-uninstall.sh 验证集群 kubectl get nodes kubectl get pods --all-namespaces 总结 最终集群架构：\n高可用：3 个控制平面节点 + HAProxy 负载均衡，任意单节点故障不影响集群 安全隐藏：只有 agent-ali 暴露公网 IP，Server 节点通过 Tailscale 内网访问 国内加速：内置镜像源列表，解决拉取超时 嵌入式镜像仓库：启用 --embedded-registry，跨节点分发更快 Tailscale 组网：跨地域节点自动互联，无需手动配置 WireGuard ","permalink":"https://hugo.luochen570.cn/posts/k3s-cluster-install/","summary":"\u003ch2 id=\"前言\"\u003e前言\u003c/h2\u003e\n\u003cp\u003e本文记录在多台服务器上部署 k3s 高可用集群的完整过程。集群架构为 \u003cstrong\u003e3 Server + 1 Agent\u003c/strong\u003e，通过 Tailscale 组建 overlay 网络，只有一台节点具有公网 IP，其余节点通过 HAProxy 代理访问。\u003c/p\u003e","title":"k3s 高可用集群安装与配置（国内镜像加速版）"},{"content":"前言 你好，我是洛尘。\n这是这个 Hugo 博客真正意义上的第一篇文章。它不是某个复杂系统的部署教程，也不是一次故障复盘，而是一个简单的开场：我想给自己留一个长期记录技术折腾、系统建设和个人思考的地方。\n过去我做过不少零散的事情：搭服务器、维护自建服务、折腾 Kubernetes、配置 VPN、写自动化脚本、部署各种工具，也经常在不同机器之间迁移环境。很多问题当时解决了，但如果没有记录，过一段时间再回头看，细节就会变得模糊。\n所以这个博客的目的很明确：把折腾过的东西沉淀下来。\n为什么要自己搭博客 选择 Hugo 这类静态博客，主要是因为它足够简单、稳定，也很适合长期维护。\n相比把内容写在某个平台上，自建博客有几个明显好处：\n内容归自己管：Markdown 文件在自己的 Git 仓库里，迁移和备份都方便。 部署链路简单：Hugo 构建成静态文件后，用 Caddy 直接托管即可。 性能和稳定性好：静态页面没有数据库依赖，也不需要复杂运行时。 适合技术记录：命令、配置、拓扑、踩坑过程都能完整保存。 博客本身也是我的一部分基础设施：源码进 Git，静态文件部署到服务器，访问入口由 Caddy 提供。它不只是一个页面，更像是我个人知识库对外可见的一层。\n我会写些什么 这个博客后续大概率会围绕这些方向展开：\n方向 内容 Linux 与服务器运维 系统配置、服务部署、故障处理、性能排查 Kubernetes / k3s 集群搭建、应用部署、网络与存储、日常维护 自托管服务 Gitea、Hugo、监控、网关、反向代理等 网络与 VPN Tailscale、内网访问、跨机器互联、安全访问 开发环境 Zsh、终端工具、编辑器、dotfiles、自动化脚本 折腾记录 一些不一定标准但真实有效的实践经验 我不打算把文章写成“完美教程”。更想保留的是实际操作中的上下文：为什么这么做、踩了什么坑、最后怎么验证成功。\n因为真实环境里的问题往往不是“复制一条命令”就能解决的。很多时候，真正有价值的是排查路径和取舍过程。\n我的记录原则 为了让这些文章以后还能看懂，我希望尽量遵循几个原则。\n1. 写清楚背景 同样一个命令，在不同场景下意义可能完全不同。比如是单机部署，还是集群部署；是公网访问，还是只在内网访问；是临时测试，还是长期运行。\n所以文章开头尽量交代清楚：我在什么环境下、为了解决什么问题、用了什么方案。\n2. 不只贴命令，也解释原因 命令本身很容易复制，但参数背后的原因更重要。尤其是一些服务端配置，如果只记录“怎么写”，以后再看可能已经忘了为什么当时要这么写。\n我希望每篇技术文章至少回答三个问题：\n这个配置解决什么问题？ 为什么选择这种方式？ 怎么确认它真的生效？ 3. 注意隐私和安全 博客会公开访问，所以真实公网 IP、密钥、Token、内部敏感信息都不会直接出现在文章里。需要示例时会使用 x.x.x.x、tskey-auth-xxxxx 之类的占位符。\n技术记录应该可复现，但不应该把自己的基础设施暴露出去。\n4. 保留踩坑过程 很多文章只写最终答案，但我觉得踩坑过程同样重要。\n比如服务为什么没启动、配置为什么没生效、构建为什么没有生成页面、网络为什么连不上。这些过程可能看起来琐碎，但往往是以后排查问题最有用的部分。\n博客也是一个长期项目 我对这个博客的期待不是短时间内写很多文章，而是长期慢慢积累。\n每次解决一个问题，如果它以后还有可能再次遇到，就值得记录下来；每次搭好一个服务，如果部署步骤有复用价值，也值得整理成文；每次踩了一个坑，如果它能帮未来的自己少浪费一点时间，就不算白写。\n技术折腾最怕的是“当时都会，过后全忘”。写博客就是给自己留一条回路：当经验变成文字，它才真正沉淀下来。\n结语 这篇文章就作为一个开始。\n后面我会陆续记录自己的服务器、集群、自托管服务、开发环境和各种折腾过程。内容可能不会总是很正式，但会尽量真实、可验证、可复用。\n如果说这个博客有什么目标，那就是：把每一次折腾变成下一次更快解决问题的经验。\n","permalink":"https://hugo.luochen570.cn/posts/my-first-post/","summary":"\u003ch2 id=\"前言\"\u003e前言\u003c/h2\u003e\n\u003cp\u003e你好，我是洛尘。\u003c/p\u003e\n\u003cp\u003e这是这个 Hugo 博客真正意义上的第一篇文章。它不是某个复杂系统的部署教程，也不是一次故障复盘，而是一个简单的开场：我想给自己留一个长期记录技术折腾、系统建设和个人思考的地方。\u003c/p\u003e","title":"你好，我是洛尘：这是一篇新的开始"},{"content":"你好，我是洛尘。\n这里是我的个人技术博客，主要记录自托管服务、Linux 运维、k3s 集群、Tailscale 组网、Hugo 博客、终端环境和自动化实践。\n我关注什么 方向 记录内容 服务器运维 Linux、systemd、Caddy、服务部署与故障排查 Kubernetes / k3s 集群搭建、应用部署、网络、存储与日常维护 自托管服务 Gitea、Hugo、监控、网关、反向代理等 网络与访问 Tailscale、内网互联、安全访问、服务暴露 开发环境 Zsh、编辑器、dotfiles、CLI 工具、自动化脚本 折腾记录 真实问题、排查路径、踩坑和复盘 写作原则 我希望这里的文章尽量做到：\n有上下文：说明为什么要做，而不只是贴命令。 可验证：每个部署或配置都尽量写清楚验证方法。 可复用：把踩坑过程沉淀成以后还能参考的记录。 注意安全：公开文章不会暴露真实公网 IP、密钥、Token 或敏感基础设施细节。 这个博客的定位 这个博客不是为了追求更新频率，而是作为一个长期的技术沉淀仓库。\n如果某个问题未来可能再次遇到，就值得写下来；如果某个部署步骤能复用，就值得整理；如果某个坑让我浪费过时间，也应该记录，避免以后再踩一次。\n联系方式 Gitea：https://git.luochen570.cn/luochen570 邮箱：1160510664@qq.com ","permalink":"https://hugo.luochen570.cn/about/","summary":"\u003cp\u003e你好，我是洛尘。\u003c/p\u003e\n\u003cp\u003e这里是我的个人技术博客，主要记录自托管服务、Linux 运维、k3s 集群、Tailscale 组网、Hugo 博客、终端环境和自动化实践。\u003c/p\u003e","title":"关于"}]