Install
Use Helm to customize your setup of Gloo Gateway in a single cluster.
In a single-cluster setup, you install the Gloo Gateway management plane and gateway proxy together, as shown in the following diagram.
- Gloo Gateway management plane: When you install the Gloo Gateway management plane, a deployment named
gloo-mesh-mgmt-server
is created to translate and implement your Gloo configurations. Because you include theglooAgent.enabled: true
setting in the installation values file, the cluster is also registered to be managed by Gloo. A deployment namedgloo-mesh-agent
is created to run the Gloo agent as part of the Gloo Gateway data plane. - Gateway proxy: Use the Gloo Gateway management plane to install an ingress gateway proxy in your cluster, as part of the Istio lifecycle management. By using a Gloo-managed installation, you no longer need to manually install and manage the
istiod
control plane and gateway proxy. Instead, you provide the Istio configuration in yourgloo-platform
Helm chart, and Gloo translates this configuration into a managedistiod
control plane and gateway proxy in the cluster.
To use a dedicated cluster for your Gloo Gateway management plane, and install gateway proxies in one or more workload clusters instead, see the Multicluster setup guide.
Before you begin
-
Create or use an existing Kubernetes or OpenShift cluster, and save the name of the cluster as an environment variable. Note: The cluster name must be alphanumeric with no special characters except a hyphen (-), lowercase, and begin with a letter (not a number).
export CLUSTER_NAME=<cluster_name>
-
Set your Gloo Gateway license key as an environment variable. If you do not have one, contact an account representative. If you prefer to specify license keys in a secret instead, see Licensing.
export GLOO_GATEWAY_LICENSE_KEY=<gloo-gateway-license-key>
To check your license's validity, you can run
meshctl license check --key $(echo ${GLOO_GATEWAY_LICENSE_KEY} | base64 -w0)
. -
Set the Gloo Gateway version as an environment variable. The latest version is used as an example. You can find other versions in the Changelog documentation. Append ‘-fips’ for a FIPS-compliant image, such as ‘2.5.3-fips’. Do not include
v
before the version number.export GLOO_VERSION=2.5.3
-
Install the following CLI tools:
helm
, the Kubernetes package manager.meshctl
, the Gloo command line tool for bootstrapping Gloo Platform, registering clusters, describing configured resources, and more. Be sure to download version2.5.3
, which uses the latest Gloo Gateway CRDs.kubectl
, the Kubernetes command line tool. Download thekubectl
version that is within one minor version of the Kubernetes cluster you plan to use.- OpenShift only:
oc
, the OpenShift command line tool. Download theoc
version that is the same minor version of the OpenShift cluster you plan to use.
-
Production installations: Review Best practices for production to prepare your security measures. For example, before you begin your Gloo installation, you can provide your own certificates and set up secure access to the Gloo UI.
Install Gloo Gateway with Helm
Customize your Gloo setup by installing with the Gloo Platform Helm chart.
-
Add and update the Helm repository for Gloo Platform.
helm repo add gloo-platform https://storage.googleapis.com/gloo-platform/helm-charts helm repo update
-
Apply the Gloo Platform CRDs to your cluster by creating a
gloo-platform-crds
Helm release. Note: If you plan to manually deploy and manage your Istio installation in workload clusters rather than using Solo's Istio lifecycle manager, include the--set installIstioOperator=false
flag to ensure that the Istio operator CRD is not managed by this Gloo CRD Helm release.helm install gloo-platform-crds gloo-platform/gloo-platform-crds \ --namespace=gloo-mesh \ --create-namespace \ --version $GLOO_VERSION
-
Prepare a Helm values file for production-level settings, including FIPS-compliant images, OIDC authorization for the Gloo UI, and more. To get started, you can use the minimum settings in the
gloo-gateway-single
profile as a basis for your values file. This profile enables all of the necessary components that are required for a single-cluster Gloo Gateway installation, such as the management server, agent, and gateway proxy, as well as some optional components, such as the Gloo UI.curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/gloo-gateway-single.yaml > gloo-gateway-single.yaml open gloo-gateway-single.yaml
For more information, see the Istio on OpenShift documentation.
- Elevate the permissions of the following service accounts that will be created. These permissions allow the ingress gateway proxy to make use of a user ID that is normally restricted by OpenShift.
oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh-gateways # Update revision as needed oc adm policy add-scc-to-group anyuid system:serviceaccounts:gm-iop-1-20
- Create the
gloo-mesh-gateways
project, and create a NetworkAttachmentDefinition custom resource for the project.kubectl create ns gloo-mesh-gateways cat <<EOF | oc -n gloo-mesh-gateways create -f - apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: istio-cni EOF
- Elevate the permissions of the service account in each project where you want to deploy workloads.
oc adm policy add-scc-to-group anyuid system:serviceaccounts:<project>
- Create a NetworkAttachmentDefinition custom resource for each project where you want to deploy workloads.
cat <<EOF | oc -n <project> create -f - apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: istio-cni EOF
- Download the
gloo-gateway-single-openshift
profile as a basis for your values file.curl https://storage.googleapis.com/gloo-platform/helm-profiles/$GLOO_VERSION/gloo-gateway-single-openshift.yaml > gloo-gateway-single.yaml open gloo-gateway-single.yaml
Note: When you use the settings in this profile to install Gloo Gateway in OpenShift 4.11 and later, you might see warnings for the pods and containers which violate the OpenShift
PodSecurity "restricted:v1.24"
profile, due to the elevated permissions required by Istio. You can ignore these warnings. For more info, see this article.
- Elevate the permissions of the following service accounts that will be created. These permissions allow the ingress gateway proxy to make use of a user ID that is normally restricted by OpenShift.
-
Decide how you want to secure the relay connection between the Gloo management server and agent. In test and POC environments, you can use Gloo Gateway self-signed certificates to secure the connection. If you plan to use Gloo Gateway in production, it is recommended to bring your own certificates instead. For more information, see Setup options.
- TLS: Self-signed server cert
- TLS: BYO server cert
- mTLS: Self-signed certs
- mTLS: BYO certs with rotation
- mTLS: BYO certs without rotation
Use Gloo Gateway to create a self-signed server TLS certificate that the Gloo management server presents when the Gloo agent connects. This setup is not recommended for production, but can be used for testing purposes. For more information, see Self-signed server TLS certificate.
In your Helm values file, add the following values.
glooMgmtServer: serviceType: ClusterIP registerCluster: true enabled: true extraEnvs: RELAY_TOKEN: value: "My token" RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION: value: "true" glooAgent: enabled: true relay: serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900 extraEnvs: RELAY_TOKEN: value: "My token" RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION: value: "true"
Helm value Description glooMgmtServer.extraEnvs.RELAY_TOKEN
Specify the relay token that the Gloo management server and agent use to establish initial trust. When you install Gloo Gateway and set RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION
to true, the connection between the Gloo management server and agent is automatically secured by using simple, server-side TLS. In a simple TLS setup, only the management server presents a certificate to authenticate its identity. The identity of the agent is not verified. To ensure that only trusted agents connect to the management server, the relay identity token is used. The relay identity token can be any string value and is stored in therelay-identity-token-secret
Kubernetes secret. You must set the same value inglooAgent.extraEnvs.RELAY_TOKEN.value
to allow the Gloo agent to connect to the Gloo management server.glooMgmtServer.extraEnvs.
RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION
Set this value to true to not require a client TLS certificate from the Gloo agent to prove the agent's identity and establish the connection with the management server. This setting is required when you want to use simple TLS to secure the connection between the Gloo management server and agent. glooAgent.extraEnvs.RELAY_TOKEN
Use the same value that you set in glooMgmtServer.extraEnvs.RELAY_TOKEN
.glooAgent.extraEnvs.
RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION
Set to true to skip validating the server TLS certificate that the Gloo management server presents. This setting is required to configure the relay connection for TLS. Use your preferred PKI provider to create the server TLS certificate for the Gloo management server. For more information, see Bring your own server TLS certificate.
- Create your root CA credentials and derive the server TLS certificate and certificate chain information. To create the TLS certificate, you can use your preferred PKI provider or follow the steps in Step 1: Create the server TLS and telemetry certificates to create a custom server TLS certificate by using OpenSSL. Store this information in the following secrets in the
gloo-mesh
namespace.relay-server-tls-secret-custom
: The key and TLS certificate for the Gloo management server, and root CA certificate information for the certificate chain. Note that you can use a different name, but you cannot userelay-server-tls-secret
as this name is reserved by the Gloo management server when creating self-signed root CAs and server TLS certificates.telemetry-root-secret
: The root CA certificate for the certificate chain.
- In your Helm values file, add the following values.
glooMgmtServer: serviceType: ClusterIP registerCluster: true enabled: true relay: tlsSecret: name: relay-server-tls-secret-custom namespace: gloo-mesh extraEnvs: RELAY_TOKEN: value: "My token" RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION: value: "true" glooAgent: enabled: true relay: serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900 extraEnvs: RELAY_TOKEN: value: "My token" RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION: value: "true" telemetryCollector: enabled: true extraVolumes: - name: root-ca secret: defaultMode: 420 optional: true secretName: telemetry-root-secret - configMap: items: - key: relay path: relay.yaml name: gloo-telemetry-collector-config name: telemetry-configmap - hostPath: path: /var/run/cilium type: DirectoryOrCreate name: cilium-run
Helm value Description glooMgmtServer.relay.tlsSecret.name
The name and namespace of the Kubernetes secret where you stored your custom server TLS certificate. glooMgmtServer.extraEnvs.RELAY_TOKEN
Specify the relay token that the Gloo management server and agent use to establish initial trust. When you install Gloo Gateway and set RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION
to true, the connection between the Gloo management server and agent is automatically secured by using simple, server-side TLS. In a simple TLS setup, only the management server presents a certificate to authenticate its identity. The identity of the agent is not verified. To ensure that only trusted agents connect to the management server, the relay identity token is used. The relay identity token can be any string value and is stored in therelay-identity-token-secret
Kubernetes secret on the management cluster. You must set the same value inglooAgent.extraEnvs.RELAY_TOKEN.value
to allow the Gloo agent to connect to the Gloo management server.glooMgmtServer.extraEnvs.
RELAY_DISABLE_CLIENT_CERTIFICATE_AUTHENTICATION
Set this value to true to not require a client TLS certificate from the Gloo agent to prove the agent's identity and establish the connection with the management server. glooAgent.extraEnvs.
RELAY_DISABLE_SERVER_CERTIFICATE_VALIDATION
Set to true to skip validating the server TLS certificate that the Gloo management server presents. This setting is required to configure the relay connection for TLS. telemetryCollector.extraVolumes
Add the telemetry-root-secret
Kubernetes secret that you created earlier to theroot-ca
volume. Make sure that you also add the other volumes to your telemetry collector configuration.
You can use Gloo to generate self-signed certificates and keys for the root and intermediate CA. These credentials are used to derive the server TLS certificate for the Gloo management server and client TLS certificate for the Gloo agent. Note that this setup is not recommended for production, but can be used for testing purposes. For more information, see Self-signed CAs with automatic client certificate rotation.
In your Helm values file, add the following values. Note that mTLS is the default mode in Gloo Gateway and does not require any additional configuration.
glooMgmtServer: enabled: true glooAgent: enabled: true
Use your preferred PKI provider to generate your root CA and intermediate CA credentials. You then store the intermediate CA credentials in your cluster so that you can leverage Gloo Gateway's built-in capability to automatically issue and sign the client TLS certificate for the Gloo agent. For more information, see the Bring your own CAs with automatic client TLS certificate rotation.
-
Create your root CA, intermediate CA credentials, server TLS certificate, and relay identity token, and store them as the following Kubernetes secrets in the
gloo-mesh
namespace:relay-root-tls-secret
that holds the root CA key, TLS certificate, and certificate chainrelay-tls-signing-secret
that holds the intermediate CA key, TLS certificate, and certificate chainrelay-server-tls-secret
that holds the server key, TLS certificate, and certificate chain for the Gloo management servertelemetry-root-secret
that holds the certificate chain information for the telemetry collector agentrelay-identity-token-secret
that holds the relay identity token value
You can use your preferred PKI provider to create the TLS certificates or follow the steps in Create TLS certificates with OpenSSL to create the relay identity token and the TLS certificate by using OpenSSL.
-
In your Helm values file, add the following values.
glooMgmtServer: enabled: true registerCluster: true serviceType: ClusterIP relay: disableCaCertGeneration: true signingTlsSecret: name: relay-tls-signing-secret namespace: gloo-mesh tlsSecret: name: relay-server-tls-secret namespace: gloo-mesh tokenSecret: key: token name: relay-identity-token-secret namespace: gloo-mesh glooAgent: enabled: true relay: authority: gloo-mesh-mgmt-server.gloo-mesh serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900 clientTlsSecretRotationGracePeriodRatio: "" rootTlsSecret: name: relay-root-tls-secret namespace: gloo-mesh tokenSecret: key: token name: relay-identity-token-secret namespace: gloo-mesh telemetryCollector: enabled: true extraVolumes: - name: root-ca secret: defaultMode: 420 optional: true secretName: telemetry-root-secret - configMap: items: - key: relay path: relay.yaml name: gloo-telemetry-collector-config name: telemetry-configmap - hostPath: path: /var/run/cilium type: DirectoryOrCreate name: cilium-run
Helm value Description glooMgmtServer.relay.disableCaCertGeneration
Disable the generation of self-signed certificates to secure the relay connection between the Gloo management server and agent. glooMgmtServer.relay.signingTlsSecret
Add the name and namespace of the Kubernetes secret that holds the intermediate CA credentials that you created earlier. glooMgmtServer.relay.tlsSecret
Add the name and namespace of the Kubernetes secret that holds the server TLS certificate for the Gloo management server that you created earlier. glooMgmtServer.relay.tokenSecret
Add the name, namespace, and key of the Kubernetes secret that holds the relay identity token that you created earlier. glooAgent.relay.rootTlsSecret
Add the name and namespace of the Kubernetes secret that holds the root CA credentials that you created earlier. glooAgent.relay.tokenSecret
Add the name, namespace, and key of the Kubernetes secret that holds the relay identity token that you created earlier. telemetryCollector.extraVolumes
Add the telemetry-root-secret
Kubernetes secret that you created earlier to theroot-ca
volume. Make sure that you also add the other volumes to your telemetry collector configuration.
Use your preferred PKI provider to create the root CA, server TLS, and client TLS certificates. Then, store these certificates in the cluster so that the Gloo agent uses a client TLS certificate when establishing the first connection with the Gloo management server. No relay identity tokens are used. With this approach, you cannot use Gloo Gateway's built-in client TLS certificate rotation capabilities. Instead, you must set up your own processes to monitor the expiration of your certificates and to rotate them before they expire. For more information, see Bring your own CAs and client TLS certificates.
-
Create your root CA, server, and client TLS certificates, and store them as the following Kubernetes secrets in the
gloo-mesh
namespace:relay-server-tls-secret
that holdes the server TLS certificate for the Gloo management serverrelay-client-tls-cert
that holds the client TLS certificate for the Gloo agenttelemetry-root-secret
that holds the certificate chain information for the telemetry collector agent
You can use your preferred PKI provider to create the TLS certificates or follow the steps in Create TLS certificates with OpenSSL to create them by using OpenSSL.
-
In your Helm values file for the management server, add the following values.
glooMgmtServer: enabled: true registerCluster: true relay: disableCa: true disableCaCertGeneration: true disableTokenGeneration: true tlsSecret: name: relay-server-tls-secret namespace: gloo-mesh tokenSecret: key: null name: null namespace: null serviceType: ClusterIP glooAgent: enabled: true relay: clientTlsSecret: name: relay-client-tls-cert namespace: gloo-mesh serverAddress: gloo-mesh-mgmt-server.gloo-mesh:9900 tokenSecret: key: null name: null namespace: null telemetryCollector: enabled: true extraVolumes: - name: root-ca secret: defaultMode: 420 optional: true secretName: telemetry-root-secret - configMap: items: - key: relay path: relay.yaml name: gloo-telemetry-collector-config name: telemetry-configmap - hostPath: path: /var/run/cilium type: DirectoryOrCreate name: cilium-run
Helm value Description glooMgmtServer.relay.disableCa
Disable the generation of self-signed root and intermediate CA certificates and the use of identity tokens to establish initial trust between the Gloo management server and agent. glooMgmtServer.relay.disableCaCertGeneration
Disable the generation of self-signed certificates to secure the relay connection between the Gloo management server and agent. glooMgmtServer.relay.disableTokenGeneration
Disable the generation of relay identity tokens. glooMgmtServer.relay.tlsSecret
Add the name and namespace of the Kubernetes secret that holds the server TLS certificate for the Gloo management server that you created earlier. glooMgmtServer.relay.tokenSecret
Set all values to null
to instruct the Gloo management server to not use identity tokens to establish initial trust with Gloo agents.glooAgent.relay.clientTlsSecret
Add the name and namespace of the Kubernetes secret that holds the client TLS certificate for the Gloo agent that you created earlier. glooAgent.tokenSecret
Set all values to null
to instruct the Gloo agent to not use identity tokens to establish initial trust with the Gloo management server.telemetryCollector.extraVolumes
Add the telemetry-root-secret
Kubernetes secret that you created earlier to theroot-ca
volume. Make sure that you also add the other volumes to your telemetry collector configuration.
-
Edit the file to provide your own details for settings that are recommended for production deployments, such as the following optional settings.
Field Decription glooMgmtServer.resources.limits
Add resource limits for the gloo-mesh-mgmt-server
pod, such ascpu: 1000m
andmemory: 1Gi
.glooMgmtServer.serviceOverrides.metadata.annotations
Add annotations for the management server load balancer as needed, such as AWS-specific load balancer annotations. For more information, see Deployment and service overrides. glooUi.auth
Set up OIDC authorization for the Gloo UI. For more information, see UI authentication. istioInstallations
The default supported version of Istio is used to install the managed gateway proxies. You can instead choose the Istio version you want to use for your gateway proxy. For an example of how this section might look, expand “Example: istioInstallations section” after this table. NOTE: To manage the gateway proxies yourself instead of the gateway lifecycle manager in this Helm chart, set istioInstallations.enabled
tofalse
, and manually deploy gateway proxies.prometheus.enabled
Disable the default Prometheus instance as needed to provide your own. Otherwise, you can keep the default Prometheus server enabled, and deploy a production-level server to scrape metrics from the server. For more information on each option, see Customization options. redis
Disable the default Redis deployment and provide your own backing database as needed. For more information, see Backing databases. For more information about the settings you can configure:
- See Best practices for production.
- See all possible fields for the Helm chart by running
helm show values gloo-platform/gloo-platform --version v2.5.3 > all-values.yaml
. You can also see these fields in the Helm values documentation.
-
Install the Gloo Gateway management plane and data plane components in your cluster, including the customizations in your Helm values file.
helm install gloo-platform gloo-platform/gloo-platform \ --namespace gloo-mesh \ --version $GLOO_VERSION \ --values gloo-gateway-single.yaml \ --set common.cluster=$CLUSTER_NAME \ --set licensing.glooGatewayLicenseKey=$GLOO_GATEWAY_LICENSE_KEY
-
Optional: Install add-ons, such as the external auth and rate limit servers, in a separate Helm release. Only create this release if you did not enable the
extAuthService
andrateLimiter
in your main installation release.Want to expose your APIs through a developer portal? You must include some extra Helm settings. To install, see Portal.
helm install gloo-agent-addons gloo-platform/gloo-platform \ --namespace gloo-mesh-addons \ --set common.addonsNamespace=gloo-mesh-addons \ --create-namespace \ --version $GLOO_VERSION \ --set common.cluster=$CLUSTER_NAME \ --set extAuthService.enabled=true \ --set rateLimiter.enabled=true
- Elevate the permissions of the
gloo-mesh-addons
service account that will be created.oc adm policy add-scc-to-group anyuid system:serviceaccounts:gloo-mesh-addons
- Create the
gloo-mesh-addons
project, and create a NetworkAttachmentDefinition custom resource for the project.kubectl create ns gloo-mesh-addons cat <<EOF | oc -n gloo-mesh-addons create -f - apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: istio-cni EOF
- Create the add-ons release.
helm install gloo-agent-addons gloo-platform/gloo-platform \ --namespace gloo-mesh-addons \ --set common.addonsNamespace=gloo-mesh-addons \ --version $GLOO_VERSION \ --set common.cluster=$CLUSTER_NAME \ --set extAuthService.enabled=true \ --set rateLimiter.enabled=true
- Elevate the permissions of the
-
Create a workspace that selects all clusters and namespaces by default, and workspace settings that enable communication across clusters. Gloo workspaces let you organize team resources across Kubernetes namespaces and clusters. In this example, you create a global workspace that imports and exports all resources and namespaces, and a workspace settings resource in the
gloo-mesh-config
namespace. Later, as your teams grow, you can create a workspace for each team, to enforce service isolation, set up federation, and even share resources by importing and exporting.kubectl apply -f- <<EOF apiVersion: admin.gloo.solo.io/v2 kind: Workspace metadata: name: $CLUSTER_NAME namespace: gloo-mesh spec: workloadClusters: - name: '*' namespaces: - name: '*' --- apiVersion: v1 kind: Namespace metadata: name: gloo-mesh-config --- apiVersion: admin.gloo.solo.io/v2 kind: WorkspaceSettings metadata: name: $CLUSTER_NAME namespace: gloo-mesh-config spec: options: serviceIsolation: enabled: false federation: enabled: false serviceSelector: - {} eastWestGateways: - selector: labels: istio: eastwestgateway EOF
Verify the installation
Ensure that Gloo Gateway is successfully installed to your cluster.
-
Verify that Gloo Gateway is correctly installed. This check might take a few seconds to verify that:
- Your Gloo Platform product licenses are valid and current.
- The Gloo Platform CRDs are installed at the correct version.
- The Gloo Gateway pods are running and healthy.
- The Gloo agent is running and connected to the management server.
meshctl check
Example output:
🟢 License status INFO gloo-gateway enterprise license expiration is 25 Aug 24 10:38 CDT INFO Valid GraphQL license module found 🟢 CRD version check 🟢 Gloo deployment status Namespace | Name | Ready | Status gloo-mesh | gloo-mesh-agent | 1/1 | Healthy gloo-mesh | gloo-mesh-mgmt-server | 1/1 | Healthy gloo-mesh | gloo-mesh-redis | 1/1 | Healthy gloo-mesh | gloo-mesh-ui | 1/1 | Healthy gloo-mesh | prometheus-server | 1/1 | Healthy gloo-mesh-addons | ext-auth-service | 1/1 | Healthy gloo-mesh-addons | rate-limiter | 1/1 | Healthy gloo-mesh-addons | redis | 1/1 | Healthy gloo-mesh | gloo-telemetry-collector-agent | 3/3 | Healthy 🟢 Mgmt server connectivity to workload agents Cluster | Registered | Connected Pod cluster1 | true | gloo-mesh/gloo-mesh-mgmt-server-65bd557b95-v8qq6
-
Verify that the gateway proxy service is created and assigned an external IP address. It might take a few minutes for the load balancer to deploy. Note: If you did not deploy a managed gateway proxy through the Helm installation, manually deploy the gateway proxy instead.
kubectl get svc -n gloo-mesh-gateways
Example output:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.XX.X.XXX 34.XXX.XXX.XXX 15021:30826/TCP,80:31257/TCP,443:30673/TCP,15443:30789/TCP 48s
-
Optional: Check out the workspace and workspace settings that were created for you. Workspaces help to organize team resources in your cluster, and to isolate Kubernetes and Gloo Gateway resources. Because the default workspace is used for demonstration purposes, it does not isolate any resources, and instead allows all Kubernetes and Gloo Gateway resources in the workspace.
kubectl get workspace $CLUSTER_NAME -n gloo-mesh -o yaml
kubectl get workspacesettings -n gloo-mesh-config $CLUSTER_NAME -o yaml
If you want to learn more about how to configure workspaces to isolate Kubernetes and Gloo Gateway resources for multiple teams, see the Multitenancy concepts page and the Organize team resources with workspaces guide.
-
Optional for OpenShift: Expose the ingress gateway by using an OpenShift route.
oc -n gloo-mesh-gateways expose svc istio-ingressgateway --port=http2
Next steps
Now that Gloo Gateway is installed, check out the following resources to explore Gloo Gateway capabilities:
- Organize team resources with workspaces.
- Deploy sample apps in your cluster to follow the guides in the documentation.
- Configure HTTP or HTTPS listeners for your gateway.
- Review routing examples, such as header matching, redirects, or direct responses that you can configure for your API Gateway.
- Explore traffic policies that you can apply to your routes and upstream services.
- Learn more about Gloo Gateway and its features in Concepts.