Increase default disk image allocation ?

[afbjorklund]

Something that we discussed about the Docker VM, which allocates 2 GB RAM + 1 GB swap:

As discussed in #7980 (comment)

Maybe it is time to increase our default memory allocation to 4 GB, at least where available ?

Similarly, we could up the default disk image to 40 GB, since it will only occupy as much as used.

The idea would be to have something like computer games, "recommended" vs "minimum":

https://minikube.sigs.k8s.io/docs/start/

Minimum:
2 CPUs or more
2GB of free memory
20GB of free disk space

Recommended:
4 CPUs or more
4GB of free memory
40GB of free disk space

Currently we follow the recommendations from kubeadm, but it seems to be a bit low ?

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

Before you begin

2 GB or more of RAM per machine (any less will leave little room for your apps)
2 CPUs or more

We already use more memory than this, so it is mostly about the documentation.

🔥 Creating virtualbox VM (CPUs=2, Memory=6000MB, Disk=20000MB) ...

🔥 Creating docker container (CPUs=2, Memory=8000MB) ...

The hard requirement is currently 1000MB, but that requires swap to even "function".

---

Ideally this would be followed up by an analysis of where the memory is actually going...

Like monitor the memory usage over time, like we did previously with the cpu usage ?

[afbjorklund]

We could use vmstat for monitoring, or write our own like we did for iostat ("cstat")

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  2   1536 3625936 9905112 15017912    0    0    20   125    6   16 10  3 87  0  0
 2  0   1536 3063600 9905216 15625908    0    0     9 73857 5365 36577  9  9 73  9  0
25  0   1536 3009120 9905632 15632688    0    0     0  1424 3566 12279  8  3 88  1  0
28  0   1536 2721084 9905684 15635796    0    0     0   171 5222 12392 23  4 72  0  0
20  0   1536 2715396 9906596 15641064    0    0    13  2548 7161 23262 10  6 82  3  0
 5  0   1536 2674888 9906792 15671304    0    0  2936   329 5553 18045  7  5 87  1  0
17  0   1536 2589184 9908292 15678200    0    0    33  2283 6654 19200 11  7 80  1  0
 0  0   1536 2576704 9908520 15679836    0    0     2   387 4598 12778  6  4 89  1  0

We might need something more advanced for KIC, since free will show the host.

e.g. docker stats https://docs.docker.com/engine/reference/commandline/stats/

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
925a4e5ec94e        minikube            52.05%              127.4MiB / 7.812GiB   1.59%               1.94kB / 614B       193kB / 0B          82
925a4e5ec94e        minikube            1.22%               126.9MiB / 7.812GiB   1.59%               3.61kB / 762B       193kB / 0B          82
925a4e5ec94e        minikube            1.22%               126.9MiB / 7.812GiB   1.59%               3.61kB / 762B       193kB / 0B          82
925a4e5ec94e        minikube            25.17%              129.5MiB / 7.812GiB   1.62%               16.9kB / 16.3kB     193kB / 0B          82
925a4e5ec94e        minikube            25.17%              129.5MiB / 7.812GiB   1.62%               16.9kB / 16.3kB     193kB / 0B          82
925a4e5ec94e        minikube            42.83%              132.3MiB / 7.812GiB   1.65%               50.9kB / 48.7kB     193kB / 0B          84
925a4e5ec94e        minikube            42.83%              132.3MiB / 7.812GiB   1.65%               50.9kB / 48.7kB     193kB / 0B          84
925a4e5ec94e        minikube            89.58%              143.7MiB / 7.812GiB   1.80%               83.5kB / 82.3kB     193kB / 0B          90
925a4e5ec94e        minikube            89.58%              143.7MiB / 7.812GiB   1.80%               83.5kB / 82.3kB     193kB / 0B          90
925a4e5ec94e        minikube            102.24%             154.2MiB / 7.812GiB   1.93%               119kB / 106kB       193kB / 0B          102

[afbjorklund]

Somewhat related to #3574

[afbjorklund]

Memory usage of "docker", from start to idle.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[medyagh]

@afbjorklund I believe our new Auto Detect memory already does this for memory. but for disk size we have not done anything.

[medyagh]

I would accept a PR that would try to allocate more disk space for VM if it is available

[medyagh]

if we need disk space issue, lets create another one

[afbjorklund]

if we need disk space issue, lets create another one

We talked about it in #8077, currently we leave 15G

It really depends on which applications you want to run...

The end goal is similar to what Vagrant is trying to do:

When creating a base box, make sure the user will have enough disk space to do interesting things, without being annoying. For example, in VirtualBox, you should create a dynamically resizing drive with a large maximum size. This causes the actual footprint of the drive to be small initially, but to dynamically grow towards the max size as disk space is needed, providing the most flexibility for the end user.

https://www.vagrantup.com/docs/boxes/base

---

User are free to choose whatever, using the disk-size config.

I will probably use 32G as a compromise, size of an SD card
Like a modest 63% size increase, from 20000M to 32768M ?

It would be more interesting to work on the monitoring: #3574