You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: The language around accessing the NGINX Service is outdated after the architecture change.
Solution: Update this language to make it clear how the Service is deployed and accesssed.
Copy file name to clipboardExpand all lines: content/includes/ngf/installation/expose-nginx-gateway-fabric.md
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,32 +4,34 @@ weight: 300
4
4
nd-docs: "DOCS-1427"
5
5
---
6
6
7
-
There are two options for accessing NGINX Gateway Fabric depending on the type of LoadBalancer service you chose during installation:
7
+
When a Gateway resource is created, the NGINX Gateway Fabric control plane will provision an NGINX service in the same namespace as the Gateway. By default, this is a LoadBalancer service. This is not the same service that is deployed when NGINX Gateway Fabric is first installed. The NGINX Gateway Fabric control plane has its own ClusterIP service for internal communication with the NGINX data planes.
8
8
9
-
- If the LoadBalancer type is `NodePort`, Kubernetes will randomly allocate two ports on every node of the cluster.
10
-
To access the NGINX Gateway Fabric, use an IP address of any node of the cluster along with the two allocated ports.
9
+
There are two options for accessing the NGINX service depending on the type of LoadBalancer service you chose during installation:
10
+
11
+
- If the Service type is `NodePort`, Kubernetes will randomly allocate two ports on every node of the cluster.
12
+
To access NGINX, use an IP address of any node of the cluster along with the two allocated ports.
11
13
12
14
{{< call-out "tip" >}} Read more about the type NodePort in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport). {{< /call-out >}}
13
15
14
-
- If the LoadBalancer type is `LoadBalancer`:
16
+
- If the Service type is `LoadBalancer`:
15
17
16
-
- For GCP or Azure, Kubernetes will allocate a cloud load balancer for load balancing the NGINX Gateway Fabric pods.
17
-
Use the public IP of the load balancer to access NGINX Gateway Fabric.
18
+
- For GCP or Azure, Kubernetes will allocate a cloud load balancer for load balancing the NGINX pods.
19
+
Use the public IP of the load balancer to access NGINX.
18
20
- For AWS, Kubernetes will allocate a Network Load Balancer (NLB) in TCP mode with the PROXY protocol enabled to pass
19
21
the client's information (the IP address and the port).
20
22
21
-
Use the public IP of the load balancer to access NGINXGateway Fabric. To get the public IP which is reported in the `EXTERNAL-IP` column:
23
+
Use the public IP of the load balancer to access NGINX. The NGINX Service exists in the same namespace that you deployed your Gateway in, and its name is `<gatewayName-gatewayClassName>`. To get the public IP which is reported in the `EXTERNAL-IP` column:
22
24
23
25
- For GCP or Azure, run:
24
26
25
27
```shell
26
-
kubectl get svc nginx-gateway -n nginx-gateway
28
+
kubectl get svc <gatewayName-gatewayClassName> -n <gateway-namespace>
27
29
```
28
30
29
-
- In AWS, the NLB (Network Load Balancer) DNS (directory name system) name will be reported by Kubernetes instead of a public IP. To get the DNS name, run:
31
+
- In AWS, the NLB (Network Load Balancer) DNS name will be reported by Kubernetes instead of a public IP. To get the DNS name, run:
30
32
31
33
```shell
32
-
kubectl get svc nginx-gateway -n nginx-gateway
34
+
kubectl get svc <gatewayName-gatewayClassName> -n <gateway-namespace>
33
35
```
34
36
35
37
{{< call-out "note">}} We recommend using the NLB DNS whenever possible, but for testing purposes, you can resolve the DNS name to get the IP address of the load balancer:
@@ -46,8 +48,6 @@ There are two options for accessing NGINX Gateway Fabric depending on the type o
46
48
termination. Read the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) to learn more.
47
49
{{< /call-out >}}
48
50
49
-
{{< call-out "important">}}By default Helm and manifests configure NGINX Gateway Fabric on ports `80` and `443`, affecting any gateway [listeners](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Listener) on these ports. To use different ports, update the configuration. NGINX Gateway Fabric requires a configured [gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/#gateway) resource with a valid listener to listen on any ports.{{< /call-out >}}
50
-
51
51
NGINX Gateway Fabric uses the created service to update the **Addresses** field in the **Gateway Status** resource. Using a **LoadBalancer** service sets this field to the IP address and/or hostname of that service. Without a service, the pod IP address is used.
52
52
53
-
This gateway is associated with the NGINX Gateway Fabric through the **gatewayClassName** field. The default installation of NGINX Gateway Fabric creates a **GatewayClass** with the name **nginx**. NGINX Gateway Fabric will only configure gateways with a **gatewayClassName** of **nginx** unless you change the name via the `--gatewayclass` [command-line flag]({{< ref "/ngf/reference/cli-help.md#controller">}}).
53
+
This gateway is associated with NGINX Gateway Fabric through the **gatewayClassName** field. The default installation of NGINX Gateway Fabric creates a **GatewayClass** with the name **nginx**. NGINX Gateway Fabric will only configure gateways with a **gatewayClassName** of **nginx** unless you change the name via the `--gatewayclass` [command-line flag]({{< ref "/ngf/reference/cli-help.md#controller">}}).
0 commit comments