From 0c1f4560e3a171afc86be612324ac3cd5b3b8cd8 Mon Sep 17 00:00:00 2001 From: Nadine2016 Date: Fri, 16 Oct 2026 10:06:38 -0400 Subject: [PATCH 1/2] Reuse snippet Signed-off-by: Nadine2016 --- assets/agw-docs/pages/install/advanced.md | 103 +----------------- .../agw-docs/snippets/multi-controlplane.md | 100 +++++++++++++++++ .../kubernetes/main/documentation/registry.md | 32 ++++++ 3 files changed, 135 insertions(+), 100 deletions(-) create mode 100644 assets/agw-docs/snippets/multi-controlplane.md create mode 100644 content/docs/kubernetes/main/documentation/registry.md diff --git a/assets/agw-docs/pages/install/advanced.md b/assets/agw-docs/pages/install/advanced.md index 6be377b75..53fc3fe37 100644 --- a/assets/agw-docs/pages/install/advanced.md +++ b/assets/agw-docs/pages/install/advanced.md @@ -57,106 +57,9 @@ controller: ``` {{< version exclude-if="1.3.x,1.2.x,1.1.x,1.0.x,2.2.x" >}} -## Multiple control planes {#multiple-control-planes} - -You can run multiple independent {{< reuse "agw-docs/snippets/agentgateway.md" >}} control planes in the same cluster. This setup is different from running multiple replicas of one control plane for high availability. Each independent control plane manages its own GatewayClass and set of Gateways. - -Each additional control plane needs the following Helm settings. - -| Setting | Description | -| -- | -- | -| Release namespace | Install each control plane in a separate namespace. The namespace separates the namespaced Helm resources and the leader election leases. | -| `gatewayClassName` | A unique GatewayClass name. GatewayClasses are cluster-scoped, so their names must be unique across the cluster. | -| `controllerName` | A unique controller name. The controller reconciles only the GatewayClasses whose `spec.controllerName` matches this value. | -| `discoveryNamespaceSelectors` | Optional. The namespaces that the control plane watches for gateway configuration. Omit to watch all namespaces. | - -> [!WARNING] -> Change `gatewayClassName` and `controllerName` together. If an additional installation changes only `controllerName`, both installations try to manage the default `agentgateway` GatewayClass. Separate release namespaces do not prevent this conflict, because GatewayClasses are cluster-scoped. - -The following steps add a second control plane for a `tenant-b` team. The {{< reuse "agw-docs/snippets/agentgateway.md" >}} and {{< reuse "agw-docs/snippets/k8s-gateway-api-name.md" >}} custom resource definitions (CRDs) are cluster-scoped, so you install them only once per cluster and not again for each control plane. - -1. Create the namespace for the workloads and Gateways that the second control plane manages, and label it so that the second control plane discovers it. - - ```sh - kubectl create namespace tenant-b - kubectl label namespace tenant-b gateway-controller=tenant-b - ``` - -2. Create a `secondary-values.yaml` file for the second control plane. Each entry in `discoveryNamespaceSelectors` is disjunctive (OR semantics), so the control plane watches a namespace if that namespace matches any entry. This example matches two sets of namespaces: the control plane's own namespace, `agentgateway-tenant-b-system`, and every namespace with the `gateway-controller: tenant-b` label. Include the control plane's own namespace, because the controller watches resources in that namespace, such as the certificate that secures its xDS connection. - - ```yaml - gatewayClassName: agentgateway-tenant-b - controllerName: agentgateway.dev/agentgateway-tenant-b - - discoveryNamespaceSelectors: - - matchExpressions: - - key: kubernetes.io/metadata.name - operator: In - values: - - agentgateway-tenant-b-system - - matchLabels: - gateway-controller: tenant-b - ``` - -3. Install the second control plane in its own namespace. - - ```sh - helm upgrade -i --create-namespace \ - -n agentgateway-tenant-b-system agentgateway-tenant-b {{< reuse "/agw-docs/snippets/helm-path.md" >}} \ - --version {{< reuse "agw-docs/versions/helm-version-flag.md" >}} \ - -f secondary-values.yaml - ``` - -4. Verify that each control plane owns its own GatewayClass. - - ```sh - kubectl get gatewayclass -o custom-columns='NAME:.metadata.name,CONTROLLER:.spec.controllerName' - ``` - - Example output: - - ```console - NAME CONTROLLER - agentgateway agentgateway.dev/agentgateway - agentgateway-tenant-b agentgateway.dev/agentgateway-tenant-b - ``` - -5. Create a Gateway that references the GatewayClass of the second control plane. - - ```yaml - kubectl apply -f - < [!NOTE] -> If you omit `discoveryNamespaceSelectors`, each control plane watches gateway configuration in all namespaces. The unique controller and GatewayClass names still separate ownership, but they do not isolate discovery by namespace. If you enable proxy monitoring, also add the custom GatewayClass to `monitoring.proxy.gatewayClassNames` for that installation. + +{{< reuse "agw-docs/snippets/multi-controlplane.md" >}} + {{< /version >}} {{< version exclude-if="2.2.x,1.0.x,1.1.x" >}} diff --git a/assets/agw-docs/snippets/multi-controlplane.md b/assets/agw-docs/snippets/multi-controlplane.md new file mode 100644 index 000000000..7846e946c --- /dev/null +++ b/assets/agw-docs/snippets/multi-controlplane.md @@ -0,0 +1,100 @@ +## Multiple control planes {#multiple-control-planes} + +You can run multiple independent {{< reuse "agw-docs/snippets/agentgateway.md" >}} control planes in the same cluster. This setup is different from running multiple replicas of one control plane for high availability. Each independent control plane manages its own GatewayClass and set of Gateways. + +Each additional control plane needs the following Helm settings. + +| Setting | Description | +| -- | -- | +| Release namespace | Install each control plane in a separate namespace. The namespace separates the namespaced Helm resources and the leader election leases. | +| `gatewayClassName` | A unique GatewayClass name. GatewayClasses are cluster-scoped, so their names must be unique across the cluster. | +| `controllerName` | A unique controller name. The controller reconciles only the GatewayClasses whose `spec.controllerName` matches this value. | +| `discoveryNamespaceSelectors` | Optional. The namespaces that the control plane watches for gateway configuration. Omit to watch all namespaces. | + +> [!WARNING] +> Change `gatewayClassName` and `controllerName` together. If an additional installation changes only `controllerName`, both installations try to manage the default `agentgateway` GatewayClass. Separate release namespaces do not prevent this conflict, because GatewayClasses are cluster-scoped. + +The following steps add a second control plane for a `tenant-b` team. The {{< reuse "agw-docs/snippets/agentgateway.md" >}} and {{< reuse "agw-docs/snippets/k8s-gateway-api-name.md" >}} custom resource definitions (CRDs) are cluster-scoped, so you install them only once per cluster and not again for each control plane. + +1. Create the namespace for the workloads and Gateways that the second control plane manages, and label it so that the second control plane discovers it. + + ```sh + kubectl create namespace tenant-b + kubectl label namespace tenant-b gateway-controller=tenant-b + ``` + +2. Create a `secondary-values.yaml` file for the second control plane. Each entry in `discoveryNamespaceSelectors` is disjunctive (OR semantics), so the control plane watches a namespace if that namespace matches any entry. This example matches two sets of namespaces: the control plane's own namespace, `agentgateway-tenant-b-system`, and every namespace with the `gateway-controller: tenant-b` label. Include the control plane's own namespace, because the controller watches resources in that namespace, such as the certificate that secures its xDS connection. + + ```yaml + gatewayClassName: agentgateway-tenant-b + controllerName: agentgateway.dev/agentgateway-tenant-b + + discoveryNamespaceSelectors: + - matchExpressions: + - key: kubernetes.io/metadata.name + operator: In + values: + - agentgateway-tenant-b-system + - matchLabels: + gateway-controller: tenant-b + ``` + +3. Install the second control plane in its own namespace. + + ```sh + helm upgrade -i --create-namespace \ + -n agentgateway-tenant-b-system agentgateway-tenant-b {{< reuse "/agw-docs/snippets/helm-path.md" >}} \ + --version {{< reuse "agw-docs/versions/helm-version-flag.md" >}} \ + -f secondary-values.yaml + ``` + +4. Verify that each control plane owns its own GatewayClass. + + ```sh + kubectl get gatewayclass -o custom-columns='NAME:.metadata.name,CONTROLLER:.spec.controllerName' + ``` + + Example output: + + ```console + NAME CONTROLLER + agentgateway agentgateway.dev/agentgateway + agentgateway-tenant-b agentgateway.dev/agentgateway-tenant-b + ``` + +5. Create a Gateway that references the GatewayClass of the second control plane. + + ```yaml + kubectl apply -f - < [!NOTE] +> If you omit `discoveryNamespaceSelectors`, each control plane watches gateway configuration in all namespaces. The unique controller and GatewayClass names still separate ownership, but they do not isolate discovery by namespace. If you enable proxy monitoring, also add the custom GatewayClass to `monitoring.proxy.gatewayClassNames` for that installation. \ No newline at end of file diff --git a/content/docs/kubernetes/main/documentation/registry.md b/content/docs/kubernetes/main/documentation/registry.md new file mode 100644 index 000000000..7c8c4d723 --- /dev/null +++ b/content/docs/kubernetes/main/documentation/registry.md @@ -0,0 +1,32 @@ +--- +title: AI artifact registry +weight: 50 +description: Discover, govern, and route to agents, MCP servers, prompts, and skills that are cataloged in an AI artifact registry. +test: skip +--- + +Agentgateway connects to an AI artifact registry that catalogs and governs the agents, Model Context Protocol (MCP) servers, prompts, and skills that requests route to. Instead of hardcoding backend addresses or tracking artifacts across Slack threads and spreadsheets, you point agentgateway at the registry and let the registry resolve which artifacts exist, which versions are approved, and where they run. + +## About the AI artifact registry + +The registry is built on the open source [agentregistry project](https://aregistry.ai). Agents, MCP servers, prompts, and skills are published to the registry with a name, version, and metadata, so that agentgateway and other consumers can discover and reuse them instead of relying on ad-hoc sharing. Every artifact carries an approval status, so agentgateway can route only to artifacts that passed review. + +The following screenshot shows the registry dashboard, where published artifacts, their versions, and their approval status are visible in one place. + +![Solo Enterprise for agentregistry dashboard, showing published agents, MCP servers, prompts, and skills with their version and approval status](https://docs.solo.io/agentregistry/img/agentregistry/ar-dashboard.svg) + +## Use cases + +- **Discover backends to route to.** Find approved MCP servers and agents to connect through agentgateway, instead of hardcoding addresses that only a few people know about. +- **Govern what agentgateway can reach.** Limit agentgateway to artifacts that passed review, so unapproved or unmaintained backends never receive production traffic. +- **Roll out new versions.** Move agentgateway traffic to a new version of an MCP server or agent as the registry approves it, without hand-editing gateway configuration for every backend. + +## Benefits + +- **One source of truth.** Replace tribal knowledge and informal sharing with a single catalog of the MCP servers, agents, prompts, and skills that agentgateway can route to. +- **Composable agents.** Build agents by combining published MCP servers, prompts, and skills instead of writing a new integration for each one. +- **Semantic discovery.** Find the artifact you need by describing it, instead of knowing its exact name, through agentregistry's built-in search. + +## Enable the AI artifact registry + +Agentgateway routes to artifacts that are published to the open source [agentregistry project](https://aregistry.ai). For centralized governance, approval workflows, and multi-cloud deployment across an organization, install [Solo Enterprise for agentregistry](https://www.solo.io/products/agentregistry) instead. For installation steps, see the [Solo Enterprise for agentregistry documentation](https://docs.solo.io/agentregistry/). \ No newline at end of file From 0b56a40c98c05d05e1a893487a9ce0985472a6d6 Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Fri, 16 Oct 2026 10:11:46 -0400 Subject: [PATCH 2/2] Delete content/docs/kubernetes/main/documentation/registry.md Signed-off-by: Nadine Spies --- .../kubernetes/main/documentation/registry.md | 32 ------------------- 1 file changed, 32 deletions(-) delete mode 100644 content/docs/kubernetes/main/documentation/registry.md diff --git a/content/docs/kubernetes/main/documentation/registry.md b/content/docs/kubernetes/main/documentation/registry.md deleted file mode 100644 index 7c8c4d723..000000000 --- a/content/docs/kubernetes/main/documentation/registry.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: AI artifact registry -weight: 50 -description: Discover, govern, and route to agents, MCP servers, prompts, and skills that are cataloged in an AI artifact registry. -test: skip ---- - -Agentgateway connects to an AI artifact registry that catalogs and governs the agents, Model Context Protocol (MCP) servers, prompts, and skills that requests route to. Instead of hardcoding backend addresses or tracking artifacts across Slack threads and spreadsheets, you point agentgateway at the registry and let the registry resolve which artifacts exist, which versions are approved, and where they run. - -## About the AI artifact registry - -The registry is built on the open source [agentregistry project](https://aregistry.ai). Agents, MCP servers, prompts, and skills are published to the registry with a name, version, and metadata, so that agentgateway and other consumers can discover and reuse them instead of relying on ad-hoc sharing. Every artifact carries an approval status, so agentgateway can route only to artifacts that passed review. - -The following screenshot shows the registry dashboard, where published artifacts, their versions, and their approval status are visible in one place. - -![Solo Enterprise for agentregistry dashboard, showing published agents, MCP servers, prompts, and skills with their version and approval status](https://docs.solo.io/agentregistry/img/agentregistry/ar-dashboard.svg) - -## Use cases - -- **Discover backends to route to.** Find approved MCP servers and agents to connect through agentgateway, instead of hardcoding addresses that only a few people know about. -- **Govern what agentgateway can reach.** Limit agentgateway to artifacts that passed review, so unapproved or unmaintained backends never receive production traffic. -- **Roll out new versions.** Move agentgateway traffic to a new version of an MCP server or agent as the registry approves it, without hand-editing gateway configuration for every backend. - -## Benefits - -- **One source of truth.** Replace tribal knowledge and informal sharing with a single catalog of the MCP servers, agents, prompts, and skills that agentgateway can route to. -- **Composable agents.** Build agents by combining published MCP servers, prompts, and skills instead of writing a new integration for each one. -- **Semantic discovery.** Find the artifact you need by describing it, instead of knowing its exact name, through agentregistry's built-in search. - -## Enable the AI artifact registry - -Agentgateway routes to artifacts that are published to the open source [agentregistry project](https://aregistry.ai). For centralized governance, approval workflows, and multi-cloud deployment across an organization, install [Solo Enterprise for agentregistry](https://www.solo.io/products/agentregistry) instead. For installation steps, see the [Solo Enterprise for agentregistry documentation](https://docs.solo.io/agentregistry/). \ No newline at end of file