Kubernetes K3s 高可用性：2 节点同步复制和故障转移

简化 K3s 高可用性：为什么选择 SafeKit 而不是 MetalLB 和 Longhorn？

虽然 K3s 的标准开源堆栈（MetalLB + Longhorn）对于大型数据中心而言功能强大，SafeKit 对于双节点本地站点而言，它引入了过多的复杂性。通过用单个综合 HA 引擎替换独立网络和存储工具来简化 K3s 环境。

为什么使用 SafeKit 来实现 2 节点 K3s 的高可用性 (HA)？

• 真正的双节点高可用性： SafeKit 仅需两个节点即可提供完全冗余，从而消除了etcd仲裁所需的三节点要求。
• 零数据丢失 (RPO = 0)： 使用同步字节级复制取代高开销的块存储，以实现本地 SSD 性能。
• 灵活的文件级保护： SafeKit 在文件级别执行基于主机的复制，对应用程序完全透明。它不仅保护数据库，还保护所有相关文件夹和数据。您可以将现有文件夹精确地复制到其安装位置，甚至在系统磁盘上。
• 集成虚拟 IP (VIP)： 在内核级别原生管理集群 IP，无需单独配置 MetalLB。
• 自动故障转移和故障恢复： 在发生故障时立即触发向辅助节点的转换；一旦主节点恢复正常，SafeKit 将在无需人工干预的情况下执行自动数据重新同步。
• 超低开销： SafeKit 运行无需标准堆栈所需的存储 Pod（CSI/Longhorn）和网络 Pod（CNI/MetalLB）的繁重管理开销，从而为您的应用程序释放关键的 RAM 和 CPU。
• 对 IT 通才友好： 用简单的 Web GUI 和自动化部署脚本取代了用于网络和存储的复杂基础设施 YAML，让您只需专注于应用程序。

适用于双节点 K3s 集群的无共享高可用性 (HA)

⚡ Kubernetes 高可用集群快速安装指南 >

目录

• SafeKit 软件如何简单地实现 Kubernetes K3s 高可用性集群？
• SafeKit mirror 集群如何与 Kubernetes K3S 配合使用？
• SafeKit 高可用性限制
• 比较：SafeKit 与标准 K3s 堆栈（MetalLB 和 Longhorn）
• 视频指南：配置 SafeKit mirror HA 集群
• 🔍 探索 SafeKit

SafeKit 软件如何简单地实现 Kubernetes K3s 高可用性集群？

如何为双节点 Kubernetes K3s 集群实现高可用性？

您可以使用 SafeKit k3s.safe mirror 模块为双节点 Kubernetes K3s 集群实现高可用性 (HA)。此解决方案允许您部署冗余环境，而无需外部 NFS 存储、专用外部配置数据库或专业的 Kubernetes 专业知识。

为什么在边缘和物联网计算中使用 K3s？

K3s是物联网和边缘计算的首选 Kubernetes 引擎，因为它是一种轻量级、经过认证的发行版，专为资源受限的环境而设计。它在保持完全兼容性的同时，简化了标准 Kubernetes 的运营开销。

k3s.safe mirror 模块的主要功能有哪些？

k3s.safe 模块通过实现以下功能，为 K3s 提供了一个全面的高可用性堆栈：

• 双主动节点： 同时运行 2 个主动 K3s 主节点/代理，以托管 Pod。
• 数据库复制： 在节点之间实时复制 MariaDB 配置数据库。
• 持久存储： 通过集成的 NFS 客户端动态配置器 (nfs-client) 复制持久卷。
• 网络连续性： 包括虚拟 IP 地址，以便客户端无缝访问。
• 自动化恢复： 完全支持自动故障转移和故障恢复。

除了 K3s，SafeKit 还能保护哪些应用程序和环境？

SafeKit 是一款适用于 Windows 和 Linux 多功能高可用性解决方案，其功能远超 K3s mirror 集群。它支持对各种关键工作负载进行同步实时复制和自动故障转移，包括：

