Unlike perm gen, it is typically not necessary to set a max/min metaspace size[1] for the following reasons:
*Metaspace size is unlimited by default. Since it only holds class metadata, size requirements are minimal.
*It does not require a full gc to resize the metaspace, as it did with the perm generation.

MaxMetaspaceSize includes CompressedClassSpaceSize, so MaxMetaspaceSize should be larger than CompressedClassSpaceSize.

The default MaxMetaspaceSize is 1g:
java -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
uintx CompressedClassSpaceSize = 1073741824

{product}

If MaxMetaspaceSize is set smaller than CompressedClassSpaceSize, the JVM auto adjusts CompressedClassSpaceSize as follows: CompressedClassSpaceSize = MaxMetaspaceSize - (2 * InitialBootClassLoaderMetaspaceSize).[2]

The default EAP Metaspace sizes are less than the default CompressedClassSpaceSize:
-XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m

This adjusts down the MaxMetaspaceSize to 248m:
java -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
uintx CompressedClassSpaceSize := 260046848 {product}

We have had a lot of OOME Metaspace cases[3], and support is no longer recommending customers set Metaspace:
"In general, you should not need to set a maximum size, unless you are experiencing large metaspace leaks and would prefer it to fail rather than keep increasing memory size."[1]

This was discussed with the OpenJDK developers[4], and their recommendation was to remove the Metaspace settings, and especially in the context of containers.

References:
[1]https://access.redhat.com/solutions/1489263
[2]https://access.redhat.com/solutions/2132101
[3]https://access.redhat.com/solutions/2038983
[4]http://post-office.corp.redhat.com/archives/support-openjdk/2019-July/msg00003.html