Fedora 36 network communication between two pods via DNS

[jezkerwin]

Describe the bug

I guess this is more of a question rather than a bug

• Running Fedora 36 all up to date as of 04/09/22
• Running lastest podman-compose devel install
• Started two applications with podman-compose, can access them via browser.
• Running as rootless containers.

The question is, how can one app in a pod communicate to the other app in another pod. One of the apps I'd like to connect to the other one via it's API. It looks like that I can ping the host via IP address but can it be done with DNS.

podman-compose version
podman-compose version: 1.0.4
['podman', '--version', '']
using podman version: 4.2.0
podman-compose version 1.0.4
podman --version 
podman version 4.2.0
exit code: 0

host:
  arch: amd64
  buildahVersion: 1.27.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 94.45
    systemPercent: 4.76
    userPercent: 0.79
  cpus: 4
  distribution:
    distribution: fedora
    variant: workstation
    version: "36"
  eventLogger: journald
  hostname: fedora
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.19.6-200.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 5836419072
  memTotal: 8294785024
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.5-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 8294232064
  swapTotal: 8294232064
  uptime: 0h 3m 42.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/jez/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 0
    stopped: 2
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/jez/.local/share/containers/storage
  graphRootAllocated: 63349719040
  graphRootUsed: 5867261952
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 18
  runRoot: /run/user/1000/containers
  volumePath: /home/jez/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0
  Built: 1660228937
  BuiltTime: Fri Aug 12 00:42:17 2022
  GitCommit: ""
  GoVersion: go1.18.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.2.0

[munterfi]

Encountered a similar issue on RHEL 8.6 with podman-compose and netavark as network backend. Setting CNI as the network backend and resetting podman worked for rootless mode, see https://github.com/containers/podman-compose/issues/500#issuecomment-1238641494

[jezkerwin]

Thanks for the suggestion @munterfi, I'll give that a go.

[jayache80]

Thank you, @munterfi! I too had to revert to CNI backend before container-to-container networking within a pod worked as expected, per your helpful instructions. If I'm not mistaken, from what I've read about netavark, the name resolution should work the same as before, so this seems to be a bug in podman?

[SecT0uch]

Same issue here (Alpine Edge)