码厩技术博客

#742 VPN 重新配置流程

处于安全原因，每隔几个月重新更换一次 OpenVPN 的配置文件，以防被攻击。运维讲配置文件加密打包分发给每个人，然后大家将其覆盖到现在的目录中。

我是 Linux 环境（Ubuntu, 准备切入 Fedora），这里我记录一下更新流程，下次务必 1 分钟之内切换完成。

1. 通过密码解压配置文件

ls ~/Documents/Mine/config20211213/
# ca.crt  client.crt  client.key  client.ovpn

1. 备份之前的证书文件

cd /etc/openvpn
sudo mkdir backup20211227
sudo mv ca.crt client.crt client.key client.ovpn backup20211227/
sudo cp client.conf backup20211227/

1. 采用新的证书文件

sudo mv ~/Documents/Mine/config20211213/{ca.crt,client.crt,client.key,client.ovpn} /etc/openvpn
sudo chmod 400 /etc/openvpn/{ca.crt,client.crt,client.key,client.ovpn}

1. 通过和旧的 client.ovpn 文件比对，讲需要修改的地方同步到 /etc/openvpn/client.conf 中

sudo diff client.ovpn backup20211227/client.ovpn
sudo vim /etc/openvpn/client.conf
# w! sudo tee %

1. 重新启动 OpenVPN，试一下是否配置成功

sudo systemctl restart openvpn@client

#741 转载：正则表达式历史

正则表达式在我们日常的软件开发过程中被广泛使用，例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件，然而不同软件不同操作系统对于正则的应用有着不一样的行为，主要原因是正则表达式演进过程中，出现 POSIX 与 PCRE 派系之分。

#740 操作系统是如何解析 DNS 的 [编辑中]

:) 本文正在编辑中，暂时不提供浏览...

#739 DNS 负载均衡 [编辑中]

:) 本文正在编辑中，暂时不提供浏览...

#738 curl 使用的 DNS 为什么和 dig 的结果不一致 [编辑中]

:) 本文正在编辑中，暂时不提供浏览...

#737 Bing 打不开了

Bing 是我的默认搜索引擎。但是今天早上发现 Bing 打不开了，只有通过特殊手段才行。

1. 应监管部门要求，Bing 需要在 30 天内对搜索框的建议功能做出整改，看到很多网友贴出了公告。
2. https://www4.bing.com 目前可用 (随时会挂)
3. 切换到谷歌 DNS 之后，Bing 可以正常访问

Update @ 2021-12-19: 必应搜索恢复正常访问（持续时间大约 2 天）。

#736 K8S 核心概念

Kubernetes (K8S) 可以通过以下方式判断每个容器需要的资源情况，然后据此进行调度：

可以根据容器所需资源情况调度：

• 定义 Pod 的资源需求和限制：可以在 Pod 的 YAML 文件中定义每个容器的资源需求和限制，包括 CPU 和内存。
  这样 Kubernetes 调度器就可以根据这些需求来选择节点和分配资源。
• 监测容器资源使用情况：Kubernetes 可以通过 kubelet 代理监测每个容器的资源使用情况，包括 CPU 和内存使用率。
  这样 Kubernetes 调度器就可以根据容器的实际资源使用情况来调整 Pod 的调度策略。
• 自动伸缩 Pod：Kubernetes 还可以根据容器的资源使用情况自动伸缩 Pod 的数量。
  可以通过 Horizontal Pod Autoscaler (HPA) 来设置 Pod 的最小和最大副本数，以及触发自动伸缩的 CPU 和内存使用率阈值。
• 节点亲和性和反亲和性：Kubernetes 可以通过节点亲和性和反亲和性来指定容器在哪些节点上运行，以及在哪些节点上不运行。
  可以通过节点标签和 Pod 标签来实现亲和性和反亲和性。

一、K8S 架构概述

K8S 采用主从架构，主要由控制平面（Control Plane）和工作节点（Worker Nodes）构成，这种架构设计使得系统具有良好的可扩展性和稳定性。

