Chapter 2. Deploy isolated MCP gateway instances


You can deploy multiple MCP gateway instances within a single cluster to isolate traffic between teams. Each instance uses a single MCPGatewayExtension custom resource (CR) to manage associated MCP servers.

Important

MCP gateway is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features offer early access to upcoming product features, enabling customers to test functionality and give feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

2.1. How isolated MCP gateway deployment works

By using isolated MCP gateway deployments, different teams can manage their own Model Context Protocol (MCP) servers independently. Each isolated MCP gateway deployment uses a single MCPGatewayExtension custom resource (CR).

You can deploy more than one MCP gateway instance within a single cluster by using more than one Gateway CR. You must use one MCPGatewayExtension CR for each Gateway CR.

Each deployment of the MCP gateway manages its associated MCP servers by using the MCPGatewayExtension CR in the following ways:

  • Defines which Gateway object the MCP gateway instance is responsible for.
  • Determines where configuration Secret objects are created.
  • Enables isolation by allowing multiple MCP gateway instances in different namespaces to target different Gateway objects.

For example, Team A and Team B share a single, cluster-wide MCP gateway controller. Each team namespace has a different Gateway object, uses different Secrets, and has different MCPServerRegistration CRs.

Team A namespace
  • MCPGatewayExtension CR targeting Gateway A
  • MCP broker and router
  • Config Secret
  • MCPServerRegistration CRs
Team B namespace
  • MCPGatewayExtension CR targeting Gateway B
  • MCP broker and router
  • Config Secret
  • MCPServerRegistration CRs

2.1.1. Important considerations

One MCPGatewayExtension CR per namespace
Each namespace can have only one MCPGatewayExtension CR. The controller writes configuration to a well-known Secret object name. More than one extension in the same namespace causes them to overwrite each other.
One MCPGatewayExtension CR per Gateway object and listener
Only one MCPGatewayExtension CR can target a specified listener for a given Gateway object. When more than one extension targets the same Gateway object, the controller marks newer ones as Ready: False, with a message starting with `conflict: `. The oldest extension by creation timestamp takes precedence.
Cross-namespace Gateway object references require a ReferenceGrant CR
The ReferenceGrant CR must exist in the target Gateway object namespace.

2.2. Deploy isolated MCP gateway instances

You can deploy more than one isolated MCP gateway instance, each with its own Gateway object, MCPGatewayExtension custom resource (CR), and ReferenceGrant CR. To get started, create an isolated instance for a team. Repeat this procedure for each team that you need to isolate.

Prerequisites

  • You installed OpenShift Container Platform.
  • You installed OpenShift CLI (oc).
  • You installed the MCP gateway in a cluster-central namespace.
  • You configured at least one listener on the Gateway object applied in your central namespace.
  • You set up multi-tenancy on your OpenShift Container Platform cluster.

