diff --git a/content/operate/kubernetes/active-active/create-reaadb.md b/content/operate/kubernetes/active-active/create-reaadb.md index 337093aa39..30db82d4c9 100644 --- a/content/operate/kubernetes/active-active/create-reaadb.md +++ b/content/operate/kubernetes/active-active/create-reaadb.md @@ -24,10 +24,12 @@ To create an Active-Active database, make sure you've completed all the followin * Name of each REC (``) * Namespace for each REC (``) -3. Configure the REC [`ingressOrRoutes` field](/content/operate/kubernetes/networking/ingressorroutespec.md) and [create DNS records](/content/operate/kubernetes/networking/ingressorroutespec.md#configure-dns/). +3. Configure the REC [`ingressOrRouteSpec` field](/content/operate/kubernetes/networking/ingressorroutespec.md) and [create DNS records](/content/operate/kubernetes/networking/ingressorroutespec.md#configure-dns/). * REC API hostname (`api--.`) * Database hostname suffix (`.db--.`) + To use the Kubernetes Gateway API instead, see [Expose Active-Active databases](/content/operate/kubernetes/networking/gateway-api.md#expose-active-active-databases). + 4. [Prepare participating clusters](/content/operate/kubernetes/active-active/prepare-clusters.md) * RERC name (`) * RERC secret name (`redis-enterprise-`) @@ -50,6 +52,8 @@ Example RERC (`rerc-raegan`) for the REC named `rec-arlington` in the namespace For more details on RERC fields, see the [RERC API reference](/content/operate/kubernetes/reference/api/redis_enterprise_remote_cluster_api.md). +If you use [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md#expose-active-active-databases), also set `replicationPort` in each RERC. + 2. Create a Redis Enterprise remote cluster from each RERC custom resource file. ```sh diff --git a/content/operate/kubernetes/active-active/edit-clusters.md b/content/operate/kubernetes/active-active/edit-clusters.md index b1a8da9215..0341dccb1e 100644 --- a/content/operate/kubernetes/active-active/edit-clusters.md +++ b/content/operate/kubernetes/active-active/edit-clusters.md @@ -91,6 +91,8 @@ To communicate with other clusters, all participating clusters need access to th secretName: redis-enterprise-rerc-logan ``` + If your participating clusters use [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md#expose-active-active-databases), also set `replicationPort` in the RERC. + 1. Create the RERC custom resource. ```sh diff --git a/content/operate/kubernetes/active-active/edit-rerc.md b/content/operate/kubernetes/active-active/edit-rerc.md index acfec81d64..a134348265 100644 --- a/content/operate/kubernetes/active-active/edit-rerc.md +++ b/content/operate/kubernetes/active-active/edit-rerc.md @@ -30,6 +30,8 @@ kubectl patch rerc rerc-ohare --type merge --patch \ '{"spec":{"dbFqdnSuffix": ".example2-cluster-rec-chicago-ns-illinois.example.com"}}' ``` +The `replicationPort` field, used for [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md#expose-active-active-databases), is an exception. Set it on every copy of the RERC, on every participating cluster, not only on the local RERC. + ## Update RERC secret If the credentials are changed or updated for a REC participating cluster, you need to manually edit the RERC secret and apply it to all participating clusters. diff --git a/content/operate/kubernetes/active-active/prepare-clusters.md b/content/operate/kubernetes/active-active/prepare-clusters.md index 58ca79c27b..57016f3cc8 100644 --- a/content/operate/kubernetes/active-active/prepare-clusters.md +++ b/content/operate/kubernetes/active-active/prepare-clusters.md @@ -21,10 +21,12 @@ Before you prepare your clusters to participate in an Active-Active database, ma * Name of each REC (``) * Namespace for each REC (``) -3. Configure the REC [`ingressOrRoutes` field](/content/operate/kubernetes/networking/ingressorroutespec.md) and [create DNS records](/content/operate/kubernetes/networking/ingressorroutespec.md#configure-dns/). +3. Configure the REC [`ingressOrRouteSpec` field](/content/operate/kubernetes/networking/ingressorroutespec.md) and [create DNS records](/content/operate/kubernetes/networking/ingressorroutespec.md#configure-dns/). * REC API hostname (`api--.`) * Database hostname suffix (`.db--.`) + To use the Kubernetes Gateway API instead, see [Expose Active-Active databases](/content/operate/kubernetes/networking/gateway-api.md#expose-active-active-databases). Gateway API routing also requires `replicationPort` in each RedisEnterpriseRemoteCluster (RERC). + Next you'll [collect credentials](#collect-rec-credentials) for your participating clusters and create secrets for the RedisEnterprsieRemoteCluster (RERC) to use. For a list of example values used throughout this article, see the [Example values](#example-values) section. diff --git a/content/operate/kubernetes/architecture/_index.md b/content/operate/kubernetes/architecture/_index.md index 1382bbd12c..c2f592efde 100644 --- a/content/operate/kubernetes/architecture/_index.md +++ b/content/operate/kubernetes/architecture/_index.md @@ -125,8 +125,9 @@ By default, Kubernetes doesn't allow you to access your Redis database from outs - Ingress controllers [HAProxy](https://haproxy-ingress.github.io/) and [NGINX](https://kubernetes.github.io/ingress-nginx/) require an `ingress` API resource. - [Istio](https://istio.io/latest/docs/setup/getting-started/) requires `Gateway` and `VirtualService` API resources. - OpenShift uses [routes](/content/operate/kubernetes/networking/routes.md) to route external traffic. +- The [Kubernetes Gateway API](/content/operate/kubernetes/networking/gateway-api.md) uses `TLSRoute` resources that the operator attaches to a Gateway you own. -The [Active-Active databases](#active-active-databases) require one of above routing methods to be configured in the REC with the [ingressOrRouteSpec field](/content/operate/kubernetes/reference/api/redis_enterprise_cluster_api.md#specingressorroutespec). +The [Active-Active databases](#active-active-databases) require routing configured in the REC, either with the [ingressOrRouteSpec field](/content/operate/kubernetes/reference/api/redis_enterprise_cluster_api.md#specingressorroutespec) or with [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md). ## Services Rigger diff --git a/content/operate/kubernetes/networking/_index.md b/content/operate/kubernetes/networking/_index.md index fb25199d78..839e5b800d 100644 --- a/content/operate/kubernetes/networking/_index.md +++ b/content/operate/kubernetes/networking/_index.md @@ -29,9 +29,10 @@ Choose the appropriate method for your environment to enable external access: ## Automatic ingress configuration -For Active-Active databases, configure automatic ingress creation: +For Active-Active databases and the cluster API, the operator can create routes for you: - [REC external routing](/content/operate/kubernetes/networking/ingressorroutespec.md) - Use `ingressOrRouteSpec` field in RedisEnterpriseCluster (REC) for automatic ingress creation +- [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md) - Use the `spec.gateway` field in the REC to attach `TLSRoute` resources to a Kubernetes Gateway that you own. Also exposes the Cluster Manager UI and metrics endpoints. ## `ingressOrRouteSpec` for Active-Active databases diff --git a/content/operate/kubernetes/networking/database-connectivity.md b/content/operate/kubernetes/networking/database-connectivity.md index 158c1af53a..87d1f90204 100644 --- a/content/operate/kubernetes/networking/database-connectivity.md +++ b/content/operate/kubernetes/networking/database-connectivity.md @@ -107,7 +107,7 @@ auth ## External database access -To access databases from outside the Kubernetes cluster, you need to configure external routing. Currently supported methods for external access are ingress controllers or OpenShift routes. +To access databases from outside the Kubernetes cluster, you need to configure external routing. Currently supported methods for external access are ingress controllers or OpenShift routes. Active-Active databases can also use [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md). ### Ingress controllers diff --git a/content/operate/kubernetes/networking/gateway-api.md b/content/operate/kubernetes/networking/gateway-api.md new file mode 100644 index 0000000000..36359714da --- /dev/null +++ b/content/operate/kubernetes/networking/gateway-api.md @@ -0,0 +1,288 @@ +--- +Title: Route external traffic with Gateway API +alwaysopen: false +categories: +- docs +- operate +- kubernetes +description: Expose the cluster API, Cluster Manager UI, metrics, and Active-Active databases through a Kubernetes Gateway. +linkTitle: Gateway API routing +weight: 35 +--- + +Redis Software for Kubernetes can expose your RedisEnterpriseCluster (REC) endpoints and Active-Active databases through the [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/). You add a `spec.gateway` section to the REC, and the operator creates a `TLSRoute` for each exposed endpoint and attaches it to a Gateway that you own. The operator never creates or changes the Gateway itself. + +Traffic uses TLS passthrough. The Gateway routes each connection by its Server Name Indication (SNI) hostname and never terminates TLS, so one Gateway listener can serve many endpoints. + +You can expose the following through Gateway API: + +- The cluster API +- The Cluster Manager UI +- The metrics endpoint +- Active-Active databases (REAADB) + +Regular databases (REDB) can't be exposed through Gateway API. To expose them, use [Ingress routing](/content/operate/kubernetes/networking/ingress.md), [Istio ingress routing](/content/operate/kubernetes/networking/istio-ingress.md), or [OpenShift routes](/content/operate/kubernetes/networking/routes.md). + +## Prerequisites + +Before you configure Gateway API routing, you need: + +- Gateway API custom resource definitions (CRDs) version 1.5 or later, installed from the standard channel. The operator requires `TLSRoute` v1, which earlier versions don't provide. +- A Gateway controller that supports `TLSRoute` with TLS passthrough. +- A Gateway with listeners that use protocol `TLS` and TLS mode `Passthrough`. +- Gateway listeners that accept routes from the REC namespace. By default, a listener accepts routes only from the Gateway's own namespace. If the Gateway is in another namespace, set `allowedRoutes.namespaces.from` to `All`, or to `Selector` with a selector that matches the REC namespace. Otherwise, the Gateway rejects every route with reason `NotAllowedByListeners`. +- DNS records that resolve each fully qualified domain name (FQDN) you expose to the Gateway's address. For Active-Active databases, every participating cluster must also be able to resolve these names, because replication traffic uses them. + +The following example shows the listeners of a Gateway that uses one listener for the cluster endpoints and one for databases: + +```yaml +spec: + listeners: + - name: https + port: 443 + protocol: TLS + tls: + mode: Passthrough + allowedRoutes: + namespaces: + from: All + - name: redis-tls + port: + protocol: TLS + tls: + mode: Passthrough + allowedRoutes: + namespaces: + from: All +``` + +## Set cluster-wide defaults + +Use `spec.gateway.default` to set values that every exposed endpoint inherits: + +- `gatewayRef`: The `name` and `namespace` of the Gateway to attach routes to. If you omit `namespace`, the operator uses the REC namespace. +- `fqdnSuffix`: The DNS suffix the operator uses to build each endpoint's hostname. +- `routeLabels` and `routeAnnotations`: Metadata to add to every route. See [Add labels and annotations to routes](#add-labels-and-annotations-to-routes). + +Each endpoint section can set its own `gatewayRef`, which overrides the default. + +## Expose the cluster API, UI, and metrics + +The `spec.gateway.api`, `spec.gateway.ui`, and `spec.gateway.metrics` sections each expose one cluster endpoint. All three are off by default. Each section supports these fields: + +- `enabled`: Set to `true` to expose the endpoint. +- `fqdn`: The endpoint's hostname. If you omit it, the operator uses `api.`, `ui.`, or `metrics.`. +- `listenerName`: The Gateway listener to attach to. It maps to the route's `parentRef.sectionName`. If you omit it, the Gateway controller selects a compatible listener. +- `listenerPort`: The Gateway listener port. It maps to the route's `parentRef.port`. +- `gatewayRef`, `routeLabels`, and `routeAnnotations`: Per-endpoint overrides of the defaults. + +To expose the cluster endpoints: + +1. Create a patch file, replacing the `` with your own values. + + ```yaml + spec: + gateway: + default: + gatewayRef: + name: + namespace: + fqdnSuffix: + api: + enabled: true + listenerName: https + listenerPort: 443 + ui: + enabled: true + listenerName: https + listenerPort: 443 + metrics: + enabled: true + listenerName: https + listenerPort: 443 + ``` + +1. Apply the patch to the REC. + + ```sh + kubectl patch rec --type merge --patch-file + ``` + +1. Confirm that the operator created the routes. They're named `-api`, `-ui`, and `-metrics`. + + ```sh + kubectl get tlsroute -n + ``` + +1. Test access to the cluster API through the Gateway. + + ```sh + curl -k -u ":" https://api./v1/cluster + ``` + + The `-k` option skips certificate verification for this test. The REC admin credentials are stored in a secret named after the REC. See [Connect to the admin console](/content/operate/kubernetes/re-clusters/connect-to-admin-console.md). + +> [!NOTE] +> - The UI endpoint requires the Cluster Manager server. If `spec.servicesConfiguration.cmServer.operatingMode` is set to `disabled`, enabling `spec.gateway.ui` makes the REC spec invalid. +> - Enabling `spec.gateway.metrics` changes the metrics service from a headless service to a ClusterIP service so that the Gateway can route to it. The service stays ClusterIP if you later turn off the metrics endpoint. + +## Expose Active-Active databases + +The `spec.gateway.activeActiveDatabases` section exposes Active-Active databases. Each exposed database gets one route, and that route carries both client traffic and replication traffic between participating clusters. Configure this section on every participating REC. + +The section supports these fields: + +- `autoEnable`: Which Active-Active databases to expose. `None` (the default) exposes none, `All` exposes every Active-Active database on the cluster, and `Selector` exposes databases whose labels match `selector`. +- `selector`: A label selector, required when `autoEnable` is `Selector`. +- `fqdnSuffix`: The DNS suffix for database hostnames. A database's hostname is `.`. If you omit it, the hostname is `.crdb.`. +- `listenerName` and `listenerPort`: The Gateway listener for databases. +- `gatewayRef`, `routeLabels`, and `routeAnnotations`: Overrides of the defaults. + +Active-Active databases are configured only at the REC level. The REAADB has no Gateway settings of its own. + +Each participating cluster needs its own `fqdnSuffix`, so that each database hostname is unique to its cluster and SNI routes it to the right cluster. + +To expose Active-Active databases: + +1. On each participating cluster, patch the REC with an `activeActiveDatabases` section, replacing the `` with your own values. This example also exposes the cluster API, so that participating clusters can reach each other's API through the Gateway. + + ```yaml + spec: + gateway: + default: + gatewayRef: + name: + namespace: + fqdnSuffix: + api: + enabled: true + listenerName: https + listenerPort: 443 + activeActiveDatabases: + autoEnable: Selector + selector: + matchLabels: + : "" + fqdnSuffix: + listenerName: redis-tls + ``` + + ```sh + kubectl patch rec --type merge --patch-file + ``` + +1. Set `spec.replicationPort` on every RedisEnterpriseRemoteCluster (RERC), on every participating cluster. This is typically the same port as the database listener on the Gateway of the cluster that the RERC describes. One port serves all Active-Active databases on that cluster; the Gateway tells them apart by SNI. + + ```sh + kubectl patch rerc --type merge --patch '{"spec":{"replicationPort": }}' + ``` + + Unlike `apiFqdnUrl`, you can edit `replicationPort` on any copy of an RERC, not only on the RERC's local cluster. + +1. If `autoEnable` is `Selector`, label each existing database on every participating cluster. + + ```sh + kubectl label reaadb = + ``` + +1. Confirm that each cluster created a route for the database. The route is named after the database. + + ```sh + kubectl get tlsroute -n + ``` + +A database you create after you enable Gateway exposure needs the label on the cluster where you create it, as long as the following conditions hold: + +- That cluster's RERC for each peer has `replicationPort` set and no `externalReplicationPort`. +- Each peer REC uses `autoEnable: Selector`. + +The operator then creates the route on each peer cluster automatically. + +If the REAADB is in a consumer namespace, its route name and hostname use `-` in place of the database name. + +To test the database, write a key through one cluster's Gateway and read it through another's. Use each cluster's database hostname as both the host and the SNI value. This example uses a client certificate and key, which you need only if the database requires client authentication. The `--insecure` option skips certificate verification for the test. + +```sh +redis-cli --tls --insecure --cert --key \ + --sni -h \ + -p SET + +redis-cli --tls --insecure --cert --key \ + --sni -h \ + -p GET +``` + +## Add labels and annotations to routes + +Use `routeLabels` and `routeAnnotations` to add metadata to the routes the operator creates, for example an annotation that an external DNS controller reads. You can set them in `spec.gateway.default`, in each endpoint section, and in `spec.gateway.activeActiveDatabases`. Values in an endpoint section are merged over the defaults and win on key conflicts. + +```yaml +spec: + gateway: + api: + enabled: true + routeAnnotations: + external-dns.alpha.kubernetes.io/hostname: api. +``` + +Labels the operator manages always take precedence over your labels. The operator doesn't apply labels with the keys `role` or `bdb`. + +## Check route status + +The REC status reports each cluster endpoint under `status.gateway.api`, `status.gateway.ui`, and `status.gateway.metrics`, with the endpoint's `fqdn`, `routeName`, and `conditions`. + +```sh +kubectl describe rec +``` + +A healthy endpoint has a condition of type `Ready` with status `True` and reason `RouteReady`, and the message `TLSRoute is accepted and its backend references are resolved`. + +For Active-Active databases, the REAADB status shows the endpoint each participating cluster advertises to its peers, under `status.participatingClusters[].replicationEndpoint`. A cluster that uses Gateway API advertises `:`. + +```sh +kubectl get reaadb -o jsonpath='{.status.participatingClusters}' +``` + +Events with reason `GatewayEndpointCutover` on the REAADB show when a cluster is waiting for its route to be accepted and when it switches its advertised endpoint to the Gateway. + +```sh +kubectl get events --field-selector involvedObject.name= +``` + +## Troubleshooting + +| What you see | What it means | What to do | +| --- | --- | --- | +| REC endpoint condition reason `RoutePending`, message `Waiting for the Gateway controller to report route readiness` | The route exists, but the Gateway controller hasn't reported on it yet. | Check that `gatewayRef` names an existing Gateway and that your Gateway controller is running. | +| REC endpoint condition reason `RouteNotReady`, or a reason reported by the Gateway controller | The Gateway didn't accept the route, or the route's backend didn't resolve. | Check the route's `Accepted` and `ResolvedRefs` conditions with `kubectl get tlsroute -o yaml`. | +| REC spec is invalid, with a message that names a `spec.gateway` field | A `spec.gateway` setting can't be resolved, for example an enabled endpoint with no hostname or no Gateway. | Fix the field the message names. | +| REC endpoint condition reason `RouteReconcileFailed` | The operator couldn't create or update the route. | Read the condition message for the cause. | +| REC endpoint condition reason `GatewayAPIUnavailable`, message `Gateway API TLSRoute v1 is not available; the operator requires Gateway API >= 1.5 (standard channel)` | The `TLSRoute` v1 CRD isn't installed. | Install Gateway API CRDs version 1.5 or later from the standard channel. | +| REAADB warning event reason `ParticipatingClusterRERCStatus`, message ending `does not set spec.replicationPort; gateway exposure is pending` | The database is selected for Gateway exposure, but an RERC has no `replicationPort`. If the database has an existing exposure method, it keeps serving through it. If it has none, this is an error. | Set `spec.replicationPort` on every RERC, on every participating cluster. | +| REAADB warning event reason `MissingOrInvalidLinkedRERC`, or a rejected `kubectl apply`, with a message containing `equals the legacy dbFqdnSuffix-derived FQDN` | During migration, the database's Gateway hostname is the same as its existing hostname, so the two can't be told apart. | Set `spec.gateway.activeActiveDatabases.fqdnSuffix` to a suffix that differs from the RERC `dbFqdnSuffix`. | +| REAADB warning event reason `MissingOrInvalidLinkedRERC`, or a rejected `kubectl apply`, with a message containing `refusing to tear down the gateway route` | You turned off Gateway exposure for a database on a cluster that has no other way to expose it. The route stays in place so replication keeps working. | Select the database for Gateway exposure again, or configure another exposure method on that cluster first. | + +## Migrate from ingressOrRouteSpec + +Gateway API routing works alongside an existing [`ingressOrRouteSpec`](/content/operate/kubernetes/networking/ingressorroutespec.md) configuration, so you can migrate without downtime. Both methods serve traffic during the migration, and each cluster switches each database to the Gateway only after its route is ready. Clusters switch independently. + +1. Upgrade the operator on all participating clusters. + +1. Set `spec.replicationPort` on every RERC, on every participating cluster. + +1. On each REC, add `spec.gateway`. Use `autoEnable: Selector` to migrate one database at a time, or `All` to migrate every database. The Gateway hostnames must differ from your existing `dbFqdnSuffix` hostnames. + +1. If you use `Selector`, label each database on every participating cluster. + +1. Wait for each cluster to switch. A `GatewayEndpointCutover` event marks the switch, and the REAADB `replicationEndpoint` changes to the Gateway hostname. Move your Redis clients to the Gateway hostnames at any time; both methods serve traffic. + +1. To move the API traffic between participating clusters, expose the cluster API through the Gateway. Then, one cluster at a time, update `apiFqdnUrl` in that cluster's local RERC to its Gateway API hostname. Wait for the REAADBs to return to `active` before you update the next cluster. + +1. Remove `spec.ingressOrRouteSpec` from the REC last. + +> [!WARNING] +> Removing `spec.ingressOrRouteSpec` deletes every Ingress or route the operator created for the REC at once, including the API route and every database route. Remove it only after all clients and participating clusters use the Gateway hostnames. + +To roll back a database before you remove `spec.ingressOrRouteSpec`, remove its label, or set `autoEnable` to `None`. The operator deletes the database's route and returns to advertising the existing endpoint. + +If a cluster exposes Active-Active databases through load balancer services with `externalReplicationPort` instead of `ingressOrRouteSpec`, you can migrate the same way. Keep `externalReplicationPort` set while the Gateway route becomes ready, and remove it after the cluster switches. This works only while the REC's `spec.servicesRiggerSpec.databaseServiceType` includes `load_balancer`. A REC with `ingressOrRouteSpec` can't combine `externalReplicationPort` with Gateway exposure. diff --git a/content/operate/kubernetes/networking/ingress.md b/content/operate/kubernetes/networking/ingress.md index 009b412912..5d0668fb0c 100644 --- a/content/operate/kubernetes/networking/ingress.md +++ b/content/operate/kubernetes/networking/ingress.md @@ -14,6 +14,8 @@ weight: 5 > [!WARNING] > The community [Ingress-NGINX controller](https://github.com/kubernetes/ingress-nginx) (`kubernetes/ingress-nginx`) is retired. Best-effort maintenance ended in March 2026 and the project no longer ships releases, bug fixes, or security updates. If you are not already using it, use HAProxy or Istio as shown below. +To expose Active-Active databases and cluster endpoints through the Kubernetes Gateway API, see [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md). + ## Prerequisites Before creating an Ingress, you'll need: diff --git a/content/operate/kubernetes/networking/ingressorroutespec.md b/content/operate/kubernetes/networking/ingressorroutespec.md index c1bb7f0afa..324490623f 100644 --- a/content/operate/kubernetes/networking/ingressorroutespec.md +++ b/content/operate/kubernetes/networking/ingressorroutespec.md @@ -14,6 +14,8 @@ An Ingress is an API resource that provides a standardized and flexible way to m > [!WARNING] > The community [Ingress-NGINX controller](https://github.com/kubernetes/ingress-nginx) (`kubernetes/ingress-nginx`) is retired. Best-effort maintenance ended in March 2026 and the project no longer ships releases, bug fixes, or security updates. If you are not already using it, use HAProxy or Istio. +To use the Kubernetes Gateway API instead, see [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md). It covers [migrating from `ingressOrRouteSpec`](/content/operate/kubernetes/networking/gateway-api.md#migrate-from-ingressorroutespec) without downtime. + ## Install Ingress controller Redis Enterprise for Kubernetes supports the Ingress controllers below: diff --git a/content/operate/kubernetes/networking/routes.md b/content/operate/kubernetes/networking/routes.md index ea74ebca6a..b009f8cd5c 100644 --- a/content/operate/kubernetes/networking/routes.md +++ b/content/operate/kubernetes/networking/routes.md @@ -12,6 +12,8 @@ weight: 15 OpenShift routes allow requests to be routed to the database or cluster API from outside the cluster. For more information about routes, see [OpenShift documentation](https://docs.openshift.com/container-platform/4.13/networking/routes/route-configuration.html). +To expose Active-Active databases and cluster endpoints through the Kubernetes Gateway API, see [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md). + ## Prerequisites * Before you can connect to your database from outside the cluster, you'll need the root CA certificate of the DMC Proxy server to validate the server certificate. diff --git a/content/operate/kubernetes/re-clusters/connect-to-admin-console.md b/content/operate/kubernetes/re-clusters/connect-to-admin-console.md index 91e00afd44..489753c390 100644 --- a/content/operate/kubernetes/re-clusters/connect-to-admin-console.md +++ b/content/operate/kubernetes/re-clusters/connect-to-admin-console.md @@ -14,7 +14,7 @@ weight: 10 The username and password for the Redis Enterprise Software [admin console](/content/operate/rs/_index.md) are stored in a Kubernetes [secret](https://kubernetes.io/docs/concepts/configuration/secret/). After retrieving your credentials, you can use port forwarding to connect to the admin console. > [!NOTE] -> There are several methods for accessing the admin console. Port forwarding is the simplest, but not the most efficient method for long-term use. You could also use a load balancer service or Ingress. +> There are several methods for accessing the admin console. Port forwarding is the simplest, but not the most efficient method for long-term use. You could also use a load balancer service, Ingress, or [Gateway API routing](/content/operate/kubernetes/networking/gateway-api.md#expose-the-cluster-api-ui-and-metrics). 1. Switch to the namespace with your Redis Enterprise cluster (REC).