• 控制平面（Master）：作为 K8S 集群的“大脑”，负责全局决策和管理，包含多个关键组件。
  • API Server：是 K8S 的核心接口，提供了一套 RESTful API，用户、客户端工具以及其他组件都通过它来与集群进行交互，实现对集群资源的操作和管理。
  • etcd：用于存储集群的配置信息和状态数据，是一个高可用的键值存储数据库，保证了数据的一致性和持久性。
  • Controller Manager：包含多个控制器，如节点控制器、副本控制器等，它们负责监控集群状态，并根据期望状态进行调整，确保集群始终处于稳定运行状态。
  • Scheduler：负责将待部署的 Pod 调度到合适的工作节点上，它会根据节点的资源情况、Pod 的需求等因素进行综合考量，以实现资源的最优分配。
• 工作节点（Node）：是运行应用容器的实际服务器，可以是物理机或虚拟机，每个节点都运行着一些必要的组件。
  • Kubelet：作为节点上的代理，负责与控制平面通信，接收并执行 Pod 的部署任务，同时监控容器的运行状态。
  • Kube Proxy：实现服务的网络代理功能，负责将服务的访问请求转发到相应的 Pod 上，确保服务的可访问性。
  • 容器运行时（Container Runtime）：用于运行容器，常见的有 Docker、containerd 等。

二、核心资源对象

在 K8S 中，一切皆为资源对象，通过操作这些对象来管理应用。

• Pod：是 K8S 中最小的部署单元，它可以包含一个或多个紧密相关的容器。这些容器共享网络和存储资源，通常作为一个整体被调度和管理。例如，一个 Web 应用 Pod 可能包含 Web 服务器容器和日志收集容器。
• Service：定义了一组 Pod 的访问规则，为这些 Pod 提供了一个稳定的网络接口。无论 Pod 如何动态变化，Service 都能确保客户端可以通过固定的 IP 和端口访问到服务。Service 有多种类型，如 ClusterIP（仅在集群内部可访问）、NodePort（通过节点端口暴露服务）、LoadBalancer（使用云服务商的负载均衡器）等。
• Deployment：用于管理 Pod 的部署和更新，它定义了 Pod 的期望状态，包括副本数量、镜像版本等。通过 Deployment，可以轻松实现应用的滚动更新、回滚等操作，确保服务的高可用性。例如，当需要更新应用版本时，Deployment 会逐步替换旧的 Pod，而不会导致服务中断。
• ReplicaSet（RS）：确保指定数量的 Pod 副本始终处于运行状态，它是 Deployment 的底层实现。通常情况下，我们通过 Deployment 来间接管理 ReplicaSet，而不是直接操作 ReplicaSet。
• StatefulSet：与 Deployment 不同，StatefulSet 用于管理有状态的应用，如数据库。它能保证 Pod 的顺序性和唯一性，为每个 Pod 提供稳定的标识符和持久化存储，确保应用在重启或迁移后能够恢复到正确的状态。
• DaemonSet：确保每个节点上都运行一个指定的 Pod 副本，常用于部署系统监控、日志收集等需要在每个节点上运行的服务。例如，Prometheus Node Exporter 就可以通过 DaemonSet 部署到每个节点上，以收集节点的性能指标。
• Job/CronJob：Job 用于执行一次性的任务，当任务完成后，Pod 会被自动终止。CronJob 则用于定时执行任务，类似于 Linux 系统中的 cron 任务，例如每天凌晨备份数据库就可以通过 CronJob 来实现。
• Namespace：用于在逻辑上划分集群资源，不同 Namespace 中的资源相互隔离。它可以帮助多个团队或项目在同一个集群中共享资源，同时又不会相互干扰。例如，开发环境和生产环境可以分别使用不同的 Namespace。
• ConfigMap/Secret：用于存储配置信息和敏感数据，如应用的配置文件、数据库密码等。通过将这些信息与容器镜像分离，可以在不修改镜像的情况下，灵活地更新应用的配置。ConfigMap 用于存储非敏感的配置信息，Secret 则用于存储敏感信息，并且会对数据进行加密存储。
• Volume：为 Pod 提供持久化存储，它可以是本地存储、网络存储（如 NFS、Ceph）等。Volume 使得容器在重启后仍然可以访问到之前的数据，保证了数据的持久性。例如，数据库 Pod 可以使用 Volume 来存储数据文件。

三、关键术语与机制

