Linux Virtual Interface “missing” pair?

• The Q may be specific to AWS EKS CNI/AWS EC2/AWS VPC Networking
• The Q may be specific to Docker networking

We have an AWS Elastic Kubernetes cluster running with a WorkerNode. On this WorkerNode, we have a Pod running with an IP 10.22.55.231 assigned to it which is a part of the AWS VPC where this WorkerNode is living.

I'm wondering, how a packet will reach this Pod via Linux Network namespaces and interfaces.

So:

1. when I'm issuing a request to an AWS LoadBlancer, it will send a packet to an EC2's TCP port, let's say 30100 on the eth0 interface
2. ipfilter on the EC2 will capture this packet and will send it over iptables tables and chains of the Host
3. it will reach the nat table and PREPOUTING chain, where will be captured by the KUBE-SERVICES chain
4. will reach the KUBE-NODEPORTS chain and will be sent to the KUBE-SEP-xxx chain
5. KUBE-SEP-xxx will send a client's packet to the 10.22.55.231 IP, which is the Secondary private IPv4 address of the AWS EC2

On the WorkerNode/EC2 in its routes 10.22.55.231 will be sent to the enif8b7efe9956 interface:

[root@ip-10-22-50-163 ec2-user]# route -n | grep 10.22.55.231
10.22.55.231    0.0.0.0         255.255.255.255 UH    0      0        0 enif8b7efe9956

Which is the veth interface from the Namespace with ID 6:

12: enif8b7efe9956@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 5a:ba:fe:22:92:aa brd ff:ff:ff:ff:ff:ff link-netnsid 6

From everything I remember and googled, its second part of the enia742601a852@if3 name, if3, specifies its second peer, where traffic is sent when it's coming to the enia742601a852.

But if I'm checking the @if3 interface - it's the eth1:

[root@ip-10-22-50-163 ec2-user]# ip a s eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0a:39:42:17:73:4c brd ff:ff:ff:ff:ff:ff
    inet 10.22.62.78/20 brd 10.22.63.255 scope global eth1

Why so? How this is going to be working? The packet will go again via iptables' nat and PREROUTING? It has to be sent via some Docker interfaces, isn't it?

The link-netnsid 6 is used by our Kubernetes Pod/Docker container, and IP 10.22.55.231 mapped to this Namespace:

[root@ip-10-22-50-163 ec2-user]# nsenter -t 7114 -n ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default 
    link/ether 32:62:fe:9e:7a:b5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.22.55.231/32 scope global eth0
       valid_lft forever preferred_lft forever

Completely lost in here.