Podman: Bug: Pods in Networks other than default cannot connect to exposed ports

Created on 17 Nov 2020  路  9Comments  路  Source: containers/podman

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

containers in pods, connected to other network than "default/podman" are not able to connect to localhost.

Steps to reproduce the issue:

  1. podman network create web
  2. podman pod create --network web --name web
  3. podman container run -dt --name web01 --network web --pod web httpd
  4. podman container run --rm -it --name client01 --pod web --network web alpine wget localhost

Describe the results you received:

The other container not reachable, even if the are in the same pod.

Connecting to localhost ([::1]:80) wget: can't connect to remote host: Connection refused

Describe the results you expected:

The containers in the same pod are exposed the same way as in the default network. The below example is the same commands as above, but without the specific network.

Connecting to localhost ([::1]:80) saving to 'index.html' index.html 100% |**********************************************************************************************************************************************************************************************| 45 0:00:00 ETA 'index.html' saved

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

Output of podman version:

podman version 2.1.1

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.21-3.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.21, commit: 0f53fb68333bdead5fe4dc5175703e22cf9882ab'
  cpus: 8
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: journald
  hostname: nb01.while-true-do.io
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.9.8-200.fc33.x86_64
  linkmode: dynamic
  memFree: 11252150272
  memTotal: 16494235648
  ociRuntime:
    name: crun
    package: crun-0.15.1-1.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.15.1
      commit: eb0145e5ad4d8207e84a327248af76663d4e50dd
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 4294963200
  swapTotal: 4294963200
  uptime: 2h 34m 14.95s (Approximately 0.08 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 4
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 4
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 2.0.0
  Built: 1602087680
  BuiltTime: Wed Oct  7 18:21:20 2020
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 2.1.1

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

podman-2.1.1-12.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

physical machine

kinbug

Most helpful comment

I opened #8367 to improve the docs.

All 9 comments

If you specify --network on the run command you overwrite the pod net namespace.
You should use podman container run -dt --name web01 --pod web httpd

Thanks a lot. This is working perfectly fine.

I would suggest to make this idiot proof as a feature request, if this is ok for you :+1:

/close

@zhangguanzhang: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

I disagree with closing it, as Daniel wrote, it should be clearer, at least in the man pages, that setting the network overwrites the pod's namespace.

I would suggest to make this idiot proof as a feature request, if this is ok for you

Well the problem is that this a legitimate use case. I don't know how we can separate between someone who wants this and someone who did this by accident.

Maybe need to throw an error directly when creating it to prevent the pod from being created?

if this is a legitimate use case to have networks attached to pods and containers in this pod, than I am ok with closing it. Otherwise a documentation hint for podman-create --network would be ok for me.

I opened #8367 to improve the docs.

Was this page helpful?
0 / 5 - 0 ratings