• 标签（Label）与选择器（Selector）：标签是附着在资源对象上的键值对，用于对资源进行分类和标识。选择器则用于根据标签筛选资源对象，是 Service、Deployment 等组件关联 Pod 的重要方式。例如，一个 Service 可以通过标签选择器找到所有具有特定标签的 Pod，并将流量转发给它们。
• 控制器（Controller）：K8S 中的核心组件，通过持续监控资源的实际状态与期望状态的差异，并进行调整，来实现集群的自修复能力。除了前面提到的 Deployment、ReplicaSet 等控制器，还有 NodeController、ServiceController 等。
• 声明式 API：K8S 采用声明式 API，用户只需定义资源的期望状态，而无需关心具体的实现过程。系统会自动将实际状态调整为期望状态，这种方式大大简化了应用的部署和管理。例如，用户只需要编写一个 Deployment 的 YAML 文件，指定 Pod 的副本数量和镜像版本，K8S 就会自动创建和管理这些 Pod。
• 服务发现与负载均衡：K8S 内置了服务发现机制，Service 会自动注册和发现相关的 Pod。同时，Service 还提供了负载均衡功能，将客户端的请求均匀地分发到多个 Pod 上，提高了服务的可用性和性能。
• 自动扩缩容（HPA/VPA）：Horizontal Pod Autoscaler（HPA）可以根据 CPU、内存等指标自动调整 Pod 的副本数量，以适应应用的负载变化。Vertical Pod Autoscaler（VPA）则可以根据 Pod 的资源使用情况自动调整其资源请求和限制。
• 滚动更新与回滚：Deployment 支持滚动更新，在更新过程中，会逐步替换旧的 Pod，同时保持服务的正常运行。如果更新出现问题，还可以快速回滚到之前的稳定版本，确保服务的可靠性。

四、新人入门建议

• 搭建本地环境：使用 Minikube 或 Docker Desktop 搭建本地 K8S 集群，便于动手实践，加深对概念的理解。
• 学习 YAML 配置：K8S 主要通过 YAML 文件来定义资源对象，熟练掌握 YAML 的语法和结构是非常重要的。
• 动手实践：从部署简单的应用开始，如 Nginx、MySQL 等，逐步熟悉 Pod、Service、Deployment 等资源的创建和管理。
• 阅读官方文档：K8S 的官方文档非常详细，是学习的重要资料。可以从入门指南开始，逐步深入学习各个概念和功能。
• 参与社区：K8S 社区非常活跃，可以通过论坛、博客、社交媒体等渠道与其他开发者交流，获取经验和解决问题。

和 Docker 生态的对比

和虚拟化生态（KVM / OpenStack）的对比

本质是计算机资源的隔离和管理，单技术原理和应用场景有显著差异：

一、核心技术定位对比

二、技术架构与实现原理

• 虚拟化生态（KVM/OpenStack）

  • KVM（Kernel-based Virtual Machine）

    • 定位：Linux 内核原生支持的硬件虚拟化技术，属于 Type 1 hypervisor（裸金属虚拟化）。
    • 核心组件：
      • KVM 模块：运行在宿主机内核中，负责创建和管理虚拟机（VM）。
      • QEMU：模拟虚拟机的硬件设备（如网卡、磁盘），与 KVM 协同工作。
      • VM：包含独立的操作系统、应用程序和配置，通过镜像（如 qcow2）存储。
    • 隔离机制：通过 CPU 虚拟化（Intel VT-x/AMD-V）、内存分页技术（EPT/MMU）实现硬件资源隔离，每个 VM 拥有独立内核。

  • OpenStack

    • 定位：开源云计算管理平台，用于编排虚拟化资源（VM、网络、存储），构建私有云或公有云。
    • 核心组件：
      • Nova：计算节点管理，负责 VM 的创建、调度和生命周期管理。
      • Neutron：网络服务，为 VM 提供虚拟网络功能（如 IP 分配、负载均衡）。
      • Cinder/Glance：存储与镜像服务，管理 VM 的持久化存储和镜像分发。
    • 特点：通过 API 接口实现对 KVM 等 hypervisor 的统一管理，支持大规模 VM 集群的资源调度。

  • K8S 与容器技术

    • 核心架构（与虚拟化的关联）：
      • 节点（Node）：可以是物理服务器或虚拟机（VM），K8S 不关心底层基础设施，仅要求节点运行容器运行时（如 Docker、containerd）。
      • 容器隔离：基于 Linux 命名空间（Namespace）隔离进程空间，通过控制组（Cgroup）限制资源使用，共享宿主机内核，因此资源占用远低于 VM。
      • 编排能力：通过 YAML 声明式配置，实现容器化应用的自动部署、扩缩容和故障恢复，无需手动管理底层服务器。

三、关键特性对比详解

