Change:
POD is OOM. k8s v1.19.4+docker is OK. but v1.21+cri-o+buildah does not work properly. Why the limits are not effective.Not the container limit memory, It's physical memory centos7 kernel use limits memory use -XX:+UseContainerSupport Cannot read memory.limitinbytes k8s version cri-o version buildah version oracleJdk or openjdk have same problem It is normal to use xms and Xmx
/sig node
Supplement v19+docker v21+cri-o+buildah
/assign taking a look, thanks for opening the issue
seems relevant, have you checked your kernel supports the memory cgroup (I know docker does work, but let's sanity check first) I checked on my machine (fedora 34) and successfully can see usageinbytes in a container on our latest 1.22 branch. also, attaching the crio logs will likely help me debug
also curious about the runc version
cri-o logs runc Looks like a problem with cgroup v1
hm the memory cgroup seems to be enabled. what is the image you're using?
centos7.9.2009
/triage needs-information
what cgroup manager are you using?
kubeadm kubectl config crio ps aux|grep kubelet
I seem to have found this bug Delete the following two items to return to normal. deployment
that is unexpected... Great find!
Does the problem manifest if either are different? (hostNetwork: false, but dnsPolicy ClusterFirstWithHostNet)
hostNetwork: true hostNetwork: false delete hostNetwork and dnsPolicy
Rocky 8.4, kernel-5.4, kubernetes v1.21.4 has the same problem
ah! I found the issue
thanks for your patience
Is crio 1.21.3 fixed? This problem still occurs after the upgrade. Branch v1.21.3 did not see the commit
no the initial PR hasn't merged yet, I will try to revive it
sorry this fell through the cracks, I'll try to get this through ASAP
will get it in 1.22.1. is that sufficient or would you like it backported to 1.21?
Thank you Both are OK, I currently use java -xmx instead.I will update in the next version. Preferably v1.21, v1.22 version I will upgrade later.
I've opened as well :)
/remove-triage needs-information /triage accepted /close as this is being tracked as a CRI-O bug
Closing this issue. <detailsIn response to : /remove-triage needs-information /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
If you have questions or want to start contributing please reach out.  We don't bite! <del> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers).  We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </del> <ins> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers). This client may be overloaded from time to time. If this happens you can use any [IRC client out there](http://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients) to talk to us. We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </ins> If you are a company and are looking for a more formal engagement with Google around Kubernetes and containers at Google as a whole, please fill out [this form](https://docs.google.com/a/google.com/forms/d/1_RfwC8LZU4CKe4vKq32x5xpEJI5QZ-j0ShGmZVv9cm4/viewform) and we'll be in touch.