A suite is a container project (introduced in NB 5.0 for the new module development support) used to group external module projects into a unit whose members can refer to one another as well as to a NB platform. If you only have one module project, you can treat it as "standalone" and you do not need a suite, but using a suite is advisable for serious projects since it offers you more options, such as adding library wrapper modules, or creating a complete application based on your module.
Currently a suite S2 cannot directly depend on another suite S1. But if S1 uses NB platform P1, you could create a derived platform P2 by building S1 on top of P1, and then select P2 as the NB platform for S2. Then S2 can refer to all the modules in P1 as well as the modules built from S1.
The NB IDE build (from CVS sources on netbeans.org) does not use suites at all. It uses a historical build infrastructure which partially overlaps the external module/suite build harness introduced in 5.0, but which has different requirements (and is considerably more complex). Module projects physically inside the netbeans.org CVS tree cannot be "standalone" modules nor "suite component" modules - they are simply netbeans.org modules, and as such use a (slightly) different format for metadata, and have access to somewhat different facilities specific to netbeans.org practices.
Now for clusters. Clusters are not really related to suites. A cluster (introduced in NB 4.0) is simply a subdirectory of a NB-based-app binary installation; every module in the installation falls into one cluster. The installation is divided into clusters for purposes of:
1. Conceptual clarity. 2. Possible mapping to native packaging systems such as RPM.
The NB team has a policy of treating inter-cluster module dependencies as more significant than intra-cluster module dependencies with respect to backward compatibility, with the aim of making it possible for product teams building on top of the NB IDE to select a subset of the IDE to use with cluster granularity rather than with module granularity, which may be simpler to grasp and integrate with native packaging. But there is nothing preventing you from reusing a subset with module granularity. Future UI for the suite project type will probably permit either style at the user's discretion.
The NB launcher (nbexec) accepts a list of cluster directories to load modules from - basically a search path. There are no further semantics to clusters.
The suite project type does not yet have a standard build target to assemble a complete application. This is coming soon. For simplicity, it will probably place all modules built from suite sources into their own cluster (with a name to be specified by the user) parallel to the clusters copied from the base platform, but there would be no particular consequences to manually overriding this behavior.
NBM files, and thus modules published on Auto Update, have no associated cluster; it is up to the update tool to decide where to install them: in an existing cluster, or in the user directory. The netbeans/ subdirectory of the NBM (which is a ZIP file) has a file layout which matches the layout of files within a single cluster. Each cluster managed by Auto Update has an update_tracking/ subdirectory with one XML file per module, enumerating the files which that module contributes to the cluster.
Currently the "NB Platform" is just the platform6 cluster from the IDE, though the exact choice of modules is not ideal. Still under discussion.
Clusters are supposed to be medium-grained or coarse-grained, unlike modules which are generally fine-grained units. It is true that we currently have one massive ide6 cluster, though I am not sure that is really by design - I think it is because no one has bothered to analyze the breakdown more carefully. Probably Java-specific functionality should be its own cluster, not ide6.
Source: NetBeans FAQ