Add integration test for cgroups v2

[nigurr]

Steps to reproduce the issue:

1. Start minikube

minikube start -p actions-dev
        --driver=docker
        --disk-size=$kubeDisk
        --cpus=$kubeCpus
        --memory=$kubeMem
        --mount=true
        --kubernetes-version=v1.20.5
        --feature-gates="StartupProbe=true"
        --extra-config="apiserver.service-node-port-range=1-65535"

2. Execute

minikube -p actions-dev docker-env

Full output of failed command:

Starting minikube with vm-driver docker, 12 cpus, 31.3949165344238 GB memory, Kubernetes v1.20.5
😄  [actions-dev] minikube v1.18.1 on Debian bullseye/sid
✨  Using the docker driver based on user configuration
❗  Your cgroup does not allow setting memory.
    ▪ More information: https://docs.doInfo.com/engine/install/linux-postinstall/#your-kernel-does-not-support-cgroup-swap-limit-capabilities
👍  Starting control plane node actions-dev in cluster actions-dev
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=12, Memory=32148MB) ...
🐳  Preparing Kubernetes v1.20.5 on Docker 20.10.3 ...
    ▪ apiserver.service-node-port-range=1-65535
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v4
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "actions-dev" cluster and "default" namespace by default
Configuring promiscuous mode on Minikube VM
Switched to context "actions-dev".
Deploying ingress-nginx to the cluster
namespace/ingress-nginx created
serviceaccount/nginx-ingress-serviceaccount created
role.rbac.authorization.k8s.io/nginx-ingress-role created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
configmap/devrouter-plugin created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
service/ingress-nginx created
deployment.apps/nginx-ingress-controller created
❌  Exiting due to GUEST_STATUS: state: unknown state "actions-dev": docker container inspect actions-dev --format=: exit status 1
stdout:


stderr:
Error: No such container: actions-dev


😿  If the above advice does not help, please let us know: 
👉  https://github.com/kubernetes/minikube/issues/new/choose
configmap/coredns replaced

❌  Exiting due to GUEST_STATUS: state: unknown state "actions-dev": docker container inspect actions-dev --format=: exit status 1
stdout:


stderr:
Error: No such container: actions-dev


😿  If the above advice does not help, please let us know: 
👉  https://github.com/kubernetes/minikube/issues/new/choose

Configuring a new mssql (test) instance
secret/mssql-sa-password created
service/mssql created
deployment.apps/mssql created
❌  Exiting due to GUEST_STATUS: state: unknown state "actions-dev": docker container inspect actions-dev --format=: exit status 1
stdout:


stderr:
Error: No such container: actions-dev


😿  If the above advice does not help, please let us know: 
👉  https://github.com/kubernetes/minikube/issues/new/choose

Optional: Full output of minikube logs command:

❌ Exiting due to GUEST_STATUS: state: unknown state "actions-dev": docker container inspect actions-dev --format=: exit status 1 stdout:

stderr:
Error: No such container: actions-dev

Additional docker info:

docker system info Client: Context: default Debug Mode: false Plugins: app: Docker App (Docker Inc., v0.9.1-beta3) buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)

Server:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 1
Server Version: 20.10.5
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
cgroupns
Kernel Version: 5.11.11-051111-generic
Operating System: Pop!_OS 20.10
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 62.79GiB
Name: pop-os
ID: BWXO:EFA7:7NIY:R7JN:FCTW:YSER:DCWQ:E7W4:NXXV:FQF2:KBOH:HHRQ
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

WARNING: Support for cgroup v2 is experimental

[medyagh]

@nigurr I noticed your cgroup version is v2, we don't have an integration test for Cgroups v2 yet ! is it possible to try with cgroup v1 ?

[medyagh]

/triage needs-information
/kind support

[nigurr]

@medyagh at this point, its hard for me to migrate to cgroups v1 for my requirements. AFAIK, with Docker 20.x and cgroups v2 is supported, we should support this? and it would be great to know which component is blocking to support cgroups v2

[medyagh]

@nigurr thats fair, I will put this on our backlog and would happily accept/review any contribution that would add cgroup v2 to minikube

@nigurr I am curious do you have same issue with a VM-Driver ? like Virtualbox or KVM ? since they use a different cgroup wrapper ?

[nigurr]

with KVM it works brilliantly. Spinning up VM is always going to be resource heavy and would be great to leverage native Docker to leverage the Kube

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sharifelgamal]

We're tracking adding test infra for cgroupsv2 in #12456

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[sharifelgamal]

We'll use #12456 as the cgroupsv2 issues. Closing this as duplicate.