Podman问题：已暴露端口的容器无法访问

我在CentOS 8系统上使用Podman（v4.5.0-dev）启动了容器并暴露8080端口，修改网络配置以解析Pod IP前，localhost:8080可以正常访问。但现在端口显示处于监听状态，却无法访问，相关命令输出如下：

端口状态与访问测试 #

[root@centos-1 pods]# netstat -tulpn |grep 8080
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      183838/conmon

[root@centos-1 pods]# curl localhost:8080 --noproxy "*"
curl: (7) Failed to connect to localhost port 8080: No route to host

[root@centos-1 pods]# podman port xptssrv-xptssrv-container
8080/tcp -> 0.0.0.0:8080

Podman网络配置 #

[root@centos-1 pods]# podman network inspect podman-default-kube-network
[
     {
          "name": "podman-default-kube-network",
          "id": "20f116e556e92b00b8e063ac464ca15eb941e88524dd2b1b1ae4f93f8878b8c6",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2023-03-03T11:56:46.112678781+01:00",
          "subnets": [
               {
                    "subnet": "10.89.1.0/24",
                    "gateway": "10.89.1.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": true,
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

Podman系统信息 #

[root@centos-1 pods]# podman info
host:
  arch: amd64
  buildahVersion: 1.30.0-dev
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  - rdma
  cgroupManager: systemd
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.5-1.module_el8.8.0+1254+78119b6e.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: 08f01a37791aa5c00f6e2e69de6bde88a23dc93d'
  cpuUtilization:
    idlePercent: 98.77
    systemPercent: 0.75
    userPercent: 0.48
  cpus: 3
  databaseBackend: boltdb
  distribution:
    distribution: '"centos"'
    version: "8"
  eventLogger: journald
  hostname: centos-1
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 4.18.0-448.el8.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 116764672
  memTotal: 2923708416
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-0.0-20230227184214.a09ab72.el8.x86_64
    path: /usr/bin/crun
    version: |-
      crun version UNKNOWN
      commit: abd499d2c0d335484a0217d984a9a4672d6be243
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/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
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-10.el8.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 123838464
  swapTotal: 2206199808
  uptime: 26h 20m 14.00s (Approximately 1.08 days)
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: /etc/containers/storage.conf
  containerStore:
    number: 5
    paused: 0
    running: 5
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 50383060992
  graphRootUsed: 25056534528
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 8
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.5.0-dev
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.18.9
  Os: linux
  OsArch: linux/amd64
  Version: 4.5.0-dev

排查与解决步骤 #

1. 检查防火墙规则 #

修改网络配置后，防火墙可能阻断了端口转发，先开放8080端口：

firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload

同时检查podman1接口的防火墙规则：

firewall-cmd --list-all-zones | grep podman1

如果该接口被限制在内部区域，需要调整规则允许外部访问。

2. 验证iptables转发规则 #

Podman使用netavark管理网络，检查转发链是否正常：

iptables -L FORWARD -n -v | grep 8080
iptables -L DOCKER-USER -n -v

确保没有规则阻断主机到容器的流量，若有异常可以尝试重置iptables规则（注意备份现有规则）：

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

3. 测试容器内部服务可用性 #

直接访问容器IP确认服务本身是否正常：

# 获取容器IP
podman inspect xptssrv-xptssrv-container | grep -i ipaddress
# 访问容器内服务
curl <容器IP>:8080

如果能正常访问，说明问题出在端口转发环节；若仍无法访问，需要检查容器内服务是否正常启动。

4. 重置Podman网络配置 #

如果上述步骤无效，尝试重置默认kube网络：

# 删除现有网络
podman network rm podman-default-kube-network
# 重新创建网络
podman network create podman-default-kube-network
# 重启容器
podman restart xptssrv-xptssrv-container

5. 查看netavark日志 #

检查netavark的运行日志，排查端口转发配置问题：

journalctl -u podman.service -g netavark --since "10 minutes ago"

内容的提问来源于stack exchange，提问作者Daniele Navarra