mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #3138] [Feature Request] Add documentation to deploy in K8s, scaling parameters and resource consumption #2517
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#2517
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @isurulucky on GitHub (Oct 19, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3138
Describe the feature request
Hello there,
Since there are not much resources related to using frp in K8s, I went ahead and tried a POC with the usecase of exposing the services privately. I would like to get your feedback and see if we can include this information in the FRP documentation for the benefit of others. Particularly, I think we need:
This is the basic sample architecture I came up with:
Here, the external secret client visitor (or any external client in the general case) should use TLS to communicate with the ingress controller. In addition, the token based authentication can be used between the FRP client and the server. Any internal communication between FRPS and FRPC within the K8s cluster need not use TLS. In addition, the external client is using websocket protocol to communicate with FRPS as the community ingress controller supports websockets out of the box, whereas TCP is not properly supported (TCP with ingress controller requires a port per ingress if am not mistaken).
As next steps we would need to to figure out autoscaling resource (CPU and memory) requests and limits. Any idea on what would be a resource requirements in a general level?
Also, any other additional improvements for the suggested approach are welcome!
Describe alternatives you've considered
No response
Affected area
@fatedier commented on GitHub (Oct 19, 2022):
frpsis not scalable now based on the current architecture. It's not cloud native. You may encounter a lot of problems.@isurulucky commented on GitHub (Oct 19, 2022):
Thanks for very much for the reply. I tried the POC out in a minimal K8s cluster, and it did seem to work. But my idea was to scale this based on need, such as when memory pressure increases etc., using the k8s autoscaling techniques. But if the current frp implementation does not support scaling, that would not work.
Would you be able to explain a bit why it won't scale as of now? And I assume the next version would address these shortcomings?
@fatedier commented on GitHub (Oct 19, 2022):
It's not stateless. All route configurations and frpc's meta infos are stored in memory.
When a request come in, frps will parse it and decide which frpc to forward by route configurations. If one frpc connect to frps A and you send requests to frps B, frps B will not know how to route this request.
@isurulucky commented on GitHub (Oct 19, 2022):
I see, I think I get the idea. If we take the exposing a private service as an example, both secret client and secret client visitor connects to frps separately. Since its a point to point connection, even if another frps comes up, it will not know about the routing configuration.
So the only way to make it work is make sure that there are only one frps running.. as I see, scaling frpc is not an issue as the configurations are read from the frpc.ini file. I assume if we can guarantee that there is one frps running, this setup would work?
@fatedier commented on GitHub (Oct 19, 2022):
Yes.
@isurulucky commented on GitHub (Oct 19, 2022):
Thanks @fatedier. Will close this.
@isurulucky commented on GitHub (Oct 20, 2022):
Re-opening to discuss a point we missed to discuss - for FRPS and FRPC, how do we need to set resources (memory and CPU) in a K8s environment? This is not for scaling but for the initial scheduling of FRPS and FRPC pods.
@fatedier commented on GitHub (Oct 20, 2022):
It depends on your usage scenarios. Small resource is fine for your demo.
@isurulucky commented on GitHub (Oct 21, 2022):
Thanks @fatedier. In a test running for a few hours, noted that all frp pods were consuming around 50MB memory and around couple of millicores of CPU. I think something around this should be a good starting point.