You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/compare/mirrord.md
+3-5
Original file line number
Diff line number
Diff line change
@@ -16,13 +16,11 @@ The client can be either completely contained in Docker or run directly on the w
16
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
17
18
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.
19
+
device and remotely mounted filesystems, mirrord will link the client application with a `mirrord-layer` shared library. This library will inject code that intercepts 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
20
21
-
### Limitations
21
+
### Limitations with Code Injection
22
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:
23
+
Telepresence 1.x used the [code injection approach](https://www.getambassador.io/blog/code-injection-on-linux-and-macos), but desided to abandon it due to several limitations:
26
24
27
25
1. It will only work on Linux and macOS platforms. There's no native support on Windows.
28
26
2. It will only work with dynamically linked executables.
## <divstyle="display:flex;"><imgsrc="images/bugfix.png"alt="bugfix"style="width:30px;height:fit-content;"/><divstyle="display:flex;margin-left:7px;">Only restore inactive traffic-agent after a replace.</div></div>
6
+
<divstyle="margin-left: 15px">
7
+
8
+
A regression in the 2.20.0 release would cause the traffic-agent to be replaced with a dormant version that
9
+
didn't touch any ports when an intercept ended. This terminated other ongoing intercepts on the same pod.
10
+
This is now changed so that the traffic-agent remains unaffected for this use-case.
11
+
</div>
12
+
4
13
## Version 2.22.0 <spanstyle="font-size: 16px;">(March 14)</span>
0 commit comments