add docs covering capacity-type topology spread

website/content/en/preview/provisioner.md

@@ -168,6 +168,7 @@ Karpenter supports specifying capacity type, which is analogous to [EC2 purchase
 
 Karpenter prioritizes Spot offerings if the provisioner allows Spot and on-demand instances. If the provider API (e.g. EC2 Fleet's API) indicates Spot capacity is unavailable, Karpenter caches that result across all attempts to provision EC2 capacity for that instance type and zone for the next 45 seconds. If there are no other possible offerings available for Spot, Karpenter will attempt to provision on-demand instances, generally within milliseconds. 
 
+Karpenter also allows `karpenter.sh/capacity-type` to be used as a topology key for enforcing topology-spread.
 
 ## spec.kubeletConfiguration
 

website/content/en/preview/tasks/scheduling.md

@@ -240,6 +240,12 @@ For example, if there were three nodes and five pods the pods could be spread 1,
 If instead the spread were 5, pods could be 5, 0, 0 or 3, 2, 0, or 2, 1, 2 and so on.
 * Karpenter is always able to improve skew by launching new nodes in the right zones. Therefore, `whenUnsatisfiable` does not change provisioning behavior.
 
+The three supported `topologyKey` values that Karpenter supports are:
+- `topology.kubernetes.io/zone`
+- `kubernetes.io/hostname`
+- `karpenter.sh/capacity-type`
+
+
 See [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) for details.
 
 ## Persistent Volume Topology