diff --git a/.openvex/templates/README.md b/.openvex/templates/README.md index d724e1d0e7..3961ecf784 100644 --- a/.openvex/templates/README.md +++ b/.openvex/templates/README.md @@ -14,7 +14,7 @@ vexctl add --in-place main.openvex.json pkg:oci/test CVE-2014-1234567 fixed That will add a new VEX statement expressing that the impact of CVE-2014-1234567 is under investigation in the test image. When cutting a new release, for `pkg:oci/test` the new file will be -incorporated to the relase's VEX data. +incorporated to the release's VEX data. ## Read more about OpenVEX diff --git a/CHANGELOG/0.x-CHANGELOG.md b/CHANGELOG/0.x-CHANGELOG.md index 20f76c6551..e5f80df856 100644 --- a/CHANGELOG/0.x-CHANGELOG.md +++ b/CHANGELOG/0.x-CHANGELOG.md @@ -226,7 +226,7 @@ For more information refer to - Added the missing ReferenceGrant resource the kustomization.yaml for the standard channel (#2084, @howardjohn) -- Webhook validation now ensures that BackendRefs can not be specified in the +- Webhook validation now ensures that BackendRefs cannot be specified in the same HTTPRoute rule as a Redirect filter (#2161, @slayer321) - GRPCRoute: The default match has been removed as it was invalid (it only specified a type of "Exact" without a corresponding Service or Method). Note @@ -407,7 +407,7 @@ For more information, refer to - Added the missing ReferenceGrant resource the kustomization.yaml for the standard channel (#2084, @howardjohn) -- Webhook validation now ensures that BackendRefs can not be specified in the +- Webhook validation now ensures that BackendRefs cannot be specified in the same HTTPRoute rule as a Redirect filter (#2161, @slayer321) # v0.7.1 @@ -1089,7 +1089,7 @@ In this release, we've made two release channels available, `experimental` and `standard`. The `experimental` channel contains all resources and fields, while `standard` -contains only resources that mave moved to beta status. +contains only resources that have moved to beta status. We've also added a way to flag particular fields within a resource as experimental, and any fields marked in this way are only present in the @@ -1274,7 +1274,7 @@ In this release, we've made two release channels available, `experimental` and `standard`. The `experimental` channel contains all resources and fields, while `standard` -contains only resources that mave moved to beta status. +contains only resources that have moved to beta status. We've also added a way to flag particular fields within a resource as experimental, and any fields marked in this way are only present in the diff --git a/CHANGELOG/1.0-CHANGELOG.md b/CHANGELOG/1.0-CHANGELOG.md index 25520bb4eb..f879309752 100644 --- a/CHANGELOG/1.0-CHANGELOG.md +++ b/CHANGELOG/1.0-CHANGELOG.md @@ -142,7 +142,7 @@ Of course there's a lot more in this release: - The condition reason `GatewayReasonAddressNotUsable` for `Programmed` has been added to deal with situations where a static address has been provided for a Gateway which is of a supported type, and is syntactically valid, but for some - reason it can not be used for this Gateway (e.g. the address is already in use + reason it cannot be used for this Gateway (e.g. the address is already in use on the network). (#2412 @shaneutt) @@ -332,7 +332,7 @@ Of course there's a lot more in this release: - The condition reason `GatewayReasonAddressNotUsable` for `Programmed` has been added to deal with situations where a static address has been provided for a Gateway which is of a supported type, and is syntactically valid, but for some - reason it can not be used for this Gateway (e.g. the address is already in use + reason it cannot be used for this Gateway (e.g. the address is already in use on the network). (#2412 @shaneutt) diff --git a/CHANGELOG/1.2-CHANGELOG.md b/CHANGELOG/1.2-CHANGELOG.md index 3d61475690..ee260c649d 100644 --- a/CHANGELOG/1.2-CHANGELOG.md +++ b/CHANGELOG/1.2-CHANGELOG.md @@ -864,7 +864,7 @@ The Experimental `supportedFeatures` field in GatewayClass `status` has changed from being a list of strings to being a list of objects/structs with a `name` field. -This is to allow addding in extra information to each entry at a later date. +This is to allow adding in extra information to each entry at a later date. Relevant PRs: diff --git a/CHANGELOG/1.2-TEAM.md b/CHANGELOG/1.2-TEAM.md index f52ba70025..ebd6283ded 100644 --- a/CHANGELOG/1.2-TEAM.md +++ b/CHANGELOG/1.2-TEAM.md @@ -7,7 +7,7 @@ | BackendProtocol Support | @dprotaso | | HTTPRoute Retries | @mikemorris | | Percentage-based request mirroring | @jakebennert | -| Backend TLS Config improvments | @mkosieradzki, @LiorLieberman | +| Backend TLS Config improvements | @mkosieradzki, @LiorLieberman | | Named Route Rules | @guicassolato, @howardjohn | | Conformance Profiles and Reports | @mlavacca, @shaneutt, @xtineskim | | Gateway API Maintainers | @mlavacca, @robscott, @shaneutt, @youngnick | diff --git a/Makefile b/Makefile index 7ef6a2a4a7..4bde1cc5e5 100644 --- a/Makefile +++ b/Makefile @@ -92,16 +92,16 @@ test.crds-validation: conformance: go test ${GO_TEST_FLAGS} -v ./conformance -run TestConformance -args ${CONFORMANCE_FLAGS} -# Install CRD's and example resources to a pre-existing cluster. +# Install CRD's and example resources to a preexisting cluster. .PHONY: install install: crd example -# Install the CRD's to a pre-existing cluster. +# Install the CRD's to a preexisting cluster. .PHONY: crd crd: kubectl kustomize config/crd | kubectl apply -f - -# Install the example resources to a pre-existing cluster. +# Install the example resources to a preexisting cluster. .PHONY: example example: hack/install-examples.sh diff --git a/RELEASE.md b/RELEASE.md index 307f33f519..d72758367e 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -70,7 +70,7 @@ The following steps must be done by one of the [Gateway API maintainers][gateway - Run the `make build-install-yaml` command which will generate install files in the `release/` directory. Attach these files to the GitHub release. - Update the `README.md` and `site-src/guides/index.md` files to point links and examples to the new release. -- Update the implementation table path (`nav.Implementations.Comparison`) in the nav of `mkdocs.yml` to point to the latest release file (for example Implementation Comparison points to `implmenetation-table-v1.2.0.md`). Add the now past version under `Past Version Comparisons`, and edit the text blurb in `mkdocs-generate-conformance.py` to also reflect the added past version. +- Update the implementation table path (`nav.Implementations.Comparison`) in the nav of `mkdocs.yml` to point to the latest release file (for example Implementation Comparison points to `implementation-table-v1.2.0.md`). Add the now past version under `Past Version Comparisons`, and edit the text blurb in `mkdocs-generate-conformance.py` to also reflect the added past version. #### For an **RC** release: - Update `pkg/consts/consts.go` with the new semver tag (like `v1.2.0-rc1`) and any updates to the API review URL. diff --git a/apis/v1/grpcroute_types.go b/apis/v1/grpcroute_types.go index 953ba0243b..21beb95e8a 100644 --- a/apis/v1/grpcroute_types.go +++ b/apis/v1/grpcroute_types.go @@ -230,7 +230,7 @@ type GRPCRouteRule struct { // Specifying the same filter multiple times is not supported unless explicitly // indicated in the filter. // - // If an implementation can not support a combination of filters, it must clearly + // If an implementation cannot support a combination of filters, it must clearly // document that limitation. In cases where incompatible or unsupported // filters are specified and cause the `Accepted` condition to be set to status // `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/apis/v1/httproute_types.go b/apis/v1/httproute_types.go index a185e3709f..8037c4f17b 100644 --- a/apis/v1/httproute_types.go +++ b/apis/v1/httproute_types.go @@ -210,7 +210,7 @@ type HTTPRouteRule struct { // they are specified. // // Implementations MAY choose to implement this ordering strictly, rejecting - // any combination or order of filters that can not be supported. If implementations + // any combination or order of filters that cannot be supported. If implementations // choose a strict interpretation of filter ordering, they MUST clearly document // that behavior. // @@ -232,7 +232,7 @@ type HTTPRouteRule struct { // // All filters are expected to be compatible with each other except for the // URLRewrite and RequestRedirect filters, which may not be combined. If an - // implementation can not support other combinations of filters, they must clearly + // implementation cannot support other combinations of filters, they must clearly // document that limitation. In cases where incompatible or unsupported // filters are specified and cause the `Accepted` condition to be set to status // `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -487,7 +487,7 @@ const ( PathMatchExact PathMatchType = "Exact" // Matches based on a URL path prefix split by `/`. Matching is - // case sensitive and done on a path element by element basis. A + // case-sensitive and done on a path element by element basis. A // path element refers to the list of labels in the path split by // the `/` separator. When specified, a trailing `/` is ignored. // @@ -596,7 +596,7 @@ type HTTPHeaderMatch struct { Type *HeaderMatchType `json:"type,omitempty"` // Name is the name of the HTTP Header to be matched. Name matching MUST be - // case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + // case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). // // If multiple entries specify equivalent header names, only the first // entry with an equivalent name MUST be considered for a match. Subsequent @@ -947,7 +947,7 @@ const ( // HTTPHeader represents an HTTP Header name and value as defined by RFC 7230. type HTTPHeader struct { // Name is the name of the HTTP Header to be matched. Name matching MUST be - // case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + // case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). // // If multiple entries specify equivalent header names, the first entry with // an equivalent name MUST be considered for a match. Subsequent entries diff --git a/apis/v1/shared_types.go b/apis/v1/shared_types.go index 998c7793fe..226c776372 100644 --- a/apis/v1/shared_types.go +++ b/apis/v1/shared_types.go @@ -469,7 +469,7 @@ type RouteParentStatus struct { // There are a number of cases where the "Accepted" condition may not be set // due to lack of controller visibility, that includes when: // - // * The Route refers to a non-existent parent. + // * The Route refers to a nonexistent parent. // * The Route is of a type that the controller does not support. // * The Route is in a namespace the controller does not have access to. // @@ -675,7 +675,7 @@ type GatewayController string // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -705,7 +705,7 @@ type AnnotationValue string // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -771,7 +771,7 @@ const ( // (see [RFC 5952](https://tools.ietf.org/html/rfc5952)). // // This type is intended for specific addresses. Address ranges are not - // supported (e.g. you can not use a CIDR range like 127.0.0.0/24 as an + // supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an // IPAddress). // // Support: Extended diff --git a/apis/v1/util/validation/gatewayclass_test.go b/apis/v1/util/validation/gatewayclass_test.go index d211b1fcd7..f5cdb1d0d6 100644 --- a/apis/v1/util/validation/gatewayclass_test.go +++ b/apis/v1/util/validation/gatewayclass_test.go @@ -20,7 +20,7 @@ import ( "testing" gatewayv1 "sigs.k8s.io/gateway-api/apis/v1" - validationtutils "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" + validationutil "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" ) func TestIsControllerNameValid(t *testing.T) { @@ -58,7 +58,7 @@ func TestIsControllerNameValid(t *testing.T) { for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { - isValid := validationtutils.IsControllerNameValid(tc.controllerName) + isValid := validationutil.IsControllerNameValid(tc.controllerName) if isValid != tc.isvalid { t.Errorf("Expected validity %t, got %t", tc.isvalid, isValid) } diff --git a/apis/v1alpha2/shared_types.go b/apis/v1alpha2/shared_types.go index af04601e41..2fb84d5f3b 100644 --- a/apis/v1alpha2/shared_types.go +++ b/apis/v1alpha2/shared_types.go @@ -313,7 +313,7 @@ type GatewayController = v1.GatewayController // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -360,7 +360,7 @@ const ( // (see [RFC 5952](https://tools.ietf.org/html/rfc5952)). // // This type is intended for specific addresses. Address ranges are not - // supported (e.g. you can not use a CIDR range like 127.0.0.0/24 as an + // supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an // IPAddress). // // Support: Extended diff --git a/apis/v1alpha2/tcproute_types.go b/apis/v1alpha2/tcproute_types.go index b79253dd33..e383af495d 100644 --- a/apis/v1alpha2/tcproute_types.go +++ b/apis/v1alpha2/tcproute_types.go @@ -67,7 +67,7 @@ type TCPRouteRule struct { Name *SectionName `json:"name,omitempty"` // BackendRefs defines the backend(s) where matching requests should be - // sent. If unspecified or invalid (refers to a non-existent resource or a + // sent. If unspecified or invalid (refers to a nonexistent resource or a // Service with no endpoints), the underlying implementation MUST actively // reject connection attempts to this backend. Connection rejections must // respect weight; if an invalid backend is requested to have 80% of diff --git a/apis/v1alpha2/tlsroute_types.go b/apis/v1alpha2/tlsroute_types.go index 26dfde77c7..f21fe3fc50 100644 --- a/apis/v1alpha2/tlsroute_types.go +++ b/apis/v1alpha2/tlsroute_types.go @@ -108,7 +108,7 @@ type TLSRouteRule struct { Name *SectionName `json:"name,omitempty"` // BackendRefs defines the backend(s) where matching requests should be - // sent. If unspecified or invalid (refers to a non-existent resource or + // sent. If unspecified or invalid (refers to a nonexistent resource or // a Service with no endpoints), the rule performs no forwarding; if no // filters are specified that would result in a response being sent, the // underlying implementation must actively reject request attempts to this diff --git a/apis/v1alpha2/udproute_types.go b/apis/v1alpha2/udproute_types.go index 9e7fe3ff80..c7e92b92b4 100644 --- a/apis/v1alpha2/udproute_types.go +++ b/apis/v1alpha2/udproute_types.go @@ -67,7 +67,7 @@ type UDPRouteRule struct { Name *SectionName `json:"name,omitempty"` // BackendRefs defines the backend(s) where matching requests should be - // sent. If unspecified or invalid (refers to a non-existent resource or a + // sent. If unspecified or invalid (refers to a nonexistent resource or a // Service with no endpoints), the underlying implementation MUST actively // reject connection attempts to this backend. Packet drops must // respect weight; if an invalid backend is requested to have 80% of diff --git a/apis/v1alpha3/backendtlspolicy_types.go b/apis/v1alpha3/backendtlspolicy_types.go index dd52d5d165..2896454a21 100644 --- a/apis/v1alpha3/backendtlspolicy_types.go +++ b/apis/v1alpha3/backendtlspolicy_types.go @@ -112,7 +112,7 @@ type BackendTLSPolicyValidation struct { // // If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be // specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, - // not both. If CACertifcateRefs is empty or unspecified, the configuration for + // not both. If CACertificateRefs is empty or unspecified, the configuration for // WellKnownCACertificates MUST be honored instead if supported by the implementation. // // References to a resource in a different namespace are invalid for the diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 2dfbb9264a..3dbcc280fc 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -313,7 +313,7 @@ type GatewayController = v1.GatewayController // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -360,7 +360,7 @@ const ( // (see [RFC 5952](https://tools.ietf.org/html/rfc5952)). // // This type is intended for specific addresses. Address ranges are not - // supported (e.g. you can not use a CIDR range like 127.0.0.0/24 as an + // supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an // IPAddress). // // Support: Extended diff --git a/apis/v1beta1/util/validation/gatewayclass_test.go b/apis/v1beta1/util/validation/gatewayclass_test.go index 175d4f9a30..128de4947e 100644 --- a/apis/v1beta1/util/validation/gatewayclass_test.go +++ b/apis/v1beta1/util/validation/gatewayclass_test.go @@ -20,7 +20,7 @@ import ( "testing" gatewayv1b1 "sigs.k8s.io/gateway-api/apis/v1beta1" - validationtutils "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" + validationutil "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" ) func TestIsControllerNameValid(t *testing.T) { @@ -58,7 +58,7 @@ func TestIsControllerNameValid(t *testing.T) { for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { - isValid := validationtutils.IsControllerNameValid(tc.controllerName) + isValid := validationutil.IsControllerNameValid(tc.controllerName) if isValid != tc.isvalid { t.Errorf("Expected validity %t, got %t", tc.isvalid, isValid) } diff --git a/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml b/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml index bdf27aaaac..052c99680b 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml @@ -174,7 +174,7 @@ spec: If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, - not both. If CACertifcateRefs is empty or unspecified, the configuration for + not both. If CACertificateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation. References to a resource in a different namespace are invalid for the diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index ad9944737e..38a433a38b 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -532,7 +532,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -607,7 +607,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -815,7 +815,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -890,7 +890,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1099,7 +1099,7 @@ spec: Specifying the same filter multiple times is not supported unless explicitly indicated in the filter. - If an implementation can not support a combination of filters, it must clearly + If an implementation cannot support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -1182,7 +1182,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1256,7 +1256,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1463,7 +1463,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1537,7 +1537,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1975,7 +1975,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 527c795f1d..e9d59f53ff 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -524,7 +524,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -599,7 +599,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -960,7 +960,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1035,7 +1035,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1356,7 +1356,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -1378,7 +1378,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -1461,7 +1461,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1535,7 +1535,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1895,7 +1895,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1969,7 +1969,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -2269,7 +2269,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent @@ -2830,7 +2830,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: @@ -3572,7 +3572,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3647,7 +3647,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4008,7 +4008,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4083,7 +4083,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4404,7 +4404,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -4426,7 +4426,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -4509,7 +4509,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4583,7 +4583,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4943,7 +4943,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -5017,7 +5017,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -5317,7 +5317,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent @@ -5878,7 +5878,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index cdbeeb8c08..5d71119425 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -293,7 +293,7 @@ spec: backendRefs: description: |- BackendRefs defines the backend(s) where matching requests should be - sent. If unspecified or invalid (refers to a non-existent resource or a + sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of @@ -488,7 +488,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index 3c5413f96e..f3e63f56dd 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -353,7 +353,7 @@ spec: backendRefs: description: |- BackendRefs defines the backend(s) where matching requests should be - sent. If unspecified or invalid (refers to a non-existent resource or + sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this @@ -551,7 +551,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index 5aec6abf64..2bfcb7aab9 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -293,7 +293,7 @@ spec: backendRefs: description: |- BackendRefs defines the backend(s) where matching requests should be - sent. If unspecified or invalid (refers to a non-existent resource or a + sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of @@ -488,7 +488,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml index 1cd8c79bf6..2950958e76 100644 --- a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml @@ -485,7 +485,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -560,7 +560,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -728,7 +728,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -803,7 +803,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1012,7 +1012,7 @@ spec: Specifying the same filter multiple times is not supported unless explicitly indicated in the filter. - If an implementation can not support a combination of filters, it must clearly + If an implementation cannot support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -1095,7 +1095,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1169,7 +1169,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1336,7 +1336,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1410,7 +1410,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1747,7 +1747,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index fc68fd8e78..0959fb2321 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -477,7 +477,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -552,7 +552,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -873,7 +873,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -948,7 +948,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1269,7 +1269,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -1291,7 +1291,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -1374,7 +1374,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1448,7 +1448,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1768,7 +1768,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1842,7 +1842,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -2142,7 +2142,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent @@ -2515,7 +2515,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: @@ -3192,7 +3192,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3267,7 +3267,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3588,7 +3588,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3663,7 +3663,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3984,7 +3984,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -4006,7 +4006,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -4089,7 +4089,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4163,7 +4163,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4483,7 +4483,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4557,7 +4557,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4857,7 +4857,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent @@ -5230,7 +5230,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/conformance/apis/v1/conformancereport.go b/conformance/apis/v1/conformancereport.go index 94e5e8e064..7f4f4d5325 100644 --- a/conformance/apis/v1/conformancereport.go +++ b/conformance/apis/v1/conformancereport.go @@ -76,10 +76,10 @@ type Implementation struct { // Contact is contact information for the maintainers so that Gateway API // maintainers can get ahold of them as needed. Ideally this should be - // Github usernames (in the form of `@`) or team names (in the + // GitHub usernames (in the form of `@`) or team names (in the // form of `@/`), but when that's not possible it can be email // addresses. - // Rather than Github usernames or email addresses you can provide a URL to the relevant + // Rather than GitHub usernames or email addresses you can provide a URL to the relevant // support pages for the project. Ideally this would be something like the issue creation page // on a repository, but for projects without a publicly exposed repository a general support // page URL can be provided. @@ -90,19 +90,19 @@ type Implementation struct { func (i *Implementation) Validate() error { // TODO: add data validation https://github.com/kubernetes-sigs/gateway-api/issues/2178 if i.Organization == "" { - return errors.New("implementation's organization can not be empty") + return errors.New("implementation's organization cannot be empty") } if i.Project == "" { - return errors.New("implementation's project can not be empty") + return errors.New("implementation's project cannot be empty") } if i.URL == "" { - return errors.New("implementation's url can not be empty") + return errors.New("implementation's url cannot be empty") } if i.Version == "" { - return errors.New("implementation's version can not be empty") + return errors.New("implementation's version cannot be empty") } if len(i.Contact) == 0 { - return errors.New("implementation's contact can not be empty") + return errors.New("implementation's contact cannot be empty") } return nil } diff --git a/conformance/apis/v1/result.go b/conformance/apis/v1/result.go index f3a826c4a2..0fbaec6570 100644 --- a/conformance/apis/v1/result.go +++ b/conformance/apis/v1/result.go @@ -29,7 +29,7 @@ var ( // tests passing without any failures, but some were skipped. Partial Result = "partial" - // Failure indicates that the test run concluded in one ore more tests + // Failure indicates that the test run concluded in one or more tests // failing to complete successfully. Failure Result = "failure" ) diff --git a/conformance/echo-basic/grpc/grpc.go b/conformance/echo-basic/grpc/grpc.go index ffb55189b9..e2f1b88ab8 100644 --- a/conformance/echo-basic/grpc/grpc.go +++ b/conformance/echo-basic/grpc/grpc.go @@ -55,7 +55,7 @@ type serverConfig struct { // Controlled by TLS_SERVER_PRIVKEY env var TLSServerPrivKey string - // Controlled by HTPPS_PORT env var + // Controlled by HTTPS_PORT env var HTTPSPort int } diff --git a/conformance/echo-basic/grpcecho.proto b/conformance/echo-basic/grpcecho.proto index 86c3fe6aed..df744e5b12 100644 --- a/conformance/echo-basic/grpcecho.proto +++ b/conformance/echo-basic/grpcecho.proto @@ -46,13 +46,13 @@ message TLSAssertions { // The TLS version used by the connection, e.g. "TLSv1.3" string version = 1; - // The negotatiated protocol. + // The negotiated protocol. string negotiated_protocol = 2; // The server name indication extension sent by the client. string server_name = 3; - // The cipher suite negotatiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" + // The cipher suite negotiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" string cipher_suite = 4; // The parsed certificates sent by the peer, in the order in which they were sent. diff --git a/conformance/echo-basic/grpcechoserver/grpcecho.pb.go b/conformance/echo-basic/grpcechoserver/grpcecho.pb.go index 9585b7760b..88207f3fe4 100644 --- a/conformance/echo-basic/grpcechoserver/grpcecho.pb.go +++ b/conformance/echo-basic/grpcechoserver/grpcecho.pb.go @@ -177,11 +177,11 @@ type TLSAssertions struct { // The TLS version used by the connection, e.g. "TLSv1.3" Version string `protobuf:"bytes,1,opt,name=version,proto3" json:"version,omitempty"` - // The negotatiated protocol. + // The negotiated protocol. NegotiatedProtocol string `protobuf:"bytes,2,opt,name=negotiated_protocol,json=negotiatedProtocol,proto3" json:"negotiated_protocol,omitempty"` // The server name indication extension sent by the client. ServerName string `protobuf:"bytes,3,opt,name=server_name,json=serverName,proto3" json:"server_name,omitempty"` - // The cipher suite negotatiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" + // The cipher suite negotiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" CipherSuite string `protobuf:"bytes,4,opt,name=cipher_suite,json=cipherSuite,proto3" json:"cipher_suite,omitempty"` // The parsed certificates sent by the peer, in the order in which they were sent. PeerCertificates []string `protobuf:"bytes,5,rep,name=peer_certificates,json=peerCertificates,proto3" json:"peer_certificates,omitempty"` diff --git a/conformance/reports/README.md b/conformance/reports/README.md index 98e8ffc34a..241ffc9d66 100644 --- a/conformance/reports/README.md +++ b/conformance/reports/README.md @@ -110,7 +110,7 @@ comply with the following rules: - `contact`: it indicates the GitHub usernames of those who are responsible for maintaining this file, so they can be easily contacted when needed (e.g. for relevant release announcements regarding conformance, etc.). Optionally, it - can be an email address or a support URL (e.g. Github new issue page). + can be an email address or a support URL (e.g. GitHub new issue page). - `url`: it must be a valid url for a GitHub repository, or any other website with information related to the project. - `version`: it must be a snapshot of the project, which means it can be a commit, diff --git a/conformance/utils/suite/suite_test.go b/conformance/utils/suite/suite_test.go index 639fc6ca2a..951571f7aa 100644 --- a/conformance/utils/suite/suite_test.go +++ b/conformance/utils/suite/suite_test.go @@ -181,7 +181,7 @@ func TestGetAPIVersionAndChannel(t *testing.T) { } const ( - coreFeature features.FeatureName = "coreFature" + coreFeature features.FeatureName = "coreFeature" extendedFeature features.FeatureName = "extendedFeature" testProfileName ConformanceProfileName = "testProfile" diff --git a/geps/gep-1016/index.md b/geps/gep-1016/index.md index afd96ef57d..08576730ca 100644 --- a/geps/gep-1016/index.md +++ b/geps/gep-1016/index.md @@ -50,7 +50,7 @@ lower layer protocol already exists. We propose the following criteria for such an addition. - Users of the encapsulated protocol would miss out on significant conventional features from their ecosystem if forced to route at a lower layer. -- Users of the enapsulated protocol would experience a degraded user experience if forced to route at a lower layer. +- Users of the encapsulated protocol would experience a degraded user experience if forced to route at a lower layer. - The encapsulated protocol has a significant user base, particularly in the Kubernetes community. gRPC meets _all_ of these criteria and is therefore, we contend, a strong @@ -424,7 +424,7 @@ type GRPCRouteRule struct { // BackendRefs defines the backend(s) where matching requests should be // sent. - // If unspecified or invalid (refers to a non-existent resource or a Service + // If unspecified or invalid (refers to a nonexistent resource or a Service // with no endpoints), the rule performs no forwarding. If there are also no // filters specified that would result in a response being sent, a gRPC `UNAVAILABLE` // status is returned. `UNAVAILABLE` responses must be sent so that the overall diff --git a/geps/gep-1282/index.md b/geps/gep-1282/index.md index c8a54f74a1..dead0babfa 100644 --- a/geps/gep-1282/index.md +++ b/geps/gep-1282/index.md @@ -53,7 +53,7 @@ We've got the following feature requests and discussions in the Gateway API repo - [#1285](https://github.com/kubernetes-sigs/gateway-api/discussions/1285) has a more specific discussion about how different ingress implementations allow this to be configured today, whether that's with the Ingress resource or their own custom one. The great roundup that Candace did is reproduced in the next few bullet points. * Istio uses a [DestinationRule resource with ClientTLSSettings](https://istio.io/latest/docs/reference/config/networking/destination-rule/#ClientTLSSettings) to capture TLS details, and the DestinationRule resource also holds traffic policy information like load balancing algorithm, connection pool size, and so on. * Openshift’s Route resource allows the [configuration of reencryption](https://docs.openshift.com/container-platform/4.10/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes) specifically, along with custom certificate details. - * Contour’s HTTPProxy captures TLS details using an Envoy client certificate, destination CA certificate, and optional SubjectName which sets what Envoy should expect to see from the backend service, all inside the HTTPProxy resource. It also requires either a Protocol field inside the HTTProxy, or an annotation on the Service that tells Contour that the service expects TLS. This is [all documented](https://projectcontour.io/docs/v1.21.1/config/upstream-tls/), but I should note that Contour’s docs use the Envoy convention where a backend in Gateway parlance is called an Upstream (which may be confusing if you’re not used to it). + * Contour’s HTTPProxy captures TLS details using an Envoy client certificate, destination CA certificate, and optional SubjectName which sets what Envoy should expect to see from the backend service, all inside the HTTPProxy resource. It also requires either a Protocol field inside the HTTPProxy, or an annotation on the Service that tells Contour that the service expects TLS. This is [all documented](https://projectcontour.io/docs/v1.21.1/config/upstream-tls/), but I should note that Contour’s docs use the Envoy convention where a backend in Gateway parlance is called an Upstream (which may be confusing if you’re not used to it). * Linkerd uses a [Server resource](https://linkerd.io/2.11/reference/authorization-policy/#server) (which is functionally pretty similar to Service in that it associates a name with a Pod selector, but also has other details like if the service supports Proxy protocol), along with a ServerAuthorization resource that specifies some constructs that sit more at the service mesh level, including identity and access control. In terms of other implementations existing use cases for features like this: diff --git a/geps/gep-1364/index.md b/geps/gep-1364/index.md index b33fee3850..25c879f907 100644 --- a/geps/gep-1364/index.md +++ b/geps/gep-1364/index.md @@ -42,7 +42,7 @@ these changes. The constants that mark the deprecated types will be also marked as deprecated, and will no longer be tested as part of conformance. They'll still be present, -and will work, but they won't be part of the spec any more. This should give +and will work, but they won't be part of the spec anymore. This should give implementations and users a release to transition to the new design (in UX terms). This grace period should be one release (so, the constants will be removed in v0.7.0.) @@ -323,13 +323,13 @@ Note that some classes of inter-resource reference failure do _not_ cause a reso to become unattached and stop being accepted (that is, to have the `Accepted` condition set to `status: false`). -* Non-existent Service backends - if the backend does not exist on a HTTPRoute that +* Nonexistent Service backends - if the backend does not exist on a HTTPRoute that is otherwise okay, then the data plane must generate 500s for traffic that matches that HTTPRoute. In this case, the `Accepted` Condition must be true, and the `ResolvedRefs` Condition must be false, with reasons and messages indicating that the backend services do not exist. * HTTPRoutes with *all* backends in other namespaces, but not permitted by ReferenceGrants. -In this case, the "non-existent service backends" rules apply, and 500s must be +In this case, the "nonexistent service backends" rules apply, and 500s must be generated. In this case, again, the `Accepted` condition is true, and the `ResolvedRefs` Condition is false, with reasons and messages indicating that the backend services are not reachable. @@ -359,21 +359,21 @@ Examples of Conditions: * HTTPRoute with one match with one backend that is valid. `Accepted` is true, `ResolvedRefs` is true. -* HTTPRoute with one match with one backend that is a non-existent Service backend. +* HTTPRoute with one match with one backend that is a nonexistent Service backend. The `Accepted` Condition is true, the `ResolvedRefs` condition is false, with a reason of `BackendNotFound`. `Accepted` is true in this case because the data path must respond to requests that would be sent to that backend with a 500 response. -* HTTPRoute with one match with two backends, one of which is a non-existent Service +* HTTPRoute with one match with two backends, one of which is a nonexistent Service backend. The `Accepted` Condition is true, the `ResolvedRefs` condition is false. `Accepted` is true in this case because the data path must respond to a percentage -of the requests matching the rule corresponding to the weighting of the non-existent +of the requests matching the rule corresponding to the weighting of the nonexistent backend (which would be fifty percent unless weights are applied). * HTTPRoute with one match with one backend that is in a different namespace, and does _not_ have a ReferenceGrant permitting that access. The `Accepted` condition is true, and the `ResolvedRefs` Condition is false, with a reason of `RefNotPermitted`. As before, `Accepted` is true because in this case, the data path must be programmed with 500s for the match. -* TCPRoute with one match with a backend that is a non-existent Service. `Accepted` +* TCPRoute with one match with a backend that is a nonexistent Service. `Accepted` is false, and `ResolvedRefs` is false. `Accepted` is false in this case because there is not enough information to program any rules to handle the traffic in the underlying data plane - TCP doesn't have a way to say "this is a valid destination @@ -418,7 +418,7 @@ For many implementations (certainly for Envoy-based ones), getting this informat correctly and avoiding races on applying it is surprisingly difficult. For this reason, this GEP proposes that we exclude the `Ready` condition from Core -conformance, and make it a feature that implementations may opt in to - making it +conformance, and make it a feature that implementations may opt into - making it an Extended condition. It will have the following behavior: diff --git a/geps/gep-1619/index.md b/geps/gep-1619/index.md index 389d0a72cf..a1e41138f2 100644 --- a/geps/gep-1619/index.md +++ b/geps/gep-1619/index.md @@ -978,7 +978,7 @@ spec: This is an invalid configuration as two separate sessions cannot have the same cookie name. Implementations SHOULD address this scenario in manner they deem appropriate. Implementations MAY choose to reject the configuration, or they -MAY non-deterministicly allow one cookie to work (e.g. whichever cookie is configured first). +MAY non-deterministically allow one cookie to work (e.g. whichever cookie is configured first). #### Traffic Splitting with route rule inline sessionPersistence field @@ -1069,7 +1069,7 @@ TODO ### Open Questions - What happens when session persistence causes traffic splitting scenarios to overload a backend? -- Should we add status somewhere when a user gets in to a "risky" configuration with session persistence? +- Should we add status somewhere when a user gets into a "risky" configuration with session persistence? - Should there be an API configuration field that specifies how already established sessions are handled? - How do implementations drain established sessions during backend upgrades without disruption? - Do we need a "session draining timeout" as documented by [A55: xDS-Based Stateful Session Affinity for Proxyless gRPC](https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md#background) diff --git a/geps/gep-1686/index.md b/geps/gep-1686/index.md index eacf2a723c..22ecb477ef 100644 --- a/geps/gep-1686/index.md +++ b/geps/gep-1686/index.md @@ -23,9 +23,9 @@ The goal of the initial conformance testing is to check the essential behavior a GAMMA intends to introduce a "Mesh" [conformance profile](https://gateway-api.sigs.k8s.io/geps/gep-1709/) to isolate tests specific to East/West functionality from both existing tests focused on North/South functionality and common Gateway API functionality shared by N/S and E/W implementations. A conformance profile is a set of tests that implementations can run to check their conformance to some subset of the Gateway API spec. -This appropach will enable service meshes to certify that an implementation follows the GAMMA spec without requiring a North/South implementation, and importantly avoid any expectation that North/South Gateway API implementations expand their scope to understand GAMMA and E/W traffic flows. +This approach will enable service meshes to certify that an implementation follows the GAMMA spec without requiring a North/South implementation, and importantly avoid any expectation that North/South Gateway API implementations expand their scope to understand GAMMA and E/W traffic flows. -Leveraging existing tests for common functionality between N/S and E/W implementations will both ensure consistency across Gateway API implementations and help limit the maintence burden for the conformance testing suite. +Leveraging existing tests for common functionality between N/S and E/W implementations will both ensure consistency across Gateway API implementations and help limit the maintenance burden for the conformance testing suite. ### Support Levels @@ -80,7 +80,7 @@ producer). - Assert that traffic from a client in a different `Namespace` is routed by the `HTTPRoute` -A consumer `HTTPRoute` is in the same `Namespace` as the the request sender (the +A consumer `HTTPRoute` is in the same `Namespace` as the request sender (the consumer), a different `Namespace` as the `parentRef` `Service`. - Given a consumer `HTTPRoute` diff --git a/geps/gep-1709/index.md b/geps/gep-1709/index.md index 102a00b2ae..c145975277 100644 --- a/geps/gep-1709/index.md +++ b/geps/gep-1709/index.md @@ -358,7 +358,7 @@ profiles: > **WARNING**: It is an important clarification that this is NOT a full > Kubernetes API. It uses `TypeMeta` for some fields that made sense to re-use -> and were familiar, but otherwise has it's own structure. It is not a [Custom +> and were familiar, but otherwise has its own structure. It is not a [Custom > Resource Definition (CRD)][crd] nor will it be made available along with our > CRDs. It will be used only by conformance test tooling. @@ -368,11 +368,11 @@ profiles: > theoretically have multiple projects and should submit separate reports for > each of them. -> **NOTE**: The `contact` field indicates the Github usernames or team +> **NOTE**: The `contact` field indicates the GitHub usernames or team > names of those who are responsible for maintaining this file, so they can be > easily contacted when needed (e.g. for relevant release announcements > regarding conformance, e.t.c.). Optionally, it can be an email address or -> a support URL (e.g. Github new issue page). +> a support URL (e.g. GitHub new issue page). The above report describes an implementation that just released `v1`, uses gateway API `v0.8.0` `experimental` channel, and has `HTTP` `core` and `extended` and `TCP` diff --git a/geps/gep-1731/index.md b/geps/gep-1731/index.md index f7785e13d5..cb479ed126 100644 --- a/geps/gep-1731/index.md +++ b/geps/gep-1731/index.md @@ -272,7 +272,7 @@ type HTTPRouteRetry struct { // Codes []HTTPRouteRetryStatusCode `json:"codes,omitempty"` - // Attempts specifies the maxmimum number of times an individual request + // Attempts specifies the maximum number of times an individual request // from the gateway to a backend should be retried. // // If the maximum number of retries has been attempted without a successful @@ -354,7 +354,7 @@ type HTTPRouteRetry struct { // +kubebuilder:validation:Maximum:=999 type HTTPRouteRetryStatusCode int -// Duration is a string value representing a duration in time. The foramat is +// Duration is a string value representing a duration in time. The format is // as specified in GEP-2257, a strict subset of the syntax parsed by Golang // time.ParseDuration. // @@ -391,21 +391,21 @@ Basic support for configuring retries in HTTPRoute up to a specified maximum cou Retrying requests based on HTTP status codes will be gated under the following features: -* `SupportHTTPRRouteRetryBackendTimeout` +* `SupportHTTPRouteRetryBackendTimeout` * Will test that backend requests that exceed a BackendRequest timeout duration are retried if a `retry` stanza is configured. -* `SupportHTTPRRouteRetryBackoff` +* `SupportHTTPRouteRetryBackoff` * Backoff will only be tested that a retry does not start before the duration specified for conformance, not that the backoff duration is precise. * Not currently supportable by NGINX or HAProxy. -* `SupportHTTPRRouteRetryCodes` +* `SupportHTTPRouteRetryCodes` * Only 500, 502, 503 and 504 will be tested for conformance. * Traefik does not seem to support specifying error codes, and will only retry on backend timeouts. -* `SupportHTTPRRouteRetryConnectionError` +* `SupportHTTPRouteRetryConnectionError` * Will test that connections interrupted by a TCP failure, disconnect or reset are retried if a `retry` stanza is configured. diff --git a/geps/gep-1731/metadata.yaml b/geps/gep-1731/metadata.yaml index 2bb398026b..c85ccbcb0c 100644 --- a/geps/gep-1731/metadata.yaml +++ b/geps/gep-1731/metadata.yaml @@ -4,7 +4,7 @@ number: 1731 name: HTTPRoute Retries status: Experimental # Any authors who contribute to the GEP in any way should be listed here using -# their Github handle. +# their GitHub handle. authors: - mikemorris relationships: @@ -13,7 +13,7 @@ relationships: # set back to this GEP, and MUST be moved to Declined. obsoletes: {} obsoletedBy: {} - # extends indicates that a GEP extends the linkned GEP, adding more detail + # extends indicates that a GEP extends the linked GEP, adding more detail # or additional implementation. The extended GEP MUST have its extendedBy # field set back to this GEP. extends: {} @@ -30,7 +30,7 @@ relationships: name: HTTPRoute Timeouts description: Covers some overlapping considerations around when requests should be retried. # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: - https://www.rfc-editor.org/rfc/rfc9110 - https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml diff --git a/geps/gep-1742/index.md b/geps/gep-1742/index.md index 39ab142b86..2019b5e505 100644 --- a/geps/gep-1742/index.md +++ b/geps/gep-1742/index.md @@ -476,7 +476,7 @@ Timeouts could be configured using policy attachments or in objects other than ` Instead of configuring timeouts directly on an API object, they could be configured using policy attachments. The advantage to this approach would be that timeout policies can be not only -configured for an `HTTPRouteRule`, but can also be added/overriden at a more fine +configured for an `HTTPRouteRule`, but can also be added/overridden at a more fine (e.g., `HTTPBackendRef`) or coarse (e.g. `HTTPRoute`) level of granularity. The downside, however, is complexity introduced for the most common use case, adding a simple diff --git a/geps/gep-1762/metadata.yaml b/geps/gep-1762/metadata.yaml index c38ad6a101..2f5677ef7d 100644 --- a/geps/gep-1762/metadata.yaml +++ b/geps/gep-1762/metadata.yaml @@ -5,7 +5,7 @@ name: In Cluster Gateway Deployments status: Standard authors: - howardjohn - - frakbu + - frankbu relationships: extendedBy: - number: 1867 diff --git a/geps/gep-1897/index.md b/geps/gep-1897/index.md index 63e3102767..09f6195fa5 100644 --- a/geps/gep-1897/index.md +++ b/geps/gep-1897/index.md @@ -216,9 +216,9 @@ specified as ""). The use and definition of system certificates is implementati these certificates are obtained from the underlying operating system. CACertificateRefs contains one or more references to Kubernetes objects that contain PEM-encoded TLS certificates, which are used to establish a TLS handshake between the gateway and backend pod. References to a resource in a different namespace are invalid. -If ClientCertifcateRefs is unspecified, then WellKnownCACertificates must be set to "System" for a valid configuration. +If ClientCertificateRefs is unspecified, then WellKnownCACertificates must be set to "System" for a valid configuration. If WellKnownCACertificates is unspecified, then CACertificateRefs must be specified with at least one entry for a valid configuration. -If WellKnownCACertficates is set to "System" and there are no system trusted certificates or the implementation doesn't define system +If WellKnownCACertificates is set to "System" and there are no system trusted certificates or the implementation doesn't define system trusted certificates, then the associated TLS connection must fail. The `Hostname` field is required and is to be used to configure the SNI the Gateway should use to connect to the backend. @@ -342,7 +342,7 @@ Ref: [TLS Origination](https://www.getambassador.io/docs/emissary/latest/topics/ ### NGINX implementation through CRDs (Comparable to Route or Policy of Gateway API) supports both TLS and mTLS * In the Upstream section of a VirtualServer or VirtualServerRoute (equivalent to HTTPRoute) there is a simple toggle to enable TLS. This does not validate the certificate of the backend and implicitly trusts the backend in order to form the SSL tunnel. This is not about validating the certificate but obfuscating the traffic with TLS/SSL. -* A Policy attachment can be provided when certification validation is required that is called egressMTLS (egress from the proxy to the upstream). This can be tuned to perform various certificate validation tests. It was created as a Policy becuase it implies some type of AuthN/AuthZ due to the additional checks. This was also compatible with Open Service Mesh and NGINX Service Mesh and removed the need for a sidecar at the ingress controller. +* A Policy attachment can be provided when certification validation is required that is called egressMTLS (egress from the proxy to the upstream). This can be tuned to perform various certificate validation tests. It was created as a Policy because it implies some type of AuthN/AuthZ due to the additional checks. This was also compatible with Open Service Mesh and NGINX Service Mesh and removed the need for a sidecar at the ingress controller. * A corresponding 'IngressMTLS' policy also exists for mTLS verification of client connections to the proxy. The Policy object is used for anything that implies AuthN/AuthZ. Ref: [Upstream.TLS](https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#upstreamtls) diff --git a/geps/gep-1911/index.md b/geps/gep-1911/index.md index ed25229444..d0db118a75 100644 --- a/geps/gep-1911/index.md +++ b/geps/gep-1911/index.md @@ -48,7 +48,7 @@ At the moment there exists three defined constants: ### New Protocols & Reserved Prefix -To add support for a new protocol it should first become a Kubernetes Standard Application Protocol by updating the [KEP-3726][kep-3726]. [KEP-3726][kep-3726] also states the `appProtocol` field accepts a domain-prefixed implementation specific value. Thus, if the suggested protocol is not suited to have a `kubernetes.io/*` prefix, then the Gateway API MAY support the new protocol using it's own prefix `gateway.networking.k8s.io/*`. Please make a PR to this GEP. +To add support for a new protocol it should first become a Kubernetes Standard Application Protocol by updating the [KEP-3726][kep-3726]. [KEP-3726][kep-3726] also states the `appProtocol` field accepts a domain-prefixed implementation specific value. Thus, if the suggested protocol is not suited to have a `kubernetes.io/*` prefix, then the Gateway API MAY support the new protocol using its own prefix `gateway.networking.k8s.io/*`. Please make a PR to this GEP. For example we may want to add a sentinel `appProtocol` value that prevents Gateway implementations from discovering the protocol of the application. Instead they should just refer to the Service's `protocol` field. Such a constant was rejected upstream (https://github.com/kubernetes/enhancements/pull/4106) but as an example it could be defined in a future addition to this GEP as `gateway.networking.k8s.io/no-sniff`. @@ -116,7 +116,7 @@ This was dropped in favour of supporting Kubernetes Standard Application Protoco ### Multiple Protocol Meta-resources Rather than bundle protocol details into a single resource an alternative would be to create distinct meta resources. -ie. `HTTP2Backend`, `GPRCBackend`, `WebsocketBackend`. +ie. `HTTP2Backend`, `GRPCBackend`, `WebsocketBackend`. The advantages of this approach are: diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md index 43f5d052d1..1000e3eea1 100644 --- a/geps/gep-2162/index.md +++ b/geps/gep-2162/index.md @@ -123,7 +123,7 @@ Every feature should: #### Conformance test names -Conformance tests file names should try to follow the the `pascal-case-name.go` format. +Conformance tests file names should try to follow the `pascal-case-name.go` format. For example for `HTTPRoutePortRedirect` - the test file would be `httproute-port-redirect.go`. We should treat this guidance as "best effort" because we might have test files that check the combination of several features and can't follow the same format. @@ -179,7 +179,7 @@ Once the GatewayClass features support are is published into the status we could ### Add Gateway API Version field to the GatewayClass Status -We got some feedback that it will be useful to indicate what what Gateway API version the implementation supports. So when we have supported features published in the GatewayClass Status, users will also be able to understand that those are the supported features for a specific Gateway API version. +We got some feedback that it will be useful to indicate which Gateway API version the implementation supports. So when we have supported features published in the GatewayClass Status, users will also be able to understand that those are the supported features for a specific Gateway API version. This work is likely to require its own small GEP but ideally what this field would mean is that an implementation supports Max(vX.X). diff --git a/geps/gep-2648/index.md b/geps/gep-2648/index.md index 681cf15ae5..05a0a44667 100644 --- a/geps/gep-2648/index.md +++ b/geps/gep-2648/index.md @@ -95,7 +95,7 @@ the Policy object, the DataplaneConfig object does not affect if the Policy is a Direct one or not. This is because _a user can understand the state of the hierarchy by looking at all the objects in the hierarchy_. DataplaneConfig is _outside_ the hierarchy in terms of understanding the state of the Policy. -Direct Attacthed Policy is intended as a way to _manage the complexity_ of +Direct Attached Policy is intended as a way to _manage the complexity_ of Policy objects and allow a _limited_ set of Policies to follow vastly more simple design patterns _if they meet a set of criteria_. @@ -300,7 +300,7 @@ const ( Implementations that use Direct Policy objects SHOULD put a Condition into `status.Conditions` of any objects affected by a Direct Policy, if that field is present. Ideally, there should be a set of Conditions that can be namespaced -by the implementing controller, but if that is not posisble, use the guidance below. +by the implementing controller, but if that is not possible, use the guidance below. If they do, that Condition MUST have a `type` ending in `PolicyAffected` (like `gateway.networking.k8s.io/PolicyAffected`), diff --git a/geps/gep-2648/metadata.yaml b/geps/gep-2648/metadata.yaml index fe9fe84336..7e9b54a867 100644 --- a/geps/gep-2648/metadata.yaml +++ b/geps/gep-2648/metadata.yaml @@ -4,7 +4,7 @@ number: 2648 name: Direct Policy Attachment status: Provisional # Any authors who contribute to the GEP in any way should be listed here using -# their Github handle. +# their GitHub handle. authors: - youngnick - robscott @@ -14,7 +14,7 @@ relationships: number: 713 description: Split out Direct Policy Attachment into its own GEP # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: - "https://github.com/kubernetes-sigs/gateway-api/discussions/2927" # changelog is a list of hyperlinks to PRs that make changes to the GEP, in diff --git a/geps/gep-2649/index.md b/geps/gep-2649/index.md index a6f18877f7..6823cfb000 100644 --- a/geps/gep-2649/index.md +++ b/geps/gep-2649/index.md @@ -60,7 +60,7 @@ an Inherited Policy. Note that the same object may be have some properties of both an Inherited Policy _and_ a Direct Policy if it can attach to multiple points of a hierarchy, such -as if the same Policy can be atttached to a Gateway (where it affects all Routes +as if the same Policy can be attached to a Gateway (where it affects all Routes attached to that Gateway) or to a Route (where it affects only that Route). If a Policy _can be_ used as an Inherited Policy, it MUST be treated as an diff --git a/geps/gep-2649/metadata.yaml b/geps/gep-2649/metadata.yaml index b6eda3b455..403a0c72ec 100644 --- a/geps/gep-2649/metadata.yaml +++ b/geps/gep-2649/metadata.yaml @@ -12,7 +12,7 @@ relationships: number: 713 description: Split out Inherited Policy Attachment # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: - "https://github.com/kubernetes-sigs/gateway-api/discussions/2927" # changelog is a list of hyperlinks to PRs that make changes to the GEP, in diff --git a/geps/gep-2659/index.md b/geps/gep-2659/index.md index b2838a7caf..3e11ff071a 100644 --- a/geps/gep-2659/index.md +++ b/geps/gep-2659/index.md @@ -87,7 +87,7 @@ Memorandum GEPs after this GEP is merged. ### Addition of YAML metadata file -The core Gateway API mainatainers were hoping not to need metadata YAMLs for a +The core Gateway API maintainers were hoping not to need metadata YAMLs for a while, but the addition of relationships has turbocharged the need for machine parseable GEP metadata. @@ -118,7 +118,7 @@ relationships: # set back to this GEP, and MUST be moved to Declined. obsoletes: {} obsoletedBy: {} - # extends indicates that a GEP extends the linkned GEP, adding more detail + # extends indicates that a GEP extends the linked GEP, adding more detail # or additional implementation. The extended GEP MUST have its extendedBy # field set back to this GEP. extends: {} @@ -127,7 +127,7 @@ relationships: # covered by an existing relationship. seeAlso: {} # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: {} # featureNames is a list of the feature names introduced by the GEP, if there # are any. This will allow us to track which feature was introduced by which GEP. diff --git a/geps/gep-3155/index.md b/geps/gep-3155/index.md index 8652b3b13b..2fb1089295 100644 --- a/geps/gep-3155/index.md +++ b/geps/gep-3155/index.md @@ -64,7 +64,7 @@ type GatewayBackendTLS struct { // ClientCertificateRef can reference to standard Kubernetes resources, i.e. // Secret, or implementation-specific custom resources. // - // This setting can be overriden on the service level by use of BackendTLSPolicy. + // This setting can be overridden on the service level by use of BackendTLSPolicy. ClientCertificateRef SecretObjectReference `json:"clientCertificateRef,omitempty"` } ``` diff --git a/geps/gep-3171/index.md b/geps/gep-3171/index.md index fbf21c4c3c..25ffd5d26d 100644 --- a/geps/gep-3171/index.md +++ b/geps/gep-3171/index.md @@ -22,7 +22,7 @@ The scope of this GEP is to add support for this feature in both HTTPRoute and G [Request Mirroring](https://gateway-api.sigs.k8s.io/guides/http-request-mirroring/) is a feature that allows a user to mirror requests going to some backend A along to some other specified backend B. Right now Request Mirroring is an all or nothing feature – either 100% of request are mirrored, or 0% are. Percentage-based Request Mirroring will allow users to specify a percentage of requests they'd like mirrored as opposed to every single request. -This feature is already [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routeaction-requestmirrorpolicy), so adding it for the Gateway API would enable better integration between the two products. There's also an existing user desire for this feature on the [HAProxy side](https://www.haproxy.com/blog/haproxy-traffic-mirroring-for-real-world-testing) and [NGINX side](https://alex.dzyoba.com/blog/nginx-mirror/). Since Request Mirroring is already supported by the Gateway API, Percentage-based Request Mirroring would a clear improvement on this pre-existing feature. +This feature is already [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routeaction-requestmirrorpolicy), so adding it for the Gateway API would enable better integration between the two products. There's also an existing user desire for this feature on the [HAProxy side](https://www.haproxy.com/blog/haproxy-traffic-mirroring-for-real-world-testing) and [NGINX side](https://alex.dzyoba.com/blog/nginx-mirror/). Since Request Mirroring is already supported by the Gateway API, Percentage-based Request Mirroring would a clear improvement on this preexisting feature. ## Existing Support in Implementations diff --git a/geps/gep-696/metadata.yaml b/geps/gep-696/metadata.yaml index efcc0d2f03..cd15a89cd4 100644 --- a/geps/gep-696/metadata.yaml +++ b/geps/gep-696/metadata.yaml @@ -4,7 +4,7 @@ number: 696 name: GEP template status: Completed # Any authors who contribute to the GEP in any way should be listed here using -# their Github handle. +# their GitHub handle. authors: - bowei - robscott @@ -16,7 +16,7 @@ relationships: # set back to this GEP, and MUST be moved to Declined. obsoletes: {} obsoletedBy: {} - # extends indicates that a GEP extends the linkned GEP, adding more detail + # extends indicates that a GEP extends the linked GEP, adding more detail # or additional implementation. The extended GEP MUST have its extendedBy # field set back to this GEP. extends: {} @@ -25,7 +25,7 @@ relationships: # covered by an existing relationship. seeAlso: {} # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: {} # featureNames is a list of the feature names introduced by the GEP, if there # are any. This will allow us to track which feature was introduced by which GEP. diff --git a/geps/gep-709/index.md b/geps/gep-709/index.md index a4a8d21379..1a2ea88f5f 100644 --- a/geps/gep-709/index.md +++ b/geps/gep-709/index.md @@ -132,7 +132,7 @@ type ReferenceGrantSpec struct { // ReferenceGrantFrom describes trusted namespaces and kinds. type ReferenceGrantFrom struct { - // Group is the group of the referrent. + // Group is the group of the referent. // // Support: Core // @@ -140,7 +140,7 @@ type ReferenceGrantFrom struct { // +kubebuilder:validation:MaxLength=253 Group string `json:"group"` - // Kind is the kind of the referrent. Although implementations may support + // Kind is the kind of the referent. Although implementations may support // additional resources, the following Route types are part of the "Core" // support level for this field: // @@ -153,7 +153,7 @@ type ReferenceGrantFrom struct { // +kubebuilder:validation:MaxLength=253 Kind string `json:"kind"` - // Namespace is the namespace of the referrent. + // Namespace is the namespace of the referent. // // Support: Core // @@ -165,7 +165,7 @@ type ReferenceGrantFrom struct { // ReferenceGrantTo describes what Kinds are allowed as targets of the // references. type ReferenceGrantTo struct { - // Group is the group of the referrent. + // Group is the group of the referent. // // Support: Core // @@ -173,7 +173,7 @@ type ReferenceGrantTo struct { // +kubebuilder:validation:MaxLength=253 Group string `json:"group"` - // Kind is the kind of the referrent. Although implementations may support + // Kind is the kind of the referent. Although implementations may support // additional resources, the following types are part of the "Core" // support level for this field: // diff --git a/geps/gep-713/index.md b/geps/gep-713/index.md index b6dfa8366c..3fa9fba4ad 100644 --- a/geps/gep-713/index.md +++ b/geps/gep-713/index.md @@ -54,7 +54,7 @@ more resources, and are consequently harder to understand and require a more complex status design. Splitting these two design patterns apart into separate GEPs is intended to -allow proceeding with stablizing the simpler (Direct) case while we work on +allow proceeding with stabilizing the simpler (Direct) case while we work on solving the status problem for the more complex (Inherited) case. Direct Attached Policies are further specified in the addendum GEP GEP-2648, @@ -555,7 +555,7 @@ that _every_ Policy update does not require a status update. Because Policy Attachment is a pattern for APIs, not an API, and needs to address all the problems above, the strategy this GEP proposes is to define a range of -options for increasing the discoverabilty of Policy resources, and provide +options for increasing the discoverability of Policy resources, and provide guidelines for when they should be used. It's likely that at some stage, the Gateway API CRDs will include some Policy @@ -588,7 +588,7 @@ plugin. ##### Design considerations -This is already part of the API pattern, but is being lifted to more prominience +This is already part of the API pattern, but is being lifted to more prominence here. #### Standard status struct @@ -789,7 +789,7 @@ This solution: - is low cost in terms of apiserver updates (because it's only on the GatewayClass, and only on implementation startup) - provides a standard place for all users to look for relevant objects -- ties in to the Conformance Profiles design and other efforts about GatewayClass +- ties into the Conformance Profiles design and other efforts about GatewayClass status #### Standard status stanza @@ -871,7 +871,7 @@ contains `status` information. ```yaml kind: EffectivePolicy -apiVersion: gateway.networkking.k8s.io/v1alpha2 +apiVersion: gateway.networking.k8s.io/v1alpha2 metadata: name: targeted-object namespace: targeted-object-namespace diff --git a/geps/gep-724/index.md b/geps/gep-724/index.md index bb1e9854f9..5fdd108f8b 100644 --- a/geps/gep-724/index.md +++ b/geps/gep-724/index.md @@ -618,7 +618,7 @@ bar namespace. Unfortunately that would be very difficult to recreate with ReferenceGrant. ReferenceGrant is fundamentally about trusting references from resource of kind -Foo in to resources of kind Bar. Names and section names are intentionally +Foo in resources of kind Bar. Names and section names are intentionally excluded. If we added both of those concepts to ReferenceGrant, this would be possible, but quite complex and verbose. This is what the example from above would look like with this approach: diff --git a/geps/gep-746/index.md b/geps/gep-746/index.md index 475a0ae8f3..4c0f33be9a 100644 --- a/geps/gep-746/index.md +++ b/geps/gep-746/index.md @@ -176,7 +176,7 @@ type TLSRouteOverrideType string const ( // Allows the parameter to be configured from all routes. - TLSROuteOVerrideAllow TLSRouteOverrideType = "Allow" + TLSRouteOverrideAllow TLSRouteOverrideType = "Allow" // Prohibits the parameter from being configured from any route. TLSRouteOverrideDeny TLSRouteOverrideType = "Deny" diff --git a/geps/gep-820/index.md b/geps/gep-820/index.md index e683060ed8..78b92a9424 100644 --- a/geps/gep-820/index.md +++ b/geps/gep-820/index.md @@ -52,7 +52,7 @@ The following fields and all associated documentation will be removed: - HTTPRouteMatch.ExtensionRef - TCPRouteMatch.ExtensionRef will be removed. This results in a struct without any members: TCPRouteMatch. The struct will be kept as it is expected that - more match criterias might be added to L4 routes. + more match criteria might be added to L4 routes. - Do the same to UDPRoute and TLSRoute diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 5999bf9a9b..fd53abc411 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -151,7 +151,7 @@ spec: This section highlights use cases that may be covered in a future iteration of this GEP * Using system CA certificates as the trust anchor to validate the certificates presented by the frontend client. -* Supporting a mode where validating client certficates is optional, useful for debugging and migrating to strict TLS. +* Supporting a mode where validating client certificates is optional, useful for debugging and migrating to strict TLS. * Supporting an optional `subjectAltNames` field within `FrontendTLSValidation` that can be used to specify one or more alternate names to verify the subject identity in the certificate presented by the client. This field falls under Authorization, the initial focus here is on Client Authentication and will be revisited when Authorization is tackled as a whole in the project. * Specifying the verification depth in the client certificate chain. This is being deferred because the default verification depth differs across implementations. diff --git a/geps/gep-922/index.md b/geps/gep-922/index.md index a1afba7965..23b6153111 100644 --- a/geps/gep-922/index.md +++ b/geps/gep-922/index.md @@ -51,7 +51,7 @@ and/or removing old ones as part of a new bundle. ## Limitations of Webhook and CRD Validation CRD and webhook validation is not the final validation i.e. webhook is “nice UX” but not schema enforcement. This validation is intended to provide immediate -feedback to users when they provide an invalid configuration, but can not +feedback to users when they provide an invalid configuration, but cannot completely be relied on because it: * Is not guaranteed to be present or up to date in all clusters. diff --git a/geps/gep-957/index.md b/geps/gep-957/index.md index f4de43e304..577076a16d 100644 --- a/geps/gep-957/index.md +++ b/geps/gep-957/index.md @@ -120,7 +120,7 @@ spec: Port matching can be supported if SectionName accepts port numbers in addition to listener names. This approach results in a less explicit API when a ParentRef points to a resource that is not `Gateway`. For example, an implementation may -attach a route to an `Mesh` CRD. In this case, it's less inituitive to set +attach a route to an `Mesh` CRD. In this case, it's less intuitive to set `ParentRef.SectionName` to `443` to express `route all traffic whose destination port is 443 to ...`. It also complicates the validation on SectionName in order to differentiate between a listener name and a port number. diff --git a/geps/gep-995/index.md b/geps/gep-995/index.md index e74c9ae07e..162cc4d676 100644 --- a/geps/gep-995/index.md +++ b/geps/gep-995/index.md @@ -50,7 +50,7 @@ If specified, the name of a route rule MUST comply with the [`SectionName`](http To preserve backward compatibility with previous version of the affected APIs, the `name` field for route rules should be introduced in the API as optional – i.e., end-user are not forced to add it to their existing or new route objects. -Implementations MAY recomend the usage of the `name` field for enabling specific features, such as for supporting policy attachment targetting individual route rules, and more assertive log messages and/or status reporting that include on the name of the rule. However, because as by API design the presence of the field is optional, implementations MUST take into account that a value may sometimes not be available. For such cases, implementations are free to decide whether to provide the feature depending the `name` field, if the feature is not required for Core compliance, or to enable the feature relying on another method of referencing of choice. +Implementations MAY recommend the usage of the `name` field for enabling specific features, such as for supporting policy attachment targeting individual route rules, and more assertive log messages and/or status reporting that include on the name of the rule. However, because as by API design the presence of the field is optional, implementations MUST take into account that a value may sometimes not be available. For such cases, implementations are free to decide whether to provide the feature depending the `name` field, if the feature is not required for Core compliance, or to enable the feature relying on another method of referencing of choice. ### Default value diff --git a/geps/overview.md b/geps/overview.md index 74fed4288c..cf331cd94d 100644 --- a/geps/overview.md +++ b/geps/overview.md @@ -59,7 +59,7 @@ of stability of the change described in the GEP: * **Provisional:** The goals described by this GEP have consensus but implementation details have not been agreed to yet. - * **Prototyping:** An extension of `Provisional` which can be opted in to in + * **Prototyping:** An optional extension of `Provisional` in order to indicate to the community that there are some active practical tests and experiments going on which are intended to be a part of the development of this GEP. This may include APIs or code, but that content _must_ not be diff --git a/hack/invalid-examples/standard/httproute/invalid-httredirect-hostname.yaml b/hack/invalid-examples/standard/httproute/invalid-httpredirect-hostname.yaml similarity index 100% rename from hack/invalid-examples/standard/httproute/invalid-httredirect-hostname.yaml rename to hack/invalid-examples/standard/httproute/invalid-httpredirect-hostname.yaml diff --git a/pkg/features/gateway.go b/pkg/features/gateway.go index a90a32a4b3..7fc1a20db0 100644 --- a/pkg/features/gateway.go +++ b/pkg/features/gateway.go @@ -58,7 +58,7 @@ const ( SupportGatewayHTTPListenerIsolation FeatureName = "GatewayHTTPListenerIsolation" // SupportGatewayInfrastructureAnnotations option indicates support for - // spec.infrastructure.annotations and spec.infrastrucutre.labels + // spec.infrastructure.annotations and spec.infrastructure.labels SupportGatewayInfrastructurePropagation FeatureName = "GatewayInfrastructurePropagation" ) diff --git a/pkg/features/httproute.go b/pkg/features/httproute.go index cd7d90ec5b..8264098493 100644 --- a/pkg/features/httproute.go +++ b/pkg/features/httproute.go @@ -95,7 +95,7 @@ const ( // This option indicates support for HTTPRoute with a backendref with an appProtocol 'kubernetes.io/h2c' (extended conformance) SupportHTTPRouteBackendProtocolH2C FeatureName = "HTTPRouteBackendProtocolH2C" - // This option indicates support for HTTPRoute with a backendref with an appProtoocol 'kubernetes.io/ws' (extended conformance) + // This option indicates support for HTTPRoute with a backendref with an appProtocol 'kubernetes.io/ws' (extended conformance) SupportHTTPRouteBackendProtocolWebSocket FeatureName = "HTTPRouteBackendProtocolWebSocket" ) diff --git a/pkg/generated/openapi/zz_generated.openapi.go b/pkg/generated/openapi/zz_generated.openapi.go index 1c4fa188f7..811e47ee48 100644 --- a/pkg/generated/openapi/zz_generated.openapi.go +++ b/pkg/generated/openapi/zz_generated.openapi.go @@ -3390,7 +3390,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_GRPCRouteRule(ref common.ReferenceCall }, "filters": { SchemaProps: spec.SchemaProps{ - Description: "Filters define the filters that are applied to requests that match this rule.\n\nThe effects of ordering of multiple behaviors are currently unspecified. This can change in the future based on feedback during the alpha stage.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations that support\n GRPCRoute.\n- Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nIf an implementation can not support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", + Description: "Filters define the filters that are applied to requests that match this rule.\n\nThe effects of ordering of multiple behaviors are currently unspecified. This can change in the future based on feedback during the alpha stage.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations that support\n GRPCRoute.\n- Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nIf an implementation cannot support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -4228,7 +4228,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_HTTPHeader(ref common.ReferenceCallbac Properties: map[string]spec.Schema{ "name": { SchemaProps: spec.SchemaProps{ - Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.", + Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.", Default: "", Type: []string{"string"}, Format: "", @@ -4344,7 +4344,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_HTTPHeaderMatch(ref common.ReferenceCa }, "name": { SchemaProps: spec.SchemaProps{ - Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.\n\nWhen a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for \"Set-Cookie\".", + Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.\n\nWhen a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for \"Set-Cookie\".", Default: "", Type: []string{"string"}, Format: "", @@ -4853,7 +4853,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_HTTPRouteRule(ref common.ReferenceCall }, "filters": { SchemaProps: spec.SchemaProps{ - Description: "Filters define the filters that are applied to requests that match this rule.\n\nWherever possible, implementations SHOULD implement filters in the order they are specified.\n\nImplementations MAY choose to implement this ordering strictly, rejecting any combination or order of filters that can not be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior.\n\nTo reject an invalid combination or order of filters, implementations SHOULD consider the Route Rules with this configuration invalid. If all Route Rules in a Route are invalid, the entire Route would be considered invalid. If only a portion of Route Rules are invalid, implementations MUST set the \"PartiallyInvalid\" condition for the Route.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations. - Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nAll filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an implementation can not support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", + Description: "Filters define the filters that are applied to requests that match this rule.\n\nWherever possible, implementations SHOULD implement filters in the order they are specified.\n\nImplementations MAY choose to implement this ordering strictly, rejecting any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior.\n\nTo reject an invalid combination or order of filters, implementations SHOULD consider the Route Rules with this configuration invalid. If all Route Rules in a Route are invalid, the entire Route would be considered invalid. If only a portion of Route Rules are invalid, implementations MUST set the \"PartiallyInvalid\" condition for the Route.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations. - Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nAll filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -5487,7 +5487,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_RouteParentStatus(ref common.Reference }, }, SchemaProps: spec.SchemaProps{ - Description: "Conditions describes the status of the route with respect to the Gateway. Note that the route's availability is also subject to the Gateway's own status conditions and listener status.\n\nIf the Route's ParentRef specifies an existing Gateway that supports Routes of this kind AND that Gateway's controller has sufficient access, then that Gateway's controller MUST set the \"Accepted\" condition on the Route, to indicate whether the route has been accepted or rejected by the Gateway, and why.\n\nA Route MUST be considered \"Accepted\" if at least one of the Route's rules is implemented by the Gateway.\n\nThere are a number of cases where the \"Accepted\" condition may not be set due to lack of controller visibility, that includes when:\n\n* The Route refers to a non-existent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to.", + Description: "Conditions describes the status of the route with respect to the Gateway. Note that the route's availability is also subject to the Gateway's own status conditions and listener status.\n\nIf the Route's ParentRef specifies an existing Gateway that supports Routes of this kind AND that Gateway's controller has sufficient access, then that Gateway's controller MUST set the \"Accepted\" condition on the Route, to indicate whether the route has been accepted or rejected by the Gateway, and why.\n\nA Route MUST be considered \"Accepted\" if at least one of the Route's rules is implemented by the Gateway.\n\nThere are a number of cases where the \"Accepted\" condition may not be set due to lack of controller visibility, that includes when:\n\n* The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to.", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -6329,7 +6329,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha2_TCPRouteRule(ref common.Referenc }, "backendRefs": { SchemaProps: spec.SchemaProps{ - Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of connections, then 80% of connections must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", + Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of connections, then 80% of connections must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -6538,7 +6538,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha2_TLSRouteRule(ref common.Referenc }, "backendRefs": { SchemaProps: spec.SchemaProps{ - Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this backend, by rejecting the connection or returning a 500 status code. Request rejections must respect weight; if an invalid backend is requested to have 80% of requests, then 80% of requests must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", + Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this backend, by rejecting the connection or returning a 500 status code. Request rejections must respect weight; if an invalid backend is requested to have 80% of requests, then 80% of requests must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -6762,7 +6762,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha2_UDPRouteRule(ref common.Referenc }, "backendRefs": { SchemaProps: spec.SchemaProps{ - Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of the packets, then 80% of packets must be dropped instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", + Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of the packets, then 80% of packets must be dropped instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -7017,7 +7017,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha3_BackendTLSPolicyValidation(ref c Properties: map[string]spec.Schema{ "caCertificateRefs": { SchemaProps: spec.SchemaProps{ - Description: "CACertificateRefs contains one or more references to Kubernetes objects that contain a PEM-encoded TLS CA certificate bundle, which is used to validate a TLS handshake between the Gateway and backend Pod.\n\nIf CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both. If CACertifcateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation.\n\nReferences to a resource in a different namespace are invalid for the moment, although we will revisit this in the future.\n\nA single CACertificateRef to a Kubernetes ConfigMap kind has \"Core\" support. Implementations MAY choose to support attaching multiple certificates to a backend, but this behavior is implementation-specific.\n\nSupport: Core - An optional single reference to a Kubernetes ConfigMap, with the CA certificate in a key named `ca.crt`.\n\nSupport: Implementation-specific (More than one reference, or other kinds of resources).", + Description: "CACertificateRefs contains one or more references to Kubernetes objects that contain a PEM-encoded TLS CA certificate bundle, which is used to validate a TLS handshake between the Gateway and backend Pod.\n\nIf CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both. If CACertificateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation.\n\nReferences to a resource in a different namespace are invalid for the moment, although we will revisit this in the future.\n\nA single CACertificateRef to a Kubernetes ConfigMap kind has \"Core\" support. Implementations MAY choose to support attaching multiple certificates to a backend, but this behavior is implementation-specific.\n\nSupport: Core - An optional single reference to a Kubernetes ConfigMap, with the CA certificate in a key named `ca.crt`.\n\nSupport: Implementation-specific (More than one reference, or other kinds of resources).", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ diff --git a/pkg/gep/gepdetail.go b/pkg/gep/gepdetail.go index dd79302971..a8c2d1c714 100644 --- a/pkg/gep/gepdetail.go +++ b/pkg/gep/gepdetail.go @@ -56,7 +56,7 @@ type GEPDetail struct { // Valid values are provided in the constants for the GEPStatus type. Status GEPStatus `json:"status"` - // The GEP's authors, listed as their Github handles. + // The GEP's authors, listed as their GitHub handles. Authors []string `json:"authors"` // Relationships describes the possible relationships between this GEP and diff --git a/site-src/api-types/backendtlspolicy.md b/site-src/api-types/backendtlspolicy.md index 7a2e568388..617ff1f865 100644 --- a/site-src/api-types/backendtlspolicy.md +++ b/site-src/api-types/backendtlspolicy.md @@ -37,10 +37,10 @@ The specification of a [BackendTLSPolicy][backendtlspolicy] consists of: WellKnownCACertificates. - [Hostname][hostname] - Defines the Server Name Indication (SNI) that the Gateway uses to connect to the backend. - [CACertificateRefs][caCertificateRefs] - Defines one or more references to objects that contain PEM-encoded TLS certificates, -which are used to establish a TLS handshake between the Gateway and backend Pod. Either CACertficateRefs or +which are used to establish a TLS handshake between the Gateway and backend Pod. Either CACertificateRefs or WellKnownCACertificates may be specified, but not both. - [WellKnownCACertificates][wellKnownCACertificates] - Specifies whether system CA certificates may be used in the TLS -handshake between the Gateway and backend Pod. Either CACertficateRefs or WellKnownCACertificates may be specified, but not both. +handshake between the Gateway and backend Pod. Either CACertificateRefs or WellKnownCACertificates may be specified, but not both. The following chart outlines the object definitions and relationship: ```mermaid @@ -57,7 +57,7 @@ flowchart LR spec -->targetRefs & validation status -->ancestorStatus targetRefs -->service - note[choose only one
caCerticateRefs OR wellKnownCACertificates] + note[choose only one
caCertificateRefs OR wellKnownCACertificates] style note fill:#fff validation -.- note ``` @@ -117,7 +117,7 @@ The BackendTLSPolicyValidation must contain a certificate reference of some kind certificate to use for backend TLS, CACertificateRefs and WellKnownCACertificates. Only one of these may be used per BackendTLSPolicyValidation. -##### CACertficateRefs +##### CACertificateRefs CACertificateRefs refer to one or more PEM-encoded TLS certificates. diff --git a/site-src/api-types/grpcroute.md b/site-src/api-types/grpcroute.md index 0bb4a9b5f7..d18ce92398 100644 --- a/site-src/api-types/grpcroute.md +++ b/site-src/api-types/grpcroute.md @@ -33,7 +33,7 @@ level, it is acceptable to introduce a route resource at the higher layer when the following criteria are met: - Users of the encapsulated protocol would miss out on significant conventional features from their ecosystem if forced to route at a lower layer. -- Users of the enapsulated protocol would experience a degraded user experience if forced to route at a lower layer. +- Users of the encapsulated protocol would experience a degraded user experience if forced to route at a lower layer. - The encapsulated protocol has a significant user base, particularly in the Kubernetes community. gRPC meets all of these criteria, so the decision was made to include `GRPCRoute`in Gateway API. @@ -185,7 +185,7 @@ Conformance levels are defined by the filter type: Specifying a core filter multiple times has unspecified or custom conformance. -If an implementation can not support a combinations of filters, they must clearly +If an implementation cannot support a combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -272,7 +272,7 @@ Multiple GRPCRoutes can be attached to a single Gateway resource. Importantly, only one Route rule may match each request. For more information on how conflict resolution applies to merging, refer to the [API specification][grpcrouterule]. -[grpcroute]: /reference/spec/#gateway.networking.k8s.io/v1.GRPCPRoute +[grpcroute]: /reference/spec/#gateway.networking.k8s.io/v1.GRPCRoute [grpcrouterule]: /reference/spec/#gateway.networking.k8s.io/v1.GRPCRouteRule [hostname]: /reference/spec/#gateway.networking.k8s.io/v1.Hostname [rfc-3986]: https://tools.ietf.org/html/rfc3986 diff --git a/site-src/api-types/httproute.md b/site-src/api-types/httproute.md index 1bdade682a..ba701b7410 100644 --- a/site-src/api-types/httproute.md +++ b/site-src/api-types/httproute.md @@ -198,7 +198,7 @@ implementation-specific conformance. All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an -implementation can not support other combinations of filters, they must clearly +implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/site-src/blog/2023/0829-mesh-support.md b/site-src/blog/2023/0829-mesh-support.md index 3b8b7741ae..14b5f101de 100644 --- a/site-src/blog/2023/0829-mesh-support.md +++ b/site-src/blog/2023/0829-mesh-support.md @@ -1,7 +1,7 @@ --- description: > We are excited to announce the v0.8.0 release of Gateway API, where service - mesh support has has now reached Experimental status, we've introduced CEL + mesh support has now reached Experimental status, we've introduced CEL validation and a Mesh conformance profile, and more! --- diff --git a/site-src/contributing/devguide.md b/site-src/contributing/devguide.md index 3f7e92a9ac..5ee98407d3 100644 --- a/site-src/contributing/devguide.md +++ b/site-src/contributing/devguide.md @@ -82,7 +82,7 @@ ensuring the field name will not be reused. ### Deploy the Code -Use the following command to deploy CRDs to the pre-existing `Kind` cluster. +Use the following command to deploy CRDs to the preexisting `Kind` cluster. ```shell make crd diff --git a/site-src/contributing/enhancement-requests.md b/site-src/contributing/enhancement-requests.md index de693a5e14..6244e8c788 100644 --- a/site-src/contributing/enhancement-requests.md +++ b/site-src/contributing/enhancement-requests.md @@ -41,7 +41,7 @@ request for enhancement if that enhancement is non-trivial (which we will define as either: _implicates changes to the API specification_ OR _has some kind of end-user impact_). -Please use our [Github Discussions][discussion] forum as the initial place to +Please use our [GitHub Discussions][discussion] forum as the initial place to start, and feel free to bring that discussion up for synchronous conversation in one of our [community meetings][meetings]. If the created request doesn't include reference to a discussion and/or recordings of discussion in our diff --git a/site-src/faq.md b/site-src/faq.md index fa8b72a27e..4610d7d962 100644 --- a/site-src/faq.md +++ b/site-src/faq.md @@ -41,8 +41,8 @@ using an explicit object reference. to use. #### Where can I find Gateway API releases? -Gateway API releases are tags of the [Github -repository](https://github.com/kubernetes-sigs/gateway-api). The [Github +Gateway API releases are tags of the [GitHub +repository](https://github.com/kubernetes-sigs/gateway-api). The [GitHub releases](https://github.com/kubernetes-sigs/gateway-api/releases) page shows all the releases. diff --git a/site-src/guides/grpc-routing.md b/site-src/guides/grpc-routing.md index acba8f1105..a0740e6e4a 100644 --- a/site-src/guides/grpc-routing.md +++ b/site-src/guides/grpc-routing.md @@ -69,7 +69,7 @@ missing or does not have the value `canary` then it will be forwarded to `bar-sv Reflection](https://github.com/grpc/grpc/blob/v1.49.1/doc/server-reflection.md) is required to use interactive clients such as [`grpcurl`](https://github.com/fullstorydev/grpcurl) without having a local copy -of the target service's protocol buffers present on your local filesysem. To +of the target service's protocol buffers present on your local filesystem. To enable this, first ensure that you have a gRPC reflection server listening on your application pods, then add the reflection method to your `GRPCRoute`. This is likely to be useful in development and staging environments, but this should diff --git a/site-src/guides/implementers.md b/site-src/guides/implementers.md index eed5e62ead..1c82a8eeaf 100644 --- a/site-src/guides/implementers.md +++ b/site-src/guides/implementers.md @@ -101,7 +101,7 @@ Gateway API conformance is version-specific. An implementation that passes conformance for version N may not pass conformance for version N+1 without changes. Implementations SHOULD submit a report from the conformance testing suite back -to the Gateway API Github repo containing details of their testing. +to the Gateway API GitHub repo containing details of their testing. The conformance suite output includes the Gateway API version supported. diff --git a/site-src/guides/simple-gateway.md b/site-src/guides/simple-gateway.md index a49bce55c0..0697dfc928 100644 --- a/site-src/guides/simple-gateway.md +++ b/site-src/guides/simple-gateway.md @@ -15,7 +15,7 @@ match all HTTP traffic and directs it to a single Service named `foo-svc`. The Gateway represents the instantiation of a logical load balancer and the GatewayClass defines the load balancer template when users create a Gateway. The example Gateway is templated from a hypothetical `example` -GatewayClass, which is meant to be a placeholder and substitued by users. Here +GatewayClass, which is meant to be a placeholder and substituted by users. Here is a list of available [Gateway Implementation](https://gateway-api.sigs.k8s.io/implementations/) that can be used to determine the correct GatewayClass based on the specific diff --git a/site-src/implementations.md b/site-src/implementations.md index 778391d298..85e2dfac38 100644 --- a/site-src/implementations.md +++ b/site-src/implementations.md @@ -330,12 +330,12 @@ HAProxy Kubernetes Ingress Controller is an open-source project maintained by HA [Consul][consul], by [HashiCorp][hashicorp], is an open source control plane for multi-cloud networking. A single Consul deployment can span bare metal, VM and container environments. -Consul service mesh works on any Kubernetes distribution, connects multiple clusters, and Consul CRDs provide a Kubernetes native workflow to manage traffic patterns and permissions in the mesh. [Consul API Gateway][consul-api-gw-doocs] supports Gateway API for managing North-South traffic. +Consul service mesh works on any Kubernetes distribution, connects multiple clusters, and Consul CRDs provide a Kubernetes native workflow to manage traffic patterns and permissions in the mesh. [Consul API Gateway][consul-api-gw-docs] supports Gateway API for managing North-South traffic. -Please see the [Consul API Gateway documentation][consul-api-gw-doocs] for current information on the supported version and features of the Gateway API. +Please see the [Consul API Gateway documentation][consul-api-gw-docs] for current information on the supported version and features of the Gateway API. [consul]:https://consul.io -[consul-api-gw-doocs]:https://www.consul.io/docs/api-gateway +[consul-api-gw-docs]:https://www.consul.io/docs/api-gateway [hashicorp]:https://www.hashicorp.com ### Istio