Memory page size
The constraints on the memory page size are primarily the MMU (Memory management Unit) hardware and performance criteria. Obviously the chosen page size has to be supported by the MMU (i.e. the page mapping hardware that provides virtual memory translations). Page size is chosen for the amount of code or data that should be swapped in or out when a page fault occurs (a small function is not in memory, so do we swap data out and read in just 1K of code or go for 8K of code?), and the cost of transferring that quantity of code/data (e.g. reading in two sectors is faster than reading 16 sectors).
Historically 4KiB has been a suitable balance for many systems. The actual size used is specified in the virtual memory code of the OS.
The cluster size is purely a filesystem unit, and the term "cluster" is primarily Microsoft terminology. The generic term is unit of allocation within a filesystem. The allocation unit is intrinsic to the specific installation of the filesystem (i.e. one NTFS partition can have a cluster size of 4 KiB and another NTFS partition on the same disk drive can have 64KiB clusters).
The filesystem allocation unit is primarily for bookkeeping of free (i.e. unallocated) versus in-use (i.e. allocated to files and directories) disk sectors (in the partition). Each file is composed of an ordered list of allocation units (i.e. clusters).
The allocation size is chosen/specified at the time of filesystem creation (i.e. formatting), and has to be based on some number of sectors (but preferably a power of 2), since the sector size is the fundamental unit of access and physical disk I/O. A small allocation size (such as just 1 sector) tends to have more negative (rather than positive, i.e. less wasted slack space) impact on filesystem (and disk) performance, such as a larger allocation table, more bookkeeping. A small allocation size also would constrain allocation addressing and total filesystem capacity. A large allocation size is beneficial when the filesystem has to span a large partition and/or the typical file size will be large (the large cluster size could reduce fragmentation) but at the expense of more wasted slack space.
Note that disk I/O does not have to be performed in units of the allocation size (e.g. if the file is less than a 512-byte sector long, the OS could chose to read only the first sector instead of the whole cluster). But any OS accessing a filesystem must adhere to its intrinsic allocation size (i.e. the allocation size cannot be changed).
Also see What are disk sectors for? and Downsides of a small allocation-unit size