Update website/content/docs/k8s/annotations-and-labels.mdx

Co-authored-by: Jared Kirschner <85913323+jkirschner-hashicorp@users.noreply.github.com>

website/content/docs/k8s/annotations-and-labels.mdx

@@ -74,7 +74,7 @@ The following Kubernetes resource annotations could be used on a pod to control
 - `consul.hashicorp.com/connect-service-upstreams` - The list of upstream
   services that this pod needs to connect to via the service mesh along with a static
   local port to listen for those connections. When transparent proxy is enabled,
-  this annotation is optional. This annotation can be either _unlabeled_ or _labeled_. Unlabeled annotations use component names, and the component types are inferred through the annotation's syntax. Labeled annotations explicitly associate component names and types to form Consul DNS addresses. To configure upstreams for [cluster peering](/consul/docs/k8s/connect/cluster-peering/tech-specs), use the labeled format.
+  this annotation is optional. This annotation can be either _labeled_ or _unlabeled_. We recommend the labeled format because it has a more consistent syntax and can be used to reference cluster peers as upstreams.
 
     - **Unlabeled**:
        The unlabeled annotation format allows you to reference any service not in a cluster peer as an upstream. You can specify a Consul Enterprise namespace. You can also specify an admin partition in the same datacenter or a WAN federated datacenter. Unlike the labeled annotation, you can also reference a prepared query as an upstream.