Infra containers receive IP addresses implicitly from unused network

[abalage]

/kind bug

Description

The package cni I use installs a bridge network by default into location /etc/cni/net.d/87-podman-bridge.conflist.
Although I do not use the network called podman it provides explicitly, IP addresses are assigned from that network to infra containers when I attach containers to other user defined networks.

I found this issue during #4907 All details which should relevant here can be found in the referenced issue.

I am not sure whether is this a problem with podman or cni.

linux-thwt:/etc/cni/net.d # cat 87-podman-bridge.conflist 
{
    "cniVersion": "0.4.0",
    "name": "podman",
    "plugins": [
        {
            "type": "bridge",
            "bridge": "cni-podman0",
            "isGateway": true,
            "ipMasq": true,
            "ipam": {
                "type": "host-local",
                "routes": [
                    {
                        "dst": "0.0.0.0/0"
                    }
                ],
                "ranges": [
                    [
                        {
                            "subnet": "10.88.0.0/16",
                            "gateway": "10.88.0.1"
                        }
                    ]
                ]
            }
        },
        {
            "type": "portmap",
            "capabilities": {
                "portMappings": true
            }
        },
        {
            "type": "firewall",
            "backend": "firewalld"
        }
    ]
}

Steps to reproduce the issue:

1. Create pods and attach containers to user defined networks.

2. Check the persistent storage of assigned IP addresses of this network in /var/lib/cni/networks/podman/

Describe the results you received:
Again this output was made from the same running environment I provided in #4907

# podman ps -ap
CONTAINER ID  IMAGE                                  COMMAND     CREATED         STATUS             PORTS                       NAMES               POD           POD NAME
ccdd5ee35526  docker.io/library/ubuntu:18.04         sleep 6000  38 minutes ago  Up 38 minutes ago                              kibana              20a630483350  elk
7e98c291d3ae  docker.io/library/ubuntu:18.04         sleep 6000  38 minutes ago  Up 38 minutes ago                              elasticsearch       20a630483350  elk
37a328b57287  registry.opensuse.org/kubic/pause:3.1              38 minutes ago  Up 38 minutes ago  172.23.0.1:5601->5601/tcp   20a630483350-infra  20a630483350  elk
11988b1b525e  docker.io/library/ubuntu:18.04         sleep 6000  38 minutes ago  Up 38 minutes ago                              proxy               3bc3a249dce3  reverse_proxy
fc8743089726  registry.opensuse.org/kubic/pause:3.1              38 minutes ago  Up 38 minutes ago  192.168.122.253:80->80/tcp  3bc3a249dce3-infra  3bc3a249dce3  reverse_proxy
# podman inspect -f "{{.NetworkSettings.IPAddress}}" 20a630483350-infra
10.88.0.100
 # podman inspect -f "{{.NetworkSettings.IPAddress}}" 3bc3a249dce3-infra
10.88.0.99
#

Describe the results you expected:
I do not expect IPs to be released from a network pool I do not explicitly use.
In case the infra images do need an IP then why don't they got it from the same network a container in that pod was attached to?
Or in case there are multiple networks, how can I specify which network it must connect to?

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

podman version 1.7.0

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.2
  podman version: 1.7.0
host:
  BuildahVersion: 1.12.0
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.9-lp151.19.1.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.9, commit: unknown'
  Distribution:
    distribution: '"opensuse-leap"'
    version: "15.1"
  MemFree: 7711289344
  MemTotal: 8357810176
  OCIRuntime:
    name: runc
    package: runc-1.0.0~rc6-lp151.1.2.x86_64
    path: /usr/sbin/runc
    version: |-
      runc version 1.0.0-rc6
      spec: 1.0.1-dev
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 2
  eventlogger: file
  hostname: linux-thwt
  kernel: 4.12.14-lp151.28.36-default
  os: linux
  rootless: false
  uptime: 2h 5m 1.33s (Approximately 0.08 days)
registries:
  search:
  - docker.io
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 5
  GraphDriverName: overlay
  GraphOptions: {}
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 9
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

cni-0.7.1-lp151.10.1.x86_64
podman-1.7.0-lp151.2.1.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
Test VM of OpenSUSE 15.1 x86_64 in KVM. The podman and cni packages are from devel:cubic repository.

[rhatdan]

@mheon PTAL

[mheon]

"name": "podman",

Eeek. Do you still have the stock 87-podman.conflist file installed as well? These names are supposed to be unique, and that file also uses the same name. I don't think we can expect sane things when they're not.

[abalage]

I don't. By default there are only two files:

1. 87-podman-bridge.conflist
2. 99-loopback.conf.sample

[mheon]

This does not sound like a bug, then. Pods presently do not support being attached to user-specified networks, and if this was supported, it would have to be done at pod creation time; attaching containers that specify custom networks should not be allowed. Your pods have joined the default network, and are receiving IP addresses from it; this sounds correct. There are separate issues for the ability to have pods join a non-default CNI network.

[abalage]

What is the purpose of attaching a pod to a network from podman's perspective?
I mean, like you said you cannot do that upon pod creation, but you can attach a container of a pod to any networks. My containers have IPs I do not need.
If it does have a purpose I am fine with it but would like to know why. :)

Sorry, I may not get everything right as I am kinda new to the concept of pods.

[mheon]

Containers in a pod all share the same network namespace - they use the same network stack and IP. Containers may allow you to specify things like CNI network if they are doing this, but that is a bug - it will be ignored, and the container will join the pod network, which is already configured.

[abalage]

Thanks for the clarification. Then it sound more reasonable to define network on pod level than on container level like the way it works now.
I am looking forward to get it supported. I am following #4718.
This case can be closed I think.