1. 资源占用与性能

   • 虚拟化（KVM）：
     • 每个 VM 需加载独立操作系统内核，内存占用通常为数百 MB 到数 GB（如 Ubuntu VM 至少占用 512MB 内存）。
     • 启动时间以秒为单位（10~30 秒），性能接近物理机（因硬件虚拟化开销较小）。
   • 容器（K8S）：
     • 容器共享宿主机内核，内存占用可低至 10MB（如 Alpine 镜像的容器）。
     • 启动时间毫秒级（100ms 内），适合快速启停和弹性扩缩容（如应对突发流量）。

2. 隔离性与安全性

   • 虚拟化：
     • 隔离性强，VM 之间完全隔离（包括内核、驱动），一个 VM 的故障不会影响其他 VM。
     • 安全性高，适合多租户环境（如公有云），可通过硬件虚拟化技术（如 Intel SGX）增强隔离。
   • 容器：
     • 隔离性较弱，依赖宿主机内核的安全性（若内核存在漏洞，可能导致容器逃逸）。
     • 安全性需通过额外机制增强（如 Seccomp、AppArmor 限制容器权限），更适合同租户内的微服务隔离。

3. 部署与管理复杂度

   • OpenStack + KVM：
     • 部署复杂，需配置计算、网络、存储等多个组件，运维门槛高（如 Neutron 网络配置易出错）。
     • 管理 VM 时需手动配置镜像、网络策略、存储挂载，适合静态资源分配场景（如固定业务负载）。
   • K8S：
     • 声明式管理，通过 YAML 定义应用“期望状态”（如副本数、资源限制），系统自动实现。
     • 支持应用级灰度发布、滚动更新，无需停机即可升级服务，适合快速迭代的互联网应用。

4. 应用迁移与兼容性

   • 虚拟化：
     • 适合传统单体应用上云，无需修改代码即可迁移（如 Windows 应用通过 VM 运行）。
     • 对 legacy 应用兼容性好，但资源利用率低（如单台物理机运行多个低负载 VM）。
   • 容器：
     • 要求应用支持容器化改造（如拆分微服务、无状态设计），传统应用需重构才能发挥优势。
     • 资源利用率高（单节点可运行数百个容器），但对有状态应用（如数据库）的支持需额外存储方案。

四、适用场景对比

• 推荐使用虚拟化（KVM/OpenStack）的场景：

  • 传统企业应用迁移：如 ERP、OA 等单体应用，无法容器化改造，需通过 VM 保留原有运行环境。
  • 多租户公有云/私有云：需强隔离性的场景（如金融、政府行业），避免租户间资源冲突或安全漏洞。
  • GPU 等特殊硬件管理：通过 VM 独占 GPU 资源（如深度学习训练），KVM 支持更成熟的硬件直通技术。
  • 长生命周期服务：如数据库集群、中间件服务，无需频繁启停，更关注稳定性而非弹性。

• 推荐使用 K8S + 容器的场景：

  • 云原生微服务架构：如电商平台、社交应用，拆分为多个微服务，通过 K8S 实现自动调度和故障恢复。
  • 弹性伸缩与峰值流量：如双十一促销、直播平台，支持秒级扩缩容 hundreds of Pod，按需分配资源。
  • CI/CD 与快速迭代：开发测试环境中，容器镜像可快速构建部署，配合 K8S 的滚动更新实现持续交付。
  • 资源利用率优先场景：如云计算厂商的 Serverless 服务，通过容器高密度部署提升硬件利用率。

五、技术协同与混合部署

K8S 与虚拟化并非对立，而是常以混合形态存在：

1. K8S 运行在虚拟机上：

   • 多数生产环境中，K8S 集群的节点本身是 VM（如通过 OpenStack 创建），利用 VM 的隔离性实现集群资源的安全划分。
   • 例如：企业用 OpenStack 构建私有云，在 VM 上部署 K8S，既享受 VM 的稳定性，又利用 K8S 管理容器化应用。

2. 容器与 VM 的互补场景：

   • VM 运行有状态服务：如数据库、大数据集群，利用 VM 的强隔离性保障数据安全。
   • 容器运行无状态服务：如 Web 前端、API 服务，通过 K8S 实现弹性扩缩容。

