|
| 1 | +--- |
| 2 | +title: "Telepresence vs mirrord" |
| 3 | +hide_table_of_contents: true |
| 4 | +--- |
| 5 | + |
| 6 | +## Telepresence |
| 7 | + |
| 8 | +Telepresence is a very feature rich tool, designed to handle a large majority of use-cases. You can use it as a cluster VPN only, or use one of its three different ways (replace, intercept, or ingest) to engage with the cluster's resources. |
| 9 | + |
| 10 | +Telepresence is intended to be installed in the cluster by an administrator and then let clients connect with a very limited set of permissions. This model is generally required by larger companies. |
| 11 | + |
| 12 | +The client can be either completely contained in Docker or run directly on the workstation. The latter will require the creation of a virtual network device, and hence admin access. |
| 13 | + |
| 14 | +## mirrord |
| 15 | + |
| 16 | +Mirrord was designed with simplicity in mind. You install the CLI tool, and that's it. It will do the rest automatically under the hood. |
| 17 | + |
| 18 | +Mirrord solves the same problem as Telepresence, but in a different way. Instead of providing a proper network |
| 19 | +device and remotely mounted filesystems, mirrord will link the client application with a `mirrord-layer` shared library. This library will intercept accesses to the network, file system, and environment variables, and reroute them to a corresponding process in the cluster (the `mirrord-agent`) which then interacts with the targeted pod. |
| 20 | + |
| 21 | +### Limitations |
| 22 | + |
| 23 | +While mirrotd is simple to set up, the chosen approach has several limitations, both on the client and the cluster side. |
| 24 | + |
| 25 | +### Limitations when using dynamic loading: |
| 26 | + |
| 27 | +1. It will only work on Linux and macOS platforms. There's native support on Windows. |
| 28 | +2. It will only work with dynamically linked executables. |
| 29 | +3. It cannot be used with docker unless you rebuild the container and inject the `mirrord-layer` into it. |
| 30 | +4. `DYLD_INSERT_LIBRARIES` causes various problems on macOS (SIP prevents it from being used), especially on silicon-based machines where mirrord will require Rosetta. |
| 31 | +5. Should Apple decide to protect their intel-based platform the same way as the silicon-based one in a future release, then mirrord will likely be problematic to use on that platform. |
| 32 | + |
| 33 | +### Cluster Permissions |
| 34 | + |
| 35 | +Mirrord does not require a sidecar. Instead they install a the `mirror-agent` into the namespace of the pod that it impersonates. That agent requires several permissions that a cluster admin might consider a security risk: |
| 36 | + |
| 37 | +* `CAP_NET_ADMIN` and `CAP_NET_RAW` - required for modifying routing tables |
| 38 | +* `CAP_SYS_PTRACE` - required for reading target pod environment |
| 39 | +* `CAP_SYS_ADMIN` - required for joining target pod network namespace |
| 40 | + |
| 41 | +Unless using "mirrord for Teams" (proprietary), all users must have permissions to create the job running the `mirror-agent` in the cluster. |
| 42 | + |
| 43 | +## Comparison Telepresence vs mirrord |
| 44 | + |
| 45 | +This comparison chart applies to the Open Source editions of both products. |
| 46 | + |
| 47 | +| Feature | Telepresence | mirrord | |
| 48 | +|---------------------------------------------------------------------------|--------------|---------| |
| 49 | +| Connect your local process to Kubernetes | ✅ | ✅ | |
| 50 | +| Works without root permission | ✅ [^1] | ✅ | |
| 51 | +| Compatible with clusters of any size | ✅ | ✅ | |
| 52 | +| Works without restarting the remote service | ✅ [^2] | ✅ | |
| 53 | +| Doesn't require a sidecar | ✅ [^3] | ✅ | |
| 54 | +| Supports connecting to clusters over a corporate VPN | ✅ | ✅ | |
| 55 | +| Can intercept traffic | ✅ | ✅ | |
| 56 | +| Can ingest a container | ✅ | ❌ | |
| 57 | +| Can replace a container | ✅ | ❌ | |
| 58 | +| Can mirror traffic | ❌ | ✅ | |
| 59 | +| Can act as a cluster VPN only | ✅ | ❌ | |
| 60 | +| Will work with statically linked binaries | ✅ | ❌ | |
| 61 | +| Runs natively on windows | ✅ | ❌ | |
| 62 | +| Can mirror traffic to and from pod's localhost | ✅ | ❌ | |
| 63 | +| Remotely mounted file system available from all applications | ✅ | ❌ | |
| 64 | +| Cluster network available to all applications (including browser) | ✅ | ❌ | |
| 65 | +| Can run the same docker container locally without rebuilding it | ✅ | ❌ | |
| 66 | +| Provides remote mounts as volumes in docker | ✅ | ❌ | |
| 67 | +| Does not require special capabilites such as CAP_SYS_ADMIN in the cluster | ✅ | ❌ | |
| 68 | +| Centralized client configuration using Helm chart | ✅ | ❌ | |
| 69 | +| Installed using a JSON-schema validated Helm chart | ✅ | ❌ | |
| 70 | +| Client need no special RBAC permissions | ✅ | ❌ | |
| 71 | + |
| 72 | +[^1]: Telepresence will not require root access on the workstation when running in docker mode. |
| 73 | + |
| 74 | +[^2]: The remote service will only restart when a traffic-agent sidecar is installed. Pod disruption budgets or pre-installed agents can be used to avoid interruptions. |
| 75 | + |
| 76 | +[^3]: A traffic-agent is only necessary when engaging with a pod. It is unnecessary when using Telepresence as a VPN. |
0 commit comments