hostNetwork support

[yangchuansheng]

Description:

I'd like to ask about hostNetwork support in Custom Resource EnvoyProxy

[optional Relevant Links:]

https://gateway.envoyproxy.io/v0.5.0/api/config_types.html#kubernetesdeploymentspec

[arkodg]

@yangchuansheng can you share your use case / why you need this feature ?

[arkodg]

copying ChatGPT's answer

In Kubernetes, the hostNetwork is a Pod-level setting that allows you to share the network namespace with the host machine on which the Pod is scheduled. When you configure a Pod to use the hostNetwork, it essentially means that the Pod directly uses the host machine's network stack, and it doesn't have its own isolated network namespace. This can be useful in certain scenarios, but it comes with some trade-offs and should be used with caution.

Here are some reasons why users might configure hostNetwork in Kubernetes:

Performance: By using the host's network stack, you can potentially achieve better network performance for applications that require low-latency communication. This is particularly relevant for applications that demand high network throughput.
Access to Host Networking Resources: Some applications might need direct access to network resources that are only available on the host machine, such as specific network devices or services. Configuring the Pod to use the host network allows access to these resources.
Port Conflicts: If your Pod needs to bind to a port that's already in use on the host, you might configure hostNetwork to avoid port conflicts. This is because, by default, Pods have their own IP address and network namespace, which can lead to port collisions if the host is already using the desired port.
However, there are several important considerations and drawbacks to using hostNetwork:

Isolation: Using hostNetwork sacrifices network isolation, which is one of the key benefits of containerization and Kubernetes. It can lead to security and stability issues, as Pods can potentially interfere with the host's network configuration.
Network Conflicts: If multiple Pods are configured to use the host's network, there can still be conflicts, as they might contend for network resources or ports. Proper coordination and planning are necessary in such scenarios.
Compatibility: Not all Kubernetes clusters or cloud environments support the use of hostNetwork, so it may limit the portability of your workloads.
Security: Running containers in the host's network namespace can pose security risks, as containers have a level of isolation by design to prevent them from directly impacting the host system. Using hostNetwork reduces this isolation.
In summary, configuring hostNetwork in Kubernetes can be a useful tool in specific cases where performance and direct access to host network resources are crucial. However, it should be used judiciously, considering the trade-offs in terms of network isolation, compatibility, and security. It's generally recommended to explore alternative solutions, such as using hostPort, NodePort services, or network policies, before resorting to hostNetwork.

The only issue I see with introducing hostNetwork is, EG cannot guarantee the listener port will be available on the host causing erratic issues in the field that will be hard to debug

[arkodg]

ptal @envoyproxy/gateway-maintainers

[Xunzhuo]

I think we should hold to merge the PR, until figure out the use case.

[zzjin]

First, this is useful for bare-metal envs with or without MetaLB support.
Then, I think we should give the choice to the user, to decide whether to use hostnetwork, with just some documentation and discouragements, but not simply ban it at the project code level.

[zirain]

First of all, EG cannot provide every single feature users request.
If the API was promoted, that means EG need support and maitain.

[docapotamus]

Sorry if this isn't directly related to this issue but I have a use case for hostPort which to me is related to hostNetwork.

We use Cilium on top of an EKS cluster with an Network Load Balancer in front. We currently use ingress-nginx and we have to set the HostPort there so that the NLB can communicate in to the Cilium network.

Not sure if there if there is another way to acheive this, if there is I haven't found it or it's not obvious to me

Update: Setting externalTrafficPolicy solved the issue for us.

[fanux]

With hostNetwork, users can expose ports 80 and 443 with almost no other dependencies. These are the ports that the gateway must expose. This is not a use case issue, but a rigid demand. In many cases, users do not want to use the loadbalancer mode, such as not wanting to introduce more dependencies, such as on their own servers, or to quickly use the gateway function. I also do not recommend other containers to use hostNetwork, but the gateway is an exception. Without this feature, more than 50% of users would be lost.