Procedure

  1. Get the hostname for Team A by running the following command:

    $ echo "team-a.apps.$(oc get dns cluster -o jsonpath='{.spec.baseDomain}')"
  2. Create a team Gateway object for Team A by using the following example:

    apiVersion: gateway.networking.k8s.io/v1
    kind: Gateway
    metadata:
      name: <team_a_mcp_gateway>
      namespace: <gateway_system>
    spec:
      gatewayClassName: openshift-default
      listeners:
        - name: mcp
          hostname: <team_a_hostname>
          port: 443
          protocol: HTTPS
          allowedRoutes:
            namespaces:
              from: All
          tls:
            certificateRefs:
              - group: ''
                kind: Secret
                name: default-ingress-cert
            mode: Terminate
    • Replace the metadata.name value with the name you want to use.
    • If you want your central platform team to manage network infrastructure, TLS certificates, and public IP address allocations, use the same value for metadata.namespace as the cluster-wide Gateway object.
    • If you want Team A to own everything from the network entry point to their MCP server pods, apply the Gateway object directly inside <team_a> in the metadata.namespace parameter.
    • Replace the value of spec.listeners.hostname with the hostname for Team A.
  3. Apply the Gateway CR by running the following command:

    $ oc apply -f <team_a_mcp_gateway.yaml>

    Replace <team_a_mcp_gateway.yaml> with the filename you used.

  4. Verify the Team A Gateway object by running the following command:

    $ oc get gateway <team_a_mcp_gateway> -n <gateway_system>
    • Replace with the Team A Gateway object name.
    • Replace with the namespace where the Team A Gateway object is applied.
  5. Create an MCPGatewayExtension CR for Team A to associate the namespace with the team Gateway object by using the following example:

    apiVersion: mcp.kuadrant.io/v1alpha1
    kind: MCPGatewayExtension
    metadata:
      name: <team_a_mcp_gateway_ext>
      namespace: <team_a>
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: <team_a_mcp_gateway>
        namespace: <gateway_system>
        sectionName: mcp
    • Replace the metadata.name value with the name you want to use.
    • Replace the metadata.namespace value with the team namespace.
    • Replace the spec.targetRef.name value with the name of the team Gateway object.
    • Replace the spec.targetRef.namespace value with the name of the Gateway object namespace.

      Important

      You can create several Gateway objects in the same namespace, but you must only reference one Gateway object one time in your MCPGatewayExtension CRs.

  6. Apply the MCPGatewayExtension CR by running the following command:

    $ oc apply -f <team_a_mcp_gateway_ext.yaml>

    Replace <team_a_mcp_gateway_ext.yaml> with the filename you used.

  7. If you are using the central Gateway object namespace, create a ReferenceGrant CR in the Gateway object namespace by using the following example:

    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: ReferenceGrant
    metadata:
      name: _<team_a_ref_grant>_
      namespace: _<gateway_system>_
    spec:
      from:
        - group: mcp.kuadrant.io
          kind: MCPGatewayExtension
          namespace: _<team_a>_
      to:
        - group: gateway.networking.k8s.io
          kind: Gateway
          name: _<team_a_mcp_gateway>_
    • Replace the metadata.name value with the name you want to use.
    • Replace the metadata.namespace value with the namespace where your Gateway object is applied.
    • Replace the spec.from.namespace value with the team namespace.
    • Replace the spec.to.name value with the team Gateway object name.
  8. Apply the ReferenceGrant CR by running the following command:

    $ oc apply -f <team_a_ref_grant.yaml>

    Replace <team_a_ref_grant.yaml> with the filename you used.

  9. Verify the team MCPGatewayExtension CR by running the following command:

    $ oc wait --for=condition=Ready mcpgatewayextension/<team_a_mcp_gateway_ext> -n <team_a> --timeout=60s
    • Replace <team_a_mcp_gateway_ext> with the name of the extension.
    • Replace <team_a> with the team namespace.
  10. Verify that a pod prefixed mcp-gateway- in the team namespace is running by using the following command:

    $ oc get pods -n <team_a>
    • Replace <team_a> with the team namespace.

Next steps

  • Repeat the steps for additional teams by creating the namespace, Gateway object, MCPGatewayExtension CR, and ReferenceGrant CR with the relevant team values. For example, "Team B", and so on.

After you deploy isolated MCP gateway instances, you can expose each Gateway object externally by creating OpenShift Container Platform routes with TLS termination. Repeat these steps for each team.

Prerequisites

  • You installed OpenShift Container Platform.
  • You installed OpenShift CLI (oc).
  • You deployed an isolated MCP gateway instance for a team.

Procedure

  1. Create an OpenShift Container Platform route for the Team A Gateway object by using the following example:

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: <team_a_route>
      namespace: <gateway_system>
    spec:
      host: <team_a_host>
      tls:
        insecureEdgeTerminationPolicy: Redirect
        termination: edge
      port:
        targetPort: mcp
      to:
        kind: Service
        name: <team_a_mcp_gateway>-openshift-default
        weight: 100
      wildcardPolicy: None
    • Replace the metadata.name value with the route name that you want to use.
    • Replace the metadata.namespace value with the namespace where the Gateway object is applied.
    • Replace the value of spec.host with the hostname for the team you are making the route for.
    • Replace the value of spec.to.name with the Gateway object name and gatewayClassName value.
  2. Apply the CR by running the following command:

    $ oc apply -f <team_a_route.yaml>

    Replace <team_a_route.yaml> with the name that you used for your Route CR.

  3. Verify that the router has successfully admitted the route and mapped it to active endpoints by running the following command:

    $ oc describe route <team_a_route> -n <gateway_system>
    • Replace <team_a_route> with the name of the route.
    • Replace <gateway_system> with the namespace where the Gateway object is applied.

Next steps

Register MCP servers with each Gateway object. When registering MCP servers, ensure that each HTTPRoute CR parentRef targets the correct Gateway object, for example:

  • Team A instance: team_a_gateway in the gateway_system namespace.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top