3. 新型技术融合：

   • Kata Containers：结合 VM 和容器优势，用轻量级 VM 包裹容器，实现“容器的便捷性 + VM 的隔离性”，适合对安全性要求高的容器场景。
   • OpenStack 对 K8S 的支持：OpenStack 社区推出 Magnum 组件，支持在 OpenStack 上部署 K8S 集群，简化云原生应用的基础设施管理。

六、技术演进与未来趋势

• 虚拟化的定位：从“通用计算平台”转向“特殊场景刚需”，如强隔离、传统应用兼容、硬件直通等领域仍不可替代。
• K8S 的扩张：成为云原生时代的“操作系统”，不仅管理容器，还通过 Project Krustlet 等项目尝试管理 VM、物理机等异构资源。
• 混合架构常态化：企业 IT 环境将同时存在 VM 和容器，K8S 可能成为统一的资源编排层，而 OpenStack 专注于基础设施虚拟化。

#735 Tornado 正在死亡

2020 年 10 月发布的 6.1，结果到现在，已经一年多过去了，6.2 还没有见到。
Update @ 2022-04-28: 又过去了小半年，6.2 还是没有影子。

从 GitHub 提交频率图上明显可以看到 Tornado 的活跃度大幅下滑，2020 年的提交已然不多，2021 年更加惨不忍睹。

官方协程框架 AsyncIO 的诞生，标志着 Tornado 的历史使命已经完成。

是时候带着对 Tornado 的回忆，全面转投原生协程生态了。

#734 plocate

Fedora 36 将采用 plocate 替代 mlocate 成为默认的查找索引，据说更快。
而且 Debian 也早采纳了 plocate。

• 官网: https://plocate.sesse.net/
• 代码仓库: https://git.sesse.net/?p=plocate;a=tree

安装

apt show plocate
# Package: plocate
# Version: 1.1.8-2
# Priority: optional
# Section: universe/utils
# Origin: Ubuntu
# Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
# Original-Maintainer: Steinar H. Gunderson <sesse@debian.org>
# Bugs: https://bugs.launchpad.net/ubuntu/+filebug
# Installed-Size: 510 kB
# Depends: libc6 (>= 2.33), libgcc-s1 (>= 3.3.1), libstdc++6 (>= 6), liburing1 (>= 0.7), libzstd1 (>= 1.4.0)
# Suggests: systemd-sysv | powermgmt-base, systemd-sysv | nocache
# Breaks: mlocate
# Replaces: mlocate
# Homepage: https://plocate.sesse.net/
# Task: xubuntu-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi
# Download-Size: 119 kB
# APT-Manual-Installed: yes
# APT-Sources: https://mirrors.cloud.tencent.com/ubuntu impish/universe amd64 Packages
# Description: much faster locate
#  plocate is a locate(1) based on posting lists, giving much faster searches
#  on a much smaller index. It is a drop-in replacement for mlocate in nearly
#  all aspects, and is fast on SSDs and non-SSDs alike.

sudo apt install -y plocate

使用

根据 apt show 信息，plocate 会 break mlocate。
updatedb 命令会改由 plocate 提供。

ll /usr/bin/locate /usr/bin/updatedb /etc/alternatives/locate /etc/alternatives/updatedb
lrwxrwxrwx 1 root root 16 2021-12-15 11:51:56 /etc/alternatives/locate -> /usr/bin/plocate
lrwxrwxrwx 1 root root 26 2021-12-15 11:51:56 /etc/alternatives/updatedb -> /usr/sbin/updatedb.plocate
lrwxrwxrwx 1 root root 24 2021-12-15 11:51:56 /usr/bin/locate -> /etc/alternatives/locate
lrwxrwxrwx 1 root root 26 2021-12-15 11:51:56 /usr/bin/updatedb -> /etc/alternatives/updatedb

根据官网提供的演示数据，其 DB 只有 mlocate 的 40%，查询时间只有 mlocate 的万分之四。

其具体操作和 mlocate 类似：

sudo updatedb

locate go.mod

有没有 2500 倍的提升我不知道，但是感觉好像确实快。挺好！

参考资料与拓展阅读

• OSCHINA, Fedora 36 将使用新的查找索引组件 Plocate

#733 基于 CentOS Stream 的桌面环境

CentOS Stream 9 已于月初发布，基于 Fedora 34，这就是 RHEL 9 未来的发展方向。
CentOS Stream 的稳定性应该是比 Fedora 更好，如果我想选择改用 Fedora 当桌面环境，为什么不试试 CentOS Stream 呢？
这里就开始调研一下。