sigs.k8s.io/gateway-api@v1.0.0/site-src/blog/2021/introducing-v1alpha2.md (about) 1 --- 2 description: > 3 We’re pleased to announce the release of v1alpha2, our second alpha API 4 version. This release includes some major changes and improvements. This post 5 will cover the highlights. 6 --- 7 8 # Introducing Gateway API v1alpha2 9 10 <small style="position:relative; top:-30px;"> 11 :octicons-calendar-24: October 14, 2021 · 12 :octicons-clock-24: 5 min read 13 </small> 14 15 We’re pleased to announce the release of v1alpha2, our second alpha API version. 16 This release includes some major changes and improvements. This post will cover 17 the highlights. 18 19 ## Highlights 20 21 ### New API Group 22 To recognize our status as an official Kubernetes API, we've transitioned from 23 an experimental API group (`networking.x-k8s.io`) to the new 24 `gateway.networking.k8s.io` API group. This means that, as far as the apiserver 25 is concerned, this version is wholly distinct from v1alpha1, and automatic 26 conversion is not possible. 27 28  29 30 ### Simpler Route-Gateway Binding 31 In v1alpha1 we provided many ways to connect Gateways and Routes. This was a bit 32 more complicated to understand than we'd like. With v1alpha2, we've focused on 33 simpler attachment mechanism: 34 35 * Routes directly reference the Gateway(s) they want to attach to. This is a 36 list, so a Route can attach to more than one Gateway. 37 * Each Gateway listener can choose to specify the kinds of Routes they support 38 and where they can be. This defaults to Routes that support the specified 39 protocol in the same Namespace as the Gateway. 40 41 For example, the following HTTPRoute uses the `parentRefs` field to attach 42 itself to the `prod-web-gw` Gateway. 43 44 ```yaml 45 apiVersion: gateway.networking.k8s.io/v1alpha2 46 kind: HTTPRoute 47 metadata: 48 name: foo 49 spec: 50 parentRefs: 51 - name: prod-web 52 rules: 53 - backendRefs: 54 - name: foo-svc 55 port: 8080 56 ``` 57 58 This is covered in more detail in [GEP 724](https://gateway-api.sigs.k8s.io/geps/gep-709/). 59 60 ### Safe Cross Namespace References 61 62 !!! info "Experimental Channel" 63 64 The `ReferenceGrant` resource described below is currently only included in the 65 "Experimental" channel of Gateway API. For more information on release 66 channels, refer to the [related documentation](https://gateway-api.sigs.k8s.io/concepts/versioning). 67 68 It is quite challenging to cross namespace boundaries in a safe manner. With 69 Gateway API, we had several key feature requests that required this capability. 70 Most notably, forwarding traffic to backends in other namespaces and referring 71 to TLS certificates in other namespaces. 72 73 To accomplish this, we've introduced a new ReferenceGrant resource that 74 provides a handshake mechanism. By default, references across namespaces are not 75 permitted; creating a reference across a namespace (like a Route referencing a 76 Service in another namespace) must be rejected by implementations. These 77 references can be accepted by creating a ReferenceGrant in the referent 78 (target) namespace, that specifies what Kind is allowed to accept incoming 79 references, and from what namespace and Kind the references may be. 80 81 For example, the following ReferenceGrant would allow HTTPRoutes in the prod 82 namespace to forward traffic to Services wherever this ReferenceGrant was 83 installed: 84 85 ```yaml 86 apiVersion: gateway.networking.k8s.io/v1alpha2 87 kind: ReferenceGrant 88 metadata: 89 name: allow-prod-traffic 90 spec: 91 from: 92 - group: gateway.networking.k8s.io 93 kind: HTTPRoute 94 namespace: prod 95 to: 96 - group: "" 97 kind: Service 98 ``` 99 100 This is covered in more detail in [GEP 709](https://gateway-api.sigs.k8s.io/geps/gep-709/). 101 102 ### Policy Attachment 103 One of the key goals of this API is to provide meaningful and consistent 104 extension points. In v1alpha2, we've introduced a new standard for attaching 105 policies to Gateway API resources. 106 107 What is a policy? Well, it's kind of up to the implementations, but the best 108 example to begin with is timeout policy. 109 110 Timeout policy for HTTP connections is highly dependent on how the underlying 111 implementation handles policy - it's very difficult to extract commonalities. 112 113 This is intended to allow things like: 114 115 * Attaching a policy that specifies the default connection timeout for backends 116 to a GatewayClass. All Gateways that are part of that Class will have Routes 117 get that default connection timeout unless they specify differently. 118 * If a Gateway that's a member of the GatewayClass has a different default 119 attached, then that will beat the GatewayClass (for defaults, more specific 120 object beats less specific object). 121 * Alternatively, a Policy that mandates that you can't set the client timeout to 122 "no timeout" can be attached to a GatewayClass as an override. An override 123 will always take effect, with less specific beating more specific. 124 125 As a simple example, a TimeoutPolicy may be attached to a Gateway. The effects 126 of that policy would cascade down to Routes attached to that policy: 127 128  129 130 This is covered in more detail in [GEP 713](https://gateway-api.sigs.k8s.io/geps/gep-713/). 131 132 ## Next Steps 133 There are a lot of changes in v1alpha2 that we haven't covered here. For the 134 full changelog, refer to our [v0.4.0 release 135 notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.4.0). 136 137 Many of our [implementations](/implementations) are planning to release support 138 for the v1alpha2 API in the coming weeks. We'll update our documentation as 139 v1alpha2 implementations become available. 140 141 We still have lots more to work on. Some of our next items to discuss include: 142 143 * Conformance testing 144 * Route delegation 145 * Rewrite support 146 * L4 Route matching 147 148 If these kinds of topics interest you, we'd love to have your input. Refer to 149 our [community page](/contributing/community) to see how you can get involved.