Install linkerd2-proxy as a standalone binary on a virtual machine instance #9849
-
Hello LinerD people. Do you know if it's possible ? Because I've been going trough you documentation and you don't have any section talking about that. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
@isaac88 it is in theory possible for the proxy to be run as a standalone process; there is nothing Kubernetes specific in it that would stop it from working. Most of the control plane, however, runs on Kubernetes. The proxy depends on the control plane for a lot of things, including but not limited to: identity bootstrapping (receiving a leaf certificate signed by a common issuer to all other proxies), service and policy discovery (what endpoints do we have for the target, any routes, timeouts, any authorization policies on the inbound side etc.). The proxy also makes use of ServiceAccount tokens for its identity. The deployment of the proxy is tied to having a working ServiceAccount token available in the pod that is then verified by the identity controller; even if the token is the default token in that namespace, it still needs one. If you were to run the proxy as a standalone you'd need to consider a bunch of the details I covered above. The first step would be to write your own control plane that implements the proxy API https://github.com/linkerd/linkerd2-proxy-api. Like I said, while theoretically possible, it's not a trivial job. |
Beta Was this translation helpful? Give feedback.
-
Hello @mateiidavid I'm right now analysing LinkerD as an option to implement it as a mesh solution but since you don't have that feature implemented yet, it's a problem for us. In our architecture we have an hybrid workloads where we have EC2 instances application and Kubernetes application services and we need to mesh them all. I saw that it's planned since more than 2 years ago reading that blog article: https://linkerd.io/2020/09/02/the-road-ahead-for-linkerd2-proxy/ regarding Off-cluster support, I hope that some day you implemented that and then LinkerD could be our production ready service mesh solution. Thanks again. |
Beta Was this translation helpful? Give feedback.
-
I second that, although our use-case is slightly different. We would like to use a service mesh in a LAN scenario where many embedded Linux satellites are connected to a bunch of servers that run services in k8s. The satellites don't have enough resources to run as a full k8s edge nodes, but we would still like to sail on an existing service mesh that is also used inside the k8s cluster. I'm surprised this use-case does not seem to be considered by the major service mesh implementations I have checked. Worse yet, most of them are based on Envoy which is a monstrous piece of dependency that's also incredibly hard to cross-compile thanks to its esoteric build system. Linkerd would be a nice fit indeed if it would fully support our use-case. Implementing something on top to fill a gap would definitely be an option, but I would like to understand the building blocks better in order to end up with something that is eventually useful beyond the scope of our own case. Any further hints on what to read up on would be appreciated. |
Beta Was this translation helpful? Give feedback.
@isaac88 it is in theory possible for the proxy to be run as a standalone process; there is nothing Kubernetes specific in it that would stop it from working. Most of the control plane, however, runs on Kubernetes. The proxy depends on the control plane for a lot of things, including but not limited to: identity bootstrapping (receiving a leaf certificate signed by a common issuer to all other proxies), service and policy discovery (what endpoints do we have for the target, any routes, timeouts, any authorization policies on the inbound side etc.).
The proxy also makes use of ServiceAccount tokens for its identity. The deployment of the proxy is tied to having a working ServiceAccount tok…