feature: add hostNetwork to the podSpec

[tanujd11]

What type of PR is this?

Feature

What this PR does / why we need it:

added hostNetwork to the podSpec

Which issue(s) this PR fixes:

Fixes #1928

[Xunzhuo]

LGTM

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (176823c) 64.37% compared to head (a3e066e) 64.33%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1944      +/-   ##
==========================================
- Coverage   64.37%   64.33%   -0.04%     
==========================================
  Files         112      112              
  Lines       15877    15879       +2     
==========================================
- Hits        10221    10216       -5     
- Misses       5007     5013       +6     
- Partials      649      650       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tanujd11]

/retest

[zirain]

Before adding this, I want to clearify the use case. The use of HostNetwork is discouraged.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[fanux]

@zirain Although the use of hostnetwork is not encouraged, it is an exception in the scenario of gateways. Firstly, gateways need to expose ports such as 80 and 443, and hostnetwork is very convenient for this. Moreover, a gateway may be shared by many applications, so there will be no port conflicts. Therefore, even in a production environment, it is very convenient to use it in this way. Otherwise, it would be necessary to rely on external load balancing to expose ports 80 and 443, which would greatly increase the complexity for users, especially in situations where there is no external load balancing.

[github-actions]

🚀 Deployed on https://gateway-pr-1944-preview--eg-preview.netlify.app

[Xunzhuo]

Re-activate this issue. @fanux and his team come to me and provided me some contexts on this request, their team tries to put EG into production, but this is a blocker for them.

In their scenarios, I think this is reasonable and this would be also a common request when deploying single EG with mergeGateways enabled in a cluster, which means there will be only one single envoyproxy instance, and will be no listeners conflicts. AND in private cloud clusters, there offen will be no loadbalancer implementations, if the envoyproxy needs to expose http-80/https-443, this cannot be worked easily, which needs some changes to kubernetes.

So I am +1 for it.

[qicz]

LGTM

[arkodg]

Im still not convinced this is a good idea, the project supports multiple ways to setup a gateway in non LoadBalancer mode

• ClusterIP
• NodePort
• External IP (using gateway.spec.addresses)

Setting up hostNetwork is not going to be enough and not going to work out of the box if trying to access the deployment directly, because of the custom service to container port mapping for privileged ports, this is not a bug, but a design decision, since the container port is an internal implementation and all traffic must be routed to the deployment via the service