Configures dynamic provisioning for the agentgateway data plane. Labels and annotations that apply to all resources may be specified at a higher level; see https://gateway-api.sigs.k8s.io/reference/api-spec/main/spec/#gatewayinfrastructure
Last changed in Agentgateway v1.4.0
APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
Desired data plane provisioning settings.
Overrides for the generated `DaemonSet` resource.
`metadata` defines a subset of object metadata to be customized. `labels` and `annotations` are merged with existing values. If both `GatewayClass` and `Gateway` parameters define the same label or annotation key, the `Gateway` value takes precedence (applied second).
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
`spec` provides an opaque mechanism to configure the resource spec. This field accepts a complete or partial Kubernetes resource spec, such as `PodSpec` or `ServiceSpec`, and will be merged with the generated configuration using **Strategic Merge Patch** semantics. # Application Order Overlays are applied after all typed configuration fields from both levels. The full merge order is: 1. `GatewayClass` typed configuration fields 2. `Gateway` typed configuration fields 3. `GatewayClass` overlays 4. `Gateway` overlays (can override all previous values) # Strategic Merge Patch & Deletion Guide This merge strategy allows you to override individual fields, merge lists, or delete items without needing to provide the entire resource definition. **1. Replacing Values (Scalars):** Simple fields (strings, integers, booleans) in your config will overwrite the generated defaults. **2. Merging Lists (Append/Merge):** Lists with "merge keys", like `containers` which merges on `name`, or `tolerations` which merges on `key`, will append your items to the generated list, or update existing items if keys match. **3. Deleting Fields or List Items ($patch: delete):** To remove a field or list item from the generated resource, use the `$patch: delete` directive. This works for both map fields and list items, and is the recommended approach because it works with both client-side and server-side apply. spec: template: spec: # Delete pod-level securityContext securityContext: $patch: delete # Delete nodeSelector nodeSelector: $patch: delete containers: # Be sure to use the correct proxy name here or you will add a # container instead of modifying a container. - name: proxy-name # Delete container-level securityContext securityContext: $patch: delete **4. Null Values (server-side apply only):** Setting a field to `null` can also remove it, but this ONLY works with `kubectl apply --server-side` or equivalent. With regular client-side `kubectl apply`, null values are stripped by kubectl before reaching the API server, so the deletion won't occur. Prefer `$patch: delete` for consistent behavior across both apply modes. spec: template: spec: nodeSelector: null # Removes nodeSelector (server-side apply only!) **5. Replacing Maps Entirely ($patch: replace):** To replace an entire map with your values (instead of merging), use `$patch: replace`. This removes all existing keys and replaces them with only your specified keys. spec: template: spec: nodeSelector: $patch: replace custom-key: custom-value **6. Replacing Lists Entirely ($patch: replace):** If you want to strictly define a list and ignore all generated defaults, use `$patch: replace`. service: spec: ports: - $patch: replace - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP
Overrides for the generated `Deployment` resource.
`metadata` defines a subset of object metadata to be customized. `labels` and `annotations` are merged with existing values. If both `GatewayClass` and `Gateway` parameters define the same label or annotation key, the `Gateway` value takes precedence (applied second).
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
`spec` provides an opaque mechanism to configure the resource spec. This field accepts a complete or partial Kubernetes resource spec, such as `PodSpec` or `ServiceSpec`, and will be merged with the generated configuration using **Strategic Merge Patch** semantics. # Application Order Overlays are applied after all typed configuration fields from both levels. The full merge order is: 1. `GatewayClass` typed configuration fields 2. `Gateway` typed configuration fields 3. `GatewayClass` overlays 4. `Gateway` overlays (can override all previous values) # Strategic Merge Patch & Deletion Guide This merge strategy allows you to override individual fields, merge lists, or delete items without needing to provide the entire resource definition. **1. Replacing Values (Scalars):** Simple fields (strings, integers, booleans) in your config will overwrite the generated defaults. **2. Merging Lists (Append/Merge):** Lists with "merge keys", like `containers` which merges on `name`, or `tolerations` which merges on `key`, will append your items to the generated list, or update existing items if keys match. **3. Deleting Fields or List Items ($patch: delete):** To remove a field or list item from the generated resource, use the `$patch: delete` directive. This works for both map fields and list items, and is the recommended approach because it works with both client-side and server-side apply. spec: template: spec: # Delete pod-level securityContext securityContext: $patch: delete # Delete nodeSelector nodeSelector: $patch: delete containers: # Be sure to use the correct proxy name here or you will add a # container instead of modifying a container. - name: proxy-name # Delete container-level securityContext securityContext: $patch: delete **4. Null Values (server-side apply only):** Setting a field to `null` can also remove it, but this ONLY works with `kubectl apply --server-side` or equivalent. With regular client-side `kubectl apply`, null values are stripped by kubectl before reaching the API server, so the deletion won't occur. Prefer `$patch: delete` for consistent behavior across both apply modes. spec: template: spec: nodeSelector: null # Removes nodeSelector (server-side apply only!) **5. Replacing Maps Entirely ($patch: replace):** To replace an entire map with your values (instead of merging), use `$patch: replace`. This removes all existing keys and replaces them with only your specified keys. spec: template: spec: nodeSelector: $patch: replace custom-key: custom-value **6. Replacing Lists Entirely ($patch: replace):** If you want to strictly define a list and ignore all generated defaults, use `$patch: replace`. service: spec: ports: - $patch: replace - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP
Container environment variables. These override any existing values. If you want to delete an environment variable entirely, use `$patch: delete` with an overlay instead. Note that [variable expansion](https://kubernetes.io/docs/tasks/inject-data-application/define-interdependent-environment-variables/) does apply, but is highly discouraged -- to set dependent environment variables, you can use `$(VAR_NAME)`, but it's highly discouraged. `$$(VAR_NAME)` avoids expansion and results in a literal `$(VAR_NAME)`. If `SESSION_KEY` is specified, it takes precedence over the controller-managed per-`Gateway` session key `Secret`.
Name of the environment variable. May consist of any printable ASCII characters except '='.
Variable references $(VAR_NAME) are expanded using the previously defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "".
Source for the environment variable's value. Cannot be used if value is not empty.
Selects a key of a ConfigMap.
The key to select.
Name of the referent
Specify whether the ConfigMap or its key must be defined
Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['<KEY>']`, `metadata.annotations['<KEY>']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.
Version of the schema the FieldPath is written in terms of, defaults to "v1".
Path of the field to select in the specified API version.
FileKeyRef selects a key of the env file. Requires the EnvFiles feature gate to be enabled.
The key within the env file. An invalid key will prevent the pod from starting. The keys defined within a source may consist of any printable ASCII characters except '='. During Alpha stage of the EnvFiles feature gate, the key size is limited to 128 characters.
Specify whether the file or its key must be defined. If the file or key does not exist, then the env var is not published. If optional is set to true and the specified key does not exist, the environment variable will not be set in the Pod's containers. If optional is set to false and the specified key does not exist, an error will be returned during Pod creation.
The path within the volume from which to select the file. Must be relative and may not contain the '..' path or start with '..'.
The name of the volume mount containing the env file.
Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.
Container name: required for volumes, optional for env vars
Specifies the output format of the exposed resources, defaults to "1"
Required: resource to select
Selects a key of a secret in the pod's namespace
The key of the secret to select from. Must be a valid secret key.
Name of the referent
Specify whether the Secret or its key must be defined
Creates a `HorizontalPodAutoscaler` for Deployment-backed agentgateway proxies. If absent, no HPA is created. If present, an HPA is created with its `scaleTargetRef` automatically configured to target the generated `Deployment`. The `metadata` and `spec` fields from this overlay are applied to the generated HPA.
`metadata` defines a subset of object metadata to be customized. `labels` and `annotations` are merged with existing values. If both `GatewayClass` and `Gateway` parameters define the same label or annotation key, the `Gateway` value takes precedence (applied second).
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
`spec` provides an opaque mechanism to configure the resource spec. This field accepts a complete or partial Kubernetes resource spec, such as `PodSpec` or `ServiceSpec`, and will be merged with the generated configuration using **Strategic Merge Patch** semantics. # Application Order Overlays are applied after all typed configuration fields from both levels. The full merge order is: 1. `GatewayClass` typed configuration fields 2. `Gateway` typed configuration fields 3. `GatewayClass` overlays 4. `Gateway` overlays (can override all previous values) # Strategic Merge Patch & Deletion Guide This merge strategy allows you to override individual fields, merge lists, or delete items without needing to provide the entire resource definition. **1. Replacing Values (Scalars):** Simple fields (strings, integers, booleans) in your config will overwrite the generated defaults. **2. Merging Lists (Append/Merge):** Lists with "merge keys", like `containers` which merges on `name`, or `tolerations` which merges on `key`, will append your items to the generated list, or update existing items if keys match. **3. Deleting Fields or List Items ($patch: delete):** To remove a field or list item from the generated resource, use the `$patch: delete` directive. This works for both map fields and list items, and is the recommended approach because it works with both client-side and server-side apply. spec: template: spec: # Delete pod-level securityContext securityContext: $patch: delete # Delete nodeSelector nodeSelector: $patch: delete containers: # Be sure to use the correct proxy name here or you will add a # container instead of modifying a container. - name: proxy-name # Delete container-level securityContext securityContext: $patch: delete **4. Null Values (server-side apply only):** Setting a field to `null` can also remove it, but this ONLY works with `kubectl apply --server-side` or equivalent. With regular client-side `kubectl apply`, null values are stripped by kubectl before reaching the API server, so the deletion won't occur. Prefer `$patch: delete` for consistent behavior across both apply modes. spec: template: spec: nodeSelector: null # Removes nodeSelector (server-side apply only!) **5. Replacing Maps Entirely ($patch: replace):** To replace an entire map with your values (instead of merging), use `$patch: replace`. This removes all existing keys and replaces them with only your specified keys. spec: template: spec: nodeSelector: $patch: replace custom-key: custom-value **6. Replacing Lists Entirely ($patch: replace):** If you want to strictly define a list and ignore all generated defaults, use `$patch: replace`. service: spec: ports: - $patch: replace - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP
The agentgateway container image. See https://kubernetes.io/docs/concepts/containers/images for details. Default values, which may be overridden individually: registry: cr.agentgateway.dev repository: agentgateway tag: <agentgateway version> pullPolicy: <omitted, relying on Kubernetes defaults which depend on the tag>
Image digest, such as `sha256:12345...`.
Image pull policy for the container. See https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy for details.
Image registry.
Image repository.
Image tag.
Istio integration settings. If enabled, agentgateway can natively connect to Istio-enabled pods with mTLS.
Additional SPIFFE trust domains accepted on inbound HBONE connections. The local trust domain is always implicitly included.
Address of the Istio CA. If unset, defaults to `https://istiod.istio-system.svc:15012`.
ID of the cluster this gateway runs in. If unset, defaults to `Kubernetes`.
Explicitly turns Istio integration on or off for this gateway.
Istio network this gateway runs in. If unset, defaults to the empty network.
Istio trust domain. If not set, defaults to `cluster.local`, or the default trust domain for the control plane's istio revision.
Logging configuration. By default, all logs are set to `info` level.
Logging output format.
Logging level in standard `RUST_LOG` syntax, for example `info` (the default), or a comma-separated per-module setting such as `rmcp=warn,hickory_server::server::server_future=off,typespec_client_core::http::policies::logging=warn`.
Model cost catalog sources. Only effective when set on a Gateway-level AgentgatewayParameters (via Gateway.spec.infrastructure.parametersRef); ignored on GatewayClass-level parameters because ConfigMap references are resolved from the Gateway's deployment namespace.
ModelCatalogConfigMapRef identifies a ConfigMap holding model cost catalog JSON. The ConfigMap must be in the same namespace as the Gateway that references it.
Data key whose value is the catalog JSON. Defaults to "catalog.json".
Creates a `PodDisruptionBudget` for the agentgateway proxy. If absent, no PDB is created. If present, a PDB is created with its selector automatically configured to target the selected generated workload. The `metadata` and `spec` fields from this overlay are applied to the generated PDB.
`metadata` defines a subset of object metadata to be customized. `labels` and `annotations` are merged with existing values. If both `GatewayClass` and `Gateway` parameters define the same label or annotation key, the `Gateway` value takes precedence (applied second).
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
`spec` provides an opaque mechanism to configure the resource spec. This field accepts a complete or partial Kubernetes resource spec, such as `PodSpec` or `ServiceSpec`, and will be merged with the generated configuration using **Strategic Merge Patch** semantics. # Application Order Overlays are applied after all typed configuration fields from both levels. The full merge order is: 1. `GatewayClass` typed configuration fields 2. `Gateway` typed configuration fields 3. `GatewayClass` overlays 4. `Gateway` overlays (can override all previous values) # Strategic Merge Patch & Deletion Guide This merge strategy allows you to override individual fields, merge lists, or delete items without needing to provide the entire resource definition. **1. Replacing Values (Scalars):** Simple fields (strings, integers, booleans) in your config will overwrite the generated defaults. **2. Merging Lists (Append/Merge):** Lists with "merge keys", like `containers` which merges on `name`, or `tolerations` which merges on `key`, will append your items to the generated list, or update existing items if keys match. **3. Deleting Fields or List Items ($patch: delete):** To remove a field or list item from the generated resource, use the `$patch: delete` directive. This works for both map fields and list items, and is the recommended approach because it works with both client-side and server-side apply. spec: template: spec: # Delete pod-level securityContext securityContext: $patch: delete # Delete nodeSelector nodeSelector: $patch: delete containers: # Be sure to use the correct proxy name here or you will add a # container instead of modifying a container. - name: proxy-name # Delete container-level securityContext securityContext: $patch: delete **4. Null Values (server-side apply only):** Setting a field to `null` can also remove it, but this ONLY works with `kubectl apply --server-side` or equivalent. With regular client-side `kubectl apply`, null values are stripped by kubectl before reaching the API server, so the deletion won't occur. Prefer `$patch: delete` for consistent behavior across both apply modes. spec: template: spec: nodeSelector: null # Removes nodeSelector (server-side apply only!) **5. Replacing Maps Entirely ($patch: replace):** To replace an entire map with your values (instead of merging), use `$patch: replace`. This removes all existing keys and replaces them with only your specified keys. spec: template: spec: nodeSelector: $patch: replace custom-key: custom-value **6. Replacing Lists Entirely ($patch: replace):** If you want to strictly define a list and ignore all generated defaults, use `$patch: replace`. service: spec: ports: - $patch: replace - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP
Raw agentgateway configuration to merge into the generated config file. This is merged with configuration derived from typed fields like `logging.format`, and those typed fields will take precedence. Example: rawConfig: binds: - port: 3000 listeners: - routes: - policies: cors: allowOrigins: - "*" allowHeaders: - mcp-protocol-version - content-type - cache-control backends: - mcp: targets: - name: everything stdio: cmd: npx args: ["@modelcontextprotocol/server-everything"]
Compute resources required by this container. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ for details.
Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. This field depends on the DynamicResourceAllocation feature gate. This field is immutable. It can only be set for containers.
Name must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container.
Request is the name chosen for a request in the referenced claim. If empty, everything from the claim is made available, otherwise only the result of this request.
Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Overrides for the generated `Service` resource.
`metadata` defines a subset of object metadata to be customized. `labels` and `annotations` are merged with existing values. If both `GatewayClass` and `Gateway` parameters define the same label or annotation key, the `Gateway` value takes precedence (applied second).
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
`spec` provides an opaque mechanism to configure the resource spec. This field accepts a complete or partial Kubernetes resource spec, such as `PodSpec` or `ServiceSpec`, and will be merged with the generated configuration using **Strategic Merge Patch** semantics. # Application Order Overlays are applied after all typed configuration fields from both levels. The full merge order is: 1. `GatewayClass` typed configuration fields 2. `Gateway` typed configuration fields 3. `GatewayClass` overlays 4. `Gateway` overlays (can override all previous values) # Strategic Merge Patch & Deletion Guide This merge strategy allows you to override individual fields, merge lists, or delete items without needing to provide the entire resource definition. **1. Replacing Values (Scalars):** Simple fields (strings, integers, booleans) in your config will overwrite the generated defaults. **2. Merging Lists (Append/Merge):** Lists with "merge keys", like `containers` which merges on `name`, or `tolerations` which merges on `key`, will append your items to the generated list, or update existing items if keys match. **3. Deleting Fields or List Items ($patch: delete):** To remove a field or list item from the generated resource, use the `$patch: delete` directive. This works for both map fields and list items, and is the recommended approach because it works with both client-side and server-side apply. spec: template: spec: # Delete pod-level securityContext securityContext: $patch: delete # Delete nodeSelector nodeSelector: $patch: delete containers: # Be sure to use the correct proxy name here or you will add a # container instead of modifying a container. - name: proxy-name # Delete container-level securityContext securityContext: $patch: delete **4. Null Values (server-side apply only):** Setting a field to `null` can also remove it, but this ONLY works with `kubectl apply --server-side` or equivalent. With regular client-side `kubectl apply`, null values are stripped by kubectl before reaching the API server, so the deletion won't occur. Prefer `$patch: delete` for consistent behavior across both apply modes. spec: template: spec: nodeSelector: null # Removes nodeSelector (server-side apply only!) **5. Replacing Maps Entirely ($patch: replace):** To replace an entire map with your values (instead of merging), use `$patch: replace`. This removes all existing keys and replaces them with only your specified keys. spec: template: spec: nodeSelector: $patch: replace custom-key: custom-value **6. Replacing Lists Entirely ($patch: replace):** If you want to strictly define a list and ignore all generated defaults, use `$patch: replace`. service: spec: ports: - $patch: replace - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP
Overrides for the generated `ServiceAccount` resource.
`metadata` defines a subset of object metadata to be customized. `labels` and `annotations` are merged with existing values. If both `GatewayClass` and `Gateway` parameters define the same label or annotation key, the `Gateway` value takes precedence (applied second).
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels
`spec` provides an opaque mechanism to configure the resource spec. This field accepts a complete or partial Kubernetes resource spec, such as `PodSpec` or `ServiceSpec`, and will be merged with the generated configuration using **Strategic Merge Patch** semantics. # Application Order Overlays are applied after all typed configuration fields from both levels. The full merge order is: 1. `GatewayClass` typed configuration fields 2. `Gateway` typed configuration fields 3. `GatewayClass` overlays 4. `Gateway` overlays (can override all previous values) # Strategic Merge Patch & Deletion Guide This merge strategy allows you to override individual fields, merge lists, or delete items without needing to provide the entire resource definition. **1. Replacing Values (Scalars):** Simple fields (strings, integers, booleans) in your config will overwrite the generated defaults. **2. Merging Lists (Append/Merge):** Lists with "merge keys", like `containers` which merges on `name`, or `tolerations` which merges on `key`, will append your items to the generated list, or update existing items if keys match. **3. Deleting Fields or List Items ($patch: delete):** To remove a field or list item from the generated resource, use the `$patch: delete` directive. This works for both map fields and list items, and is the recommended approach because it works with both client-side and server-side apply. spec: template: spec: # Delete pod-level securityContext securityContext: $patch: delete # Delete nodeSelector nodeSelector: $patch: delete containers: # Be sure to use the correct proxy name here or you will add a # container instead of modifying a container. - name: proxy-name # Delete container-level securityContext securityContext: $patch: delete **4. Null Values (server-side apply only):** Setting a field to `null` can also remove it, but this ONLY works with `kubectl apply --server-side` or equivalent. With regular client-side `kubectl apply`, null values are stripped by kubectl before reaching the API server, so the deletion won't occur. Prefer `$patch: delete` for consistent behavior across both apply modes. spec: template: spec: nodeSelector: null # Removes nodeSelector (server-side apply only!) **5. Replacing Maps Entirely ($patch: replace):** To replace an entire map with your values (instead of merging), use `$patch: replace`. This removes all existing keys and replaces them with only your specified keys. spec: template: spec: nodeSelector: $patch: replace custom-key: custom-value **6. Replacing Lists Entirely ($patch: replace):** If you want to strictly define a list and ignore all generated defaults, use `$patch: replace`. service: spec: ports: - $patch: replace - name: http port: 80 targetPort: 8080 protocol: TCP - name: https port: 443 targetPort: 8443 protocol: TCP
Shutdown delay configuration. How graceful planned or unplanned data plane changes happen is in tension with how quickly rollouts of the data plane complete. How long a data plane pod must wait for shutdown to be perfectly graceful depends on how you have configured your `Gateway` resources.
Maximum time (in seconds) to wait before allowing Agentgateway to terminate. Refer to the `TERMINATION_GRACE_PERIOD_SECONDS` environment variable for details.
Minimum time (in seconds) to wait before allowing Agentgateway to terminate. Refer to the `CONNECTION_MIN_TERMINATION_DEADLINE` environment variable for details.
`workload` selects the Kubernetes workload kind for the managed Gateway data plane. If unset, Deployment is used.
Kind selects the Kubernetes workload kind. When unset, Deployment is used.
Current status for these provisioning settings.
Source: agentgateway.dev_agentgatewayparameters.yaml
Changes to AgentgatewayParameters (agentgateway.dev/v1alpha1) in each Agentgateway version, compared to the version before it.
2 properties have been added
4 properties have changed the description
Released · View AgentgatewayParameters in v1.4.0
4 properties have been added
The description of AgentgatewayParameters has changed
20 properties have changed the description
Released · View AgentgatewayParameters in v1.3.0
1 property has been added
Released · View AgentgatewayParameters in v1.2.0
22 properties have changed the description
Released · View AgentgatewayParameters in v1.1.0
AgentgatewayParameters was already present in this version of Agentgateway, the oldest one on kubespec.dev
Released · View AgentgatewayParameters in v1.0.0
No examples of AgentgatewayParameters yet. Contribute one on GitHub.
kubespec.dev