docs: Update v2 Catalog API note to re-iterate beta and add downgrade from enterprise note (#20757)

* Update v1_18_x.mdx
* Update traffic-split.mdx

---------

Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>

website/content/docs/architecture/v2/catalog.mdx

@@ -4,6 +4,12 @@ page_title: Consul catalog v2 architecture
 description: Learn about version 2 of the Consul catalog, which uses GAMMA specified resources. Learn how the v2 catalog corresponds to the v1 catalog.
 ---
 
+<Warning>
+
+The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
+
+</Warning>
+
 # Consul catalog v2 architecture
 
 This topic provides information about version 2 (v2) of the Consul catalog API. The catalog tracks registered services and their locations for both service discovery and service mesh use cases.

website/content/docs/architecture/v2/groups.mdx

@@ -4,6 +4,12 @@ page_title: Consul resource groups
 description: Learn about resource groups in version 2 of Consul's internal architecture. The auth, catalog, and mesh groups structure Consul's ability to target individual workloads or an entire collection of workload endpoints.
 ---
 
+<Warning>
+
+The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
+
+</Warning>
+
 # Consul resource groups
 
 This topic provides an overview of resource groups in Consul's v2 architecture.

website/content/docs/architecture/v2/index.mdx

@@ -4,6 +4,12 @@ page_title: Consul v2 architecture
 description: Learn about version 2 of Consul's internal architecture, which replaces services and service instances with workloads and workload identies.
 ---
 
+<Warning>
+
+The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
+
+</Warning>
+
 # Consul v2 architecture
 
 This topic provides an overview of Consul's v2 architecture changes and their impact on Consul operations. 

website/content/docs/k8s/multiport/configure.mdx

@@ -6,6 +6,12 @@ description: Learn how to enable the v2 catalog and configure services to suppor
 
 # Configure multi-port services
 
+<Warning>
+
+The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
+
+</Warning>
+
 <Note>
 
 Multi-port services and selecting workloads using multiple services require enabling [Consul's v2 architecture](/consul/docs/architecture/v2).  

website/content/docs/k8s/multiport/index.mdx

@@ -4,6 +4,12 @@ page_title: Use the v2 Catalog API
 description: Consul on Kubernetes supports the Catalog V2 API, which unlocks new service discovery and service mesh workflows. Learn how Consul’s Catalog V2 API supports workloads with multiple ports and selecting a workload using multiple services.  
 ---
 
+<Warning>
+
+The v2 catalog API and Traffic Permissions API are currently in beta. This documentation supports testing and development scenarios. Do not use these APIs in secure production environments.
+
+</Warning>
+
 # Use the v2 Catalog API
 
 This topic describes the process to use the v2 catalog API to register a service with multiple ports or select a workload using multiple services on Kubernetes deployments. For information about the v2 catalog’s contents and structure, refer to [v2 catalog architecture](/consul/docs/architecture/v2/catalog).

website/content/docs/k8s/multiport/traffic-split.mdx

@@ -8,7 +8,7 @@ description: Learn how to configure Consul to split TCP traffic between two port
 
 <Warning>
 
-Multi-port services are part of a beta release. This documentation supports testing and development scenarios. Do not use multi-port services or the v2 catalog API in secure production environments.
+The v2 catalog API is currently in beta. This documentation supports testing and development scenarios. Do not use the v2 catalog API in secure production environments.
 
 </Warning>
 
@@ -18,10 +18,10 @@ This page describes the process for splitting TCP, HTTP, and gRPC traffic betwee
 
 Splitting traffic between two ports of a multi-port service requires the [v2 catalog API](/consul/docs/architecture/v2/catalog).
 
-In addition, how you define a multi-port service affects how Services are addressed in Kubernetes. The instructions on this page offer examples for two configuration methods:
+In addition, they are two different workflows for registering Services in Kubernetes using the v2 catalog API. The instructions on this page offer examples for two configuration methods:
 
-- **Method 1**: Define a single Kubernetes Service that exposes multiple ports
+- **Method 1**: Register a Kubernetes service that select workloads which expose multiple ports
-- **Method 2**: Define multiple Kubernetes Services that expose individual ports
+- **Method 2**: Register multiple Kubernetes Services that direct traffic to an explicit port on the same workload
 
 For guidance on enabling the v2 catalog, deploying multi-port services using these methods, and applying traffic permissions to the services, refer to [configure multi-port services](/consul/docs/k8s/multiport/configure).
 

website/content/docs/release-notes/consul/v1_18_x.mdx

@@ -11,30 +11,34 @@ We are pleased to announce the following Consul updates.
 
 ## Release highlights
 
-**Consul catalog v2 API updates:** Additional improvements were made to the v2 catalog API, which enables support for [multi-port services on Kubernetes](/consul/docs/k8s/multiport). End user facing changes include the ability to use a service's ports in xRoute configurations as opposed to the workload port for reference in the parentRef stanza of the xRoute configuration, and the change in Traffic Permissions to only allow `ACTION_DENY` for Consul Enterprise as it will enable future governance related workflows. 
+- **Consul v2 Catalog API and Traffic Permission API updates:** Additional improvements were made to the v2 catalog API, which enables support for [multi-port services on Kubernetes](/consul/docs/k8s/multiport). End user facing changes include the ability to use a service's ports in xRoute configurations as opposed to the workload port for reference in the parentRef stanza of the xRoute configuration. In addition, the Traffic Permissions API was changed to only allow `ACTION_DENY` for Consul Enterprise as it will enable future governance related workflows. 
 
-The v2 catalog API is currently available for Consul on Kubernetes deployments only. Refer to [Consul v2 architecture](/consul/docs/architecture/v2) for more information.
+  The v2 Catalog API is currently available for Consul on Kubernetes deployments only. Refer to [Consul v2 architecture](/consul/docs/architecture/v2) for more information.
 
-**Consul Long Term Support (LTS) (Enterprise):** Consul Enterprise users can now receive Long Term Support for approximately 2 years on some Consul releases, starting with Consul Enterprise v1.15. During the LTS window, eligible fixes are provided through a new minor release on the affected LTS release branch.
+  <Note> The v2 Catalog API and the Traffic Permssions API are in beta and under active development, so we do not recommend using them in production. </Note>
+
+- **Consul Long Term Support (LTS) (Enterprise):** Consul Enterprise users can now receive Long Term Support for approximately 2 years on some Consul releases, starting with Consul Enterprise v1.15. During the LTS window, eligible fixes are provided through a new minor release on the affected LTS release branch.
 
   An LTS release is planned for every 3 releases, and it is maintained until it is 6 releases from the latest major release. For example, Consul Enterprise v1.15.x, v1.18x, and v1.21.x are the next three planned releases. The LTS period for Consul Enterprise v1.15.x ends when Consul Enterprise v1.21.0 releases.
 
   For more information, refer to [Consul Enterprise Long Term Support](/consul/docs/enterprise/long-term-support).
 
-**Fault injection (Enterprise):** For Enterprise users, Consul’s service mesh now supports managing traffic with fault injection behavior that is defined in an upstream service’s service defaults configuration entry or CRD. Supported fault injection behavior includes delaying, aborting, and rate limiting traffic between services. You can use fault injection to test your network’s resilience under different conditions.
+- **Fault injection (Enterprise):** For Enterprise users, Consul’s service mesh now supports managing traffic with fault injection behavior that is defined in an upstream service’s service defaults configuration entry or CRD. Supported fault injection behavior includes delaying, aborting, and rate limiting traffic between services. You can use fault injection to test your network’s resilience under different conditions.
 
   For more information, refer to [fault injection](/consul/docs/manage-traffic/fault-injection).
 
-**Consul admin partition support for Nomad:** Nomad now supports configurations for a Consul datacenter’s admin partition when scheduling applications. Admin partitions are a Consul Enterprise feature that enable multi-tenancy for Consul servers so that several teams in your organization can use a single secure Consul datacenter. Admin partitions also enable cluster peering as a strategy for extending your service mesh east-west across regions in a single cloud provider or across multiple cloud providers.
+- **Consul admin partition support for Nomad:** Nomad now supports configurations for a Consul datacenter’s admin partition when scheduling applications. Admin partitions are a Consul Enterprise feature that enable multi-tenancy for Consul servers so that several teams in your organization can use a single secure Consul datacenter. Admin partitions also enable cluster peering as a strategy for extending your service mesh east-west across regions in a single cloud provider or across multiple cloud providers.
 
   Refer to [admin partitions](/consul/docs/enterprise/admin-partitions) for more information.
 
-**Transparent proxy for EC2 on ECS:**  Consul now supports transparent proxy mode for deployments running on EC2 instances in AWS Elastic Container Service (ECS). When service mesh proxies are in transparent proxy mode, Consul service mesh uses IPtables to direct all inbound and outbound traffic to the sidecar. Consul also uses information configured in service intentions to infer routes, which eliminates the need to explicitly configure upstreams.
+- **Transparent proxy for EC2 on ECS:**  Consul now supports transparent proxy mode for deployments running on EC2 instances in AWS Elastic Container Service (ECS). When service mesh proxies are in transparent proxy mode, Consul service mesh uses IPtables to direct all inbound and outbound traffic to the sidecar. Consul also uses information configured in service intentions to infer routes, which eliminates the need to explicitly configure upstreams.
 
   Consul’s transparent proxy allows applications to communicate through Consul’s service mesh without modifying their underlying configurations to use Consul DNS. The transparent proxy also hardens application security by preventing direct inbound connections that bypass the mesh.
 
   Refer to [transparent proxy overview](/consul/docs/k8s/connect/transparent-proxy) and [Consul on ECS overview](/consul/docs/ecs) for more information.
 
+- **Downgrade from Consul Enterprise to Consul Community Edition**: Consul now provides the ability for enterprise users to migrate their deployments to Community edition and disable enterprise features for business continuity. Refer to [Downgrade from Consul Enterprise to the community edition](/consul/docs/v1.18.x/enterprise/ent-to-ce-downgrades) for more information. 
+
 ## Upgrading
 
 For more detailed information, please refer to the [upgrade details page](/consul/docs/upgrading/upgrade-specific) and the changelogs.