通知：《打工人日报》迁移到独立板块 考虑到近期的一些情况，我决定将《打工人日报》迁移到独立板块，将不在首页展示，后续的更新将在独立板块中进行。不影响原文章的阅读和订阅邮件的推送。感谢各位的支持和关注！！！
访问地址 访问链接 首页点击访问
介绍 Apache SkyWalking 是一个应用性能监控（APM）系统，用于分布式系统的监控、追踪和诊断。它提供了完整的可观测性解决方案，帮助开发者和运维人员快速定位和解决分布式系统中的性能问题。
组件说明 OAP (Observability Analysis Platform): 核心分析平台，负责数据收集、分析和存储 UI: Web 界面，用于可视化和查询监控数据 BanyanDB: 高性能时序数据库，作为 SkyWalking 的存储后端 etcd: 分布式键值存储，BanyanDB 使用它来存储元数据 功能特性 分布式追踪: 自动收集和关联分布式系统的调用链，支持跨服务追踪 服务拓扑: 可视化服务之间的依赖关系，实时展示服务调用图 性能指标: 收集服务的性能指标（延迟、吞吐量、错误率等） 日志关联: 将日志与追踪数据关联，通过 TraceID 快速定位问题 告警机制: 支持基于指标的告警规则配置 部署 前置要求 在开始部署之前，请确保满足以下要求：
Kubernetes 集群: 版本 1.20+ 命名空间: 已创建 logging 命名空间（或根据实际情况修改） 存储: 确保节点有足够的存储空间（建议至少 10Gi） 网络: 确保 Pod 之间可以正常通信 提示: 本文档中的所有资源都部署在 logging 命名空间中，如需使用其他命名空间，请修改相应的 YAML 文件。
部署 BanyanDB BanyanDB 是 SkyWalking 的存储后端，需要先部署 BanyanDB 和 etcd。
1. 部署 etcd etcd 用于存储 BanyanDB 的元数据。
背景 在k8s 部署一套 promtail + loki + grafana 日志系统。日志由 Promtail 从 Kubernetes 集群中收集并发送到 Loki。Promtail 会提取以下标签：
namespace: Pod 所在的命名空间 pod_name: Pod 名称 deployment_name: Deployment 名称（从 Pod 的 app 标签或 Pod 名称中提取） container: 容器名称 部署 loki Deployment: Loki 主服务 Service: 提供集群内部访问 ConfigMap: Loki 配置文件 PVC: 数据持久化存储（10Gi） PV: 数据存储类 创建 YAML 文件 首先创建 namespace:
1kubectl create namespace logging 创建 loki 目录并创建 pv.yaml
1apiVersion: v1 2kind: PersistentVolume 3metadata: 4 name: loki-data-pv 5spec: 6 capacity: 7 storage: 10Gi # 存储大小 8 accessModes: 9 - ReadWriteOnce 10 persistentVolumeReclaimPolicy: Retain 11 storageClassName: host-loki 12 hostPath: 13 path: /data/loki # 存储位置 14 type: DirectoryOrCreate 15 nodeAffinity: 16 required: 17 nodeSelectorTerms: 18 - matchExpressions: 19 - key: kubernetes.
故障 多master集群的k8s其中一台master 出现 You must be logged in to the server (Unauthorized)，说明当前节点上的 kubectl 无法认证到 apiserver。
共有三台master：
master1 正常 master2 异常 master3 异常 排查问题 用 admin 证书直接用 curl 测试认证 1curl --cert /etc/kubernetes/pki/admin.crt --key /etc/kubernetes/pki/admin.key -k https://10.10.10.68:6443/healthz 结果 HTTP/1.1 200 OK → TLS + 认证成功（client cert 被接受）。 若返回 401/403 → TLS 成功但授权失败（RBAC 或 client cert 虽被接受但没有权限）。把完整返回贴来。 若 curl 报 TLS 错误 → client cert/CA 有问题（贴错误信息）。 把 kubeconfig 中的 client cert/key 解码到临时文件并检查它们（确认 kubectl 用的是这个证书、并检查证书 Subject/CN/到期日） 1# 解码证书与私钥 2awk '/client-certificate-data/ {print $2}' ~/.
背景 鉴于 Ingress NGINX 将在 2026 年 3 月停止积极维护（只保留 “best-effort maintenance”）考虑切换到Traefik。Traefik 官方推荐是最直接的替代，因为 Traefik 围绕 Ingress NGINX 的兼容层做了优化：它对部分常见的 nginx-ingress 注解提供了兼容支持。
MEtalLB 安装 1kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.2/config/manifests/metallb-native.yaml 1kubectl get pods -n metallb-system 创建 metallb-config.yaml
1# metallb-config.yaml 2apiVersion: metallb.io/v1beta1 3kind: IPAddressPool 4metadata: 5 name: local-pool 6 namespace: metallb-system 7spec: 8 addresses: 9 - 10.10.10.180-10.10.10.181 # ← 修改为你的局域网可用 IP 10--- 11apiVersion: metallb.io/v1beta1 12kind: L2Advertisement 13metadata: 14 name: l2adv 15 namespace: metallb-system 1kubectl apply -f metallb-config.
介绍 提供一个在 Kubernetes 中使用 cert-manager + Cloudflare 自动签发并自动更新 Let’s Encrypt 证书的完整思路与示例（DNS-01 验证），方便你在集群内自动化 TLS 证书更新。
前置条件 Kubernetes 集群：可正常访问外网。不做网络环境配置的教程，具体可以去看其他文章 Cloudflare 账号：已将你的域名托管到 Cloudflare。使用 Cloudflare 做 dns-01 挑战 kubectl：已连接到集群。最基本的条件，保证k8s能正常访问 helm：推荐用 Helm 安装 cert-manager。使用helm安装，方便干净 安装 官方推荐用 Helm，这里我使用 1.18.2 的版本，在我这个时间点这个版本还是比较新的
安装 cert-manager 1# 安装 cert-manager CRDs 2kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.crds.yaml 1## Add the Jetstack Helm repository 2helm repo add jetstack https://charts.jetstack.io --force-update 1## Install the cert-manager helm chart 2helm install cert-manager --namespace cert-manager --version v1.18.2 jetstack/cert-manager 验证：
准备工作 节点名称 节点IP k8s-master-1 10.10.10.151 k8s-master-2 10.10.10.152 k8s-master-3 10.10.10.153 kube-vip(虚拟IP) 10.10.10.150 RKE 安装 rancher 在第一个 master 安装 RKE2 server 1# 安装 RKE2 2curl -sfL https://get.rke2.io | sh - 创建配置文件
1mkdir -p /etc/rancher/rke2/ 1# 配置 server 2cat <<EOF >/etc/rancher/rke2/config.yaml 3write-kubeconfig-mode: "0644" 4tls-san: 5 - 10.10.10.150 6 - rancher.jobcher.com 7cni: cilium 8disable-kube-proxy: true 9EOF 1# 启动 server 2systemctl enable rke2-server --now 3systemctl status rke2-server 1ln -s /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/kubectl 2echo 'export KUBECONFIG=/etc/rancher/rke2/rke2.yaml' >> ~/.
介绍 TLS v1.3（Transport Layer Security version 1.3）是传输层安全协议的最新正式版本，用于在计算机网络中提供加密通信。它由 IETF（Internet Engineering Task Force） 于 2018 年 8 月正式发布，是对 TLS v1.2 的重大改进。
由于原有老的nginx版本不支持新的TLSv1.3,需要升级nginx和openssl。
🔐 TLS 的用途 TLS 常用于以下场景：
HTTPS（浏览器访问网站） 邮件客户端与服务器通信（如 IMAP/SMTP over TLS） VPN、聊天工具等需要安全传输的场合 ✨ 相比 TLS 1.2，TLS 1.3 有哪些主要改进？ 特性 TLS 1.2 TLS 1.3 握手轮数 至少 2 次往返 最多 1 次往返，支持 0-RTT 加密套件 多且复杂，包含弱算法 简化，仅支持强加密算法 前向保密 可选 强制启用 加密内容 一部分未加密 握手后所有内容都加密，包括证书 安全性 存在旧漏洞（如 BEAST、POODLE） 移除已知不安全特性 性能 较慢 更快（特别是在移动网络） 🔧 移除的内容（相比 TLS 1.2） RSA 密钥交换（只保留 ECDHE/DHE） 不安全的加密算法（如 RC4、3DES、MD5） 静态密钥协商、不再支持非前向保密 会话恢复机制被简化为基于票据（session tickets） ✅ TLS 1.
背景 由于增加了新的pve机器组了pve集群，这过程中发生很多事情，打算记录一下过程中发生的问题。
如何不使用企业源完成pve更新 修改订阅源 禁用企业源
添加 no-subscription 源
执行命令 到具体的pve机器上执行命令
1apt update 2apt dist-upgrade 3# 查看版本 4pveversion HA 集群无法正常运行 出现lrm pve (old timestamp - dead?)获取不到pve主机状态
查看 lrm 服务状态
1systemctl status pve-ha-lrm 2systemctl status pve-ha-crm 重启 lrm 服务
1# 重启 lrm 服务 2systemctl restart pve-ha-lrm 3# 重启 crm 服务 4systemctl restart pve-ha-crm
背景 最近看到了一本电子书《just for fun》 Linux之父：林纳斯的自传。就想上传到kindle上去看这本书，但是之前epub的上传都没有问题，唯独这本一直上传失败。E999 故障。我直接说我对于这个问题的解决办法。
解决方法 将epub转换为mobi格式 将装换好的mobi文件再转换为新的epub文件 上传新的epub文件到kindle 总结 感觉是原本的epub文件格式有损坏导致，amzon无法正确识别epub格式，所有按照这个方式转换一遍，基本上上传就没有问题了。
环境准备(配置代理) proxy_setting.yml
1--- 2- name: 设置全局代理并测试连接 3 hosts: all 4 become: yes 5 vars: 6 proxy_host: "10.10.10.254" 7 proxy_port: "7890" 8 http_proxy: "http://{{ proxy_host }}:{{ proxy_port }}" 9 https_proxy: "http://{{ proxy_host }}:{{ proxy_port }}" 10 no_proxy: "localhost,127.0.0.1" 11 12 environment: 13 http_proxy: "{{ http_proxy }}" 14 https_proxy: "{{ https_proxy }}" 15 no_proxy: "{{ no_proxy }}" 16 17 tasks: 18 - name: 显示代理设置 19 debug: 20 msg: 21 - "HTTP Proxy: {{ http_proxy }}" 22 - "HTTPS Proxy: {{ https_proxy }}" 23 - "NO_PROXY: {{ no_proxy }}" 24 25 - name: 使用 curl 测试外部连接（使用代理） 26 command: curl -I https://www.
背景 我主要介绍通过openwrt中的openclash覆写hosts实现dns劫持的方法。
操作 进入openwrt后台，进入openclash，进入覆写设置，进入dns设置
勾选hosts，并写入hosts信息,10.10.10.6是内网nas的ip地址，你可以改成任意的IP
1'nas.com': 10.10.10.6 2'*.nas.com': 10.10.10.6 3. 保存并应用 测试 1ping nas.com 2ping www.nas.com 总结 openclash实现dns劫持的方法非常简单，只需要在openclash中配置hosts即可。
