Bug report

Cilium v1.8 release candidates include a native bpf hostport feature to replace CNI portmap chaining (#10359) implemented in #10592. In testing, it seems this feature is a partial implementation of CNI portmap.

When CNI portmap is used in a CNI conflist (with any CNI provider, not just Cilium), Kubernetes Pods that set a hostPort proxy any traffic on that host port to the container.

          ports:
            - name: http
              containerPort: 80
              hostPort: 80

For example, a PodSpec above would allow the web app to be accessed via multiple host IPs - hostPort maps multiple interface addresses (unless a single hostIP is set https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#containerport-v1-core).

curl 127.0.0.1:80  (works)
curl 10.135.173.170:80 (works)
curl publicipv4:80 (works)
curl [someipv6]:80 (depends)

In Cilium v1.8.0-rc3 the hostport feature works as described in docs, but its always picking the node's own internal IP, which doesn't satisfy the use cases CNI portmap had.

curl 127.0.0.1:80  (no)
curl 10.135.173.170:80 (works)
curl publicipv4:80 (no)
curl [someipv6]:80 (no)

cilium service list
...
13   10.135.173.170:80      HostPort       1 => 10.2.0.214:80

So its not a bug per-se, more that the implementation isn't a drop-in for CNI portmap yet, unless the node's internal IP is the only address you are interested in. (imo) Most uses of CNI portmap to support containers with hostPort are using it to listen on any of the available host addresses.

• node with a private IP (kubelet internal IP, tunnels) and public IP (interfacing with LBs)
• health checks may expect the hostPort to be available on 127.0.0.1 or ::1 as well
• node with multiple addresses for other reasons

For myself, I have to fallback to certain pods that could use hostPort to just using full hostNetwork.

General Information

• Cilium version: 1.8.0-rc3
• Kernel version: 5.6.11
• Orchestration system version: Kubernetes v1.18.3