[Question] Support proxy-like behavior for microservice apps

[ghost]

Given the following Helm chart for the OSS e-commerce application Reaction Commerce:

https://github.com/slingshotlabs/reaction-oss-helm-chart

Installing the Chart eventually gives me the following services:

NAME                                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
kubernetes                             ClusterIP   10.43.0.1       <none>        443/TCP                      42m
reactioncommerce-mongodb-headless      ClusterIP   None            <none>        27017/TCP                    35m
reactioncommerce-postgresql-headless   ClusterIP   None            <none>        5432/TCP                     35m
reactioncommerce-identity              ClusterIP   10.43.221.178   <none>        4100/TCP                     35m
reactioncommerce-admin                 ClusterIP   10.43.255.208   <none>        4080/TCP                     35m
reactioncommerce-web                   ClusterIP   10.43.45.59     <none>        4000/TCP                     35m
reactioncommerce-postgresql            ClusterIP   10.43.191.95    <none>        5432/TCP                     35m
reactioncommerce-api                   ClusterIP   10.43.36.244    <none>        3000/TCP                     35m
reactioncommerce-mongodb               ClusterIP   10.43.4.224     <none>        27017/TCP                    35m
reactioncommerce-hydra                 ClusterIP   10.43.214.100   <none>        4444/TCP,4445/TCP,5555/TCP   35m

When I run sudo -E kubefwd svc -n default -l "app=reactioncommerce" I see:

INFO[11:56:33]  _          _           __             _     
INFO[11:56:33] | | ___   _| |__   ___ / _|_      ____| |    
INFO[11:56:33] | |/ / | | | '_ \ / _ \ |_\ \ /\ / / _  |    
INFO[11:56:33] |   <| |_| | |_) |  __/  _|\ V  V / (_| |    
INFO[11:56:33] |_|\_\\__,_|_.__/ \___|_|   \_/\_/ \__,_|    
INFO[11:56:33]                                              
INFO[11:56:33] Version 1.17.3                               
INFO[11:56:33] https://github.com/txn2/kubefwd              
INFO[11:56:33]                                              
INFO[11:56:33] Press [Ctrl-C] to stop forwarding.           
INFO[11:56:33] 'cat /etc/hosts' to see all host entries.    
INFO[11:56:33] Loaded hosts file /etc/hosts                 
INFO[11:56:33] HostFile management: Original hosts backup already exists at /Users/jos/hosts.original 
INFO[11:56:33] Successfully connected context: k3d-k3s-demandcluster 
INFO[11:56:33] Port-Forward: 127.1.27.1 reactioncommerce-admin:4080 to pod reactioncommerce-admin-645878f657-jz2v9:4080 
INFO[11:56:33] Port-Forward: 127.1.27.2 reactioncommerce-hydra:4444 to pod reactioncommerce-hydra-7fb869c745-9xgkv:4444 
INFO[11:56:33] Port-Forward: 127.1.27.2 reactioncommerce-hydra:4445 to pod reactioncommerce-hydra-7fb869c745-9xgkv:4445 
INFO[11:56:33] Port-Forward: 127.1.27.2 reactioncommerce-hydra:5555 to pod reactioncommerce-hydra-7fb869c745-9xgkv:5555 
INFO[11:56:33] Port-Forward: 127.1.27.3 reactioncommerce-api:3000 to pod reactioncommerce-api-7688b68f95-9kvzn:3000 
INFO[11:56:33] Port-Forward: 127.1.27.4 reactioncommerce-identity:4100 to pod reactioncommerce-identity-66dc8778f4-vnddz:4100 
INFO[11:56:33] Port-Forward: 127.1.27.5 reactioncommerce-web:4000 to pod reactioncommerce-web-788c9dbd4-sv5jg:4000 

Accessing the admin or website front-end causes issues because all user-facing services (e.g. identity, api) expect to be running on port 80 on their own subdomains, i.e. wss://api.reaction.test/graphql for the API.

Which leads me to my questions:

• Is is possible to use kubefwd to handle web socket connections (with or without TLS)
• What's the suggested way to go about mapping each of the public-facing services to a specific port (i.e. port 80)?

Thanks in advance for your help.

[ghost]

#121 may be related to this question/request. desired functionality is something like kubefwd + ergo proxy.

[cjimti]

I think @balibebas is correct that you might need to use some kind of reverse proxy.

kubefwd forwards Pods backing a service, if the service is mapping on port 80 then it will be forwarded as 80. But I assume you would like to replicate Ingress, which is typically a reverse proxy like nginx. You can run nginx on your local workstation and point it to the hostnames/ports kubefwd is forwarding, just like you do in Kubernetes.