Note: There is an existing stackoverflow post which discuss about --master-ipv4-cidr, but it doesn't discuss about the topic which I am asking in the question. Please don't mark this as duplicate.

Problem description I am creating private clusters in GKE and got confused with the --master-ipv4-cidr range. This link, mentions that --master-ipv4-cidr needed CIDR in RFC 1918 range.

"--master-ipv4-cidr 172.16.0.0/28 specifies an RFC 1918 range for the master. This setting is permanent for this cluster."

Since valid RFC 1918 ranges are

 10.0.0.0        -   10.255.255.255  (10/8 prefix)
 172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
 192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

So I tried to create private cluster with following values:

  --master-ipv4-cidr "172.17.0.0/28" 
  --cluster-ipv4-cidr "172.16.128.0/17" 
  --services-ipv4-cidr "192.168.1.0/24" 

Since 172.17.0.0/28 is also from RFC 1918 range I thought that cluster will come up. But it resulted in error as mentioned below

172.17.0.0/16 is a reserved GKE IP range and cannot be used for the 'master-ipv4-cidr'.

Then I changed --master-ipv4-cidr to example given in link and cluster created successfully. Below are the successful case values.

  --master-ipv4-cidr "172.16.0.16/28" 
  --cluster-ipv4-cidr "172.16.128.0/17" 
  --services-ipv4-cidr "192.168.1.0/24" 

Now my question are

1. Does --master-ipv4-cidr expects CIDR in 172.16.0.0/28 only and it cannot accept any other range from 10/8 or 192.168/16 or any other range for example 172.17.0.0/28 which I provided earlier?
2. With an existing cluster --master-ipv4-cidr of 172.16.0.0/28, if I create another cluster in same VPC what should be the --master-ipv4-cidr value? Because creating another cluster with same --master-ipv4-cidr 172.16.0.0/28 fails with below error which is quite expected.

Google Compute Engine: An IP range in the peer network (172.16.0.16/28) overlaps with an IP range (172.16.0.16/28) in an active peer (gke-c2a126697c6fee94c2b8-1e18-f2ff-peer) of the local network. and thats expected because 172.16.0.16/28 already exist in an existing cluster in same vpc to which its getting peered.

3. I am thinking to manage my cluster pods from 172.16.0.0 range and services from 192.168.0.0 range of RFC 1918 and not use 10/8 network to avoid conflict with existing office network. Since 172.16/12 is a superset of 172.16.0.0/28. How do you make sure that they are separated from each other?

Apologies for asking many question here, but I am just trying to keep the entire context at same place.