From 783acb852449a5b29b60378b6d64bb6a696b94d5 Mon Sep 17 00:00:00 2001 From: Nell Jerram Date: Thu, 12 Jun 2025 16:58:42 +0100 Subject: [PATCH 1/5] [RS-2577] Mention new GatewayAPI customization fields --- calico-enterprise/networking/gateway-api.mdx | 3 +++ 1 file changed, 3 insertions(+) diff --git a/calico-enterprise/networking/gateway-api.mdx b/calico-enterprise/networking/gateway-api.mdx index 830355fa80..92cadecf14 100644 --- a/calico-enterprise/networking/gateway-api.mdx +++ b/calico-enterprise/networking/gateway-api.mdx @@ -428,6 +428,9 @@ The `GatewayAPI` resource has fields that allow some aspects of Gateway deployme - `spec.gatewayDeployment.spec.template.spec.nodeSelector` allows control over where Gateway implementation pods are scheduled - `spec.gatewayDeployment.spec.template.spec.containers` allows control over the memory and CPU that Gateway implementation pods can use - `spec.gatewayControllerDeployment.spec.template.spec.nodeSelector` allows control over where the gateway controller is scheduled. +- `spec.gatewayDeployment.service.metadata.annotations` allows control over annotations to place on the Service that is provisioned for each Gateway; these can be used, for example, to configure the cloud-specific type and properties of the associated external load balancer. +- `spec.gatewayDeployment.service.spec.*loadbalancer*` allows control over the corresponding `*loadbalancer*` fields in the Service that is provisioned for each Gateway; in some clouds these can also be used to configure the type and properties of the associated external load balancer. +- `spec.gatewayClasses` allows the provisioning of multiple GatewayClasses, each with its own set of customizations, instead of the single GatewayClass that the Tigera operator provisions by default. For full details please see [the `GatewayAPI` reference documentation](../reference/installation/api.mdx#operator.tigera.io/v1.GatewayAPI). From 7a60c2606d099ce699338f1aae690a08a6931055 Mon Sep 17 00:00:00 2001 From: Nell Jerram Date: Tue, 17 Jun 2025 17:22:04 +0100 Subject: [PATCH 2/5] Copy changes across to OSS and Cloud --- calico-cloud/networking/gateway-api.mdx | 16 ++++++++ calico/networking/gateway-api.mdx | 49 ++----------------------- 2 files changed, 19 insertions(+), 46 deletions(-) diff --git a/calico-cloud/networking/gateway-api.mdx b/calico-cloud/networking/gateway-api.mdx index 82ae57bfaf..994f2e2160 100644 --- a/calico-cloud/networking/gateway-api.mdx +++ b/calico-cloud/networking/gateway-api.mdx @@ -58,6 +58,7 @@ Managed Kubernetes services like AKS, EKS and GKE include a `type: LoadBalancer` - [Enable Gateway API support](#enable-gateway-api-support) - [Use the Gateway API](#use-the-gateway-api) - [Disable Gateway API support](#disable-gateway-api-support) +- [Customize Gateway deployment and features](#customize-gateway-deployment-and-features) ### Enable Gateway API support @@ -419,3 +420,18 @@ EOF ``` Please note that the Gateway API CRDs will be left in place. This is to allow for the possibility of using other Gateway API implementations in addition to the one provided by $[prodname]. + +### Customize Gateway deployment and features + +The `GatewayAPI` resource has fields that allow some aspects of Gateway deployments to be customized. For example: +- `spec.gatewayDeployment.spec.template.metadata` allows arbitrary labels or annotations to be added to the pod that is created to implement each configured Gateway +- `spec.gatewayDeployment.spec.template.spec.nodeSelector` allows control over where Gateway implementation pods are scheduled +- `spec.gatewayDeployment.spec.template.spec.containers` allows control over the memory and CPU that Gateway implementation pods can use +- `spec.gatewayControllerDeployment.spec.template.spec.nodeSelector` allows control over where the gateway controller is scheduled. +- `spec.gatewayDeployment.service.metadata.annotations` allows control over annotations to place on the Service that is provisioned for each Gateway; these can be used, for example, to configure the cloud-specific type and properties of the associated external load balancer. +- `spec.gatewayDeployment.service.spec.*loadbalancer*` allows control over the corresponding `*loadbalancer*` fields in the Service that is provisioned for each Gateway; in some clouds these can also be used to configure the type and properties of the associated external load balancer. +- `spec.gatewayClasses` allows the provisioning of multiple GatewayClasses, each with its own set of customizations, instead of the single GatewayClass that the Tigera operator provisions by default. + +For full details please see [the `GatewayAPI` reference documentation](../reference/installation/api.mdx#operator.tigera.io/v1.GatewayAPI). + +To make use of these customization fields, use `kubectl edit gatewayapi tigera-secure` to edit the YAML for the `GatewayAPI` resource, and add or modify the customization fields that you require. diff --git a/calico/networking/gateway-api.mdx b/calico/networking/gateway-api.mdx index 2b8501277d..c5394491b9 100644 --- a/calico/networking/gateway-api.mdx +++ b/calico/networking/gateway-api.mdx @@ -59,7 +59,6 @@ Managed Kubernetes services like AKS, EKS and GKE include a `type: LoadBalancer` - [Use the Gateway API](#use-the-gateway-api) - [Disable Gateway API support](#disable-gateway-api-support) - [Customize Gateway deployment and features](#customize-gateway-deployment-and-features) -- [Configure additional GatewayClasses](#configure-additional-gatewayclasses) ### Enable Gateway API support @@ -429,56 +428,14 @@ The `GatewayAPI` resource has fields that allow some aspects of Gateway deployme - `spec.gatewayDeployment.spec.template.spec.nodeSelector` allows control over where Gateway implementation pods are scheduled - `spec.gatewayDeployment.spec.template.spec.containers` allows control over the memory and CPU that Gateway implementation pods can use - `spec.gatewayControllerDeployment.spec.template.spec.nodeSelector` allows control over where the gateway controller is scheduled. +- `spec.gatewayDeployment.service.metadata.annotations` allows control over annotations to place on the Service that is provisioned for each Gateway; these can be used, for example, to configure the cloud-specific type and properties of the associated external load balancer. +- `spec.gatewayDeployment.service.spec.*loadbalancer*` allows control over the corresponding `*loadbalancer*` fields in the Service that is provisioned for each Gateway; in some clouds these can also be used to configure the type and properties of the associated external load balancer. +- `spec.gatewayClasses` allows the provisioning of multiple GatewayClasses, each with its own set of customizations, instead of the single GatewayClass that the Tigera operator provisions by default. For full details please see [the `GatewayAPI` reference documentation](../reference/installation/api.mdx#operator.tigera.io/v1.GatewayAPI). To make use of these customization fields, use `kubectl edit gatewayapi default` to edit the YAML for the `GatewayAPI` resource, and add or modify the customization fields that you require. -### Configure additional GatewayClasses - -You may have a need for a tweak or customization that our `GatewayAPI` resource does not yet support. For example, you may want to create a Gateway with EnvoyProxy config different from that which the Tigera operator provisions, and where the change that you need is not supported by an existing customization field in the `GatewayAPI` resource. - -To do this: -- Extract the YAML for the EnvoyProxy and GatewayClass objects that the Tigera operator provisions. -- Change the EnvoyProxy YAML according to your needs, and create that modified EnvoyProxy object with a different name (than `envoy-proxy-config`). -- Change the GatewayClass YAML to reference the name of the modified EnvoyProxy object, and create that modified GatewayClass with a different name (than `tigera-gateway-class`). - -Now you can configure Gateways using the new GatewayClass name, or update existing Gateways to use that new GatewayClass instead of `tigera-gateway-class`. - -In more detail: - -1. Extract the YAML for the EnvoyProxy and GatewayClass objects that the Tigera operator provisions: - - ```bash - kubectl get envoyproxy envoy-proxy-config -n tigera-gateway -o yaml > envoy-proxy.yml - kubectl get gatewayclass tigera-gateway-class -o yaml > gateway-class.yml - ``` - -2. Edit `envoy-proxy.yml` to: - - change the `metadata.name` field to some name other than `envoy-proxy-config` - - delete all other `metadata` fields, except for `namespace` - - make whatever changes or additions you need in the `spec` section. - -3. Create the modified EnvoyProxy object: - - ```bash - kubectl apply -f envoy-proxy.yml - ``` - -4. Edit `gateway-class.yml` to: - - change the `metadata.name` field to some name other than `tigera-gateway-class` - - delete all other `metadata` fields - - delete the `status` section - - change `spec.parametersRef.name` to the name of the modified EnvoyProxy object. - -5. Create the modified GatewayClass: - - ```bash - kubectl apply -f gateway-class.yml - ``` - -6. Use the modified GatewayClass name, instead of `tigera-gateway-class`, for the Gateways that need this (as determined by your own requirements). - ## Additional resources * [Video: Learn more about using the Gateway API with Calico](https://www.youtube.com/watch?v=Q8pbFLJIi5I) From 2db754f12675672c6d8313822c6fec526d8c13f0 Mon Sep 17 00:00:00 2001 From: Nell Jerram Date: Tue, 17 Jun 2025 17:22:15 +0100 Subject: [PATCH 3/5] Delete a stray apostrophe --- calico-enterprise/networking/gateway-api.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/calico-enterprise/networking/gateway-api.mdx b/calico-enterprise/networking/gateway-api.mdx index 92cadecf14..994f2e2160 100644 --- a/calico-enterprise/networking/gateway-api.mdx +++ b/calico-enterprise/networking/gateway-api.mdx @@ -95,7 +95,7 @@ udproutes And also that there is a GatewayClass resource corresponding to the Envoy Gateway implementation included in $[prodname]: ```bash -kubectl get gatewayclass -o=jsonpath='{.items[0].spec}' | jq' +kubectl get gatewayclass -o=jsonpath='{.items[0].spec}' | jq ``` ``` From 6562baf2aae9c773b07d5973ea3769b665fe778e Mon Sep 17 00:00:00 2001 From: Nell Jerram Date: Thu, 19 Jun 2025 17:31:54 +0100 Subject: [PATCH 4/5] EnvoyProxy name is now the same as the GatewayClass name --- calico-cloud/networking/gateway-api.mdx | 2 +- calico-enterprise/networking/gateway-api.mdx | 2 +- calico/networking/gateway-api.mdx | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/calico-cloud/networking/gateway-api.mdx b/calico-cloud/networking/gateway-api.mdx index 994f2e2160..7d1adf1dc8 100644 --- a/calico-cloud/networking/gateway-api.mdx +++ b/calico-cloud/networking/gateway-api.mdx @@ -104,7 +104,7 @@ kubectl get gatewayclass -o=jsonpath='{.items[0].spec}' | jq "parametersRef": { "group": "gateway.envoyproxy.io", "kind": "EnvoyProxy", - "name": "envoy-proxy-config", + "name": "tigera-gateway-class", "namespace": "tigera-gateway" } } diff --git a/calico-enterprise/networking/gateway-api.mdx b/calico-enterprise/networking/gateway-api.mdx index 994f2e2160..7d1adf1dc8 100644 --- a/calico-enterprise/networking/gateway-api.mdx +++ b/calico-enterprise/networking/gateway-api.mdx @@ -104,7 +104,7 @@ kubectl get gatewayclass -o=jsonpath='{.items[0].spec}' | jq "parametersRef": { "group": "gateway.envoyproxy.io", "kind": "EnvoyProxy", - "name": "envoy-proxy-config", + "name": "tigera-gateway-class", "namespace": "tigera-gateway" } } diff --git a/calico/networking/gateway-api.mdx b/calico/networking/gateway-api.mdx index c5394491b9..74b193415d 100644 --- a/calico/networking/gateway-api.mdx +++ b/calico/networking/gateway-api.mdx @@ -104,7 +104,7 @@ kubectl get gatewayclass -o=jsonpath='{.items[0].spec}' | jq "parametersRef": { "group": "gateway.envoyproxy.io", "kind": "EnvoyProxy", - "name": "envoy-proxy-config", + "name": "tigera-gateway-class", "namespace": "tigera-gateway" } } From 8801038b272cabfbc89a678165214b1181a00e94 Mon Sep 17 00:00:00 2001 From: Nell Jerram Date: Fri, 11 Jul 2025 11:28:59 +0100 Subject: [PATCH 5/5] Review markups --- calico-cloud/networking/gateway-api.mdx | 77 +++++++++++++++++++- calico-enterprise/networking/gateway-api.mdx | 77 +++++++++++++++++++- calico/networking/gateway-api.mdx | 77 +++++++++++++++++++- 3 files changed, 225 insertions(+), 6 deletions(-) diff --git a/calico-cloud/networking/gateway-api.mdx b/calico-cloud/networking/gateway-api.mdx index 4edc8f675a..5e283154ae 100644 --- a/calico-cloud/networking/gateway-api.mdx +++ b/calico-cloud/networking/gateway-api.mdx @@ -423,7 +423,7 @@ Please note that the Gateway API CRDs will be left in place. This is to allow f ### Customize Gateway deployment and features -The `GatewayAPI` resource has fields that allow some aspects of Gateway deployments to be customized. For example: +All gateway customization is done through the single `GatewayAPI` resource. This resource has fields that allow some aspects of Gateway deployments to be customized. For example: - `spec.gatewayDeployment.spec.template.metadata` allows arbitrary labels or annotations to be added to the pod that is created to implement each configured Gateway - `spec.gatewayDeployment.spec.template.spec.nodeSelector` allows control over where Gateway implementation pods are scheduled - `spec.gatewayDeployment.spec.template.spec.containers` allows control over the memory and CPU that Gateway implementation pods can use @@ -434,4 +434,77 @@ The `GatewayAPI` resource has fields that allow some aspects of Gateway deployme For full details please see [the `GatewayAPI` reference documentation](../reference/installation/api.mdx#operator.tigera.io/v1.GatewayAPI). -To make use of these customization fields, use `kubectl edit gatewayapi tigera-secure` to edit the YAML for the `GatewayAPI` resource, and add or modify the customization fields that you require. +To make use of these customization fields, use `kubectl edit gatewayapi tigera-secure` to edit the YAML for the `GatewayAPI` resource, and add or modify the customization fields that you require. Following are a few examples of possible customizations. + +#### Handle high traffic with multiple gateway pods and adequate memory per-pod + +```bash +kubectl apply -f - <