as others have said, absolutely do not consider storing a KMS on the vsanDatastore it is providing encryption to and here's why: such a cluster is just one power-outage away from:
1. Losing the cached KEK that it uses to unlock the disks using the DEK leading to
2. Not being able to access the Disk-Groups and thus the data and thus
3. Not being able to power the KMS VM(s) on to get the KEK (repeat in a circle indefinitely).
Just because you only have one datastore available doesn't mean you can't have a KMS available else where - this can run anywhere else, either on another cluster you have available or even in the cloud.
Going with vSphere Native Key Provider is potentially a viable option here - while this relies on vCenter instead of a KMS (and which you should ideally always be running somewhere other than on the cluster it manages) to store keys, if you configure the hosts with physical TPM modules and configure ESXi Key Persistence the KDK (Key Derivation Key) will still be available post reboot even if vCenter is not available. Do note though that this is not the same thing as a full-fledged KMS and can't be used for anything non-vSphere.
Before deciding on either of these (or any solution) I would strongly advise doing the due diligence of reading as much relevant documentation possible relating to these two topics.