Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infra containers receive IP addresses implicitly from unused network #4908

Closed
abalage opened this issue Jan 20, 2020 · 7 comments
Closed

Infra containers receive IP addresses implicitly from unused network #4908

abalage opened this issue Jan 20, 2020 · 7 comments
Assignees
Labels

Comments

@abalage
Copy link

@abalage abalage commented Jan 20, 2020

/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.

@abalage abalage changed the title Infra images got IP addresses implicitly from unused network Infra containers receive IP addresses implicitly from unused network Jan 20, 2020
@rhatdan

This comment has been minimized.

Copy link
Member

@rhatdan rhatdan commented Jan 20, 2020

@mheon PTAL

@mheon

This comment has been minimized.

Copy link
Collaborator

@mheon mheon commented Jan 20, 2020

"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

This comment has been minimized.

Copy link
Author

@abalage abalage commented Jan 20, 2020

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

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

This comment has been minimized.

Copy link
Collaborator

@mheon mheon commented Jan 20, 2020

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

This comment has been minimized.

Copy link
Author

@abalage abalage commented Jan 20, 2020

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

This comment has been minimized.

Copy link
Collaborator

@mheon mheon commented Jan 22, 2020

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

This comment has been minimized.

Copy link
Author

@abalage abalage commented Jan 22, 2020

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.

@mheon mheon closed this Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.