Skip to content

Commit 339b898

Browse files
author
Nick Young
committed
Update line breaks to 80 characters or so
Signed-off-by: Nick Young <[email protected]>
1 parent cafc2c7 commit 339b898

File tree

1 file changed

+94
-34
lines changed

1 file changed

+94
-34
lines changed

‎CHANGELOG.md

+94-34
Original file line numberDiff line numberDiff line change
@@ -14,70 +14,130 @@
1414

1515
API version: v1alpha2
1616

17-
This release is intended to be last alpha release, so there are a lot of breaking API changes. Please read these release notes carefully.
17+
This release is intended to be last alpha release, so there are a lot of breaking
18+
API changes. Please read these release notes carefully.
1819

1920
### Major Changes
2021

21-
* The Gateway API APIGroup has moved from `networking.x-k8s.io` to `gateway.networking.k8s.io`. This means that, as far as the apiserver is concerned, this version is wholly distinct from v1alpha1, and automatic conversion is not possible. As part of this process, Gateway API is now subject to Kubernetes API review, the same as changes made to core API resources. More details in [#780](https://github.com/kubernetes-sigs/gateway-api/pull/780) and [#716](https://github.com/kubernetes-sigs/gateway-api/issues/716).
22-
23-
* Gateway-Route binding changes, [GEP-724](https://gateway-api.sigs.k8s.io/geps/gep-724/). Currently, Gateways choose which Routes are attached using a combination of object and namespace selectors, with the option of also specifying object names. This has made a very complex config, that's easy to misinterpret. As part of v1alpha2, we're changing to:
24-
* Gateways *may* specify what kind of Routes they support (defaults to same protocol if not specified), and where those Routes can be (defaults to same namespace).
25-
* Routes *must* directly reference the Gateways the want to attach to, this is a list, so a Route can attach to more than one Gateway.
22+
* The Gateway API APIGroup has moved from `networking.x-k8s.io` to
23+
`gateway.networking.k8s.io`. This means that, as far as the apiserver is
24+
concerned, this version is wholly distinct from v1alpha1, and automatic conversion
25+
is not possible. As part of this process, Gateway API is now subject to Kubernetes
26+
API review, the same as changes made to core API resources. More details in
27+
[#780](https://github.com/kubernetes-sigs/gateway-api/pull/780) and [#716](https://github.com/kubernetes-sigs/gateway-api/issues/716).
28+
29+
* Gateway-Route binding changes,
30+
[GEP-724](https://gateway-api.sigs.k8s.io/geps/gep-724/). Currently, Gateways
31+
choose which Routes are attached using a combination of object and namespace
32+
selectors, with the option of also specifying object names. This has made a very
33+
complex config, that's easy to misinterpret. As part of v1alpha2, we're changing to:
34+
* Gateways *may* specify what kind of Routes they support (defaults to same
35+
protocol if not specified), and where those Routes can be (defaults to same
36+
namespace).
37+
* Routes *must* directly reference the Gateways the want to attach to, this is
38+
a list, so a Route can attach to more than one Gateway.
2639
* The Route becomes attached only when the specifications intersect.
2740

28-
We believe this is quite a bit easier to understand, and still gives good flexibility for most use cases.
41+
We believe this is quite a bit easier to understand, and still gives good
42+
flexibility for most use cases.
2943
GEP added in [#725](https://github.com/kubernetes-sigs/gateway-api/pull/725).
3044
Implemented in [#754](https://github.com/kubernetes-sigs/gateway-api/pull/754).
3145
Further documentation was added in [#762](https://github.com/kubernetes-sigs/gateway-api/pull/762).
3246

3347

34-
* Safer cross-namespace references ([GEP-709](https://gateway-api.sigs.k8s.io/geps/gep-709/)): This one concerns (currently), references from Routes to Backends, and Gateways to Secrets. The new behavior is:
35-
* By default, references across namespaces are not permitted; creating a reference across a namespace (like a Route referencing a Service in another namespace) must be rejected by implementations.
36-
* These references can be accepted by creating a ReferencePolicy in the referent (target) namespace, that specifies what Kind is allowed to accept incoming references, and from what namespace and Kind the references may be.
37-
38-
The intent here is that the owner of the referent namespace must explicitly accept incoming references, otherwise we can run into all sorts of bad things from breaking the namespace security model.
48+
* Safer cross-namespace references
49+
([GEP-709](https://gateway-api.sigs.k8s.io/geps/gep-709/)): This one concerns
50+
(currently), references from Routes to Backends, and Gateways to Secrets. The
51+
new behavior is:
52+
* By default, references across namespaces are not permitted; creating a
53+
reference across a namespace (like a Route referencing a Service in another
54+
namespace) must be rejected by implementations.
55+
* These references can be accepted by creating a ReferencePolicy in the
56+
referent (target) namespace, that specifies what Kind is allowed to accept
57+
incoming references, and from what namespace and Kind the references may be.
58+
59+
The intent here is that the owner of the referent namespace must explicitly
60+
accept incoming references, otherwise we can run into all sorts of bad things
61+
from breaking the namespace security model.
3962
Implemented in [#741](https://github.com/kubernetes-sigs/gateway-api/pull/741).
4063

41-
* Attaching Policy to objects, [GEP-713](https://gateway-api.sigs.k8s.io/geps/gep-713/): This one has been added so that we have an extensible mechanism for adding a cascading set of policy to Gateway API objects.
64+
* Attaching Policy to objects,
65+
[GEP-713](https://gateway-api.sigs.k8s.io/geps/gep-713/): This one has been added
66+
so that we have an extensible mechanism for adding a cascading set of policy to
67+
Gateway API objects.
4268

43-
What policy? Well, it's kind of up to the implementations, but the best example to begin with is timeout policy.
69+
What policy? Well, it's kind of up to the implementations, but the best example
70+
to begin with is timeout policy.
4471

45-
Timeout policy for HTTP connections is highly depedent on how the underlying implementation handles policy - it's very difficult to extract commonalities.
46-
This is intended to allow things like:
47-
* Attach a policy that specifies the default connection timeout for backends to a GatewayClass. All Gateways that are part of that Class will have Routes get that default connection timeout unless they specify differently.
48-
* If a Gateway that's a member of the GatewayClass has a different default attached, then that will beat the GatewayClass (for defaults, more specific object beats less specific object).
49-
* Alternatively, a Policy that mandates that you can't set the client timeout to "no timeout" can be attached to a GatewayClass as an override. An override will always take effect, with less specific beating more specific.
72+
Timeout policy for HTTP connections is highly depedent on how the underlying
73+
implementation handles policy - it's very difficult to extract commonalities.
5074

51-
This one is a bit complex, but will allow implementations to solve some things that currently require tools like admission control.
75+
This is intended to allow things like:
76+
* Attach a policy that specifies the default connection timeout for backends
77+
to a GatewayClass. All Gateways that are part of that Class will have Routes
78+
get that default connection timeout unless they specify differently.
79+
* If a Gateway that's a member of the GatewayClass has a different default
80+
attached, then that will beat the GatewayClass (for defaults, more specific
81+
object beats less specific object).
82+
* Alternatively, a Policy that mandates that you can't set the client timeout
83+
to "no timeout" can be attached to a GatewayClass as an override. An override
84+
will always take effect, with less specific beating more specific.
85+
86+
This one is a bit complex, but will allow implementations to solve some things
87+
that currently require tools like admission control.
5288
Implemented in [#736](https://github.com/kubernetes-sigs/gateway-api/pull/736).
5389

54-
* As part of GEP-713, `BackendPolicy` has been removed, as its functionality is now better handled using that mechanism. [#732](https://github.com/kubernetes-sigs/gateway-api/pull/732).
55-
56-
* Removal of certificate references from HTTPRoutes, [GEP-746](https://gateway-api.sigs.k8s.io/geps/gep-746/):
57-
In v1alpha1, HTTPRoute objects have a stanza that allows referencing a TLS keypair, intended to allow people to have a more self-service model, where an app owner can provision a TLS keypair inside their own namespace, attach it to a HTTPRoute they control, and then have that used to secure their app.
58-
When implementing this, however, there are a large number of edge cases that are complex, hard to handle, and poorly defined - about checking SNI, hostname, and overrides, that made even writing a spec on how to implement this very difficult, let alone actually implementing it.
59-
In removing certificate references from HTTPRoute, we're using the ReferencePolicy from GEP-709 to allow Gateways to securely create a cross-namespace reference to TLS keypairs in app namespaces.
60-
We're hopeful that this will hit most of the self-service use case, and even if not, provide a basis to build from to meet it eventually.
90+
* As part of GEP-713, `BackendPolicy` has been removed, as its functionality is
91+
now better handled using that mechanism. [#732](https://github.com/kubernetes-sigs/gateway-api/pull/732).
92+
93+
* Removal of certificate references from HTTPRoutes,
94+
[GEP-746](https://gateway-api.sigs.k8s.io/geps/gep-746/):
95+
In v1alpha1, HTTPRoute objects have a stanza that allows referencing a TLS
96+
keypair, intended to allow people to have a more self-service model, where an
97+
app owner can provision a TLS keypair inside their own namespace, attach it to
98+
a HTTPRoute they control, and then have that used to secure their app.
99+
When implementing this, however, there are a large number of edge cases that
100+
are complex, hard to handle, and poorly defined - about checking SNI, hostname,
101+
and overrides, that made even writing a spec on how to implement this very
102+
difficult, let alone actually implementing it.
103+
104+
In removing certificate references from HTTPRoute, we're using the
105+
ReferencePolicy from GEP-709 to allow Gateways to securely create a
106+
cross-namespace reference to TLS keypairs in app namespaces.
107+
We're hopeful that this will hit most of the self-service use case, and even
108+
if not, provide a basis to build from to meet it eventually.
61109
GEP added in [#749](https://github.com/kubernetes-sigs/gateway-api/pull/749).
62110
Implemented in [#768](https://github.com/kubernetes-sigs/gateway-api/pull/768).
63111

64-
* The `RouteForwardTo` (YAML: `routeForwardTo`) struct/stanza has been reworked into the `BackendRef` (YAML: `backendRef`) struct/stanza, [GEP-718](https://gateway-api.sigs.k8s.io/geps/gep-718/). As part of this change, the `ServiceName` (YAML: `serviceName`) field has been removed, and Service references must instead now use the `BackendRef`/`backendRef` struct/stanza.
112+
* The `RouteForwardTo` (YAML: `routeForwardTo`) struct/stanza has been reworked
113+
into the `BackendRef` (YAML: `backendRef`) struct/stanza,
114+
[GEP-718](https://gateway-api.sigs.k8s.io/geps/gep-718/). As part of this change,
115+
the `ServiceName` (YAML: `serviceName`) field has been removed, and Service
116+
references must instead now use the `BackendRef`/`backendRef` struct/stanza.
65117

66118
### Other changes
67-
* HTTP Method matching is now added into HTTPRoute, with Extended support: [#733](https://github.com/kubernetes-sigs/gateway-api/pull/733).
119+
* HTTP Method matching is now added into HTTPRoute, with Extended support:
120+
[#733](https://github.com/kubernetes-sigs/gateway-api/pull/733).
68121

69-
* GatewayClass now has a 'Description' field that is printed as a column in `kubectl get` output. You can now end up with output that looks like this:
122+
* GatewayClass now has a 'Description' field that is printed as a column in
123+
`kubectl get` output. You can now end up with output that looks like this:
70124
```shell
71125
$> kubectl get gatewayclass
72126
NAME CONTROLLER DESCRIPTION
73127
internal gateway-controller-internal For non-internet-facing Gateways.
74128
external gateway-controller-external For internet-facing Gateways.
75129
```
76-
See [#610](https://github.com/kubernetes-sigs/gateway-api/issues/610) and [#653](https://github.com/kubernetes-sigs/gateway-api/pull/653) for the details.
130+
See [#610](https://github.com/kubernetes-sigs/gateway-api/issues/610) and
131+
[#653](https://github.com/kubernetes-sigs/gateway-api/pull/653) for the details.
77132

78-
* [#671](https://github.com/kubernetes-sigs/gateway-api/pull/671) Controller is now a required field in Gateway references from Route status. Fixes [#669](https://github.com/kubernetes-sigs/gateway-api/pull/671).
79-
80-
* [#657](https://github.com/kubernetes-sigs/gateway-api/pull/657) and [#681](https://github.com/kubernetes-sigs/gateway-api/pull/681) Header Matching, Query Param Matching, and HTTPRequestHeaderFilter now use named subobjects instead of maps.
133+
* [#671](https://github.com/kubernetes-sigs/gateway-api/pull/671) Controller is
134+
now a required field in Gateway references from Route status. Fixes
135+
[#669](https://github.com/kubernetes-sigs/gateway-api/pull/671).
136+
137+
* [#657](https://github.com/kubernetes-sigs/gateway-api/pull/657) and
138+
[#681](https://github.com/kubernetes-sigs/gateway-api/pull/681) Header Matching,
139+
Query Param Matching, and HTTPRequestHeaderFilter now use named subobjects
140+
instead of maps.
81141

82142

83143
### Documentation Updates

0 commit comments

Comments
 (0)