Skip to content
This repository has been archived by the owner on May 13, 2024. It is now read-only.

[Question] About run pipy on the same pod of ingress controller #241

Open
liangyuanpeng opened this issue Mar 5, 2023 · 1 comment
Open
Labels
area/documentation Improvements or additions to documentation question Further information is requested

Comments

@liangyuanpeng
Copy link

liangyuanpeng commented Mar 5, 2023

Please describe what should be documented

Is it mean one pipy ingress controller only working for one pipy service?

And what's the motivation for this design? Why not two pod or tow containers of one pod for this?

https://github.com/flomesh-io/fsm/blob/f5500f07b889a9f8168baa42ade08535f676ef97/cmd/ingress-pipy/main.go#L188-L195

Please suggest where in the repo the document should be located

Some design at README for ingress controller and pipy.

@liangyuanpeng liangyuanpeng added the area/documentation Improvements or additions to documentation label Mar 5, 2023
@reaver-flomesh
Copy link
Collaborator

PIPY was single thread, we need to leverage OS capabilities to run multiple PIPY instances with port reuse and let OS to distribute requests among those instances. Thus when it configures more than ONE core CPU resource for the ingress POD, more PIPY instances are started according to the CPU limits to gain better performance and throughput.

As of PIPY 0.90.0, it supports multi-threads natively, so it runs ONE pipy instance with multiple threads --threads=%d. Two ingress pods doesn't resolve the problem if more cores are configured. If running two containers in one pod, it cannot listen on same port, making it more complicated for the PIPY scripts and config JSON.

@reaver-flomesh reaver-flomesh added the question Further information is requested label Mar 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/documentation Improvements or additions to documentation question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants