Bump sigs.k8s.io/gateway-api from 0.4.2 to 0.5.0

README.md

@@ -27,7 +27,7 @@ Before you can build and run the NGINX Kubernetes Gateway, make sure you have th
    ```
 
 1. Build the image:
- 
+
    ```
    make PREFIX=myregistry.example.com/nginx-kubernetes-gateway container
    ```
@@ -44,7 +44,7 @@ Before you can build and run the NGINX Kubernetes Gateway, make sure you have th
 
 ## Deploy NGINX Kubernetes Gateway
 
-You can deploy NGINX Kubernetes Gateway on an existing Kubernetes 1.16+ cluster. The following instructions walk through the steps for deploying on a [kind](https://kind.sigs.k8s.io/) cluster. 
+You can deploy NGINX Kubernetes Gateway on an existing Kubernetes 1.16+ cluster. The following instructions walk through the steps for deploying on a [kind](https://kind.sigs.k8s.io/) cluster.
 
 1. Load the NGINX Kubernetes Gateway image onto your kind cluster:
 
@@ -57,19 +57,19 @@ You can deploy NGINX Kubernetes Gateway on an existing Kubernetes 1.16+ cluster.
 1. Install the Gateway CRDs:
 
    ```
-   kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.2" 
+   kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0"
    ```
 
 1. Create the nginx-gateway namespace:
-   
+
     ```
     kubectl apply -f deploy/manifests/namespace.yaml
     ```
 
 1. Create the njs-modules configmap:
 
     ```
-    kubectl create configmap njs-modules --from-file=internal/nginx/modules/src/httpmatches.js -n nginx-gateway  
+    kubectl create configmap njs-modules --from-file=internal/nginx/modules/src/httpmatches.js -n nginx-gateway
     ```
 
 1. Create the GatewayClass resource:
@@ -84,7 +84,7 @@ You can deploy NGINX Kubernetes Gateway on an existing Kubernetes 1.16+ cluster.
 
    ```
    kubectl apply -f deploy/manifests/nginx-gateway.yaml
-   ``` 
+   ```
 
 1. Confirm the NGINX Kubernetes Gateway is running in `nginx-gateway` namespace:
 
@@ -110,7 +110,7 @@ A `NodePort` service will randomly allocate one port on every node of the cluste
 
 ### Create a LoadBalancer Service
 
-Create a service with type `LoadBalancer` using the appropriate manifest for your cloud provider. 
+Create a service with type `LoadBalancer` using the appropriate manifest for your cloud provider.
 
 - For GCP or Azure:
 
@@ -119,13 +119,13 @@ Create a service with type `LoadBalancer` using the appropriate manifest for you
    ```
 
    Lookup the public IP of the load balancer:
-   
+
    ```
    kubectl get svc nginx-gateway -n nginx-gateway
-   ``` 
-   
+   ```
+
    Use the public IP of the load balancer to access NGINX Kubernetes Gateway.
-   
+
 - For AWS:
 
    ```
@@ -136,8 +136,8 @@ Create a service with type `LoadBalancer` using the appropriate manifest for you
 
    ```
    kubectl get svc nginx-gateway -n nginx-gateway