• 虚拟和物理环境： 完整的 Hyper-V 或 KVM 虚拟机。
• 容器编排： Docker、Podman 环境。
• 数据与服务： 单个文件目录、服务和各种数据库。
• 云基础设施： 为云应用程序提供高可用性。

SafeKit 还为 farm 集群提供原生网络负载均衡和故障转移，以支持 Web 服务器等无状态应用程序。

💡 在此处查看支持的 HA 解决方案的完整列表。

SafeKit 如何实现 K3s 的高可用性？

使用 SafeKit 2 节点 K3s 集群的架构和冗余逻辑

自动故障转移机制： 如果主节点发生故障，SafeKit 自动将虚拟 IP 和存储服务迁移到辅助节点，确保 K3s 集群的服务不中断。

SafeKit mirror 集群如何与 Kubernetes K3S 配合使用？

步骤 1：在 mirror 集群中进行字节级文件复制

此阶段说明了服务器 1 (PRIM) 和服务器 2 (SECOND) 之间的可用性架构。两台服务器都运行 K3s master 和 agent 组件，如架构表中定义。

目前，虚拟 IP (VIP)、NFS 持久存储和 MariaDB 仅在服务器 1 (PRIM) 上处于活动状态。两个节点上的 K3s 主组件通过虚拟 IP 和 MariaDB 端口访问集群状态，从而相互同步。SafeKit 了 MariaDB 和持久 NFS 文件的同步复制，确保在发生故障时实现零数据丢失 (RPO = 0)。

K3s master 通过直接与 K3s agent 通信，将工作负载分配到两个（或更多）节点。外部客户端连接到
集群在 PRIM 节点上的虚拟 IP 地址。使用标准 Kubernetes 机制，K3s 主节点将流量中继到分布在各个节点上的 Pod。同样，Pod 通过虚拟 IP 和 NFS 端口访问 PRIM 服务器上的持久卷 (PV)。

步骤 2：自动故障转移和业务连续性

当服务器 1（PRIM） 发生故障时，服务器 2（SECOND） 会自动接管集群操作，以确保连续性。

SafeKit 检测到故障后，会立即将集群的虚拟 IP 地址迁移到服务器 2。然后，它将本地 MariaDB 和 NFS 服务提升为活动状态。由于在步骤 1 中执行了同步复制，所有 MariaDB 数据库和 NFS 持久卷 (PV) 文件在服务器 2 上都已更新，从而确保零数据丢失。

集群状态保留后，服务器 2 上的 K3s Master 继续执行。它检测到服务器 1 代理丢失，并自动将受影响的 Pod 重新调度到剩余的活动 K3s 代理上。总故障转移时间 (RTO) 是故障检测间隔（默认：30 秒）与 K3s 组件在辅助节点上初始化所需时间之和。

在服务器 1 离线期间，MariaDB 和 NFS 服务继续在服务器 2 上运行，仅在本地写入更改。

步骤 3：故障恢复和自动重新集成

当初始问题解决后重新启动服务器 1 时，会发生故障恢复。SafeKit 自动重新同步 MariaDB 和 NFS 文件，仅更新停机期间在服务器 2 上修改的数据。此重新集成过程是非中断性的；K3s 主服务器和代理组件将继续在服务器 2 上运行，不会中断。

SafeKit 会根据服务器的停止方式优化恢复时间：

• 干净关闭： 如果在服务器 1 上有意停止 SafeKit，则仅使用修改跟踪位图对文件内特定修改的区域进行重新同步。这确保了超快速的重新集成。
• 系统崩溃（例如，电源故障）： 如果服务器 1 发生非正常关机，则出于安全考虑，修改位图将被绕过 SafeKit 将重新同步所有修改时间戳晚于上次建立的同步点的时间戳的文件，从而确保数据完整性。

步骤 4：恢复高可用性和负载分配

重新集成后，集群将返回完全 mirror 模式，镜像步骤 1 中描述的状态。系统再次处于高可用状态： MariaDB 和 NFS 服务在服务器 2 上保持活动状态，而 SafeKit 对所有文件更新执行实时复制，并将其返回到服务器 1。

