Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
It seems like some Attributes/Paramaters in a kubernetes deployment.yaml are ignored in podman. I was able to identify
the following behaviour.
Steps to reproduce the issue:
apiVersion: v1
kind: Deployment
metadata:
name: test
labels:
app: test
namespace: test
spec:
restartPolicy: Always
selectors:
matchLabels:
app: test
template:
metadata:
labels:
app: test
spec:
containers:
- name: web01
image: docker.io/library/httpd:2.4
imagePullPolicy: Always
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "250m"
ports:
- name: http
containerPort: 80
[sudo] podman play kube deployment.yml podman (container|pod) (inspect|stats)Describe the results you received:
For step 2, the deployment does not work at all.
In Step 5, you can see that the deployment still uses all of the available memory/cpu and the restartPolicy seems to be ignored.
Also the namespace declaration is not shown in podman pod ls --ns.
Describe the results you expected:
-m when using podman runAdditional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version: 2.0.6
API Version: 1
Go Version: go1.14.6
Built: Tue Sep 1 21:26:51 2020
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.15.1
cgroupVersion: v2
conmon:
package: conmon-2.0.19-1.fc32.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.19, commit: 5dce9767526ed27f177a8fa3f281889ad509fea7'
cpus: 8
distribution:
distribution: fedora
version: "32"
eventLogger: file
hostname: nb01
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.8.9-200.fc32.x86_64
linkmode: dynamic
memFree: 3985612800
memTotal: 16600133632
ociRuntime:
name: crun
package: crun-0.14.1-5.fc32.x86_64
path: /usr/bin/crun
version: |-
crun version 0.14.1
commit: 598ea5e192ca12d4f6378217d3ab1415efeddefa
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
path: /run/user/1000/podman/podman.sock
rootless: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.4-1.fc32.x86_64
version: |-
slirp4netns version 1.1.4
commit: b66ffa8e262507e37fca689822d23430f3357fe8
libslirp: 4.3.1
SLIRP_CONFIG_VERSION_MAX: 2
swapFree: 8371826688
swapTotal: 8371826688
uptime: 40h 52m 8.75s (Approximately 1.67 days)
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- registry.centos.org
- docker.io
store:
configFile: /var/home/dschier/.config/containers/storage.conf
containerStore:
number: 2
paused: 0
running: 1
stopped: 1
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-1.1.2-1.fc32.x86_64
Version: |-
fusermount3 version: 3.9.1
fuse-overlayfs: version 1.1.0
FUSE library version 3.9.1
using FUSE kernel interface version 7.31
graphRoot: /var/home/dschier/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 10
runRoot: /run/user/1000
volumePath: /var/home/dschier/.local/share/containers/storage/volumes
version:
APIVersion: 1
Built: 1598988411
BuiltTime: Tue Sep 1 21:26:51 2020
GitCommit: ""
GoVersion: go1.14.6
OsArch: linux/amd64
Version: 2.0.6
Package info (e.g. output of rpm -q podman or apt list podman):
podman-2.0.6-1.fc32.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.):
Issue occurs on Fedora 32 Silverblue, Fedora 32 Server and Fedora CoreOS.
Interested in opening a PR to fix this?
@zhangguanzhang @ashley-cui @haircommander Anyone else interested in fixing this?
I think I can fix this problem, but I am busy recently. If others are busy, I will fix this problem later.
First error is comming up, that the imagePullPolicy is not ok
This was fixed in cd2b2d9fae0c1dbcf8f4222ba461d5cc8223dd51 and released in podman 2.1.0.
Just to be clear, the imagePullPolicy: Always issue was fixed in that commit, but not the rest of it. Was another fix done recently that fixes the limits issue?
No, reopening.
Also the namespace declaration is not shown in podman pod ls --ns.
I think --ns shows you information about Linux namespaces (as in man 7 namespaces), which are different from Kubernetes namespaces. Does podman support Kubernetes namespaces? If not, what would be required to add them?
We have something similar (Libpod namespaces and the --namespace flag) but they are poorly documented and, honestly, I doubt anyone uses them. They're a little on the limited side right now.
It wouldnt be required. For me it would be totally fine to have some kind of documentation which parameters/arguments/flags are supported if one uses podman play kube (pod.yml|deployment.yml) :)
I'm working on adding support for limits to play kube in xordspar0:play-kube-limits-#7742.
@xordspar0 Any progress?
I guess I forgot to link to the PR I opened: https://github.com/containers/podman/pull/7853
I'm still working on it. I'm currently stuck with some test failures. I haven't figured out why it's happening yet.
Awesome.
https://github.com/containers/podman/pull/7853 was merged, so that should wrap this issue up I think.
As the reporter gave a thumbs up, I'm closing this issue. @xordspar0 TYVM for the PR to fix this!