-   ``` 
-  
+   ```
+
    In general, you should rely on the NLB DNS name, however for testing purposes you can resolve the DNS name to get the IP address of the load balancer:
 
    ```

deploy/manifests/gatewayclass.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: GatewayClass
 metadata:
   name: nginx

design/archive/gateway-evaluation.md

@@ -33,7 +33,7 @@ The Gateway evaluation will employ each in the following manner:
 
 Gateway evaluation requires supplemental resources; other Core API resources are needed to complete traffic routing between an ingress point and the final backend Pod endpoints. Required supplemental resources are:
 * Services: The AppDev controls the resource lifecycle and is responsible for creating, updating, and deleting Service resources. Kubernetes Service resources describe a logical collection of like processes and act as a load balancing primitive. AppDevs create Service resources to describe their product subsystems, Services act as an abstraction for a set of real backend processes that can serve requests.
-* Endpoints: Kubernetes controllers manage Endpoint resources, Endpoints provide the association between Service abstractions and real servers. Gateway evaluation will watch Endpoints to discover upstream addresses. When AppDevs create Service and HTTPRoute objects, Gateway evaluation uses references in the HTTPRoute (via a HTTPRouteRules and HTTPBackendRefs (see [HTTP Routing](https://gateway-api.sigs.k8s.io/v1alpha2/guides/http-routing/) for more detail)) to discover the Pod IP endpoints, i.e. Gateway evaluation uses Endpoints resources, referred to by HTTPRoutes, to link routing rules to upstream addresses.
+* Endpoints: Kubernetes controllers manage Endpoint resources, Endpoints provide the association between Service abstractions and real servers. Gateway evaluation will watch Endpoints to discover upstream addresses. When AppDevs create Service and HTTPRoute objects, Gateway evaluation uses references in the HTTPRoute (via a HTTPRouteRules and HTTPBackendRefs (see [HTTP Routing](https://gateway-api.sigs.k8s.io/guides/http-routing/) for more detail)) to discover the Pod IP endpoints, i.e. Gateway evaluation uses Endpoints resources, referred to by HTTPRoutes, to link routing rules to upstream addresses.
 
 ### Goals
 - Vet a minimal feature set of Core resources for their applicability and conformance to NGINX configuration models.

examples/advanced-routing/cafe-routes.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: coffee
@@ -33,7 +33,7 @@ spec:
     - name: coffee-v2-svc
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: tea

examples/advanced-routing/gateway.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: Gateway
 metadata:
   name: gateway

examples/cafe-example/cafe-routes.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: cafe
@@ -13,7 +13,7 @@ spec:
     - name: main
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: coffee
@@ -32,7 +32,7 @@ spec:
     - name: coffee
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: tea

examples/cafe-example/gateway.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: Gateway
 metadata:
   name: gateway

examples/https-termination/README.md

@@ -9,21 +9,21 @@ In this example we expand on the simple [cafe-example](../cafe-example) by addin
 1. Follow the [installation instructions](https://github.com/nginxinc/nginx-kubernetes-gateway/blob/main/README.md#run-nginx-gateway) to deploy NGINX Gateway.
 
 1. Save the public IP address of NGINX Kubernetes Gateway into a shell variable:
-   
+
    ```
    GW_IP=XXX.YYY.ZZZ.III
    ```
 
 1. Save the HTTPS port of NGINX Kubernetes Gateway:
-   
+
    ```
    GW_HTTPS_PORT=port
    ```
 
-## 2. Deploy the Cafe Application  
+## 2. Deploy the Cafe Application
 
 1. Create the coffee and the tea deployments and services:
-   
+
    ```
    kubectl apply -f cafe.yaml
    ```
@@ -45,21 +45,21 @@ In this example we expand on the simple [cafe-example](../cafe-example) by addin
    ```
 
    The TLS certificate and key in this secret are used to terminate the TLS connections for the cafe application.
-   **Important**: This certificate and key are for demo purposes only. 
-   
+   **Important**: This certificate and key are for demo purposes only.
+
 1. Create the `Gateway` resource:
    ```
    kubectl apply -f gateway.yaml
    ```
 
-   This [gateway](./gateway.yaml) configures an `https` listener is to terminate TLS connections using the `cafe-secret` we created in the step 1. 
+   This [gateway](./gateway.yaml) configures an `https` listener is to terminate TLS connections using the `cafe-secret` we created in the step 1.
 
 1. Create the `HTTPRoute` resources:
    ```
    kubectl apply -f cafe-routes.yaml
    ```
 
-   To configure HTTPS termination for our cafe application, we will bind the `https` listener to our `HTTPRoutes` in [cafe-routes.yaml](./cafe-routes.yaml) using the [`parentRef`](https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io%2fv1alpha2.ParentReference) field:
+   To configure HTTPS termination for our cafe application, we will bind the `https` listener to our `HTTPRoutes` in [cafe-routes.yaml](./cafe-routes.yaml) using the [`parentReference`](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.ParentReference) field:
 
    ```yaml
    parentRefs:

examples/https-termination/cafe-routes.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: coffee
@@ -17,7 +17,7 @@ spec:
     - name: coffee
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: HTTPRoute
 metadata:
   name: tea

examples/https-termination/gateway.yaml

@@ -1,4 +1,4 @@
-apiVersion: gateway.networking.k8s.io/v1alpha2
+apiVersion: gateway.networking.k8s.io/v1beta1
 kind: Gateway
 metadata:
   name: gateway

go.mod

@@ -16,7 +16,7 @@ require (
 	k8s.io/code-generator v0.24.3
 	sigs.k8s.io/controller-runtime v0.12.3
 	sigs.k8s.io/controller-tools v0.9.2
-	sigs.k8s.io/gateway-api v0.4.2
+	sigs.k8s.io/gateway-api v0.5.0
 )
 
 require (