K3s Master 和 K3s Agent 会在服务器 1 上自动重启。Kubernetes 调度程序现在将服务器 1 识别为健康节点，并可以开始重新调度 Pod 以便在两个服务器之间分配工作负载。

如果管理员希望 MariaDB 和 NFS 服务在服务器 1 上运行（恢复原始 PRIM 角色），则可以在方便的时候通过 Web 控制台手动触发切换，也可以通过配置设置自动进行切换。

如何配置 SafeKit mirror 集群？

SafeKit Web 控制台提供了一个直观的界面，用于为您的关键应用程序编排高可用性。只需几个步骤，您就可以配置 SafeKit mirror 集群以确保业务连续性：

• 应用程序故障转移（宏选项卡）： 定义在发生故障时要自动重新启动的特定应用程序服务。
• 心跳网络： 集群节点用于持续监控彼此的运行状况和可用性以及同步故障转移决策的专用通信路径。
• 虚拟 IP 管理： 设置虚拟 IP (VIP)，以便在故障转移后实现透明的客户端重新连接。
• 实时复制： 选择用于基于主机、同步字节级复制的关键目录。
• 检查器： 监控应用程序的运行状况，并在检测到进程故障时触发自动恢复。

SafeKit 集群包含一个专用的裂脑检查器，用于解决网络隔离问题，而无需第三个见证机或额外的保活网络。了解有关集群中的保活、故障转移和仲裁的更多信息。

如何监控 SafeKit mirror 集群？

SafeKit 管理控制台提供高可用性基础设施的统一视图。它允许管理员监控集群的运行状态并实时跟踪数据同步。

对于一个 2 节点 mirror 集群，控制台会清晰地显示每个服务器的角色：

• PRIM（主）： 当前运行应用程序并管理虚拟 IP 的活动节点。它将写入本地存储，并实时复制到辅助节点。
• SECOND（辅助）： 接收同步字节级更新的备用节点。如果主节点发生故障，它已准备好立即接管。
• ALONE 状态： 当集群在单个节点上运行时（例如，在维护期间或发生故障后），会向您发出视觉警报，表明冗余暂时丢失。
• 重新同步进度： 当故障节点恢复时，其状态在后台数据重新集成期间变为橙色，确保在“恢复正常”阶段没有停机时间。

除了简单的状态图标，该界面还提供一键式故障转移编排，允许您在计划维护期间手动重新分配主角色，同时确保用户活动的持续可用性。

SafeKit 高可用性限制

比较：SafeKit 与标准 K3s 堆栈（MetalLB 和 Longhorn）

比较：SafeKit 与标准开源方案 (MetalLB + Longhorn)

总而言之，虽然标准的 DIY 堆栈（MetalLB + Longhorn）为 Kubernetes 专家提供了模块化，但它创建了一个循环依赖，其中存储和网络工具容易受到它们旨在管理的相同节点故障的影响。SafeKit 通过作为独立的底层架构运行来打破这个循环；提供了一个更强大、与硬件无关的双节点高可用性解决方案，即使 Kubernetes 引擎或主机操作系统挂起，它也能保持运行。这确保了自动恢复和数据完整性，而无需传统分布式块存储和网络覆盖所需的繁重资源开销、强制性三节点仲裁或配置复杂性。

视频指南：配置 SafeKit HA mirror 集群

SafeKit 视频：应用级集群 (8:47)

虽然此视频演示了 SafeKit 对 Microsoft SQL Server 的高可用性，但它很好地概述了该解决方案如何保护 K3s 环境。SafeKit 对任何其他数据库或业务关键型应用程序的功能相同。

视频亮点

1. 🎬 两个带有 SQL Server 节点 (0:32)
2. 🎬 配置集群和 mirror.safe 模块 (3:58)
3. 🎬 启动和测试 SQL 复制、迁移、崩溃时故障转移 (4:17)

<br />

🔍 探索 SafeKit

查找有关 SafeKit 功能、架构、视频、文档和免费试用的信息。