# Kubernetes 本地开发工具比较:Telepresence、Gefyra 和 mirrord > **作者:** Eyal Bukchin (MetalBear) > > **译者:** [Michael Yao](https://github.com/windsonsea) (DaoCloud) Kubernetes 的开发周期是一个不断演化的领域,有许多工具在寻求简化这个过程。 每个工具都有其独特的方法,具体选择通常取决于各个项目的要求、团队的专业知识以及所偏好的工作流。 在各种解决方案中,我们称之为“本地 K8s 开发工具”的一个类别已渐露端倪, 这一类方案通过将本地运行的组件连接到 Kubernetes 集群来提升 Kubernetes 开发体验。 这样可以在云环境中快速测试新代码,避开了 Docker 化、CI 和部署这样的传统周期。 在本文中,我们将比较这个类别中的三个解决方案:Telepresence、Gefyra 和我们自己的挑战者 mirrord。 ## Telepresence [Telepresence](https://www.telepresence.io/) 是这类工具中最早也最成熟的解决方案, 它使用 VPN(或更具体地说,一个 __tun__ 设备)将用户的机器(或本地运行的容器)与集群的网络相连。 它支持拦截发送到集群中特定服务的传入流量,并将其重定向到本地端口。 被重定向的流量还可以被过滤,以避免完全破坏远程服务。 它还提供了一些补充特性,如支持文件访问(通过本地挂载卷将其挂载到 Pod 上)和导入环境变量。 Telepresence 需要在用户的机器上安装一个本地守护进程(需要 root 权限),并在集群上运行一个 Traffic Manager 组件。此外,它在 Pod 上以边车的形式运行一个 Agent 来拦截所需的流量。 ## Gefyra [Gefyra](https://gefyra.dev/) 与 Telepresence 类似,也采用 VPN 连接到集群。 但 Gefyra 只支持将本地运行的 Docker 容器连接到集群。 这种方法增强了在不同操作系统和本地设置环境之间的可移植性。 然而,它的缺点是不支持原生运行非容器化的代码。 Gefyra 主要关注网络流量,不支持文件访问和环境变量。 与 Telepresence 不同,Gefyra 不会改变集群中的工作负载, 因此如果发生意外情况,清理过程更加简单明了。 ## mirrord 作为这三个工具中最新的工具,[mirrord](https://mirrord.dev/)采用了一种不同的方法, 它通过将自身注入到本地二进制文件中(在 Linux 上利用 __LD_PRELOAD__ ,在 macOS 上利用 __DYLD_INSERT_LIBRARIES__ ), 并重写 libc 函数调用,然后代理到在集群中运行的临时代理。 例如,当本地进程尝试读取一个文件时,mirrord 会拦截该调用并将其发送到该代理, 该代理再从远程 Pod 读取文件。这种方法允许 mirrord 覆盖进程的所有输入和输出,统一处理网络访问、文件访问和环境变量。 通过在进程级别工作,mirrord 支持同时运行多个本地进程,每个进程都在集群中的相应 Pod 上下文中运行, 无需将这些进程容器化,也无需在用户机器上获取 root 权限。 ## 摘要 {#summary}
比较 Telepresence、Gefyra 和 mirrord
Telepresence Gefyra mirrord
集群连接作用域 整台机器或容器 容器 进程
开发者操作系统支持 Linux、macOS、Windows Linux、macOS、Windows Linux、macOS、Windows (WSL)
传入的流量特性 拦截 拦截 拦截或镜像
文件访问 支持 不支持 支持
环境变量 支持 不支持 支持
需要本地 root
如何使用
  • CLI
  • Docker Desktop 扩展
  • CLI
  • Docker Desktop 扩展
  • CLI
  • Visual Studio Code 扩展
  • IntelliJ 插件
## 结论 {#conclusion} Telepresence、Gefyra 和 mirrord 各自提供了独特的方法来简化 Kubernetes 开发周期, 每个工具都有其优缺点。Telepresence 功能丰富但复杂,mirrord 提供无缝体验并支持各种功能, 而 Gefyra 则追求简单和稳健。 你的选择应取决于项目的具体要求、团队对工具的熟悉程度以及所需的开发工作流。 无论你选择哪个工具,我们相信本地 Kubernetes 开发方法都可以提供一种简单、有效和低成本的解决方案, 来应对 Kubernetes 开发周期中的瓶颈,并且随着这些工具的不断创新和发展,这种本地方法将变得更加普遍。